EDGE Field Trial Guideline: Originator File Date Edition

EDGE Field trial Guideline
Originator P. Henriques
File EDGE Trial Guideline
Date 07/2006
Edition 04.
Page 1
All rights reserved. Passing on and copying of this document, use and communication of its contents not permitted without written authorisation.
CONTENTS
1. SCOPE....................................................................................................................5 2. EDGE FIELD TRIAL SEVERAL OBJECTIVES..................................................6

2.1 What Is EDGE.............................................................................................................................. 6 2.2 Several objectives for EDGE field trials....................................................................................6
3. TELECOM FUNCTIONS........................................................................................8
3.1 B8 release transmission resource management TRX Class concept.................................8 3.2 B9 release Transmission resource management.....................................................................8 3.3 Traffic management.................................................................................................................... 9 3.3.1 New coding schemes or MCS for EDGE transfers.....................................................................9 3.3.2 New modulation.......................................................................................................................... 9 3.3.3 Link adaptation for EGPRS...................................................................................................... 10 3.3.4 ARQ mechanism types............................................................................................................. 10
4. SYSTEM CONFIGURATION AND TEST ENVIRONMENT.................................11

4.1 Sytem configuration.................................................................................................................. 11 4.1.1 Overall configuration................................................................................................................ 11 4.1.2 Radio access network............................................................................................................... 11 4.2 Mobile station............................................................................................................................ 12 4.3 Applications............................................................................................................................... 13 4.4 Test conditions.......................................................................................................................... 13
5. EDGE VALIDATION TEST STRATEGY..............................................................15

5.1 End User performances validation.......................................................................................... 15 5.1.1 Scope of the tests..................................................................................................................... 15 5.1.2 Applications used for performance tests..................................................................................15 5.1.3 Tests specifications.................................................................................................................. 16 5.1.4 Performance tests strategy....................................................................................................... 16 5.2 Coverage validation.................................................................................................................. 23 5.2.1 Scope of the tests..................................................................................................................... 23 5.2.2 Maximum throughput achievable for each MCS/CS................................................................23 5.2.3 GPRS and EDGE radio coverage ........................................................................................... 25
6. QUALITY OF SERVICE MONITORING..............................................................27

6.1 Quality of service monitoring EDGE experimentation........................................................27 6.2 Quality of service monitoring EDGE Pilot...........................................................................27
7. TEST TOOLS.......................................................................................................28
7.1 End-to-End investigation.......................................................................................................... 28 7.2 Mobile Equipment (mobile handsets and clients)..................................................................29 7.2.1 EDGE and GPRS mobiles........................................................................................................ 29 7.2.2 PC and applications.................................................................................................................. 29
Date 07/2006
Edition 04.
Page 2
7.2.3 K1205....................................................................................................................................... 29 7.2.4 Ethereal.................................................................................................................................... 30 7.2.5 Compass................................................................................................................................... 30 7.2.6 MFS terminal............................................................................................................................ 30 7.3 Drive test measurement tool chain.......................................................................................... 30 7.4 Qos follow-up ANAQOS tool................................................................................................. 31
8. ANNEX:................................................................................................................32
8.1 Detailed EDGE test plan.......................................................................................................... 32 8.2 TCP parameters......................................................................................................................... 33
Date 07/2006
Edition 04.
Page 3
History :
Edition 1
Date 19/07/04
Originator S. RABILLARD
Comments Creation of document the
1/09/04
S. RABILLARD
Modification of the documents after comments Modification after field experiments Update to include B9 release
20/05/05
P. F. COSTA
04/07/06
P. HENRIQUES
Reference :
[1] : EDGE&HSDS : introduction, algorithms and parameters, 3DF 01906 2810 VAZZA [2] : DEUTRIP User guide, ed2.1
Useful documentation : B8
- SFD: High Speed Data Service (Telecom), B8, 3BK 10204 0598 DTZZA, ed. 01 - RLC sublayer, 3BK 11202 368 DSZZA, ed. 05 - Resource Allocation and Management (RAM), 3BK 11202 0350 DSZZA, ed. 03 - RRM sub-layer (PCC), 3BK 11202 0367 DSZZA, ed. 06 - RRM sub-layer (PRH), 3BK 11202 0366 DSZZA, ed. 07
B9
- (E)GPRS and LCS TELECOM PRESENTATION, 3BK 11203 0114 DSZZA, ed. 01 - FBS-GPRS-Radio Interface- RLC SubLayer, 3BK 11202 0392 DSZZA, ed. 08 - Resource Allocation and Management, 3BK 11202 0387 DSZZA, ed. 06 - FBS-GPRS-Radio Interface- RRM SubLayer-PCC, 3BK 11202 0391 DSZZA, ed. 08 - (E)GPRS-Radio Interface- RRM - PRH, 3BK 11202 0390 DSZZA, ed. 07
Date 07/2006
Edition 04.
Page 4
1.
SCOPE
The scope of this document is to define the strategy for testing the new EDGE feature in the frame of any EDGE field Experimentation or Pilot. This document will not present in detail how to perform the tests but will explain what could be interesting to study or to propose during such a project. In this document the following aspects will be presented : The main objectives The main B8 telecom features involved during the field tests The main B9 telecom features involved during the field trial tests The different domains of tests which could be tackled and the associated planning The test tools
Date 07/2006
Edition 04.
Page 5
2. 2.1
EDGE FIELD TRIAL SEVERAL OBJECTIVES What Is EDGE

EDGE is a global radio-based high-speed mobile data rate standard that can be introduced into GSM/GPRS networks. EDGE allows data transmission speeds up to 473,6 Kbit/s (8 TS in downlink) in packet-switched mode in order to suppor multimedia services. This is achieved within the same GSM bandwidth and existing 800, 900, 1800 and 1900 MHz frequency bands. The idea behind EDGE is to increase the data rate that can be achieved by changing the type of modulation used while still working with existing GSM and GPRS network nodes. The new modulation that is introduced is the eight-state phase-shift keying (8-PSK) allowing to carry 3 bits per modulated symbol over the radio path.
2.2
Several objectives for EDGE field trials

The two main objectives of a field trial are the following: 1) Validate the gains brought by EDGE on the field This objective will be of course the main one. Assessing the throughput gain offered by EDGE versus GPRS will help the operator to refine its EDGE business model. Depending on what throughputs can be achieved some new services may or may not be marketed. 2) Help the customer to define the best EDGE introduction strategy on the two following aspects Find the best trade-off between the required EDGE throughputs (marketing needs) and the necessary capacity extension (anticipating the need for network deployment). Thus, assessing in advance the GPRS/EDGE throughputs depending on the transmission capacity (TRX class in B8 and number extra Abis TS in B9 ), it will help the operator in selecting the most appropriate transmission capacity/BSS architecture depending on the gain brought by increasing the capacity. Identify in advance the radio engineering solution or radio parameters which could influence the radio throughputs: usage of incremental redundancy and frequency hopping, frequency band impact, EDGE on BCCH TRX .. The frequency hoping can impact the DL throughput from 2% in good radio conditions up to 16% in normal radio conditions; however the impact of the frequency hoping is high dependent of the frequency plan and the band width. A low interference network improves the DL throughput. The values presented are average gather by statistical way and they may change with the network configuration and the frequency plan of the operator. Furthermore, it is pratically impossible to find 2 cells with different hopping schemes and the same radio conditions and in this way it is very difficult to test in the field the
Date 07/2006
Edition 04.
Page 6
impact of carrying PS in frequency hoping TRX Some improvements in frequency plan can be proposed to the customer using RMS. The RMS provides useful statistics on reported radio measurements, which will easier the work for planning and optimization of a network. With this strong information it is possible make a good frequency plan and so to lower the interference in the network. The final impact will be a better QoS in EDGE. The advantage of choosing PS in the BCCH TRX is not conclusive. External factors such as the frequency plan, cell configuration have a higher impact in choose.
Date 07/2006
Edition 04.
Page 7
3.
TELECOM FUNCTIONS
The aim of this part is not to explain in detail the new algorithms and parameter linked to GPRS CS3/CS4 and EDGE (refer to [1]) but to present quickly the main telecom functions that will be used during the trial.
3.1
B8 release transmission resource management TRX Class concept

Depending on the used (M)CS, from one and up to five 16 kbit/s channels are needed per PDCH between the BTS and the MFS (for example, the 59.2 kbit/s theoretical throughput per PDCH with MCS9 cannot be carried by a single 16 kbit/s channel on the Abis/Ater interfaces). Therefore, each TRX has a TRX class (from one to five), which defines the number of Abis/Ater GCH per radio TS or PDCH. One PDCH on a class n TRX uses n GCH (1 EGCH = n 16 kbit/s channels = n GCH) on the Abis and Ater interfaces. In each cell the operator defines the number of TRX of each TRX class.
The table below indicates the available CS and MCS depending on the TRX class.
TRX class 1 2 3 4 5
Available CS CS1 to CS2 CS1 to CS4 CS1 to CS4 CS1 to CS4 CS1 to CS4
Available MCS MCS1 to MCS2 MCS1 to MCS5 MCS1 to MCS6 MCS1 to MCS8 MCS1 to MCS9
3.2
B9 release Transmission resource management

In B9 release the TRX class concept no longer exists. The new Enhanced Transmission Resource Management feature is totally different concept, it allows a dynamic adaptation of the transmission to the existing circuit switch and packet switch traffic. The feature runs in the top of the new 4 subfeatures: M-EGCH Statistical Multiplexing - This feature provides a solution to share the Ater and Abis nibbles between the radio timeslots of a TRX so that the transmission resources left available by a PDCH can be reused by other PDCHs as long as those PDCHs belong to the same TRX. Thus, it allows reducing the waste of transmission bandwidth on the Ater and Abis interfaces.
Date 07/2006
Edition 04.
Page 8
Dynamic Abis Allocation - This feature enables to dynamically allocate Abis nibbles among the different TREs used for PS traffic in a given BTS. Compared to B8, it allows a higher average Abis bandwidth per PDCH, the BSC capacity in terms of TREs is increased, and in some BTS configurations it may avoid to deploy a second Abis link. Ater Resource Management The Ater resource management was changed from B8 to the new concept, the strong requirement is to ensure GPRS access in all the cells of the GPU (no cell shall be blocked due to an Ater congestion).
DL Retransmission in the BTS- Avoid consuming transmission resources (Abis + Ater) in case of DL RLC data blocks retransmissions. Store for a certain time, in the memory of the TRE involved in the packet transfer mode with an MS, the DL RLC data blocks received from the MFS for this MS. Then, the MFS can ask the TRE (in the BTS) to retransmit some data blocks. The enhanced transmission resource management can be split in two parts : The first part consists in the managing of the M-EGCH link (size determination, establishment, release, .) The second consists in the activation of GCH resources during resource allocation/reallocation (for a TBF establishment for example).
3.3
3.3.1
Traffic management
New coding schemes or MCS for EDGE transfers EDGE is an evolution of the GSM standard, introduced in the 3GPP release 99. It is designed to allow higher throughputs than the GPRS thanks to the use of new coding schemes : MCS1 to MCS9 in downlink and uplink. These coding schemes are defined only for the EGPRS packet data traffic channels (PDTCH). For all the EGPRS packet control channels the corresponding GPRS control channel coding is used (that is MCS1 for the PACCH, PBCCH, PAGCH, PPCH and downlink PTCCH). In B8 release, the MCS1 to MCS9 coding schemes are available in downlink whereas only the MCS1 to MCS4 coding schemes are available in uplink. Although, in B9 is available in uplink the 8PSK modulation allowing to have the MCS1 to MCS9 coding schemes.
3.3.2
New modulation EDGE introduces a new modulation: the 8-PSK modulation. This new modulation is used for the MCS5 to MCS9 coding schemes. Contrary to the GMSK modulation that has a constant envelope, the 8-PSK modulation envelope carries information. We will see later that this has an impact on the available output power in 8-PSK.
Date 07/2006
Edition 04.
Page 9
3.3.3
Link adaptation for EGPRS The aim of link adaptation is to find the best compromise between BLER (which depends on the radio path quality) and the data protection (MCS1 offers the best protection but the lowest throughput whereas MSC9 offers the highest throughput but low protection). In RLC acknowledged mode, the objective is to achieve the best possible throughput, whereas in RLC unacknowledged mode the objective is to remain below a certain level of residual bit error rate. Depending on measurement (MEAN_BEP, CV_BEP) performed either by the MS (reported in EGPRS PDAN, DL case) or by the BTS (reported in GCH frames, UL case), the modulation and coding scheme is changed. The link adaptation algorithm is different according to RLC mode (ack/nack) and ARQ (IR used / not used).
3.3.4
ARQ mechanism types In RLC acknowledged mode, there are two types of ARQ mechanisms: Type 1 ARQ (already used in B6 and B7 releases, used in B8 and B9 release for GPRS and EGPRS) Type 2 hybrid ARQ = Incremental Redundancy (new in B8 release, only used for EGPRS)
Type I ARQ for EGPRS In type I ARQ mechanism, when a RLC data block is retransmitted, the same or another MCS from the same family of MCS is selected. This is valid for DL and UL direction. However, in B8 (no longer valid for B9), in UL only RLC data blocks sent with MCS4 could be retransmitted with a MCS from the same family. For MCS1, MCS2 and MCS3, the blocks will be retransmitted with the same MCS.
Type II hybrid ARQ or Incremental Redundancy In type I ARQ, if a RLC block is received with errors, it is discarded. With Incremental Redundancy the soft bits information from N different transmissions of the same RLC block can be combined to increase the chances to decode the RLC block. Incremental redundancy only applies to DL EGPRS data blocks in RLC acknowledged mode. The Alcatel BSS in B8 does not support incremental redundancy in the UL direction. At the MS side incremental redundancy is mandatory. In B9 release the incremental redudancy in the UL is optional and it can be enabled by the parameter En_IR_UL.
Date 07/2006
Edition 04.
Page 10
4. 4.1
4.1.1
SYSTEM CONFIGURATION AND TEST ENVIRONMENT Sytem configuration

Overall configuration
Air BTS Abis BSC TC A MSC D HLR Radius
Serial / USB
Gs Ater
Gr
Gb MFS SGSN
Gn GGSN
Gi
FTP
HTTP
4.1.2
Radio access network Two different scenarii could be considered depending on the context: 1. EDGE experimentation: preliminary assessment on a dedicated network (BSS+GSS) 2. EDGE Pilot: full validation on the real commercial network
EDGE experimentation network As it was done during the first experimentation performed in Bucharest (January 04) the EDGE software could be run on a specific network in order to avoid any interference with the commercial network. This standalone access network (BSS+GSS) should be composed of :
5/10 Evolium BTS 3x2 (3 sectors with 2 TRXs/sector) 1x4 (1 sector with 4 TRxs) with at least one G4 TRE per sector
Date 07/2006
Edition 04.
Page 11
1 dedicated BSC (small configuration) + TC 1 dedicated MFS with 2 GPUs 1 OMC-R small configuration (with embedded NPA) 1 RNO/NPA tool chain 1 A-interface link to one MSC in order to retrieve the synchronisation 1 link to an Alcatel SGSN/GGSN Core network (R2.1 at least or higher release) Cells shall belong to a PLMN different from the one of the operator (specific SIM cards needed) all the application servers should be connected on Gi interface (just behind the GGSN)
EDGE Pilot network In order to validate the EDGE benefits on a real B8 or B9 commercial network some cells should be with EDGE activated without any transmission limitation, allowing to achieve the best throughputs. This means in B8 at least one cell with a TRX Class 5 configured. For B9, since the extra transmission capacity is configure by BTS, it means that the extra nibbles will be shared between the cells of the BTS and a precaution should be take tocheck the PS traffic impact from one cell in another. As an example of an EDGE pilot for B9, it is presented the following annex:
HSDS_test_report_e d01.doc
As for the experimentation, the application servers will have to be connected on the Gi interface in order to avoid any internet bad effects.
4.2
Mobile station
The Nokia 6230 or 6230i terminals (commercial products) have been chosen as the reference MS for testing EDGE on the field (first commercial MS with a good quality). Therefore, they will be used to run all the functional end-to-end tests. .
Date 07/2006
Edition 04.
Page 12
The Nokia 6230 is a (4+1) or a (3+2) terminal (depending on the transfer direction). It keeps the same multislot class during GPRS and EGPRS transfers. It supports the bluetooth wireless technology avoiding the usage of the USB cable (useful functionality in case of drive test measurements).
The Nokia 6230i has the same capacity of the Nokia 6230 but it is also a R4 mobile, allowing the usage of B9 features like Extended UL TBF mode or Network Assisted Cell Change.
The Nokia 6630 and 6680 are consider the refernce mobile EDGE to UMTS tests.
All Nokia EDGE mobiles (Nokia 6230, 6230i and 6630) have the possibility of having Net Monitor installed this application permits to not only have precious network information shown in the mobiles display, but also to force camping in one particular BCCH, or ignore/invert the CELL_BAR_ACCESS command.
4.3
Applications
In order to secure the field tests, a limited number of applications were chosen using the EDGE terminals as modem. Two types of application services are considered: Performance application services (Ping, FTP and Web) in order to assess the new accessibility and throughputs achievable with EDGE Commercial application services as Video streaming in downlink
Regarding WAP service no tests are foreseen because: since the transfers are too short we don't expect any significant gain in WAP performances with EDGE WAP transfers are too dependent on the MS WAP browser behaviour (stability)
4.4
Test conditions
In order to evaluate EDGE and GPRS CS3/CS4 performances in different types of environments the following Tests Conditions are defined:
Date 07/2006
Edition 04.
Page 13
EDGE transfers in GOOD / NORMAL / BAD radio conditions *** (see hereafter) EDGE transfers static/mobility EDGE transfers with/without hopping (BBH/Radio Frequency Hopping) (see comments in 2.2) EDGE transfers on the BCCH / non BCCH TRX EDGE transfers on different TRX Class for B8 networks or different maximum MCS for B9
*** Good : downlink RxLev [-55dBm, -65 dBm] and MeanBEP [31, 25] Normal : downlink RxLev [-65dBm, -85 dBm] and MeanBEP [25, 15] Poor : downlink RxLev [-85dBm, -100 dBm] and MeanBEP [15, 00]
Date 07/2006
Edition 04.
Page 14
5.
EDGE VALIDATION TEST STRATEGY

The objective of this part is to specify the different domains on which the radio tests could be performed. Depending on the context (duration of the project and/or customer expectations) only a reduced part of the test plan could be performed.
To be aligned on the objectives, any EDGE Trial could be splitted into four main domains : End User performances validation EDGE/GPRS coverage study Radio quality of service monitoring Test tools
5.1
5.1.1
End User performances validation

Scope of the tests The main objective of this package is to highlight the improvements brought by EDGE and GPRS CS3/CS4 especially in term of throughputs. In order to validate the performances in a real environment a strong distinction should be done between the two scopes of the tests: pure GPRS/EDGE performances tests - best GPRS/EDGE quality a subscriber could experiment in a network and also the ideal trial to achieve the system stability, not only in terms of RLC/MAC layer but also the upper layers (LLC layer and TCP/IP layer)
commercial GPRS/EDGE performances tests - real GPRS/EDGE quality that subscriber could experiment in a commercial network and the best trial to test the impact of the PS features, such as the IR and resegmentation. In the pure GPRS/EDGE performance the radio and load conditions should be controlled. A condition not valid during the commercial tests.
5.1.2
Applications used for performance tests Two types of services have been chosen: Performance application services like Ping, FTP and WEB applications more demanding applications like video streaming
Ping service will be used to test the accessibility. FTP and WEB services will be used to show the
Date 07/2006
Edition 04.
Page 15
gain in download/upload time brought by EDGE and GPRS CS3/CS4 compared to GPRS CS1/CS2. These three services are also important to measure/investigate the impact of the different layers and network entities in the end user performance.
Video streaming in downlink will be used to show what stable throughputs could be achieved allowing the usage of this demanding service. The download of the video streaming, in a mobility test, allows measuring the impact of the cell reselection on the QoS, the buffer size have major rule in the previous results.
The following KPI will be provided: time to download a specific Web page and non quality factor for WEB access failure rate throughput and failure rate for uplink and downlink FTP transfers quality of the video for video streaming
5.1.3
Tests specifications All the tests will be run with the optimised parameter values (ref 8.1) and they can include the tests of a subset of B8/B9 features. Depending on the set of tests tackled, the data transfers could be performed in different kind of radio environments. After KPI stability and optimisation degree in static tests is achieved, mobility tests should be performed. The services tested should be the FTP, Web and Video Streaming. They allow measuring the impact of the radio conditions variations and the cell reselections. These tests are high dependent of the server specification, such as the TCP parameter timeout. BSS PS features, like Enhanced Cell Reselection and DL LLC PDU, can be tested to improve the end user performance.
5.1.4
Performance tests strategy Three sets of EDGE tests and one set of GPRS test can be defined: pure EDGE performance tests EDGE performances in various radio environments or commercial EDGE performances EDGE performances versus GPRS performances GPRS CS3/CS4 performances versus GPRS CS1/CS2 performances
Date 07/2006
Edition 04.
Page 16
5.1.4.1 Pure EDGE performance tests Test cases: The aim of this first set of performance tests is to assess the gain brought by EDGE and so the test should be performed in good radio conditions. They should be used to get end user QoS stability. The following cases should be performed in good radio conditions (refer to part 4.4) with all MCS allowed 1 EDGE MS in DL FTP transfer (different file sizes will have to be foreseen). 1 EDGE MS in UL FTP transfer (different file sizes will have to be foreseen) 1 EDGE MS in Web transfer (different Web pages will have to be foreseen) 1 EDGE MS in downlink Video transfer 1 EDGE MS in accessibility test (different ping sizes and intervals will have to be foreseen)
Each test should be run several times in order to have reliable statistics.
Test specification: The test should be performed: In good radio conditions (Rxlev [-55;-65dBm], MeanBEP [31;25]) In cells with low traffic load. With all MCS allowed and with link adaptation activated. With different pool types (from 5 to 2) in B8 and for different maximum MCS in B9. In 900 and 1800 bands With and without hopping (BBH or Radio Frequency Hopping) (see comments in 2.2) EDGE TRX configured on the BCCH / Non BCCH TRX
Date 07/2006
Edition 04.
Page 17
Manpower estimation for B8 release :

Pure EDGE performance tests - B8 release
Basic tests (default configuration) : EDGE performances in good radio conditions in the classical frequency band on a Pool type 5 TRX Influence of the frequency band : EDGE performances in good radio conditions in the classical / non "classical" frequency band EDGE traffic on the BCCH carrier : EDGE performances in good radio conditions on BCCH and non BCCH TRX Infuence of hopping : EDGE performances on a hopping/non hopping TRX in good radio conditions TRX Class influence : EDGE performances with different pool types DURATION (hours) 3 6 6 6 12 DURATION (days) 0.375 0.75 0.75 0.75 1.5
**** 3 hours are needed to perform the different measurements for a given configuration.
Manpower estimation for B9 release:

Pure EDGE performance tests - B9 release
Basic tests: EDGE perf. in good radio conditions in the classical frequency band with max. MCS9 and available transmission capacity Influence of the frequency band : EDGE performances in good radio conditions in the classical / non "classical" frequency band EDGE traffic on the BCCH carrier : EDGE performances in good radio conditions on BCCH and non BCCH TRX Infuence of hopping : EDGE performances on a hopping/non hopping TRX in good radio conditions Maximum MCS influence : EDGE performances with differents maximum MCS DURATION (hours) 3 6 6 6 12 DURATION (days) 0.375 0.75 0.75 0.75 1.5
5.1.4.2 EDGE performance tests in various radio/load conditions - commercial EDGE performance Test cases: The aim of this set of tests is to assess the gain brought by EDGE in various radio conditions (RxLev, MeanBEP) and possibly different load conditions (however, such variability should be limited as much as possible). During this field trial it is proposed to test the EDGE features IR and Resegmentation. The following cases should be performed in various radio conditions with all MCS allowed : 1 EDGE MS in DL FTP transfer (different file sizes will have to be foreseen). 1 EDGE MS in UL FTP transfer (different file sizes will have to be foreseen) 1 EDGE MS in Web transfer (different Web pages will have to be foreseen)
Date 07/2006
Edition 04.
Page 18
1 EDGE MS in downlink Video transfer 1 EDGE MS in accessibility test (different ping sizes and intervals will have to be foreseen)
Each test should be run several times in order to obtain reliable statistics.
Test specification: The test could be performed: In different kind of radio conditions (Rxlev, MeanBEP) (Main difference with the previous set of tests). With all MCS allowed and with link adaptation activated. With different pool types (from 5 to 2) in B8 and for different maximum MCS in B9. In 900 and 1800 frequency bands With and without hopping (BBH or Radio Frequency Hopping) (see comments in 2.2) With / without DL and UL(only in B9) re-segmentation activated (optional) With / without Incremental redundancy in UL in B9 release (optional) EDGE TRX configured on the BCCH / Non BCCH TRX Tests performed at the same hour of the day in order to meet same kind of traffic load
Manpower estimation for B8 release (Standard tests):

"Commercial" EDGE performance tests - B8 release
Basic tests (default configuration) : EDGE performances in various radio conditions in the classical frequency band on a Pool type 5 TRX Influence of the frequency band : EDGE performances in various radio conditions in the classical / non "classical" frequency band EDGE traffic on the BCCH carrier : EDGE performances in various radio conditions on BCCH and non BCCH TRX Infuence of hopping : EDGE performances on a hopping/non hopping TRX in different radio conditions TRX Class influence : EDGE performances in different radio conditions and with different pool types DURATION (hours) 9 18 18 18 36 DURATION (days) 1.125 2.25 2.25 2.25 4.5
**** 3x3 hours are needed to perform the different measurements for a given configuration.
Date 07/2006
Edition 04.
Page 19
Manpower estimation for B8 release (DL re-segmentation tests):

DURATION (hours) 4 8 16 DURATION (days) 0.5 1 2
EDGE performance tests - DL Re-segmentation influence - B8 release

Basic tests (default configuration) : EDGE performances in normal and bad radio conditions with/without DL re-segmentation Infuence of hopping in different radio conditions : EDGE performances on a hopping TRX/ non hopping TRX with different radio conditions TRX Class influence : EDGE performances in different radio conditions and with different pool types
Manpower estimation for B9 release (Standard tests):

"Commercial" EDGE performance tests - B9 release
Basic tests: EDGE perf. in various radio conditions in the classical frequency band with max. MCS9 and available transmission capacity Influence of the frequency band : EDGE performances in various radio conditions in the classical / non "classical" frequency band EDGE traffic on the BCCH carrier : EDGE performances in various radio conditions on BCCH and non BCCH TRX Infuence of hopping : EDGE performances on a hopping/non hopping TRX in different radio conditions Maximum MCS influence : EDGE performances in different radio conditions and with differents maximum MCS DURATION (hours) 9 18 18 18 36 DURATION (days) 1.125 2.25 2.25 2.25 4.5
Manpower estimation for B9 release (DL re-segmentation tests):

EDGE performance tests - DL Re-segmentation influence - B9 release
Basic tests (default configuration) : EDGE performances in normal and bad radio conditions with/without DL re-segmentation Infuence of hopping in different radio conditions : EDGE performances on a hopping TRX/ non hopping TRX with different radio conditions Maximum MCS influence : EDGE performances in different radio conditions and with differents maximum MCS DURATION (hours) 4 8 16 DURATION (days) 0.5 1 2
Date 07/2006
Edition 04.
Page 20
Manpower estimation for B9 release (UL IR and re-segmentation tests):

EDGE performance tests - UL IR and Re-segmentation influence - B9 release
Basic tests (default configuration) : EDGE perf. in normal and bad radio conditions with/without UL IR and with/without UL re-segmentation Infuence of hopping in different radio conditions : EDGE performances on a hopping TRX/ non hopping TRX with different radio conditions Maximum MCS influence : EDGE performances in different radio conditions and with differents maximum MCS DURATION (hours) 4 8 16 DURATION (days) 0.5 1 2
5.1.4.3 EDGE performances versus GPRS performances Test cases: The aim of this set of tests is to evaluate the gain brought by EDGE compared to GPRS. The following test cases should be performed in various radio conditions: At the same geographical point 1 EDGE MS and 1 GPRS MS in DL FTP transfer (same files, same terminal) At the same geographical point 1 EDGE MS and 1 GPRS MS in UL FTP transfer (same files, same terminal) At the same geographical point 1 EDGE MS and 1 GPRS MS in Web transfer (same pages, same terminal)
Each test should be run several times in order to obtain reliable statistics. In order to avoid too noticeable impact from load varaiations, EDGE and GPRS tests should be consecutive in a short timeframe.
Test specification: The tests could be performed: in different kinds of radio conditions (Rxlev, MeanBEP) (refer to part 4.4) With all MCS/CS allowed and with link adaptation activated. In 900 or 1800 band With and without hopping (BBH or Radio Frequency Hopping) (see comments in 2.2) With re-segmentation not activated (EN_FULL_IR_DL=enable for DL and EN_Resegmentation_UL = Disable. only for B9)
Manpower estimation:
Date 07/2006
Edition 04.
Page 21
EDGE performances versus GPRS performances

Basic tests (default configuration) : GPRS/EGPRS performances in good radio conditions Influence of the radio conditions : GPRS/EGPRS performances in different radio conditions Infuence of hopping : GPRS/EGPRS performances on a hopping TRX / non hopping TRX in good radio conditions Infuence of hopping in different radio conditions : GPRS/EGPRS performances on a hopping / non hopping TRX with different radio conditions
DURATION (hours) 7 21 14 42
DURATION (days) 0.875 2.625 1.75 5.25
5.1.4.4 GPRS CS3/CS4 compared to GPRS CS1/CS2 Test cases: The aim of this last set of tests is to evaluate the gain brought by CS3/CS4 compared to CS1/CS2. All the tests could be performed with commercial mobiles that normally support all the GPRS coding schemes (CS1-->CS4). The following test cases should be performed in various radio conditions: 1 MS in DL FTP transfer with CS1/CS2 then same MS in DL FTP transfer using CS3/CS4 1 MS in UL FTP transfer with CS1/CS2 then same MS in UL FTP transfer using CS3/CS4 1 MS in Web transfer with CS1/CS2 then same MS in Web transfer using CS3/CS4
Each test will be run several times in order to obtain reliable statistics.
Test specification: The tests could be performed: In different kind of radio conditions (Rxlev, MeanBEP) With all CS (MAX_GPRS_CS = 2 first, then MAX_GPRS_CS = 4) allowed and with link adaptation activated. In 900 or 1800 bands GPRS transfers on the BCCH / a non BCCH TRX With and without hopping (BBH or Radio Frequency Hopping) (see comments in 2.2)
Manpower estimation:
Date 07/2006
Edition 04.
Page 22
GPRS CS3/CS4 versus GPRS CS1/CS2

Basic tests (default configuration) : CS3/CS4 versus CS1/CS2 performances in good radio conditions Influence of the frequency band : CS3/CS4 versus CS1/CS2 performances in good radio conditions in the classical bd / non "classical" bd Infuence of hopping : CS3/CS4 versus CS1/CS2 performances on a hopping TRX / non hopping TRX in good radio conditions Influence of the radio conditions : CS3/CS4 versus CS1/CS2 performances in different radio conditions
DURATION (hours) 8 16 16 24
DURATION (days) 1 2 2 3
5.2
5.2.1
Coverage validation
Scope of the tests The main objective of this package is to evaluate the maximum throughput that can be reached for each MCS and new GPRS coding schemes (CS3-4) according to the coverage brought by a network design.
5.2.2
Maximum throughput achievable for each MCS/CS Test cases: The maximum throughput that can be reached with each MCS/CS will be measured and compared with theoretical values. The following cases shall be tested with link adaptation disabled TBF_INIT_DL(UL)_(M)CS = MAX_(E)GPRS_(M)CS = chosen (M)CS): 1 MS in DL FTP transfer with MCS1 1 MS in DL FTP transfer with MCS2 1 MS in DL FTP transfer with MCS3 1 MS in DL FTP transfer with MCS4 1 MS in DL FTP transfer with MCS5 1 MS in DL FTP transfer with MCS6 1 MS in DL FTP transfer with MCS7 1 MS in DL FTP transfer with MCS8 1 MS in DL FTP transfer with MCS9 1 MS in DL FTP transfer with CS3 1 MS in DL FTP transfer with CS4 (for all cases
Date 07/2006
Edition 04.
Page 23
1 MS in UL FTP transfer with MCS1 1 MS in UL FTP transfer with MCS2 1 MS in UL FTP transfer with MCS3 1 MS in UL FTP transfer with MCS4 1 MS in UL FTP transfer with MCS5 (only in B9) 1 MS in UL FTP transfer with MCS6 (only in B9) 1 MS in UL FTP transfer with MCS7 (only in B9) 1 MS in UL FTP transfer with MCS8 (only in B9) 1 MS in UL FTP transfer with MCS9 (only in B9) 1 MS in UL FTP transfer with CS3 1 MS in UL FTP transfer with CS4
Please note that although the MCS may be fixed, it is possible that radio blocks in a different MCS are exchanged. Indeed, retransmission in EDGE can be done either using the same MCS but a different Puncturing Scheme (in the case IR is used DL case), or using a radio block in another MCS from the same MCS family. Test specification: The test should be performed: in different kinds of radio conditions (Rxlev, MeanBEP) In 900 and 1800 bands With and without hopping (BBH or Radio Frequency Hopping) (see comments in 2.2) With / without DL and UL(only in B9) re-segmentation activated EDGE TRX configured on the BCCH / Non BCCH TRX
Manpower estimation for B8 release :
Date 07/2006
Edition 04.
Page 24
Maximum throughput achievable per coding scheme - B8 release

Basic tests (default configuration) : max. throughput per CS/MCS in good radio conditions Influence of the radio conditions : max. throughput per CS/MCS in different radio conditions GPRS/EGPRS traffic on BCCH and non BCCH TRX Influence of the frequency band : max. throughput per CS/MCS on the "classical" and non "classical" frequency band Influence of DL resegmentation: max. throughput per CS/MCS in normal and bad radio conditions Infuence of hopping : max. throughput per CS/MCS on hopping/non hopping TRX
DURATION (hours) 8 24 16 16 32 16
DURATION (days) 1 3 2 2 4 2
**** 8 hours are needed to perform the different measurements for a given configuration
Manpower estimation for B9 release

Maximum throughput achievable per coding scheme - B9 release
Basic tests (default configuration) : max. throughput per CS/MCS in good radio conditions Influence of the radio conditions : max. throughput per CS/MCS in different radio conditions GPRS/EGPRS traffic on BCCH and non BCCH TRX Influence of the frequency band : max. throughput per CS/MCS on the "classical" and non "classical" frequency band Influence of DL resegmentation: max. throughput per CS/MCS in normal and bad radio conditions Influence of UL IR and resegmentation: max. throughput per CS/MCS in normal and bad radio conditions Infuence of hopping : max. throughput per CS/MCS on hopping/non hopping TRX DURATION (hours) 8 24 16 16 32 64 16 DURATION (days) 1 3 2 2 4 8 2
5.2.3
GPRS and EDGE radio coverage With GPRS and EDGE, the service can be offered everywhere within the cell range as for voice, but due to the link adaptation, the throughput differs significantly from the center of the cell towards the edge of the cell. The aim of this part is to study and compare the GPRS and EDGE cell coverage in term of throughput.
Test cases:
Date 07/2006
Edition 04.
Page 25
Different geographical points should be chosen within the cell coverage in order to perform GPRS and EDGE transfers in different radio conditions. On each point the following measurements should be done: DL FTP transfers UL FTP transfers Web transfer
Test specification: The tests could be performed: in different kinds of radio conditions In 900 and 1800 bands With and without hopping (BBH or Radio Frequency Hopping) (see comments in 2.2) With all MCS/CS allowed and with link adaptation activated. With or without resegmentation (only in DL in B8, in DL & UL in B9).

GPRS/EGPRS data throughput planning - B8 release
Basic tests : GPRS/EGPRS service coverage GPRS/EGPRS service coverage w/wo hopping Influence of DL resegmentation DURATION (hours) 12 24 24 DURATION (days) 1.5 3 3

GPRS/EGPRS data throughput planning - B9 release
Basic tests : GPRS/EGPRS service coverage GPRS/EGPRS service coverage w/wo hopping Influence of DL resegmentation Influence of UL IR and resegmentation DURATION (hours) 12 24 24 48 DURATION (days) 1.5 3 3 6
Date 07/2006
Edition 04.
Page 26
6. 6.1
QUALITY OF SERVICE MONITORING Quality of service monitoring EDGE experimentation

From a pure experimentation point of view the RNO/NPA tool chain is not necessary to demonstrate that EDGE is interworking with some mobiles and provides the expected throughput. Nevertheless a light tool chain solution could be provided (NPA embedded plus RNO or ANAQOS tool) in order to follow: GPRS/EDGE TBFs establishment phase (UL and DL directions) GPRS/EDGE TBFs transfer phase GPRS/EDGE coding scheme usage (UL and DL directions) and radio quality (retransmission rate) Radio throughput at TBF level
6.2
Quality of service monitoring EDGE Pilot

The GPRS/EDGE quality of service monitoring will be performed through the RNO/NPA tool chain (RNO version 4 for B8, version 5 for B9). The following features could be used: parameter checking (to compare operational and reference parameter values) counters/indicators accessibility telecom reports
The GPRS/EDGE indicators could be gathered into three groups dedicated to: radio interface Gb interface Ater interface
During the testing period it will be important to follow the radio interface indicators that allow assessing: GPRS/EDGE TBF establishments (request, success, cause of failures.) transfer phase after TBF establishment (normal release, cell re-selection (NC0/NC2), TBF connection time, TBF drops, drop causes) radio resources allocation (PDCH and master PDCH allocation, PDCH usage.) transmission and throughput aspects ( number of blocks and bytes transmitted/retransmitted in (M)CSx, coding scheme usage, radio throughput at TBF, PDCH, cell level.) It would be important to show also some of the indicators to look at for dimensioning follow-up.
Date 07/2006
Edition 04.
Page 27
7. 7.1
TEST TOOLS End-to-End investigation

In PS drive test, several entities have an impact in the end user performance. Each entity has a layer protocol to communicate to is per. The layers that have more impact in the end user performace are the: - Phisycal layer - RLC/MAC layer Acknowledge mode Between the MS and the BSS (MFS) - LLC layer Unacknowledge mode Between the MS and the SGSN (however the MFS also process this layer) - TCP/IP layer Acknowledge mode - The TCP between the PC and the server and the IP between the PC and the GGSN
When performing a PS investigation analyse the different interfaces in order to detect in which entity the problem is.
Date 07/2006
Edition 04.
Page 28
7.2
7.2.1
Mobile Equipment (mobile handsets and clients)

EDGE and GPRS mobiles Tests will be performed with Release 99 or release 4 MS supporting CS3-CS4 and EDGE. As it was mentioned before all the EDGE tests should be performed with the Nokia terminals 6230/6230i or Nokia 6630. Regarding the classical GPRS tests as all the current GPRS mobiles should support CS3/CS4 coding schemes different mobile suppliers could be used.
7.2.2
PC and applications MS will be connected to PCs running on Windows 2000 or Windows XP. In order to achieve the best performances with a 4+1 EDGE terminal the following TCP parameters will have to be modifed via the regedit command (increasing of the TCP transmission window + activation of the selective acknowledgement): ****In order to a have a clear definition of the modified parameters see the TCP parameters section in the Annex.
Register modification in the following folder: HKLM\SYSTEM\CurrentControlSet\Services\Tcpip\Parameters New TCP values: "TcpGlobalWindowSize"=dword:64000 "TcpWindowSize"=dword:64000 "SackOpts"=dword:00000001 "Tcp1323Opts"=dword:00000002
In order to generate automatic FTP download/upload or Web access, we advise to use the DEUTRIP (Data End User T raffic generatoR & Indicator Provider) too (see Ref [2]). This tool covers the main applications, which are automatically generated according to a set of parameters defined by the user. It provides application layer QoS indicators. These ones should be then correlated with radio layer indicators given by a third part tool, Nitro solution from Agilent for instance.
7.2.3
K1205 The K1205 could be used to monitor the Abis, Ater and Gb interfaces.
Date 07/2006
Edition 04.
Page 29
In B8 and in B9, a SW upgrade of this tool is needed in order to decode new/modified messages of the following specific protocol layers: RSL, BSCGP on GSL, EGCH and RLC/MAC. 7.2.4 Ethereal Ethereal is a TCP dump analyser that decodes most of the Internet protocols: FTP, Ping, HTTP, WTP/WSP (WAP), SMTP, POP3, IMAP4. This tool will be used on a spy PC to monitor the Gn and Gi interfaces. It may also be used on the PC to monitor the PPP layer. 7.2.5 Compass Compass will be used to post process GB traces provided by K1205. Compass has been developed as a tool to solve real radio interface issues. Compass can sort, analyze and graphically present huge amounts of captured data from the network in intuitive, easyto-use tables and graphs, pinpointing detected errors of weak spots in the network at exactly the right time. As an example: using Compass, it is possible to access the TCP/IP message flow and from this information retrieve statistics such as the DL TCP throughput. Also, the GMM messages, from the MS to the SGSN are available.
7.2.6
MFS terminal One MFS terminal can be connected in order to follow : the correct setting of radio parameters the correct allocation of the radio resources during the GPRS/EDGE transfers
7.3
Drive test measurement tool chain

Alcatel decided to use the Agilent product as drive test solution. The first official release for EDGE functionality was E6474A Release 8.0. All following releases are all EDGE capable. The product numbers needed are the following: E6474A #65: EDGE measurement SW Licence Key (Requires E6474A #600 GSM/GPRS Phone measurement SW Licence Key) E6473B #751: GSM/GPRS/EDGE Test mobile (Nokia 6230 European version) E5643A #100: Firmware update for Nokia 6230
Over the drive test solution proposed by Agilent, PCS has developed its own postprocessing
Date 07/2006
Edition 04.
Page 30
solution (DMS tool) that provides from the raw measurements some useful radio statistics related directly to the tests performed: Coding scheme usage in DL/UL directions Radio throughput per TBF Time slot allocation Mean BEP value Etc.
7.4
Qos follow-up ANAQOS tool

The ANAQOS tool could be the appropriate tool for experimentation. Used on several Alcatel networks where the customer did not purchase the RNO/NPA tool chain, ANAQOS was updated to support the B8 and B9 releases. This tool is a pure internal tool not included within the Alcatel product line.
Date 07/2006
Edition 04.
Page 31
8. 8.1
ANNEX: Detailed EDGE test plan
The following excell file will present: The detailed test plan The radio parameters which could be optimised in order to achieve the best performances The main GPRS/EGPRS RNO report
EDGE_Test_Plan_B8 _B9_v3.xls
Date 07/2006
Edition 04.
Page 32
8.2
TCP parameters
Parameter name
Value Type
Value Range
Default
Description This parameter determines the maximum TCP receive window size offered by the system. The receive window specifies the number of bytes a sender may transmit without receiving an acknowledgement. In general, larger receive windows will improve performance over high (delay * bandwidth) networks. For highest efficiency, the receive window should be an even multiple of the TCP Maximum Segment Size (MSS). MSS is generally MTU 40 (20 bytes for TCP header, 20 bytes for IP header), where MTU (Maximum Transmission Unit) is the largest packet size that can be transmitted. For MTU equals to 1400 (to avoid IP fragmentation on Gi), TcpWindowSize will be 65280 (48 * 1360). This parameter is both a per-interface parameter and a global parameter, depending upon where the registry key is located. If there is a value for a specific interface, that value overrides the systemwide value. The TCP Window Size parameter may be used to set the receive window on a per-interface basis. This parameter can be used to set a global limit for the TCP window size on a system-wide basis. This parameter is new in Windows 2000 and is considered as the default for all interfaces. It controls whether or not SACK (Selective Acknowledgement) support is enabled, as specified in RFC 2018. SACK is especially important for connections using large TCP Window sizes. Recommended settings for UMTS is 1. This parameter controls RFC 1323 time stamps and window-scaling options. Time stamps and window scaling are enabled by default, but can be manipulated with flag bits. Bit 0 controls window scaling, and bit 1 controls time stamps. Tcp1323Opts is a necessary setting in order to enable Large TCPWindow support as described in RFC 1323. Without this parameter, the TCPWindow is limited to 64K. For UMTS, the recommended value is 1. But Tcp1323Opts="3" might help in some cases where there is increased packet loss, however generally better throughput can be achieved with Tcp1323Opts="1", since Timestamps add 12 bytes to the header of each packet.
TCPWi ndowSi ze
Number of bytes
0 0x3FFF FFFF
* 8760 for Ethernet
Global Max TCP Windows Size
Numbe r of bytes
0 0x3FFF
FFFF
Does not exist by default
SackOpt s
0: False, Boolean 1: True
Tcp1323Opts
Number (flags)
0,1,2,3
No value
Date 07/2006
Edition 04.
Page 33

EDGE Field Trial Guideline: Originator File Date Edition

Uploaded by

Copyright:

Available Formats

EDGE Field Trial Guideline: Originator File Date Edition

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

EDGE Field Trial Guideline: Originator File Date Edition

Uploaded by

Copyright:

Available Formats

EDGE Field trial Guideline

File EDGE Trial Guideline

1. SCOPE....................................................................................................................5 2. EDGE FIELD TRIAL SEVERAL OBJECTIVES..................................................6

4. SYSTEM CONFIGURATION AND TEST ENVIRONMENT.................................11

5. EDGE VALIDATION TEST STRATEGY..............................................................15

6. QUALITY OF SERVICE MONITORING..............................................................27

File EDGE Trial Guideline

File EDGE Trial Guideline

Comments Creation of document the

File EDGE Trial Guideline

File EDGE Trial Guideline

EDGE FIELD TRIAL SEVERAL OBJECTIVES What Is EDGE

Several objectives for EDGE field trials

File EDGE Trial Guideline

File EDGE Trial Guideline

B8 release transmission resource management TRX Class concept

B9 release Transmission resource management

File EDGE Trial Guideline

File EDGE Trial Guideline

File EDGE Trial Guideline

SYSTEM CONFIGURATION AND TEST ENVIRONMENT Sytem configuration

Air BTS Abis BSC TC A MSC D HLR Radius

File EDGE Trial Guideline

File EDGE Trial Guideline

File EDGE Trial Guideline

File EDGE Trial Guideline

EDGE VALIDATION TEST STRATEGY

End User performances validation

File EDGE Trial Guideline

File EDGE Trial Guideline

File EDGE Trial Guideline

Manpower estimation for B8 release :

Manpower estimation for B9 release:

File EDGE Trial Guideline

Manpower estimation for B8 release (Standard tests):

File EDGE Trial Guideline

Manpower estimation for B8 release (DL re-segmentation tests):

EDGE performance tests - DL Re-segmentation influence - B8 release

Manpower estimation for B9 release (Standard tests):

Manpower estimation for B9 release (DL re-segmentation tests):

File EDGE Trial Guideline

Manpower estimation for B9 release (UL IR and re-segmentation tests):

File EDGE Trial Guideline

EDGE performances versus GPRS performances

DURATION (days) 0.875 2.625 1.75 5.25

File EDGE Trial Guideline

GPRS CS3/CS4 versus GPRS CS1/CS2

File EDGE Trial Guideline

Manpower estimation for B8 release :

File EDGE Trial Guideline

Maximum throughput achievable per coding scheme - B8 release

Manpower estimation for B9 release

File EDGE Trial Guideline

Manpower estimation for B8 release:

Manpower estimation for B9 release:

File EDGE Trial Guideline

QUALITY OF SERVICE MONITORING Quality of service monitoring EDGE experimentation

Quality of service monitoring EDGE Pilot