Hm.%mm.__m_um5_.:mmZ<W_LEv__..___Q:umocmccm
`
`
`
`
`
`
`
`88.v__a<:5._ems._.230.:mfiEEm.m_£$~95z<~_owkEEamm'
`
`
`
`
`
`
`
`N9...m._.._an.E_$_§.._ummE81n_m.99coE.2_:o9owoco
`
`
`
`
`::
`
`<E:.m_RE:
`
`
`
`Ea:m._2522%.<m§mEm._=__n5-aE_z<m_E<mmz<m.5mamamz<mEw._$m5o.mm
`
`
`
`
`
`__mEm=_829.mzmeormo2umfiewmS8-n_mmo9e229w._EmEo-mm
`
`
`
`Eoo:._mcm.-OS>_
`
`
`
`m$§Em.oN._-n_E_z<w_Ema--_s8_¢-mz<m.3_a=_é%25:u-o<s_Em._wmm$o-mm
`
`
`
`
`
`
`
`mEmEEoo=5ommw_m._3>_n_m..«amazon332.:w.__...:=
`
`con»
`
`
`
`msEumo;z<momk.5mcweemu:8_m__309:0
`
`
`
`
`
`“Dxmcc<
`
`
`
`-mm=_28%N2$n_no“._.__2%10$.._._m_o
`
`:
`
`amass
`
`
`
`
`
`m%_._mo-maE_c_mu....§8o-qmEE8_m=o-Emamuowsmoem2w._2%”.oB5o-~w_
`
`:9...~25:Em:
`
`Emomo.mm5:.86>mu.5E88
`
`$Ewo-mm9:2$m=Eo..Eaims
`
`
`
`u§.8o.mmEbmz<m.m&n_§.omo-mm2m._aquaEm5o-mm
`
`.__os:.6fiE._2
`
`
`
`
`
`xmn_-aE_z<m:o$o_._m_xmoms5mamamz<mcom._Em$o-~m
`
`
`
`ummmo8-n_oES“.25..Eummmowoiw2m._Ema5omwo-mmmo
`
`
`
`
`
`N::mo-mmeooamm.§o_._msESimo
`
`2<m_5-m_2z<mmo9u9m_9
`
`m_.__«:o_.s._3:_
`
`
`
`m_._.:_m-._m_mnmmmowoam_wto2-mz<mmmmomoamw._2m._mmcoammmmmomm.o-mn-.
`
`
`
`
`
`
`
`
`
`m§:mo-~m_cm..,o8m“Sm:0mmimoamH
`
`3:.go2maul
`
`
`
`Nx.m>o:o=mE._o.E_
`
`o:...$o-mm30coammmmamEo:...5o
`
`
`
`EzumooaEmEwmm_._mE
`
`mco=m.N_E:n_o
`
`SAM
`
`NG 1017-0281
`
`
`
`uoE8o-_o=om8_m__mz<mEbamuofiomofiu2w._Emammomwo-~m
`
`
`
`
`
`SAMSUNG 1017-0281
`
`
`

`
`
`
`884.__a<:5._ems_.E_5_:mfi.§_wgflmuN03z<~_owk".0uoamm'
`
`
`
`
`
`
`
`mEoEEoo:533.2B>_o_w.uofizou33oz:m.__m:=
`
`
`
`nEmowoamm<m_mz<m-mmHEmomoam9w._zaom§.%o-mm
`
`83
`
`
`
`
`
`R3mo-mm_m:_:o%m_..o:muo._comime
`
`w._:nmoo.a
`
`
`
`
`
`3%w_:;m:o_.=_<“£02umwmowoam_._ommu_._m_-mmnmmmomoaw22Emaw8m8-mm
`
`
`
`
`
`
`
`__m8Nmo-§__co_.m._um._p.£m5o-mmm<zmc__u:wE:ocoE28
`
`
`
`
`
`.w.__m:_.,9:m_wmmmmwmE
`
`
`
`tm$o-mm:o_fi2Em£:<:0Cm$o-mm
`
`
`
`n...._-o8-mmuommomoam2m._mwcogmomm8Nwo-~m
`
`m::wo-mw_ho:o_mm_Em:m._._.comxxmo
`
`
`
`
`
`nmm.23.3.:88_m_.Enma.59E2nBm_m:9m8N8-~m
`
`EwE;m__n_Emm
`
`
`
`
`
`EBmEm.mg.m..nm__mo_QEg
`
`
`
`5.9..N25:Emu._a.9IOODn_E838
`
`8m8.o-mm-9.n828$.Em888
`
`
`
`umn;mB.EEEoo_w:Oamnmo53.5.B859.m._$.o%o-mm_
`
`
`
`
`
`-m~_cozomccooommHm
`
`
`
`u8..Fwo-_.m_mmmuomEOUCEEm_m>Em
`
`
`
`
`
`
`
`
`
`_.o<Im._.._ra3:o_mm:om__umNE8.mm.m_2»gm-__mo.m_._.._co$38
`
`
`
`9_..mowo.mm:0flomamw..E.=._ummcomqmowo
`
`
`
`n9%50$-mmuommaoam2m._.,_%mo3N8-~w_
`
`
`
`.m>ou_._m_._E2m._nm-_oE_
`
`=o=S=_E%_
`
`:2.ha2maul
`
`Emucmqwu \
`mmiumooa
`
`EE
`MSUNG E317-0282
`
`
`
`
`
`6.,:o_.om_mE_m<:m<zcow._:.oN8-mm_
`
`
`
`__mEm:_Beamn:.mowo-mm:owmo_:m_Eb_mz<m-mmHSmomoam2w._Ema:amwo-mm
`
`
`
`
`
`
`
`
`
`omvww.u-Nw_fiE._o._mm:oamm._
`
`SAMSUNG 1017-0282
`
`
`

`
`
`
`
`
`88_w__a<:5._ems._.230.:mfiEEm98%~95z<~_owkEEammU
`
`
`
`.<..,._S2BEEcEa<mS-m=m59E29.#_“@5352:3%:95382%NwEE_2_cE..3mzfizomm;waowso2E95
`
`F2.noRwmmn.
`
`SAMSUNG 1017-0283
`
`SAMSUNG 1017-0283
`
`

`
`
`
`886__a<IS5.22.220.._9_~:Bm.229“No.52%om»E:33.I
`
`
`
`
`
`
`
`
`
`._a>o.:Eu._3:_.._£,¢_Umanna!ENew«O3z<mamp2__a:_=:_._8..2.E9:2m_.:£__«U3z$_owe.35.9_.om.S_.=o=<
`
`
`
`
`
`EvenMU.__a£.595.2..~352:E_§3_.=5m._o._E==muofmm:E3a:=__...wt.3%N0325.02.3$5_.mm.::.:u322.
`
`
`
`
`
`
`
`
`
`5.-..3ta3322En...=a_m_$.c385
`
`
`
`
`
`.33m=_§_E_=_2.3.u=aE3=a2:E».55:2..uBmu=_3._on89:2.3&032:._£m._2_E:=~25.m:=E=%a...SU
`
`
`
`
`
`
`
`
`
`
`
`___$...wmmawfi:3%mooflsowmac.can...
`
`._on_E_.E
`
`
`
`.::mEoE._Lo_.xm:05
`
`
`
`0&2.mm_>_._.n_._._w0oz_m:om_._o_mzms_m2
`
`
`
`
`
`
`
`
`
`mm.mmEmuN._x:__a:mN_mnon.o._mE:E_xwE
`
`
`
`:o_§:mEm_QE_own»m:_._:_u
`
`
`
`
`
`
`
`on_o-.E_z<~_EmawomanC885.:o=m..m.om$_-:oom-m_._..o..m._mEoIoomwmxSm39$.
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`on_o-n_E_z<mw-._m_mEmma83:om8_m_:o=mc.wn_om$_-:uom-w:.5»m._.wU._o:oom-m:mom5o-mw_
`
`
`
`
`
`
`
`“.2.goEmmml
`
`mfiozamz
`
`
`
`
`
`xmn_-aE_z<mw-._m_mwoman88mcwemmm$62_:o=m:0n:o0mgozKID_._u<n_|._._m_o*0E_§_uEE_Nam5o-mw_
`
`
`
`z$_-m2m_s_:om8_m_E.3_.E%___mom:_:_._onEm_mZ.9:.5:o=m«m:Q._mE_SqEo-mm
`
`
`
`
`
`
`
`
`
`:3_..ommo_..m_D_o@X(S_:0:o:mo_.Em_0mow5o-~m_
`
`
`
`z§-ms_m_28$u_m_8_eo%_nmsas:0._o_:..o_.,__m_owm3mo-mm_
`
`
`
`
`
`
`
`gm:com8_m_n__oX<_>_:0:o_«mo_.Em_OmmEmo-mw_
`
`
`
`
`
`
`
`
`
`m5m-._mmmmnmm.88commo_._m_5s:m>.6m.c_.m_ua.._:0902326mBasoemm92»Six
`
`
`
`
`
`
`
`
`
`m-._m_mmum?co$o_m_,._o_§_8_8mamm_.=B:o:moE._m_ONE.50$.
`
`
`
`
`
`m-._m_mmmnmm.u:_mu_:§...m_m_0._mm._._m_._oBEEmoan.SqSim
`
`
`
`
`
`m_._.:_w-._m_mmmmmmwoos:o$u_m_:o:m._:o_mommm9:hor_o_Hmu_.=._m_UEq5o-mm
`
`
`
`
`
`
`
`
`
`.m_.:c_wNU?Z<mOmh3u3:En:memu._c.__.33o__a9.9:235::MUozuoucz
`
`
`
`
`
`
`
`msatN02,2%om»so:mmo_8e8$.5as
`
`
`
`“m.xmE:<
`
`
`
`
`
`n_m_._._..ommu_._m_vmfiflmu.w._o.:m2,6mcozowtoo—.2m<.o_.___>_mm:mo-mm_
`
`
`
`
`
`
`
`
`
`-aE_z<mcommo_._m_v_._mE:E_c_Em_.=.8mw:_m>w_nm5m_EoOmom_.wo-Nm_
`
`
`
`
`
`
`
`
`
`
`
`m_._.._m-._m_mmmnom38.o:_8_c§8_mO4252.6_msoEmm_as50$.
`
`SAMSUNG 101 7-0284
`
`SAMSUNG 1017-0284
`
`
`
`

`
`
`
`(QDWIGOP.w_._o_:....u_c:EEooEzzummaw:o:moc__omam
`
`
`
`
`
`.aaE_._:
`
`
`
`
`
`884__a<IS552.220.._9.~:Bm.229“mo;25.09553¢I
`
`
`
`80:mu;§240%__._om_»¢n:_t.<o.C_mMNon:m3omm:_23%B_._o_§.u§,.__tmEo-mw_
`
`
`
`
`
`o_>3on_
`
`
`
`
`
`
`
`.322mm;.2_2¢Q...om-,_m_w_momma__._om_+-n:E40_t_mMRa___n_m%ooohmm:m5:_249.30_..o_§ao.E_omo5o-~m_
`
`
`
`
`
`
`
`
`
`
`
`<n_DWIDD._._m:o=mu_::EEooEszummamcozmnéomnm
`
`
`
`
`
`
`
`
`
`m§mEm_-aE_z<m_m..s<::E993:_awe»Bmsefim9:.5:o_§Eoomw$mo-mm
`
`:o_.m_.E£:_
`
`o_>9on_
`
`
`
`
`
`
`
`.a.§mEm_-aE_z<m_~-._m_mEvan_m.s<::m;m-o<s_msmccoueEEsumtou_m__2__m_£.m5o-mm
`
`
`
`
`
`
`
`
`
`
`
`oonfiomuooEaucmcEm;8m__§_:_-m._m=_E=.5IUn_D-n_.3
`
`
`
`
`
`_._own_-m_._
`
`mlmm
`
`
`
`
`
`®-:_MW_LO»w:o_m_...Dn_$:Qd~_>_CO:o_mm_Ew_._mb_._o_:mE_£:_
`
`V2.3Rmaul
`
`:o_:m._on_._oo
`
`
`
`._owE,_oozo_Ez_m_aoo
`
`
`
`._oEzoozo_Ez_m__2oo
`
`Jamc_on»302mm.
`
`
`
`
`
`o§m£._m_-9._.__z<m_~-._mmwoman_m..s<:_._comc_&mEzoomcuesnm.so__mmacs5:Bx2...o5o-mm_
`
`
`
`
`
`
`
`
`
`m:m_.._um_.___%_o9
`
`5_._:ou_z_|._._m_o
`
`
`
`
`
`
`
`
`
`
`
`-mmm<m-ae_z<m_.m-._m_mSnow220000tzmate«Em...I0n_n_.5:o_E_6_8052:o_§Eoomom:8-mm_
`
`
`
`
`
`EP~-._m_mEmma_m..s<::B_a_a__a%m_n_m_.m>2E_§E8_m_§_umté5o-mm
`
`
`
`
`
`
`
`
`
`
`
`
`
`m-._mm_I28go»mo;.8
`
`
`
`_._oam_-on_Eo4Emma53._.._.<UEmEm:Emtom_.__&ms_9:E:o=8:oommtmo-mw_:on_m_-an_Eo.__~-._m_mmamaE8._.._.<Uco_sm_mmo“:-mnew853mm:B:o_ao_.__uos_mE$o-NmI83._..m_on:ma:mm;.3mm._..m_m2
`
`
`
`
`
`
`
`
`
`Emamcgmemm;o_§_8_om<n_co:o_ao_Em_ottmo-mm_
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`m-:_wI.m_._OO._O._.oco_mDDn_D-U<_2_.._O:o_ww_Ew_._m:_._0_uM_.._._._Oh__..__
`
`
`
`
`
`
`
`
`
`
`
`:oam_-an_Eo.__~-._m_mEnmm£8._.._.<Om:__:umEm.2Em_=E$EEco=o_§&._ooomtmfim_._on_m_-gn_Eo4_n-._mmEmmaC,<Ooc__:_§_om.9Em_:m5mE2:0cozmaeooEtmo-mm_I._:m_:_00...was.wme
`
`
`
`
`
`mm?Emammnmmmsasmmco_.u_%u_%oe.2:coco_sm:oo3tmo..mm
`
`
`
`
`
`
`
`
`
`
`
`
`
`m%_._mo-mqE_=_m_w-._m_m«~08mzoz_B_.o.§mzEmEm_m$62=o_E__mEmmm.5<n_m_+mo8tmo-~m_
`
`
`
`
`
`
`
`
`
`
`
`~_m_._.EmaEnmmmacaw.E2833025.0“.Eoamzfifi.5mc__Em:$550-?
`
`
`
`
`
`
`
`
`
`
`
`
`
`miw-._m_mmmnmm.o=_8_EE$_m_w._.s8:__sm:_28EmnbfimE_m..aEmmEm5o-mm
`
`
`
`
`
`
`
`
`
`
`
`
`
`~_m_._.m-._mmEmmmmacaw2285.02.5.0“.Eoamzfifi.6mc__Em_..2mSo-mm_
`
`
`
`
`
`
`
`SAMSUNG 1017-0285
`
`SAMSUNG 1017-0285
`
`
`
`
`

`
`wm.m~_£mu§,_:__.:
`
`$.m~_m.mE._v_,.___.:
`
`w-,_mm
`
`
`
`_.$_=wommo_m._momu.:owo=_._......ou._.
`
`
`
`
`
`
`
`884__...<IS5.22_9___.oEficflm..._£%mo;25.om»353¢I
`
`
`
`
`
`
`
`
`
`$fimm.%m._-..E_z<m_Emo::_-_m=mo_<w:m-U<_>_.9:c:_:_.+m_u.50:U-U<_>_.0$9.20mam:.o-mm
`
`
`
`
`
`
`
`
`
`$.§m.%~._-n_E_z<m_:.mo:._._m.mo_<2_o,o<_2.9_..o_.__.__E_u..so_._.9052.0mmcmsomam50$.
`
`
`
`
`
`
`
`
`
`m2mmm.mum._-.E_Z<mEwo::_-_m:mo_<e..a.-o<_2.8:o_.__._.%.50:U-U<_>_.0mafiaEmEo-mw_
`
`
`
`
`
`
`
`
`
`
`
`$.mmm.m_u~._-.E_z<mEmo:._._9mo_<9_o-o¢_2.3:o_._=_.m_.so:.9032.0mmcmgowmm5o-mm
`
`
`
`
`
`
`
`
`
`:on_m_-on_Eo._.._.._._m_.m_._.N.:om._.n_._..._.._.<O-m_whoEflmw:_E.m.mU:_uofima.0_..o=mu_..__._m_Ommm5o-mm
`
`
`
`
`
`
`
`
`
`
`
`m:o__mo_::EEooE:.=umm.qwnew.8nib
`
`
`
`
`
`
`
`_._on_m_-anEo4.._.._._m_.m_._.N.:om._.n_._..._.._.<O:o_fi_m_mmou:-mEmwmfimgmm:._oE=8=_E_>_owmSo-mm
`
`
`
`
`
`
`
`
`
`
`
`
`
`w-._m_w_comm_m_.o=mu_::EEooE:.=umm.aw
`
`
`
`m>m>zxmz.mmm_m._>>n__
`
`
`
`_m:o=mu__.:EEooE:.=umm.am
`
`
`
`m>m.§xmz.wmm_m._>;n__
`
`
`
`.w_.o__mo_c:EEooE:.__umm.aw
`
`
`
`w>m.,3xmz_mmm_w._..Sn__
`
`
`
`m:o__mo_::EEooE:.=umm.n_m09.mo._.2:o_.mE.oE_
`
`
`
`
`
`m:o=mo_:_._EEooE_...=umm.mwn_n_._.mo;.0m.._:on_mw_
`
`
`
`
`
`m_.o=mo_::EEooE:.=umm.n_woohm_O._.2:o_um.E.oE_
`
`
`
`.5m__.__Do...m.o_>_8..
`
`
`
`
`
`w-._m_mmoanm_..o=mo_:_._EEo0E_.._.=umm.QwDD...N_O:_
`
`
`
`
`
`Em...goasmaul
`
`
`
`m-._m_mEmam:o=mu_::E_..:oUE=._fi$.awDD...
`
`
`
`
`
`
`
`
`
`m:o=mo_:=EEooE:.fimm.am.9mco_m:n_n_@043.cc:o_mm_Em:m.u:o_.wE.o.:_
`
`
`
`
`
`
`
`
`
`m:o=mo__.SEEooE:._=...mm.awn_n:.mo;.2
`
`
`
`
`
`-uE_Z<~.s_EmmmBE:ommo_.m_=o_.om_mmOu_._.-m.0._o._._mm_..___mqmM.6co:om..o0mmm5o-mm
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`_._on_m_-an_Eo._...:m.m_._.N.com._.n_._..._.._.<Om:__%m6m.8Ew__._m_._uwE9.:.0_.o_.m_nEoo:...m$o-mm
`
`
`
`
`
`
`
`-aE_z<mm-._m_mNmmwmwvmmom_.=._mEmwBzcmo._m_>_¢m.:_EEm:m...9_..o__om..o0m....wEo-Nm
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`Emammmnm.o_.._8_,._9.8_m.0...=o_.§_Bz<~.._»S.5_m_;oEow_ommEo-mm
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`:on_m_-an_Eo._.._.._._m_.m_._.N.:om._.n_._..._.._.<Um_.__%mEm.0b___n_m__m..Ucm:o_mm_Em:m:.m.mmm_.._.mwmEo-mm
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`:on_m_-an_.,mo._.._.._._m_.m_._.N__._om._.n_._..._.._.<U9.__%m€m.0b___n_m__m..Em:_u_mm_Em:m:.m.wmm_.._.mum_mo-mw_
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`:on_m_-on_.&o._...:m.m_._.N.:um.._.n_._..._.._.<O_.o=Em..u.:._m_.__%m_.om.0»w.mE=Em.mE:oOEm5o-mm
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`:o_,..m_-on_E3.._.._._w_.m_._.N.cum._.n_._..._.._.¢Oan:.9Ema.0_._o_.__.._..m_um_.=.0_..o_.mu_.=.m_0£.m5o-mm_
`
`
`
`
`
`zon_m_-an_Eo._Fzx.m_._.N_r_om._.n_._..._.._.<Un_n_._..0»Emu..0:o=_:_..m.U9:.0:n.:mu_..._._m_Umam5o-~m
`
`
`
`
`
`
`
`
`
`
`
`_._oom_-aoE8.3mESmnm88....._m_.m_._.N.839..Fr<Un_n_._..9EmaEco_._£.%9:.0_..o:mo_.._.m_o:.m5o-mm_
`
`
`
`
`
`
`
`
`
`
`
`
`
`_._on_m_-n_n_Eo.__~-._mmEmmaBmm.._.._._N_.m_._.N.:om._.n_._..._.._.,QO.0.£5_._oo:m-m_E.._o=moE.=...._0Ucm_..o_.—um..oOmwmEo-mm_
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`_._on_m_-n_n_Eo.__~-._mmBeam8%.._.._._w_.m_._.N.com._.n_._..._.._.<010.._.___._o:n_-m_.2amm_nE_._oo.m..soa8.32m.m$So-mm_
`
`
`
`
`
`
`
`
`
`
`
`SAMSUNG 1017-0286
`
`SAMSUNG 1017-0286
`
`
`
`

`
`.aaE::
`
`
`
`
`
`88.v__a,...IS5.22.220.._9.~:Bm.229“mo;25.095teamI
`
`
`
`
`
`
`
`
`
`
`
`_._oam_-n_n_E8Emnm.t._w_MFN.EmE._.._..r<UHmmto_m..son_0%:Eco_.mu_Em_oNmmmm_$.._omm5o-m~_
`
`
`
`
`
`
`
`
`
`
`
`
`
`m_._o_:....u_::EEooEazummawu-o<_2m_a_=:EBm_.__xm_n__u_:Em_.__._:U_._o_Em_mm
`
`
`
`
`
`
`
`mica
`
`
`
`
`
`
`
`:on_m_-an_Eo4Emma.._.._._m_.m:.N.com._b._..._.._.¢OEmtoEsauom?.6:o_fio_____m_ow33?.Eo5o-~m_
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`m:o=mo_::EEooEshummzamu-o<_>_m_n_=_:E.5mc_xm_a:_:Em:_.=._u:onum_mm
`
`
`
`
`
`
`
`w..soc
`
`
`
`
`
`
`
`
`
`.322mm;.2_2<o£Emmm_Iom_._.-n_._..._.._.<U_._.._._w_.m._.Nn_n_._.mo._o<_2:_s_¢n=.,.whe:o:o:uEE_¢mm_mo-mm
`
`
`
`
`
`
`
`
`
`
`
`
`
`o_>mc
`
`
`
`<n_ow_._OE..w_._o__mo__._:EEooE::_u.mm:HaM:o_fio_L__o8m
`
`
`
`
`
`mmEm_EwuN._-aE_z<m_com8_m_o._m.8coaucouEmE%__nE$-om$m5o-mm
`
`
`
`
`
`
`
`wN_m3n_n_m_n_xw=E9»umxcE_._o=m5.::oom:
`
`
`
`
`
`
`
`._.._.z0<n_n_E:o=E:mEo_aE_émmNmm5o-mw_«mama.o:_8_:§8_m_0..o._m_SS_.__cosoflmu28__5o:0Nmnmm9mo:o%o-~mg220000
`
`
`
`
`
`
`
`
`
`34.BSmmml
`
`m?e.<E:-mhe3Esmix<5:3..N353.E35cm.
`
`a_n__£~25E953.53.32”3o
`
`
`
` 23.8..mu_E3..5...MO_
`
`2..._#_EuEuoo
`
`SouS...35S.
`
`Box.8£0m.
`
`
`
`EEou_m_._O__..o$o_m_m_£Q__Nzdm.6mEmEm.o_mmmctmsoomo50%2.om8-mm
`
`
`
`
`
`
`
`.5558m_£....EmzqmEmEwEmE.m.:_.w>oumoEmmaomomewmm
`
`
`
`
`
`
`
`8_:o:8_m_0..m._%m8amc___on_E_._o_§:._ooco«N082motoNmo-mw_
`
`
`
`._.._.zmwnommp3mcozomtoom:omcm__mom_28.o%o-~m_
`
`
`
`
`
`
`
`:om8__m_o._mBmcozumtoo__mEwmmnmm9moEommo-mm
`
`
`
`
`
`
`
`
`
`0..£0mmnom_um:mEL810$ommo-mm_
`
`
`
`
`
`0..mssoucmzmmm_mmo_m:_EmmEmmmdm2mo3émmo-mm
`
`
`
`
`
`SAMSUNG 1017-0287
`
`
`
`

`
`2 Report of TSG RAN WG2 #61bis. Shenzhen. China, March 31 — April 4. 2008
`
`Annex F:
`
`Report of LTE user plane session (Al 5.1)
`
`For convenience the summary R2-082026 ofthe LTE user plane session (agenda item 5.1) is copied into this annex.
`Note: The report ofthis session was already agreed separately under agenda item 7.2.
`
`5.1
`
`User plane
`
`5.1.1
`
`MAC (36,321)
`
`5.1.1.1
`
`Status
`
`iiipirrjroiir :'upp0i'.tem' 0i.'.f_l'. E.g. endai‘se.=rieii! Qffarest oI':.v'a.fl’ i'uppo:'re:.-r E "R c'o\'ei'ing (.'ifiLmg(’S agreed so_I£u', open issrie H.-.'.f (ma! p0ren:fa!_firi'r.’m‘
`mpporrei.-r rrprfore pmposais.
`
`R2-081799: Report of MAC activitiesMAC Rapporteurs (Qua|comrn Europe, Ericsson)
`-
`Etienne announces that Ericsson (Magnus) will be the rapporteur from now on, and Arnaud
`will be the new editor for MAC.
`=> Noted
`
`R2-081801: Comment on MAC specification v6 MAC Rapporteurs (Quaicomm Europe, Ericsson)
`=> Noted without presentation
`
`R2-081718: MAC Open Issues list MAC Rapporteurs (Ericsson, Qualcomm Europe)
`-
`Panasonic wonders how the worksplit between RAN1 and RAN2 is assumed for TB sizes ?
`RAN1 is specifying the MCS values. Ericsson assumes that this could to a large extend be
`handled in RAN1. If there are RAN2 aspects they should be identified so that they can be
`discussed in RAN2. Panasonic assumes that it would be good if RAN1 would get some input
`on typical MAC PDU sizes.
`Panasonic assumes that the MAC CE prioritisation is still open (only BSR at handover has
`been agreed).
`NSN is wondering if nothing concerning CQJ reporting needs to be specified in MAC ? At
`least the relation between DRX and CQIISPS will need to be specified. NSN was thinking
`about the scheduled CQI reports. Ericsson wonders what aspect is MAC ? NSN assumes this
`is MAC because it is a scheduled behaviour. Ericsson assumes MAC in the UE would not
`need to be involved. Panasonic assumes this should be handled in L1.
`
`-
`
`-
`
`- Motorola thinks it is not that clear from the MAC spec that we will always have a PHICH
`configured. It seems to be specified only very implicitly ?
`- Motorola assumes that DR04 would be more an system implementation issue. Ericsson is not
`sure there is no problem : eg. if the long-DRX is distributed. does that enable a limited
`« change indication » ? Should show there is a problem before we solve anything.
`=> Noted
`
`R2-081?19:
`
`E-UTRA MAC protocol specification update (CR) MAC Rapportuers (Ericsson, Qualcomm
`Europe)
`=> Agreed as baseline for the future
`Note: After RAN2 #61 bis R2-081719 was revised in R2-082049 (see email discussion
`61 b_36.321).
`
`R2-081720: Clarification of Random Access identities MAC Rapporteurs (Ericsson, Qualcomm Europe}
`-
`LG wonders if there is a definition of “RAPID” in the spec ?
`=> Text proposal is agreed
`
`R2-081721: Correction of dedicated preamble handling in absence of expiry time MAC Rapporteurs
`(Ericsson, Qualcomm Europe)
`=> Text proposal is agreed
`
`32/ 134
`
`SAMSUNG 1017-0288
`
`SAMSUNG 1017-0288
`
`

`
`2 Report of TSG RAN WG2 #61bis, Shenzhen, China, March 31 — April 4, 2008
`
`R2-081?22: Correction to local-NACK MAC Rapporteurs(Ericsson.Qualcornm Europe)
`=> Text proposal is agreed
`
`-
`-
`
`-
`
`R2-081724: UE behaviour for sub-80-bit grant for RA msg3MAC Rapporteurs (Ericsson, Qualcomm Europe)
`- Motorola indicates at least for RRC we would not too frequently use this “UE behaviour not
`specified", but instead describe the mandated network behaviour.
`Chairman asked why the “first" UL transmission is mentioned ?
`Could instead of the suggested sentence, indicate in a note in this section ‘‘In case an UL
`transmission is required, the eNB shall not provide a grant smaller than 80 bits in lv1sg2".
`Ericsson thinks if the network would give such a grant, it would be good that the UE does not
`end up in a deadlock.
`Panasonic assumes that in the current spec, the UE would send padding (UE has to follow
`the grant).
`=> Add a note in this section ‘‘In case an UL transmission is required, the eNB should not
`provide a grant smaller than 80 bits in Msg2".
`
`-
`
`R2-081725:
`
`Streamlining of the description of UL HARQ MAC Rapporteurs (Ericsson, Qualcomm Europe)
`-
`NSN assumes that in some cases where it says retransmission it could also be a new
`transmission. So the “re-“ should be placed in “(re-)“. Ericsson assumes the text is correct:
`the eNB should not schedule a first transmission in a measurement gap.
`NSN agrees that the current update is in line with the current spec. However we might have
`to reconsider this for persistent scheduling.
`=> Text proposal is agreed
`
`-
`
`R2-081800: Correction to Random Access power setting MAC Rapporteurs (Qualcomrn Europe, Ericsson)
`=> Text proposal is agreed
`
`5.1.1.2
`
`Dynamic scheduling
`
`,-'iir_i'r.liiirg icffi to be c'fnr'i1?edfspec.y'ied?
`
`Redundancy version determination
`R2-081529: RV for non-adaptive retransmissions Nokia Corporation, Nokia Siemens Networks
`-
`QC wonders whether this proposal the redundancy versions are not incremented during
`"suspension" ? QC thinks now the redundancy version is also updated in case of suspension,
`and this was not the situation before.
`
`-
`
`-
`
`-
`
`NTT DCM thinks that the proposed behaviour might be better, because otherwise due to a
`false ACK a misalignment in RV could arise.
`In Panasonic’s assumption after suspension you wouid only restart after a PDCCH with an
`explicit RV indication. So there is no risk for misalignment.
`NTT DCM indicates that if we don't have an implicit rule for the RV, then you cannot adapt
`the MCS. Panasonic clarifies that you can adapt the MCS and go to RV=0. Ericsson assumes
`that if this is signailed, it is a new transmission. Panasonic clarifies that there is still the NDI
`field.
`
`-
`
`Ericsson wonders whether the intention is to indeed not to take the RV signalled for
`retransmissions into account ? This is indeed a restriction.
`=> Noted
`
`R2-081723: TP on uplink RV handling MAC Rapporteurs (Ericsson, Qualcomm Europe)
`-
`Panasonic indicates that the CURRENT_lRV is now an index to the RV. However the
`PDCCH signals RV itseif. So if we receive a grant for a retransmission, we should set the
`CURRENT_|RV to the index value corresponding to the indicated RV (or similar formulation).
`=> Text proposal is agreed with this change
`
`R2-081573: RV usage for UL HARQ Panasonic
`=> Noted
`
`PHICH in measurement gap
`R2-081602: HARQ feedback and Measurement Gap LG Electronics Inc.
`=> We agree we need to specify the HARQ behaviour for this case.
`
`33 / 134
`
`SAMSUNG 1017-0289
`
`

`
`2 Report of TSG RAN WG2 #61bis. Shenzhen. China, March 31 — April 4. 2008
`
`R2-081727:
`
`UL HARQ handling when P-HIGH collides with measurement gap NTT DoCoMo, Inc.
`-
`NSN assumes that in the proposal it is still a “tentative ACK”, so suspension. NTT DCM
`confirms.
`
`-
`-
`
`-
`
`LG supports this proposal.
`Chairman wonders how this works with UL bundling ? NTT DCM sees no specific problems:
`there is still only 1 ACKINACK.
`Samsung is a bit worried about the number of options. In general we could assume a NACK
`when PHICH cannot be received. Samsung would prefer that skipping the UL transmission
`and skipping the PHICH reception should be handled in a unified way.
`QC assumes it would be better to consider it an ACK.
`NTT DCM wonders what the UE behaviour is for the other case (i.e. UL tx not performed due
`to measurement, thus no PHICH allocated). So in this case you have to assume a NACK.
`Ericsson wonders how often this will happen ? If this happens frequently we need more
`retransmissions. Depends on configuration.
`=> Proposal is technically endorsed. Will see a text proposal in R2-081991
`R2-081991: TP for UL HARD handiing for P-HICH in measurement gap
`-
`Ericsson thinks there is a problem with how to capture this but the section also is updated by
`other CR’s. Rapporteur will try to take care of this (movingislight revision).
`=> Agree on the text proposal
`
`-
`-
`
`-
`
`-
`
`UL Bundling
`R2-081446: RAN2 aspects of the soiutions for Subfrarne Bundling Alcatel-Lucent
`-
`NSN thinks that 2 aspects are missing: how do the bundling proposals fit to TDD and HD ?
`None of the proposats seems to consider that ? ALU thinks that since all 3 proposals come
`from RAN1, they should all be feasible.
`Ericsson thinks it would be a bit premature to already discuss HD a lot since we only now
`introduce it in MAC. Ericsson thinks that at least alternatives 1 and 2 seems no specific
`problem for HD_ Maybe alternative 3 would cause more problems for HD. TDD will need to be
`considered further for all proposals (e.g. in combination with only allocation 1 UL subframe).
`QC wonders if UL bundling is really required for TDD: if a cell is so big that you need
`bundling. the UL/DL switching times will be very large. So maybe you should not have
`bundling.
`CATT thinks UL bundling for TDD is much more complex. 80 we need more time to consider
`this. So CATT would like to wait for the conclusion from RAN1 first on TDD.
`
`—
`
`-
`
`-
`
`-
`-
`
`Ericsson thinks that for TDD the same coverage problem exists for TDD than for FDD. Based
`on a first analysis, Ericsson does not see any major consequence for alternative 1 with TDD.
`Ericson assumes that in TDD the UL subframes do not have to be consequetive.
`Ericsson would prefer to have a decision in this meeting, and we will make it for TDD as well.
`
`R2-081465: Evaluation of TTI-Bundling Alternatives Ericsson
`-
`Ericsson values the “used resources" higher than the “latency gain” potentially provided by
`proposal 2.
`Philips wonders whether there are also simulation result for 3 ? Ericsson has no results.
`
`-
`
`R2-0317533 UL coverage enhancement TOT VOIP transmission Philips, NXP Semiconductors
`
`Discussion:
`
`-
`
`Nokia prefers to have 1 HARD number bundling for testing purposes. They think this would
`also be enough to meet the HARD. msg3 performance. For FDD Nokia was thinking about the
`value 4. (TDD FFS).
`- Motorola wonders whether bundling is a static or a semi-static configuration ? Ericsson
`assumes it is a semi-static configuration configured with RRC. This is also reflected in R2-
`081326.
`
`-
`
`QC thinks that this is an optimisation and would like to keep the #options low, so it would be
`good to limit to one value.
`- Motorola wonders whether the fact that we would limit to 4 HARQ retrans would impact the
`decision.
`
`-
`
`Samsung is happy to do an indicative show of hands.
`
`34/ 134
`
`SAMSUNG 1017-0290
`
`SAMSUNG 1017-0290
`
`

`
`2 Report of TSG RAN WG2 #61bis. Shenzhen. China, March 31 — April 4. 2008
`
`-
`
`Ericsson assumes alt alternatives work with 4 HARD retrans. ALU indicates that for
`alternative 3 complexity is added with a flexible bundiing.
`
`For indication:
`
`- “Altemative 1":
`- “Alternative 2":
`- “Alternative 3":
`
`[4]
`[2]
`[3]
`
`-
`
`-
`
`NSN indicates they did not vote because it is to early. NSN would like more time to think
`about especially the TDD aspect.
`QC wonders if we could agree to limit to a bundle of 4. Ericsson thinks we could wait for the
`further analysis.
`=> Will defer until next meeting; hopefully take a decision at the coming meeting.
`
`R2-081466: Text Proposal for TTI bundling Ericsson
`
`DRX handling
`5.1.1.3
`Hg. ‘liulieii are f’Q.l:’S.’t‘S .':‘wisnH'.s'.s'.50ii.s' to be _uei_'fw'mea’ I’
`
`DRX control
`R2-081603: Corrections on DRX LG Electronics Inc.
`
`Proposal 1:
`-
`Put "when configured" at the beginning of the cycled.
`- Motorola things this is not strictly required. The procedure text should make this clear, not in
`the definition section.
`=> Not needed (already clear in procedure text}
`Proposal 2:
`-
`It was questioned whether we should also add “SR pending time” or UE waiting for UL
`transmissions. Sunplus thinks it might be easier to define the “active time" as the time when
`UE is reading PDCCH.
`=> Agreed (can revisit if we want to extend it even more}; Later overruled by decisions on R2-
`081879
`
`-
`
`Proposal 3:
`-
`QC things considering the timer “expired“ at receipt of the MAC CE would also solve the
`problem. So the timer would be “considered expired" when the MAC CE is explained.
`Sunplus asks what happens if the inactivity timer is not running when the MAC CE is received
`? Is the DRX short DRX cycle not started ? LG assumes there is little reason to sent the
`MAC CE when the inactivity timer is not running. Sunplus things that the MAC CE could also
`be received during on-duration without inactivity timer running.
`=> Agreed with this change; later overruled by decisions on R2-081879
`
`R2-081680: Discussion on DRX cycie ASUSTeK
`=> Noted
`
`R2-081879: DRX related correction and clarification Sunplus mMobiIe Inc.
`Proposal 1:
`—
`NSN thinks this was discussed in the past but does not remember the reason for not having
`it. Ericsson thinks if we allow this it is kind of abusing the fact that the UE is in principle onty
`waiting for a retransmission.
`Samsung think it would be simpler to say that the inactivity timer is started whenever a new
`transmission is received.
`
`-
`
`-
`
`RIM thinks the DRX retransmission timer is never stopped. Sunplus thinks it is stopped when
`a PDCCH is received.
`
`-
`
`Panasonic thinks this was a deliberate choice: the UE already went to a kind of sleep mode
`but only wants to receive retransmissions.
`- Motorola thinks the current behaviour is indeed a bit strange.
`-
`Can we agree that whenever the UE receives a new grant it shall start the inactivity timer ?
`-
`Nokia agrees with Panasonic that the current behaviour is safer. Panasonic has no strong
`concerns and think it might make sense to always start the inactivity timer. UE has to foilow
`the grant anyway,
`
`35/134
`
`SAMSUNG 1017-0291
`
`SAMSUNG 1017-0291
`
`

`
`2 Report of TSG RAN WG2 #61bis. Shenzhen. China, March 31 — April 4. 2008
`
`-
`-
`
`=> Might Agree that: whenever the PDCCH indicates a new transmission (DL or UL). the UE
`starts or restans the DRX Inactivity timer ?
`Continuation on Thursday: QC support the proposal
`NSN is not convinced about the need. Ericsson does not see a strong need but is fine if there
`is a majority. Panasonic sees a benefit for the simplification and supports this change. LG is
`also in favour of the change.
`=> Agree that whenever the PDCCH indicates a new transmission (DL or UL), the UE starts or
`restarts the DRX Inactivity timer (include in QC CR).
`Proposal 2:
`-
`Proposal is to read the active time in the definition section as “the time the UE monitors the
`PDCCH”.
`
`-
`
`-
`
`-
`
`QC support this proposal.
`-
`Ericsson likes the idea of simplification but would like to check the impact
`-
`After revisit on Thursday
`-
`QC thinks it cieans up the definition. NSN thinks it would be a good idea.
`=> Agree with the change in definition (include in QC CR).
`Proposal 3:
`-
`RIM thinks the MAC CE could give the option to go to ether long or short DRX.
`-
`Chairman thought it would be ok to always go to short DRX. Motorola thought it would be
`more logical to go to a long DRX. Going to short DRX would only save a few ms of
`monitoring.
`Ericsson thinks that the MAC CE could eg. be used when you have removed the PUCCH
`resources, and then bring the UE to the cycle it was in before.
`Samsung assumes that the inactivity timer can be short for VOIP, but for packet service with
`lower priority, the inactivity timer could be quite long for scheduling flexibility. Samsung thinks
`it would be nicest to have a simple behaviour.
`QC would like 1 behaviour when the MAC CE is sent. QC's understanding was that we would
`always go to the long DRX. NSN has no preference on what DRX to go to but it should only
`be 1. Ericsson thinks the original intend was to stay in the DRX you were.
`- Motorola wonder if that was the intention, why not wait for the inactivity timer. Then the UE
`would anyway have gone to that DRX.
`IDT thinks it would be most logical to start the short DRX Cycle Timer.
`Huawei thinks this MAC CE enabled a quite long Inactivity timer. So Huawei is fine with going
`to the short cycle.
`There are 3 options:
`1} Always go to short DRX
`2) Always go to long DRX
`3) Go to the “DR)( you were in”
`On Thursday. QC reported that 9 companies are in favour of going to short DRX only (if
`configured). However still some companies would some other behaviour.
`NSN thinks we should not have so much discussion on such a detailed issue. NSN would be
`
`-
`-
`
`-
`
`-
`
`-
`
`happy to follow the majority.
`=> Agree that we will go to short DRX if configured.
`=> [CB text proposal with 3 proposals in R2-031997]
`
`R2-081874: DRX clarification in TDD CATT, CMCC
`Proposal 1
`=> Agreed
`Proposal 2
`-
`QC wonders if this is a proposal only for TDD ? CATT thinks it could be applicable for FDD
`and TDD. Samsung sees no big problem to have this for FDD also.
`NSN is fine for TDD, but would like to keep the FDD part as part of the email discussion on
`RRC MAC parameters.
`=> Agree for TDD; FDD FFS.
`Proposal 3:
`-
`Chairman asks if proposal 2 is not sufficient ? If the “DRX starts offset" is configured to be a
`DL subframe, then any subframe x times 10ms away is also always a DL subframe ? So it
`would be sufficient to mandate that the “DRX Starts Offset“ always points to a DL subframe.
`So this is an implementation issue (eNB configuration}.
`
`-
`
`as/134
`
`SAMSUNG 1017-0292
`
`SAMSUNG 1017-0292
`
`

`
`2 Report of TSG RAN WG2 #61bis. Shenzhen. China, March 31 — April 4. 2008
`
`=> Agree to include in the spec that the "DRX Starts Offset" should always be set to a DL
`subframe for TDD. GATT is requested to come with an RRC CR for the next meeting to
`clarify this.
`
`R2-081682: The operation of DRX Short Cycle Timer ASUSTeK
`-
`Sunplus thinks this is related to proposal 4 from their paper.
`=> Can also be discussed in the offline discussion.
`
`R2-081698: Activation of DRXHUAWEI
`
`-
`
`QC thinks we should try to stick to the principle to have no activation time in LTE. Huawei
`wonders how you would do this type of configuration then ? QC thinks it can be left to
`implementation. Huawei wonders how to achieve a synchronised view.
`RIM sees some benefits of signalling an activation time. IDT thinks this could potentially use
`any solution that might come out of the email discussion on “synchronised reconfiguration“.
`Chairman wonders if there is a real problem ? The UE wiil try to deliver the RRC response
`message irrespective of the DRX and then the eNB knows the DRX.
`NSN had the same proposal in the last meeting, but now thinks that it is not needed: the eNB
`can try all subframes he thinks the UE could be listening in.
`Ericsson thinks that for DRX the eNB could ensure that the patterns are multiples and only
`assume the longer until the shorter has been confirmed.
`Samsung thinks the desynchronisation is a quite rare case and there are solutions to recover.
`-
`=> Noted; No iarge need is seen
`
`-
`
`-
`
`-
`
`-
`
`R2-081888: Go to Long Sleep Command for LTE DRX Research In Motion
`-
`ls related to the offline discussion.
`
`-
`
`Huawei wonders when one command would be used, and when you would use the short
`command ? Huawei sees no use for 2 commands since there would be only ‘i situation in
`which you use it. This is also the Ericsson view.
`=> Can be considered as part of the offline discussion
`
`PUCCH resources
`
`R2-081533:
`
`PUCCH handling during DRX Samsung
`Proposal 1:
`-
`NSN thinks if you have big traffic, the on-duration will be longer and you can sent the CQI
`during on-duration. NSN does not like to reserve PUCCH resources when you are not sure
`they will be used. NSN thinks today it is clear in the stage-2 that you would only sent it during
`on duration.
`
`-
`
`-
`-
`-
`
`-
`
`-
`
`-
`
`Ericsson thinks that NSN can still achieve its goal with the Samsung proposal by only
`configuring CQI resources in the on-duration. So it becomes a configuration issue.
`RIM sees some benefits for the proposal.
`NSN thinks we can still always have the aperiodic ones.
`Samsung thinks there is no perfect solution, and agrees it can be solved with the aperiodic
`CQI. Which one is better is probably depending on the scenario. If you expect heavy traffic
`than the active period could be quite long.
`NSN thinks the probability is larger to end up with unused PUCCH resources with this
`proposed solution. It is true that heavy DL traffic will normally also result in quite some UL
`traffic.
`
`NTT DCM woutd prefer to have the possibility not to totally depend on polling, so would
`support the proposal. They think the NSN concern can be addressed by only configuring the
`resources during the on-duration. Panasonic agrees with this.
`NSN is fine as long as the configuration allows the possibility to only configure the PUCCH in
`on-duration.
`
`=> Agree that CQI is sent during “active time", but it shall be possible to configure this such that it
`results in only periodic CQI during the on-duration. { 80 AND function between RRC
`configuration and the “active time”)
`=> Samsung will bring a corresponding RRC CR that enables this behaviour for the next meeting
`Proposal 2:
`—
`Samsung likes to aiign UL traffic and SR5 but not to make the proposal to complex. RIM
`thinks it is a waste to transmit SR8 also when there is only DL activity. Samsung agrees the
`
`37/ 134
`
`SAMSUNG 1017-0293
`
`SAMSUNG 1017-0293
`
`

`
`2 Report of TSG RAN WG2 #61bis. Shenzhen. China, March 31 — April 4. 2008
`
`-
`
`-
`
`solution is not perfect, but we should also consider simplicity. RIM thinks maybe alternative
`trade-offs between alignment and simplicity are possible.
`LG thinks that UL SR8 is also used for UL TA, so also in case of DL activity only this is
`required.
`Panasonic indicates that currently the active time does not include the PDCCH reading time
`used for UL retransmission. Is it the intention of Samsung to also include this time. Samsung
`thinks this can depend on whatever the outcome of the offline discussion is.
`=> Can agree to this as a starting point
`=> Will see MAC text proposals in R2-081993
`R2-081993: TP for PUCCH resource handling during DRX
`-
`QC thinks there could be better sections to put this. Samsung admits they could not really
`find a good section and is fine if the rapporteur would move it.
`RIM thinks we could talk about “if a periodical CQI is configured for this TT|” instead of
`mentioning the PUCCH resource.
`Ericsson thinks we should indicate to L1 to transmit the CQI.
`
`-
`
`-
`
`=> Agreed with text proposal but change to “if periodical CQI is configured for this TTJ”, “if SR8 is
`configured for this ‘l'l'l" and "indicate to L1 to transmit the CQI"
`
`R2-081866: Some Details on CQI Transmission during DRX Research In Motion
`-
`Proposal 2 already covered