3GPP TSG-WG2 Meeting #18
`Edinburgh, Scotland, 17th-19th January 2001
`
`
`Agenda Item:
`
`6.1
`
`Source:
`
`Title:
`
`Mitsubishi Electric Telecom (Trium R&D)1
`
`Corrections to logical channel priorities in MAC protocol
`
`
`
`Document for:
`
`Discussion & Decision
`
`
`
`
`
`
`Introduction
`
`R2-010182
`
`
`
`This discussion paper and its attached draft CR propose introduction of new parameters given by the
`network to UE for MAC TFC selection. These parameters MinGBr : Min Guaranted Bit rate, MaxBr :
`Max Guaranted Bit rate, TW : Time Window, will complete the current MLP for representing Logical
`channels priorities.
`
`References
`
`[1] 3GPP TS 25.321 version 3.4.0, “MAC protocol specifications”, September 2000
`
`[2] R2-001000, “Clarification on Prioritisation of Logical Channels in UE”, May 2000
`
`[3] R2-001270, “CR 044r2 to TS 25.331 clarification of prioritisation of logical channels in UE”, May 2000
`
`[4] R2-001587, “CR 050 to TS 25.331 clarification of prioritisation of logical channels in UE”, August 2000
`
`[5] R2-001838, “ Corrections to relative priorities in MAC Protocol”, August 2000
`
`[6] 3GPP SA 23.107 version 3.4.0, “QoS concept and architecture”, October 2000
`
`
`
`Discussion
`
`It was previously shown during e-mail, physical discussions and in document [2] that the current algorithm
`proposed for TFC selection in MAC is not satisfying because of its absolute priority scheme. It could lead to
`exclusion of some logical channels for transmission in case some TFC become unvalid.
`
`Moreover, attributes such as Maximum bitrate, Guaranteed bitrate defined by TSG SA in [6], are specifying
`requirements for UMTS bearer service and radio bearer service. They could easily be derived to calculate
`equivalent parameters at MAC level.
`
`It was admitted that a relative priority scheme would improve TFC selection efficiency. Some new parameters
`were proposed (MaxLoss in first round [3], [4] and then BW [5]), but no one was able to present a simple
`algorithm to implement them. These solutions were left aside.
`
`We think that three main problems occur in the present scheme :
`
`- There is only one way to represent the quality of service at logical channel level (MLP). This parameter
`ranging from 1 to 8 is not sufficient to characterise all the applications foreseen for UMTS.
`
`
`1 Contact person :
`Ludovic Tancerel
`e-mail: ludovic.tancerel@trium-rd.com
`tel. : +33 2 99 27 47 70 (switchboard)
`
`BLACKBERRY 1008
`
`

`

`-
`
`Priority are absolute. Logical channels of higher MLP can never preempt lower MLP logical channels and
`thus may be systematically prevented by them from transmitting
`
`- MAC (by the mean of TFC selection algorithm) is not informed of the past of its transmission (currently,
`TFC selection is instantaneous)
`
`Our conclusion is that the MLP is not enough to implement a relative priority scheme. We propose to introduce
`3 new parameters completing MLP to express accurately the needs of different applications in term of bit rate.
`
`The parameters we propose are :
`
`TW : Time window. It is the time period on which the allocated bit rate for the logical channel is estim
`
`ated. It is a number of TTI.
`
`MinGBr : Min guaranted bit rate. It is the basic needs of the logical channel. This amount will be transmitted
`with an absolute priority scheme. Its unit is in Bits/TW
`
`MaxBr : Max bit rate. It represents the nominal needs of the logical channel. This amount will be transmitted
`when the MinGBr has been allocated to all the logical channels. Its unit is in Bits/TW.
`
`The main idea is first to have a time measure of the data allocated in the previous TTI. This was missing in the
`previous proposals.
`
`The principle of the current “absolute priority” algorithm is kept, but instead of trying to “maximise the
`transmission of high priority data “, we make three steps, where in the first step, we try to reach the MinGBr
`for each logical channel in the descending order of priority. When all the logical channels have been served,
`we go to the second step where we try to reach the MaxBr for each logical channel in the descending order of
`priority. The last step is to serve the logical channels which still have remaining data (best effort), still in the
`descending order of priority.
`
`This solution is able to solve the problems encountered in the absolute priority scheme. It also gives the
`possibility to the network to decide of the behaviour of the UE, relative to its global policy. The solution
`increases the complexity compared to the current TFC selection algorithm, but it is not very much more
`complex because the treatment is a function of the number of valid TFC, and this number decreases as the
`algorithm is progressing.
`
`A configuration of the new parameters of the proposed solution with a time window TW of a single TTI would
`give the same behaviour as the current scheme. So there is no regression, only additional capability here.
`
`The resulting changes in other specs (3G TS 25.331) will be proposed further.
`
`In the example below : 2 logical channels are considered, mapped on two different transport channels.
`
`The parameters for the logical channels are :
`
`
`
`LC1 LC2
`
`MLP
`
`TW(TTI)
`
`1
`
`3
`
`2
`
`4
`
`MinGBr
`
`100
`
`100
`
`MaxBr
`
`200
`
`200
`
`The set of valid TFC is as follows :
`
`TFCI TrCH 1 TrCH 2
`
`0
`
`1
`
`0100
`
`0100
`
`1100
`
`0100
`
`
`
`
`
`2
`
`

`

`2
`
`0100
`
`1100
`
`
`
`TrCH 1 and TrCH 2 have the same TTI.
`
`In absolute priority scheme, TrCH2 will transmit only when LC1 has no data.
`
`The way the allocated bit rate is computed in the exemple is the following. It is the bit rate allocated to the
`LgCH in the TW-1 previous TTI.
`
`TW
`
`TTIk-Ft+1
`
`...
`
`TTIk-1
`
`TTIk
`
`(Nk-Ft+1 x BSk-Ft+1 )
`
`(Nk-1 x BSk-1 )
`
`??
`
`In our scheme, if both logical channels always have data to transmit, the TFCI will be the following. The
`allocated bit rate is computed before the TFC selection.
`
`
`
`TTI
`
`0
`
`1
`
`2
`
`3
`
`4
`
`5
`
`6
`
`
`
`TrCH1
`
`TrCH2
`
`TFCI
`
`Allocated Bit Rate
`
`Data transmitted
`
`Allocated Bit Rate
`
`Data transmitted
`
`0
`
`100
`
`100
`
`100
`
`200
`
`100
`
`100
`
`1  100
`
`0  100
`
`1  100
`
`1  100
`
`0  100
`
`1  100
`
`1  100
`
`0
`
`0
`
`100
`
`100
`
`100
`
`100
`
`100
`
`0  100
`
`1  100
`
`0  100
`
`0  100
`
`1  100
`
`0  100
`
`0  100
`
`
`
`
`
`1
`
`2
`
`1
`
`1
`
`2
`
`1
`
`1
`
`
`
`3
`
`

`

`
`
`
`
`
`
`CHANGE REQUEST
`
`CR-Form-v3
`
`
`
`25.321 CR XXX
`
` rev
`
`
`
`-  Current version: 3.6.0
`For HELP on using this form, see bottom of this page or look at the pop-up text over the  symbols.
`
`(U)SIM
`
`
`
`ME/UE X Radio Access Network X Core Network
`
`
`Proposed change affects: 
`
` Corrections to logical channel priorities in MAC protocol
`Title:
`
`
` Trium R&D
`Source:
`
`
`Work item code: 
`
`
` C
`Category:
`
`
`Use one of the following categories:
`F (essential correction)
`A (corresponds to a correction in an earlier release)
`B (Addition of feature),
`C (Functional modification of feature)
`D (Editorial modification)
`Detailed explanations of the above categories can
`be found in 3GPP TR 21.900.
`
`
`
`
`
`
`
`Date:  15 jan 2001
`
`
`
`
`
`
`Release: 
`
`Use one of the following releases:
`2
`(GSM Phase 2)
`R96
`(Release 1996)
`R97
`(Release 1997)
`R98
`(Release 1998)
`R99
`(Release 1999)
`REL-4
`(Release 4)
`(Release 5)
`REL-5
`
`
`
`Reason for change:  Current algorithm specified in 11.4 is unsatisfying because of its absolute priority
`scheme
`
`
`Summary of change: 
`
`
`
`
`Consequences if 
`not approved:
`
`
`
`
`
`Introduction of new parameters to characterise MAC logical channels for TFC
`selection. Modification of the current algorithm to take into account these new
`parameters
`
` Current scheme would go on allowing complete blocking of a logical channel
`by a higher priority one
` SA 23.107 requirements will not be fully satisfied.
`
`
`
`Clauses affected:  11.4
`
`
`Other specs
`affected:
`
`
`
`Other comments:  25.331 is affected by the introduction of the signalling of the new parameters.
`modifications will be proposed later.
`
`
`
`
`
`
`
` Other core specifications
` Test specifications
` O&M Specifications
`
`
`
`
`
`
`
`
`
`CR page 4
`
`Commented [H1]: Enter the specification number in this
`box. For example, 04.08 or 31.102. Do not prefix the number
`with anything . i.e. do not use "TS", "GSM" or "3GPP" etc.
`Commented [H2]: Enter the CR number here. This
`number is allocated by the 3GPP support team.
`Commented [H3]: Enter the revision number of the CR
`here. If it is the first version, use a "-".
`Commented [H4]: Enter the version of the specification
`here. This number is the version of the specification to which
`the CR will be applied if it is approved. Make sure that the
`lastest version of the specification (of the relevant release) is
`used when creating the CR. If unsure what the latest version
`is, go to http://www.3gpp.org/3G_Specs/3G_Specs.htm
`Commented [H5]: For help on how to fill out a field,
`place the mouse pointer over the special symbol closest to
`the field in question.
`Commented [H6]: Mark one or more of the boxes with an
`X.
`Commented [H7]: Enter a concise description of the
`subject matter of the CR. It should be no longer than one
`line.
`Commented [H8]: Enter the source of the CR. This is
`either (a) one or several companies or, (b) if a (sub)working
`group has already reviewed and agreed the CR, then list the
`group as the source.
`Commented [H9]: Enter the acronym for the work item
`which is applicable to the change. This field is mandatory for
`category F, B & C CRs for release 4 and later. Work item
`acronyms are listed in the 3GPP work plan. See
`http://www.3gpp.org/ftp/information/work_plan/
`Commented [H10]: Enter the date on which the CR was
`last revised.
`Commented [H11]: Enter a single letter corresponding to
`the most appropriate category listed below. For more
`detailed help on interpreting these categories, see the
`Technical Report 21.900 "3GPP working methods".
`Commented [H12]: Enter a single release code from the
`list below.
`Commented [H13]: Enter text which explains why the
`change is necessary.
`Commented [H14]: Enter text which describes the most
`important components of the change. i.e. How the change is
`made.
`Commented [H15]: Enter here the consequences if this
`CR was to be rejected. It is necessary to complete this
`section only if the CR is of category "F" (i.e. essential
`correction).
`Commented [H16]: Enter each the number of each clause
`which contains changes.
`Commented [H17]: Enter an X in the box if any other
`specifications are affected by this change.
`Commented [H18]: List here the specifications which are
`affected or the CRs which are linked.
`Commented [H19]: Enter any other information which
`may be needed by the group being requested to approve the
`CR. This could include special conditions for it's approval
`which are not listed anywhere else above.
`
`4
`
`

`

`3GPP TS 25.321 v3.6.0 (2000-12)
`
`CR page 5
`
`11.4
`
`Transport format combination selection in UE
`
`RRC can control the scheduling of uplink data by giving a priority value between 1 and 8 for each logical channel
`where 1 is the highest priority and 8 the lowest, a Time window TW (expressed in number of TTI) on which the
`allocated bit rate is computed, a Minimum Guaranteed bit rate MinGBr and a Maximum bit rate (both expressed in
`bit/TW). The selection of TFC in the UE shall be done according to the priorities between logical channels indicated by
`RRC. Logical channels have absolute relative priorityies i.e.the UE shall maximize the transmission of high priority
`data allocate the Minimum guaranteed bit rate to each logical channel by serving them in descending order of priority, it
`will then allocate the Maximum bit rate to each logical channel by serving them in descending order of priority. If there
`is still available capacity, the remaining data will be transmitted by serving the logical channels in descending order of
`priority.
`
`The scheme is performed each time a TFC selection is performed, i.e., each time the shortest configured TTI begins.
`
`Consider the priorities N1..N2 (N2>N1) where data is available for transmission at the time the TFC selection is
`performed. Let S1 and S2 be sets of TFCs.
`
`1. Let S2 be the set of all TFCs in the TFCS that can be supported at the current UE maximum transmitter power.
`
`2.
`
`Iteration ITER = 1
`
`2.3. Priority N = N1.
`
`4. Set S1 = S2.
`
`5. If S1 contains one single TFC, select this TFC and end the procedure.
`
`6. Case ITER of :
`
`7.
`
`
`
`If ITER = 1 :
`
`Let S2 be the set of all TFCs in S1 that allow the minimal amount of available priority N data bits to be
`transmitted such as MinGBr is guranteed. Go to step 10.
`
`8.
`
`
`
`If ITER = 2 :
`
`6. Let S2 be the set of all TFCs in S1 that allow the remaining amount of available priority N data bits
`to be transmitted such as MaxBr is not exceeded. Go to step 10.
`
`9.
`
`
`
`If ITER = 3 :
`
`9. Let S2 be the set of all TFCs in S1 that allow the highest remaining amount of available priority N
`data bits to be transmitted.
`
`10. End of case
`
`11. N = N + 1.
`
`10.12. If N>N2, then ITER = ITER+1 and Priority N = N1
`
`12. If N ITER > N23, select anyone of the TFCs in S2 and end the procedure.
`
`813. Go back to step 34.
`
`The above rules for TFC selection in the UE shall apply to DCH, and the same rules shall apply for TF selection on
`RACH and CPCH.
`
`When the UE output power is approaching the UE maximum transmit power and the inner loop for power control can
`no longer be maintained for coverage reasons, the UE shall adapt to the TFC corresponding to the next lower bit rate,
`i.e. the TFC with the present total bit rate shall not be used. If the bit rate of a logical channel carrying data from a
`codec supporting variable-rate operation is impacted, the codec data rate shall be adopted accordingly.
`
`The UE shall continuously estimate whether the maximum transmitter power is sufficient to support the temporarily
`blocked TFC. When the maximum transmitter power is sufficient, the temporarily blocked TFC shall again be
`considered in the TFC selection.
`
`CR page 5
`
`Formatted: Bullets and Numbering
`
`Formatted: Bullets and Numbering
`
`Formatted: Bullets and Numbering
`
`Formatted: Bullets and Numbering
`
`Formatted: Bullets and Numbering
`
`Formatted: Bullets and Numbering
`
`Formatted: Bullets and Numbering
`
`5
`
`

`

`3GPP TS 25.321 v3.6.0 (2000-12)
`
`CR page 6
`
`The maximum UE power is defined in [25.331].
`
`
`
`CR page 6
`
`6
`
`