MMWWWMWWWWW
`
`WMWMWMWW
`
`US 20090l632l 1A1
`
`(19) United States
`(12) Patent Application Publication (10) Pub. No.: US 2009/0163211 A1
`Kitazoe et al.
`(43) Pub. Date:
`Jun. 25, 2009
`
`(54)
`
`METHOD AND APPARATUS FOR TRANSFER
`OF A MESSAGE ON A COMMON CONTROL
`CHANNEL FOR RANDOM ACCESS IN A
`WIRPZIJPZSS (.‘OMMUNI(.‘A'l”l()N NI-2'lWV()RK
`
`Publication Classification
`
`(51)
`
`Int. Cl.
`HOIIW 36/90
`
`(2009.01)
`
`(75)
`
`lnvetttors:
`
`Masato Ki tame. Tokyo (JP):
`Arnaud Meylan. San Diego. CA
`(US)
`
`Cttnespttndence Address:
`QU.-—\I.( i( )NI M I lN( 30 RI-"( )RATlC I)
`5775 NIOREHOUSE DR.
`SAN DIFGO, CA 92121 (US)
`
`(73)
`
`Assigtteez
`
`QUAI.(?().V[M Incorporated. San
`Diego. CA (US)
`
`(21)
`
`Appl. No.:
`
`12.-337,383
`
`(22)
`
`Filed:
`
`Dec. 17.. 2008
`
`Related U.S. Application Data
`
`(60)
`
`Pnwisionulz1pplicatiunNc. (aU0l5.l59. filed on Dec.
`19. 2007.
`
`(52) U.S.(.'l.
`
`455436
`
`(57)
`
`Ans'1‘R.A(:'l‘
`
`Techniques for sending, a message for random access by a
`user equipment (U li) are described. In an aspect. tl1e U17. may
`send 1l1e message on a ctnttml channel for random access and
`may send a reserved channel identifier to indicate the tnessage
`being sent on the control channel. In another aspect. tl1e Ul-F,
`may send the message in a protocol data unit (PDUJ and may
`send additional information (e.g.. a bu tier status report) in the
`PDU ifit can accoinnlodate the additional information. In yet
`another aspect. the Uli may generate a short message authen-
`licalitm code for integrity protection (MAC-I) [hr the mes-
`sage. The sllort MAC‘-l may have a smaller size and may be
`used to authenticate the U13. In yet another aspect. the U F. may
`send a U13 1].) ofone olmulliple types for random access and
`may convey the UE [B type via a fc-rniat field in the niessage.
`
`APPLE 1009
`
`APPLE 1009
`
`1
`
`

`
`PatentApplicati0n Publication
`
`Jun. 25, 2009 Sheet 1 of 10
`
`US 2009l016321l A1
`
`2
`
`

`
`PatentApplicati0n Publication
`
`Jun. 25, 2009 Sheet 2 of 10
`
`US 2009l016321l A1
`
`sou--on-noon.-an-nu-an-an---qnu---anpaaononoguuounaunoauouunau-u-cu.----on-un----on-nun.-no-anu--I
`
`xc:
`
`6?_l""--f
`
`_m>mJ_
`
`A--u
`‘_
`_l--...-4
`
`_m.o_mb._n_
`
`_m>m4
`
`3
`
`

`
`PatentApplicati0n Publication
`
`Jun. 25, 2009 Sheet 3 of 10
`
`US 2009l016321l A1
`
`CCCH
`
`DOC”
`
`DTCH
`
`Uplink
`Logical Channels
`
`
`
`RACH
`
`UL"SCH
`
`Upiink
`Transport Channels
`
`FIG. 3
`
`Random Access Preamble
`
`Random Access Response
`
`Scheduled Transmission (Message 3)
`
`Contention Resolution
`
`FIG. 4
`
`4
`
`

`
`PatentApplicati0n Publication
`
`Jun. 25, 2009 Sheet 4 of 10
`
`US 2009I016321l A1
`
`RRC
`
`RRC Message
`
`RRC Message =
`PDCP SDU
`
`< 3|<3
`<:T<:‘
`
`RRC Message
`
`PDCP PDU =
`RLP SDU
`
`RRC Message
`
`- Reserved
`
`LCID
`
`<=
`
`MAC
`
`RRC Message
`
`eader
`
`HMAC
`
`RRC Message
`
`MAC PDU =
`
`PHY SDU
`
`PHY PDU
`
`Message 3
`
`FIG. 5
`
`5
`
`

`
`PatentApplicati0n Publication
`
`Jun. 25, 2009 Sheet 5 of 10
`
`US 2009I016321l A1
`
`
`
`umo_>mn_o<s_
`
`
`
`_m_2$xo<s_
`
`.m6mmE-n_aw_mnmm7._#o_:m
`
`_.
`
`_m_umm;-n_:m
`
`6
`
`

`
`PatentApplicati0n Publication
`
`Jun. 25, 2009 Sheet 6 of 10
`
`US 2009l016321l A1
`
`8-Bit MAC Sub-header
`
`710
`3*’
`
`FIG. 7A
`
`‘I6-Bit MAC Sub-header
`
`720
`3"
`
`
`
`24-Bit MAC Sub-header
`
`730
`V’
`
`
`
`7
`
`

`
`MP.
`
`3
`
`mM
`
`90
`
`0
`
`US 2009!016321l A1
`
`.mnew052_%$._-%m0,32Ba
`
`
`um.;l|DDn_Od._._.,._:n_-©mliv
`
`
`
`n398850mmE403coummfizm2000.
`
`
`0mmmem
`
`
`n._.:mE;m_3Emm,m._cozomccoo0mm.5:m\..XI000commmwwmfi
`
`"WHmmooowEmnummnzw5.EmEr_om:mG5
`
`M1.
`
`.nanammm
`
`
`
`_o__.$__-%wam,.fimmmmmmEoxmEam.__c%$_E:mI000._..m_now04.5.0<_2E-»Mmm.._uE
`
`
`
`
`
`
`I000:0®mmwwm_>_ommn__0._m_
`
`
`
`
`
`N. DDn_O/w_>_:n_-vo_. .
`
`.u:08mmmw\..l%9%Q3980%«mm
`
`
`.mI000cowmmwwwfi0mm._mnmmE-n_:mhmnmw_._-n:wUmOE
`
`\...l
`
`ovmAllw:n_mm.02.IIIIIw:n_um.6m[VIII25mIilll.E5mI‘.
`
`NaammaSmSumNEW
`
`
`
`
`
`
`
`._o_ummE-p:m..m_ommE-n:w._mbmmE-n_:w
`
`
`
`
`
`m:__u_umn_1000ccmmmmwmfiommm.:_uumn_I000mwm
`
`
`
`.595z.wTmtg8Lo2.ll!95E.0mIIYII£5mIYIII25SIIIII95mIt...
`
`9..GE
`
`8
`
`

`
`Patent Application Publication
`
`Jun. 25, 2009 Sheet 8 of 10
`
`US 2009f016321l A1
`
`Send a message on a control
`channel (e.g., an RRC message on
`CCCH) for random access by a UE
`
`Send a message in a PDU, the
`message being sent on a control
`channel for random access by a UE
`
`Send a reserved channel
`
`identifier (e.g., a reserved LCID)
`to indicate the message being
`sent on the control channel
`
`Send the message and the
`reserved channel identifier on an
`
`uplink shared channel (UL-SCH)
`carrying the control channel
`
`Send additional information in the
`PDU if the PDU can accommodate
`the additional information
`
`Pad the message, if needed,
`to obtain a predetermined
`message length andfor pad the
`PDU, if needed, to fill the PDU
`
`FIG. 9
`
`FIG. 10
`
`9
`
`

`
`PatentApplication Publication
`
`Jun. 25, 2009 Sheet 9 of 10
`
`US 2009I016321l A1
`
`1100
`r../
`
`Generate a short MAC-I for a
`
`message sent on a control channel
`for random access by a UE, the short
`
`MAC-i having a smaller size than a
`full MAC—l used for integrity protection
`of messages sent on a control plane
`
`Send the message
`comprising the short MAC-l
`for random access by the UE
`
`Set a format field of a message
`to a first value to indicate a first
`type Of
`being Sent in the
`message or to a second value to
`indicate a second type of UE ID
`being sent in the message
`
`Generate the message comprising
`the format fietd and a UE ID of the
`
`type indicated by the format field
`
`1216
`
`Send the message for
`random access by a UE
`
`FIG. 12
`
`10
`
`
`
`
`1300
`r_/
`
`
`
`1312
`
`Generate an RRC message on a
`CCCH for random access by a UE
`
`1314
`
`1316
`
`1320
`
`Generate a MAC SDU
`comprising the RRC message
`
`Generate a MAC sub—header
`
`comprising a reserved LCD to
`indicate the RRC message
`being sent on the CCCH
`
`Generate a MAC PDU
`
`comprising the MAC
`sub—header and the MAC SDU
`
`Send the MAC PDU for
`random access
`the
`
`10
`
`

`
`PatentApplicati0n Publication
`
`Jun. 25, 2009 Sheet 10 of 10
`
`US 2009l016321l A1
`
`NE“...
`
`28
`
`mo.5ow
`
`~_EmcmC.
`
`.owmoo9n_
`
`3GE
`
`O_>___>_
`
`._Du_Umu_0D
`
`o>_moow_
`
`Lommmuoi
`
`m>_moom
`
`Lommoooi
`
`02:2
`
`._2uBma
`
`02:2Xh
`
`._owwmoo._n_
`
`._omwooo._n_tEmCMC:
`
`___.._®=0bCO./.u
`
`.owm..wo9n_
`
`.m_:vmEow
`
`.:o__o..EoO
`
`.ommmuo._n_
`
`11
`
`11
`
`

`
`US 2009f0l632l1 Al
`
`Jun. 25, 2009
`
`METHOD AND APPARATUS FOR TRANSFER
`OF A MESSAGE ON A COMMON CONTROL
`CHANNEL FOR RANDOM ACCESS IN A
`\lVIRELI~lSS (.‘()MMUNI(fA'I'lON Nlll'IWORK
`
`CLAIM OF PRIORITY UNDER 35 U.S.C. §l 19
`
`[0001] The present application for patent claims priority to
`Provisional US. Application Ser. No. 6li'Ol5.l59. entitled
`“MF,'l'I-IODS AND APPARATUSIES FOR TRANSFER OF
`l’IRS'I' S(TIIIiDUI.I€I.)
`’l‘RANSMlSSI()N USING CON-
`TROL CHANNEL.” filed Dec. 19. 2007. assigned to the
`assignee hereof. and expressly incorporated herein by refer-
`ence.
`
`BACKGROUND
`
`I. Field
`[0002]
`[0003] The present disclosure relates generally to commu-
`nication. and more specifically to techniques for performing
`random access in a wireless comrntuiication network.
`
`11. Background
`[0004]
`[0005] Wireless communication networks are widely
`deployed to provide various coinrnunication services such as
`voice, video. packet data, messaging. broadcast. etc. These
`networks may be multiple-access networks capable of sup-
`porting multiple users by sharing the available network
`resources.
`lixamples of such multiple~aceess networks
`include Code Division Multiple Access (CDMA) networks.
`Time Division Multiple Access (TDMA) networks. Fre-
`quency Division Multiple Access
`(FDMA) networks.
`Orthogonal FDMA (OFDMA) networks, and Single-Carrier
`FDMA {SC-l"l')MA) networks.
`[0006] A wireless communication network may include a
`number of base station that can support eonlmunication for a
`number of user equipments (UEs}. A UE may perform ran-
`dom access i11 order to establish a connection with a base
`station. The UH may send pertinent in.formation used to estab-
`lish the connection.
`It is desirable to elficiently send the
`ittlormatiotl during random access.
`
`SUMMARY
`
`" ‘echniques for sending a message for random
`[0007]
`access by a U13 are described herein. In an aspect. a reserved
`channel identifier may be used to indicate a message being
`sent on a control channel for random access. In one design. a
`UE may send a message on a control channel for random
`access and may also send a reserved channel identifier to
`indicate the message being sent on tl1e control channel. The
`message sent on the control channel may comprise a Radio
`Resource Control (RRC) message sent on a common control
`channel (CCCI-I), which may be mapped to an uplink shared
`channel
`(UI..-SCI-I). The reserved channel
`identifier may
`comprise a reserved logical channel identifier [LCID).
`[0008]
`In another aspect, a message and additional infor-
`mation may be sent for random access. In one design. a UE
`may send a message in a protocol data unit (Pl.)U}. with the
`message being sent on a control channel for random access by
`the U E. The UE may send additional information in the PDU
`if the PDU can accommodate the additional information. The
`additional information may comprise a buffer status report for
`the UE. a power headroom report for the UE, data for a
`dedicated control channel, data for a dedicated traffic chan-
`nel. etc. The PDU may have a variable size determined based
`on an uplink grant for the U13.
`
`In yet another aspect. a short message autl1entica-
`[0009]
`tion code for integrity protection {MAC-I) may be sent in a
`message for random access. In one design. a UE may generate
`a short MAC.‘-I for 3 message sent on a control channel for
`random access. The short MAC.‘-I may have a smaller size
`than a full MAC-1 used for integrity protection of messages
`sent on a control plane. The short MAC-1 may be for an RRC
`message sent on the CCCH for RRC connection re-establish-
`n1ent and may be used to authenticate the UE.
`[0010]
`In yet another aspect. a UE ID of one of multiple
`types may be sent for random access. I11 one design, a UII 111ay
`set a format field ofa message to a first value to indicate a first
`type ofUE ID being sent in the message (eg. for attachment)
`or to a second value to indicate a second type ofUE ID being
`sent in the message (e.g.. for subsequent access). The UE may
`generate the message comprising the fomiat field and a UE ID
`ofthe type indicated by the format field. The UE may send the
`message for random access.
`[0011] Various aspects and features of the disclosure are
`described in further detail below.
`
`BRIEF DESCRIPTION OF TH E DRAWINGS
`
`FIG. I shows a wireless communication network.
`[0012]
`FIG. 2 shows protocol stacks for a control plane in
`[0013]
`Long Term Evolution (LTE}.
`[0014]
`FIG. 3 shows mapping oflogical channels to trans-
`port‘ channels for the up] ink.
`[0015]
`FIG. 4 shows a message flow for a random access
`procedure in LTE.
`[0016]
`FIG. 5 shows processing to generate Message 3 in
`the random access procedure.
`[0017]
`FIG. 6 shows a Medium Access Control (MAC)
`PDU for Message 3.
`[0018]
`FIGS. 7A to TC show three MAC sub-headers.
`[0019]
`FIGS. 8A to 81) show four MAC PDUs carrying a
`message for random access.
`[0020]
`FIG. 9 shows a process for sending. a message on a
`control channel with a reserved channel iclenlilier for random
`£:lCC€SS.
`
`FIG. 10 shows a process for sending a message and
`[0021]
`additional information for random access.
`[0022]
`FIG. 11 shows a process forsendinga message with
`a short MAC-1 for random access.
`
`FIG. 12 shows a process for sending a UE ID for
`[0023]
`random access.
`
`FIG. 13 shows a process for sending a message for
`[0024]
`random access.
`
`FIG. 14 shows a block diagram of an eNB;'base
`[0025]
`station and a UE.
`
`DETAILED DESCRIPTION
`
`[0026] The techniques described herein may be used for
`various wireless communication networks such as CDMA,
`TDMA_. FDMA. OFDIVLA. SC —FDMA and other networks.
`The terms “network" and “system” are often used inter-
`changeably. A CDMA network may implement a radio tech-
`nology such as Universal Terrestrial Radio Access (UTRA).
`cdJna2000.
`etc. UTRA includes Wideband CDMA
`(WCDMA} and other variants of C DMA. cdma2000 covers
`IS—2000, IS—95 and IS-856 standards. A TDMA network may
`implement a radio technology such as Global System tor
`Mobile C0l'I‘ll1'1i.ll'].lCEl'lI0l1S (GSM). An (JFDMA network may
`impiement a radio technology such as Evolved UTRA
`
`12
`
`12
`
`

`
`US 2009l0l632l1 A1
`
`Jun. 25, 2009
`
`[0031] RRC messages may be exchanged between UF. I20
`and eNB 110 via Packet Data Convergence Protocol (PDCP]_.
`Radio Link Control (RLC). and Medium Access Control
`(MAC }. which are sublayers of Layer 2 (L2). Each protocol
`receives service data units (Sl)Us) from a higher sttblayerf
`layer and provides protocol data units (PDUs) to a lower
`sublayerflayer. PDC P may perfonn various functions such as
`ciphering (i.e._. encryption) and integrity protection for con-
`trol plane. cipltering and header compression for user plane.
`etc. RLC may perzfomi various functions such as (i) segmen-
`tation and concatenation of RLC SDUS and error correction
`through Automatic Repeat reQuest (ARQ) at a transmitting
`entity and (ii) duplicate detection of lower layer SIJUs_. re-
`ordering of RLC SDUs. and in-order delivery of upper layer
`PDUS at a receiving entity. MAC may perform various func-
`tions such as rnapping between logical channels and transport
`channels. rnultiplexing and dentultiplexing of RLC l’DUs for
`logical channels intoffroni transport blocks for transport
`channels. tratlic voltunc mcasurelnent reponing, error correc-
`tion through llybrid ARQ (IIARQ), priority handling
`between logical channels ofa UE. priority handling between
`UEs via dynamic scheduling. transport format selection. pad-
`ding. etc. The functions performed by RRC. PDCP. RI .C and
`MAC in LTE may be provided by equivalent protocols in
`other radio technologies. UE 120 further communicates with
`chili 110 via 1"‘.-UTRA air-link interface at the physical layer
`(PI-IY).
`[0032] MAC may provide data transfer services via logical
`channels. A set of logical channels may be defined for differ-
`ent data lransfer services offered by MAC. MAC may also
`utilize a set of transport channels to carry data for the logical
`channels. The logical channels may be characterized by what
`is transported whereas the transport channels may be charac-
`terized by how and with what characteristics user data and
`control data are translerrcd over a radio interface. The logical
`channels may be mapped to transport channels. which may
`further be mapped to physical channels.
`[0033] Table 1 lists some logical and transport channels in
`LTE. LTE supports other logical and transport channels that
`are not shown in Table 1 for simplicity.
`
`'l’AI3Ll'.i l
`
`I.ogica| and Tranfirt Cliaitnels in LTF.
`
`Type
`
`Cfhannel
`
`{T 1annc Nsu-ne Description
`
`line with double arrows indicates a UE performing random
`access.
`
`Logicrtl
`
`DTCH
`
`[E-UTRA), Ultra Mobile Broadband (UMB), IEEE 802.11
`(W1-Fi).
`IEEE 802.16 (WiMAX)_.
`IEEE 802.20, Flash-
`OFDMFBJ. etc. E—UTRA employs OFDMA on the downlink
`and SC-I-'lJM,I\ on the uplink. 3G1-’P I.t.'Jng Term livolution
`(I..Tl'E) utilizes an air interface defined by l'.i-UTRA and a
`network architecture defined by an E-UTRAN. UTRA.
`E-UTRA. E-UTRAN. LTE and GSM are described in docu-
`ments from an organization named ‘‘3rd Generation Partner-
`ship Project" (3GPP). cdma2t)0O and UMB are described in
`documents from an organization named “3rd Generation
`Partnership Project 2" (3(‘rPl-’2}. For clarity, certain aspects of
`the tcchtliques are described below for [..'l"|.i_. and I.'I‘l.". termi-
`nology is used in much of the description below.
`[0027]
`FIG.
`"I shows a wireless conununication network
`100. which may be an LTE network. Network 100 may
`include evolved Node Bs (eNBs) 110 and other network
`entities described by 3GPP. An eNB may be a fixed station
`that conirnnnicates with the UEs and may also be referred to
`as 3 Node B. a base station. an access point. etc. liach CNB
`r11ay provide communication coverage for a particular geo-
`graphic area. To improve network capacity. the overall cov-
`erage area of an eNB may be partitioned into multiple {c.g.,
`three) smaller areas. Each smaller area may be served by a
`respective eNB subsystem. In 3-GPP. the term “cell" can refer
`to the smallest coverage area of an eNB andfor an eNB sub-
`system serving this coverage area.
`Izintity (MMl.i)fServing
`[0028] A Mobility’ Management
`Gateway {S-GW) 130 may couple to a set ofeNl3s and pro-
`vide coordination aud control for these eNBs. Serving gate-
`way 130 may support data services such as packet data. Voice-
`over-lnternet Protocol (VOIP). video. messaging, etc. MME
`130 may be responsible for path switching between a source
`cNl3 and a target eNI3 at handover. MMl7.fserving gateway
`130 may couple to a core andfor data network (c.g.. the
`Internet) and may communicate with other entities {e.g._.
`remote servers and tenninals) coupled to the corefdata net-
`work.
`
`U135 120 may be dispersed throughout the network.
`[0029]
`and each UE may be stationary or mobile. A UE may also be
`referred to as a mobile station. a terminal. an access terminal.
`a subscriber unit. a station, etc . A U Ii may be a cellular plione,
`a personal digital assistant (PDA), a wireless modem, a wire-
`less conimutiication device. a handheld device. a laptop com-
`puter. a cordless phone, a wireless local loop [WI_L) station.
`etc. A UIE may communicate with an cNl3 via the downlink
`and uplink. The downlink (or forward link) refers to the
`communication link from the eNB to the UE. and the uplink
`(or reverse link] refers to the communication link front the UIE
`to the em}. In l"lG. 1 _. a solid line with double arrows indicates
`active communication between an eNB and a UE. A dashed
`
`FIG. 2 shows example protocol stacks 200 for a
`[0030]
`control plane in LTE. The control plane carries signaling
`between a U5 120 and MME 130 via an eNB 110. UE 120
`may cornnninication with MMIE 130 via a Non-Access Stra-
`tum (NASJI control protocol. NAS may perform various func-
`tions such as Evolved Packet System [BPS] bearer n1anage-
`ment, authentication. mobility handling. paging origination.
`security control. etc. UE 120 may exchange signaling mes-
`sages witheNB 110 via Radio Resource Control (RRC). RRC
`may perform functions such as RRC connection manage-
`ment. U I-5 measurernent reporting and control. radio bearer
`(RB) control. mobility functions. broadcast, paging, etc.
`
`I.ogical
`
`CCCH
`
`Logical
`
`DCCII
`
`'I'r:i.nspurt RACH
`
`‘l‘ra.nsport Ul.-S(.‘H
`
`Transport
`
`DL—SCH
`
`Coninion
`Control
`C I.'l.l1J1U
`Dedicated
`Control
`C Iannc
`Dedicated
`Traffic
`C iaruie
`Random
`Access
`C I.LII]1l..
`Uplink
`Sliared
`C Iti.lI.l'IC
`Downlink
`Shared
`C ianne
`
`Carry control rlal.'11n.-‘from 3 U F2
`not known to the network.
`
`Carry control data toffroiii it UE
`known to the network.
`
`Carry user tiatrt toffrotn .-t L'l':.
`
`Carry rarlrlorn access preambles
`on uplink from :1 HE.
`
`Carry usertinla arid control data
`on uplink from n L‘-E.
`
`t'_‘arr_v user data and control data
`on rlowrtl ink to 21 l.TlE_
`
`FIG. 3 shows a mapping of some logical channels to
`[0034]
`transport channels for the uplink in LTH. On the nplink. the
`
`13
`
`13
`
`

`
`US 2009f0l632l1 A1
`
`Jun. 25, 2009
`
`CC(.‘I--I. DCCI-I and DTCI-I may be mapped to the UL-SCH. A
`UE may use the CCCH when the network does not know the
`identity of the UE and may use the DCC H when the network
`knows the identity of the U I3. On the downlink, the CCCI-l
`may be mapped to the I31.-SCII (not shown in I"-‘I(i. 3).
`[0035] A U13 may perform a random access procedure in
`order to access the network andfor ibr other purposes. The
`terms “random access”. “system access". and “access" may
`be used interchangeably. For example. the UE may perform
`the random access procedure for the following random access
`scenarios:
`[0036] RRC connection rt:-establishiileiit,
`[0037] Attachment
`to the network. e.g.. based on an
`International Mobile Subscriber Identity (IMSI). or
`[0038]
`Subsequent access to the network for transition
`from an Idle mode to an Active mode. e.g.. based on an
`EPS Temporary Mobile Subscriber Identity {S-TMSI).
`[0039] The UE may also perform the random access pro-
`cedure for hartdover access when the U Ii is handed over from
`
`one cNI3 to another eN]-3. The U IE may also perform the
`random access procedure for other scenarios. The UE may
`use the CCCH for RRC connection re-establisliment. attach-
`ment. and subsequent access.
`[0040]
`FIG. 4 shows a message flow 400 for the random
`access procedure in LTE. A UE may transmit a random access
`(RA) preamble on the RACII whenever the [Hi desires to
`access the network and resources are available [step 1). The
`RA preamble may also be referred to as Message I. The RA
`preamble may be identified by an RA preamble identifier (ID)
`used as a temporary II) for the U E during the random access
`procedure. An eNB may receive the RA preamble from the
`UE and possibly RA preambles from other UEs. The eNB
`may send a random access resportse on the DI.-SCH to
`respond to one or more RA preambles (step 2). The random
`access response may also be referred to as Message 2 and may
`include various types ofinforiiiation such as the RA preamble
`ID. timing alignment information. an initial uplink grant. an
`assignment of a temporary UE ID. etc.
`[0041] The UE may receive the random access response
`from the eNB and may send a first scheduled transmission on
`l.l1e UI.-SCII. The first scheduled transmission may also be
`referred to as Message 3 and may include different infom1a-
`tion for different types of random access. as described below.
`The size of the first scheduled transmission may be dependent
`on the uplink grant conveyed in Message 2. The eN}3 may
`receive the first scheduled transmission and may send a mes-
`sage on the DL—SCH for contention resolution. if necessary
`[step 4). A collision may occur when multiple Ulfis send the
`same RA preamble on the RACI-I. Contention resolution may
`be perfonned to resolve which UE is granted access.
`[0042] The random access procedure ‘liar LTE is described
`in 3GPP TS 36.213. TS 36.300. TS 36.321 and TS 36.33 I.
`which are publicly available.
`[0043] The first scheduled transmission in step 3 is referred
`to as Message 3 in most ofthe description below. Table 2 lists
`different types of information that may be sent in Message 3
`for different random access scenariosttypes, in accordance
`with one design. I MS] is a UE identity (ID) that is globally
`unique. S-TMSI is a U131 ID that is unique within a network.
`Cell Radio Network Temporary Identifier (C-RNTI} is a UE
`ID that is unique within a cell. The different types of UE IDs
`may be applicable tor different areas and may have different
`lengths. MAC-I is a Message Authentication Code for Integ-
`rity protection and may be used to authenticate the sender of
`
`a message. Table 2 also gives the number ofbits for each type
`of information in accordance with one design. Other types of
`information may also be sent for each random access type.
`
`iIiAI3I.I.i 2
`
`Initial bit counts for Message 3
`
`Rant! om Access Typg
`
`RRC‘ Coiniection
`RL'—t_’3-}l2lbllSl1Illl.' nl
`
`."\I'lllC.l1lIlL‘I1l
`
`Subsequent
`»\ecess
`
`In.it.i:I.| UE identity Initial L'-E identity
`Old cell ID: 9 bits.
`tIMS[]: 84 hits
`(S-T.\«'fSI}: 4-l'J bits
`Old (.‘-RN'I"I: 16 bits.
`l.istablisIuiie1|I
`Estsbiisitrnent
`MAC-I: 32 hits.
`cause: 3 bits
`cruise: 3 bits
`Frequency info: 14
`bits
`PDCP wititoul MAC-I: 8 bits
`REX‘-"I'M: ill hil
`MAC header: to bits
`Physical iaycr (.‘RC: 24 bits
`87
`48
`
`T1
`48
`
`43
`48
`
`I I9
`
`I35
`
`91
`
`I .:i_ver
`
`RRC‘
`
`PDCP
`R11.‘
`MAC
`PI-IY
`RRC bits
`Other bits
`
`Total hits
`
`[0044] The UE may be allocated an uplink grant for send-
`ing Message 3. In one design, the uplink grant may be at least
`80 bits and may be given in multiple of8 bits. e.g._. 80 bits, 88
`bits. 96 bits. etc. The minimum uplink grant of80 bits may be
`selected based on various factors such as the amount of infor-
`
`mation to send in Message 3. the desired performance at cell
`edge. etc. Fewer bits (e.g.. 72 bits) or more bits may also be
`supported for the minimum uplink grant.
`[0045] As shown in Table 2, the total number of bits for
`Message 3 foreach random access type exceeds the minimum
`uplink grant of 80 bits. 11 may be desirable to reduce the total
`number of bits for Message 3 so that Message 3 can be sent
`with the minimum uplink grant. It may also be desirable to
`define a single format for PDCP. RLC and MAC for Message
`3. The total number of bits for Message 3 may be reduced as
`described beiow.
`
`For RRC, one ofa limited number of RRC message
`[0046]
`sizes may be supported for an RRC.‘ message sent on the
`(_‘C(_‘.I-I for Message 3. In one design, RRC message sires of
`48 bits and 96 bits may be supported. A 48-bit RRC message
`or a 96-bit RRC message may be sent in Message 3 depending
`on the uplink grant size.
`[0047]
`For RRC connection re—establishnient. Message 3
`may comprise an RRC Connection Re-establishment
`Request message or some other RRC message. In one design.
`the number of bits for the RRC message for RRC connection
`re-establishment may be reduced by omitting the 32-bit
`IVLAC‘-I as well as the frequency information. MAC-I may be
`used to verify a U E sending the RRC message and may act as
`a trigger for switching an S1 data path tor the UE on the
`network side. The omission of MAC—I from the RRC Con-
`
`nection Re—estabIishn1enI Request message may delay the
`path switching until an RRC‘ (Tonnection Reconfiguration
`Complete message (which may be integrity protected) is sent
`by the UE in a11 RRC cor1nectio11 re-establishment procedure.
`In another design, a short MAC-I of a smaller size may be
`generated and sent in the RRC mess age. For example. a 16- bit
`short MAC-I may be generated based on 16 most significant
`bits (MSBS) of a fi.Ill MAC—I and may be sent in the RRC
`message. In yet another design. a short MAC-I may have a
`variable size. which may be dependent on the uplink grant
`
`14
`
`14
`
`

`
`US 2009f0l632l1 A1
`
`Jun. 25, 2009
`
`size. For all designs. a 48-bit RRC message may be sent for
`RRC connection re-establishment and may be filled with a
`suificient number of padding bits. if needed.
`[0048]
`For attachment. Message 3 may comprise an RRC
`Connection Request message or some other RRC message. In
`one design. the size of an initial U E ID (eg. an IMSI) may be
`redttced. if needed, so tltat the RRC message can fit one of the
`supported RRC message sizes. An IMSI Inay be composed of
`a 3-digit mobile country code (MCC). a 2-digit or 3-digit
`mobile network code (MNCT), and a mobile station identifi-
`cation nttrnber (MSIN) that is unique within a network. An
`IMSI 111ay have a length of between 6 and 21 decimal digits.
`and 15 digits may be the typical length of the IMSI in LTE.
`[0049]
`In one design. the IMSI may be conveyed using
`binary representation (instead ofhexadec imal representation]
`in order to increase the amount of IMSI information that can
`
`be sent in an RRC message ofa given si'/.e.IIiael1 decimal digit
`of the IMSI may be conveyed with one 4-bit hexadecimal
`(e.g.. as in UTRAN). A 2] -digit IMSI may be conveyed with
`34 bits using hexadecimal representation or 70 bits using
`binary representation.
`[0050]
`In one design, a predetermined number of least sig-
`nificant bits (LSBS) ofthe IMSI may be sent in a fixed size
`field of an RC message. For example, a partial UE ID may
`be formed with 44 I.Sl3s ofthe IMSI and may be sent in a
`48-bit RRC message. Although the [MSI is globally unique
`for each UE. using a portion of the IMSI introduces a {very
`low} probability of collisions due to multiple UEs having
`globally unique IMSIs but potentially the satne partial IMSI.
`Since the MCC and MNC are typically the same for a given
`network. using the LSBS of the IMSI may reduce the likeli-
`hood ofcollision. It may not be feasible to detect and resolve
`collision of partial IMSIS at the radio level. Instead. a failure
`of an upper layer procedure (e.g.. an authentication chal-
`lenge) may be used to detect and resolve collision of partial
`IMSls.
`
`[0051] A partial [MS] may be composed of a portion ofan
`IMSI and may be conveyed using binary representation. For
`example. 13 ieast significant digits of the IMS] may be con-
`veyed with 44 hits using binary representation versus 52 bits
`using hexadecimal representation. A 44-bit partial IMSI may
`be sent in a 48-bit RRC message. Ifthe IMSI is shorter than 13
`digits. then the RRC message may be padded with zeros. The
`RRC.‘ message may include a 1-bit Format field that may be set
`to ‘0‘ to indicate a 43-bit partial IMSI or to ‘ 1 ‘to indicate a full
`IMSI.
`
`I11 anotherdesign. a variable amount ofUE ID infor-
`[0052]
`mation may he sent in the RRC message depending on the
`uplink grant size. A UE may be allocated the minimum uplink
`grant in rare bad situation and may send the tniniinum Itumber
`of bits for tlte IMSI. 'lhc U13 may be allocated more than the
`minirnunt uplink grant in most situations and may be able to
`send more bits ofthe IMSI in the RRC message when allowed
`by the larger uplink grant. In one design. the 1-bit Format field
`of the RRC message may be set to ‘ 1 ‘ to indicate a variable
`size RRC message or to ‘O’ to indicate a predetermined sized
`RRC message. The variable size RRC message may include
`an IMSI length field and an IMSI field. The IMSI length field
`may indicate the length of the IMSI field. which may carry a
`partial or full IMSI. MAC may receive an uplink grant for the
`UE and may convey the uplink grant size to RRC. RRC may
`tlten include as many IMSI digits or hits as possible in the
`RRC message.
`
`[0053] Table 3 lists diflerent types of information that may
`be sent on the CCCH for Message 3 for difiertent random
`access types. in accordance with one design. Table 3 assumes
`a minimunt uplink grant of 80 bits. Information for RRC may
`be reduced as described above. I-‘or RRC connection re-es-
`tablishmcnt. an RRC Connection Re-establishment Request
`message may include an old cell ID (9 bits), an old C-RNTI
`(16 hits). a short MAC-I. and padding andfor reserved bits for
`the mininmm uplink grant. The RRC message may include a
`16-bit IVIAC-I and 7 padding hits (as shown in Table 3). or a
`23-bit MAC-I and no padding bits, or some other CUl11l'Ji}’1£iIiOl’l
`ofMA(.'-I bits and padding bits. The RRC message may also
`include a larger MAC-I (e.g.. a 32-bit full MAC-I normally
`generated by PDCP for messages 011 the control plane) for a
`larger uplink grant. The short MAC-l may have a variable size
`determined based on the upiink grant for the UE. For attach-
`ment. an RRC Connection Request message may include (i)
`a partial 44-bit IMSI when the Format field is set to ‘O’ or (ii)
`an IMSI ofa variable length (e.g.. in multiple ol‘8 bits and up
`to a maximum of 96 bits) when the Format field is set to *1’.
`Information for PDC P and MAC may be reduced as described
`below.
`
`TABLE 3
`
`Revised bit counts for first scheduled Lransrniasion (Message 3}
`
`Rruititittt .-l\CC{:SS '1'y'}3g
`
`Layer
`RRC
`
`PDCP
`RLC‘
`MAC
`PIIY
`RRC‘ bits
`
`Other bits
`‘1‘otsJ bits
`
`RRC Connection
`Re-estrtbl ishmenl
`Old cell ID: 9 bits,
`Old C—RNTI: 16 bits,
`i\-"l.-’\(.‘~I: [6 bits
`Pzidriing: "I bits
`
`48
`
`24
`30
`
`Subseqttcnt
`Access
`Attachment
`Forrnat: 1 bit
`i"orruaI: 1 bit
`Irtitittl UE identity Initial UE identity
`{IMSI}: 44 bits
`(S-'l‘M.‘iI]: 4111 hits
`when lionn.-it bit
`listablisitnterit
`set to '0'
`cause: 3 hits
`l'.$L’1i‘JllSlIn‘It:J1l
`Patiditig: 4 bits
`cause: 3 bits
`PDCP transparent operation: 0 bits
`R_LC—TM: (I bit
`M.-\C header: 8 bits
`Physical layer CRC: 24 bits
`48
`
`48
`
`‘_?_4_
`80
`
`24
`Stu
`
`I11 another design not shown in Table 3. a random ID
`[0054]
`may be sent instead ol‘ :1 partial IMSI for attachment. The
`random ID may be a pseudo-random value selected by the
`UE, a hash value generated by hashing the IMSI or some other
`UE ID. or a value obtained in other manners. The random ID
`may have a fixed size (e.g.. 40 bits to match the size of the
`S-TMSI) or a variable size (e.g., dependent the uplinit grant
`size).
`In another design, the Formal field may indicate one
`[0055]
`ofmttltiple types ofUE ID being sent in an RRC‘ message. For
`example, the Format field may be set (i) to ‘O’ to indicate an
`S-TMSI being sent
`in the RRC message for subsequent
`access or (ii) to ‘I ’ to indicate a partial [MS] or a random I1)
`being sent in the RRC message for attachment.
`[0056]
`FIG. 5 shows a design of processing to generate
`Message 3 in [.,7l‘E. Message 3 may include all of the infor-
`mation for RRC shown in Table 3. In one design. Message 3
`may have a fixed length (e.g._. 80 bits) for all random access
`types. In another design, Message 3 may have different
`lengths for different random access types. dilierent uplink
`grant sizes. etc.
`
`15
`
`15
`
`

`
`US 2009f0l632l1 A1
`
`Jun. 25, 2009
`
`In one design. a transparent mode ofoperation may
`[0057]
`be defined for PDCP to support transfer of an RRC message
`on the CC CI-I for random access. In the transparent mode.
`PIJCP may neither perloml integrity protection nor cipherittg
`for the CCCI I carrying the RRC message. and a PDCI’ header
`may be omitted in the transfer of the CCCH. PDCP may be
`informed to operate in the transparent mode and may then
`perform no operation for the CCCH. PIJCP may receive the
`RRC message as a