UMTS Release 99 corrections from 31st TSG-RAN WG2 meeting
(Arlanda, Sweden, 19 - 23 August 2002)
==========
6 Corrections on Release '99
6.1 Incoming LSs on Release '99
Liaisons on Rel-4 are captured under Agenda Item 8.1, liaisons on Rel-5 under Agenda Item 9.1 and liaisons on Rel-6 under Agenda Item 10.1.
6.1.1 TSG-RAN WG1
R2-021816 (R1-02-1007, copy TSG-RAN WG2) LS on additional reference configuration for 34.108.
Presented by Himke van der Velde from Ericsson.
Discussion:
Decision: The LS was noted.
R2-021821 (R1-02-1016, to TSG-RAN WG2) Response to LS (R2-021753) on Reference configurations in TS 34.108
Presented by Francesco Grilli from Qualcomm. It seems that a CR on 25.331 is submitted for that (Ericsson).
Discussion: What does ‘discontinuous operation mean’ ? Is it up to the UE to decide ? How is it known ?
Ericsson and Qualcomm: There are already some requirements on outer loop, but do they specify everything ?
Denis: Removing the condition is adding requirements on the mobile.
Mony: we should consider the 0 transport block configuration for future releases.
Decision: T1 should add reference configurations.
We will see the CR later.
Ericsson will provide the answer LS to RAN1, RAN4 and T1 when we will have seen the CR. LS in R2-022204.
6.1.2 TSG-RAN WG3
There was no input for this agenda item.
6.1.3 TSG-RAN WG4
R2-022213 (R4-011346, to TSG-RAN-WG2) Liaison Statement on cell identification performance RAN WG4
Presented by Richard Burbidge from Motorola.
Discussion:
Decision: The LS was noted.
R2-022215 (R4-021386) Response to LS (R2-021470) on Rate Adaptation of AMR Codec RAN WG4
Presented by Gairn Kalla from Nokia.
Discussion:
Decision: The LS was noted.
6.1.4 TSG-SA and TSG-SA WGs
R2-021840 (S4-020468, to TSG-RAN WG2) Response to LS (R2-021470) on Rate Adaptation of AMR codec
Presented by Gairn Kalla from Nokia.
Discussion:
Decision: The LS was noted. An LS will be sent to SA4 to clarify the questions, in tdoc R2-02 2423. The coding should be in the SA4 specifications. Then, RAN4 should take it into account.
R2-021841 (S4-020482, to TSG-RAN WG2) LS on QoS parameters Maximum bit rate/Guaranteed bit rate
Presented by Denis Fauconnier (chairman).
Discussion: The power control guarantees the QoS, trying to meet the BLER target. If it is not met, other actions are taken (e.g. handover), but the NAS is not informed.
For Speech, class A bits have all the same BLER target.
Decision: An LS will be drafted to give those answers. There is no real guarantee, this is an operator policy. LS in R2-022205. Drafted by Denis.
6.1.5 TSG-CN and TSG-CN WGs
There was no input under this agenda item.
6.1.6 TSG-T and TSG-T WGs
R2-021913 (T1-020600, to TSG-RAN WG2) Response to LS (R2-021753) on reference configurations in TS 34.108
Presented by Francesco Grilli from Qualcomm.
Discussion:
Decision: The LS was Noted.
R2-021914 (T1-020603, to TSG-RAN WG2) LS on test cases for unsupported UE configuration
Presented by Himke van der Velde from Ericsson.
Discussion: Is is difficult to state when each case apply.
Francesco shares the concern of the unsupported configuration, however this would be a new requirement.
Question on the core specification where the unsupported configuration (according to the capabilities) can be found: this is not specified.
Decision:
- Unsupported: Means in fact ‘which is not according to the UE capabilities’.
- Invalid: This is too late to define every new case. It may be impossible anyway as come cases may be unsupported from a working group and invalid from another one. The added value for the network does not seem too interesting anyway. We may suggest some invalid configurations to T1, but do not define new ones.
An LS will be sent to reflect that, in R2-022206. Francesco will write it.
R2-021915 (T1-020606, to TSG-RAN WG2) Reply to LS (R2-020790) on Layer 2 tests in 34.123.
Presented by Johan Torsner from Ericsson.
Discussion:
For item1, it may be beneficial to mention what is really tested.
For item 6, no need to a particular trigger.
Decision: An LS will be sent to reflect this. Written by Johan in R2-022207.
R2-021916 (T1-020607, to TSG-RAN WG2) LS on change to the UL:8 DL:8 kbps PS transport channel configuration
Presented by Claudiu Mihailescu from Nortel Netwroks.
Discussion:
This is widening the test case coverage.
The ‘consequence if not approved’ may not be up to date.
We should try to keep those test cases stable. Changes should be done only if essential.
Decision:
Generally, TS 34.108 has various uses and RAN WG2 is wondering for how long new configurations should be added.
An LS will be sent to RAN1 to say that RAN2 has no technical problem with this CR.
The final decision will go to RAN1. LS in R2-022208. The CR itself is revised in R2-021902.
6.1.7 TSG-GERAN and TSG-GERAN WGs
There was no input for this agenda item.
6.1.8 ITU-R/ITU-T
There was no input for this agenda item.
6.1.9 GSMA TWG
R2-021865 (TWG 195_02, to TSG RAN WG2) LS on unclear standardisation of an AT command in TS 27.007
Presented by Axel Klatt from T-Mobile.
The proposal from T-Mobile would be to remove the command from the specification.
Discussion: We will delete number 22 and the complete AT command from the 3GPP specifications.
Decision: LS in R2-022221, written by Axel. Copy to T, T2 and GERAN2.
6.2 General decisions
6.2.1 Outcome of RAN2#30 (R'99)
R2-021844 CR-list and CRs agreed at WG2 meeting #30 Torino, Italy, 24 - 27 June 2002 (Secretary)
This document list all change requests agreed at RAN WG2#30.
The two following CRs are shadows of R2-021709 agreed at RAN2#30 (as shadows were not provided there):
R2-022180 Proposed CR 1536 to 25.331 (Rel-4 shadow of the RAN2#30 CR 1535) on Clarifications for Quality Measurements TTPCom, Nortel Networks
R2-022181 Proposed CR 1537 to 25.331 (Rel-5 shadow of the RAN2#30 CR 1535) on Clarifications for Quality Measurements TTPCom, Nortel Networks
Presented by Will Powell from TTPCom.
Discussion:
Decision:
Agreed on Monday. However, later on during the week, off-line comments were received and those documents R2-021709, R2-022180 and R2-022181 were revised into R2-022334, R2-022335 and R2-022336 (CR 1535r1, 1536r1 and 1537r1).
R2-022334 Proposed CR 1535r1 to 25.331 (R'99) on Clarifications for Quality Measurements TTPCom, Nortel Networks
R2-022335 Proposed CR 1536r1 to 25.331 [Rel-4 shadow] on Clarifications for Quality Measurements TTPCom, Nortel Networks
R2-022336 Proposed CR 1537r1 to 25.331 [Rel-5 shadow] on Clarifications for Quality Measurements TTPCom, Nortel Networks
Presented by Will Powell from TTPCom.
Discussion:
Decision: The CRs are agreed.
From the R'99 CRs in the list in R2-021844, the following CRs are revised:
R2-021693, R2-021694 and R2-021695
R2-021690, R2-021691 and R2-021692
R2-021706, R2-021599 and R2-021600
R2-021716, R2-021717 and R2-021718.
They will be treated under agenda item 6.13.
6.2.2 General decisions
R2-021854 Introduction of Extension Container mechanism in ASN.1 Nokia
Presented by Gairn Kalla from Nokia. A technical solution is proposed.
Discussion:
Do RAN2 agree to solve it ?
Do RAN2 agree to solve it with this solution ?
And for which release ?
The proposal is in a non-critical extension.
Francesco: What is the benefit for the R’99 ?
Denis: At a point of time, some R’99 mobiles may support or not support the change.
Francesco: This idea was already discussed in the past, and it was decided that a strong need should be demonstrated.
Francesco: Drawbacks are bigger messages. Also this mechanism would allow to add R’99 changes far away in the future, which is not advisable.
Gairn: The cost is 0 bits for the R’99.
Denis: There is no impact on the current implementation.
Gairn: It is immediately after the R’99 bits, in a bit string, on purpose so that it does not impact the current R’99 implementation. A Length field specifies the length of this container.
Vincent (Belaiche): Another solution is to have it under the non-critical extension of the Rel-4.
Denis: But if used, then you would need to change the R’99.
What is the most acceptable extension mechanism, should it be required ?
This one is backward compatible and also allows the future.
It costs nothing until we use it, in fact does not change the current implementation. In the Rel-4, the bits will have to be skipped.
If we do not use it, we increase the level of the non-critical extension by 1 in the Rel-4, so we add one bit in the Rel-4 (the presence bit of the bit string).
Hence, this change is not backward compatible for the Rel-4.
This would be for all non-critical extensions in the Rel-4 (there are not many).
Question: Are any extra error handling cases been considered for this introduction (e.g. when the recursive structure of the container makes that it is longer than the overall length indicated).
Answer: The PER decoder rule is not fulfilled and there are already some rules for that. Also the end of the message can be discarded, such as today.
However, the receiver has to continue the reading of the information this time (this is not a complete end). Some additional rules may be added.
Decision:
RAN WG2 has a mechanism for the extension, impacting the Rel-4.
The mechanism is technically correct but it is expensive so we should not use it yet.
Rel-4 should not be totally frozen until this becomes very important.
R2-021856 Proposed CR to 25.301 [R'99] on Bi-directional radio bearers Siemens
The document was withdrawn before presentation.
R2-021920 Increase efficient use of Air Interface through reduced use of 15 bit LI Nokia
Presented by Kairn Kalla from Nokia.
Discussion:
Decision:
This could be part of the Contributions on the enhancements for the Rel-5 instead.
A CR on 25.331 (1548) will be proposed for the Rel-5 (in tdoc R2-022216).
R2-021942 Issue on RB2 HFN initialization during SRNS relocation ASUSTeK
Presented by Richard Kuo ASUSTeK.
Discussion:
Decision: Questions were asked. We may come-back on it during the week. The document was noted.
R2-021991 Proposed (alternative) CRs to 25.331 [R'99] on Reception of MEASUREMENT CONTROL in state CELL_FACH TTPCom
R2-021992 Proposed (alternative) CRs to 25.331 [Rel-4 shadow] on Reception of MEASUREMENT CONTROL in state CELL_FACH TTPCom
R2-021993 Proposed (alternative) CRs to 25.331 [Rel-5 shadow] on Reception of MEASUREMENT CONTROL in state CELL_FACH TTPCom
Presented by Will Powell from TTPCom.
2 alternatives: Clear the Cell info list when leaving cell dch, or maintain a second cell info list.
Discussion:
Question: On the first issue, why did you not leave open to the UE ?
Answer: This would be another possibility.
Question: On the first issue, are you proposing additional measurements ?
Answer: Update of the proposal is possible. Additional measurements are disallowed in the proposal.
Additional traffic volume measurements would not really be justified.
The current text of not having the cell info list has been here for a long time. It, however, may have been interpreted differently.
Which cell info list do you clear on cell reselection ?
There may be two different readings of the specification.
Decision: People will check home. We will come-back on it.
R2-022413 Proposed CR to 25.331 [R'99] on Reception of MEASUREMENT CONTROL in state CELL_FACH TTPCom
R2-022414 Proposed CR to 25.331 [Rel-4 shadow] on Reception of MEASUREMENT CONTROL in state CELL_FACH TTPCom
R2-022415 Proposed CR to 25.331 [Rel-5 shadow] on Reception of MEASUREMENT CONTROL in state CELL_FACH TTPCom
Presented by Will Powell from TTPCom.
Discussion:
This is the issue on 1 or 2 cell info list.
Decision: Agreed into R2-022427, 02 2428 and 2429. CRs 1674, 1675 and 1676.
R2-022068 Discussion on ASC Parameters Qualcomm
Presented by Hector Vayanos from Qualcomm.
Discussion:
The first one does not justify a correction.
For the second one (the note): What if some UEs do not support the correction ? Is it so costly ?
Tim S.: In 25.321 (MAC), Access Class 0 is forbidden.
Denis: Then 8 cannot be used.
Hector: MAC has no idea on the RAB being used.
If the change is not approved, Access Class 0 will only be used for RRC connection request for emergency services.
Without the change, 7 Access Class values can be used, instead of 8.
Decision:
Network manufacturers have to be aware of the limitation. 7 Access Class values can be used, instead of 8.
R2-022098 Handling of Integrity Protection Mode Info errors Nokia
Presented by Gairn Kalla from Nokia. This is consistent with the current behaviour of the integrity ptotection.
Discussion:
Francesco: What should be in the CR ?
Answer: ‘The UE may discard it’.
Question: For the RRC sequence numbers, do you increment them when you discard the message ?
Answer: You do not treat this sequence number as having being received, so no.
Question: Did you check the S3 requirements (e.g. ‘man in the middle’ scenario ?). Would it not be better if it was visible to the network ?
Answer: S3 requirements are that you should not change the UE state neither send a messaqe.
Comment: There is already a requirement saying that ‘If such a security mode is received the UE should put the invalid configuration to TRUE and not send the message’. This may conflict.
Answer: An ‘either or’ may solve the problem.
Question: What is the current behaviour ? Do we have a problem, or additional complexity in the UE ?
Answer: Additional complexity, but also in 2.1 it is not totally clear how the UE should behave.
Decision: This does not look like a correction.
R2-022144 Proposed CR to 25.331 [R'99] on Nested Cell Updates and SRNS Relocation Motorola
R2-022145 Proposed CR to 25.331 [Rel-4 shadow] on Nested Cell Updates and SRNS Relocation Motorola
R2-022146 Proposed CR to 25.331 [Rel-5 shadow] on Nested Cell Updates and SRNS Relocation Motorola
Presented by Ravi.
Discussion: We will come-back to this document. Motorola will provide more information on the CR on Tuesday.
The CR on R’99 was revised into R2-02 2222 (agenda item 6.13).
R2-022151 Proposed CR to 21.905 [R'99] on Correction of the definition of the term Active Set Philips
R2-022152 Proposed CR to 21.905 [Rel-4 shadow] on Correction of the definition of the term Active Set Philips
R2-022153 Proposed CR to 21.905 [Rel-5 shadow] on Correction of the definition of the term Active Set
Presented by Christoph Hermann from Philips.
Discussion: Is there a reason to change this definition ? This is also not in line with HS-DSCH.
Other groups would have to be consulted.
Decision: No change was needed. |
