3GPP - LTE - MAC层协议36321-870(Release8) - 图文 联系客服

发布时间 : 星期一 文章3GPP - LTE - MAC层协议36321-870(Release8) - 图文更新完毕开始阅读d0d0fe8da0116c175f0e480f

Release 8 29 3GPP TS 36.321 V8.7.0 (2009-09)

NOTE:

A UE may optionally choose to not send CQI/PMI/RI reports on PUCCH and/or SRS transmissions for

up to 4 subframes following a PDCCH indicating a new transmission (UL or DL) received in the last subframe of active time. The choice not to send CQI/PMI/RI reports on PUCCH and/or SRS transmissions is not applicable for subframes where onDurationTimer is running.

5.8 MAC reconfiguration

When a reconfiguration of the MAC entity is requested by upper layers, the UE shall: - for timers apply the new value when the timer is (re)started;

- when counters are initialized apply the new maximum parameter value;

- for other parameters, apply immediately the configurations received from upper layers.

5.9 MAC Reset

If a reset of the MAC entity is requested by upper layers, the UE shall: - initialize Bj for each logical channel to zero; - stop (if running) all timers;

- consider timeAlignmentTimer as expired and perform the corresponding actions in subclause 5.2; - set the NDIs for all uplink HARQ processes to the value 0; - stop, if any, ongoing RACH procedure;

- discard explicitly signalled ra-PreambleIndex and ra-PRACH-MaskIndex, if any; - flush Msg3 buffer;

- cancel, if any, triggered Scheduling Request procedure; - cancel, if any, triggered Buffer Status Reporting procedure; - cancel, if any, triggered Power Headroom Reporting procedure; - flush the soft buffers for all DL HARQ processes;

- for each DL HARQ process, consider the next received transmission for a TB as the very first transmission; - release, if any, Temporary C-RNTI.

5.10 Semi-Persistent Scheduling

When Semi-Persistent Scheduling is enabled by RRC, the following information is provided [8]: - Semi-Persistent Scheduling C-RNTI;

- Uplink Semi-Persistent Scheduling interval semiPersistSchedIntervalUL and number of empty transmissions before implicit release implicitReleaseAfter, if Semi-Persistent Scheduling is enabled for the uplink; - Whether twoIntervalsConfig is enabled or disabled for uplink, only for TDD;

- Downlink Semi-Persistent Scheduling interval semiPersistSchedIntervalDL and number of configured HARQ processes for Semi-Persistent Scheduling numberOfConfSPS-Processes, if Semi-Persistent Scheduling is enabled for the downlink; When Semi-Persistent Scheduling for uplink or downlink is disabled by RRC, the corresponding configured grant or configured assignment shall be discarded.

3GPP

Release 8 30 3GPP TS 36.321 V8.7.0 (2009-09)

5.10.1 Downlink

After a Semi-Persistent downlink assignment is configured, the UE shall consider that the assignment recurs in each subframe for which:

- (10 * SFN + subframe) = [(10 * SFNstart time + subframestart time) + N * semiPersistSchedIntervalDL] modulo 10240, for all N>0. Where SFNstart time and subframestart time are the SFN and subframe, respectively, at the time the configured downlink assignment were (re-)initialised.

5.10.2 Uplink

After a Semi-Persistent Scheduling uplink grant is configured, the UE shall: - if twoIntervalsConfig is enabled by upper layer: - set the Subframe_Offset according to Table 7.4-1. - else:

- set Subframe_Offset to 0.

- consider that the grant recurs in each subframe for which:

- (10 * SFN + subframe) = [(10 * SFNstart time + subframestart time) + N * semiPersistSchedIntervalUL + Subframe_Offset * (N modulo 2)] modulo 10240, for all N>0. Where SFNstart time and subframestart time are the SFN and subframe, respectively, at the time the configured uplink grant were (re-)initialised.

The UE shall clear the configured uplink grant immediately after implicitReleaseAfter [8] number of consecutive new MAC PDUs each containing zero MAC SDUs have been provided by the Multiplexing and Assembly entity, on the Semi-Persistent Scheduling resource. NOTE:

Retransmissions for Semi-Persistent Scheduling can continue after clearing the configured uplink grant.

5.11

Handling of unknown, unforeseen and erroneous protocol data

When a MAC entity receives a MAC PDU for the UE’s C-RNTI or Semi-Persistent Scheduling C-RNTI, or by the configured downlink assignment, containing reserved or invalid values, the MAC entity shall: - discard the received PDU.

6

6.1

6.1.1

Protocol Data Units, formats and parameters

Protocol Data Units

General

A MAC PDU is a bit string that is byte aligned (i.e. multiple of 8 bits) in length. In the figures in subclause 6.1, bit

strings are represented by tables in which the most significant bit is the leftmost bit of the first line of the table, the least significant bit is the rightmost bit on the last line of the table, and more generally the bit string is to be read from left to right and then in the reading order of the lines. The bit order of each parameter field within a MAC PDU is represented with the first and most significant bit in the leftmost bit and the last and least significant bit in the rightmost bit. MAC SDUs are bit strings that are byte aligned (i.e. multiple of 8 bits) in length. An SDU is included into a MAC PDU from the first bit onward.

3GPP

Release 8 31 3GPP TS 36.321 V8.7.0 (2009-09)

The UE shall ignore the value of Reserved bits in downlink MAC PDUs.

6.1.2

MAC PDU (DL-SCH and UL-SCH except transparent MAC and

Random Access Response)

A MAC PDU consists of a MAC header, zero or more MAC Service Data Units (MAC SDU), zero, or more MAC control elements, and optionally padding; as described in Figure 6.1.2-3. Both the MAC header and the MAC SDUs are of variable sizes.

A MAC PDU header consists of one or more MAC PDU subheaders; each subheader corresponds to either a MAC SDU, a MAC control element or padding.

A MAC PDU subheader consists of the six header fields R/R/E/LCID/F/L but for the last subheader in the MAC PDU and for fixed sized MAC control elements. The last subheader in the MAC PDU and subheaders for fixed sized MAC control elements consist solely of the four header fields R/R/E/LCID. A MAC PDU subheader corresponding to padding consists of the four header fields R/R/E/LCID.

RFRELLCIDOct 1Oct 2RFRELLLCIDOct 1Oct 2Oct 3R/R/E/LCID/F/L sub-header with 7-bits L fieldR/R/E/LCID/F/L sub-header with 15-bits L field

Figure 6.1.2-1: R/R/E/LCID/F/L MAC subheader

RRELCIDOct 1R/R/E/LCID sub-header

Figure 6.1.2-2: R/R/E/LCID MAC subheader

MAC PDU subheaders have the same order as the corresponding MAC SDUs, MAC control elements and padding. MAC control elements are always placed before any MAC SDU.

Padding occurs at the end of the MAC PDU, except when single-byte or two-byte padding is required. Padding may have any value and the UE shall ignore it. When padding is performed at the end of the MAC PDU, zero or more padding bytes are allowed.

When single-byte or two-byte padding is required, one or two MAC PDU subheaders corresponding to padding are placed at the beginning of the MAC PDU before any other MAC PDU subheader. A maximum of one MAC PDU can be transmitted per TB per UE.

3GPP

Release 8 32 3GPP TS 36.321 V8.7.0 (2009-09)

R/R/E/LCID sub-headerR/R/E/LCIDsub-headerR/R/E/LCID/F/L sub-headerR/R/E/LCID/F/L sub-header...R/R/E/LCID/F/L sub-headerR/R/E/LCID padding sub-headerMAC headerMAC Control MAC Control element 1element 2MAC SDU ...MAC SDU Padding (opt)MAC payload

Figure 6.1.2-3: Example of MAC PDU consisting of MAC header, MAC control elements, MAC SDUs

and padding

6.1.3

6.1.3.1

MAC Control Elements

Buffer Status Report MAC Control Elements

Buffer Status Report (BSR) MAC control elements consist of either:

- Short BSR and Truncated BSR format: one LCG ID field and one corresponding Buffer Size field (figure 6.1.3.1-1); or - Long BSR format: four Buffer Size fields, corresponding to LCG IDs #0 through #3 (figure 6.1.3.1-2). The BSR formats are identified by MAC PDU subheaders with LCIDs as specified in table 6.2.1-2. The fields LCG ID and Buffer Size are defined as follow:

- LCG ID: The Logical Channel Group ID field identifies the group of logical channel(s) which buffer status is being reported. The length of the field is 2 bits; - Buffer Size: The Buffer Size field identifies the total amount of data available across all logical channels of a logical channel group after the MAC PDU has been built. The amount of data is indicated in number of bytes. It shall include all data that is available for transmission in the RLC layer and in the PDCP layer; the definition of what data shall be considered as available for transmission is specified in [3] and [4] respectively. The size of the RLC and MAC headers are not considered in the buffer size computation. The length of this field is 6 bits. The values taken by the Buffer Size field are shown in Table 6.1.3.1-1.

LCG IDBuffer SizeOct 1

Figure 6.1.3.1-1: Short BSR and Truncated BSR MAC control element

Buffer Size #0Buffer Size #1Buffer Size #2Buffer Size #1Buffer Size #2Oct 1Oct 2Oct 3Buffer Size #3

Figure 6.1.3.1-2: Long BSR MAC control element

3GPP