BSSB9 Description UL EGPRS Resel EGSM

All rights reserved.
Passing on and copying of this document, use and communication of its contents not permitted without written authorization from Evolium.
Site VELIZY Originators S. Garcia System Sub-system Document Category : : : ALCATEL GSM BSS PCS - BSS B9 Description
ABSTRACT
This document gives an overview of part of B9 features : Enhanced support of E-GPRS in UL (8-PSK in UL and IR in UL), Extended UL TBF mode, Enhanced Packet Cell Reselection, Enhanced E-GSM band Handling, Improved 3G Cell reselection Approvals Name App.
HISTORY
Ed. 01 Proposal 01 2005/07/01 First Proposal
ED 01 Proposal 1
138124182.doc 03/07/2005
PCS BSS B9 Description PCS/GSM/2005-07001 1/79
All rights reserved. Passing on and copying of this document, use and communication of its contents not permitted without written authorization from Evolium.
TABLE OF CONTENTS
TABLE OF CONTENTS.................................................................................................................................. 2 1 INTRODUCTION........................................................................................................................................... 4 2 ENHANCED SUPPORT OF E-GPRS IN UL................................................................................................. 5 3 EXTENDED UL TBF MODE (PART OF MS GERAN FEATURE PACKAGE 1)....................................17 4 ENHANCED PACKET CELL RESELECTION............................................................................................ 42 5 ENHANCED E-GSM BAND HANDLING..................................................................................................... 54 6 IMPROVED 3G CELL RESELECTION TO BE COMPLETED................................................................60 7 ANNEX A 3GPP 44060............................................................................................................................ 61 8 ANNEX B 3GPP 48018............................................................................................................................ 68 9 ANNEX C 3GPP 24008............................................................................................................................ 70
ED 01 Proposal 1
138124182.doc 03/07/2005
INTERNAL REFERENCED DOCUMENTS

Not applicable
REFERENCED DOCUMENTS
Alcatel references [1] [2] [4] [5] [6] [7] [8] 3BK 10204 0606 DTZZA 3BK 10204 0607 DTZZA 3BK 10204 0610 DTZZA 3BK 10204 0611 DTZZA 3BK 10204 0612 DTZZA 3BK 11202 0391 DSZZA 3BK 11202 0392 DSZZA SFD: Enhanced Packet cell reselection SFD: Extented UL TBF mode SFD : Enhanced Support of E-GPRS in UL SFD : Improved 3G cell reselection SFD : Enhanced E-GSM band handling (E)GPRS Radio Interface RRM sub-mayer (PCC) Ed3 (E)GPRS Radio Interface RLC Sub-layer Ed3
RELATED DOCUMENTS PREFACE
ED 01 Proposal 1
138124182.doc 03/07/2005
1 1.1
INTRODUCTION Scope
The present document aims to describe a part of new B9 features. It is an overview of the new features and their description needs to be enhanced with more details. This will be done in a further edition of the document. Furthermore some issues are highlighted and will be solved in next edition of the document. The list of features described in this document is presented here after: 1.1.1 1.1.2 1.1.3 1.1.4 1.1.5 Enhanced Support of E-GPRS in UL (See chapter 2) Extended UL GPRS mode (See Chapter 3) Enhanced Packet cell reselection (See Chapter 4) Enhanced E-GSM band handling (See Chapter 5) Improved 3G cell Reselection (See Chapter 6)
ED 01 Proposal 1
138124182.doc 03/07/2005
ENHANCED SUPPORT OF E-GPRS IN UL
Aim of the feature: - Increase of maximum throughput in UL (8-PSK in UL from MCS5 to MCS9 also described in SFD [4]) - Increase Coverage in UL (increase the maximum user throughput when the mobile is a the border of a cell using incremental redundancy feature in UL; expected improvement: gain of 15%)
2.1
Introduction (sub-features)
This feature is part of EGPRS package (sold to operator with EGPRS feature). It is divided in two sub features: Support of 8-PSK in UL (See Chapter 2.2) Support of Incremental Redundancy in UL (See Chapter 2.3)
Feature 8-PSK in UL is enhanced by feature Statistical Multiplexing Feature Incremental Redundancy in UL requires Statistical Multiplexing (it will be easier to support the MFS <-> BTS signalling messages: TBF_OPEN_REQUEST, TBF_CLOSE_REQUEST, TBF_OPEN_CONFIRM and TBF_CLOSE CONFIRM messages. Otherwise theses messages should preempt other messages or should be inserted in holes).
Open issue: To be checked if the modification of TBF allocation due to the management of 8-PSK in UL will be taken into account in the description of the feature Autonomous Packet Ressource Allocation or if it has to be described here. Open Issue : To be checked if there is any problem to send an USF for an UL TBF Edge 8-PSK on a DL TBF GPRS.
2.2
2.2.1
Overall description of 8-PSK in UL sub-feature

Support of MCS5 to MCS9
8-PSK modulation is used with the coding schemes MCS5 to MCS9 in RLC acknowledge and unacknowledge modes. -----------------------------The 8-PSK is optional for the mobile and provided to the network through specific messages:
ED 01 Proposal 1
138124182.doc 03/07/2005
In case of one phase access UL TBF establishment initiated by the MS in packet idle mode on PBCCH The MS initiates the packet access procedure by sending the EPGRS Packet Channel Request on a PRACH block located on the timeslot corresponding to its PCCCH group: MS
1
BSS
(EGPRS) Packet Channel Request scenario 1 : request is rejected Packet Access Reject scenario 2 : request is accepted Packet Uplink Assignment USFscheduling
3b
3c 3a 3 2
RLC data block
Packet UL ack/nack
3d
Figure 1 One Phase access for UL (E)GPRS TBF establishment by a MS in packet idle mode on PCCCH In order to initiate the UL EGPRS TBF establishment in 8PSK modulation, the MS shall send the EGPRS Packet Channel Request using TS1 alternative training sequences. (otherwise, it uses the TS2 alternative training sequence) (if it is not possible to allocate the TBF in EGPRS mode, the packet uplink assignment message is sent to the MS in GPRS mode).
ED 01 Proposal 1
138124182.doc 03/07/2005
In case of one phase access UL TBF establishment initiated by the MS in packet idle mode on CCCH (RRM PCC) The mobile station initiates the channel access procedure by sending the CHANNEL REQUEST or the EGPRS PACKET CHANNEL REQUEST message on the RACH block located on the timeslot corresponding to its CCCH group.
MS (EGPRS PACKET) Channel Request scenario 1 : request is rejected

2 1
BSS
Immediate Assignment Reject scenario 2 : request is accepted Immediate Assignment

3a 3b 3c 3d 3e 3
Wait T_USF_Scheduling_AGCH USF Scheduling RLC data block
Packet UL Ack/nack
Figure 2 One Phase access for UL (E)GPRS TBF establishment by MS in packet idle mode on CCCH If an EGPRS mobile station wants to initiate the UL EGPRS TBF establishment and if the mobile supports the 8PSK in uplink, then it shall send an EGPRS Packet Channel Request using TS1 alternative training sequences to request the resources in EGPRS mode and provide its EGPRS modulation capability. 2.2.1.1 Access Burst alternative training sequence
The alternative training sequence used in the (EGPRS) (packet) access request access burst (as described in Figure 1 One Phase access for UL (E)GPRS TBF establishment by a MS in packet idle mode on PCCCH and Figure 2 One Phase access for UL (E)GPRS TBF establishment by MS in packet idle mode on CCCH) is described in 3GPP 45002. It corresponds to a set of bits of access burst which are called synchronisation sequence bits:
ED 01 Proposal 1
138124182.doc 03/07/2005
Bit Number (BN) 0 8 49 85 (88
Length of field
Contents of field extended tail bits synch. sequence bits encrypted bits (e0..e35) tail bits extended guard period (bits)
Definition
- 7 - 48 - 84 - 87 - 156
8 41 36 3 68,25
(below) (below) 45.003 (below) subclause 5.2.8)
where the "synch. sequence bits" are defined as modulating bits with the following states, unless explicitly stated otherwise (see 3GPP TS 44.060): (BN8, BN9 .. BN48) = (0, 1, 0, 0, 1, 0, 1, 1, 0, 1, 1, 1, 1, 1, 1, 1, 1, 0, 0, 1, 1, 0, 0, 1, 1, 0, 1, 0, 1, 0, 1, 0, 0, 0, 1, 1, 1, 1, 0, 0, 0)
in case alternative training (synchronization) sequence "TS1" is used, the "synch. sequence bits" shall be defined as modulating bits with the following states: (BN8, BN9 .. BN48) = (0, 1, 0, 1, 0, 1, 0, 0, 1, 1, 1, 1, 1, 0, 0, 0, 1, 0, 0, 0, 0, 1, 1, 0, 0, 0, 1, 0, 1, 1, 1, 1, 0, 0, 1, 0, 0, 1, 1, 0, 1)
in case alternative training (synchronization) sequence "TS2" is used, the "synch. sequence bits" shall be defined as modulating bits with the following states: (BN8, BN9 .. BN48) = (1, 1, 1, 0, 1, 1, 1, 1, 0, 0, 1, 0, 0, 1, 1, 1, 0, 1, 0, 1, 0, 1, 1, 0, 0, 0, 0, 0, 1, 1, 0, 1, 1, 0, 1, 1, 1, 0, 1, 1, 1)
ED 01 Proposal 1
138124182.doc 03/07/2005
ED 01 Proposal 1
138124182.doc 03/07/2005
PCS/GSM/2005-07001
PCS BSS B9 Description
9/79
In case of two-phase access UL TBF establishment initiated by the MS in packet idle mode on PCCCH
MS
1
BSS (EGPRS) Packet Channel request scenario 1 : request is rejected Packet Access Reject scenario 2 : one UL block is assigned Packet Uplink Assignment Packet Resource request
3a 3 2
3b
scenario 3 : request is rejected Packet Access Reject
scenario 4 : request is accepted Packet Uplink assignment USF scheduling RLC data block
5c 5a 5b
Figure 3 Two-Phase access UL TBF establishment by MS in packet idle mode on PCCCH In Packet Resource Request message, the TLLI is also given by the MS which allows contention resolution at BSS side (details to be given) In case the 8PSK Power Capability field is present in the "Mobile Station Radio Access Capability" IE in the PACKET RESOURCE REQUEST message, the 8PSK modulation (MCS-5 to MCS-9) may be used in uplink. In case the 8PSK Power Capability field is not present, the 8PSK modulation is not used in uplink. In case of two-phase access UL TBF establishment initiated by the MS in packet idle mode on CCCH (RRM PCC)
ED 01 Proposal 1
138124182.doc 03/07/2005
MS (EGPRS Packet) Channel Request scenario 1 : request is rejected Immediate Reject scenario 2 : one UL block is assigned Immediate Assignment Packet Resource Request
3a 3b 3 2 1
BSS
scenario 3 : request is rejected Packet Access Reject
scenario 4 : request is accepted Packet Uplink Assignment USF scheduling RLC data block
5b 5a
5c
Figure 4 Two-Phase access UL TBF establishment by MS in packet idle mode on CCCH With the Packet Resource Request message, the MS provides in the assigned UL radio block detailed information about requested UL resources and the information concerning radio aspect of the MS by the Mobile Station Radio Access Capability IE (Note that the EGPRS capable MS shall provide its EGPRS capability). TLLI is also given by the MS which allows contention resolution at the BSS side ( details to be given). In case the 8PSK Power Capability field is present in the "Mobile Station Radio Access Capability" IE in the PACKET RESOURCE REQUEST message, the 8PSK modulation (MCS-5 to MCS-9) may be used in uplink. In case the 8PSK Power Capability field is not present, the 8PSK modulation is not used in uplink.
ED 01 Proposal 1
138124182.doc 03/07/2005
In case of UL TBF establishment initiated by the MS in packet transfer mode without radio resources reallocation of the DL TBF
MS On-going DL transfer
1
BSS
RLC data block with polling bit Packet channel access phase
2
(EGPRS) Packet Downlink Ack/Nack request is rejected

T3168
3
Packet Access Reject OR request is accepted

4 4a
Packet Uplink Assignment ... Packet Uplink Assignment USF scheduling

4b
Start of UL transfer RLC data block
Figure 5 UL TBF establishment by MS in packet transfer mode The MS requests establishment of an UL TBF by including a Channel Request Description IE in the (EGPRS) Packet Downlink Ack/Nack message sent on PACCH/U of DL TBF. The same TBF mode (GPRS or EGPRS) as the concurrent DL TBF shall be assigned to the MS. Open issue: describe when the BSS is aware of the UL MS capabilitites (8-PSK in UL) Radio resource reallocation of existing DL TBF upon UL TBF establishment To be described
ED 01 Proposal 1
138124182.doc 03/07/2005
The following behaviour are true in both acknowledged and unacknowledged modes: The MCS to be used by the mobile is controlled by the BSS. The link adaptation mechanism in UL is based on measurements (MEAN_BEP, CV_BEP) done by the BTS on the radio blocks received from the mobile. The tables used by the algorithm are the same as the one already used in DL. The selected MCS is provided to the MS through the PACKET UPLINK ACK/NACK messages. The TRX shall transmit to the MFS: - In unacknowledged mode, the erroneous RLC data block for which the header has been correctly decoded - In acknowledged mode, the MEAN_BEP and CV_BEP of erroneous RLC/MAC blocks for which the header has been correctly decoded (for MCS7 to 9, both RLC data block must not be decoded in this case) Retransmitted data blocks can be sent with or without resegmentation (information sent to the MS through specific messages) Open issues: - Is there any guard timer to avoid too many PUAN msgs due to MCS oscillations - What does happen if PUAN are no more received by the MS (due to bad radio conditions) ? - When retransmitting, is MS able to take into account the MCS ordered on the PUAN just received (and trigerring the retransmission ?)
ED 01 Proposal 1
138124182.doc 03/07/2005
2.2.2
Contention Resolution with MCS5 to MCS9
The MS can use RLC data blocks coded with MCS5 to MCS9 during contention resolution procedure (this is described in SFD but it is different from RRM-PCC and RLC specifications, see below) RRM-PCC spec Ed3 : In this release of the BSS, only MCS which are equal to or lower than MCS -4 will be used during contention resolution. RLC spec Ed3 : However, in this release of the BSS, only MCS which are equal to or lower than MCS -4 will be selected for contention resolution Open issue: to be clarified (also in B8, MCS4 is applicable during contention resolution) 2.2.3 Modification of the M-EGCH interface
New RLC data block UL formats are needed to support MCS5 to MCS9. Up to 5 GCH are needed. 2.2.3.1 EGPRS RLC/MAC block format
The RLC/MAC block for EGPRS data transfer consists of a combined RLC/MAC header and one or two RLC data blocks. RLC/MAC block RLC/MAC header RLC data block 1 RLC data block 2 (conditional) Figure 6: RLC/MAC block structure for data transfer for EGPRS Each RLC data blocks contain octets from one or more LLC PDUs. Depending on the MCS (see 3GPP TS 44.004 and 3GPP TS 45.003) one or two RLC data blocks are contained in one RLC/MAC block. For MCS-1, MCS-2, MCS-3, MCS-4, MCS-5 and MCS-6 there is one RLC data block whereas for MCS-7, MCS-8 and MCS-9 there are two RLC data blocks in the RLC/MAC block. 2.2.3.1.1 EGPRS RLC data block
The EGPRS RLC data block consists of a FBI (DL) or TI (UL) field and an E field followed by an EGPRS RLC data unit. The EGPRS RLC data unit is a sequence of N2 octets that are numbered from 1 to N2. In EGPRS UL RLC Data bocks, if MCS-7, MCS-8 or MCS-9 is used (2 RLC data blocks within a radio block), TLLI is indicated in both RLC data blocks. 2.2.4 Management of RLC/MAC block when the header has not been decoded
RLC: When EGPRS TBF is activated in unacknowledged RLC mode, the TRX shall send every RLC data block which is received with a correctly decoded RLC/MAC header, whether the RLC data block is correctly decoded or not.
ED 01 Proposal 1
138124182.doc 03/07/2005
MS
TRX
UL Radio block the header is correct but not the payload UL RLC data block(s) (BFI) the uncorrect payload is sent to the MFS with a Bad Frame indicator
MFS RLC
Figure 7: Uplink radio block not correctly decoded. When the header is not correctly decoded and a RLC data block was scheduled, the TRX shall send to the MFS a NODATA UL indication.
2.3
Overall description of Incremental Redundancy in UL sub-feature
Part of EGPRS package (sold to operator with EGPRS feature). This feature can be activated/deactivated with an O&M flag. The IR (type II hybrid ARQ) can only be used with EGPRS data blocks in RLC acknowledge mode (using MCS1 to MCS9). RLC datablocks are sent by the mobile: - with 3 different PS for MCS3, MCS4, MCS7, MCS8 and MCS9 - with 2 different PS for MCS1, MCS2, MCS5, MCS6 The first RLC data block transmission is performed with PS1. The PS sequence used for the retransmission depends also on the MCS value (if different between first transmitted block and retransmitted blocks) Open issue: to be checked if same rules as DL. The repetition of RLC datablocks is requested by the BSS with PACKET UPLINK ACK/NACK message. To be completed to described the difference between UL and DL if any.
2.4
Parameters/Timers
(OMC-R) EN_IR_UL (Enables/Disables Incremental redundancy for the uplink TBF in the BSS) (MFS B9 critical parameter BSS level) (OMC-R) TBF_UL_INIT_MCS (Value of the uplink modulation and coding scheme when the link adaptation algorithm is disabled or initial value of the modulation and coding scheme otherwise cell level already in B8) T_IR () (Open issue: only in SFD, not in BTP)
2.5
HW coverage
The features shall be supported by systems
ED 01 Proposal 1
138124182.doc 03/07/2005
GSM 900 DCS 1800 / DCS 1900 GSM 850
Open issue: check if also supported by E-GSM. 2.5.1 BSS Telecom Parameters
See Chapter 2.4 2.5.2 MFS Counter Catalogue
(Modified vs B8) P21e (Modified vs B8) P73d (New) P57i, P57j, P57k, P57l, P57m. 2.5.3 None BSC Counter Catalogue
ED 01 Proposal 1
138124182.doc 03/07/2005
3 3.1
EXTENDED UL TBF MODE (PART OF MS GERAN FEATURE PACKAGE 1) Introduction
The aim of the feature is to extend the duration of an UL TBF in order : To quickly restart data transmission in UL if higher layers in the MS deliver new data , without having to re-establish a new UL TBF, after the countdown procedure has started To maintain the UL TBF established , some time after the last block (CV=0) has been acknowledged by the network
This feature allows to improve access time to the GPRS network and in some case the throughput . The feature is described in 3GPP TS 44.060 - V4.18.0. It applies for R4 MS Characteristics: The feature is not an optional one but it is possible to disable it by parameter setting at the OMC. Extended UL TBF used whenever allowed by the MS capabilities . MS capabilities acquired by the BSS as fast as possible; and if UL already established before MS capability known, switch to extended UL TBF possible before the end of UL TBF If the MS does not support the extended UL TBF mode, delayed Final PUAN procedure instead (if T_Delayed_final_PUAN <> 0) During the UL TBF extension , the network can initiate sending of data to the MS without performing a downlink TBF establishment on common control channel . The MS can send data from newly arrived LLC frames after the countdown has started . ??? The frequency at which radio block are scheduled is conditioned by the need of optimzing the MS access time to the network T3180 and T3184 should not be violated (See section Error: Reference source not found for description of these timers) To be added: CS/MCS value after if UL transfer restarted during extended phase.
ED 01 Proposal 1
138124182.doc 03/07/2005
3.1.1
Reminder : B8 normal UL TBF release behaviour
In B8, the main drawback of the normal UL TBF release is that once the countdown procedure been started (at the end of an UL TBF, this procedure starts by giving to the network the number of remaining RLC PDUs), no new PDUs coming can be transmitted on the current TBF. A new one shall be transmitted and restarted wasting some release and establishment delay. In B8, two normal UL TBF release procedures are implemented: without delayed final PUAN (normalEnd, O&M Parameter) T_Delayed_Final_PUAN = 0 => TBF activated by RRM , in RLC with normal_end_handling flag set to allowed (see sectionError: Reference source not found) After UL TBF reallocation (whatever T_ Delayed_Final_PUAN value, the delayed final PUAN procedure is not re-activated.) The UL TBF is established on the PACCH on the DL TBF EMBED Word.Picture.8 MS RLC RRM
BSSGP
last RLC block (BSN=n; CV=0) Packet UL Ack/Nack (SSN=n+1; FAI=1) (1) Packet Control Ack (2)
LLC PDU (last LLC)
RL-UL-Unitdata-req
PCC-RLC-Release-ind (3) PRH-PDTCH-Deassign-req (4) PRH-PDTCH-Deassign-cnf (5) RL-UL-Stop-req (6)
Figure 8
UL TBF release scenario initiated by RLC, without delayed final PUAN procedure
ED 01 Proposal 1
138124182.doc 03/07/2005
- with delayed final PUAN procedure (when T_Delayed_Final_PUAN 0 => TBF activated by RRM , in RLC with normal_end_handling flag set to not allowed. This procedure is inhibited after an UL reallocation process. This procedure is started upon reception of the last UL LLC PDU if there is no concurrent DL TBF (neither establishing, nor established, nor releasing) and no DL TBF was present at UL TBF establishment time (mme si le DL TBF est fini ?????) Then 2 scenarii may occur: First scenario: no DL LLC PDU is received during the delayed final PUAN phase
MS
RLC
RRM
SGSN
RLC/MAC block (BSN = n,CV=0) (1)
LLC PDU (last LLC) (2) PCC-RLC-activate-req DFPUAN (3)
(4)
P. UL Ack/Nack (FAI=0, SSN = n) T3180 PCC-RLC-activate-cnf T3180n T_DELAYED_ FINAL_PUAN
final P. UL ACK/NACK + polling Packet Control Ack (6)
PCC-RLC-activate-req(NE) (5) PCC-RLC-activate-cnf PCC-RLC-Release-ind (7)
Figure 9 Normal UL TBF release (delayed final PUAN) Open issue: This figure comes from RRM-PCC ed3 and is different from the one presented in the SFD
ED 01 Proposal 1
138124182.doc 03/07/2005
Second scenario: a DL LLC PDU is received during the delayed final PUAN phase
MS
RLC
RRM
SGSN
RLC/MAC block (BSN = n,CV=0) (1) LLC PDU (last LLC) (2) P. UL Ack/Nack (FAI=0, SSN = n) (3) PCC-RLC-activate-req DFPUAN PCC-RLC-activate-cnf PACKET DOWNLINK ASSIGNMENT (6) T3180 PACKET CONTROL ACKNOWLEDGEMENT (7) final P. UL ACK/NACK + polling Packet Control Ack (9) PCC-RLC-activate-req NE (8) PCC-RLC-activate-cnf PCC-RLC-Release-ind (10) T3180n T_DELAYED_FINAL_PUAN
(4)
(5)
Figure 10
Normal UL TBF release (delayed final PUAN, with DL TBF establishment)
Open issue: This figure comes from RRM-PCC ed3 and is different from the one presented in the SFD If an abnormal UL TBF release is notified, by RLC, during T3180n activation, then UL resources are frozen until T3180n expiry. T_DELAYED_FINAL_PUAN + DL_TBF establishment duration + UL TBF release duration is always lower than T3180 B8 default values: T_DELAYED_FINAL_PUAN : min = 0s, max = 2s, default = 0,4s
3.2
Overall description of the proposed solutions
The RRM layer selects the extended UL TBF mode to delay the release of an UL TBF for Rel-4 MS onwards (this mode is not supported by R97 and R99 MSs). In this mode, the RLC layer continues to assign USFs to the UL TBF. If the MS has no RLC data blocks to send to the network, it sends PACKET UPLINK DUMMY CONTROL BLOCK messages instead (in this case the counter N_UL_Dummy shall not be increased, and if the radio block is valid, the counter N3101 shall not be increased neither) Open issue: The fact that N_UL_Dummy and N3101 are not increased has to be checked.
ED 01 Proposal 1
138124182.doc 03/07/2005
MS USF RLC Block, BSN=n, CV =0
BSS
start T_extended_UL_TBF PUAN, SSN= n+1, FAI=0
USF dummy block USF dummy block USF transfer resumes RLC Block, BSN=n+1 Stop T_extended_UL_TBF
NOTE:
The network might not receive the radio access capabilities of the mobile station at one-phase packet access. In that case, the two entities may operate in different mode.
In the extended uplink TBF mode, if V(S) = V(A) and there is no RLC data block with BSN = V(S) available, the mobile station shall stop sending RLC data blocks. The mobile station shall continue sending RLC data blocks when a RLC data block with BSN = V(S) is available. When the mobile station is allocated an uplink radio block and there is no RLC data block ready to send, the mobile station shall send an RLC/MAC control block in each uplink radio block allocated by the network Open issue: clarify if there is a information sent to the MS to indicate that the TBF entered in extended mode : in one section of RRM-PCC, the following sentence seems to indicate that the fact that FAI <>1 is enough: The BSS acknowledges the last Data block with Packet UL Ack/Nack message, but the Final Ack Indicator is not set, so that the uplink TBF enters in extended mode in both MS and BSS side. The MS starts T3184. T3180 and T3184 (See section 3.3.2 for more information on these timers) must not expire because the MS is in the extended phase. In order to avoid the expiry of T3184, timer T_max_extended_UL has to be tuned properly. In order to avoid the expiry of T3180, the scheduling time between two USF will be small enough. When the timer T_max_extended_UL expires (see section 3.3.2), the network initiates the release of the UL TBF as shown in figure below
ED 01 Proposal 1
138124182.doc 03/07/2005
3.2.1
MS and BSS capability
The MS is aware of the BSS capability by the NW_EXT_UTBF parameter broadcast on either BCCH (SI13) or PBCCH (PSI1). MS supporting extended UL TBF mode = a mobile indicating support of GERAN feature Package 1 in the Mobile Station Classmark 3IE, the MS Radio Access Capabiility IE and the MS Radio Access Capability 2 IE (see 3GPP TS 24.008) (only R4 MS) MS is always aware of the BSS capability before establishing an UL TBF . BSS not always aware of the MS capability when the first UL is established at the beginning of a session. Apply for both acknowledge and unacknowledged mode
ED 01 Proposal 1
138124182.doc 03/07/2005
3.2.2 SFD:
Acquiring the MS capability (with Extended UL TBF mode capability)
The MS Radio access capability is received at downlink TBF establishment in the first downlink PDU on the Gb interface. In case of cell reselection, too much time can ellapse => 2 procedures may be used to obtained this information (later, only one of the two solutions will be choisen) Radio access capability update (described in 3GPP TS 48.018 4.7.0) TLLI retrieval (Open Issue :to be clarified)
RRM-PCC: The MS supports the extended UL TBF mode if the Radio Access Capability indicates that the MS supports the Geran feature package 1. At UL TBF establishement RLC provides to RRM the MS TLLI. As soon as the TLLI is known by RRM-PCC, RRM looks into MS context to see if the MS Radio Access Capability is already stored from a previous transaction. If the radio access capability is not known and if the parameter EN_RA_CAP_UPDATE is set to enable (see section 3.3), then the BSS trigers the RA capability update procedure towards the SGSN . This procedure is summarized in section 3.2.2.1 (BSSGP messages BSS->SGSN: RA-CAPABILITY-UPDATE, and SGSN->BSS: RA-CAPABILITY-UPDATE-ACK) As soon as the RA capability is received from the SGSN, RRM-PCC updates the MS context. If the parameter EN_RA_CAP_UPDATE (See Section 3.3) is set to disable, or if the RA capability update procedure has failed, then the BSS assumes the MS does not support Geran feature package 1 . The RA capability will then be received in the first DL PDU for this TLLI (see section 8.2). As soon as a Radio access capability is received from the SGSN, it shall overwrite previously stored information. If RRM knows the MS capability at TBF establishment, then the TBF is activated in exended UL mode at RLC level. Else, RLC waits for RRM command to use the appropriate mode (extended UL TBF, or Delayed final PUAN or Normal End). Storing the radio access capabilities in the BSS The radio access capability shall be stored with the corresponding TLLI by the BSS, in the MS context so that when the next UL TBF is established on (P)CCCH the relevant TBF mode shall be applied. This can be useful mainly for interactive sessions, when the inter-page reading time is longer than the Delayed DL TBF phase or Extended UL TBF phase, but still shorter than the T_MS_Context_Lifetime timer (See section 3.3).
3.2.2.1 3.2.2.1.1
RA Update Capability procedure (BSSGP Ed2) Successful case
It is the role of the (BSSGP) to insert the tag in the RA-CAPABILITY-UPDATE PDU, and to control the tag at reception from the SGSN.
ED 01 Proposal 1
138124182.doc 03/07/2005
BSS
(RRM-PCC)
(BSSGP)
SGSN (BSSGP)
GMM-RA-CAPABILITY-UPDATE.req
add Tag
RA-CAPABILITY-UPDATE T5 RA-CAPABILITY-UPDATE-ACK
X
control Tag
GMM-RA-CAPABILITY-UPDATE.cnf
Figure 11: RA-CAPABILITY requested by the BSS
3.2.2.1.2
Abnormal case
If the PDU RA-CAPABILITY-UPDATE-ACK is not received within T5, BSSGP has to repeat the request a maximum of NB_MAX_RA_CAP attempts. (BSSGP) has to modify the tag at each retry. Open issue : where is described NB_MAX_RA_CAP. If no response is received, BSSGP sends back a GMM-RA-CAPABILITY-UPDATE.cnf to RRM with an appropriate cause (for instance, no response from SGSN).
ED 01 Proposal 1
138124182.doc 03/07/2005
3.2.3 3.2.3.1
MS is know by the BSS to support the extended UL mode Extended UL phase followed by DL TBF establishment. (comes from RRM-PCC)
This case shows the respective handling of T_NW_RESPONSE TIME and T_MAX_EXTENDED_UL
MS
RLC
RRM
SGSN
RLC/MAC block (BSN = n,CV=0) (1) P. UL Ack/Nack (FAI=0, SSN = n+1) (3)
LLC PDU (last LLC) (2)
(4)
T_NW_resp_time (5)
T3184
DL LLC PDU (6) DL TBF establishment (7) DL RLC radio blocks DL LLC PDU T_MAX_ extended_UL
Figure 12
Extended UL phase followed DL TBF establishment
The extended UL phase is described in the next scenario.
ED 01 Proposal 1
138124182.doc 03/07/2005
3.2.3.2
Extended UL phase followed by TBF release. (comes from RRM-PCC)
In general T_MAX_EXTENDED_UL > T_NW_RESPONSE_TIME. Case A) no DL TBF established, T_NW_REPONSE_TIME expiry. This case occurs when no DL transfer is on-going.
MS
RLC
RRM
SGSN
RLC/MAC block (BSN = n,CV=0) (1) P. UL Ack/Nack (FAI=0, SSN = n+1) (3)
LLC PDU (last LLC) (2) T_MAX_ EXTENDED_UL
(4) T_NW_RESP _TIME (5)
T3184 PCC-RLC-activate-req NE (6) final P. UL ACK/NACK + polling PCC-RLC-activate-cnf Packet Control Ack (7) PCC-RLC-Release-ind (8)
Figure 13
Extended UL phase followed by UL TBF release (no DL established)
If the timer T_NW_RESPONSE_TIME expires, RRM-PCC stops the timer T_MAX_EXTENDED_UL and requests RLC to initiate the release of the UL TBF.
ED 01 Proposal 1
138124182.doc 03/07/2005
Case B) T_DELAYED_DL_TBF_REL expires while the UL TBF is in extended state If an uplink TBF is in extended state and T_DELAYED_DL_TBF timer expires at the end of the delayed DL period, then the UL TBF is maintained in extended mode until the release of the DL TBF has completed, so until T3192 expires. The expiry of T3192 triggers the release of the extended UL TBF. Note that this case may never occur with small value of T_MAX_EXTENDED_UL.
MS T3184
RLC
RRM
SGSN
UL TBF has entered extended state, last DL PDU is being sent

Last useful DL RLC blocks (1) TRN-DL_Ack_Ind (2) Packet DL Ack/Nack T_MAX_ EXTENDED_UL T_Delayed_ DL_TBF_rel (3) PCC-RLC-activate-req (4) Dummy crtl block + polling PCC-RLC-activate-cnf Packet Downlink Ack / Nack (5) PCC-RLC-Release-ind T3192 & T3192n (6) Packet UL Ack/Nack FBI=1 PCC-RLC-activate-req (7)
(8)
Packet control Ack
PCC-RLC-release-ind
Figure 14
DL TBF release while UL is in extended state
the BSS request RLC to release the UL TBF upon T3192 expiry. Note: the maximum duration of the extended UL state in the MS with above case is equal to T_MAX_EXTENDED_UL + T3192. Both timers value must be such that the total extended UL duration is shorter than the MS timer T3184 (5s) to avoid abnormal release by the MS.
ED 01 Proposal 1
138124182.doc 03/07/2005
CASE C) T_MAX_EXTENDED_UL expiry This case occurs when a concurrent DL transfer is on-going, so T_NW_RESPONSE time was not started. Timer T_MAX_EXTENDED_UL expires when the DL is still transfering or in DL delayed state (T_DELAYED_DL_TBF_REL still running). The scenario is the same as CASE A), except that the trigger to send PCC-RLC-activate-req(normal-endhandling= allowed) is the expiry of T_MAX_EXTENDED_UL. There is no action triggered towards the concurrent DL TBF. Case D) T3192 expiry T3192 expiry triggers the release of a concurrent UL TBF in extended UL sub-state. See case B).
ED 01 Proposal 1
138124182.doc 03/07/2005
3.2.3.3
Extended UL phase followed by transfer resumption
Case A: nominal case MS RLC RRM SGSN
RLC/MAC block (BSN = n,CV=0) (1) P. UL Ack/Nack (FAI=0, SSN = n+1) (3) UL TBF extension phase RLC/MAC block (BSN = n+1) (6)
LLC PDU (last LLC) (2)
(4) T_max_extended_UL T_NW_resp_time (5)
T3184
PCC-RLC-start-ind (7) RLC/MAC block (end of PDU ) LLC PDU (8)
Figure 15
Extended UL phase followed by transfer resumption
The MS sends an uplink data block, which restarts the uplink TBF (6). RLC indicates to RRM the restart of the TBF, RRM stops the timers T_MAX_EXTENDED_UL, and the timer T_NW_RESPONSE_TIME if running. When a PDU is completely received, RLC re-assembles it and transmits it to RRM, which forwards it to the SGSN. The MS will stop (and restart) T3184 upon reception of the next PUAN from the BSS.
ED 01 Proposal 1
138124182.doc 03/07/2005
Case B: crossing of PCC-RLC-activate-req(normal-end) and of UL transfer resumption .
MS
RLC
RRM
RRM decides to release the extended UL TBF PCC-RLC-activate-req (1)
UL radio block(3)
(2) PCC-RLC-start-ind (4)
PCC-RLC-activatecnf (nack) (5)
UL TBF is in transfer again
Figure 16
Crossing of PCC-RLC- activate-req(normal-end) and UL transfer resumption
RRM requests RLC to release the uplink TBF. RLC does not release the TBF immediately but waits during one round-trip-delay for UL radio blocks corresponding to already scheduled USFs. The MS restarts the uplink transfer by sending at least one radio block during this round-trip-delay with a BSN within the allowed range (i.e greater than the last BSN received before switching to the extended phase). RLC acknowledges negatively the request to release the TBF .
ED 01 Proposal 1
138124182.doc 03/07/2005
Open issue: following sentence comes from SFD but has to be checked in the other specs: The BSS consider that the transfer is resumed upon reception of When receiving an E-GPRS block with a correctly decoded header but an invalid data field (in this cas N3101 shall be incremented)
If the MS requests a change of RLC mode when the UL TBF is in extended phase, then the UL TBF shall be released and the TBF will be re-established by the MS as specified by 3GPP 44.060
ED 01 Proposal 1
138124182.doc 03/07/2005
3.2.4
When the MS capability is not known at UL TBF mode
This can occur during a MS originated session (eg Dowlink FTP transfer, WAP transaction) for the first UL TBF establishment. 3.2.4.1 Extended UL phase started during delayed final PUAN phase (RRM-PCC)
This case corresponds to an MS, which supports the GERAN feature package 1, but for which the BSS does not know the Radio Access capability at TBF establishment. The TBF was activated with normal-endhandling = None. The BSS acquires the Radio Access Capability when T_Delayed_Final_PUAN is already started. MS RLC RRM SGSN
RLC/MAC block (BSN = n, CV=0) (1)
LLC PDU (last LLC) (2) PCC-RLC-activate-req DFPUAN(3) PCC-RLC-activate-cnf PCC-RLC-activate-req (6)
(4)
T_DELAYED_FINAL_PUAN
P. UL Ack/Nack (FAI=0, SSN = n)
(5)
T_MAX_EXTENDED_UL T_NW_RESPONSE_TIME
T3184 (9)
PUAN (FAI =0, SSN=n+1) (7) PCC-RLC-activate-cnf (8)
UL TBF is extended Figure 17 Extended UL phase starts during T_delayed_final_PUAN
Upon PUAN reception the MS stops timer T3184 and restarts it (9).
ED 01 Proposal 1
138124182.doc 03/07/2005
Following part comes from SFD (part to be checked) When T_delayed_final_PUAN is running, the BSS does not know whether the MS supports the extended UL mode, so it must accept MS behaviour corresponding to both modes, without counting any protocol error. If the MS is a R99 MS, it will repeat the last BSN for these USF. The BSS discard this block, but does not count any protocol error. If the MS is a R4 MS it will repeat the last BSN once, and then it may send a few dummy blocks or it may try to sent blokcks with BSN>n if it has new data to transfer. Dummy blocks and data blocks, if received by the BSS while T_delayed_PUAN is running shall be discarded, but shall not increment any counter for protocol error
N_UL_dummy shall not be incremented in this state..
MS R4
BSS MS release not known yet USF Data block
CV=0 new data CV =n start T_delayed_final PUAN no more USF are sent received block is discarded
Figure 18: RLC blocks received while T_delayed_final_PUAN is running Open issue: clarify in which cases the received blocks are discarded and clarify what are the two modes. - When Timer T_delayed_final_PUAN expires, the UL TBF is released as in B8.
ED 01 Proposal 1
138124182.doc 03/07/2005
3.2.5
Scheduling of USF to the MS
The constraints to be taken into account are: USF must be provided as often as possible so that the transfer resumption of UL PDU is as fast as possible. When the MS is not multiplexed, USF are scheduled on every UL radio blocks of the PDCH which carries the PACCH. When several UL TBF are multiplexed on the same PDCH, priority for bandwith usage shall be given to the MS which are currently transmitting data, other those (???) which are in extended UL Modes if all are in extended TBF mode and if EN_fast_USF_UL_extended is enable, USF is scheduled every n*20ms with n egal number of MSs, if the PDCH supports at least one MS which is in UL mode or if the flag EN_fast_USF_UL_extended is disabled, the polling period T_extended_UL_TBF_POL is used for the MSs in extended UL mode. This polling period can be expressed in ms or in radio block period, it should be implemented at MAC level. A default value of 200ms is recommended. Priority is given to RRBP mechanism above USF scheduling. This means the USF scheduling may be shifted if RRBP request from RLC. USF must be provided often enough so that the MS timer T3180 (5s) does not expire. USF has to be sent to only one PDCH (the one which carries thePACCH) even if the MS have more than one TS capability ion the UL.
ED 01 Proposal 1
138124182.doc 03/07/2005
3.2.6
Interaction with concurrent downlink TBFs
When the uplink TBF is in extended phase and has a concurrent DL TBF established and in delayed state, there is no need to poll the MS in downlink at short interval. Then the polling period for the delayed downlink TBF is the same as for an uplink TBF established and in transfer, just tuned to avoid RLC timer expiry. This means that the polling timer in downlink is done using the parameter T_Delayed_DL_TBF_Pol_UL (see section 3.3.2). The BSS shall monitor the duration of the extended state and of the delayed downlink phase. The purpose is to minimize end-to-end round trip time in the case of response-answer type of traffic, and to maintain the TBF during short interruptions of transfer during downlink or or uplink transfer. We consider that the time during which the uplink and downlink TBF are both delayed (i.e. uplink extended and downlink delayed) should not be longer than an expected MS response time and Network response time. We expect the network response time to always be greater than the MS response time, so in practice the Network response time is used. Additionally, a maximum time is introduced to avoid too long duration of the extended UL TBF, even when the downlink TBF remains established , so as to save MS battery usage in compliance with 3GPP requirements. It must be noted that the symetrical behaviour does not exist in downlink : a downlink TBF may be maintained in this state as long as a concurrent uplink TBF is established; Several cases are considered, depending whether the UL or DL transfer finishes first. Timer T3192 is taken into account to avoid that timer T3192 runs while the UL TBF is released, as in this case is causing loss of performances for Ping application. UL transfer stops when DL is still in transfer A) In case of DL over UDP, the time between two consecutive UL application messages is quite long: DL UL T_max_extended-UL in transfer extended mode T_max_extended_UL expires => UL TBF is released, DL goes on
B) If he DL transfer also stops while UL TBF has switched to extended state. The UL TBF in extended mode is released when either T3192 or T_max_extended_UL expires. DL UL in transfer delayed extended mode T_NW_response_time expires still running T3192 expires (3) (4)=> UL TBF is released T3192
T_NW_response_time T_max_extended-UL T3192 Event
(1)
(2)
ED 01 Proposal 1
138124182.doc 03/07/2005
DL transfer stops when UL is still in transfer. The UL TBF in extended mode is released when either T3192 or T_max_extended_UL expires.
DL UL T_NW_response_time T_max_extended-UL T3192 Event 3.2.7
delayed mode in transfer
T3192
extended mode T_NW_response_time expires T3192 expires =>release extended UL
(1)
(2)
(3)
Fast UL TBF reestablishment
This feature is not requested in B9 feature list. It is provided here for informative usage. During an uplink TBF release, the TBF_EST bit, which may be set by the network allows the MS to insert a Packet Channel Request in the final Packet Control Ack during an uplink TBF release. This enables an MS from R99 to request for an uplink TBF while an uplink TBF is already being released. A following uplink TBF may be established without the MS to switch on (P)CCCH, and the BSS already knows the MS Radio Access capabilties. However, the feature is optional for MS and does not apply to R97 MS. Furthermore, for Pre-Rel-4 MS, the Delayed Final Packet Uplink Ack/Nack has been designed in order to ensure that a downlink TBF is established in nominal cases before the uplink is released. On the PACCH of such a downlink TBF, the MS may request the establishment of an uplink TBF, inserted in last PDAN without the use of the fast uplink TBF re-establishment. Thus, the BSS is not required to support the fast uplink TBF re-establishment, because it would cover only a very small proportion of cases, corresponding to two successive uplink TBFs, with no concurrent downlink established. 3.2.8 Link adaptation
Link adaptation mechanism based on measurements made in UL is deactivated during extended phase : the last CS or MCS in UL is used during a maximum time (CS_MAX_IDLE_PERIOD with a new definition in B9). Then the initial CS or MCS is applied again (TBF_UL_init_CS or TBF_UL_init_MCS). New internal timer needed at RLC level (??) 3.2.9 Extension phase duration
The timer T_MAX_EXTENDED_UL monitors the maximum extended UL TBF duration. Minimum value: > 1s Maximum value : <= 4s Default value = 2s
ED 01 Proposal 1
138124182.doc 03/07/2005
3.2.10 Pre-emption and re-allocation If radio resources are requested by the BSC, and if it involves the PDCH carrying PACCH of the TBF, then T1 reallocation shall be performed. The re-allocated TBF shall keep the same mode as before the reallocation. If the re-allocation fails, then, the Uplink TBF in extended mode shall be handled in the same way as in normal mode (for TBFs whose PACCH corresponds to the SPDCH being de-allocated, the MFS triggers a T1 reallocation to reallocate them and the SPDCH enters the de-allocating state. If the T1 reallocation fails due to a radio problem, the SPDCH is then freed by a Packet TBF Release message info coming from Autonomous Packet Ressource Allocation SFD) For other re-allocation triggered the same principle applies: The uplink TBF in extended mode remains in extended mode after the re-allocation. Open issue: to be checked in SYT specifications (???) 3.2.11 NC2 de-activation When the DL TBF is release, the following cases are possible: No Uplink TBF established Uplink TBF in extended state When the NC2 deactivation mode is at the end of the packet transfer, the Packet Measurement Order shall be sent like in B8 at the end of the Delayed Downlink TBF release, even if the uplink TBF is still in extended state.
3.3
3.3.1
Parameters/Timers
BSS parameters/Timers
- (OMC-R changeable) Timer T_max_extended_UL (Maximum duration of extended UL TBF phase - cell level) - Timer T_NETWORK_RESPONSE_TIME (Timer controlling the network part of the delayed TBF release feature. It corresponds to the typical server response time and is therefore heavily dependent on the MFS location wrt the server location. This timer is also used to control the extended UL TBF mode BSS level) - (OMC-R changeable) EN_EXTENDED_UL_TBF (Enables /disables the extended UL TBF feature cell level) : => recommended not to activate this parameter at the same time as EN_AUTONOMOUS_REROUTING . - (OMC-R changeable) EN_fast_USF_UL_extended (Flag to disable/enable the transmission of USF every 20ms in extended mode - BSS level) - Timer T_extended_UL_TBF_POL (To control the USF scheduling on the uplink when a TBF is in extended TBF mode) - (OMC-R changeable) EN_RA_CAP_UPDATE (Flag to enable/disable the Radio Acces Capability update on Gb BSS level) - (OMC-R changeable) CS_MAX_IDLE_PERIOD (Maximum downlink (or respectively uplink) transfer interruption between two successive DL (or respectively UL) PDU to be able to reuse the coding scheme or modulation and coding scheme of the previous transmitted (or respectively received) radio blocks. This applies in case of data transfer resumption for a DL TBF in delayed release state, or an UL TBF in extended state. When a new LLC PDU is received and the downlink/uplink transfer is resumed, the timer defined by CS_MAX_IDLE_PERIOD shall be checked. If it has not expired, then the previous coding scheme or modulation and coding scheme of the DL/UL TBF shall be applied cell already in ED 01 Proposal 1
138124182.doc 03/07/2005
B8) default value = 680ms. - T_MS_Context_Lifetime timer (same as in B8 ? if yes should be moved in 3.3.2) 3.3.2 Parameters/timers definitions (not modified by B9 features)
- T_DELAYED_DL_TBF () - T_Delayed_DL_TBF_Pol_UL (This timer defines the period of sending 'Dummy UI commands' in the delayed DL TBF release state, when there is an on-going UL TBF) - TBF_UL_init_CS (Value of the uplink coding scheme when the link adaptation algorithm is disabled or initial value of the coding scheme otherwise cell) - TBF_UL_init_MCS (Value of the uplink modulation and coding scheme when the link adaptation algorithm is disabled or initial value of the modulation and coding scheme otherwise cell) - T_DELAYED_FINAL_PUAN (This timer defines the duration of the delay introdueced by the BSS to send the final Packet UL Ack/Nack message when releasing an UL TBF - BSS) Reminder (counters/Timers definition): - N3101: When the network after setting USF, receives a valid data block from the mobile station, it will reset counter N3101. The network will increment counter N3101 for each USF for which no data is received. N3101max shall be greater than 8. - N3103 is reset when transmitting the final PACKET UPLINK ACK/NACK message within a TBF (final ack indicator set to 1). If the network does not receive the PACKET CONTROL ACKNOWLEDGEMENT message in the scheduled block, it shall increment counter N3103 and retransmit the PACKET UPLINK ACK/NACK message. If counter N3103 exceeds its limit, the network shall start timer T3169. - T3180: Wait for Uplink State Flag After Data Block. This timer is used on the mobile station side to define when to stop waiting for the USF determining the assigned portion of the uplink channel after the pervious RLC/MAC block is sent. In multislot operation, it is enough that the assigned USF is noted on one of the uplink PDCHs. If expired, the mobile station repeats the procedure for random access. This timer does not apply to fixed allocation transfers. - T3180n: to be completed - T3184: No Ack/Nack Received. At fixed allocation, this timer is used on the mobile station side to decide when to stop waiting for a Packet Uplink Ack/Nack. (This timer does not apply to mobiles performing a dynamic allocation transfer). At exclusive allocation, this timer is used to detect a radio link failure condition. If expired, the mobile station performs an abnormal release with access retry. - T3192: to be completed
ED 01 Proposal 1
138124182.doc 03/07/2005
3.4
Dependencies
The Feature "Enhanced packet cell reselection": is enhanced by Dependency TBF Both Delayed DL TBF release and UL extended feature tend to save establishment time in case of bursty traffic. Both feature are complementary, but the DL applies to all MS whereas the UL provides improvement only for MS which support GERAN Feature Package 1. At first MS access, the Radio Access capabilities are not known by the BSS. The Delayed final Uplink Packet Uplink Ack/Nack should enable the SGSN to send a DL LLC PDU in the time between so that the BSS may apply the Extended UL TBF mode if supported by the MS. If the uplink TBF is extended, possible sub-optimal allocations may last during a long time. TBF resource reallocation will allow, to modify initial sub-optimal allocations. 1 When the first uplink TBF is established, the BSS may know if the MS supports the feature, thanks to radio access capability stored in the MS context during the T_MS_context_lifetime duration. . The Extended UL TBF mode allows to decrease GPU CPU load for release 4 MS, by diminishing the number of UL TBF establishment & release. In ref Error: Reference source not found it is proposed to also help decrease the GPU load for non-release 4 MS by keeping the uplink radio resources established like for a release 4 MS, but releasing the TBF on the radio interface. This mayalso improve UL TBF establishment time in a number of cases. The extended UL TBF mode tends to increase radio resource usage. Statistical multiplexing will prevent this increase to produce increased Ater blocking.
Feature Delayed Downlink Release (B8)
Delayed final Ack/Nack (B8)
Packet
Uplink
TBF (B8)
Resource
Reallocation
MS context handling
Alignment of PPC capacity to DSP capacity.(B9)
Statistical multiplexing
With extended UL TBF, the UL TBF is likely to be maintained during the whole transaction. Hence the initial allocation for this TBF could be kept during the whole transaction (e.g. UL FTP transfer), so like for DL delayed TBF release, the Radio resource re-allocation will help prevent a bad UL allocation to be kept too long.
1
ED 01 Proposal 1
138124182.doc 03/07/2005
decreases the interest of Dependency As a consequence of extended UL mode, the TCP ACKs transmitted over the UL are less bursty and have a lower delay, and the jitter of the total round trip delay for TCP packets is lower. A lower jitter for TCP RTD implies that the TCP retransmission timer value is lower, i.e. the TCP retransmission timer is more likely to expire during cell reselection. when DL PDU re-routing is implemented, the PDU will be retransmitted twice: by TCP additionnlly to the BSS mechanism, thus causing loss of throughput at application level in case of cell reselection. It is advised not to activate both features simultaneously .
Feature DL PDU rerouting
3.5
HW coverage
The features shall be supported systems GSM 900 (what about E-GSM ?)
Open issue: to be checked if also supported by E-GSM DCS 1800 / DCS 1900 GSM 850
ED 01 Proposal 1
138124182.doc 03/07/2005
3.6
3.6.1
New parameters, counters, indicators

BSS Telecom Parameters
See Chapter 3.3 3.6.2 MFS Counter Catalogue
(Modified vs B8) P21a, b, d, e : retransmission counters should not be incremented by the packet UL Dummy Control Block (Modified vs B8) P73c, P73d : Lost RLC data block corresponding to the USFs scheduled during the extension phase shall not increment these 2 counters. (Modified vs B8) P57a, b, c, d, e, f, g, h : useful blocks shall not take into account the Packet UL Dummy Control blocks. (New) P57i, j, k, l, m : idem above but new due to feature enhanced support of (E)GPRS in UL (See chapter 2) (Modified vs B8) P350b : idem P57a (Deleted) P29a, b, c, d : to be deleted and replaced by new counters for which active and extended phases are distinguished. (New) P129a, b, c, d: Cumulated time duration of all active UL TBFs established in (E)GPRS mode in RLC acknowledged mode or unacknowledged mode (New) P461: Cumulated overall time of UL TBF connections (in active state or extended phase). (New) P462: Number of Packet Uplink Dummy Control blocks received on the radio interface (This counter applies to both GPRS and EGPRS TBFs.) (Modified vs B8) P38b : modify trigger definition to take into account extended phase 3.6.3 None BSC Counter Catalogue
ED 01 Proposal 1
138124182.doc 03/07/2005
4 4.1
ENHANCED PACKET CELL RESELECTION Introduction (Sub-features)
There are two functional requirements : 1. limit the service outage during packet cell reselection (NC0 and NC2 modes) : Packet PSI Status procedure Packet SI Status procedure Network Assisted Cell Change Procedures (NACC)
2. in NC2 mode, introduce a feature avoiding to direct MSs towards high loaded cells, where the MS can be served with non-optimum resources, or even worse, rejected due to congestion (NC2 improvement: cell ranking with load criteria) Open issue: gains of these improvements through cell reselection time reduction to be added Cell reselection is described in RRM-PCC specification (The summary described in this document is inspired from RRM-PCC ed3 and not SFD) The sub-feature list is described here after: 4.1.1 4.1.2 4.1.3 4.1.4 Network Assisted Cell Change procedure (See chapters 4.2.1, 4.2.3) Packet SI Status procedure (See chapter 4.2.2) Packet PSI Status procedure (See chapter 4.2.2) NC2 improvement : cell ranking with load criteria (See Chapter 4.2.4)
4.2
4.2.1

NACC procedure - NC0
The NACC procedure for a mobile station operating in NC2 mode corresponds to the Cell System Information Distribution procedure in NC2 described in one of the next sections, thus this section will focus on NACC for an MS operating in NC0 mode. The Network Assisted Cell Change takes place in the serving cell and consists in 2 independent procedures : CCN mode procedure (Cell Change Notification) Cell System Information distribution Procedure in which the MS notifies the network when the cell reselection is decided and delays the cell reselection to let the network act on need, eventually through the Cell System Information distribution procedure. Procedure that can assist an MS in Packet Transfer Mode with target cell system information required for initial packet access after a cell change. This information is sent to the MS in the serving cell and before the cell change is performed.
ED 01 Proposal 1
138124182.doc 03/07/2005
When supported (EN_NACC O&M parameter is set to True, see section 4.3), the use of the CCN mode is ordered to all mobile stations supporting GERAN feature package 1 in the cell (R4 MSs). The following scenario describes the NACC procedure in a cell in NC0 mode.
MS on-going data transfer
Cell A
Cell B
target cell choice (1) T3206

RLC data block, polling Packet Cell Change Notification (2)
T3208
T3210
retrieval of PSI instances of the chosen cell(3) Packet Neighbour Cell Data (PSI14) Packet Neighbour Cell Data (PSI1) Packet Neighbour Cell Data (PSI2 - first instance)
T3208n
Packet Neighbour Cell Data (PSI2 - intermediate instance) Packet Neighbour Cell Data (PSI2 - last instance) Packet Cell Change Continue (4)
Figure 19 Note:
Cell Change Notification procedure
The figure above covers the case where there is a PBCCH in the target cell. When there is no PBCCH channel in the target cell, the same scenario takes place with the difference that the BSS sends the SI13, SI1 and SI3 messages instead of the PSI14, PSI1 and PSI2 messages. T3206 (400ms) (see section 4.3) monitors the sending of the Packet Cell Change Notification. This requires that the BSS ensures a regular scheduling of uplink PACCH blocks to any existing TBF : it shall allocate at least one USF every 400 ms to an uplink TBF, and it shall poll the mobile station at least every 400 ms during a downlink TBF.
- (1):
- (2):
At receipt of the PACKET CELL CHANGE NOTIFICATION message, the MFS checks whether the proposed cell belongs to the same BSS as the serving cell. If the proposed cell does not belong to the same BSS (i.e. BSC_ID(n) (target cell) <> BSC_ID (serving cell)), a PACKET CELL CHANGE CONTINUE (PCCC) message is sent to the mobile station without sending any neighbour cell system information. In the case the neighbour cell belongs to the same BSS, RRM starts the timer T3208n (T3208 RTD) (see section 4.3) that monitors the sending of the PCCC and retrieves the SI13 / SI1 / SI3 or PSI14 / PSI1 / PSI2 instances currently broadcast in the neighbour cell (possibly located on another GPU) and requests MAC to send, before any other downlink RLC data block (except blocks with polling), the relevant (P)SI to the mobile station : - if the target cell supports a PBCCH channel (i.e. a PBCCH channel is currently allocated in the cell), RRM encodes the PSI14, PSI1 and PSI2 instances of that cell in one or multiple instances of the PACKET NEIGHBOUR CELL DATA message which are then sent individually to the mobile station, followed by a PACKET CELL CHANGE CONTINUE message 2. The PSI14 message
- (3):
The Packet Cell Change Continue message is preferred to the Packet Cell Change Order message in NC0 mode to avoid forcing a cell reselection that would not be needed anymore as determined by the mobile
2
ED 01 Proposal 1
138124182.doc 03/07/2005
contains an explicit description of the PBCCH channel configuration (i.e. when hopping, a mobile allocation not relative to the cell allocation), in particular the slot supporting the PBCCH ; - if the target cell does not support a PBCCH channel (i.e. no PBCCH is currently allocated in the cell), RRM encodes the SI13, SI1 and SI3 instances of that cell in one or multiple instances of the PACKET NEIGHBOUR CELL DATA message which are then sent individually to the mobile station, followed by a PACKET CELL CHANGE CONTINUE message. When the MS sends the Packet Cell Change Notification message, the MS activates the timer T3210 (see section 4.3) (300 ms) to wait for a response from the BSS (at timer expiry, the Packet Cell Change Notification is retransmitted at the first opportunity, consequently T3210 has not to be managed by the MFS). The MS also activates the timer T3208 (960 msec) to wait for PACKET CELL CHANGE CONTINUE from the BSS (at timer expiry, the MS will continue the cell reselection in NC0 mode). This means that : - the duration of cell B [P]SI information retrieval has to be lower than T3210 - RTD = 140 ms. - the duration for sending of cell B (P)SI information has to be lower than T3208 RTD = 800 msec. - (4): When RLC has sent all the instances of the PACKET NEIGHBOUR CELL DATA message, the PACKET CELL CHANGE CONTINUE (PCCC) message is sent on the PACCH of the mobile station and the timer T3208n is stopped. The PNCDs are sent on all the PDCHs of the TBF. If there is a DL TBF then the PNCDs are sent on this DL TBF, even if there is an UL TBF. If there is no DL TBF then the PNCDs are sent on all the PDCHs of the UL TBF. It is to be noted that no PCA is requested to acknowledge the PCCC (No T_Ack_Wait timer (1,2s) is launched by the BSS when sending the PCCC because at the timer expiry, the mobile station has already left the CCN mode either because it has received the PCCC or because T3208=960ms has already expired and it is not necessary to send the PCCC another time). When the mobile station receives the PACKET CELL CHANGE CONTINUE message, it shall leave CCN mode and continue cell reselection in NC0 mode. It is to be noted that none of the TBFs is stopped during the CCN procedure and that it is not necessary to monitor the T_Wait_Flush timer as for PCCO in NC2. Exception: 2nd PCCN received by the BSS during T3208n Exception: Expiry of T3208n Exception: Reception of a Packet (P)SI Status message during NACC procedure Normal case: DL TBF in Delayed state Normal case: UL TBF in Delayed Final PUAN state Normal case: UL TBF in uplink extended state Abnormal case: Reception of a Flush before end of NACC procedure Abnormal case: Abnormal Release of the TBF on which the PNCDs are transmitted
station, and thus to avoid ping-pong effects. ED 01 Proposal 1

138124182.doc 03/07/2005
4.2.2
Packet (P)SI Status procedures
The Packet PSI Status procedure is a feature standardized from Release 97 onwards, optional for Release 97, Release 98 and Release 99 mobile stations, and mandatory for Release 4 onwards mobile stations supporting GERAN Feature Package 1. The Packet SI Status procedure is a new feature standardized in Release 4, mandatory for Release 4 onwards mobile stations supporting GERAN Feature Package 1. The Packet SI Status procedure (resp. Packet PSI Status procedure) takes place in the target cell. It allows the mobile station to make an access to a new cell without having previously acquired the full set of SYSTEM INFORMATION (resp. PACKET SYSTEM INFORMATION if PBCCH is present in the target cell) messages sent on the BCCH channel (resp. PBCCH) of this target cell.
ED 01 Proposal 1
138124182.doc 03/07/2005
4.2.2.1
Packet SI Status procedure
When this procedure is supported,the mobile station is only required to read the information really needed to perform GPRS operations in the new cell, contained in : - SI13, - SI1 if present - and SI3 messages. Normal case The following scenario describes the procedure
MS Cell A Cell B
RLC data block (1) Packet SI Status (SI2, SI2bis, SI2ter msg type missing) (2) scheduling of the serving cell SI messages to the MS Packet SERVING CELL DATA (SI2 message) (4) Packet SERVING CELL DATA (SI2 bis message) Packet SERVING CELL DATA (SI2 ter message) Completion of UL LLC PDU transfer RLC data block Packet Uplink Ack/nack T_PSCD_SCHEDULE_ACK (3)
Figure 20 - (1):
Packet SI Status procedure
When reselecting a new cell without a PBCCH channel and supporting the PACKET SI STATUS procedure (indicated by En_PSI_Status O&M parameter, see 4.3), the mobile station can immediately request the establishment of an uplink TBF provided it has acquired the SI13, SI3 and SI1 message (if present) of this new cell. It can then send a cell update or restarts its on-going data transfer. The Mobile station asks the BSS to provide him with the missing system information by sending a PACKET SI STATUS message on a PACCH block. When receiving the MS request, if a downlink TBF is already established, or if a downlink TBF is being established, or if a downlink TBF will soon be established (DL LLC PDU are being rerouted to the new cell), then the BSS shall wait until full establishement of the downlink TBF to send requested SIs on all the downlink PDCHs allocated to the MS. Otherwise, SIs are sent on all the PDCHs of the uplink TBF. A supervision timer (T_PSCD_SCHEDULE_ACK, see 4.3) is started to monitor the sending of the SI messages to the mobile. T_PSCD_SCHEDULE_ACK is set to 1s RTD because the MS should send a 2nd Packet (P)SI status message 1s after the first one if it has not received any answer from the BSS or if the first set of PSCDs did not include all the requested SIs. It is to be noted that the MS may send up to 4 Packet SI status messages to the BSS with an interval of 1 s between the first 2 messages and of 2 s between the subsequent messages. The SI instances are encapsulated in one or multiple instances of a PACKET SERVING CELL DATA message and sent individually to the mobile station.
- (2): - (3)
- (4)
ED 01 Proposal 1
138124182.doc 03/07/2005
When the last SI is sent to the mobile, T_PSCD_SCHEDULE_ACK is stopped (RLC indicates to RRM that all the SIs have been sent).
Exception: T_PSCD_SCHEDULE_ACK Expiry Exception: Reception of a 2nd Packet SI status T_PSCD_SCHEDULE_ACK running Exception: Reception of a PCCN during a Packet SI Status procedure Normal case: Reception of a 2nd Packet SI status after expiry of T_PSCD_SCHEDULE_ACK Normal case: Release of the TBF T_PSCD_SCHEDULE_ACK running
ED 01 Proposal 1
138124182.doc 03/07/2005
4.2.2.2
Packet PSI Status procedure
When this procedure is supported, the mobile station is only required to read the information really needed to perform GPRS operations in the new cell, contained in : - PSI1 - PSI2 messages - SI13 (or PSI14 if NACC is supported in the serving cell, SI13 and PSI14 contain almost the same information). If the feature PACKET PSI STATUS is activated in the cell (EN_PSI_STATUS = ON, see 4.3), the mobile may then send a PACKET PSI STATUS message to the BSS informing it of the list of the requested PSI messages and the list of the already received PSI messages. The network may then send the remaining packet system information messages needed by the mobile station, unless the mobile station returns to packet idle mode within the next following seconds, in which case it is able to read by itself the missing packet system information messages. The MS may indicate as supported PSI: PSI2, PSI3, PSI3bis, PSI4, PSI5, PSI3ter, PSI3quater, PSI6, PSI7 and PSI8, but the BSS can only provide PSI2, PSI3, PSI3bis, PSI3quater and PSI8. The other PSIs are not currently supported by the BSS. The PSI1 is only sent if the MS requests it explicitly. The MFS will build the list of PSI to be sent as follows : Initially, the list of PSI to be provided to the MS is : PSI2, PSI3, PSI3bis, PSI3quater and PSI8 (or less, depending on cell configuration) If a PSI is indicated as already received in the PACKET PSI STATUS, then it is removed from the list of PSIs to be provided to the MS. If a PSI is indicated as supported, but not received, in the PACKET PSI STATUS, and it is part of the PSIs existing for this cell, it is added to the list of PSIs to be sent to the MS (this applies in particular to PSI1).
Opposite to Packet SI status procedure, PSI messages are sent in a broadcasted way. Open issue : clarify the meaning of broadcasted way The following scenario describes the Packet PSI status procedure.
MS Cell A Cell B
RLC data block 1) Packet PSI Status (PSI3, PSI3bis missing) (2) scheduling of the serving cell PSI messages to the MS Packet System Information Type 3 Packet System Information Type 3bis - first instance Packet System Information Type 3bis - intermediate instance Packet System Information Type 3bis - last instance Completion of UL LLC PDU transfer RLC data block Packet Uplink Ack/nack T_PSCD_SCHEDULE_ACK (3)
Figure 21 ED 01 Proposal 1
Packet PSI Status procedure PCS BSS B9 Description

138124182.doc 03/07/2005
PCS/GSM/2005-07001
48/79
- (1):
When reselecting a new cell with a PBCCH channel and supporting the PACKET PSI STATUS procedure (indicated by En_ PSI_Status O&M parameter), the mobile station can immediately request the establishment of an uplink TBF provided it has acquired the PBCCH description (e.g. through the PSI14 message), the PSI1 and PSI2 messages of this new cell. It may then send a cell update or restart its on-going data transfer. The Mobile station asks the BSS to provide him with the missing system information by sending a PACKET PSI STATUS message on a PACCH block When receiving the MS request, if a downlink TBF is already established, or if a downlink TBF is being established, or if a downlink TBF will soon be established (DL LLC PDU are being rerouted to the new cell), then the BSS shall wait until full establishement of the downlink TBF to send requested PSIs on all the downlink PDCHs allocated to the MS. Otherwise, PSIs are sent on all the PDCHs of the uplink TBF. A supervision timer (T_PSCD_SCHEDULE_ACK) is started to monitor the sending of the PSI messages to the mobile The PSI instances are sent with the same coding as the one used for the scheduling on the PBCCH channel and sent in a distributed way to the mobile station. When the last PSI is sent to the mobile, T_PSCD_SCHEDULE_ACK is stopped (RLC indicates to RRM that all the SIs have been sent). 3
- (2): - (3)
- (4)
The other use cases related to Packet PSI Status are identical to the one of the Packet SI status. Open issue: clarify the gains of these improvements through cell reselection time reduction.
By sending PSI in a distributed way to a given MS, any other MS can take advantage of that, e.g. by requesting less PSI in a subsequent PACKET PSI STATUS message.
3
ED 01 Proposal 1
138124182.doc 03/07/2005
4.2.3
NACC procedure NC2 (Cell system information distribution in NC2 mode)
This is part of NC2 cell reselection execution procedure (4.1.7.4.2 of RRM-PRH - Ed3) Provided the Cell Change Notification feature is supported in the cell, once the BSS has decided that a cell reselection should be performed for a mobile station in Packet Transfer Mode, it checks whether the target cell belongs to the same BSS and whether the mobile station supports the acquisition of neighbour cell (P)SIs (in the MS Radio Access Capabilities). If it is the case, Packet Neighbour Cell Data (PNCDs) messages indicating the (P)SI of the target cell are sent by the BSS to the MS before sending the PCCO. This corresponds to the Cell System Information Distribution procedure in NC2 and leads to the scenario described hereafter:
MS BSS
Serving cell
BSS
Target cell
SGSN
On going UL or DL TBF (1) Packet Measurement Report / PACCH (2) Packet Neighbour Cell Data / PDCHs (4) Packet Neighbour Cell Data /PDCHs (4) Packet Cell Change Order / PACCH (5) (6) Packet Control Acknowledgement / PACCH (7) (3)
Supervision Timer
T_ Ack_Wait
Figure 22: NC cell reselection execution with Cell System Information Distribution (1) (2) (3) An UL or DL TBF is assumed on-going. The MS sends a Packet Measurement Report message on one of the allocated UL block on PACCH. Upon receipt of the Packet Measurement Report message, the BSS detects that a NC cell reselection must be triggered. It finds out that the target cell belongs to the same BSS and that the mobile station supports the acquisition of neighbour cell (P)Sis (in the MS Radio Access Capabilities). The BSS starts a timer to supervise the Packet Neighbour Cell Data sending to the mobile station. 4It sends the PNCDs to the MS, on all the PDCHs of the TBF , to transmit it the (Packet) System Information for the target cell: - SI13, SI1 and SI3 for a target cell without PBCCH - or PSI14 (containing the same information as SI13), PSI1 and a consistent set of PSI2 for a target cell with a PBCCH. In case both a UL and a DL TBF exist, PNCDs are sent on the DL TBF. When all the PNCDs have been sent or at the supervision timer expiry, the BSS orders the MS to reselect a new cell by sending a Packet Cell Change Order message on the PACCH of the DL or UL TBF. If both an UL and a DL TBFs are on-going, the message is preferentially addressed by a DL TFI.
(4)
(5)
This timer is stopped when all the PNCDs have been sent to the mobile. ED 01 Proposal 1
138124182.doc 03/07/2005
The Packet Cell Change Order message is sent in acknowledged mode and contains the ARFCN and the BSIC of the target cell plus the NC parameters of the target cell (if the MS can operate in NC2 mode in the target cell). When sending the Packet Cell Change Order message, the BSS starts the timer T_ACK_WAIT to monitor the receipt of the Packet Control Acknowledgement message. (6)-(7) Upon receipt of the Packet Cell Change Order message, the MS aborts its on-going TBF in the serving cell and sends the Packet Control Acknowledgement message. Once the MS has sent the Packet Control Acknowledgement message, the MS switches to the new cell. The rest of the scenario corresponds to the nominal case of NC cell reselection execution
4.2.4
NC2 improvement: cell ranking with load criteria
- Cell load evaluation This section describes on which criteria a target cell is considered as loaded in the cell ranking process. Indeed, when selecting the target cell for a NC cell reselection, the BSS considers the load of the candidate target cells. The MS is directed preferentially towards a target cell that is not in a high load. At initialisation, all target cells are considered in high load. a) NC2 load sampling The NC2 load is sampled every T_NC2_LOAD_RANKING (see section 4.3) seconds by dividing the used bandwidth by the total bandwidth available in the cell
NC2_Load (in %) =
with:
MAX[ UL_PS_Used_Bandwidth; DL_PS_Used_Bandwidth ] + CS_Used_Bandwidth 100 Total_PS_Bandwidth
UL_PS_used_Bandwidth => bandwidth used by PS traffic in the UL direction, DL_PS_Used_Bandwidth => bandwidth used by PS traffic in the DL direction, CS_Used_Bandwidth => bandwidth used by CS traffic Total_PS_Bandwidth => total bandwidth available in the cell.
To be completed with the description of the way the NC2 load is computed. b) NC2 load averaging The NC2 load samples are further averaged using a sliding window. The size of the sliding window is defined by the parameter NC2_LOAD_EV_PERIOD. The remaining available throughput for RT TBFs is not averaged, it is recomputed at each T_NC2_LOAD_RANKING expiry. c) Load evaluation in cells internal to the BSS
ED 01 Proposal 1
138124182.doc 03/07/2005
In each serving cell internal to the BSS, every T_NC2_LOAD_RANKING, the BSS compares the computed NC2 load of the cell to the threshold THR_NC2_LOAD_RANKING: - If the NC2 load average is lower than or equal to the threshold, the cell is considered in a low load situation - If the NC2 load average is higher than the threshold, the cell is considered in a high load situation. The MFS shares the NC2 load situation information among the different cells of the BSS (or at least between the cells having a cell reselection link with the serving cell), i.e. low/high load, NC2_UL_RT_avail and NC2_DL_RT_avail. That exchange of information is taking place every MULTI_GPU_INFO_BROADCAST_PERIOD following load calculation. d) Load evaluation in cells external to the BSS The load situation of external cells is unknown in the serving cell. The BSS computes the NC2 load of those cells as follows: - If the threshold THR_NC2_LOAD_RANKING is set to a value lower than 100 %, then the cell is considered in a low load situation. - If the threshold THR_NC2_LOAD_RANKING is set to 100 %, then the cell is considered in an high load situation.
4.3
Parameters/Timers
EN_NACC (Enables the Network Assisted Cell Change feature) En_PSI_Status (Enables the Packet SI Status feature in cells w/o PBCCH or the Packet PSI Status feature in cells with a PBCCH - cell) T_PSCD_SCHEDULE_ACK (Timer guarding on network side the sending of Packet Serving Cell Data or PSI messages for Packet (P)SI Status feature. It is started at reception of Packet PSI Status / Packet SI Status message, and stopped when all PSCDs / PSIs have been sent to the mobile (as indicated by RLC layer to RRM layer MFS level ). T_NC2_LOAD_RANKING (Period of the cell load evaluation for the NC2 cell ranking process MFS level) NC2_LOAD_EV_PERIOD (Number of NC2 load samples used to compute the NC2 load average MFS level) THR_NC2_LOAD_RANKING (Period of the cell load evaluation for the NC2 cell ranking process cell level) MULTI_GPU_INFO_BROADCAST_PERIOD (RRM reporting period to update the information (per cell) necessary for the Multi-GPU feature MFS level already in B8) T3208n (BSS side: Timer used in the NACC procedure to monitor the sending of the PCCC message. (T3208n = T3208 RoundTripDelay). T3206 (MS side: Wait for sending of the PACKET CELL CHANGE NOTIFICATION message after entering CCN mode. This timer is used to control that the MS in CCN mode is not prevented to proceed with a cell re-selection for too long if it cannot send the PACKET CELL CHANGE NOTIFICATION message (e.g. T3192 is running and there is no uplink block granted to the MS). ED 01 Proposal 1
138124182.doc 03/07/2005
T3208 (MS side: Maximum delay of the MS initiated cell re-selection after the point in time when the MS has sent the PACKET CELL CHANGE NOTIFICATION message in CCN mode.) T3210 (MS side: Wait for retransmitting the PACKET CELL CHANGE NOTIFICATION message after having sent the PACKET CELL CHANGE NOTIFICATION message for the first time. This timer is used to request the mobile station to retransmit the PACKET CELL CHANGE NOTIFICATION message in the case it has not received any PACKET NEIGHBOUR CELL DATA message nor PACKET CELL CHANGE CONTINUE message nor PACKET CELL CHANGE ORDER message in response to the sending of the PACKET CELL CHANGE NOTIFICATION message sent for the first time. It can reduce the cell re-selection delay implied by entering CCN mode in case the first PACKET CELL CHANGE NOTIFICATION message was not received by the network.)
ED 01 Proposal 1
138124182.doc 03/07/2005
5 5.1
ENHANCED E-GSM BAND HANDLING Introduction (Sub-features)
The 3GPP standard has specified a set of 1024 possible ARFCNs (0, ,1023) for GSM900, DCS1800 and DCS1900. Some of those values have already been allocated to certain frequencies (See the following table). Frequency span P-GSM band G1 band GSM850 band DCS1800 band DCS1900 band (U)ARFCNs 1 .. 124 975 .. 1023, 0 128 251 512 .. 885 512 .. 810 Uplink frequencies 890.2 to 915.0 MHz 880.2 to 890.0 MHz 824.2 MHz to 848.8 MHz 1710.2 to 1784.8 MHz 1850.2 to 1909.8 MHz Table 1: Frequency ranges In this document, the term P-GSM band refers to the primary GSM 900 band, whereas the term E-GSM band refers to the extended GSM 900 band including the P-GSM band and the extended G1 band. The term GSM900 band refers to P-GSM band, or E-GSM band, or G1 band. The ARFCNs corresponding to the R-GSM, GSM 450 and GSM 480 bands are specified in the 3GPP standard but they are not mentioned in the Table 1 because these bands are not supported by the Alcatel BSS. The list of sub-features is described here after: 5.1.1 5.1.2 Support of E-GSM networks (See Chapter 5.2.3) Support of P-GSM MS in E-GSM networks (See Chapter 5.2.3) Downlink frequencies 935.2 to 960.0 MHz 925.2 to 935.0 MHz 869.2 MHz to 893.8 MHz 1805.2 to 1879.8 MHz 1930.2 to 1989.8 MHz
5.2
5.2.1
Functional requirement
Market view
Business Case 1: P-GSM network extension with the frequencies in G1 band Business Case 2: DCS 1800 network extension with the frequencies in E-GSM band Business Case 3: full G1 network or network with mainly the frequencies in G1 band
ED 01 Proposal 1
138124182.doc 03/07/2005
5.2.2
Requirements for each business case
Idem B8 ?
BUSINESS CASE Business Case 1 (P-GSM network extension with the frequencies in G1 band)
MARKETING REQUIREMENTS This business case is partly covered by Alcatel BSS B7.2 implementation. The following improvement is required: 1. Being able to support the (E)GPRS service on E-GSM TRXs of an E-GSM cell; 2. In the monoband concentric cell, being able to support E-GSM TRXs in outer zone or in inner zone. Note that (E)GPRS service and signaling can only be supported on E-GSM TRXs of outer zone 3. The P-GSM capable only MS shall be supported (Note that this requirement is not new one, it has been implemented since B7.2).
Business Case 2 and Business Case 3
This business case is partly covered by Alcatel BSS B7.2 implementation. The following improvements are required: 1. In the E-GSM cell (section Error: Reference source not found), being able to support the (E)GPRS service on E-GSM TRXs; 2. In the E-GSM cell (section Error: Reference source not found), being able to support all types of signaling channels (BCCH, CCCH, MPDCH, etc) on any frequency belonging to the E-GSM band; 3. In the multiband concentric cell, being able to support E-GSM TRXs in outer zone or in inner zone (Note). Note: If DCS1800 TRXs are in outer zone and E-GSM TRXs are in inner zone, (E)GPRS service and signaling are not supported by E-GSM TRXs. If EGSM TRXs are in outer zone and DCS1800 TRXs are in inner zone, (E)GPRS service and signaling are supported on E-GSM TRXs; 4. In the monoband concentric cell, being able to support E-GSM TRXs in outer zone or in inner zone. Note that (E)GPRS service and signaling can only be supported on E-GSM TRXs of outer zone; 5. It is not required to support P-GSM capable only MS (This means no specific resource allocation strategy).
ED 01 Proposal 1
138124182.doc 03/07/2005
5.2.3
A Two step approach is chosen (split of the feature in 2 sub feature): Sub-feature 1 : Support of E-GSM networks Sub-feature 2 : Support of P-GSM MS in E-GSMsnetworks
All the frequencies in the P-GSM band and G1 and are considered as a whole, and all the features possible in the P-GSM band shall be possible (as far as possible) in the E-GSM band. Sub-feature1 and sub-feature 2 are equivalent from the radio-channel configuration point of view. Their difference consists only in the strategy for radio resource allocation in the E-GSM cell 5.2.3.1 Sub-feature 1 (step 1)
With sub-feature 1: the E-GSM TRX is defined as follow: frequencies in P-GSM band only; or frequencies in G1 band only; or mixing frequencies in P-GSM band and G1 band.
The (E)GPRS service is supported, without any constraint, on E-GSM TRXs; All types of signaling channels (BCCH, CCCH, MPDCH, etc) are supported, without any constraint, on E-GSM TRXs; P-GSM capable only MS is not supported, because contrary to the B7.2, P-GSM capable only MS is not ensured to be allocated with P-GSM resources(no specific resource allocation strategy for P-GSM capable only MS); In case of multiband concentric cell, specific behaviour.
- Ressource allocation strategy : As the P-GSM capable only MS is not supported, there is not specific radio resource allocation strategy in the E-GSM cell. 5.2.3.2 Sub-feature 2 (step 2)
The main improvement related to step 1 is: To support the (E)GPRS service on E-GSM TRXs of an E-GSM cell, the radio resource allocation strategy applied for P-GSM capable only MSs is different than that applied for E-GSM capable MSs . From the radio resource allocation point of view, the meaning of E-GSM TRX is changed with related to the sub-feature 1. An E-GSM TRX is re-defined as follow: frequencies in G1 band only; or mixing frequencies in P-GSM band and G1 band.
ED 01 Proposal 1
138124182.doc 03/07/2005
Ressources allocation strategy All this part is to be clarified Both P-GSM capable only MS and E-GSM capable MS are supported. It is proposed to use the following resource allocation strategy in the E-GSM cell (Figure 1): PS requests are served on E-GSM PS capable TRXs, then on P-GSM PS capable TRXs; CS requests for EGSM capable MSs are served first on E-GSM non-PS capable TRXs, then on P-GSM non-PS capable TRXs, then on P-GSM PS capable TRXs, then on E-GSM PS capable TRXs.
This strategy makes sense only if all GSM900 (E)GPRS capable MSs of the related network supports the G1 band.
E-GSM TRX PS capable
PS allocation (from higher to lower priority)
E-GSM TRX PS capable
P-GSM TRX PS capable
CS allocation (from higher to lower priority)
P-GSM TRX PS capable
Figure 1: Strategy for radio resource allocation (Sub-feature 2/ P-GSM capable only MS is supported). The Alcatel BSS does not reject the request from an (E)GPRS MS which is not E-GSM capable. In that case the MS will not answer to the assignment messages sent on G1 frequencies or allocating G1 frequencies to the MS. Note that in Figure 1 all TRXs are assumed PS capable.
5.2.4
Multiband concentric cell
To be completed 5.2.4.1 Sub-feature 1
To be completed 5.2.4.2 Sub-feature 2
To be completed 5.2.5 Compliance to the Marketing Requirements
ED 01 Proposal 1
138124182.doc 03/07/2005
FEATURE ITEM
COMPLIANCE Subfeature 1 Subfeature 2
COMMENTS
G1 TRX is a special case of E-GSM TRX; Sub-feature 1 does not support P-GSM capable only MSs, as consequence, in case of Two steps approach with only Sub-feature 1, the B7.2 solution is used for the Business Case 1 (section Error: Reference source not found)
Support of G1 TRX in P-GSM network
Not applicable
Yes
Support of E-GSM TRX Support of the Full G1 network (or a network in which the majority of frequencies belong to the G1 band) Mixing E-GSM and GSM 1800 frequencies in the multiband cell configurations Mixing P-GSM and G1 frequencies in the same FHS. Support of P-GSM capable only MS Support of E-GSM capable MS
Yes
Yes In case of Two steps approach with only Subfeature 1, P-GSM capable only MSs are not supported. If DCS1800 TRXs are in outer zone and E-GSM TRXs are in inner zone, (E)GPRS service and signaling are not supported by E-GSM TRXs. If EGSM TRXs are in outer zone and DCS1800 TRXs are in inner zone, E)GPRS service and signaling are supported on E-GSM TRXs;
Yes
Yes
Yes
Yes
Yes No Yes
No Yes Yes Hopping E-GSM PS capable TRXs are not supported.
ED 01 Proposal 1
138124182.doc 03/07/2005
5.2.6
Working assumptions
1. The one MA (Mobile Allocation) at the most used for GPRS constraint remains valid with the Enhanced packet cell reselection feature. 2. (E)GPRS service and signaling are not supported on E-GSM TRXs in inner zone; 3. The new radio resource allocation strategy is based on the hypotheses that all GSM900 (E)GPRS MSs are assumed E-GSM capable and compliant to Phase 2 of 3GPP standard . 4. For the Business Case 1(P-GSM network extension with the frequencies in G1 band), (E)GPRS service is only supported on the non-hopping E-GSM TRXs of an E-GSM cell. Open issue: Explain point 4 5. There is no specific requirement on the TRX/RSL mapping algorithm. As consequence, in case of mixed hardware configuration in a cell with both G3 and G4 TREs in the same cell, it is recommended to map to E-GSM TRX on G4 TRE and P-GSM TRX on G3 TRX. To have this mapping result, the TRX_PREF_MARK parameter should be set to: zero for the E-GSM TRXs; non-zero value for the P-GSM TRXs.
The consequence of above recommended rule for TRX_PREF_MARK parameter is that there is no (E)GPRS service on P-GSM TRX. Open issue: last sentence to be confirmed because, it not acceptable for GPRS only Msworking on PGSM band (many GPRS MS)
5.3
Parameters/Timers
EGSM_RR_Alloc_Strategy (Defines the radio resource allocation strategy used in EGSM cells BSS level) Explain the different possible values for the previous parameter. PLMN_FREQUENCY_BANDS (Frequency bands used in the whole PLMN - BSS level already in B8) PLMN_FREQUENCY_BANDS (Frequency bands used in the whole PLMN - MFS level already in B8)
5.4
None
Dependencies
5.5
HW coverage
BSC G2, MFS : SW impact OMC-R, POLO, OEF, RNO, MSTS : SW impact
ED 01 Proposal 1
138124182.doc 03/07/2005
6 6.1
IMPROVED 3G CELL RESELECTION TO BE COMPLETED Functional requirement
The feature is not an optional feature. It contains 4 main requirements: Requirement 1: UTRAN FDD neighbourhood information conveyed in SI2quater on BCCH Requirement 2: Cell instanciation of the UTRAN FDD neighbourhood information Requirement 3: UTRAN FDD cells description with Scrambling codes Requirement 4: BSS instanciation of UTRAN frequencies
6.2 6.3
Overall Description of the proposed solutions Parameters/Timers
9 parameters to be added..
6.4
Dependencies
The feature is enhanced by non blind 2G to 3G handover, extended BCCH, SI13 BCCH configurability. The feature will be enhanced by 2G to 3G handover. The feature decrease the interest of .
6.5
HW coverage
BTS A9100, BTS A9110 (M4M), BTS A9110-E (M5M), BSC G2, MFS: SW impact OMC-R, POLP, OEF, RNO: SW impact.
ED 01 Proposal 1
138124182.doc 03/07/2005
ANNEX A 3GPP 44060
3GPP 44060 4.18.0
7.1
Packet Uplink Ack/Nack
This message is sent on the PACCH by the network to the mobile station indicate the status of the received RLC data blocks. This message may also update the timing advance and power control parameters. A fixed allocation mobile station may also be assigned uplink resources. Message type: PACKET UPLINK ACK/NACK Direction: Classification: network to mobile station non-distribution message Table A.1.1: PACKET UPLINK ACK/NACK information elements
< Packet Uplink Ack/Nack message content > ::= < PAGE MODE : bit (2) > { 00 < UPLINK_TFI : bit (5) > {0 -- Message escape { < CHANNEL_CODING_COMMAND : bit (2) > < Ack/Nack Description : < Ack/Nack Description IE > > {0|1 < CONTENTION_RESOLUTION_TLLI : bit (32) > } {0|1 < Packet Timing Advance : < Packet Timing Advance IE > > } {0|1 < Power Control Parameters : < Power Control Parameters IE > > } {0|1 < Extension Bits : Extension Bits IE > } -- sub-clause 12.26 {0|1 < Fixed Allocation Parameters : < Fixed Allocation struct > > } { null | 0 bit** = < no string > -- Receiver backward compatible with earlier version |1 -- Additions for R99 { 0 | 1 <Packet Extended Timing Advance : bit (2)>} <TBF_EST : bit (1)> < padding bits > } ! < Non-distribution part error : bit (*) = < no string > > } |1 -- Message escape bit used to define EGPRS message contents { 00 { < EGPRS Channel Coding Command : < EGPRS Modulation and Coding IE >> < RESEGMENT : bit (1) > < PRE_EMPTIVE_TRANSMISSION : bit (1) > < PRR RETRANSMISSION REQUEST : bit (1) > < ARAC RETRANSMISSION REQUEST : bit (1) > {0|1 < CONTENTION_RESOLUTION_TLLI : bit (32) > } <TBF_EST : bit (1)> {0|1 < Packet Timing Advance : < Packet Timing Advance IE > > } {0|1 <Packet Extended Timing Advance : bit (2)> } {0|1 < Power Control Parameters : < Power Control Parameters IE > > } {0|1 < Extension Bits : Extension Bits IE > } -- subclause 12.26 { < EGPRS Ack/Nack Description : < EGPRS Ack/Nack Description IE > > {0|1 < Fixed Allocation Parameters : < Fixed Allocation struct > > } } // < padding bits > ! < Non-distribution part error : bit (*) = < no string > > } ! < Message escape : {01| 10 | 11} bit (*) = <no string> > } } -- Extended for future changes ! < Address information part error : bit (*) = < no string > > } ! < Distribution part error : bit (*) = < no string > > ; < Fixed Allocation struct > ::= < FINAL_ALLOCATION : bit (1) >
ED 01 Proposal 1
138124182.doc 03/07/2005
{0 |1
-- Repeat Allocation < TS_OVERRIDE : bit (8) > -- Allocation with Allocation bitmap < TBF Starting Time : < Starting Frame Number Description IE > > {0|1 <TIMESLOT_ALLOCATION : bit (8) > } {0{0 -- with length of Allocation Bitmap < BLOCKS_OR_BLOCK_PERIODS : bit (1) > < ALLOCATION_BITMAP_LENGTH : bit (7) > < ALLOCATION_BITMAP : bit (val(ALLOCATION_BITMAP_LENGTH)) > |1 -- without length of Allocation Bitmap (fills remainder of the message) < ALLOCATION_BITMAP : bit ** > } ! < Message escape : 1 bit (*) = <no string> > };
Table A.1.2: PACKET UPLINK ACK/NACK information element details PAGE_MODE This field is defined in sub-clause 12.20. (2 bit field)
UPLINK_TFI (5 bit field) This field identifies the uplink TBF to which this message applies. This field is coded the same as the TFI field defined in sub-clause 12.15. (range : 0 to 31) CHANNEL_CODING_COMMAND (2 bit field) The Channel Coding Indicator field indicates the channel coding scheme that the mobile station shall use when transmitting on the uplink. bits 21 00 01 10 11 value CS-1 CS-2 CS-3 CS-4 Description
Ack/Nack This information element is defined in sub-clause 12.3.
EGPRS Modulation and Coding Scheme The EGPRS Modulation and Coding Scheme information element is defined in sub-clause 12.10d.1 RESEGMENT (1 bit This field is defined in sub-clause 12.10e. (value 0: no resegmentation or 1: resegmentation) field)
PRE_EMPTIVE_TRANSMISSION (1 bit field) This bit informs the mobile station if it may or may not transmit the oldest RLC data block whose corresponding element in V(B) has the value PENDING_ACK (and repeating the process, refer to subclause 9.1.3.2) when the protocol is stalled or has no more RLC data blocks to transmit. 0 1 The mobile station shall not use The mobile station shall use pre-emptive transmission. pre-emptive transmission.
PRR RETRANSMISSION REQUEST (1 bit field) 0 1 indicates that retransmission of a PACKET RESOURCE REQUEST message is not requested indicates that retransmission of a PACKET RESOURCE REQUEST message is requested
ED 01 Proposal 1
138124182.doc 03/07/2005
ARAC RETRANSMISSION REQUEST (1 bit field) 0 indicates that retransmission of an ADDITIONAL MS RADIO ACCESS CAPABILITIES message is not requested 1 indicates that retransmission of an ADDITIONAL MS RADIO ACCESS CAPABILITIES message is requested EGPRS Ack/Nack Description This information element is defined in sub-clause 12.3.1. The number of bits (L) available for Ack/Nack Description information element depends on the inclusion of other information elements. L may be set so that the entire EGPRS PACKET UPLINK ACK/NACK message evenly fits into an RLC/MAC control block. If a lower L covers the entire receive window, that L may be used. CONTENTION_RESOLUTION_TLLI (32 bit field) The CONTENTION_RESOLUTION_TLLI field is present only if the network has decoded one of the uplink RLC data blocks containing the TLLI. The mobile station shall perform the contention resolution function if the TLLI information element is present. This field contains a TLLI, which is defined in sub-clause 12.16. Packet Timing This information element is defined in sub-clause 12.12. TIMESLOT_ALLOCATION This field is defined in sub-clause 12.18. (8 bit Advance field)
Power Control Parameters This information element, if present, contains power control command for the mobile station. If this information element is not present for certain previously allocated timeslots, the MS shall continue to use the previous power on these timeslots. This information element is defined in sub-clause 12.13. Extension Bits This information element, if present, shall be skipped over. Any information content shall be ignored by the mobile station. This information element is defined in sub-clause 12.26. FINAL_ALLOCATION (1 bit This field indicates whether this allocation is the last allocation of the TBF. 0 1 this allocation is not the this allocation is the last allocation of the TBF last allocation of the field) TBF
Repeat Allocation If present, the mobile station shall repeat the current allocation after the current allocation ends. TS_OVERRIDE This is defined in sub-clause 12.19. (8 bit field)
Allocation with Allocation bitmap If present, the mobile station shall use the included Allocation bitmap and associated parameters. The mobile station shall not repeat the current allocation after the current allocation ends. BLOCKS_OR_BLOCK_PERIODS (1 bit This indicates if the ALLOCATION_BITMAP is to be interpreted as blocks or block periods. 0 1 the ALLOCATION_BITMAP is to be the ALLOCATION_BITMAP is to be interpreted as block periods (7 interpreted bit as field) blocks field)
ALLOCATION_BITMAP_LENGTH ED 01 Proposal 1
138124182.doc 03/07/2005
This field Range 0 to 127
specifies
the
number
of
bits
in
the
ALLOCATION_BITMAP.
TBF Starting Time The TBF Starting Time field contains a starting time that indicates the earliest frame number during which the assigned TBF may start. In case of dynamic allocation, the MS shall continue to use the parameters of the existing TBF until the TDMA frame number occurs. When the indicated TDMA frame number occurs, the mobile station shall immediately begin to monitor the USF field and use the new assigned uplink TBF parameters when its USF has occurred. In case of fixed allocation, the MS shall continue to use the parameters of the existing TBF until the TDMA frame number occurs. When the TDMA frame number occurs, the MS shall then use the assigned uplink resources from the indicated TDMA frame number forward, according to the parameters in the fixed allocation struct. This information element is defined in sub-clause 12.21. ALLOCATION_BITMAP (variable length field) The ALLOCATION_BITMAP field is variable length. If the ALLOCATION_BITMAP_LENGTH field is not present, the ALLOCATION_BITMAP fills the remainder of the message. If the BLOCKS_OR_BLOCK_PERIODS field is not present, then the ALLOCATION_BITMAP should be interpreted as blocks. This field is defined in sub-clause 12.4. Packet Extended Timing This field is defined in sub-clause 12.12b. Advance (2 bit field)
TBF_EST (1 bit field) If included, this field indicates that the mobile station is allowed to request the establishment of new TBF on PACCH. 0 1 7.1.1 the mobile station is not allowed to request the establishment of new TBF the mobile station is allowed to request the establishment of new TBF 11.2.16 Packet Resource Request
This message is sent on the PACCH by the mobile station to the network to request a change in the uplink resources assigned. Message type: PACKET RESOURCE REQUEST Direction: mobile station to network
ED 01 Proposal 1
138124182.doc 03/07/2005
Table 11.2.16.1: PACKET RESOURCE REQUEST information elements

< Packet Resource Request message content > ::= { 0 | 1 < ACCESS_TYPE : bit (2) > } { 0 < Global TFI : < Global TFI IE > > | 1 < TLLI : < TLLI IE > > } { 0 | 1 < MS Radio Access Capability 2 : < MS Radio Access Capability 2 IE > > } < Channel Request Description : < Channel Request Description IE > > { 0 | 1 < CHANGE_MARK : bit (2) > } < C_VALUE : bit (6) > { 0 | 1 < SIGN_VAR : bit (6) >} { 0 | 1 < I_LEVEL_TN0 : bit (4) > } { 0 | 1 < I_LEVEL_TN1 : bit (4) > } { 0 | 1 < I_LEVEL_TN2 : bit (4) > } { 0 | 1 < I_LEVEL_TN3 : bit (4) > } { 0 | 1 < I_LEVEL_TN4 : bit (4) > } { 0 | 1 < I_LEVEL_TN5 : bit (4) > } { 0 | 1 < I_LEVEL_TN6 : bit (4) > } { 0 | 1 < I_LEVEL_TN7 : bit (4) > } { null | 0 bit** = <no string> -- Receiver backward compatible with earlier version |1 -- Additional contents for Release 1999 { 0 | 1 < EGPRS BEP Link Quality Measurements : < EGPRS BEP Link Quality Measurements IE >> } { 0 | 1 < EGPRS Timeslot Link Quality Measurements : < EGPRS Timeslot Link Quality Measurements IE >>} { 0 | 1 < PFI: bit(7) > } < ADDITIONAL MS RAC INFORMATION AVAILABLE : bit (1) > < RETRANSMISSION OF PRR : bit (1) > < padding bits > } ;
Table 11.2.16.2: PACKET RESOURCE REQUEST information element details Global TFI This information element contains the TFI of the mobile station's uplink TBF, if available, or the TFI of the mobile station's downlink TBF. If no TFI is available, this field is omitted. This field is defined in sub-clause 12.10. ACCESS_TYPE (2 bit field) This field indicates the reason for requesting the access. It shall be included only in response to a single block or Multi block assignment. bit 2 00 01 10 11 1 Request Response Update
Two Phase Page Cell Mobility Management procedure
Access
TLLI This information element is defined in sub-clause 12.16. MS Radio Access Capability 2 This information element is defined in sub-clause 12.30. This information element is sent only during two phase access. Channel Request This information element is defined in sub-clause 12.7. CHANGE_MARK ED 01 Proposal 1
138124182.doc 03/07/2005
Description bit field) PCS BSS B9 Description PCS/GSM/2005-07001 65/79
(2
This field contains the PSI2_CHANGE_MARK value stored by the mobile station's if PBCCH is present in the current cell. If PBCCH is not present in the current cell, this field contains the SI13_CHANGE_MARK value stored by the mobile station. If the mobile station does not have a valid PSI2 or SI13 change mark for the current cell, the mobile station shall omit this field. The coding of this field is network dependent. C_VALUE (6 bit field) This field is encoded as the binary representation of the C value as specified in 3GPP TS 45.008. Range 0 to 63 SIGN_VAR (6 bits) This field contains the signal variance parameter SIGN_VAR calculated by the mobile station (see 3GPP TS 45.008). This field is not present for TBF establishment using two phase access or for a TBF in EGPRS mode. bit 6 000000 000001 000010 : 111110 111111 5 0dB2 >0.25 >0.50 : >15.50 >15.75 dB2 dB2 to 4 to dB2 dB2 to to : 15.75 dB2 3 0.25 0.50 0.75 2 1 dB2 dB2 dB2
I_LEVEL_TN0 (4 bit field) I_LEVEL_TN1 (4 bit field) I_LEVEL_TN2 (4 bit field) I_LEVEL_TN3 (4 bit field) I_LEVEL_TN4 (4 bit field) I_LEVEL_TN5 (4 bit field) I_LEVEL_TN6 (4 bit field) I_LEVEL_TN7 (4 bit field) For element definition see sub-clause 11.2.6 Packet Downlink Ack/Nack. These fields shall not be present if they are included in the EGPRS Timeslot Link Quality Measurements IE. EGPRS BEP Link Quality Measurements IE This information element is defined in sub-clause 12.5.3. These fields are transferred if the data is available and if the fields would not cause the message to expand beyond one RLC/MAC control block and if the PACKET RESOURCE REQUEST is sent during on-going EGPRS concurrent TBF. EGPRS Timeslot Link Quality Measurements This information element is defined in sub-clause 12.5.4. These fields are transferred if the data is available and if the fields would not cause the message to expand beyond one RLC/MAC control block and if the PACKET RESOURCE REQUEST is sent during on-going EGPRS TBF. PFI (7 bit field) This field contains the PFI parameter identifying a Packet Flow Context. The PFI parameter is encoded as the contents of the PFI information element as defined in 3GPP TS 44.018. This field may be included if the network supports packet flow context procedures. ADDITIONAL MS RAC INFORMATION AVAILABLE (1 bit field) 0 1 indicates that the MS will not send more information about its radio access capabilities than included in this message indicates that the MS will provide more information about its radio access capabilities by sending an ADDITIONAL MS RADIO ACCESS CAPABILITIES message, either in the next radio block allocated to the mobile station on the assigned PDCH, or upon a further request from the network if the mobile PCS BSS B9 Description
138124182.doc 03/07/2005
ED 01 Proposal 1
PCS/GSM/2005-07001
66/79
station was allocated only one radio block. RETRANSMISSION OF PRR (1 bit field) This field indicates whether the corresponding Packet Resource Request message is a retransmission. In case the PRR message is a retransmission, the message content (except this field and the address information) shall be identical to the one of the PRR which was sent immediately after the uplink TBF was established (and preceding any eventual request for resource reassignment). 0 1 indicates that this message is an initial Packet Resource Request indicates that this message is a retransmitted Packet Resource Request: in this case the corresponding PRR message shall not be interpreted as a request for resource reassignment.
ED 01 Proposal 1
138124182.doc 03/07/2005
ANNEX B 3GPP 48018
3GPP-48018 (4.7.0)
8.1
RA-CAPABILITY-UPDATE
This PDU requests that the SGSN send an MS's current Radio Access capability or IMSI to the BSS. PDU type: RA-CAPABILITY-UPDATE Direction: BSS to SGSN Table 10.3.3: RA-CAPABILITY-UPDATE PDU content
Information element Type / Reference PDU type PDU type/11.3.26 TLLI TLLI/11.3.35 Tag Tag/11.3.34 Presence M M M Format V TLV TLV Length 1 6 3
8.1.1
RA-CAPABILITY-UPDATE-ACK
This PDU provides the BSS with an MS's current Radio Access capability and IMSI. PDU type: RA-CAPABILITY-UPDATE-ACK Direction: SGSN to BSS Table 10.3.4: RA-CAPABILITY-UPDATE-ACK PDU content
Information element PDU type TLLI Tag IMSI a) RA-Cap-UPDCAUSE MS Radio Access Capability Type / Reference PDU type/11.3.26 TLLI/11.3.35 Tag/11.3.34 IMSI/11.3.14 RA-Cap-UPDCAUSE/11.3.30 MS Radio Access Capability/11.3.22 Presence M M M C M C Format V TLV TLV TLV TLV TLV Length 1 6 3 5 -10 3 7-?
a) If RA-Cap-UPD-CAUSE indicates failure of the RA-CAPABILITY-UPDATE procedure due to TLLI unknown in SGSN the IMSI IE will not be present. Otherwise, the IMSI will be present.
ED 01 Proposal 1
138124182.doc 03/07/2005
8.2
DL-UNITDATA
This PDU is sent to the BSS to transfer an LLC-PDU across the radio interface to an MS. PDU type: DL-UNITDATA Direction: SGSN to BSS Table 10.2.1: DL-UNITDATA PDU contents
Information element PDU type TLLI (current) QoS Profile PDU Lifetime MS Radio Access Capability a) Priority DRX Parameters IMSI TLLI (old) PFI LSA Information Service UTRAN CCO Alignment octets LLC-PDU b) Type / Reference PDU type/11.3.26 TLLI/11.3.35 QoS Profile/11.3.28 PDU Lifetime/11.3.25 MS Radio Access Capability/11.3.22 Priority/11.3.27 DRX Parameters/11.3.11 IMSI/11.3.14 TLLI/11.3.35 PFI/1.3.42 LSA Information/11.3.19 Service UTRAN CCO /11.3.47. Alignment octets/11.3.1 LLC-PDU/11.3.15 Presence M M M M O O O O O O O O O M Format V V V TLV TLV TLV TLV TLV TLV TLV TLV TLV TLV TLV Length 1 4 3 4 7-? 3 4 5 10 6 3 7-? 3 2-5 2-?
a) The field shall be present if there is valid MS Radio Access Capability information known by the SGSN; the field shall not be present otherwise. b) The LLC-PDU Length Indicator may be zero.
ED 01 Proposal 1
138124182.doc 03/07/2005
3GPP-24008 4.14.0
ED 01 Proposal 1
ANNEX C 3GPP 24008
138124182.doc 03/07/2005
PCS/GSM/2005-07001
70/79
Table 10.5.146/3GPP TS 24.008: Mobile Station Radio Access Capability Information Element < MS Radio Access capability IE > ::= <MS Radio Access capability IEI : 00100100 > <Length of MS RA capability : <octet>> -- length in octets of MS RA capability value part and spare bits <MS RA capability value part : < MS RA capability value part struct >> <spare bits>**; -- may be used for future enhancements <MS RA capability value part struct >::= -- recursive structure allows any number of Access technologies { { < Access Technology Type: bit (4) exclude 1111 > < Access capabilities : <Access capabilities struct> > } | { capabilities < Access Technology Type: bit (4) == 1111 > -- structure adding Access technologies with same
< Length : bit (7) > -- length in bits of list of Additional access technologies and spare bits { 1 < Additional access technologies: < Additional access technologies struct > > } ** 0 <spare bits>** } }
{ 0 | 1 <MS RA capability value part struct> } ; < Additional access technologies struct > ::= < Access Technology Type : bit (4) > < GMSK Power Class : bit (3) > < 8PSK Power Class : bit (2) > ; < Access capabilities struct > ::= < Length : bit (7) > -- length in bits of Content and spare bits <Access capabilities : <Content>> <spare bits>** ; -- expands to the indicated length -- may be used for future enhancements < Content > ::= < RF Power Capability : bit (3) > { 0 | 1 <A5 bits : <A5 bits> > } -- zero means that the same values apply for parameters as in the immediately preceding Access capabilities field within this IE < ES IND : bit > < PS : bit > < VGCS : bit > < VBS : bit > { 0 | 1 < Multislot capability : Multislot capability struct > } -- zero means that the same values for multislot parameters as given in an earlier Access capabilities field within this IE apply also here -- Additions in release 99 { 0 | 1 < 8PSK Power Capability : bit(2) >} -- '1' also means 8PSK modulation capability in uplink. < COMPACT Interference Measurement Capability : bit > < Revision Level Indicator : bit > < UMTS FDD Radio Access Technology Capability : bit > -- 3G RAT < UMTS 3.84 Mcps TDD Radio Access Technology Capability : bit > -- 3G RAT < CDMA 2000 Radio Access Technology Capability : bit > -- 3G RAT -- Additions in release 4 < UMTS 1.28 Mcps TDD Radio Access Technology Capability : bit > -- 3G RAT < GERAN Feature Package 1 : bit > { 0 | 1 < Extended DTM GPRS Multi Slot Class : bit(2) > < Extended DTM EGPRS Multi Slot Class : bit(2) > } < Modulation based multislot class support : bit > ; -- error: struct too short, assume features do not exist -- error: struct too long, ignore data and jump to next Access technology
ED 01 Proposal 1
138124182.doc 03/07/2005
Table 10.5.146/3GPP TS 24.008 (continued): Mobile Station Radio Access Capability IE
ED 01 Proposal 1
138124182.doc 03/07/2005
< Multislot capability struct > ::= { 0 | 1 < HSCSD multislot class : bit (5) > } { 0 | 1 < GPRS multislot class : bit (5) > < GPRS Extended Dynamic Allocation Capability : bit > } { 0 | 1 < SMS_VALUE : bit (4) > < SM_VALUE : bit (4) > } -- Additions in release 99
{ 0 | 1 < ECSD multislot class : bit (5) > }
{ 0 | 1 < EGPRS multislot class : bit (5) > < EGPRS Extended Dynamic Allocation {0 | 1< DTM GPRS Multi Slot Class: bit(2)> <Single Slot DTM : bit> {0 | 1 <DTM EGPRS Multi Slot Class : bit(2)> } } ; -- error: struct too short, assume features do not exist
Capability : bit > }
<A5 bits> ::= < A5/1 : bit> <A5/2 : bit> <A5/3 : bit> <A5/4 : bit> <A5/5 : bit> <A5/6 : bit> <A5/7 : bit>; -- bits for circuit mode ciphering algorithms. These fields are not used by the network and may be excluded by the MS. Access Technology Type This field indicates the access technology type to be associated with the following access capabilities. Bits 4321 0000 GSM P 0001 GSM E --note that GSM E covers GSM P 0010 GSM R --note that GSM R covers GSM E and GSM P 0011 GSM 1800 0100 GSM 1900 0101 GSM 450 0110 GSM 480 0111 GSM 850 1000 GSM 700 1111 Indicates the presence of a list of Additional access technologies All other values are treated as unknown by the receiver. A MS which does not support any GSM access technology type shall set this field to '0000'. RF Power Capability, GMSK Power Class (3 bit field) This field contains the binary coding of the power class used for GMSK associated with the indicated Access Technology Type (see 3GPP TS 45.005). A MS which does not support any GSM access technology type shall set this field to '000'. 8PSK Power Capability (2 bit field) If 8-PSK modulation is supported for uplink, this field indicates the radio capability for 8-PSK modulation. The following coding is used (see 3GPP TS 45.005 [33]): Bits 2 1 00 Reserved 01 Power class E1 10 Power class E2 11 Power class E3 8PSK Power Class (2 bit field) This field indicates the radio capability for 8-PSK modulation. The following coding is used (see 3GPP TS 45.005): Bits 2 1 00 8PSK modulation not supported for uplink 01 Power class E1 10 Power class E2 11 Power class E3 Additional access technologies struct This structure contains the GMSK Power Class and 8PSK Power Class for an additional Access Technology. All other capabilities for this indicated Access Technology are the same as the capabilities indicated by the preceding Access capabilities struct. A5/1 0 encryption algorithm A5/1 not available 1 encryption algorithm A5/1 available A5/2
ED 01 Proposal 1
138124182.doc 03/07/2005
ED 01 Proposal 1
138124182.doc 03/07/2005
PCS/GSM/2005-07001
74/79
Table 10.5.146/3GPP TS 24.008 (concluded): Mobile Station Radio Access Capability IE
ED 01 Proposal 1
138124182.doc 03/07/2005
PS (Pseudo Synchronisation) 0 PS capability not present 1 PS capability present VGCS (Voice Group Call Service) 0 no VGCS capability or no notifications wanted 1 VGCS capability and notifications wanted. VBS (Voice Broadcast Service) 0 no VBS capability or no notifications wanted 1 VBS capability and notifications wanted
HSCSD
Multi
Slot
Class
The Multi Slot Class field is coded as the binary representation of the multislot class defined in 3GPP TS 45.002 [32]. This field is not used by the network and may be excluded by the MS. Range 1 to 18, all other values are reserved.
GPRS
Multi
Slot
Class
The GPRS Multi Slot Class field is coded as the binary representation of the multislot class defined in 3GPP TS 45.002 [32].
ECSD
Multi
Slot
Class
The presence of this field indicates ECSD capability. Whether the MS is capable of 8-PSK modulation in uplink is indicated by the presence of 8-PSK Power Capability field. The Multi Slot Class field is coded as the binary representation of the multislot class defined in 3GPP TS 45.002 [32]. This field is not used by the network and may be excluded by the MS. Range 1 to 18, all other values are reserved. EGPRS Multi Slot Class The presence of this field indicates EGPRS capability. Whether the MS is capable of 8-PSK modulation in uplink is indicated by the presence of 8-PSK Power Capability field. The EGPRS Multi Slot Class field is coded as the binary representation of the multislot class defined in 3GPP TS 45.002 [32]. GPRS Extended Dynamic Allocation Capability 0 Extended Dynamic Allocation Capability for GPRS is not implemented 1 Extended Dynamic Allocation Capability for GPRS is implemented EGPRS Extended Dynamic Allocation Capability 0 Extended Dynamic Allocation Capability for EGPRS is not implemented 1 Extended Dynamic Allocation Capability for EGPRS is implemented SMS_VALUE (Switch-Measure-Switch) (4 bit field) The SMS field indicates the time needed for the mobile station to switch from one radio channel to another, perform a neighbor cell power measurement, and the switch from that radio channel to another radio channel. This field is not used by the network and may be excluded by the MS. Bits 4321 0000 1/4 timeslot (~144 microseconds) 0001 2/4 timeslot (~288 microseconds) 0010 3/4 timeslot (~433 microseconds) ... 1111 16/4 timeslot (~2307 microseconds) (SM_VALUE) Switch-Measure (4 bit field) The SM field indicates the time needed for the mobile station to switch from one radio channel to another and perform a neighbour cell power measurement. This field is not used by the network and may be excluded by the MS.
Bits 4321 0000 0001 0010 ... 1111
1/4 timeslot (~144 microseconds) 2/4 timeslot (~288 microseconds) 3/4 timeslot (~433 microseconds) 16/4 timeslot (~2307 microseconds) PCS BSS B9 Description
138124182.doc 03/07/2005
ED 01 Proposal 1
PCS/GSM/2005-07001
76/79
ED 01 Proposal 1
138124182.doc 03/07/2005
PCS/GSM/2005-07001
77/79
DTM GPRS Multi Slot Class (2 bit field) This field indicates the DTM GPRS multislot capabilities of the MS. It is coded as follows: Bits 21 00 Unused. If received, the network shall interpret this as 01 01 Multislot class 5 supported 10 Multislot class 9 supported 11 Multislot class 11 supported Single Slot DTM (1 bit field) This field indicates whether the MS supports single slot DTM operation (see 3GPP TS 43.055 [87]). Bit 1 0 Single Slot DTM not supported 1 Single Slot DTM supported DTM EGPRS Multi Slot Class (2 bit field) This field indicates the DTM EGPRS multislot capabilities of the MS. This field shall be included only if the mobile station supports DTM EGPRS. This field is coded as the DTM GPRS multislot Class field. COMPACT Interference Measurement Capability (1 bit field) Bit 0 COMPACT Interference Measurement Capability is not implemented 1 COMPACT Interference Measurement Capability is implemented Revision Level Indicator (1 bit field) Bit 0 The ME is Release 98 or older 1 The ME is Release 99 onwards UMTS FDD Radio Access Technology Capability (1 bit field) Bit 0 UMTS FDD not supported 1 UMTS FDD supported UMTS 3.84 Mcps TDD Radio Access Technology Capability (1 bit field) Bit 0 UMTS 3.84 Mcps TDD not supported 1 UMTS 3.84 Mcps TDD supported CDMA 2000 Radio Access Technology Capability (1 bit field) Bit 0 CDMA2000 not supported 1 CDMA2000 supported UMTS 1.28 Mcps TDD Radio Access Technology Capability (1 bit field) Bit 0 UMTS 1.28 Mcps TDD not supported 1 UMTS 1.28 Mcps TDD supported GERAN Feature Package 1 (1 bit field) This field indicates whether the MS supports the GERAN Feature Package 1 (see 3GPP TS 44.060). It is coded as follows: Bit 0 GERAN feature package 1 not supported. 1 GERAN feature package 1 supported. DTM Extended GPRS Multi Slot Class (2 bit field) This field indicates the extended DTM GPRS capabilities of the MS and shall be interpreted in conjunction with the DTM GPRS Multi Slot Class field. It is coded as follows, where DGMSC denotes the DTM GPRS multislot class field: DGMSC Bit 21 Bit 2 1 00 00 Unused. If received, it shall be interpreted as 01 00 00 01 Unused. If received, it shall be interpreted as 01 00 00 10 Unused. If received, it shall be interpreted as 01 00 00 11 Unused. If received, it shall be interpreted as 01 00 01 00 Multislot class 5 supported
ED 01 Proposal 1
138124182.doc 03/07/2005
ED 01 Proposal 1
138124182.doc 03/07/2005
PCS/GSM/2005-07001
79/79

BSSB9 Description UL EGPRS Resel EGSM

Uploaded by

Document Information

Original Description:

Original Title

Copyright

Available Formats

Share this document

Share or Embed Document

Sharing Options

Did you find this document useful?

Is this content inappropriate?

Copyright:

Available Formats

BSSB9 Description UL EGPRS Resel EGSM

Uploaded by

Copyright:

Available Formats

All rights reserved.

PCS BSS B9 Description PCS/GSM/2005-07001 1/79

PCS BSS B9 Description PCS/GSM/2005-07001 2/79

INTERNAL REFERENCED DOCUMENTS

RELATED DOCUMENTS PREFACE

PCS BSS B9 Description PCS/GSM/2005-07001 3/79

PCS BSS B9 Description PCS/GSM/2005-07001 4/79

ENHANCED SUPPORT OF E-GPRS IN UL

Overall description of 8-PSK in UL sub-feature

PCS BSS B9 Description PCS/GSM/2005-07001 5/79

RLC data block

PCS BSS B9 Description PCS/GSM/2005-07001 6/79

MS (EGPRS PACKET) Channel Request scenario 1 : request is rejected

Immediate Assignment Reject scenario 2 : request is accepted Immediate Assignment

Wait T_USF_Scheduling_AGCH USF Scheduling RLC data block

PCS BSS B9 Description PCS/GSM/2005-07001 7/79

Bit Number (BN) 0 8 49 85 (88

(below) (below) 45.003 (below) subclause 5.2.8)

PCS BSS B9 Description PCS/GSM/2005-07001 8/79

PCS BSS B9 Description

scenario 3 : request is rejected Packet Access Reject

PCS BSS B9 Description PCS/GSM/2005-07001 10/79

scenario 3 : request is rejected Packet Access Reject

PCS BSS B9 Description PCS/GSM/2005-07001 11/79

(EGPRS) Packet Downlink Ack/Nack request is rejected

Packet Access Reject OR request is accepted

Packet Uplink Assignment ... Packet Uplink Assignment USF scheduling

Start of UL transfer RLC data block

PCS BSS B9 Description PCS/GSM/2005-07001 12/79

PCS BSS B9 Description PCS/GSM/2005-07001 13/79

Contention Resolution with MCS5 to MCS9

PCS BSS B9 Description PCS/GSM/2005-07001 14/79

Overall description of Incremental Redundancy in UL sub-feature

The features shall be supported by systems

PCS BSS B9 Description PCS/GSM/2005-07001 15/79

GSM 900 DCS 1800 / DCS 1900 GSM 850

See Chapter 2.4 2.5.2 MFS Counter Catalogue

PCS BSS B9 Description PCS/GSM/2005-07001 16/79

EXTENDED UL TBF MODE (PART OF MS GERAN FEATURE PACKAGE 1) Introduction

PCS BSS B9 Description PCS/GSM/2005-07001 17/79

Reminder : B8 normal UL TBF release behaviour

LLC PDU (last LLC)

PCC-RLC-Release-ind (3) PRH-PDTCH-Deassign-req (4) PRH-PDTCH-Deassign-cnf (5) RL-UL-Stop-req (6)

PCS BSS B9 Description PCS/GSM/2005-07001 18/79

RLC/MAC block (BSN = n,CV=0) (1)

LLC PDU (last LLC) (2) PCC-RLC-activate-req DFPUAN (3)

P. UL Ack/Nack (FAI=0, SSN = n) T3180 PCC-RLC-activate-cnf T3180n T_DELAYED_ FINAL_PUAN

final P. UL ACK/NACK + polling Packet Control Ack (6)

PCC-RLC-activate-req(NE) (5) PCC-RLC-activate-cnf PCC-RLC-Release-ind (7)

PCS BSS B9 Description PCS/GSM/2005-07001 19/79

Normal UL TBF release (delayed final PUAN, with DL TBF establishment)

Overall description of the proposed solutions

PCS BSS B9 Description PCS/GSM/2005-07001 20/79

MS USF RLC Block, BSN=n, CV =0

start T_extended_UL_TBF PUAN, SSN= n+1, FAI=0

PCS BSS B9 Description PCS/GSM/2005-07001 21/79

MS and BSS capability

PCS BSS B9 Description PCS/GSM/2005-07001 22/79

Acquiring the MS capability (with Extended UL TBF mode capability)

RA Update Capability procedure (BSSGP Ed2) Successful case

PCS BSS B9 Description PCS/GSM/2005-07001 23/79

Figure 11: RA-CAPABILITY requested by the BSS