(12) United States Patent
`Beckmann et al.
`
`(10) Patent No.:
`(45) Date of Patent:
`
`US 7,333,443 B2
`Feb. 19, 2008
`
`USOO7333443B2
`
`METHOD FORTRANSMITTING DATA
`PACKETS VA ARADIO INTERFACE OF A
`MOBILE RADIO SYSTEM
`
`(56)
`
`References Cited
`
`U.S. PATENT DOCUMENTS
`
`(54)
`
`(75)
`
`Inventors: Mark Beckmann, Braunschweig (DE);
`Michael Eckert, Braunschweig (DE);
`Udo Hallmann, Lahstedt (DE); Martin
`Hans, Hildesheim (DE); Andreas Otte,
`Celle (DE)
`
`(73)
`
`Assignee:
`
`(*)
`
`Notice:
`
`Siemens Aktiengesellschaft, Munich
`(DE)
`Subject to any disclaimer, the term of this
`patent is extended or adjusted under 35
`U.S.C. 154(b) by 884 days.
`
`(21)
`(22)
`(86)
`
`Appl. No.:
`
`10/398,672
`
`PCT Fed:
`
`Oct. 5, 2001
`
`PCT No.:
`
`PCT/DEO1AO3843
`
`S 371 (c)(1),
`(2), (4) Date:
`
`Aug. 25, 2003
`
`(87)
`
`PCT Pub. No.: WOO2/O96.030
`
`PCT Pub. Date: Nov. 28, 2002
`
`(65)
`
`Prior Publication Data
`US 2004/0O28O78 A1
`Feb. 12, 2004
`
`Foreign Application Priority Data
`(30)
`Oct. 9, 2000
`(DE) ................................ 100 49 797
`
`(51)
`
`(52)
`(58)
`
`Int. C.
`(2006.01)
`H04L 2/28
`U.S. Cl. ....................... 370/254; 370/338; 370/469
`Field of Classification Search ................ 370/338,
`370/254, 255, 469
`See application file for complete search history.
`
`6,850,540 B1* 2/2005 Peisa et al. ................. 370/468
`2003/0039236 A1* 2/2003 Uga ........................... 370,345
`2006/0140158 A1* 6/2006 Terry .......................... 370,335
`
`FOREIGN PATENT DOCUMENTS
`
`WO
`WO
`
`WO 99,52307
`WOOO,2876O
`
`10, 1999
`5, 2000
`
`OTHER PUBLICATIONS
`3' Generation Partnership Project: Technical Specification Group
`Radio Access Network: Radio Interface Protocol Architecture (3G
`TS 25.301 Version 3.3.0) Dec. 1999 XP002164238 p. 11, 14 and 27.
`* cited by examiner
`Primary Examiner Ricky Q. Ngo
`Assistant Examiner Pao Sinkantarakorn
`(74) Attorney, Agent, or Firm—Bell, Boyd & Lloyd LLP
`
`(57)
`
`ABSTRACT
`
`Data packets are transmitted via a radio interface, wherein a
`control unit of a first entity transmits information via its
`logical channels serving as service access points in the form
`of a configuration message, with the configuration message
`including information about which logical channels are to be
`mapped onto which transport channels serving as service
`access points for a bit transmission layer. A set of transport
`formats are predetermined for each of the transport channels
`along with a set of permitted combinations of transport
`formats for all transport channels. Each transport format
`includes a set of parameters determining transmission char
`acteristics of the transport channel configured with the
`corresponding transport format. The first entity selects a
`transport format for each of the transport channels, such that
`the resulting combination of transport formats corresponds
`to one of the transport combinations defined as permissible
`and wherein the first entity transmits the data to initiate the
`transmission of the data packets.
`
`7 Claims, 20 Drawing Sheets
`
`UMTSlayer 23 Protocol Architecture
`C-planesignalling
`Uplane information
`
`
`
`Radio Bearer
`
`logical
`Channels
`2MAC
`Transport
`Channels
`
`Petitioner's Exhibit 1006
`Page 1 of 27
`
`

`

`U.S. Patent
`
`Feb. 19, 2008
`
`Sheet 1 of 20
`
`US 7,333,443 B2
`
`
`
`Oluoo
`
`Petitioner's Exhibit 1006
`Page 2 of 27
`
`

`

`U.S. Patent
`
`Feb.19,2008
`
`Sheet2 of20
`
`US 7,333,443 B2
`
`
`
`m0<wmms_mam—mmum—4mm29E
`
`
`
`
`
`
`
`Efozn:wmmmmms.cow—EsmzcouomEmom23mN0—”—
`
`
`
`
`
`w.2"—wow
`
`
`
`
`
`m.9".8w3m.my:955%.:osmccoE.mm
`
`86%82Eggs:EIgm3%.22:.m5..........
`
`.I'IIIIvIIIu
`
`I//
`
`.38he=o=m§o§mm.3mm8». 3:gm8m<m>35.8“8%:gag8..
`coumEEEmad
`
`3422:5mm.8“8%:9:3.é833.859».
`
`
`
`EamEpSEmEIa“3322:.$53%
`_‘.3mm9£5mam
`
`
`
`mmzogi25$832
`
`
`mw_:o._._.wm=mmmm=zomm.m:
`
`meamwm\2826mm
`
`£5:E
`
`259.3%:mmE28.mm£582
`
`Petitioner's Exhibit 1006
`
`Page 3 of 27
`
`Petitioner's Exhibit 1006
`Page 3 of 27
`
`
`
`
`

`

`U.S. Patent
`
`R
`
`3m7m
`
`2B3M,
`
`__m5“33%a8:35210:..5umsuccoomm.6822\1/m.
`omu:,2so:.5mrIlIIIIIJIIIIIIIIILM58:20teams“:359E002
`
`
`mE.55355%games:6:
`
`
`
`
`:23Ewt23m:.255:32“:m0—”—
`
`m.9".3w
`
`Petitioner's Exhibit 1006
`
`Page 4 of 27
`
`Petitioner's Exhibit 1006
`Page 4 of 27
`
`

`

`U.S. Patent
`
`F
`
`m
`
`S
`
`4
`
`2B344n}3m7
`
`
`
`
`
`H,551.8SEC93%:Nfimm.253095%:Ema3223093%:mSEC93%:mm
`
`
`
`
`
`
`
`
`
`EEOEV8:835%:Emma2.8mv0....—
`
`
`
`mH.2game5%..8m
`
`
`
`
`
`mmho22509.3%.:=m.239%;.
`
`
`
`
`
`
`
`
`
`:09:.25coma0%.2Iowa.25:SE0:I-II.III.m$2E:
`
`
`
`
`
`mmho22:20_mo_mo._.5=m.3“mmaom
`
`
`
`
`
`mmmho22:20_8_mo._.5__m.258mm
`
`\lllllllxrll‘lllllulj
`
`.258...25:..E83so:.5”H
`
`Petitioner's Exhibit 1006
`
`Page 5 of 27
`
`Petitioner's Exhibit 1006
`Page 5 of 27
`
`
`
`
`

`

`U.S. Patent
`U.S. Patent
`
`F
`
`US 7,333,443 B2
`2B3M,m
`
`
`
`
`
`
`
`3&5:,Ema320:8Eggmmm32.2509.3%:=m.2“.3ngmgm3:250Egglgmmszgao
`
`32:52:2:85.5283:SEQ9.5%:m0—"—
`
`SEC93%:mm
`
`
`
`
`
`
`
`E3&589:Sm
`
`0\IllllllxrlllllljmH“8.x2.58...255mg0%.259:“H
`
`
`
`
`
`
`
`mmho29.526_mo_mo._.5=m82331
`
`
`
`
`
`7,mmho28:20_mo_mo._._n_:5how.53%m\ll||||lulll>lllllnll.lllJ
`
`Petitioner's Exhibit 1006
`
`Page 6 of 27
`
`Petitioner's Exhibit 1006
`Page 6 of 27
`
`
`
`

`

`U.S. Patent
`
`
`
`
`
`US 7,333,443 B2
`
`
`
`(ZO
`
`‘E;-----—–^???????????????????????????????????????????????????????????????????????????????\
`ËTZ?TTOJEZIS-5???JIJOITTI I
`
`Petitioner's Exhibit 1006
`Page 7 of 27
`
`

`

`U.S. Patent
`
`Feb. 19, 2008
`
`Sheet 7 of 20
`
`US 7,333,443 B2
`
`
`
`
`
`
`
`?#-IL JOJ SEIL JO "IN
`
`
`
`Petitioner's Exhibit 1006
`Page 8 of 27
`
`

`

`U.S. Patent
`U.S. Patent
`
`Feb. 19, 2008
`Feb.19,2008
`
`Sheet 8 of 20
`Sheet8 0f20
`
`US 7,333,443 B2
`US 7,333,443 B2
`
`
`
`9%g
`
`m.0.E25.6”;mm._.”6.2
`
`,
`
`Efiwfimm:9%:6mg
`
`ENE“mmESEtoamcmt
`
`Assn—:352:BmEEooo$
`
`ww...—
`
`
`
`muz. at3562gramH
`
`Petitioner‘s Exhibit 1006
`
`Page 9 of 27
`
`Petitioner's Exhibit 1006
`Page 9 of 27
`
`
`

`

`U.S. Patent
`
`Feb.19,2008
`
`Sheet9 0f20
`
`US 7,333,443 B2
`
`
`
`85:58:83.55%E:25.:85??me:osmées
`
`
`8:295.9%:
`
`
`
`:086323:.8:8mm356:53:5:822:58::08:2:8836255<:2.
`horn:OE3:qumm”<m0—...—
`
`
`
`9:279:
`
`
`
`
`
` 552mm3:63:55:08:8Sang::
`
`
`
`
`
`
`
`
`
`383.9:Emmoon.9%:8563
`:8:8:9?6:52:H.062m_m::m:o
`
`
`8m:8=95_¢::m:o625.20.28:855
`
`“we2.:“:58:855.25.$225-S.>o93:2:6::«5.852San
`
`.852oz:9::o55%5E33:8,mac:3%Em
`
`.m_m::m:o
`
`
`
`
`
`2:8653865mm._<n_
`
`.50:3:8.5:
`
`mg:m:S:
`
`:8:Ea:8:as:Eg:8:
`Iomzfomo
`.12:an
`ufiemssfi
`
`:8:Em_:8:
`:8:Eg:8:
`
`5:28.:
`6:520
`
`8.3.?
`$52
`
`GEE
`
`:28:2:983::Ex:53me85BM28:2:
`533E233o:.53Eagamxgaaegsazn
`
`
`
`
`
`8b.052:raga:xsaak
`
`
`
`>552_m::m:o:o%:m:._..SAA
`
`
`
`
`
`Petitioner‘s Exhibit 1006
`
`Page 10 of 27
`
`Petitioner's Exhibit 1006
`Page 10 of 27
`
`
`
`
`
`
`
`
`
`
`
`

`

`U.S. Patent
`
`Feb.19,2008
`
`Sheet10 0f20
`
`US 7,333,443 B2
`
`
`285%.862smfiméflc988m.
`5220toamcgmcoo<_>_38383235
`
`
`.852BywmmE93:Mam:
`_m:85?3:0:2mm
`
`é3:553:
`
`rouge...
`.2520
`
`9.3.2
`
`£52
`
`$35382;
`fioao.ma358,,u852who,ms:38o.325?
`
`finfi28m73%Emma22:52:50.2,$03me22:20
`
`
`7
`.few7
`29¢zooas
`
`
`
`2.5otoawzgxEEBoRA
`
`mmGE
`
`Petitioner's Exhibit 1006
`
`Page 11 of 27
`
`Petitioner's Exhibit 1006
`Page 11 of 27
`
`

`

`U.S. Patent
`
`Feb. 19, 2008
`
`Sheet 11 of 20
`
`US 7,333,443 B2
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`HOSTIHOG-Tn
`
`_HOSCHOO-TC)
`
`Petitioner's Exhibit 1006
`Page 12 of 27
`
`

`

`U.S. Patent
`
`Feb.19,2008
`
`Sheet12 0f20
`
`US 7,333,443 B2
`
`
`
`
`
`323:“:amass”.tags:<3GE
`
`
`
`5553:8:55am
`
`Emmg1..
`
`III!a:5520Egg86:0
`
`gaszgcgotamcmfifiII!22.50:829:.2850?
`85$?9%:
`£22:32:520>:mEo_w.:o_fi::e:_
`
`
`doonEmv6E8».ragga:9.
`
`25:8oHEB5:29.:2283:8:oamctegSEE
`
`28%m5___o::m:oto%:m.=
`
`toawcm:2:355:Smemaa
`
`
`
`:5B8:32E:9:.
`
`run0.3Bm:w”?mg5.3859:8
`
`
`
`
`
`HES”.:o%:§QEmESR
`
`8:282.
`
`
`:83:Em$292QOV{cm3oto???
`
`weN2$535-oREESme:53:55AAA
`
`
`
`“9:5":53%;
`
`8%:58:5
`
`.5:ng
`
` oasismwk!5...:as:NAMI!9.8:535:03.53%
`
`8:58:85
`
`5.3.2
`
`6:8”.
`
`
`
`Petitioner's Exhibit 1006
`
`Page 13 of 27
`
`:ozmées
`
`Petitioner's Exhibit 1006
`Page 13 of 27
`
`
`
`
`
`
`
`

`

`U.S. Patent
`
`Feb. 19, 2008
`
`Sheet 13 of 20
`
`US 7,333,443 B2
`
`coeff
`
`Z6
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`Petitioner's Exhibit 1006
`Page 14 of 27
`
`

`

`U.S. Patent
`
`Feb. 19, 2008
`
`Sheet14 0f20
`
`US 7,333,443 B2
`
`
`
`coiEmmumowcmEom
`
`28%9:gmmama.Emube
`
`8m:8=93Eccmcu5052
`
`weas6585055map
`
`
`
`com:3=965220.852
`.39.3:8.2
`
`
`
`6E8E:@865mm._<n_
`
`_8_mo_939:B55%8E38:8323%new
`Emma28.5>550.3
`an28:20Nav.m_w=:m;u
`33%38m
`
`mm£5as388:28:a:8mBa.asgé:
`.35Exams82:8
`
`toamcmfi
`3:520
`
`m5.02
`3252
`
`:8on:a5m:as8”.a:08
`uofimszcw
`
`commEEE <30."—
`
`$9.28_¢>=mEo=<.:o_Em>:_2:BmEEouom25mcaamEmm
`
`
`
`coumxmamae8:8mm25ficcmzotoamcggamma5%.8Sagomsxmause<
`ion5ta.25BuquEoo
`
`Ba25.
`
`883%:
`
`528m
`
`2mmmevB_.
`
`chozéx:
`
`22:20
`.mu_mo._
`
`..5.>o
`
`3m
`
`geoEmEom
`
`2cm:
`
`mExmaasecommbeconga?
`
`
`_8:8
`
`
`
`3&9:355%$20.23%
`
`heme—us
`
`£03me2F
`0.25
`
`850E
`
`..S.>U
`
`IowEIUQ
`
`-.5.>o
`
`
`
`.838m3.53:..323?
`
`295.98
`
`
`
`2532202825:£332
`
`
`
`
`
`3:52.05553%sz.52
`
`Petitioner's Exhibit 1006
`
`Page 15 of 27
`
`Petitioner's Exhibit 1006
`Page 15 of 27
`
`
`

`

`U.S. Patent
`U.S. Patent
`
`Feb. 19, 2008
`Feb. 19, 2008
`
`Sheet 15 of 20
`Sheet15 0f20
`
`US 7,333,443 B2
`US 7,333,443 B2
`
`
`"c.326232:E38;“oz
`.32203032as.be
`
`.33on:8
`
`com:3E:E:3950"—
`
`tonmfit.2:$333..
`
`w":9:55E"z.
`
`
`
`225%.852€59.3595m:2555%;m2;
`
`
`
`$5.205%:thm:00.4.2386352:.
`
`28525Vmmm290%flow:a$92?3:25m.m;
`
`:33.38:20
`
`
`
`w.gfiizmmm.Hmm.
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`.NEggsl!!
`
`
`
`€...§%%I!95..352038.5
`
`onrum=uw=cu"FAA
`
`mZGE
`
`32:933052
`
`3.553....I!.4
`
`5.582%..LoEm3man$55memoN8
`
`53mw:Sm
`
`355otongs:E.5692
`
`2:.
`
`Petitioner's Exhibit 1006
`
`Page 16 of 27
`
`Petitioner's Exhibit 1006
`Page 16 of 27
`
`
`
`
`
`
`
`
`

`

`U.S. Patent
`
`Feb.19,2008
`
`Sheet16 0f20
`
`US 7,333,443 B2
`
`=IOD=
`
`28:3m_8
`
`.838a:m_m.as8:226m:gm:E
`
`
` =5?2=33w_=2535.20SnagEEO?m.t68$:Ho:w_m.2:$3226.2m_m:m:38RE.189.a.mEmfi
`
`:oawcg€253?m._
`
`=68:
`
`8:22am.g@...:.§5
`
`
`w_:850.?m.E38:.SmEgon
`
`
`
`mos—.6.:.8388cm”m:058:226ms.m_m:£5E852=850.?m:E.82:SmEa:mo_oxo_..__
`
`.882.«o:am:9:$32050m22m:£5#585
`
`mm:M—F:
`
`.—
`
`
`$5$226.2035gm:55.Nm_
`29.5%$6523mx53:555:52..
`
`.882“o:m_m:
`:859.3%.:
`
`toamcmc.
`6:35
`
`$6.2:
`2:32
`
`IowQIOQ .53£5255205&5:
`
`.52
`
`030E
`
`
`
`33%;6:58$0532
`
`SEES
`
`w_o::m:o_mo_mo..o..m-.5
`
`oE0.3.5
`
`8504min—
`
`IowEIOQJD
`
`Iomofoofio
`
`Petitioner's Exhibit 1006
`
`Page 17 of 27
`
`Petitioner's Exhibit 1006
`Page 17 of 27
`
`
`
`
`
`
`
`
`

`

`U.S. Patent
`U.S. Patent
`
`Feb. 19, 2008
`Feb. 19, 2008
`
`Sheet 17 of 20
`Sheet17 0f20
`
`US 7,333,443 B2
`US 7,333,443 B2
`
`
`
`couazommv85553
`
`V5gm“:m:5:,853:8
`m_“as$5.20toamcg2:.
`
`
`
`mom33
`
`£5Eoagetawny...2283:8:ofiEoEfigs
`
`
`
`
`
`tonmcmb225:5$3598
`
`9:.6823mgEL.9;
`
`
`
`
`
`.8cmEm22:3toamcg22.8%ms.32:anraga:
`
`8822m$2996%v.7we
`32£855
`
`2953:.
`3.23
`
`352“ED
`
`Petitioner's Exhibit 1006
`
`Page 18 of 27
`
`
`
`
`
`Eon5ta3:.£3,uoEQEoo89.28
`
`
`
`
`
`5:52:3...30.5288“mmHEB”.roams:
`
`
`
`<30E
`
`8:996.
`
`
`
`Eu8?,asegcwEwmconga:
`
`mEm:
`
`
`
`
`
`BEE;toqwcmb2525.2
`
`scumEBE
`
`Petitioner's Exhibit 1006
`Page 18 of 27
`
`
`

`

`U.S. Patent
`U.S. Patent
`
`Feb. 19, 2008
`Feb.19,2008
`
`Sheet 18 of 20
`Sheet18 0f20
`
`US 7,333,443 B2
`US 7,333,443 B2
`
`
`
`
`
`
`25mm:>9:“2:23:20
`.353as“$3055
`
`
`
`fiasco".tonmcmfi
`
`
`326:“m_35.28.853
`
`
`
`ago28:.“came“.“oz
`
`o_§m-_Emw
`
`toamcmc.
`Huston
`
`gunfigs
`
`:.m.m.2
`
`m39E
`
`cowmcmaxm
`
`
`
`o_§m-_Emw53:2505:.cofigemcm:m:5386:.m_can?E252%.m8305w_m:95
`
`
`
`
`
`8828:m_t35:26SEES:fiEom5.29...
`
`E282? 8%:8
`
`Petitioner's Exhibit 1006
`
`Page 19 of 27
`
`
`
`
`
`
`
`
`
`
`
`
`
`um:mm:2somflkn
`
`am:3somSAAAA
`
`
`
`
`
`5E5;togmcmfio_§m-_EomAA
`
`833.85
`
`Petitioner's Exhibit 1006
`Page 19 of 27
`
`

`

`U.S. Patent
`
`Feb. 19, 2008
`
`Sheet 19 of 20
`
`US 7,333,443 B2
`
`HO
`
`#ff | rw |
`
`?UUBU
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`Petitioner's Exhibit 1006
`Page 20 of 27
`
`

`

`U.S. Patent
`U.S. Patent
`
`Feb. 19, 2008
`Feb.19,2008
`
`Sheet 20 of 20
`Sheet20 0f20
`
`US 7,333,443 B2
`US 7,333,443 B2
`
`
`
`cowmcmaxm
`
`38652wmm:E2Em§u”a38.05B:e_£5.
`
`u_Ew-_Emm5$29505:.83583m_s,
`
`UEEEmm
`
`toamcmc.
`3E8”.
`
`commas:
`
`2.3.9
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`.838“o:2g35:258395853.58toacmc.
`
`o_§m._EmwAA cm?0."—
`
`
`
`«9E8toawcmfi
`
`8:355.
`
`Petitioner's Exhibit 1006
`
`Page 21 of 27
`
`Petitioner's Exhibit 1006
`Page 21 of 27
`
`

`

`US 7,333,443 B2
`
`1.
`METHOD FORTRANSMITTING DATA
`PACKETS VIA ARADIO INTERFACE OF A
`MOBILE RADIO SYSTEM
`
`BACKGROUND OF THE INVENTION
`
`2
`As the data streams of such an RB are either continuous
`or in packets of any length, it is the task of the RLC protocol
`to split (or combine) the data stream into packets, which are
`of an optimal length for the radio interface. Therefore,
`RLC-SDUs are broken down into RLC-PDUs or a number
`of RCL-SDUs are merged into RLC-PDUs. The RLC layer
`also stores the data at an RB in an RLC buffer until it can be
`transported from layers under RLC via the radio interface.
`The RLC layer has other tasks (in particular, that of error
`correction), which are not relevant here however 5. The
`RLC layer sends the RLC-PDUs resulting from the split
`(merger) to the MAC layer for further transmission. The
`RLC layer is modeled so that there is an independent RLC
`entity for each Radio Bearer.
`The service access points, at which the MAC layer
`provides its services, are referred to as logical channels.
`There is precisely one RLC entity per Radio Bearer and
`either one or two logical channels per direction (UL/DL).
`Logical channels differ with regard to the nature of the data
`which is transmitted on them. A distinction is therefore made
`between logical channels, on which UE-specific useful data,
`like the above-mentioned voice data streams (Dedicated
`Traffic Channel, DTCH), UE-specific control data (Dedi
`cated Control Channel, DCCH) or general control data
`(Common Control Channel, CCCH) is transmitted. A num
`ber of DTCHs also can be differentiated by the QoS con
`figured for the corresponding RB.
`It is not of primary importance for the transmission of data
`via the radio interface what is transmitted but how the data
`is transmitted. Therefore, the physical layer, which contains
`the data coding, the modulation, the high frequency tech
`nology and the antenna, provides service access points for
`the MAC layer, which are characterized by how the data is
`transmitted. These are known as transport channels. A dis
`tinction is no longer made on the transport channels between
`useful and control data, a distinction is made, for example,
`between UE-specific channels (Dedicated Channel, DCH),
`channels with random access (Random Access Channel,
`RACH) or channels, the use of which is shared by a number
`of UEs (Uplink or Downlink Shared Channel, USCH or
`DSCH).
`It is the task of the MAC layer in the sender to map the
`data at a logical channel above the MAC layer onto the
`transport channels of the physical layer or to distribute data
`received in the receiver on transport channels to logical
`channels. Each transport channel is preconfigured for this
`purpose with a set of fixed parameters for data transmission.
`The MAC layer can search in a further set of variable
`parameters for the most favorable for the current transmis
`sion in each instance and can, in this way, influence data
`transmission dynamically. A valid setting of all parameters
`for a transport channel is then referred to as the Transport
`Format (TF). The quantity of all possible settings for a
`transport channel is referred to as the Transport Format Set
`(TFS). Only the variable (dynamic) parameters of the TF
`vary within a TFS. Only one transport format is set for each
`transport channel at one specific time. The set of transport
`formats set at one specific time for all available transport
`channels is referred to as the Transport Set Combination
`(TFC). The transport formats valid for each transport chan
`nels result in a large number of possible combinations for all
`transport channel and in theory each of these combinations
`could result in a TFC. In practice, the number of combina
`tions of transport formats actually permitted is restricted.
`The set of all permitted TFCs is referred to as the Transport
`Format Combination Set (TFCS).
`
`10
`
`15
`
`General
`FIG. 1 shows the UMTS protocol architecture of layer 2
`and lower layer 3 (for the layer model, see 1), which
`contains the protocols of the UMTS radio interface. This
`architecture exists both in the mobile device (User Equip
`ment, UE) and also in a node of the mobile communication
`network (Radio Network Controller, RNC); in other words,
`each of the protocols exists once in the UE and once in the
`RNC.
`The same protocols exchange Protocol Data Units
`(PDUs), as they use the services of the protocol layers below
`them for the transport of PDUs. Every protocol layer pro
`vides the layer above it with its services at what are known
`as service access points. To understand the architecture
`better, these service access points are given commonly used
`and unique names; e.g., logical channels, transport channels,
`Radio Bearer. For data transfer, protocols pick up service
`data units (SDUs) at their service access points and transmit
`PDUs generated from these to the layer below them, so
`PDUs from upper layers are identical to the SDUs of the
`layer below.
`The protocol layers shown in FIG. 1 are
`the Radio Resource Control (RRC) layer
`the Packet Data Convergence Protocol (PDCP) layer
`the Broadcast/Multicast Control (BMC) layer
`the Radio Link Control (RLC) layer
`the Medium Access Control SAC) layer
`and the physical layer (PHY).
`As the PDCP and BMC layers have no specific signifi
`cance for this invention disclosure, they are not described in
`any more detail here. The functions of RRC, RLC and MAC
`are described briefly and generally below. There follows a
`40
`more precise description of those functions which should be
`improved or modified via the present invention.
`
`25
`
`30
`
`35
`
`MODE OF OPERATION OF THE PROTOCOLS
`
`Data from different applications can be generated in the
`UMTS mobile device (UE). For voice connections, for
`example, a Voice coder generates one or more voice data
`streams oran HTML browser generates irregular packet data
`streams. This data is first modified, if required, by higher
`layer protocols and prepared for data transfer in different
`networks (e.g. TCP 3 and IP 4). For transport via the
`UMTS radio interface this data has to be optimized in the
`various layer 2 protocols (PDCP RLC and MAC). The
`service access point, at which non-UMTS-specific protocols
`can use the transmission service of the UMTS radio inter
`face, is called Radio Bearer (RB). RBs are therefore Sup
`plied above layer 2, depending on the protocols used above
`PDCP, BMC or RLC, and transmit data transparently from
`the UE via the UMTS radio interface to the RNC and
`vice-versa. When setting up such an RB, a predetermined
`transmission service quality (Quality of Service, QoS) is
`specified for this transmission and is characterized, for
`example, by a predetermined guaranteed data rate or a
`maximum transmission delay. RBs are essentially bi-direc
`tional; therefore, an RB can transmit data in two directions
`(in the Uplink, UL and in the Downlink, DL).
`
`45
`
`50
`
`55
`
`60
`
`65
`
`Petitioner's Exhibit 1006
`Page 22 of 27
`
`

`

`3
`The RRC protocol is responsible for setting up, removing
`and reconfiguring transport channels and RBS and for nego
`tiating all parameters of the layer 2 protocols. This protocol
`also exists in the UE and the RNC and it uses the transmis
`sion services provided by the RLC layer, in other words the
`logical channels, to send RRC messages. The different layer
`2 protocols are then configured with the transmission param
`eters negotiated between the RRC protocols. For example, a
`TFS is negotiated between the RRC protocols for each
`transport channel when setting up or reconfiguring and the
`TFCS valid for all channels is transmitted. Both are then
`configured in the MAC layer so that MAC can map the
`logical channels onto the transport channels.
`As described above, a transport format includes static
`parameters, which cannot be influenced by the MAC layer
`but are negotiated only by RRC and dynamic parameters,
`from which a set of different settings is negotiated by RRC
`and which can be influenced by the MAC layer. The static
`parameters include:
`The length of the transmission interval (Transmission
`Time Interval, TTI), which is the time interval for
`which the physical layer processes data contiguously.
`This may be 10, 20, 40 or 80 milliseconds long.
`The coding system for error protection.
`The length of redundancy information for error protection
`(CRC, Cyclic Redundancy Check).
`The dynamic parameters are:
`RLC size. This parameter indicates the RLC-PDU size.
`As the MAC layer does not generate MAC-PDUs or
`segment or collate the RLC-PDUs received from RLC,
`30
`a MAC-PDU always corresponds to just one RLC
`PDU. Depending on whether or not the MAC layer
`prefixes a MAC-PDU with a control data header (MAC
`header), a MAC-PDU is exactly the size of or the
`length of a MAC header bigger than the RLC-PDU.
`These parameters are used to set both the size of the
`MAC-PDU and the size of the RLC-PDU. The data
`block transmitted on the transport channel to the physi
`cal layer, the MAC-PDU, is also referred to as the
`transport block.
`Number of transport blocks. This parameter determines
`the number of MAC-PDUs, which may be transmitted
`during a TTI to the physical layer for simultaneous
`processing and transmission via the radio interface.
`In some cases the TTI also can be a dynamic parameter.
`As can be seen, the current data rate of the transport
`channel, which can be set by the MAC layer dynamically by
`selecting the different transport formats, in other words by
`varying the TTI, the RLC size and the Number of Transport
`Blocks, is determined by the parameters TTI, RLC size and
`Number of Transport Blocks.
`As well as the dynamic selection of a TFC for every
`transmission interval, the MAC layer has the task of dis
`tributing the data coming in on the various RBs to the
`transport channels taking into account the QoS set for the
`RB. In this process, what is known as the RB Mapping Info
`is negotiated by the RRC layer, Such as during setting up and
`reconfiguration of RBS, and this indicates which logical
`channels are to be mapped onto which transport channels,
`with the possibility of assigning more than one logical
`channel to each transport channel.
`The sending MAC layer therefore searches for a transport
`format for each transmission interval and for each transport
`channel (therefore, one TFC in total) and determines the
`logical channels from which data can be transmitted in the
`TTI in question. The MAC layer then informs the corre
`sponding RLC units of the RLC-PDU size associated with
`
`4
`the relevant TF and the number of expected RLC-PDUs.
`RLC then segments the data from the RLC buffer according
`to the RLC-PDU size and transmits the corresponding
`number of RCL-PDUs on the corresponding logical channel
`to the MAC layer. This adds a Mac header to the data, if
`required, and transmits all the MAC-PDUs for one transport
`channel simultaneously to the physical layer, which then
`deals with data transport via the UMTS radio interface
`within a TTI.
`
`PRIOR ART
`
`The present invention relates to the configuration of data
`channels for data transmission via a radio interface of a
`mobile radio system, in particular UMTS, from a mobile
`station (UE) to a node in the mobile radio system, in
`particular a Radio Network Controller (RNC).
`In the description of the data transmission below, a
`distinction is made where necessary between a sender and a
`receiver unit, with both UE and RNC having the capacity to
`undertake both the role of sender and the role of receiver.
`During the exchange of configuration data there is essen
`tially one configuring unit, which determines the configu
`ration parameters and which serves as the sender unit for
`configuration messages, and one configured unit, which
`accepts the configuration parameters and serves as the
`receiver unit for configuration messages. In UMTS, the
`RNC is essentially the configuring unit and the UE is the
`configured unit. The receipt of configuration messages with
`configuration parameters can be acknowledged by the return
`of receipt confirmation messages from the UE to the RNC,
`with these messages containing values which are different
`from the parameters received in the UE if necessary.
`Useful data exists in the sender unit in the form of
`continuous data streams or packet data streams, which are
`generated by different applications or received at corre
`sponding interfaces from a different unit and, where neces
`sary, handled by different protocols; in particular, being
`segmented or merged into bigger packets. These data
`streams are transmitted at service access points, known as
`the logical channels, to the MAC protocol specified in 6.
`which provides the service of transmitting the data streams
`via the UMTS radio interface.
`The physical layer described in 8, which contains
`among others the functionalities of antenna, high frequency
`technology, modulation and data coding, provides the Ser
`Vice of transmitting data packets within transmission inter
`vals at its service access points, known as transport chan
`nels. The size and number of the data packets, which are
`transmitted within a transmission interval, here create the
`length of the transmission interval and the coding used on
`the data creates a set of parameters, which characterize each
`transport channel at one time and is hereafter referred to as
`the Transport Format (TF).
`It is the task of the MAC layer to distribute the data
`packets at the logical channels to the available transport
`channels and in this process to select an appropriate trans
`port format for each transmission interval and for each
`transport channel from a predetermined quantity of transport
`formats, known as the Transport Format Set (TFS). The
`nature of the distribution of the different logical channels to
`the available transport channels is restricted here by a table,
`known as the RB mapping info, which clearly assigns to
`each logical channel those transport channels which can be
`used for a transmission. See, for example, FIGS. 9A, B and
`C.
`
`US 7,333,443 B2
`
`10
`
`15
`
`25
`
`35
`
`40
`
`45
`
`50
`
`55
`
`60
`
`65
`
`Petitioner's Exhibit 1006
`Page 23 of 27
`
`

`

`5
`The setting up, reconfiguration and removal of logical
`channels and transport channels and the negotiation of the
`RB mapping info required by the MAC layer and the TFSs
`of the individual transport channels are carried out by the
`RRC protocol specified in 7. For this purpose, the RRC
`protocol in the RNC decides for each transport channel on
`the selection of the parameters for each individual TF and
`the number of TFs within a TFS and on the RB mapping info
`and collates this in a configuration message or a reconfigu
`ration message with other information. This message is then
`sent by the RNC to the UE and fed there to the RRC
`protocol. The parameters contained in this are then trans
`mitted to the MAC layer. (The MAC layer in the RNC can
`be configured directly by the RRC layer in the RNC).
`The RRC (re)configuration message can exist in different
`forms; for example, as RADIO BEARER RECONFIGU
`RATION, RADIO BEARER SETUP or TRANSPORT
`CHANNEL RECONFIGURATION. FIGS. 2 (and 3) shows
`a diagram of the RADIO BEARER SETUP message
`described in 7. In these messages the RB mapping option,
`which assigns a transport channel to a logical channel for
`each mapping option, and the TFSs of the different transport
`channels, which contain a list of valid TFs with the dynamic
`and semi-static parameters (see FIG. 6), are indicated inde
`pendently of each other.
`The RB mapping option is shown, for example, in FIG. 4.
`As can be seen in the example shown there, a Multiplexing
`Option for a specific Radio Bearer includes the following
`indications per direction (Uplink, UL, and Downlink, DL)
`and per logical channel used by this RB:
`Transport channel types (“TrCh type’).
`ID number of the transport channel onto which the logical
`channel is to be mapped for the option (Tr).
`ID number of the logical channel unique to this transport
`channel (LogChild).
`For the UL prioritization, information for the logical
`channel in respect of the other logical channels mapped
`onto this transport channel and an indication of the
`maximum data rate loss to the benefit of other logical
`channels (MAC LogCh Prio.
`or LogCh max loss).
`The unique tabular representation of the RB mapping info
`is shown in Table 17. The rows show the different elements
`of the IE and the first column shows the name of the element
`and, where necessary, a hierarchical breakdown of the
`element using the symbol ">''. The second column gives an
`indication of whether the element has to be present
`(MP="Mandatory
`Present’,
`OP=“Optional”, CV
`50
`X="Conditional Value', i.e. dependent on X, with X defined
`below the table). The third column, where necessary, gives
`an indication of the multiple presence of the element and the
`other columns contain further information. The indication
`“OP” means that in a bit representation the IE first starts with
`the information which indicates whether further information
`is present for this element. As this information can, for
`example, be represented by a single bit, optional information
`elements can save transmission bandwidth if the information
`is not present.
`The first row in Table I therefore signifies that all the
`elements below in the table, indented with at least one ">
`are repeated as frequently as this first element indicates (in
`this case, a value between 1 and 8). The second row signifies
`that all elements indented with ">>'' are repeated either once
`or twice, depending on whether the RB in question uses one
`or two logical channels for the UL. Rows 3-6 contain the
`
`6
`above-mentioned IEs, which constitute the actual RB map
`ping info. The information in rows 3-5 is then repeated for
`the DL transport channels.
`The tabular representation of the TFS is shown similarly
`in Table 27. In the first row a distinction is made between
`Dedicated Transport Channels and Common Transport
`Channels by making a selection (“CHOICE). The Dynamic
`Transport Format Information, including RLC size, number
`of Transport Blocks (and, where applicable, TTI), is then
`listed and is repeated for each transport format with different
`values. As the Semi-Static Transport Format Information for
`the various transport formats does not vary within a TFS, it
`is only indicated once. See, for example, FIGS. 10A and B.
`
`SUMMARY OF THE INVENTION
`
`The basis of the present invention is the extension of RRC
`(re)configuration messages with the purpose of restricting
`the logical channels to be configured in Such a manner that
`they can only use predetermined transport formats contained
`in the (re)configuration message, thereby suspending the
`independence of the RB mapping info from the indication of
`the TFSS by adding in an extension of the corresponding
`RRC messages a correlation between the transport formats
`and the logical channels, with the corresponding logical
`channels naturally having to be configured for a mapping
`onto the corresponding transport channel. Particularly, the
`logical channels are restricted to the use of predetermined
`values of the parameter RLC size.
`An advantage of the present invention is that the RNC is
`able to configure the data transmission of a number of data
`streams so that they are transmitted via the same transport
`channel and each data stream can, nevertheless, be assigned
`its own transport format; in particular, its own RLC size.
`It is particularly advantageous that a set of “semi-static'
`parameters is equal to all the data streams, which are
`transmitted via a transport channel, the transport formats of
`which are therefore part of the same TFS. Data streams with
`the same requirements with regard to coding type and
`redundancy data length are, therefore, transmitted via the
`same transport channel.
`It is also particularly advantageous that with this method
`the parameters of data block size and their number within a
`transmission interval and, where applicable, the length of the
`transmission interval between the logical channels can differ
`between the logical channels, which are transmitted via a
`transport channel. As the current data rate is determined by
`the combination of these parameters, the data rate of each
`individual logical channel can be predetermined with maxi
`mum efficiency.
`This variation in data rates per logical channel means that
`irregular data streams, in particular, can be transmitted
`efficiently via the UMTS radio interface, which is a further
`advantage of the invention.
`The particularly advantageous restriction of the use of the
`parameter RLC size to predetermined logical channels has
`the particular advantage that the number of RLC-PDUs of a
`logical channel transmitted during a TTI can be influenced
`by the MAC protocol, while the RLC size use