3GPP TSG RAN WG1 #57b & WG2 #66b /08/20

Size: px

Start display at page:

Download "3GPP TSG RAN WG1 #57b & WG2 #66b /08/20"

百闷尹
4 years ago
Views:

1 3GPP TSG RAN WG1 #57b & WG2 #66b /08/20

2 3GPP TSG RAN1/2 Los Angeles, USA ITRI TW4G RAN1 RAN2 WGs Contribution ITRI Contributions RAN1 RAN2 RAN1 contribution RAN2 3GPP LTE-Advanced 3GPP ITU-R IMT-Advanced LTE-Advanced ITU-R RAN1 LTE-Advanced 3GPP RAN LTE-Advanced TW4G LTE-Advanced 3GPP LTE-Advanced 3GPP LTE LTE Stage 3 PHY Layer MAC RLC PDCP RRC release 8 release 9 stage 2 M300 RAN1/2 3GPP LTE-Advanced (980052) (950655) 3GPP RAN2#66bis MBMS (940030) RAN1 3GPP LTE-Advanced 1. Obtain the potential research issues and progress of LTE-A and MAC in (970529) LTE Rel-8 & Rel-9 2. Present our contributions and discuss them with other companies 1

4 3GPP TSG RAN1 #57bis Meeting 3GPP TSG RAN2 #66bis Meeting LTE-A CoMP HeNB MBMS (RAN1 RAN2) June 29, 2009 ~ July 3, 2009 Hilton Los Angeles/Universal City, Los Angeles, USA 3

5 RAN1 Tentative Schedule RAN1#57bis Monday Tuesday Wednesday Thursday Friday 1, 2, (Pos) 10 (LTE) 15, 15.7 (Eval) (DL RS) 15.2 (CoMP) 15.4 (BW aggr.) 15.3 (Relays) (DS BF) 12 Revisions Main room Breakout room RAN2 Indicative Time-schedule Main room 2 nd LTE room Mon: before morning coffee Mon: morning coffee -> lunch Mon: lunch -> afternoon coffee Mon: after afternoon coffee [2], [3], [4.1] + [4.2.1],[6.4],[4.2.2] Tue: before morning coffee Tue: morning coffee -> lunch Tue: lunch -> afternoon coffee Tue: after afternoon coffee LTE CP [5.8][5.9][6.7.1] + Rel-9 [6.2]. LTE UP [5.3] [5.6], [6.7.2] Wed: before morning coffee Wed: morning coffee -> lunch Wed: lunch -> afternoon coffee Wed: after afternoon coffee Positioning [6.1] MBMS [6.3] Thu: before morning coffee Rel-9 Thu: morning coffee -> lunch LTE-A [7.1][7.2][7.3] Thu: lunch -> afternoon coffee Thu: after afternoon coffee LTE-A: Relay [7.4] Fri: before morning coffee Fri: morning coffee -> lunch Fri: lunch -> afternoon coffee Fri: after afternoon coffee Left-overs, comebacks 4

6 RAN1 Meeting LTE Advance: BW Aggregation : Carrier Aggregation : (Backwards compatible carrier): LTE UEs Carrier Aggregation FDD (Non-backwards compatible carrier): UEs UEs Carrier Aggregation (Extension carrier): (UE DL Component Carrier Set): PDSCH (UE UL Component Carrier Set): PUSCH PDCCH RAN2 RAN1 RAN2 RAN2 Meeting LTE rel-8 User Plane: MAC 5

7 R Report of discussion on [66.12] LTE NDI handling with T-CRNTI in consideration R PDCCH on C-RNTI HARQ process X NDI = y RAR HARQ process X NDI = 0 PDCCH on C-RNTI HARQ process X NDI = y Previous TB Current TB Table 1 & 2 summarize the consequence if we don't agree the CR R CASE 1) NDI is set to zero. - ENB commands adaptive retransmission of the previous TB <TABLE 1> NDI of the previous TB NDI after Msg 3 reception NDI of the UL grant Consequence CASE UE assumes it is the UL grant for the Msg 3. If TBS is not same, UE would ignore the UL grant UE assumes it is the UL grant for the new transmission. UE consider the contention is resolved. BSR is lost without new transmission. - ENB commands new transmission before msg3 is received. <TABLE 2> NDI of the NDI after NDI of Consequence CASE previous TB Msg 3 reception the UL grant UE assumes it is the UL grant for the new transmission. UE consider the contention is resolved. BSR is lost but new transmission is still performed UE assumes it is the UL grant for the Msg 3. If TBS is not same, UE would ignore the Ul grant Table 3 & 4 summarize the consequence if we agree the CR R CASE 2) NDI is kept as before. - ENB commands adaptive retransmission of the previous TB 6

8 <TABLE 3> NDI of the NDI after NDI of Consequence previous Msg 3 the UL CASE TB reception grant UE is able to know that it is the UL grant for the previous TB. If TBS is not same, UE would ignore the UL grant UE is able to know that it is the UL grant for the previous TB. If TBS is not same, UE would ignore the UL grant - ENB commands new transmission before msg3 is received. <TABLE 4> NDI of the NDI after NDI of Consequence previous Msg 3 the UL CASE TB reception grant UE assumes it is the UL grant for the new transmission. UE consider the contention is resolved. BSR is lost but new transmission is still performed UE assumes it is the UL grant for the new transmission. UE consider the contention is resolved. BSR is lost but new transmission is still performed. LTE-Advance: Carrier Aggregation 7

9 Connected mode mobility & measurements 8

10 LTE release 9: MBMS LTE RAN2#66bis MBMS discussion discussion : [66#18] LTE: MBMS Notification [66#19] LTE: MBMS Control Plane details [66#20] LTE: MBMS User Plane details : 1. R : Report of discussion [66#18] LTE: MBMS Notification (Huawei) discussion MCCH modification period MBMS notification MCCH modification period MBMS notification mechanism discussion (Rapportuer) : Proposal 1: The rapporteur proposes to agree to have a MCCH modification period. Proposal 2: The rapporteur proposes that the UE shall update its MCCH at least at the modification period boundary while receiveing a session. MBMS notification 12 4 MBMS notification RAN2 => Agreements: (MBMS notification) 1) Will have an MCCH modification period 2) We will have a notification mechanism 3) Notification mechanism will be used for session starts. UE receiving a service will have to read the MCCH every modification period 4) UE in IDLE only needs to check the notification during its paging occasion or does the UE wakeup additionally (FFS) 9

11 5) If the UE sees the notification, it will acquire the MCCH after the next MCCH modification period boundary 6) PDCCH with new MBMS Specific M-RNTI is used for notification 2. R : discussion on embms control plane details (66#19) (Samsung) MBMS control plane discussion discussion MBMS BCCH MCCH discussion BCCH => BCCH signalling related agreements: 1) Agreed way forward #1: indicate the subframe allocation for MCCH on BCCH directly and not indirectly by indicating the MSAP of the PMCH on which it it mapped. Further details are FFS. Use of PMCH MSAP may be reconsidered (at a later stage i.e. when the MSAP signalling is more clear) only if it can really simplify without introducing much additional overhead 2) MSAP occasion period is not indicated i.e. the MCCH subframe allocation for MCCH in conjunction with the repetition period should be sufficient for the UE to acquire MCCH 3) For now, CR should only include one MBSFN area/1 MCCH reference in BCCH. MCCH MBSFN Area MCH MCHs Option 1) 1 MCH per MBSFN area, with one MCS [2] Option 2) 1 MCH per MBSFN area with different MCS based on MSCH/blind decoding[3] Option 3) Multiple MCH per MBSFN area with one MCS per MCH [8] Option 3 8 MBSFN Area MCHs MCCH => MCCH signalling related agreements: 5) Modified and unmodified services listed together i.e. no distinction between the two 6) No service status for the moment, until a clear need/ use case is agreed 7) Working assumption is to have a short session identity e.g. for use in the scheduling information, but the details are FFS (e.g. whether logical channel identity is used, whether explicit signalling is avoided i.e. identity is determined by the order in the list) 8): Sessions are (dynamically) scheduled in the order in which they are included in this list. Note that this does not imply a priority, only the order. 9) One MBSFN area can contain 1 or more MCH s, with one MCS per MCH. 3. R : Report of discussion on MBMS user plane details [66#20] (Huawei) MBMS user plane discussion 10

12 Dynamic Scheduling Information (DSI) RRC signalling MAC control element (MAC CE) discussion DSI MAC CE 15 MAC CE 4 RRC DSI MAC CE MBMS U-plane => Agreements: (MBMS U-plane) 1) Dynamic Scheduling is transported in a MAC CE 2) In one MSAP occasion, we will only sent the MSCH once. 3) Current assumption is that no change is needed to RLC and MAC for content synchronisation. i.e. e.g. no requirement on one LI per SDU. 4) MCCH repetitions are handled at RRC level. 5) On MCH the MCCH LCID is 0. - note that if there is no MCCH on MCH, an MTCH could use this value. 6) MCCH explicitly signal the LCID for each MTCH 7) LCID is explicitly indicated in MAC subheader for each MBMS transmission. RAN 1 LTE-Advance: CoMP, MIMO, Relay CoMP session contribution CoMP feedback cells coordination coordination precoder interference power feedback -reflector feedback CoMP mode(jt/cs/cb) ITRI R symbol (cyclic-prefix) (cyclic-postfix) cell-edge UE CoMP coordinated cell detection CoMP contribution treated CoMP uplink MIMO two layer beamforing layer shifting ITRI Type II Relay Type II Relay Cell ID Release 8 UEs Type II RN 11

13 coverage Type II Relay RAN 2 LTE rel-8 & rel-9 User Plane: MAC LTE rel-8 :Ericsson NSN Ericsson LTE rel-9 Ericsson LTE rel-8 Ericsson LTE rel-8 LTE-Advance: Carrier Aggregation LTE-A Stage 1 LTE rel-9 Carrier Aggregation carrier RAN1 RAN2 RAN2 RAN1 stage 1 handover handover command multiple carrier configuration LTE release-9: MBMS MBMS discussion [66b#11] LTE: MBMS Control Plane (Samsung) discussion to progress any remaining MBMS control plane issue, e.g.: - how to specify the MSAP for a specific MCH (see R , R , R )? - how to specify the MCCH subframes on BCCH (see e.g. R )? - QOS handling for MCCH (e.g. specific QOS for MCCH, or only one QOS on that MCH)? - ASN.1 structure aspects [66b#12] LTE: MBMS User Plane (Huawei) discussion to progress any remaining MBMS user plane issue, e.g.: - do we need to extend the LCID space? If so how? - contents/format of the dynamic scheduling MAC CE 12

14 - is there a problem with the PDCCH common search space w.r.t. the notification? RAN2#67 discussion 13

15 3GPP LTE RAN1#57bis (29 Jun 03 July 2009) LA, (5; 2: 1) 1. R , Further Performance Enhancement using Priority Allocation (PA) on codeword-to-layer mapping for dual-layer beamforming, ITRI, RAN1#57b, Posted 2. R , Carrier Identification in PDCCH, ITRI, RAN1#57b, Posted 3. R , Draft Text Proposal on Type I Relay UL Backhaul Subframes in LTE-A, CATT, CMCC, Huawei, ITRI, LGE, Motorola, Nokia, Nokia Siemens Networks, Potevio, Qualcomm, RITT, Samsung, Texas Instruments, ZTE, RAN1#57b, Accepted 4. R , Way forward on PDCCH in LTE-A, Alcatel-Lucent, ASUSTeK, CATT, CEWiT, CHTTL, CMCC, Huawei, Interdigital, ITRI, Motorola, NEC, Nokia, NSN, Panasonic, Philips, Potevio, Qualcomm, RIM, RITT, Samsung, Texas Instruments, Vodafone, RAN1#57b, Posted 5. R , Text proposal to support Type II relay, Alcatel-Lucent, Alcatel-Lucent Shanghai Bell, CATT, CMCC, CHTTL, HTC, InterDigital, ITRI, Qualcomm, RIM, RITT, Vodafone, ZTE, RAN1#57b, Treated 3GPP LTE RAN2#66bis (29 June-3 July 2009) Los Angles, USA (5:3:0) 1. R , Configuration for Carrier Aggregation, ITRI, RAN2#66bis Posted 2. R , An invalid UL grant in RAR, ITRI, RAN2#66bis Treated 3. R , Fast acquisition of system information for inbound handover, ITRI, RAN2#66bis Treated 4. R , Discussion of DRX in carrier aggregation, ITRI, RAN2#66bis Posted 5. R , Simulation results for Blind HARQ transmission on MCH, ITRI, RAN2#66bis Treated 14

3GPP TSG RAN WG1 #56 WG2 #

3GPP TSG RAN WG1 #56 WG2 #65 98 02 06 98 02 15 98 03 24 3GPP TSG RAN1/2 Athens, Greece ITRI TW4G RAN1 RAN2 WGs 3GPP LTE-Advanced ITU-R IMT-Advanced 3GPP LTE-Advanced ITU-R Workshops RAN1 LTE-Advanced 3GPP