ETSI TC SMG TDoc SMG 388/96 Meeting #19 Kista, 24 - 28 ... · PDF file7.1 Physical interface layer 1 ... 8.1.3.3.4 No radio resources available ... 8.1.3.7.3 Reversion to old channel

ETSI TC SMG TDoc SMG 388/96 Meeting #19 Kista, 24 - 28 June 1996 Source : SMG8

CHANGE REQUEST TO

GSM 11.23 version 4.4.0

Introduction : This document contains a CR to the phase 2 version (4.4.0) of GSM 11.23, “Base Station System (BSS) equipment specification : Signalling Aspects"

Page CR Subject Cat 3 11.23-009 Final Review of 11.23 before PE F (Strategic) Other Comments:

This has been categorised as strategic because with the approval of this Change Request, it will be requested that 11.23 is submitted for Public Enquiry.

Page 1 of 31

Blank page

CHANGE REQUEST No. A009

Technical Specification GSM 11.23 version 4.4.0

Submitted to SMG for approval without presentation ("non-strategic") [ ]

with presentation ("strategic") [ X ]

Status at SMG#19 : Approved [ ] Rejected [ ] Postponed [ ]

Phase 1: [ ] Phase 2: [ x ] Phase 2+: [ ] Work item:

Other phase(s) affected: [ ] If yes, linked CR(s):

Proposed change affects: SIM [ ] ME [ ] Network [ X ]

Source: SMG8 Date: 23 May, 1996

Subject: Final Review of 11.23 before Public Enquiry

Category: F - Correction [ X ] A - Corresponds to a Phase 2 correction [ ] B - Addition of Feature [ ] C - Functional modification of Feature [ ] D - Editorial modification [ ]

Reason for change: The SMG8 signalling subgroup did a complete review of the specification to prepare it for public enqiry. The review dealt with the following items: - all references to other specifications are checked - open items are filled with an explicit meaning - normative references are completed - editorial errors are corrected Sections affected, and additional explanation of details of change (if needed):

Sections 5,8,9,10 and 11

Attached revised pages:

Page(s): 19-20, 67, 88-90, 93,164-165, 167-169, 174-177, 218-219, 221, 224, 240-241, 264-265, 272-273, 294-295 If other core Specifications are affected, necessary (and attached) Joint CRs:

Affects (possibly):

MS Test Specifications [ ] BSS Test Specifications [ ] O&M Specifications [ ]

Attached CRs?: Cross Phase Compatibility: Change affects operation of: Phase 1 MS in Phase 2(+) NW [ ] Phase 2(+) MS in Phase 1 NW [ ]

CR to 09.90 attached: Change affects operation of: Phase 1 SIM in Phase 2(+) ME[ ]

CR to 09.91 attached: Phase 2(+) SIM in Phase 1 ME [ ] CR to 09.91 attached:

Other comments:

Blank page

ETSI-SMG GSM 11.23

Technical Version: 4.4.0

Specification Date: May 1996

Key words: European Digital Cellular Telecommunications System, Global System for Mobile Communications (GSM).

GSM Signalling Aspects

Base Station System Equipment Specification

ETSI

European Telecommunications Standards Institute

ETSI Secretariat

Postal address: 06921 Sophia Antipolis Cedex - FRANCE Office address: Route des Lucioles - Sophia Antipolis - Valbonne - FRANCE

Tel.: +33 92 94 42 00 - Fax: +33 93 65 47 16

This is an unpublished work the copyright in which vests in the European Telecommunications Standards Institute. All rights reserved. The information contained herein is the property of ETSI and no part may be reproduced or used except as authorised by contract or other written permission. The copyright and the foregoing restriction on reproduction and use extend to all media in which the information may be embodied.

Page 2 GSM 11.23 v.4.4.0: May 1996

Blank page

CONTENTS

Foreword......................................................................................................................................................10

1 Scope........................................................................................................................................................12

2 Normative references ...............................................................................................................................12

3 Definitions, symbols and abbreviations ....................................................................................................14

4 Guide to Document...................................................................................................................................14 4.1 Layer 2 signalling.........................................................................................................................14 4.2 Layer 3 signalling.........................................................................................................................14 4.3 Core Recommendations..............................................................................................................14

5 Testing of Layer 2 (LAPDm) functions......................................................................................................15 5.1 Scope ..........................................................................................................................................15 5.2 Introduction..................................................................................................................................15 5.3 Layer 2 test frames......................................................................................................................15 5.4 General requirements..................................................................................................................16 5.5 Establishment of the dedicated physical resource ......................................................................17

5.5.1 MS-originated............................................................................................................17 5.5.1.1 Contention resolution on FACCH or SDCCH ....................................17 5.5.1.2 No Contention resolution on FACCH or SDCCH...............................18 5.5.1.3 No Contention resolution on FACCH ( No immediate Assign

procedures)..........................................................................19 5.5.1.4 No contention resolution on SACCH ( Short Message Service )......20

5.5.2 BSS-originated ..........................................................................................................20 5.5.2.1 Short Message Service .....................................................................20

5.6 Release of the dedicated physical resource................................................................................21 5.6.1 MS-originated............................................................................................................21 5.6.2 BSS-originated ..........................................................................................................21

5.7 LAPDm idle state.........................................................................................................................21 5.8 Signalling connections (SAPI=0) .................................................................................................23

5.8.1 Link establishment ....................................................................................................23 5.8.1.1 Normal initialisation (contention resolution).......................................23 5.8.1.2 Initialisation failure (contention resolution) ........................................23

5.8.1.2.1 Repeated SABM (loss of UA frame) .....................23 5.8.1.2.2 SABMs with different information fields ................24

5.8.1.3 Normal initialisation (no contention resolution)..................................26 5.8.2 Normal information transfer ......................................................................................27

5.8.2.1 Sequence counting and I frame acknowledgements.........................27 5.8.2.2 Receipt of an I frame in the timer recovery state...............................30 5.8.2.3 Segmentation and Concatenation .....................................................32

5.8.3 Normal Layer 2 release by MS..................................................................................33 5.8.4 Normal Layer 2 release by BSS................................................................................34 5.8.5 Abnormal release......................................................................................................34 5.8.6 Frame loss ................................................................................................................35

5.8.6.1 I Frame loss (BSS to BSSTE) ...........................................................35 5.8.6.2 RR Response frame loss (BSSTE to BSS) .......................................35 5.8.6.3 RR response frame loss (BSS to BSSTE) ........................................36

5.8.7 Reception of REJ frames ..........................................................................................37 5.8.7.1 Data link layer not in the timer recovery state....................................37 5.8.7.2 Data link layer in the timer recovery state, reception of a REJ

response frame....................................................................38 5.8.7.3 Data link layer in the timer recovery state, reception of a REJ

command frame...................................................................39 5.8.8 Frame transmission with incorrect C/R values..........................................................40

5.8.8.1 I frame with C bit set to one...............................................................40 5.8.8.2 SABM frame with C bit set to one......................................................41

Page 4 GSM 11.23 v.4.4.0: May 1996

5.8.9 Link failure ................................................................................................................ 42 5.8.10 Errors in the Control Field....................................................................................... 44

5.8.10.1 N(S) sequence error ....................................................................... 44 5.8.10.2 N(R) sequence error ....................................................................... 46 5.8.10.3 Improper F bit.................................................................................. 47

5.8.11 Receipt of invalid frames ........................................................................................ 49 5.9 Short Message Services (SMS) (SAPI=3) .................................................................................. 52

5.9.1 MS-originated link establishment ............................................................................. 53 5.9.2 BSS-originated link establishment............................................................................ 53

5.9.2.1 Normal initialisation (no contention resolution) ................................. 53 5.9.2.2 Initialisation failure (no contention resolution)................................... 54 5.9.2.3 Initialisation denial (no contention resolution) ................................... 55 5.9.2.4 Total initialisation failure (no contention resolution) .......................... 56

5.9.3 Normal information transfer...................................................................................... 57 5.9.4 Normal layer 2 release by MS. ................................................................................ 57 5.9.5 Normal Layer 2 release by BSS ............................................................................... 58 5.9.6 Abnormal release ..................................................................................................... 58 5.9.7 Frame loss................................................................................................................ 59 5.9.8 Reception of REJ frames ......................................................................................... 60

5.9.8.1 Data link layer not in the timer recovery state................................... 60 5.9.8.2 Data link layer in the timer recovery state, reception of a REJ

response frame ................................................................... 61 5.9.8.3 Data link layer in the timer recovery state, reception of a REJ

command frame .................................................................. 62 5.9.9 Frame transmission with incorrect C/R values......................................................... 63

5.9.9.1 I frame with C bit set to one .............................................................. 63 5.9.9.2 SABM frame with C bit set to one ..................................................... 64

5.9.10 Link failure .............................................................................................................. 66 5.9.11 Errors in the Control Field....................................................................................... 67 5.9.12 Receipt of invalid frames ........................................................................................ 68

5.10 Layer 3 functions....................................................................................................................... 68 5.11 Short Message Service Cell Broadcast (SMSCB) .................................................................... 68

6 Internal A-BIS interfacing ......................................................................................................................... 69 6.1 Layer 1 ........................................................................................................................................ 69 6.2 Signalling transport mechanism, layer 2 ..................................................................................... 69

6.2.1 Base Station Controller............................................................................................. 69 6.2.1.1 Successful TEI allocation - fixed TEI ................................................ 69 6.2.1.2 Denied TEI allocation - fixed TEI ...................................................... 71 6.2.1.3 Successful TEI allocation - additional TEI......................................... 72 6.2.1.4 Denied TEI allocation - additional TEI............................................... 73

6.2.2 Base Transceiver Station ......................................................................................... 74 6.2.2.1 Successful TEI allocation - fixed TEI ................................................ 75 6.2.2.2 Denied TEI allocation - fixed TEI ...................................................... 76 6.2.2.3 Successful TEI allocation - additional TEI......................................... 77 6.2.2.4 Denied TEI allocation - additional TEI............................................... 79

6.3 LAYER 3 ..................................................................................................................................... 80

7 Interfacing with the mobile services switching centre .............................................................................. 81 7.1 Physical interface layer 1 ............................................................................................................ 81 7.2 Signalling transport mechanism, layer 2 ..................................................................................... 81 7.3 Layer 3 protocol .......................................................................................................................... 81

8 Base station system network aspects ...................................................................................................... 82 8.1 Base station system network functions....................................................................................... 82

8.1.1 General..................................................................................................................... 82 8.1.2 Testing of the DTAP ................................................................................................. 83

8.1.2.1 Messages from MSC to MS.............................................................. 83 8.1.2.2 Messages from MS to MSC.............................................................. 84

8.1.3 Testing of the BSSMAP and RR functions ............................................................... 84 8.1.3.1 System information ........................................................................... 86

8.1.3.1.1 Dedicated resource set up ................................... 86

8.1.3.1.2 No dedicated resource established ......................87 GSM 04.08 §9.1.31 to 9.1.40 ........................................................................88 8.1.3.2 Service requests in SABM frames.....................................................88

8.1.3.2.1 Allowed messages................................................88 8.1.3.2.2 Not allowed messages..........................................89

8.1.3.3 Random access by MS and immediate assignment .........................90 8.1.3.3.1 Normal Case - SDCCH.........................................90 8.1.3.3.2 Normal Case - TCH ..............................................91 8.1.3.3.3 T3101 expiry case.................................................93 8.1.3.3.4 No radio resources available ................................95 8.1.3.3.5 Immediate assignment extended..........................96

8.1.3.4 Paging 97 8.1.3.4.1 Normal case..........................................................97 8.1.3.4.2 Paging reorganisation ...........................................98 8.1.3.4.3 Channel needed....................................................99

8.1.3.5 Measurement reporting ...................................................................100 8.1.3.6 Assignment......................................................................................100

8.1.3.6.1 Normal case........................................................100 8.1.3.6.2 T10 expiry ...........................................................101 8.1.3.6.3 Terrestrial resources already allocated...............103 8.1.3.6.4 Reverse to old channel .......................................104

8.1.3.7 External handover as seen from the old BSS..................................105 8.1.3.7.1 Normal case........................................................105 8.1.3.7.2 T8 expiry 107 8.1.3.7.3 Reversion to old channel ....................................108

8.1.3.8 External handover as seen from the new BSS................................109 8.1.3.8.1 Non-synchronised network .................................109 8.1.3.8.1.1 Normal Case..................................................110 8.1.3.8.1.2 No LAPDm connection ..................................112 8.1.3.8.1.3 Wrong Handover Reference..........................114 8.1.3.8.1.4 Wrong physical channel.................................115 8.1.3.8.1.5 No radio resources available .........................116 8.1.3.8.1.6 Clear Command from the MSC .....................117 8.1.3.8.1.7 No terrestrial resource available. ...................118 8.1.3.8.1.8 Handover - CLM2...........................................119 8.1.3.8.1.9 Handover - CLM2 and CLM3.........................120 8.1.3.8.2 Synchronised network.........................................120

8.1.3.9 Internal handover.............................................................................121 8.1.3.9.1 Internal inter-cell handover .................................121 8.1.3.9.1.1 Normal case...................................................121 8.1.3.9.1.2 No LAPDm connection ..................................123 8.1.3.9.2 Internal intra-cell handover .................................124 8.1.3.9.2.1. Intra-cell handover by the assignment

procedure............................................124 8.1.3.9.2.1.1 Normal case................................................124 8.1.3.9.2.1.2 T10 expiry ...................................................126 8.1.3.9.2.1.3 Reverse to old channel ...............................127 8.1.3.9.2.1.4 CLM2 ..........................................................128 8.1.3.9.2.2 Intra-cell handover by the handover procedure129 8.1.3.9.2.2.1 Normal case................................................129 8.1.3.9.2.2.2 T8 expiry .....................................................130 8.1.3.9.2.2.3 Reverse to old channel ...............................131

8.1.3.10 Frequency redefinition ...................................................................132 8.1.3.11 Transmission mode change ..........................................................133 8.1.3.12 Ciphering mode setting..................................................................134

8.1.3.12.1 Cipher Mode Complete.....................................135 8.1.3.12.2 DTAP message.................................................136 8.1.3.12.3 IMEISV request without starting encryption ......137 8.1.3.12.4 IMEISV request with invalid answer..................138 8.1.3.12.5 IMEISV not requested with invalid answer........140

8.1.3.13 Additional assignment ...................................................................141 8.1.3.14 Partial release................................................................................141

Page 6 GSM 11.23 v.4.4.0: May 1996

8.1.3.15 Classmark..................................................................................... 141 8.1.3.15.1 Classmark change ........................................... 141 8.1.3.15.2 Classmark Interrogation ................................... 142

8.1.3.16 Channel release............................................................................ 143 8.1.3.16.1 Normal case ..................................................... 143 8.1.3.16.2 T3109 expiry..................................................... 144 8.1.3.16.3 Radio resources out of service......................... 146

8.1.3.17 Radio link failure ........................................................................... 146 8.1.3.18 Blocking ........................................................................................ 147

8.1.3.18.1 Single circuit blocking....................................... 147 8.1.3.18.1.1 Normal Case ................................................. 147 8.1.3.18.1.2 Blocking a terrestrial circuit already used on

a call. .................................................. 149 8.1.3.18.1.3 No response to the Unblocking message. .... 150 8.1.3.18.1.4 Unblocking, Normal case. ............................. 151 8.1.3.18.1.5 MSC Reset during Blocking procedure. ........ 152 8.1.3.18.2 Circuit group blocking....................................... 153 8.1.3.18.2.1 Circuit group block - Normal case................. 153 8.1.3.18.2.2 Circuit group unblock - Normal case............. 154

8.1.3.19 Resource indication ...................................................................... 155 8. 1.3.19.1 Spontaneous indication ................................... 155

8.1.3.19.2 One single indication.................................................................. 157 8.1.3.19.3 Periodic indication ............................................ 157 8.1.3.19.4 No indication..................................................... 158 8.1.3.19.5 Extended resource indicator ............................ 160

8.1.3.20 Reset 160 8.1.3.20.1 Global reset ...................................................... 160 8.1.3.20.1.1 Global reset at the BSS................................. 161 8.1.3.20.1.2 Global reset at the MSC................................ 162 8.1.3.20.2 Reset circuit...................................................... 163 8.1.3.20.2.1 Reset circuit at the BSS ................................ 163 8.1.3.20.2.2 Reset circuit at the MSC................................ 164

8.1.3.21 Handover candidate enquiry ......................................................... 166 8.1.3.21.1 Handover candidate enquiry for 3 MSs. ........... 166 8.1.3.21.2 Handover candidate enquiry for 1 MS.............. 167 8.1.3.21.3 Repetition of the Handover candidate enquiry

message............................................. 168 8.1.3.22 Trace invocation............................................................................ 169

8.1.3.22.1 Trace invoked by the MSC............................... 169 8.1.3.22.2 Trace invoked by the BSS................................ 170

8.1.3.23 Flow control................................................................................... 170 8.1.3.23.1 Overload in the MSC........................................ 170 8.1.3.23.2 Overload in the BSS......................................... 171

8.1.3.24 Data link control for SAPI not equal to 0 ....................................... 171 8.1.3.24.1 MSC-originated transaction.............................. 171 8.1.3.24.1.1 Normal case .................................................. 171 8.1.3.24.1.2 MS failure. ..................................................... 172 8.1.3.24.1.3 SAPI 3 transactions rejected in the OMC...... 173 8.1.3.24.2. MS-originated transaction ............................... 174 8.1.3.24.2.1 Normal case .................................................. 174

8.1.3.25 Queuing indication ........................................................................ 175 8.1.3.25.1 Assignment case.............................................. 175 8.1.3.25.2 Handover case. ................................................ 177

8.1.3.26 Short Message Service Cell Broadcast (SMSCB) ........................ 178 8.1.3.27 Unequipped circuit ........................................................................ 178

8.1.3.27.1 Unequipped circuit - normal case..................... 178 8.1.3.27.2 Unequipped circuit used in assignment request

message............................................. 179 8.1.3.27.3 Unequipped circuit used in handover request

message............................................. 180 8.1.3.27.4 Unequipped circuit used in blocking

acknowledge message....................... 181

8.1.3.27.5 Unequipped circuit used in unblocking acknowledge message .......................182

8.1.3.27.6 Unequipped circuit used in reset circuit message .............................................183

8.1.3.27.7 Unequipped circuit used in circuit group blocking acknowledge message .........183

8.1.3.27.8 Unequipped Circuit used in circuit group unblocking acknowledge message .....184

8.1.3.27.9 Unequipped circuit used in unequipped circuit message .............................................185

8.1.3.28 Confusion ......................................................................................186 8.1.3.28.1 Confusion - reserved element used..................186 8.1.3.28.2 Confusion - zero length value ...........................186 8.1.3.28.3 Confusion, inconsistent length value ................187

9 Base station controller network aspects .................................................................................................189 9.1 Base station controller network functions..................................................................................189

9.1.1 General ...................................................................................................................189 9.1.2 Transparent messages ...........................................................................................190 9.1.3 Non-transparent messages.....................................................................................190

9.1.3.1 Link establishment indication...........................................................191 9.1.3.2 Link establishment request..............................................................193 9.1.3.3 Link release indication .....................................................................195 9.1.3.4 Link release request ........................................................................196 9.1.3.5 Transmission of transparent L3-message in acknowledged mode.197 9.1.3.6 Reception of transparent L3-message in acknowledged mode ......198 9.1.3.7 Transmission of transparent L3-message in unacknowledged

mode..................................................................................199 9.1.3.8 Reception of transparent L3-message in unacknowledged mode ..199 9.1.3.9 Link error indication .........................................................................199 9.1.3.10 Channel activation .........................................................................199 9.1.3.11 Channel mode modify....................................................................202 9.1.3.12 Handover detection .......................................................................204 9.1.3.13 Encryption......................................................................................205

9.1.3.13.1 Start of encryption.............................................205 9.1.3.13.2 Stop of encryption .............................................206 9.1.3.13.3 Failure case .....................................................207

9.1.3.14 Measurement reporting .................................................................208 9.1.3.14.1 Basic measurement reporting...........................208 9.1.3.14.2 Preprocessed measurement reporting

(optional) .............................................208 9.1.3.14.3 Preprocessing configuration (optional) .............208

9.1.3.15 Deactivate SACCH ........................................................................209 9.1.3.16 Radio channel release...................................................................211 9.1.3.17 MS power control (optional)...........................................................212 9.1.3.18 Transmission power control (optional) ..........................................213 9.1.3.19 Connection failure..........................................................................214 9.1.3.20 Physical context request (optional)................................................214 9.1.3.21 SACCH Info modify .......................................................................215 9.1.3.22 Channel request by MS .................................................................216 9.1.3.23 Paging 216 9.1.3.24 Delete indication ............................................................................217 9.1.3.25 CCCH load indication ....................................................................218 9.1.3.26 Broadcast information modify........................................................218 9.1.3.27 Immediate assignment ..................................................................219 9.1.3.28 Short Message Service Cell Broadcast (SMSCB).........................219 9.1.3.29 Radio resource indication ..............................................................219 9.1.3.30 SACCH filling information modify ..................................................221 9.1.3.31 Flow control ...................................................................................221 9.1.3.32 Error reporting ...............................................................................222

10 Base transceiver station network aspects ............................................................................................223

Page 8 GSM 11.23 v.4.4.0: May 1996

10.1 Base transeiver station network aspects functions................................................................. 223 10.1.1 General................................................................................................................. 223 10.1.2 Transparent messages......................................................................................... 223 10.1.3 Non-transparent messages .................................................................................. 223

10.1.3.1 Link establishment indication ........................................................ 224 10.1.3.1.1 SDCCH, Contention Resolution ....................... 225 10.1.3.1.2 FACCH, Contention Resolution, Channel Mode

modify, Sapi3...................................... 226 10.1.3.1.3 No Contention Resolution, Normal Case ......... 228

10.1.3.2 Link establishment request ........................................................... 229 10.1.3.2.1 Normal Case .................................................... 229 10.1.3.2.2 T200 x (N200 + 1) times expiry........................ 230

10.1.3.3 Link release indication .................................................................. 231 10.1.3.4 Link release request...................................................................... 232

10.1.3.4.1 Normal Case .................................................... 232 10.1.3.4.2 T200 x (N200 + 1) times expiry........................ 233

10.1.3.5 Transmission of transparent L3-message in acknowledged mode235 10.1.3.6 Reception of transparent L3-message in acknowledged mode.... 236 10.1.3.7 Transmission of transparent L3-message in unacknowledged

mode. ................................................................................ 237 10.1.3.8 Reception of transparent L3-message in unacknowledged mode 237 10.1.3.9 Link error indication....................................................................... 238 10.1.3.10 Channel activation....................................................................... 238 10.1.3.11 Channel mode modify................................................................. 239

10.1.3.11.1 Normal Case .................................................. 239 10.1.3.11.2 Abnormal Case .............................................. 240

10.1.3.12 Handover detection..................................................................... 241 10.1.3.12.1 Non-synchronised case.................................. 241 10.1.3.12.2 Synchronised case ......................................... 243

10.1.3.13 Start of encryption....................................................................... 244 10.1.3.13.1 Ciphering mode complete .............................. 244 10.1.3.13.2 DTAP message .............................................. 246 10.1.3.13.3 Start of encryption with unavailable algorithm 247 10.1.3.13.4 Stop ciphering ................................................ 248 10.1.3.13.5 Failure case................................................... 250

10.1.3.14 Measurement reporting............................................................... 250 10.1.3.14.1 Basic measurement reporting ........................ 251 10.1.3.14.2 Preprocessed measurement reporting

(optional)............................................. 252 10.1.3.14.3 Preprocessing configuration (optional)........... 252

10.1.3.15 Deactivate SACCH ..................................................................... 252 10.1.3.16 Radio channel release ................................................................ 253 10.1.3.17 MS power control ........................................................................ 254 10.1.3.18 Transmission power control (optional) ........................................ 255 10.1.3.19 Connection failure ....................................................................... 256 10.1.3.20 Physical context request (optional) ............................................. 257 10.1.3.21 Channel request by MS............................................................... 258 10.1.3.22 Paging......................................................................................... 258 10.1.3.23 Delete indication.......................................................................... 260 10.1.3.24 CCCH load indication.................................................................. 260 10.1.3.25 Broadcast information modify ..................................................... 260 10.1.3.26 Immediate assignment................................................................ 262

10.1.3.26.1 Normal case ................................................... 262 10.1.3.26.2 Extended immediate assignment procedure.. 263 10.1.3.26.3 Reject immediate assignment procedure....... 265

10.1.3.27 Short Message Service Cell Broadcast (SMSCB) ...................... 266 10.1.3.27.1 SMS broadcast request.................................. 266 10.1.3.27.2 SMS broadcast command.............................. 267

10.1.3.28 Radio resource indication ........................................................... 267 10.1.3.29 SACCH filling information modify................................................ 268 10.1.3.30 Flow control................................................................................. 270 10.1.3.31 Error reporting............................................................................. 270

11 GSM Phases interworking ....................................................................................................................272 11.1 Interworking between phase 1 mobile and phase 2 network ..................................................272 11.2 Interworking between phase 2 mobile and phase 1 network ..................................................272

11.2.1 Scope ....................................................................................................................272 11.2.2 References............................................................................................................272 11.2.3 Radio Interface......................................................................................................272

11.2.3.1 Information Elements ....................................................................272 11.2.3.1.1 Mobile Classmark 1 ..........................................272 11.2.3.1.1.1 Revision Level................................................272 11.2.3.1.1.1.1 Location updating - revision level 00..........273 11.2.3.1.1.1.2 Location updating - revision level 01..........274 11.2.3.1.1.1.3 Location updating - revision level 10..........274 11.2.3.1.1.1.4 Location updating - revision level 11..........275 11.2.3.1.1.2 Encryption algorithm A5/1..............................276 11.2.3.1.1.2.1 Location updating - encryption algorithm

A5/1.....................................................276 11.2.3.1.2 Mobile classmark 2 ...........................................277 11.2.3.1.2.1 Revision level.................................................277 11.2.3.1.2.1.1 CM Service - revision level 00 ....................277 11.2.3.1.2.1.2 CM Service - revision level 01 ....................278 11.2.3.1.2.1.3 CM Service - revision level 10 ....................279 11.2.3.1.2.1.4 CM Service - revision level 11 ....................280 11.2.3.1.2.2 Encryption algorithm A5/1..............................281 11.2.3.1.2.2.1 CM Service - encryption algorithm A5/1 .....281 11.2.3.1.2.3 Frequency capability ......................................282 11.2.3.1.2.3.1 CM Service .................................................282 11.2.3.1.2.4 SS Screening Indicator ..................................283 11.2.3.1.2.4.1 CM Service - SS Screening Indicator 01 ....283 11.2.3.1.2.4.2 CM Service - SS Screening Indicator 10 ....284 11.2.3.1.2.4.3 CM Service - SS Screening Indicator 11 ....284 11.2.3.1.2.5 PS Capability..................................................285 11.2.3.1.2.5.1 CM Service - PS Capability.........................285 11.2.3.1.2.6 Encryption Algorithm A5/2, A5/3 ....................286 11.2.3.1.2.6.1 CM Service - Encryption Algorithm A5/2.....286 11.2.3.1.2.6.2 CM Service - Encryption Algorithm A5/3.....287 11.2.3.1.2.6.3 CM Service - Encryption Algorithm A5/2,

A5/3.....................................................288 11.2.3.1.3 Location Updating Type ....................................289 11.2.3.1.3.1 Location Updating - Location -Updating Type289

11.2.3.2 Radio Resource Procedures .........................................................290 11.2.3.2.1 Assignment Procedure .....................................290 11.2.3.2.1.1 Assignment Failure - RR cause 09 ................290 11.2.3.2.1.2 Assignment Failure - RR cause 0A................291 11.2.3.2.2 Handover Procedure.........................................292 11.2.3.2.2.1 Handover Failure - RR cause 09 ...................293 11.2.3.2.2.2 Handover Failure - RR cause 0A...................294

11.2.3.3 Transmission Mode Change .........................................................295 11.2.3.3.1 Channel Mode Modify .......................................296

11.2.3.4 Messages ......................................................................................297 11.2.3.4.1 Classmark Change ...........................................297 11.2.3.4.1.1 Classmark Change - Mobile Station

Classmark 3 ........................................297 11.2.4 Abis Interface ........................................................................................................298 11.2.5 A Interface.............................................................................................................298

History........................................................................................................................................................299

Page 10 GSM 11.23 v.4.4.0: May 1996

Foreword

Blank page

Page 12 GSM 11.23 v.4.4.0: May 1996

1 Scope

This document contains the signalling aspects of the Base Station System for GSM. The set of signalling tests cover major areas of functionality on the air, Abis and A interfaces, but is not designed to be a complete set of all the possible scenarios.

The tests were designed from the set of core recommendations that exist for the GSM network and any changes that occur these recommendations will be reflected in the test set documented within.

2 Normative references

The following publications are referenced in this document. It is recommended that the relevant standards index is consulted for their full titles.

[1] GSM 01.04 (ETR 100): "Digital cellular telecommunications system (Phase 2); Abbreviations and acronyms".

[2] GSM 04.04 (ETS 300 553): "Digital cellular telecommunications system (Phase 2); layer 1 General requirements".

[3] GSM 03.01 (ETS 300 521): "Digital cellular telecommunications system (Phase 2); Network functions".

[4] GSM 04.05 (ETS 300 554): "Digital cellular telecommunications system (Phase 2); Data Link (DL) layer General aspects".

[5] GSM 04.06 (ETS 300 555): "Digital cellular telecommunications system (Phase 2); Mobile Station - Base Station System (MS - BSS) interface Data Link (DL) layer specification".

[6] GSM 04.08 (ETS 300 557): "Digital cellular telecommunications system (Phase 2); Mobile radio interface layer 3 specification".

[7] GSM 04.12 (ETS 300 560): "Digital cellular telecommunications system (Phase 2); Short Message Service Cell Broadcast (SMSCB) support on the mobile radio interface".

[8] GSM 05.02 (ETS 300 574): "Digital cellular telecommunications system (Phase 2); Multiplexing and multiple access on the radio path".

[9] GSM 05.05 (ETS 300 577): "Digital cellular telecommunications system (Phase 2); Radio transmission and reception".

[10] GSM 05.08 (ETS 300 578): "Digital cellular telecommunications system (Phase 2); Radio subsystem link control".

[11] GSM 05.10 (ETS 300 579): "Digital cellular telecommunications system (Phase 2); Radio subsystem synchronisation".

[12] GSM 08.02 (ETS 300 588-2): "Digital cellular telecommunications system (Phase 2); Base Station System - Mobile-services Switching Centre (BSS - MSC) interface; Interface Principles".

[13] GSM 08.06 (ETS 300 589): "Digital cellular telecommunications system (Phase 2); Signalling transport mechanism specification for the Base Station System - Mobile-services Switching Centre (BSS - MSC) interface".

[14] GSM 08.08 (ETS 300 590): "Digital cellular telecommunications system (Phase 2); Mobile Switching Centre - Base Station System (MSC - BSS) interface Layer 3 specification".

[15] GSM 08.51 (ETS 300 592): "Digital cellular telecommunications system (Phase 2); Base Station Controller - Base Transceiver Station (BSC - BTS) interface General aspects".

[16] GSM 08.52 (ETS 300 593): "Digital cellular telecommunications system (Phase 2); Base Station Controller - Base Transceiver Station (BSC - BTS) interface principles".

[17] GSM 08.56 (ETS 300 595): "Digital cellular telecommunications system (Phase 2); Base Station Controller - Base Transceiver Station (BSC - BTS) interface Layer 2 specification".

[18] GSM 08.58 (ETS 300 596): "Digital cellular telecommunications system (Phase 2); Base Station Controller - Base Transceiver Station (BSC - BTS) interface Layer 3 specification".

[19] GSM 09.90 (ETR 111): "Digital cellular telecommunications system (Phase2); Interworking between Phase1 infrastructure and Phase 2 Mobile Stations (MS)

[20] GSM 11.21: "Digital cellular telecommunications system; GSM Radio Aspects, Base Station System, Equipment Specification".

[21] GSM 11.22: "Digital cellular telecommunications system, Base Station and Ancillary Equipment, Physical and electrical parameters, Application of standards and guidance notes ".

[22] GSM 11.24: "Digital cellular telecommunications system; GSM Transcoding Aspects, Base Station System, Equipment Specification".

[23] GSM 12.20 (ETS 300 622): "Digital cellular telecommunications system (Phase 2); Network Management (NM) procedures and message on the A-bis interface".

Note: Subsequent references may be found in the specifications listed above.

Page 14 GSM 11.23 v.4.4.0: May 1996

3 Definitions, symbols and abbreviations

BSSTE Base Station System Test Equipment

Additional abbreviations used in this specification are listed in GSM 01.04 or in the concerned core recommendations.

4 Guide to Document

The document is divided into six separate signalling chapters, a description of each follows.

4.1 Layer 2 signalling

Clause 5 contains the test set for LAPDm on the air interface.

Clause 6 contains the test set for Internal A-bis interfacing. This interface is optional for GSM PLMN operators.

Clause 7 contains the specification for the A-interface. This chapter only contains a reference to the relevant CCITT, MTP recommendations.

4.2 Layer 3 signalling

Clause 8 contains the Base Station Signalling network aspects. It defines the BSS to be a black box and tests the relationship between the layer 3 messages on the air and A interfaces.

Clause 9 contains the Base Station Controller network aspects. The tests are primarily on the A-bis and will be used when one or more of the Base Station Transceivers in not co-located with the BSC.

Clause 10 contains the Base Station Transceiver network aspects. The tests are primarily on the A-bis and will be used when one or more of the Base Station Transceivers is not co-located with the BSC.

4.3 Core Recommendations.

Chapter Recommendations 5 GSM 04.06 6 GSM 08.56, GSM 08.58 7 CCITT Recommendations 8 GSM 04.06, GSM 04.08, GSM 08.08 9 GSM 04.08, GSM 08.08, GSM 08.58 10 GSM 04.08, GSM 08.08, GSM 08.58 11 GSM 04,08 GSM 08.08, GSM 09.90

5 Testing of Layer 2 (LAPDm) functions

5.1 Scope

The tests in this section apply to an integrated BSS as well as to a BTS.

The tests in this section are intended to verify the correct operation of the Layer 2 on the radio interface (LAPDm) on a per channel basis. The tests cover only the simplified protocol as described in GSM 04.06. Any interactions between Layer 2 on the radio interface and Layer 2 on the A-interface, or the A-bis interface if supported by the BSS, as well as the performance under traffic load, are outside the scope of the tests described in this section. The Layer 2 tests described in this section for the BSS are to great extent similar to the radio interface Layer 2 conformance tests for the Mobile Station (see GSM 11.10).

It should be noted that tests under traffic load, e.g. when the BSS is exposed to a high number of MS-originated or network originated calls or when Mobile Stations are performing handover at a high rate, are important to verify. It is, as also in the case of the MSC, up to the manufacturer to guarantee the operation of the BSS under a certain traffic load. It is a national or operator specific matter as to whether this shall be verified or not and how to verify it. The verification of the operation under traffic load conditions may differ depending of the internal structure of the BSS.

Tests of other than the simplified LAPDm protocol are a national or operator specific matter.

Only multiple frame operation will be tested. Transfer of unnumbered information is considered as tested implicitly by Layer 1 and Layer 3 tests.

5.2 Introduction

Before the LAPDm functions are tested, the Layer 1 functions must be verified in advance and T200 initialised. The logical channels SDCCH, FACCH and SACCH all have to be tested in turn with the appropriate tests.

The tests in this section are mostly carried out using the radio interface exclusively, and the tests are described for an integrated BSS. In some cases a message is input on the MSC-interface or the recording of a message on the MSC-interface is of importance to the test. In those case DTAP messages are used.

In the case of testing of a BTS, the DTAP messages used will be mapped on to a DATA REQUEST or DATA INDICATION message containing the DTAP message. It should also be noted that for a BTS there will be additional messages occurring at the A-bis-interface, like ESTABLISHMENT INDICATION, RELEASE INDICATION, ERROR INDICATION etc. These messages are of no importance to the tests.

Although all the tests in this section are described for an integrated BSS, it is also possible to connect the test equipment directly to the BTS and fulfil the test requirements by emulating the actions of both the BSC and MSC. on the test equipment.

5.3 Layer 2 test frames

The Layer 2 tests are accomplished by sequences of those frames which are contained in GSM 04.06 (Layer 2 frame repertoire etc.).

These frame sequences are under control of the BSSTE and are related to the state that the BSSTE perceives the BSS to be in as a result of frames transferred across the air interface.

These frame sequences shall comply with the following rules:

1. The test sequences exchanged between the BSSTE and BSS are assumed to be free from transmission errors.

2. The BSSTE may introduce errors in the direction BSSTE to BSS by inserting wrong parameters in

the address, control and length indication field. 3. The BSSTE may simulate errors in the direction BSS to BSSTE by ignoring the receipt of frames.

Page 16 GSM 11.23 v.4.4.0: May 1996

4. The BSSTE may violate the protocol rules related to the control of state variables to provoke

sequence gaps. 5. There is no contention on the Dm channel at Layer 1 (Layer 1 point-to-point). 6. With respect to contention on the Dm channel at Layer 2, two distinct situations are defined:

i) Test of the protocol procedure supported by a single entity. In this case there is no contention on the Dm channel (one peer-to-peer information transfer invoked at a time). This test applies to all BSSs and is performed for SAPI=0 and SAPI=3.

ii) Test of Layer 2 multiplexing and BSS processing capacity in terms of the number of SAPs

and links which a BSS is able to support simultaneously. In this case there is contention on the Dm channel at Layer 2 and this contention is resolved within Layer 2 based on the SAPI. This is considered part of the load testing of a BSS and is not defined in this specification. Load testing of a BSS is a national or operator specific matter.

5.4 General requirements

1) Timing requirement: The BSS shall respond to a command or repeat a command within T200 as defined in GSM 04.06

section 5.8.1. 2) Constant bit values: In each frame from the BSS the following shall be checked:

- bits 6 through 8 of the address field shall be set to zero as defined in GSM 04.06 section 3.1 and 3.2.

- except for tests 5.8.11 and 5.9.12, the address extension bit (EA bit) shall be set to 1 as

defined in GSM 04.06 section 3.3.1. - except for tests 5.8.11 and 5.9.12, the length indicator field extension bit (EL bit) shall be set

to 1 as defined in GSM 04.06 section 3.7.1.

3) Fill bits: The fill bits transmitted/received with each frame from/to the BSS whose length indicator L is less

than N201 as defined in GSM 04.06 section 5.8.3 shall be set as defined in GSM 04.06 section 2.2. It should be noted that the fill frames to be received by the BSS may occur in two different formats (see GSM 04.06).

4) Frame format description: The simplified LAPDm protocol does not utilise all Layer 2 frames defined in GSM 04.06. The

simplified LAPDm set of Layer 2 frames are listed in the following with their parameters: SABM (C, P, M = 0, L = 0) SABM (C, P, M = 0, L > 0) DISC (C, P, M = 0, L = 0) UA (R, F, M = 0, L = 0) UA (R, F, M = 0, L > 0) DM (R, F, M = 0, L = 0) RR (C, P, M = 0, L = 0, N(R)) RR (R, F, M = 0, L = 0, N(R)) REJ(C, P, M = 0, L = 0, N(R)) REJ(R, F, M = 0, L = 0, N(R)) I (C, P, M = 0, 0 < L < N201, N(S), N(R)) I (C, P, M = 1, L = N201, N(S), N(R))

UI (C, P = 0, M = 0, L = 0) UI (C, P = 0, M = 0, L < N201) SABM = Set Asynchronous Balanced Mode (Command) DISC = DISConnect (Command) UA = Unnumbered Acknowledge (Response) DM = Disconnect Mode (Response) RR = Receive Ready (Command/Response) REJ = Reject (Command/Response) I = Information transfer (Command) UI = Unnumbered Information (Command) C = Command R = Response P = Poll F = Final M = More data bit L = Length indicator N(S) = Send sequence number N(R) = Receive sequence number.

NOTE: If L=0 in a LAPDm frame, this means that there is no information field in it. If 0 < L <= N201, the frame contains a Layer 3 message.

5) Unnumbered Information (UI frames): The BSS shall at any instant during each of the tests described in this section be able to transmit

and receive Unnumbered Information (UI) frames without influence on the multiple frame operation. 6) Fill frames In periods when no other frames are scheduled for transmission on an SDCCH, or on the

TCH/FACCH when configured for signalling only, fill frames shall be sent by the BSS. A fill frame is a UI command frame, P=0, for SAPI=0 with an information field of 0 octets length.

5.5 Establishment of the dedicated physical resource

5.5.1 MS-originated

5.5.1.1 Contention resolution on FACCH or SDCCH

Test Purpose

To establish a connection between the mobile station and the base station.

Test case

Initial Setup

No initial setup required

Description

For tests on the Main Signalling Link (MSL) with contention resolution, i.e. the FACCH or the SDCCH, the BSSTE shall input a CHANNEL REQUEST message on the radio interface of the BSS. The BSS should then respond with an IMMEDIATE ASSIGN message in order to assign either a FACCH or an SDCCH, and expect an SABM frame with information element (contention resolution) from the BSSTE. The BSSTE shall then input an SABM frame (SAPI=0) with contention resolution.

Page 18 GSM 11.23 v.4.4.0: May 1996

Message Flow

BSSTE(MS)_ BSS 1 ------------ Channel request ------------> <-----------Immediate Assign ------------- 2 3 -------- SABM ( SAPI, C, P, M, L) -------> <-------- UA ( SAPI, R, F, M, L ) -------- 4 The frame from the BSSTE will be:

3. SABM frame containing: SAPI = 0, C = 0, P = 1, M = 0, 0 < L <= N201 Information Field = CM Service Request

Conformance requirements

The frame from the BSS shall be:

4. UA frame containing: SAPI = 0, R = 0, F = 1, M = 0, L = L of SABM Information Field = information field of SABM Requirements reference

The operation is defined in GSM 04.06, section 5.4.1.4

5.5.1.2 No Contention resolution on FACCH or SDCCH

Test Purpose

To establish a link between the mobile station and the base station without contention resolution.

Test Case

Initial Setup

No initial setup is required

Description

For tests on the main signalling link without contention resolution, the procedure in test 5.5.1.1 shall be performed and acknowledged.The BSSTE shall input a correct I-frame and the BSS shall respond with an RR-frame., and then tThe BSSTE shall then input a second SABM frame without information element (without contention resolution).

Message Flow

BSSTE(MS) BSS 1 ------------ Channel request ------------> <-----------Immediate Assign ------------- 2 3 -------- SABM ( SAPI, C, P, M, L) -------> <-------- UA ( SAPI, R, F, M, L ) -------- 4 5 -------I (SAPI, C, P, M, L, N(R), N(S))--> <-------- RR ( SAPI, R, F, M, L, N(R)) --- 6 75 -------- SABM ( SAPI, C, P, M, L) -------> <-------- UA ( SAPI, R, F, M, L ) -------- 86

The frames from the BSSTE will be:

3. SABM frame containing: SAPI = 0, C = 0, P = 1, M = 0, 0 < L <= N201 Information Field = CM Service Request 5. I frame containing: SAPI = 0, C = 0, P = 0, M = 0, 0 < L <= N201 N(R) = 0, N(S) = 0 75. SABM frame containing: SAPI = 0, C = 0, P = 1, M = 0, L = 0 Conformance Requirements


4. UA frame containing: SAPI = 0, R = 0, F = 1, M = 0, L = L of SABM Information Field = information field of SABM 6. RR frame containing: SAPI = 0, R = 0, F = 0, M = 0, N(R) = 1 86. UA frame containing SAPI = 0, R = 0, F = 1, M = 0, L = 0 Requirements Reference

This operation is defined in GSM 04.06, section 5.4.1.2.

5.5.1.3 No Contention resolution on FACCH ( No immediate Assign procedures)

Test Purpose

To establish a link between the mobile station and the base station when the BTS does not support the allocation of the TCH by the immediate assignment message.

Test Case

Initial Setup

The test is setup as specified in test 5.5.1.1.

Description

An ASSIGNMENT REQUEST message is sent to the BSS from the MSC which results in a ASSIGNMENT COMMAND message being sent to the mobile, to assign the TCH. The mobile replies with a SABM of zero length which is acknowledged by the BSS with a UA of zero length. The mobile completes the sequence with a ASSIGNMENT COMPLETE message.

Page 20 GSM 11.23 v.4.4.0: May 1996

Message Flow

BBSTE(MS) BSS MSC 1-------Channel request----------> <------Immediate Assign----------2 3-----SABM(SAPI, C, P, M, L)-----> <----UA (SAPI, R, F, M, L)-------4 <-------Assignment request------ <-----Assignment command-------- 5-----SABM(SAPI, C, P, M, L)-----> <----UA ( SAPI, R, F, M, L)------6 --------Assignment complete------> The frames from the BSSTE will be:

3. SABM frame containing: SAPI = 0, C = 0, P = 1, M = 0, 0 < L <= N201 Information Field = CM Service Request 5. SABM frame containing: SAPI = 0, C = 0, P = 1, M = 0, L = 0 Conformance Requirements


4. UA frame containing: SAPI = 0, R = 0, F = 1, M = 0, L = L of SABM Information Field = information field of SABM 6. UA frame containing SAPI = 0, R = 0, F = 1, M = 0, L = 0 Requirements Reference

This operation is defined in GSM 04.06, section 5.4.1.2.

5.5.1.4 No contention resolution on SACCH ( Short Message Service )

For tests on the SACCH the above procedure on the main signalling link with contention resolution shall be performed and acknowledged, and then an SABM frame without contention resolution indicating SAPI=3 concerning a Short Message Service (SMS) shall be input from the BSSTE. The state of the BSSTE shall be as if an SMS service request has been accepted.

5.5.2 BSS-originated

The establishment of the dedicated physical resources will be as in section 5.5.1

This establishment applies only to Short Message Services (SMS) on the SACCH or on the SDCCH with SAPI=3.

5.5.2.1 Short Message Service

The establishment procedure on the main signalling link with contention resolution in section 5.5.1.1 shall be performed and acknowledged, and then any DTAP message indicating SAPI=3 concerning a Short Message Service (SMS) shall be input on the MSC-interface of the BSS. Then an SABM frame without contention resolution shall be expected from the BSS.

5.6 Release of the dedicated physical resource

5.6.1 MS-originated

After a test has been performed the BSSTE shall initiate the release of the SDCCH or FACCH by sending a LAPDm DISC frame to the BSS.

5.6.2 BSS-originated

This release applies only to Short Message Services (SMS) on the SACCH with SAPI=3.

After a test has been performed the BSSTE shall initiate the release of the SACCH by inputting a SAPI "n" CLEAR COMMAND message indicating SAPI=3 on the MSC-interface of the BSS. A LAPDm DISC frame indicating SAPI=3 shall then be expected from the BSS.

5.7 LAPDm idle state

Test Purpose

To test that the BSS responds correctly to received frames when in the idle state.

Test Case

Initial Setup

The BSS shall be in the LAPDm idle state. This is obtained by carrying out the MS-originated link establishment in the first paragraph of section 5.5.1, but without inputting the SABM frame. This applies to the main signalling link as well as to the SACCH.

Description

The BSSTE shall then in turn input:

- a DISC frame - an I frame with P=1 - an RR frame with P=1 In all cases the BSS should respond with a DM frame with F=1.

Further, the BSSTE shall in turn input:

- a UA frame - a DM frame with F=1 - an RR frame with F=1 - an I frame with P=0 - an I frame with L=0 In all cases the BSS shall not respond and the timer T200 shall expire in the BSSTE.

NOTE: Due to a timeout of timer T3101 at Layer 3 (see GSM 04.08), it may not be possible to perform the complete test in one row. In this case, the MS-originated link establishment shall be repeated and the test continued from when it was interrupted by T3101.

Page 22 GSM 11.23 v.4.4.0: May 1996

Message Flow

BSSTE (MS) BSS 1 --------DISC (SAPI, C, P, M, L)----------> <-------DM (SAPI, R, F, M, L)------------- 2 3 --- I (SAPI, C, P, M, L, N (R), N(S))----> <-------DM (SAPI, R, F, M, L)------------- 2 4 ----- RR (SAPI, C, P, M, L, N (R))-------> <-------DM (SAPI, R, F, M, L)------------- 2 5 ------- UA (SAPI, R, F, M, L)------------> Timeout of T200 6 ------- DM (SAPI, R, F, M, L)------------> Timeout of T200 7 ----- RR (SAPI, R, F, M, L, N(R))--------> Timeout of T200 8 --- I (SAPI, C, P, M, L, N(R),N(S))------> Timeout of T200 9 --- I (SAPI, C, P, M, L, N(R),N(S))------>


1. DISC frame containing: SAPI = 0, C = 0, P = 1, M = 0, L = 0 3. I frame containing: SAPI = 0, C = 0, P = 1, M = 0, 0 < L <= N201 N(R)=0, N(S)=0 4. RR frame containing: SAPI = 0, C = 0, P = 1, M = 0, L = 0 N(R)=0 5. UA frame containing: SAPI = 0, R = 1, F = 1, M = 0, L = 0 6. DM frame containing: SAPI = 0, R = 1, F = 1, M = 0, L = 0 7. RR frame containing: SAPI = 0, R = 1, F = 1, M = 0, L = 0 N(R)= 0 8. I frame containing: SAPI = 0, C = 0, P = 0, M = 0, 0 < L <= N201 N(R)=1, N(S)=1 9. I frame containing: SAPI = 0, C = 0, P= 0, M = 0, L = 0 N(R)=1, N(S)=1 Conformance Requirements

The frames from the BSS shall be:

2. DM frame containing: SAPI = 0, R = 0, F = 1, M = 0, L = 0 Requirements Reference

The operation of this is described in GSM 04.06 section 5.4.5.

5.8 Signalling connections (SAPI=0)

The signalling for Call Control (CC), Mobility Management (MM), Radio Resource management (RR) and Supplementary Services support (SS) as defined in GSM 04.08 and GSM 04.10 is characterised on Layer 2 by:

- SAPI=0 - The LAPDm signalling link is always established by MS - Contention resolution may be required. Hence, only MS-originated link establishment is tested in this section.

All the tests in this section shall be performed on a FACCH and on an SDCCH. The test on the FACCH shall be carried out twice, if both possibilities are supported by the BSS/BTS as an operator or manufacturer choice, once when the TCH/FACCH is used for signalling only and once when the TCH/FACCH is used for speech/data and signalling.

For tests without contention resolution, as an alternative to the establishment procedure in section 5.5.1, the FACCH or SDCCH may also be established by using the dedicated assignment procedure of section 8.1.3.6 assigning either any traffic channel or only signalling channels, respectively.

5.8.1 Link establishment

5.8.1.1 Normal initialisation (contention resolution)

Test Purpose

To test the normal establishment of multiple frame operation between the BSS and the MS when contention resolution is required. .

Test Case

This test is defined in section 5.5.1.1.

Requirements Reference

The operation of this is described in GSM 04.06 section 5.4.1.4

5.8.1.2 Initialisation failure (contention resolution)

5.8.1.2.1 Repeated SABM (loss of UA frame)

Test Purpose

To test that the BSS can properly handle a repeated SABM frame with contention resolution due to loss of the UA frame sent to the MS.

Page 24 GSM 11.23 v.4.4.0: May 1996

Test Case

Initial Setup

The signalling link is set up according to section 5.5.1.1 ending with an SABM frame from the BSSTE.

Description

The BSS should respond with a UA frame.

The BSSTE shall then simulate the loss of the UA frame by repeating the SABM frame after T200.

The BSS should again respond with a UA frame.

The link shall then be released as described in section 5.6.1.

Message Flow

BSS---------------------------------------------BSSTE (MS) <---------SABM (SAPI, C, P, M, L)----------------- 1 | 2 -----------UA (SAPI, R, F, M, L)-----------------> T200 | <---------SABM (SAPI, C, P, M, L)----------------- 1 2 -UA (SAPI, R, F, M, L)----------------->


1. SABM frame containing: SAPI = 0, C = 0, P = 1, M = 0, 0 < L <= N201 information field = CM SERVICE REQUEST Conformance Requirements


2. UA frame containing: SAPI = 0, R = 0, F = 1, M = 0, L = L of SABM information field = information field of SABM Requirements Reference

The operation of this is described in GSM 04.06 section 5.4.1.4.

5.8.1.2.2 SABMs with different information fields

Test Purpose

To test that the BSS will ignore an SABM frame with contention resolution when another SABM frame with contention resolution is already received but unacknowledged, and when the information contents in the 2 are different. It is also tested that new SABMs with contention resolution are ignored when received in the multiple frame established state. It also tests that new SABMs without contention resolution are ignored when received in the contention resolution receiver state.

NOTE: Concerning a re-establishment of the link, an SABM frame without contention resolution will be used. Otherwise the SABM with contention resolution will occur from the idle state.

Test Case

Initial Setup

The signalling link is set up according to section 5.5.1.1. The information in the SABM and UA shall be defined as I1.

Description

Another SABM frame with contention resolution, but with different information field (info=I2) shall be input.

The BSS should ignore the 2nd SABM frame and timer T200 shall expire in the BSSTE.

Then another SABM frame without contention resolution (no information field) shall be input by the BSSTE.

The BSS should ignore this SABM frame and timer T200 shall expire in the BSSTE.

Another SABM frame with contention resolution (info=I1) shall be input by the BSSTE.

The BSS should respond with a UA frame with contention resolution (info=I1).

The BSSTE shall then input a correct I frame and the BSS should respond with an RR frame.

Another SABM frame with contention resolution (info=I1) shall be input by the BSSTE.

The BSS should ignore this SABM frame and timer T200 shall expire in the BSSTE.

Another SABM frame without contention resolution (no information field) shall be input by the BSSTE. The BSS should respond with a UA frame.

The BSS is returned to the idle state as described in section 5. 6.1.

Message Flow

BSS BSSTE (MS) <-------------------------------- SABM (SAPI, C, P, M, L, I1) -------------------------------1 2 -----------------------------------UA (SAPI, R, F, M, L, I1) ---------------------------------> <-------------------------------- SABM (SAPI, C, P, M, L, I2) -------------------------------3 Timeout of T200 <---------------------------------- SABM (SAPI, C, P, M, L) ---------------------------------4 Timeout of T200 <-------------------------------- SABM (SAPI, C, P, M, L, I1) -------------------------------1 2 -----------------------------------UA (SAPI, R, F, M, L, I1) ---------------------------------> <------------------------------ I (SAPI, C, P, M, L, N (R), N(S))-----------------------------5 6 --------------------------------- RR (SAPI, R, F, M, L, N(R))--------------------------------> <-------------------------------- SABM (SAPI, C, P, M, L, I1) -------------------------------1 Timeout of T200 <---------------------------------- SABM (SAPI, C, P, M, L) ---------------------------------4

Page 26 GSM 11.23 v.4.4.0: May 1996

2----------------------------------- UA (SAPI, R, F, M, L, I1) --------------------------------->


1. SABM frame containing: SAPI = 0, C = 0, P = 1, M = 0, 0 < L <= N201 information field = CM SERVICE REQUEST 3. SABM frame containing: SAPI = 0, C = 0, P = 1, M = 0, 0 < L <= N201 information field = PAGING RESPONSE 4. SABM frame containing: SAPI = 0, C = 0, P = 1, M = 0, L = 0 5. I frame containing: SAPI = 0, C = 0, P = 1, M = 0, 0 < L <= N201 N(R)=0, N(S)=0 Conformance Requirements


2. UA frame containing: SAPI = 0, R = 0, F = 1, M = 0, L = L of SABM information field = information field of SABM 6. RR frame containing: SAPI = 0, R = 0, F = 1, M = 0 N(R)=1 Requirements Reference


5.8.1.3 Normal initialisation (no contention resolution)

Test Purpose

To test the normal initialisation of multiple-frame operation when contention resolution is not required.

This procedure is used after a data link once has been established with contention resolution and a new data link is established on a new channel, e.g. handover or dedicated channel assignment.

Test Case

Initial Setup

The data link is set up between the BSSTE and the BSS as in test 5.5.1.2 ending with an SABM frame without contention resolution from the BSSTE.

Description

The BSS shall respond with a UA frame.

The link shall then be released according to section 5.6.1.

Message Flow

BSS BSSTE (MS) <---------------------------------- SABM (SAPI, C, P, M, L) ---------------------------------1 2 -------------------------------------UA (SAPI, R, F, M, L) ----------------------------------->


1. SABM frame containing: SAPI = 0, C = 0, P = 1, M = 0, L = 0 Conformance Requirements


2. UA frame containing: SAPI = 0, R = 0, F = 1, M = 0, L = 0 Requirements reference


5.8.2 Normal information transfer

5.8.2.1 Sequence counting and I frame acknowledgements

Test Purpose

To test the operation of Layer 2 sequence numbering and transferring Layer 2 acknowledgements in I frames ("piggy-backing"). Since there are 8 sequence numbers, the test cycles through 9 information frame transfers.

The non-interfering reception of a UI frame is also tested since this might imply extra RR frames depending on time constraints.

Otherwise the non-interfering reception of a UI frame should be verified at any time during other tests.

Test Case

Initial Setup

The BSS shall be initialised as described in test 5.8.1.1. This will include the establishment of the corresponding SCCP connection on the MSC-interface of the BSS.

Description

On the radio interface the BSSTE shall input a series of 9 I frames, each containing the CONNECT ACKNOWLEDGE message, as rapidly as the LAPDm protocol with window size 1 will allow.

NOTE 1: Any other DTAP message with SAPI=0 will also serve the purpose, as long as it is short enough not to need segmentation on the radio interface, i.e. at most 20 octets.

After the 3rd I frame, the BSSTE shall input a UI frame into the series of I frames.

During the same time the BSSTE shall input 9 CONNECT ACKNOWLEDGE messages on the MSC-interface as rapidly as the protocol on the SS7 link will allow. The output of the BSS on the MSC-interface

Page 28 GSM 11.23 v.4.4.0: May 1996

will not be evaluated in this test. The BSSTE will, however, have to perform all MSC-interface functions needed to make the BSS transmit on the MSC-interface.

NOTE 2: It is assumed that:

DTAP messages on the MSC-interface can be input at a rate of at least one message every 235 ms (recurrence rate of the SDCCH).

The transfer of a DTAP message through the BSS does not take longer than 235 ms.

If one of the assumptions is not valid, then the BSS will be found using RR frames for acknowledging I frames instead of piggy-backing acknowledgements into its own I frames.

The BSS should acknowledge the I frames which it received from the BSSTE with first 1 RR frame and with I frames thereafter. Even the first RR frame might be substituted by an I frame if DTAP messages are routed through the BSS fast enough. After the UI frame from the BSSTE, the BSS shall repeat its last I frame, but with the P bit set to 1 this time. The BSSTE shall respond with an RR response, F=1. Thereafter the transmission of I frames shall be resumed on both sides.

NOTE 3: On the FACCH the sequence of frames might be quite different. Depending on the transfer time through the BSS and on the speed with which DTAP messages can be input on the MSC-interface, the BSS may always have to use RR frames for acknowledgements.

After all I frames have been sent and acknowledged, UI fill frames shall be transmitted by both the BSS and the BSSTE (only during signalling only - not on the TCH/FACCH during speech/data and signalling). The BSSTE shall stop transmitting UI fill frames after 3 UI frames.

Message Flow

BSSTE BSSTE (MS) BSS (MSC) CONN ACK 1 ----------I (SAPI, C, P, M, L, N(S), N(R))----> <---------------- CONN ACK <---------RR (SAPI, R, M, L, N(R), F)---------- 2 <---------------- CONN ACK 3 ----------I (SAPI, C, P, M, L, N(S), N(R))----> <---------------- CONN ACK <-----------I (SAPI, C, P, M, L, N(S), N(R))--- 4 <---------------- CONN ACK 5-----------I (SAPI, C, P, M, L, N(S), N(R))----> <---------------- CONN ACK <-----------I (SAPI, C, P, M, L, N(S), N(R))--- 6 <---------------- CONN ACK 7----------------UI (SAPI, C, P, M, L)----------> <---------------- CONN ACK <-----------I (SAPI, C, P, M, L, N(S), N(R))--- 8 <---------------- CONN ACK 9 ------------RR (SAPI, R, F, M, L, N(R))-------> <---------------- <-----------I (SAPI, C, P, M, L, N(S), N(R))--- 10 11 ---------I (SAPI, C, P, M, L, N(S), N(R))----> <-----------I (SAPI, C, P, M, L, N(S), N(R))--- 12 13 ---------I (SAPI, C, P, M, L, N(S), N(R))---->

<-----------I (SAPI, C, P, M, L, N(S), N(R))--- 14 15 ---------I (SAPI, C, P, M, L, N(S), N(R))----> <-----------I (SAPI, C, P, M, L, N(S), N(R))--- 16 17 ---------I (SAPI, C, P, M, L, N(S), N(R))----> <-----------I (SAPI, C, P, M, L, N(S), N(R))--- 18 19 ---------I (SAPI, C, P, M, L, N(S), N(R))----> <-----------I (SAPI, C, P, M, L, N(S), N(R))--- 20 21 ---------I (SAPI, C, P, M, L, N(S), N(R))----> <-----------I (SAPI, C, P, M, L, N(S), N(R))--- 22 23 -------------RR (SAPI, R, P, M, L, N(R))-----> Not during speech/data <------------------UI (SAPI, C, P, M, L)------- 24 Not during speech/data 25 ----------------UI (SAPI, C, P, M, L)-------->


1,3,5,11,13,15,17,19,21: I frame containing: SAPI = 0, C = 0, P = 0, M = 0, L = 2 N(S) = 0, 1, 2, 3....7, 0 N(R) = 0, 0, 1, 3....7, 0 information field = CONNECT ACKNOWLEDGE 7,25: UI frame containing: SAPI = 0, C = 0, P = 0, M = 0, L = 0 9: RR frame containing: SAPI = 0, R = 1, F = 1, M = 0, L = 0, N(R) = 2 23: RR frame containing: SAPI = 0, R = 1, F = 0, M = 0, L = 0, N(R) = 1 Conformance Requirements


2: RR frame containing: SAPI = 0, R = 0, F = 0, M = 0, N(R) = 1 4,6,10,12,14,16,18,20,22: I frame containing: SAPI = 0, C = 1, P = 0, M = 0, L = 2 N(S) = 0,1,2,3,4....6,7,0 N(R) = 2,3,3,4,5....7,0,1 information field = CONNECT ACKNOWLEDGE 8: I frame containing: SAPI = 0, C = 1, P = 1, M = 0, L = 2

Page 30 GSM 11.23 v.4.4.0: May 1996

N(S) = 1 N(R) = 3 information field = CONNECT ACKNOWLEDGE 24: UI frame (fill frame) containing: SAPI = 0, C = 1, P = 0, M = 0, L = 0 Requirements Reference

The operation of this is described in GSM 04.06 section 5.5.2

5.8.2.2 Receipt of an I frame in the timer recovery state

Test Purpose

To test that the BSS is able to respond to I frames also while in the timer recovery state.

Test Case

Initial Setup

The link shall be established according to section 5.8.1.1.

Description

The BSSTE shall input an AUTHENTICATION REJECT message to the BSS on the MSC-interface. The BSS should then respond with an I frame on the radio interface.

The BSSTE shall not respond, and the BSS should either repeat the I frame or reply with an RR frame after the expiry of timer T200.

Before the expiry of T200 again, the BSSTE shall input an I frame on the radio interface containing the message CONNECT ACKNOWLEDGE, but not acknowledging the received I frame from the BSS.

After the expiry of T200, the BSS should repeat the I frame or RR frame once again, but acknowledging the I frame received from the BSSTE.

The test is stopped by the BSSTE with an RR frame acknowledging the I frame or RR frame received from the BSS.

Message Flow

BSSTE BSSTE (MS) BSS (MSC) AUTH REJ <------------------- <-----I (SAPI, C, P, M, L, N(S), N(R))----------- 1 -- | T200 <-----I (SAPI, C, P, M, L, N(S), N(R))----------- 2 | or | <-------RR( SAPI, C, P, M, L, N(R))-------------- 2bis _ | 3 ----I (SAPI, C, P, M, L, N(S), N(R))----------> _- | T200 | <-----I (SAPI, C, P, M, L, N(S), N(R))----------- 4 | or | <--------RR( SAPI, C, P, M, L, N(R))-------------- 4bis| _ | 5 -------RR (SAPI, R, F, M, L, N(R))------------> -


3: I frame containing: SAPI = 0, C = 0, P = 0, M = 0, 0< L <= N201 (L = 2) N(S) = 0 N(R) = 0 information field = CONNECT ACKNOWLEDGE 5: RR frame containing: SAPI = 0, R = 1, F = 1, M = 0, L = 0 N(R) = 1 Conformance Requirements


1: I frame containing: SAPI = 0, C = 1, P = 0, M = 0, 0< L <= N201 (L = 2) N(S) = 0 N(R) = 0 information field = AUTHENTICATION REJECT 2,4: I frame containing: SAPI = 0, C = 1, P = 1, M = 0, 0< L <= N201 (L = 2) N(S) = 0,0 N(R) = 0,1 information field = AUTHENTICATION REJECT 2bis, 4bis:

RR frame containing: SAPI = 0, C = 1, P = 1, M = 0, L = 0 N(R) = 0,1


The operation of this is described in GSM 04.06, section 5.5.2

Page 32 GSM 11.23 v.4.4.0: May 1996

5.8.2.3 Segmentation and Concatenation

Test Purpose

To test the proper use of segmentation and concatenation.

Test Case

Initial Setup


Description

Then the BSSTE shall input a SETUP message exceeding 22 and less than 37 octets to the BSS on the MSC-interface. The BSS should then output this message on the radio interface in two I frames.

NOTE: Any other DTAP message which is longer than 18-22 octets depending on the signalling channel used would also serve the purpose.

The BSSTE shall acknowledge each of the two I frames received from the BSS with an RR frame.

The BSSTE shall now input a SETUP message on the radio interface, length between 23 and 36 octets, in two I frames. The BSS should acknowledge both I frames with two RR frames and should output the SETUP message on the MSC-interface.

Then both sides may start transmitting UI fill frames if the test is on an SDCCH or on the FACCH during signalling only (not on a TCH/FACCH during speech/data and signalling).

Message Flow

BSSTE BSSTE (MS) BSS (MSC) SETUP <--------- <---------I (SAPI, C, P, M, L, N(S), N(R))--------1 2---------RR (SAPI, R, F, M, L, N(R))-------------> <---------I (SAPI, C, P, M, L, N(S), N(R))--------3 4---------RR (SAPI, R, F, M, L, N(R))-------------> Not during speech/data <---------UI (SAPI, C, P, M, L)-------------------5 6---------I (SAPI, C, P, M, L, N(S), N(R))--------> <---------RR (SAPI, R, F, M, L, N(R))-------------7 8---------I (SAPI, C, P, M, L, N(S), N(R))--------> <---------RR (SAPI, R, F, M, L, N(R))-------------7 SETUP ---------> The frames from the BSSTE will be:

2,4: RR frame containing: SAPI = 0, R = 1, F = 0, M = 0, L = 0 N(R) = 1,2 6: I frame containing: SAPI = 0, C = 0, P = 0, M = 1, L = 20 N(S) = 0, N(R) = 2 Information field = SETUP (part 1)

8: I frame containing: SAPI = 0, C = 0, P = 0, M = 0, 0 < L <= 20 N(S) = 1, N(R) = 2 Information field = SETUP (part 2) Conformance Requirements


1: I frame containing: SAPI = 0, C = 1, P = 0, M = 1, L = 20 N(S) = 0 N(R) = 0 information field = SETUP (part 1) 3: I frame containing: SAPI = 0, C = 1, P = 0, M = 0, 0 < L <= 20 N(S) = 1 N(R) = 0 information field = SETUP (part 2) 5: UI frame (fill frame) containing: SAPI = 0, C = 1, P = 0, M = 0, L = 0 7: RR frame containing: SAPI = 0, R = 0, F = 0, M = 0, L = 0, N(R) = 1,2 Requirements Reference

The operation of this is described in GSM 04.06, section5.5.1 and 5.5.2.

5.8.3 Normal Layer 2 release by MS

Test Purpose

To test the normal data link disconnection sequences.

Test Case

Initial Setup

The BSS is brought to the multiple frame established state as in section 5.8.1.1.

Description

The BSSTE shall send a Layer 2 DISC frame to the BSS as defined in section 5.6.1. The BSS should respond with a UA frame and return to the idle state.

The BSSTE confirms that that the BSS has returned to the idle state by performing test 5.8.1.1 successfully.

Message Flow

BSSTE (MS) BSS 1-----------------DISC (SAPI, C, P, M, L)------------------> <-----------------UA (SAPI, R, M, L, F)--------------------2 The frames from the BSSTE will be:

Page 34 GSM 11.23 v.4.4.0: May 1996

1. DISC frame containing: SAPI = 0, C = 0, P = 1, M = 0, L = 0 Conformance Requirements


2. UA frame containing: SAPI = 0, R = 0, F = 1, M = 0, L = 0 Requirements Reference

This operation is described in GSM 04.06, section, 5.4.4.2.

5.8.4 Normal Layer 2 release by BSS

Normal Layer 2 disconnection by the BSS does not apply to signalling connections using SAPI=0. Signalling connections are always disconnected by the Mobile Station or by abnormal release.

5.8.5 Abnormal release

Test Purpose

To test the abnormal data link release procedure.

Test Case

Initial Setup

The BSS is initialised as described in test 5.8.1.1.

Description

The BSSTE shall input a DM frame with F=0.

The BSS should then respond in one of the 2 following ways:

1) Local end release

The BSS should go to the idle state without transmitting any DISC frames. After 4 times T200 the BSSTE will have to verify the idle state by sending a DISC frame.

The BSS may then respond with a DM frame.

NOTE 1: It is assumed that the Layer 3 reaction time in the BSS in order to command abnormal release is shorter than 4 x T200.

NOTE 2: Local end release may in some cases be carried out in the BSS by disconnecting the channels. In such a case there will be no DM frame as a response to the DISC frame input.

2) Normal release

The BSS should respond with a DISC frame. The BSSTE shall then stop the procedure by sending a UA frame.

Message Flow


BSSTE (MS) BSS 1------------------DM (SAPI, R, F, M, L)---------------------> 2------------------DISC (SAPI, C, P, M, L)-------------------> <------------------DM (SAPI, R, F, M, L)---------------------3 2) Normal release

BSSTE (MS) BSS 1------------------DM (SAPI, R, F, M, L)---------------------> <------------------DISC (SAPI, C, P, M, L)-------------------2 3------------------UA (SAPI, R, F, M, L)---------------------> The frames from the BSSTE will be:


1. DM frame containing: SAPI = 0, R = 1, F = 0, M = 0, L = 0 2. DISC frame containing: SAPI = 0, C = 0, P = 1, M = 0, L = 0 2) Normal release

1. DM frame containing: SAPI = 0, R = 1, F = 0, M = 0, L = 0 3. UA frame containing: SAPI = 0, R = 1, F = 1, M = 0, L = 0 Conformance Requirements



3. DM frame containing: SAPI = 0, R = 0, F = 1, M = 0, L = 0 2) Normal release

2. DISC frame containing: SAPI = 0, C = 1, P = 1, M = 0, L = 0 Requirements Reference

The procedure is specified in GSM 04.06 section 5.6.4.

5.8.6 Frame loss

5.8.6.1 I Frame loss (BSS to BSSTE)

This is covered by the test in section 5.8.2.2 on receipt of I frames in the timer recovery state.

5.8.6.2 RR Response frame loss (BSSTE to BSS)

This is covered by the test in section 5.8.2.2 on receipt of I frames in the timer recovery state.

Page 36 GSM 11.23 v.4.4.0: May 1996

5.8.6.3 RR response frame loss (BSS to BSSTE)

Test Purpose

To test the Layer 2 recovery mechanism in the event of RR frame loss.

Test Case

Initial Setup


Description

The BSSTE sends a I frame to the BSS. The BSS should respond with an RR frame.

The BSSTE ignores the RR frame from the BSS, but after T200 from the I frame sent by the BSSTE the BSSTE repeats the I frame but with the P bit set to 1. This simulates loss of the RR from the BSS.

The BSS shall send a REJ frame acknowledging the I frame.

Message Flow

BSSTE (MS) BSS 1-------------I (SAPI, C, P, M, L, N(S), N(R))-----------> - | <-------------RR (SAPI, R, M, L, N(R), F)----------------2 T200 | 3-------------I (SAPI, C, P, M, L, N(S), N(R))-----------> - <-------------REJ (SAPI, R, M, L, N(R), F)---------------4 The frames from the BSSTE will be:

1. I frame containing: SAPI = 0, C = 0, P = 0, M = 0, 0 < L <= N201 N(S) = 0, N(R) = 0 3. I frame containing: SAPI = 0, C = 0, P = 1, M = 0, 0 < L< = N201 N(S) = 0, N(R) = 0 Conformance Requirements


2. RR frame containing: SAPI = 0, R = 0, F = 0, M = 0, L = 0, N(R) = 1 4. REJ frame containing: SAPI = 0, R = 0, F = 1, M = 0, L = 0, N(R) = 1 Requirements Reference

The operation of this is described in GSM 04.06, section 5.7.1.

5.8.7 Reception of REJ frames

5.8.7.1 Data link layer not in the timer recovery state

Test Purpose

To test the REJ frame reception sequence when the data link layer entity is not in a timer recovery state.

Test Case

Initial Setup

The data link is set up between the BSS and the BSSTE as in section 5.8.1.1.

Description

The BSSTE shall input a Layer 3 DTAP message, e.g. IDENTITY REQUEST, on the MSC-interface, that should result in the transmission of an I frame with P=0 from the BSS.

The BSSTE shall input a REJ command frame with P=1. The BSS should then respond with a supervisory RR frame with F=1 and then the I frame with P=0.

The BSSTE shall input a normal supervisory RR frame indicating satisfactory reception of the I frame.

Message Flow

BSSTE BSSTE (MS) BSS (MSC) ID REQ <--------- <-------I (SAPI, C, P, M, L, N(S), N(R))-------- 1 2 ------REJ (SAPI, C, P, M, L, N(R))-------------> <-------RR (SAPI, R, F, M, L, N(R))------------- 3 <-------I (SAPI, C, P, M, L, N(S), N(R))-------- 1 4 ------RR (SAPI, R, F, M, L, N(R))--------------> The frames from the BSSTE will be:

2. REJ frame containing: SAPI = 0, C = 0, P = 1, M = 0, L = 0 N(R) = 0 4. RR frame containing: SAPI = 0, R = 1, F = 0, M = 0, L = 0 N(R) = 1 Conformance Requirements


1. I frame containing: SAPI = 0, C = 1, P = 0, M = 0, 0 < L <= N201, N(S = 0, N(R) = 0, information field = IDENTITY REQUEST 3. RR frame containing: SAPI = 0, R = 0, F = 1, M = 0, L = 0, N(R) = 0

Page 38 GSM 11.23 v.4.4.0: May 1996

Requirements reference

The operation is described in GSM 04.06, section 5.5.4.1, item i).

5.8.7.2 Data link layer in the timer recovery state, reception of a REJ response frame

Test Purpose

To test the REJ response frame reception sequence when the data link layer entity is in a timer recovery state.

Test Case

Initial Setup


Description


The BSSTE shall not respond. After T200, the BSS should repeat the I frame with P=1, and will then enter into the timer recovery state.

The BSSTE shall input a REJ response frame with F=1. The BSS should then exit the timer recovery state and transmit the I frame with P=0.


Message Flow

BSSTE BSSTE (MS) BSS (MSC) ID REQ <-------- <------------I (SAPI, C, P, M, L, N(S), N(R))-------- 1 Timeout of T200 <------------I (SAPI, C, P, M, L, N(S), N(R))-------- 3 4 -----------REJ (SAPI, R, F, M, L, N(R))-------------> <------------I (SAPI, C, P, M, L, N(S), N(R))-------- 1 5 -----------RR (SAPI, R, F, M, L, N(R))--------------> The frames from the BSSTE will be:

4. REJ frame containing: SAPI = 0, R = 1, F = 1, M = 0, L = 0 N(R) = 0 5. RR frame containing: SAPI = 0, R = 1, F = 0, M = 0, L = 0 N(R) = 1 Conformance Requirements


1. I frame containing: SAPI = 0, C = 1, P = 0, M = 0, 0 < L <= N201, N(S) = 0, N(R) = 0, information field = IDENTITY REQUEST 3. I frame containing: SAPI = 0, C = 1, P = 1, M = 0, 0 < L <= N201, N(S) = 0, N(R) = 0, information field = IDENTITY REQUEST Requirements Reference

The operation is described in GSM 04.06, section 5.5.4.1, item ii).

5.8.7.3 Data link layer in the timer recovery state, reception of a REJ command frame

Test Purpose

To test the REJ command frame reception sequence when the data link layer entity is in a timer recovery state.

Test Case

Initial Setup


Description



The BSSTE shall input a REJ command frame with P=1. The BSS should not exit the timer recovery state, but transmit a supervisory RR frame with F=1 and then transmit the I frame with P=1.


Message Flow

BSSTE BSSTE (MS) BSS (MSC) ID REQ <--------- <------------I (SAPI, C, P, M, L, N(S), N(R))-------- 1 Timeout of T200 <------------I (SAPI, C, P, M, L, N(S), N(R))-------- 3 4 -----------REJ (SAPI, C, P, M, L, N(R))-------------> <------------RR (SAPI, R, F, M, L, N(R))------------- 5 <------------I (SAPI, C, P, M, L, N(S), N(R))-------- 6 7 -----------RR (SAPI, R, F, M, L, N(R))--------------> The frames from the BSSTE will be:

4. REJ frame containing: SAPI = 0, C = 0, P = 1, M = 0, L = 0 N(R) = 0

Page 40 GSM 11.23 v.4.4.0: May 1996

7. RR frame containing: SAPI = 0, R = 1, F = 1, M = 0, L = 0 N(R) = 1 Conformance Requirements


1. I frame containing: SAPI = 0, C = 1, P = 0, M = 0, 0 < L <= N201, N(S) = 0, N(R) = 0, information field = IDENTITY REQUEST 3. I frame containing: SAPI = 0, C = 1, P = 1, M = 0, 0 < L <= N201, N(S) = 0, N(R) = 0, information field = IDENTITY REQUEST 5. RR frame containing: SAPI = 0, R = 0, F = 1, M = 0, L = 0, N(R) = 0, 6. I frame containing: SAPI = 0, C = 1, P = 1, M = 0, 0 < L <= N201, N(S) = 0, N(R) = 0, information field = IDENTITY REQUEST Requirements Reference

The operation is described in GSM 04.06, section 5.5.4.1, section iii).

5.8.8 Frame transmission with incorrect C/R values

5.8.8.1 I frame with C bit set to one

Test Purpose

To test that the BSS will take no action when it receives an I frame with the C bit set to one.

Test Case

Initial Setup

The data link is set up between the BSS and the BSSTE as in test 5.8.1.1.

Description

The BSSTE shall send an I frame with C=1 to the BSS and 0 < L <= N201.

The BSSTE shall then wait for at least 4 times T200 to make sure that the BSS does not respond to that I frame, but that the BSS keeps sending UI fill frames if the test is being performed on the SDCCH. On the FACCH the BSS shall respond if used for signalling only, otherwise not.

The BSSTE shall after 4 times T200 send a RR command, P bit set to 1.

The BSS shall respond with an RR response, F bit set to 1.

Message Flow

BSSTE (MS) BSS 1---------------I (SAPI, C, P, M, L, N(S), N(R))-------------> Not during speech/data <---------------UI (SAPI, C, P, M, L)------------------------2 3---------------RR (SAPI, C, M, L, N(R), P)------------------> <---------------RR (SAPI, R, M, L, N(R), F)------------------4 The frames from the BSSTE will be:

1. I frame containing: SAPI = 0, C = 1, P = 1, M = 0, 0 < L <= N201 N(R) = 0, N(S) = 0 3. RR frame containing: SAPI = 0, C = 0, P = 1, M = 0, L = 0, N(R) = 0 Conformance Requirements


2. UI fill frame containing: SAPI = 0, C = 1, P = 0, M = 0, L = 0 4. RR frame containing: SAPI = 0, R = 0, F = 1, M = 0, L = 0, N(R) = 0 Requirements Reference

The operation of this is described in GSM 04.06, section 3.8, table 4.

5.8.8.2 SABM frame with C bit set to one

Test Purpose

To test that the BSS will take no action when it receives an SABM frame with the C bit set to one.

Test Case

Initial Setup


Description

The BSSTE shall send a valid I frame including CONNECT ACKNOWLEDGE in order to raise V(R) in the BSS to 1.

The BSS shall acknowledge this by the appropriate RR frame.

The BSSTE sends SABM with C=1.

The BSS shall send a UI fill frame if the test is being performed on the SDCCH. On the FACCH the BSS shall respond only if during signalling only, otherwise not.

The BSSTE shall after T200 send an RR command, P bit set to 1. The BSS shall respond with an RR response, F bit set to 1.

Page 42 GSM 11.23 v.4.4.0: May 1996

The BSS is returned to the idle state as described in 5.6.1.

Message Flow

BSSTE (MS) BSS 1---------------I (SAPI, C, P, M, L, N(S), N(R))-------------> <---------------RR (SAPI, R, F, M, L, N(R))------------------2 3---------------SABM (SAPI, C, P, M, L)----------------------> - Not during speech/data T200 <---------------UI (SAPI, C, P, M, L)------------------------4 | 5---------------RR (SAPI, C, P, M, L, N(R))------------------> - <---------------RR (SAPI, R, F, M, L, N(R))------------------6 The frames from the BSSTE will be:

1. I frame containing: SAPI = 0, C = 0, P = 0, M = 0, 0 < L <= N201 N(S) = 0, N(R) = 0 information field = CONNECT ACKNOWLEDGE 3. SABM frame containing: SAPI = 0, C = 1, P = 1, M = 0, L = 0 5. RR frame containing: SAPI = 0, C = 0, P = 1, M = 0, L = 0, N(R) = 0 Conformance Requirements


2. RR frame containing: SAPI = 0, R = 0, F = 0, M = 0, L = 0, N(R) = 1 4. UI fill frame containing: SAPI = 0, C = 1, P = 0, M = 0, L = 0 6. RR frame containing: SAPI = 0, R = 0, F = 1, M = 0, L = 0, N(R) = 1 Requirements Reference

The operation of this is described in GSM 04.06, section 3.8, table 4.

5.8.9 Link failure

Test Purpose

To test that the BSS while in the multiple frame established state and after T200 has expired N200 + 1 times in a row will either release or re-establish the link.

Test Case

Initial Setup


Description

Over the MSC interface the BSSTE shall input any DTAP message (length less than 23 octets). The BSS should then transmit an I frame with the P bit set to 0 on the radio interface.

The BSSTE shall not respond.

After T200 the BSS should repeat the I frame, but with the P bit set to 1.

The BSSTE shall not respond

The last two steps shall reoccur N200 times.

The BSS may now proceed in either of 3 ways: local end release, normal release or link re-establishment.

1) Local end release As in section 5.8.5 (local end release). 2) Normal release As in section 5.8.5 (normal release). 3) Link re-establishment After approximately 4 times T200 the BSS shall transmit an SABM frame without contention

resolution. The BSSTE shall answer with a UA frame. Message Flow

BSSTE BSSTE (MS) BSS (MSC) DTAP <--------- <--------I (SAPI, C, P, M, L, N(S), N(R))---------1 Timeout of T200 <--------I (SAPI, C, P, M, L, N(S), N(R))---------1 Timeout of T200 <--------I (SAPI, C, P, M, L, N(S), N(R))---------1 Timeout of T200 . N200+1 . <--------I (SAPI, C, P, M, L, N(S), N(R))---------1 3) Link re-establishment

BSSTE (MS) BSS <---------------SABM(SAPI, C, P, M, L)--------------------2 3----------------UA(SAPI, R, F, M, L)---------------------> The frames from the BSSTE will be:

3) Link re-establishment

3: UA frame containing: SAPI = 0, R = 1, F = 1, M = 0, L = 0 Conformance Requirements


1: I frame containing:

Page 44 GSM 11.23 v.4.4.0: May 1996

SAPI = 0, C = 1, P = 1(except for the first I frame where P=0), M = 0, 0 < L <= N201 N(S) = 0, N(R) = 0 Information field = DTAP message 3) Link re-establishment

2: SABM frame containing: SAPI = 0, C = 1, P = 1, M = 0, L = 0 Requirements Reference


NOTE: The choice between releasing or re-establishing the link is left to the manufacturer by GSM 04.06.

5.8.10 Errors in the Control Field

5.8.10.1 N(S) sequence error

Test Purpose

To test that the BSS will ignore the contents of the I field of an out-of-sequence I frame from the BSSTE, and also to test that the BSS will make use of and react to the N(R) and/or P/F bit contained in an I frame causing an N(S) sequence error.

Test Case

Initial Setup


Description

The BSSTE shall send a correct I frame containing CONNECT ACKNOWLEDGE on the radio interface and input an AUTHENTICATION REJECT message on the MSC-interface.

The BSS shall acknowledge the I frame in an RR frame or piggy back the acknowledgement into the I frame carrying AUTHENTICATION REJECT.

The BSSTE shall first send an RR frame acknowledging the I frame received from the BSS (in order to avoid the problem of timer recovery conditions) and then send an I frame containing CONNECT ACKNOWLEDGE with incorrect N(S), but correctly acknowledging the BSSs I frame (P bit set to zero). The BSS shall not output a CONNECT ACKNOWLEDGE message on the MSC-interface.

The BSS should, however, respond either with a REJ command frame, P=0, or P = 1 or ignore the out of sequence frame. If a REJ frame with P = 1 is sent, the BSSTE shall respond with an RR frame with F = 1.

The BSSTE shall, after T200, retransmit its last I frame (with the incorrect N(S) sequence number), but with the P bit set to 1 this time. The BSS shall respond with a REJ response frame, F=1 or an RR frame with the F bit set to 1.

The BSSTE shall now transmit an I frame with correct N(S) sequence number. The BSS should acknowledge this by an RR frame.

Message Flow

BSSTE BSSTE (MS) BSS (MSC) AUTH REJ <--------- 1---------I (SAPI, C, P, M, L, N(S), N(R))----------> <---------RR (SAPI, R, F, M, L, N(R))---------------2 May be one frame <---------I (SAPI, C, P, M, L, N(S), N(R))----------3 1bis------RR (SAPI, R, F, M, L, N(R))---------------> 4---------I (SAPI, C, P, M, L, N(S), N(R))----------> The following frame is optional: <---------REJ (SAPI, C, P, M, L, N(R))--------------5 4bis------RR (SAPI, R, F, M, L, N(R))---------------> (see Note) 6---------I (SAPI, C, P, M, L, N(S), N(R))----------> The following frame is optional: <---------REJ (SAPI, R, F, M, L, N(R))--------------7 8---------I (SAPI, C, P, M, L, N(S), N(R))----------> <---------RR (SAPI, R, F, M, L, N(R))---------------9

NOTE: This frame is only used by the BSSTE to acknowledge the REJ frame with P bit set to 1. In the other cases this frame is not used.


1. I frame containing: SAPI = 0, C = 0, P = 0, M = 0, 0 < L <= N201 N(S) = 0, N(R) = 0 information field = CONNECT ACKNOWLEDGE 1bis. RR frame containing SAPI = 0, R = 1, F = 0, M = 0, L = 0, N(R) = 1. 4. I frame containing: SAPI = 0, C = 0, P = 0, M = 0, 0 < L <= N201 N(S) = 2, N(R) = 1 information field = CONNECT ACKNOWLEDGE 4bis. RR frame containing SAPI = 0, R = 1, F = 1, M = 0, L = 0, N(R) = 1. 6. I frame containing: SAPI = 0, C=0, P = 1, M = 0, 0 < L <= N201 N(S) = 2, N(R) = 1 information field = CONNECT ACKNOWLEDGE 8. I frame containing: SAPI = 0, C = 0, P = 0, M = 0, 0 < L <= N201 N(S) = 1, N(R) = 1 information field = CONNECT ACKNOWLEDGE Conformance Requirements


2. RR frame containing: SAPI = 0, R = 0, F = 0, M = 0, L = 0, N(R) = 1

Page 46 GSM 11.23 v.4.4.0: May 1996

3. I frame containing: SAPI = 0, C = 1, P = 0, M = 0, 0 < L <= N201 N(R) = 1, N(S) = 0 information field = AUTHENTICATION REJECT 5. REJ frame containing (optional): SAPI = 0, C = 1, P = 0 or P = 1, M = 0, L = 0, N(R) = 1 7. REJ or RR frame containing: SAPI = 0, R = 0, F = 1, M = 0, L = 0, N(R) = 1 9. RR frame containing: SAPI = 0, R = 0, F = 0, M = 0, L = 0, N(R) = 2 Requirements Reference

The operation of this is described in GSM 04.06 section 5.7.1 and 5.7.2. Three answers are possible, therefore this tests allows the BSS to use any of them.

5.8.10.2 N(R) sequence error

Test Purpose

To test that the BSS will detect a N(R) sequence error and react in the proper way to it, in particular, that the BSS will react to a P bit set to 1 before performing abnormal link release and that the information field contained in an I frame causing the N(R) sequence error is passed on to higher layers if N(S) was correct.

Test Case

Initial Setup


Description

The BSSTE shall input an AUTHENTICATION REJECT message on the MSC-interface of the BSS. The BSS should then transmit an I frame on the radio interface.

The BSSTE shall send an I frame containing CONNECT ACKNOWLEDGE, a correct send sequence number N(S) and a faulty receive sequence number N(R).

Depending on the processing speed and on the implementation of LAPDm in the BSS the BSS may send a UI fill frame if the test is being performed on the SDCCH. On the FACCH, a UI fill frame may also be sent if the TCH/FACCH is configured for signalling only, otherwise not. Then the BSS shall perform abnormal release (see section 5.8.5) and the CONNECT ACKNOWLEDGE message may be output on the MSC-interface.

NOTE: It is assumed that the Layer 3 reaction time within the BSS to command abnormal release is less than 4 times T200.

Message Flow

BSSTE BSSTE (MS) BSS (MSC) AUTH REJ <---------- <--------I (SAPI, C, P, M, L, N (R), N (S))--------1 2--------I (SAPI, C, P, M, L, N (R), N (S))--------> Not during speech/data <--------UI (SAPI, C, P, M, L)---------------------3 . CONN ACK . ----------> Abnormal release The frames from the BSSTE are:

2. I frame: SAPI = 0, C = 0, P = 0, M = 0, 0 < L < N 201 (L = 2) N (R) = 5, N (S) = 0 information field = CONNECT ACKNOWLEDGE Conformance Requirements


1. I frame: SAPI = 0, C = 1, P = 0, M = 0, 0 <= L <= N 201 (L = 2) N (S) = 0, N (R) = 0 information field = AUTHENTICATION REJECT 3. UI frame (fill frame): SAPI = 0, C = 1, P = 0, M = 0, L = 0 Requirements Reference

The operation of this is outlined in GSM 04.06 section 5.7.4.

5.8.10.3 Improper F bit

Test Purpose

To test that the BSS, being in the timer recovery state, will return to the multiple frame established state only after having received an RR response with the F bit set to 1.

Test Case

Initial Setup


Description

The BSSTE shall input an AUTHENTICATION REJECT message to the BSS on the MSC interface. The BSS should respond with an I frame on the radio interface.

The BSSTE shall not respond, timer T200 shall expire in the BSS and the BSS shall repeat its I frame, with the P bit set to 1 this time.

Page 48 GSM 11.23 v.4.4.0: May 1996

The BSSTE shall respond with a RR response, acknowledging the I frame from the BSS but with the F bit set to 0. Timer T200 should expire again in the BSS and the BSS should repeat its I frame, with the P bit set to 1 again.

The BSSTE shall now input a RR response frame with the F bit set to 1, acknowledging the I frame again. The BSS should accept the acknowledge. It should start transmitting fill frames (on the SDCCH or FACCH during signalling only) or send no further frames (on the TCH/FACCH during speech/data and signalling).

Message Flow

BSSTE BSSTE (MS) BSS (MSC) AUTH REJ <------I (SAPI, C, P, M, L, N(S), N(R))-------1 - <-------- | T200 | <------I (SAPI, C, P, M, L, N(S), N(R))-------2 - | 3--------RR (SAPI, R, F, M, L, N(R))----------> T200 | <------I (SAPI, C, P, M, L, N(S), N(R))-------2 - 4--------RR (SAPI, R, F, M, L, N(R))----------> Not during speech/data <----------UI (SAPI, C, P, M, L)--------------5 The frames from the BSSTE will be:

3: RR frame containing: SAPI = 0, R = 1, F = 0, M = 0, L = 0 N(R) = 1 4: RR frame containing: SAPI = 0, R = 1, F = 1, M = 0, L = 0 N(R) = 1 Conformance Requirements


1: I frame containing: SAPI = 0, C = 1, P = 0, M = 0, 0 < L <= N201 N(S) = 0 N(R) = 0 information field = AUTHENTICATION REJECT 2: I frame containing: SAPI = 0, C = 1, P = 1, M = 0, 0 < L <= N201 N(S) = 0 N(R) = 0 information field = AUTHENTICATION REJECT 5: UI frame (fill frame) containing: SAPI = 0, C = 1, P = 0, M = 0, L = 0 Requirements Reference

This test is described in GSM 04.06 section 5.5.7.

5.8.11 Receipt of invalid frames

Test Purpose

To test that the BSS will ignore all invalid frames.

Test Case

Initial Setup


Description

The BSSTE shall then transmit:

- SABM frame with the EL bit set to zero; - DM frame with the Length Indicator greater than zero; - DISC frame with the M bit set to 1; - UA frame with the EA bit set to zero; - I frame with the Length Indicator greater than N201; - I frame with the M bit set to 1 and the Length Indicator less than N201; - Command frames with correct Address and Length Indicator field and a non-implemented control

field. To all those frames the BSS shall respond by sending a UI fill frame, if the test is being performed on the SDCCH. On the FACCH, a UI fill frame may be sent if the TCH/FACCH is configured for signalling only, otherwise not.

After T200 the BSSTE shall in every case transmit an RR command, P bit set to 1.

The BSS shall respond with RR response, F bit set to 1.

NOTE: GSM 04.06 only specifies that any contents of invalid frames (control parameters or information fields) are to be discarded and that an error indication to Layer 3 has to be given. The actions thereafter by Layer 3 are not specified. One conceivable reaction of Layer 3 to the reception of an invalid frame could be an abnormal release of the data link. In such a case the tests outlined in this section could not be performed in a row. Instead, the link would have to be established again and again from scratch (starting with the CHANNEL REQUEST message from the BSSTE on the RACH).

Page 50 GSM 11.23 v.4.4.0: May 1996

Message Flow

BSSTE (MS) BSS 5 -------------SABM (SAPI, C, P, M, L)----------------------> Not during speech/data <--------------UI (SAPI, C, P, M, L)----------------------- 2 11 ------------RR (SAPI, C, P, M, L, N (R))-----------------> <--------------RR (SAPI, R, F, M, L, N (R))----------------12 6 -------------DM (SAPI, R, P, M, L)------------------------> Not during speech/data <--------------UI (SAPI, C, P, M, L)----------------------- 2 11 ------------RR (SAPI, C, P, M, L, N (R))-----------------> <--------------RR (SAPI, R, F, M, L, N (R))----------------12 7 -------------DISC (SAPI, C, P, M, L)----------------------> Not during speech/data <--------------UI (SAPI, C, P, M, L)----------------------- 2 11 ------------RR (SAPI, C, P, M, L, N (R))-----------------> <--------------RR (SAPI, R, F, M, L, N (R))----------------12 8 -------------UA (SAPI, R, F, M, L)------------------------> Not during speech/data <--------------UI (SAPI, C, P, M, L)----------------------- 2 11 ------------RR (SAPI, C, P, M, L, N (R))-----------------> <--------------RR (SAPI, R, F, M, L, N (R))----------------12 9 -------------I (SAPI, C, P, M, L, N (R), N (S))-----------> Not during speech/data <--------------UI (SAPI, C, P, M, L)----------------------- 2 11 ------------RR (SAPI, C, P, M, L, N (R))-----------------> <--------------RR (SAPI, R, F, M, L, N (R))----------------12 10 ------------I (SAPI, C, P, M, L, N (R), N (S))-----------> Not during speech/data <--------------UI (SAPI, C, P, M, L)----------------------- 2 11 ------------RR (SAPI, C, P, M, L, N (R))-----------------> <---------------RR (SAPI, R, F, M, L, N (R))----------------12 13 ---------------------------------------------------------> Not during speech/data <--------------UI (SAPI, C, P, M, L)------------------------2 11 ------------RR (SAPI, C, P, M, L, N (R))-----------------> <--------------RR (SAPI, R, F, M, L, N (R))----------------12

14 ---------------------------------------------------------> Not during speech/data <--------------UI(SAPI, C, P, M, L)------------------------ 2 11 ------------RR (SAPI, C, P, M, L, N (R))-----------------> <--------------RR (SAPI, R, F, M, L, N (R))----------------12 15 ---------------------------------------------------------> Not during speech/data <--------------UI(SAPI, C, P, M, L)------------------------ 2 11 ------------RR (SAPI, C, P, M, L, N (R))-----------------> <--------------RR (SAPI, R, F, M, L, N (R))----------------12 16 ---------------------------------------------------------> Not during speech/data <--------------UI(SAPI, C, P, M, L)------------------------ 2 11 ------------RR (SAPI, C, P, M, L, N (R))-----------------> <--------------RR (SAPI, R, F, M, L, N (R))----------------12 17 ---------------------------------------------------------> Not during speech/data <--------------UI(SAPI, C, P, M, L)------------------------ 2 11 ------------RR (SAPI, C, P, M, L, N (R))-----------------> <--------------RR (SAPI, R, F, M, L, N (R))----------------12 18 ---------------------------------------------------------> Not during speech/data <--------------UI(SAPI, C, P, M, L)------------------------ 2 11 ------------RR (SAPI, C, P, M, L, N (R))-----------------> <--------------RR (SAPI, R, F, M, L, N (R))----------------12 19 ---------------------------------------------------------> Not during speech/data <--------------UI(SAPI, C, P, M, L)------------------------ 2 11 ------------RR (SAPI, C, P, M, L, N (R))-----------------> <--------------RR (SAPI, R, F, M, L, N (R))----------------12 The frames from the BSSTE are:

5 SABM frame: SAPI = 0, C = 0, P = 1, M = 0, L = 0, EL = 0 6 DM frame: SAPI = 0, R = 1, F = 1, M = 0, L > 0 7 DISC frame: SAPI = 0, C = 0, P = 1, M = 1, L = 0,

Page 52 GSM 11.23 v.4.4.0: May 1996

8 UA frame: SAPI = 0, R = 1, F = 0, M = 0, L = 0, EA = 0 9 I frame: SAPI = 0, C = 0, P = 0, M = 0, L > N201, N(R) = 0, N(S) = 0 10 I frame: SAPI = 0, C = 0, P = 0, M = 1, L < N201, N(R) = 0, N(S) = 0 11 RR frame: SAPI = 0, C = 0, P = 1, M = 0, L = 0, N(R) = 0 13 A command frame with Control Field = XXX1 1101 14 A command frame with Control field = XXX1 1011 15 A command frame with Control field = XXX1 0111 16 A command frame with Control field = 01X1 1111 17 A command frame with Control field = 1XX1 1111 18 A command frame with Control field = 0011 0011 19. A command frame with Control field = 1XX1 0011

NOTE: An "X" stands for an arbitrary bit value.

Conformance Requirements


2. UI fill frame: SAPI = 0, C = 1, P = 0, M = 0, L = 0 12. RR frame: SAPI = 0, R = 0, F = 1, M = 0, L = 0, N (R) = 0 Requirements Reference

The definition of invalidity and the operation of this test is described in GSM 04.06 section 5.7.3.

5.9 Short Message Services (SMS) (SAPI=3)

The Short Message Services support (SMS) as defined in GSM 04.11 is characterised on Layer 2 by:

- SAPI=3 - SMS exists on the SACCH if a TCH is allocated. If no TCH is allocated, SMS exists on the SDCCH.

Consequently, all tests described below shall be carried out once on an SACCH (of a TCH) and once on an SDCCH.

- The LAPDm signalling link may be established by MS or by BSS. - Contention resolution is not required. - A data link for SAPI=3 can only be established and maintained while a data link for SAPI=0 is

existing. Consequently, it will be assumed throughout this section that a data link for SAPI=0 exists.

- Timer T200 for SAPI=3 is not necessarily the same as for SAPI=0 and depends on the logical channel used.

5.9.1 MS-originated link establishment

The tests shall be performed as in section 5.5.1, with the following modifications:

- SAPI=3 - The link shall in each case be established on the SACCH and on the SDCCH in turn as in section

5.5.1. 5.9.2 BSS-originated link establishment

5.9.2.1 Normal initialisation (no contention resolution)

Test Purpose

To test the normal initialisation of multiple-frame operation when contention resolution is not required. This procedure is used after a data link has been established with contention resolution and an additional data link is established for a Short Message Service (SMS) using SAPI=3.

Test Case

Initial Setup

The data link shall be established on a SACCH according to section 5.5.2.1

Description

An SABM frame without contention resolution will be sent from the BSS.

The BSSTE responds with a UA frame.

The test shall be repeated on an SDCCH.

Message Flow

BSSTE (MS) BSS <-----------------SABM (SAPI, C, P, M, L)------------------1 2-----------------UA (SAPI, R, F, M, L)--------------------> The frames from the BSSTE will be:

2. UA frame containing: SAPI = 3, R = 1, F = 1, M = 0, L = 0 Conformance Requirements


1. SABM frame containing: SAPI = 3, C = 1, P = 1, M = 0, L = 0 Requirements Reference


Page 54 GSM 11.23 v.4.4.0: May 1996

5.9.2.2 Initialisation failure (no contention resolution)

Test Purpose:

To test the BSS response to the loss of a Layer 2 UA frame during initialisation. Also the fact that numbered frames and wrong DM and UA frames (F=0) are ignored is tested.

Test Case

Initial Setup

The data link shall be established on a SACCH according to section 5.5.2 ending with an SABM frame without contention resolution from the BSS.

Description

The BSSTE shall ignore the first SABM frame from the BSS. The BSS should wait for timeout of timer T200 and then send a second SABM frame.

The BSSTE shall before T200 expires send an I frame.

The BSS should ignore the I frame and repeat the SABM frame after T200.

The BSSTE shall before T200 expires send a UA frame with F=0. The BSS should ignore the UA frame and repeat the SABM frame after T200.

The BSSTE shall before T200 expires send a DM frame with F=0.

The BSS should ignore the DM frame and repeat the SABM frame after T200. The BSSTE shall respond with a UA frame with F=1 to finish the procedure.



Message Flow

BSSTE (MS) BSS <---------------SABM (SAPI, C, P, M, L)------------------1 Timeout of T200 <---------------SABM (SAPI, C, P, M, L)------------------1 - | 2---------------I (SAPI, C, P, M, L, N(R), N(S))---------> T200 | <---------------SABM (SAPI, C, P, M, L)------------------1 - | 3---------------UA (SAPI, R, F, M, L)--------------------> T200 | <---------------SABM (SAPI, C, P, M, L)------------------1 - | 4---------------DM (SAPI, R, F, M, L)--------------------> T200 | <---------------SABM (SAPI, C, P, M, L)------------------1 - 5---------------UA (SAPI, R, F, M, L)--------------------> The frames from the BSSTE will be:

2. I frame containing: SAPI = 3, C = 0, P = 1, M = 0, 0 < L <= N201 N(S)=0, N(R)=0 3. UA frame containing: SAPI = 3, R = 1, F = 0, M = 0, L = 0 4. DM frame containing: SAPI = 3, R = 1, F = 0, M = 0, L = 0 5. UA frame containing: SAPI = 3, R = 1, F = 1, M = 0, L = 0 Conformance Requirements



The operation of this is defined in GSM 04.06, section 5.4.1.3.

5.9.2.3 Initialisation denial (no contention resolution)

Test Purpose

To test that the BSS takes appropriate action if the data link can not be initialised.

Test case

Initial Setup


Description

The BSSTE responds with a DM frame.

The BSSTE then waits at least T200.

The BSS shall not repeat the SABM frame.


Message Flow

BSSTE (MS) BSS <-----------------SABM (SAPI, C, P, M, L)------------------1 2-----------------DM (SAPI, R, F, M, L)--------------------> The frames from the BSSTE will be:

2. DM frame containing:

Page 56 GSM 11.23 v.4.4.0: May 1996

SAPI = 3, R = 1, F = 1, M = 0, L = 0 Conformance Requirements


1. SABM frame containing: SAPI = 3, C = 1, P = 1, M = 0, L = 0 Requirements reference


5.9.2.4 Total initialisation failure (no contention resolution)

Test Purpose

To test the BSS response to the lack of the system to respond to requests to initialise the data link.

Test Case

Initial Setup


Description

The BSSTE ignores the first SABM frame from the BSS.

The BSS shall wait for timeout of timer T200 and then send a second SABM frame.

This is repeated until the BSS has sent the SABM frame N200+1 times. The BSS shall not send the SABM more than N200+1 times.


Message Flow

BSSTE (MS) BSS <-----------------SABM (SAPI, C, P, M, L)--------------------1 Timeout of T200 <-----------------SABM (SAPI, C, P, M, L)--------------------1 Timeout of T200 <-----------------SABM (SAPI, C, P, M, L)--------------------1 Timeout of T200 <-----------------SABM (SAPI, C, P, M, L)--------------------1 . . . Timeout of T200 <-----------------SABM (SAPI, C, P, M, L)--------------------1 Timeout of T200 <-----------------SABM (SAPI, C, P, M, L)--------------------1 (N200+1 SABM frames)





5.9.3 Normal information transfer



5.5.2. - A relevant short message shall be used instead of the DTAP messages with SAPI=0 for the test of

signalling connections (either a message which is short enough to avoid segmentation or long enough to need it).

5.9.4 Normal layer 2 release by MS.

Test Purpose

To test the normal data link disconnection sequences.

Test Case

Initial Setup

The link shall be established on the SACCH and on the SDCCH in turn as in section 5.5.2.1

Description

The BSSTE shall send a Layer 2 DISC frame to the BSS as defined in section 5.6.1. The BSS should respond with a UA frame and return to the idle state.

The BSSTE confirms that that the BSS has returned to the idle state by performing the procedures documented in section 5.5.1 successfully.

Message Flow

BSSTE (MS) BSS 1-----------------DISC (SAPI, C, P, M, L)------------------> <-----------------UA (SAPI, R, M, L, F)--------------------2 The frames from the BSSTE will be:

1. DISC frame containing: SAPI = 3, C = 0, P = 1, M = 0, L = 0 Conformance Requirements


Page 58 GSM 11.23 v.4.4.0: May 1996

2. UA frame containing: SAPI = 3, R = 0, F = 1, M = 0, L = 0 Requirements Reference

The operation is described in GSM 04.06, section 5.4.4.2

5.9.5 Normal Layer 2 release by BSS

The tests shall be performed as in section 5.8.5 (abnormal release), with the following modifications:


5.5.2. - The disconnection shall be triggered by a SAPI "n" CLEAR COMMAND message indicating SAPI=3

on the MSC-interface of the BSS rather than the erroneous DM frame. 5.9.6 Abnormal release

Test Purpose

To test the abnormal data link release procedure.

Test Case

Initial Setup

The link shall be established on the SACCH and on the SDCCH in turn as is described in section 5.5.2.1

Description

The BSSTE shall input a DM frame with F=0.

The BSS should then respond in one of the 2 following ways:

1) Local end release The BSS should go to the idle state without transmitting any DISC frames. After 4 times T200 the

BSSTE will have to verify the idle state by sending a DISC frame. The BSS may then respond with a DM frame.

NOTE 1: It is assumed that the Layer 3 reaction time in the BSS in order to command abnormal release is shorter than 4 x T200.

NOTE 2: Local end release may in some cases be carried out in the BSS by disconnecting the channels. In such a case there will be no DM frame as a response to the DISC frame input.

2) Normal release The BSS should respond with a DISC frame. The BSSTE shall then stop the procedure by sending

a UA frame. Message Flow


BSSTE (MS) BSS 1------------------DM (SAPI, R, F, M, L)---------------------> 2------------------DISC (SAPI, C, P, M, L)-------------------> <------------------DM (SAPI, R, F, M, L)---------------------3 2) Normal release BSSTE (MS) BSS 1------------------DM (SAPI, R, F, M, L)---------------------> <------------------DISC (SAPI, C, P, M, L)-------------------2 3------------------UA (SAPI, R, F, M, L)---------------------> The frames from the BSSTE will be:

1) Local end release 1. DM frame containing: SAPI = 3, R = 1, F = 0, M = 0, L = 0 2. DISC frame containing: SAPI = 3, C = 0, P = 1, M = 0, L = 0 2) Normal release 1. DM frame containing: SAPI = 3, R = 1, F = 0, M = 0, L = 0 3. UA frame containing: SAPI = 3, R = 1, F = 1, M = 0, L = 0 Conformance Requirements


1) Local end release 3. DM frame containing: SAPI = 3, R = 0, F = 1, M = 0, L = 0 2) Normal release 2. DISC frame containing: SAPI = 3, C = 1, P = 1, M = 0, L = 0 Requirements Reference


5.9.7 Frame loss



5.5.2.

Page 60 GSM 11.23 v.4.4.0: May 1996

5.9.8 Reception of REJ frames

5.9.8.1 Data link layer not in the timer recovery state

Test Purpose

To test the REJ frame reception sequence when the data link layer entity is not in a timer recovery state.

Test Case

Initial Setup


Description

The BSSTE shall input a SMS message on the MSC-interface, that should result in the transmission of an I frame with P=0 from the BSS.

The BSSTE shall input a REJ command frame with P=1. The BSS should then respond with a supervisory RR frame with F=1 and then the I frame with P=0.


Message Flow

BSSTE BSSTE (MS) BSS (MSC) SMS message <-------- <------------I (SAPI, C, P, M, L, N(S), N(R))-------- 1 2 -----------REJ (SAPI, C, P, M, L, N(R))-------------> <------------RR (SAPI, R, F, M, L, N(R))------------- 3 <------------I (SAPI, C, P, M, L, N(S), N(R))-------- 1 4 -----------RR (SAPI, R, F, M, L, N(R))--------------> The frames from the BSSTE will be:



1. I frame containing: SAPI =3, C = 1, P = 0, M = 0, 0 < L <= N201,

N(S) = 0, N(R) = 0, information field = SMS message information 3. RR frame containing: SAPI = 3, R = 0, F = 1, M = 0, L = 0, N(R) = 0 Requirements reference

The operation is described in GSM 04.06, section 5.5.4.1. item i)

5.9.8.2 Data link layer in the timer recovery state, reception of a REJ response frame

Test Purpose

To test the REJ response frame reception sequence when the data link layer entity is in a timer recovery state.

Test Case

Initial Setup

The data link is set up between the BSS and the BSSTE as in section 5.5.2.1

Description



The BSSTE shall input a REJ response frame with F=1. The BSS should then exit the timer recovery state and transmit the I frame with P=0.


Message Flow

BSSTE BSSTE (MS) BSS (MSC) SMS message <-------- <------------I (SAPI, C, P, M, L, N(S), N(R))-------- 1 Timeout of T200 <------------I (SAPI, C, P, M, L, N(S), N(R))-------- 3 4 -----------REJ (SAPI, R, F, M, L, N(R))-------------> <------------I (SAPI, C, P, M, L, N(S), N(R))-------- 1 5 -----------RR (SAPI, R, F, M, L, N(R))--------------> The frames from the BSSTE will be:

4. REJ frame containing: SAPI = 3, R = 1, F = 1, M = 0, L = 0

Page 62 GSM 11.23 v.4.4.0: May 1996

N(R) = 0 5. RR frame containing: SAPI = 3, R = 1, F = 0, M = 0, L = 0 N(R) = 1 Conformance Requirements


1. I frame containing: SAPI = 3, C = 1, P = 0, M = 0, 0 < L <= N201, N(S) = 0, N(R) = 0, information field = SMS message contents 3. I frame containing: SAPI = 3, C = 1, P = 1, M = 0, 0 < L <= N201, N(S) = 0, N(R) = 0, information field = SMS message contents Requirements reference

The operation is described in GSM 04.06, section 5.5.4.1, item ii).

5.9.8.3 Data link layer in the timer recovery state, reception of a REJ command frame

Test Purpose

To test the REJ command frame reception sequence when the data link layer entity is in a timer recovery state. .

Test Case

Initial Setup


Description



The BSSTE shall input a REJ command frame with P=1. The BSS should not exit the timer recovery state, but transmit a supervisory RR frame with F=1 and then transmit the I frame with P=1.


Message Flow

BSSTE BSSTE (MS) BSS (MSC) SMS message <-------- <------------I (SAPI, C, P, M, L, N(S), N(R))-------- 1 Timeout of T200 <------------I (SAPI, C, P, M, L, N(S), N(R))-------- 3 4 -----------REJ (SAPI, C, P, M, L, N(R))-------------> <------------RR (SAPI, R, F, M, L, N(R))------------- 5 <------------I (SAPI, C, P, M, L, N(S), N(R))-------- 3 7 -----------RR (SAPI, R, F, M, L, N(R))--------------> The frames from the BSSTE will be:



1. I frame containing: SAPI = 3, C = 1, P = 0, M = 0, 0 < L <= N201, N(S) = 0, N(R) = 0, information field = SMS message contents 3. I frame containing: SAPI = 3, C = 1, P = 1, M = 0, 0 < L <= N201, N(S) = 0, N(R) = 0, information field = SMS message contents 5. RR frame containing: SAPI = 3, R = 0, F = 1, M = 0, L = 0, N(R) = 0, Requirements reference

The operation is described in GSM 04.06, section 5.5.4.1, iem iii).

5.9.9 Frame transmission with incorrect C/R values

5.9.9.1 I frame with C bit set to one

Test Purpose

To test that the BSS will take no action when it receives an I frame with the C bit set to one.

Page 64 GSM 11.23 v.4.4.0: May 1996

Test Case

Initial Setup


Description

The BSSTE shall send an I frame with C=1 to the BSS.

The BSSTE shall then wait for at least 4 times T200 to make sure that the BSS does not respond to that I frame, but that the BSS keeps sending UI fill frames.

The BSSTE shall after 4 times T200 send a RR command, P bit set to 1.

The BSS shall respond with an RR response, F bit set to 1.

Message Flow

BSSTE (MS) BSS 1---------------I (SAPI, C, P, M, L, N(S), N(R))-------------> <---------------UI (SAPI, C, P, M, L)------------------------2 3---------------RR (SAPI, C, M, L, N(R), P)------------------> <---------------RR (SAPI, R, M, L, N(R), F)------------------4 The frames from the BSSTE will be:

1. I frame containing: SAPI = 3, C = 1, P = 1, M = 0, 0 < L <= N201 N(R) = 0, N(S) = 0 3. RR frame containing: SAPI = 3, C = 0, P = 1, M = 0, L = 0, N(R) = 0 Conformance Requirements


2. UI fill frame containing: SAPI = 3, C = 1, P = 0, M = 0, L = 0 4. RR frame containing: SAPI = 3, R = 0, F = 1, M = 0, L = 0, N(R) = 0 Requirements Reference

The operation is described in GSM 04.06, section 3.8 table 4.

5.9.9.2 SABM frame with C bit set to one

Test Purpose

To test that the BSS will take no action when it receives an SABM frame with the C bit set to one.

Test Case

Initial Setup

The link shall be established according to section 5.5.1.

Description

The BSSTE shall send a valid I frame in order to raise V(R) in the BSS to 1.

The BSS shall acknowledge this by the appropriate RR frame.

The BSSTE sends SABM with C=1.

The BSS shall send a UI fill frame.

The BSSTE shall after T200 send an RR command, P bit set to 1. The BSS shall respond with an RR response, F bit set to 1.


Message Flow

BSSTE (MS) BSS 1---------------I (SAPI, C, P, M, L, N(S), N(R))-------------> <---------------RR (SAPI, R, F, M, L, N(R))------------------2 3---------------SABM (SAPI, C, P, M, L)----------------------> - T200 <---------------UI (SAPI, C, P, M, L)------------------------4 | | 5---------------RR (SAPI, C, P, M, L, N(R))------------------> - <---------------RR (SAPI, R, F, M, L, N(R))------------------6 The frames from the BSSTE will be:

1. I frame containing: SAPI = 3, C = 0, P = 0, M = 0, 0 < L <= N201 N(S) = 0, N(R) = 0 3. SABM frame containing: SAPI = 3, C = 1, P = 1, M = 0, L = 0 5. RR frame containing: SAPI = 3, C = 0, P = 1, M = 0, L = 0, N(R) = 0 Conformance Requirements


2. RR frame containing: SAPI = 3, R = 0, F = 0, M = 0, L = 0, N(R) = 1 4. UI fill frame containing: SAPI = 3, C = 1, P = 0, M = 0, L = 0

Page 66 GSM 11.23 v.4.4.0: May 1996

6. RR frame containing: SAPI = 3, R = 0, F = 1, M = 0, L = 0, N(R) = 1 Requirements Reference

The operation of this is described in GSM 04.06, section 3.8 table 4.

5.9.10 Link failure

Test Purpose

To test that the BSS while in the multiple frame established state and after T200 has expired N200+1 times in a row will either release or re-establish the link. The procedure is specified in GSM 04.06 section 5.5.7.

NOTE: The choice between releasing or re-establishing the link is left to the manufacturer by GSM 04.06.

Test Case

Initial Setup

The BSS is brought into the multiple frame established state as described in test 5.5.2.1.

Description

Over the MSC interface the BSSTE shall input a SMS message ). The BSS should then transmit an I frame with the P bit set to 0 on the radio interface.


After T200 the BSS should repeat the I frame, but with the P bit set to 1.

The BSSTE shall not respond

The last two steps shall reoccur N200 times.

The BSS may now proceed in either of 3 ways: local end release, normal release or link re-establishment.

1) Local end release As in section 5.9.6 (local end release). 2) Normal release As in section 5.9.6 (normal release). 3) Link re-establishment After approximately 4 times T200 the BSS shall transmit an SABM frame without contention

resolution. The BSSTE shall answer with a UA frame.

Message Flow

BSSTE BSSTE (MS) BSS (MSC) SMS message <--------- <--------I (SAPI, C, P, M, L, N(S), N(R))---------1 Timeout of T200 <--------I (SAPI, C, P, M, L, N(S), N(R))---------1 Timeout of T200 <--------I (SAPI, C, P, M, L, N(S), N(R))---------1 Timeout of T200 . N200+1 . <--------I (SAPI, C, P, M, L, N(S), N(R))---------1 3) Link re-establishment

BSSTE (MS) BSS <---------------SABM(SAPI, C, P, M, L)--------------------2 3----------------UA(SAPI, R, F, M, L)---------------------> The frames from the BSSTE will be:

3) Link re-establishment

3: UA frame containing: SAPI = 3, R = 1, F = 1, M = 0, L = 0 Conformance Requirements


1: I frame containing: SAPI = 3, C = 1, P = 1 (except for the first I frame where P = 0), M = 0, 0 < L <= N201 N(S) = 0, N(R) = 0 Information field = SMS Message contents 3) Link re-establishment

2: SABM frame containing: SAPI = 3, C = 1, P = 1, M = 0, L = 0 Requirements Reference

The operation of this is described in GSM 04.06, section 5.5.7

5.9.11 Errors in the Control Field



5.5.2.

Page 68 GSM 11.23 v.4.4.0: May 1996

5.9.12 Receipt of invalid frames



5.5.2. 5.10 Layer 3 functions

The functions of the Layer 3 are partitioned into the following 3 sublayer entities according to GSM 04.07 and GSM 04.08:

1. Connection Management (CM) This entity is further split into the 3 following independent Layer 3 sub-entities:

a) Call Control (CC) The CC entity contains elementary procedures which are necessary for establishment and

clearing of mobile originated or mobile terminated circuit switched calls. For details see GSM 04.08.

b) Supplementary Services support (SS) The SS entity contains elementary procedures for support of supplementary services. The

procedures concern administration of calls, like call forwarding and charging. For details see GSM 04.10.

c) Short Message Services support (SMS) The SMS entity contains elementary procedures to relay a short message between the MS

and MSC over the radio path. For details see GSM 04.11.

2. Mobility Management (MM) The MM entity contains procedures which support the mobility of user terminals. The purpose of

these functions is to inform the network when a Mobile Station is activated and deactivated or changing location area, and also to take care of the security aspects that are related to the open radio path. For details see GSM 04.08.

3. Radio Resource management (RR) The RR entity contains elementary procedures for radio resource management, e.g. establishing

and maintaining physical channels. This includes handover upon request by the network and re-establishment in case of a lost channel. For details see GSM 04.08.

The Layer 3 on the radio interface shall be according to the detailed descriptions given in GSM 04.08, GSM 04.10, GSM 04.11 and the GSM 04.8x-series.

For testing of the radio interface Layer 3 functions see sections 8.1 and 10.1 in this specification. The Layer 3 functions of the radio interface are tested together with Layer 3 on the A-interface (BSS network functions). The radio interface Layer 3 is also tested together with the Layer 3 on the A-bis-interface, if used (BTS network functions).

5.11 Short Message Service Cell Broadcast (SMSCB)

The SMSCB function is specific in that it uses its own physical channel, CBCH, where complete 24 octets Layer 1 blocks are transmitted as defined in GSM 04.12, 05.02, 05.03 and 04.06. No LAPDm functionality is used.

The testing of this transmission and the corresponding functions within the BSS are included in sections 8.1.3, 9.1.3 and 10.1.3.

6 Internal A-BIS interfacing

The use of the A-bis-interface is optional for a GSM PLMN operator. However, if one or more transceiver units of a BSS are not co-located with the control functions of the BSS, the BSS shall be split into the 2 functional entities Base Station Controller (BSC) and Base Transceiver Station(s) (BTS(s)). See also section 1 in this specification. This section tests the A-bis-interface, if used, and applies to a BSC as well as to a BTS.

The interface between the Base Station Controller (BSC) and the Base Transceiver Station (BTS) is defined in GSM 08.5x and 08.6x.

6.1 Layer 1

This section applies to a BSC as well as to a BTS.

Layer 1 shall utilise digital transmission at a rate of 2048 kbit/s with a frame structure of 32 x 64 kbit/s timeslots or at a rate of 64 kbit/s. The detailed structure of Layer 1 on the A-bis-interface shall be according to GSM 08.54.

The Layer 1 testing of a 64 kbit/s or 2048 kbit/s PCM link is a national or operator specific matter.

6.2 Signalling transport mechanism, layer 2

6.2.1 Base Station Controller

Layer 2 on the A-bis-interface is based on the modified LAPD protocol as specified in recommendation CEPT T/S 46.20. The detailed Layer 2 specification is given in GSM 08.56.

Layer 2 shall be tested according to the relevant parts of the Layer 2 testing in:

NET 3 (Norme Europeenne de Telecommunications):

Approval requirements for terminal equipment to connect to Integrated Services Digital Network (ISDN) using basic ISDN access, part 1 (layers 1 and 2

aspects) Testing of parts of LAPD to which the Layer 2 testing in NET 3 does not apply, is a national or operator specific matter.

NOTE: NET 3 applies to the terminal equipment side of LAPD, while in GSM the BSC represents the network side.

In the GSM system the LAPD protocol on the A-bis-interface has been slightly modified. The modifications to the LAPD protocol have to be tested explicitly. Other modifications to the LAPD protocol have to be taken into account while applying the tests given in NET3.

Additional tests for the modified parts of LAPD according to GSM 08.56 are defined in the following. The following tests replace the corresponding tests in NET3.

Before carrying out any of the following tests the timer T201 shall be set globally by an O&M message as defined by the operator or the manufacturer over the OMC-interface.

6.2.1.1 Successful TEI allocation - fixed TEI

Test Purpose

To check that the BSC correctly initiates the TEI identity check procedure during TEI allocation and correctly assigns the requested TEI when no identity responses occur within a certain guard period. The TEI shall be in the range 0-63.

Page 70 GSM 11.23 v.4.4.0: May 1996

Test Case

Initial Setup

The BSC shall be in the TEI unassigned state.

Description

A UI frame shall be input to the BSC containing the message IDENTITY REQUEST and an Action Indicator (AI). The AI shall be 50.

The BSC should respond with a UI frame containing the message IDENTITY CHECK REQUEST and AI=50, followed by a UI frame containing the message IDENTITY ASSIGN and AI=50 after the expiry of T201 twice.

In principle, the frames from the BSC could be replaced by a UI frame containing IDENTITY DENIED and AI=50, but it is assumed that the conditions are such that there is no reason for the BSC to deny TEI allocation.

Message Flow

BSSTE BSC UI (ID REQ, AI) 1 -------------------------------------------------> UI (ID CHK REQ, AI) <------------------------------------------------- 2 - T201 - UI (ID ASS, AI) T201 <------------------------------------------------- 3 - The frames from the BSSTE will be:

1. UI frame with: SAPI=63, C=0, P=0, TEI=127 Info=IDENTITY REQUEST AI=50, RI=0 (not used) Conformance Requirements

The frames from the BSC shall be:

2. UI frame with: SAPI=63, C=1, P=0, TEI=127 Info=IDENTITY CHECK REQUEST AI=50, RI=0 (not used) 3. UI frame with: SAPI=63, C=1, P=0, TEI=127 Info=IDENTITY ASSIGN AI=50, RI=0 (not used) Requirements Reference

This operation is outlined in GSM 08.56 section 6.1.11.2.

6.2.1.2 Denied TEI allocation - fixed TEI

Test Purpose

To check that the BSC correctly omits to assign a TEI when another TRX responds to the identity check within a certain guard period. The TEI shall be in the range 0-63.

Test Case

Initial Setup

The BSC shall be in the TEI unassigned state.

Description

A UI frame shall be input to the BSC containing the message IDENTITY REQUEST and AI=50.

The BSC should respond with a UI frame containing the message IDENTITY CHECK REQUEST and AI=50.

Within twice the expiry of T201 a UI frame containing the message IDENTITY CHECK RESPONSE and AI=50 shall be input to the BSC emulating a response from another TRX.

The BSC shall not respond with any further frames.

Message Flow

BSSTE BSC UI (ID REQ, AI) 1 -------------------------------------------------> UI (ID CHK REQ, AI) <------------------------------------------------- 2 - T201 UI (ID CHK RES, AI) - 3 -------------------------------------------------> T201 - The frames from the BSSTE will be:

1. UI frame with: SAPI=63, C=0, P=0, TEI=127 Info=IDENTITY REQUEST AI=50, RI=0 (not used) 3. UI frame with: SAPI=63, C=0, P=0, TEI=127 Info=IDENTITY CHECK REQUEST AI=50, RI=0 (not used) Conformance Requirements


2. UI frame with: SAPI=63, C=1, P=0, TEI=127 Info=IDENTITY CHECK RESPONSE AI=50, RI=0 (not used)

Page 72 GSM 11.23 v.4.4.0: May 1996



6.2.1.3 Successful TEI allocation - additional TEI

Test Purpose

To check that the BSC correctly initiates the TEI identity check procedure during the assignment of an additional TEI and correctly assigns the requested TEI when no identity responses occur within a certain guard period. The additional TEI is assigned to a physical connection via an O & M command and is in the range 64-126

Test Case

Initial Setup

The BSC shall have a TEI in range 0-63 assigned and an additional TEI , in the range 64-126,assigned to a physical connection via an O & M message.

BSSTE BSC UI (ID REQ, AI) 1 -------------------------------------------------> UI (ID CHK REQ, AI) <------------------------------------------------- 2 - T201 - UI (ID ASS, AI) T201 <------------------------------------------------- 3 - O&M(EST TEI)- <------------------------------------------------- O&M(EST ACK) --------------------------------------------------> Description

A UI frame shall be input to the BSC containing the message IDENTITY REQUEST and an Action Indicator (AI). The AI is in range 64-126 and TEI=127.

The BSC should respond with a UI frame containing the message IDENTITY CHECK REQUEST and AI=64-126, followed by a UI frame containing the message IDENTITY ASSIGN and AI=64-126 after the expiry of T201 twice.

Message Flow

BSSTE BSC UI (ID REQ, AI) 1 -------------------------------------------------> UI (ID CHK REQ, AI) <------------------------------------------------- 2 - T201 - UI (ID ASS, AI) T201 <------------------------------------------------- 3 - The frames from the BSSTE will be:

1. UI frame with:

SAPI=63, C=0, P=0, TEI=127 Info=IDENTITY REQUEST AI=64-126, RI=0 (not used) Conformance Requirements


2. UI frame with: SAPI=63, C=1, P=0, TEI=127 Info=IDENTITY CHECK REQUEST AI=64-126, RI=0 (not used) 3. UI frame with: SAPI=63, C=1, P=0, TEI=127 Info=IDENTITY ASSIGN AI=64-126, RI=0 (not used) Requirements Reference


6.2.1.4 Denied TEI allocation - additional TEI

Test Purpose

To check that the BSC correctly omits to assign an additional TEI when another TRX responds to the identity check within a certain guard period. The TEI shall be in the range 64-126.

Test Case

Initial Setup

The BSC shall have a TEI in range 0-63 assigned and an additional TEI , in the range 64-126,assigned to a physical connection via an O & M message.

BSSTE BSC UI (ID REQ, AI) 1 -------------------------------------------------> UI (ID CHK REQ, AI) <------------------------------------------------- 2 - T201 - UI (ID ASS, AI) T201 <------------------------------------------------- 3 - O&M(EST TEI)- <-------------------------------------------------- O&M(EST ACK) --------------------------------------------------> Description

A UI frame shall be input to the BSC containing the message IDENTITY REQUEST with AI = 64-126 and TEI=127

The BSC should respond with a UI frame containing the message IDENTITY CHECK REQUEST and AI=64-126.

Page 74 GSM 11.23 v.4.4.0: May 1996

Within twice the expiry of T201 a UI frame containing the message IDENTITY CHECK RESPONSE and AI=64-126 shall be input to the BSC emulating a response from another TRX.

The BSC shall not respond with any further frames.

Message Flow

BSSTE BSC UI (ID REQ, AI) 1 -------------------------------------------------> UI (ID CHK REQ, AI) <------------------------------------------------- 2 - T201 UI (ID CHK RES, AI) - 3 -------------------------------------------------> T201 - The frames from the BSSTE will be:

1. UI frame with: SAPI=63, C=0, P=0, TEI=127 Info=IDENTITY REQUEST AI=64-126, RI=0 (not used) 3. UI frame with: SAPI=63, C=0, P=0, TEI=127 Info=IDENTITY CHECK REQUEST AI=64-126, RI=0 (not used) Conformance Requirements


2. UI frame with: SAPI=63, C=1, P=0, TEI=127 Info=IDENTITY CHECK RESPONSE AI=64-126, RI=0 (not used) Requirements Reference


6.2.2 Base Transceiver Station

Layer 2 on the A-bis-interface is based on the modified LAPD protocol as specified in recommendation CEPT T/S 46.20. The detailed Layer 2 specification is given in GSM 08.56.

Layer 2 shall be tested according to the relevant parts of the Layer 2 testing in:

NET 3 (Norme Europeenne de Telecommunications):

Approval requirements for terminal equipment to connect to Integrated Services Digital Network (ISDN) using basic ISDN access, part 1 (layers 1 and 2

aspects) In the GSM system the LAPD protocol on the A-bis-interface has been slightly modified. The modifications to the LAPD protocol have to be tested explicitly. Other modifications to the LAPD protocol have to be taken into account while applying the tests given in NET3.

Additional tests for the modified parts of LAPD according to GSM 08.56 are defined in the following. The following tests replace the corresponding tests in NET3.

Before carrying out any of the following tests the timer T202 shall be set globally by O&M, manually or with an O&M-message as defined by the operator or the manufacturer over the A-bis-interface.

6.2.2.1 Successful TEI allocation - fixed TEI

Test Purpose

To check the correct TEI identity request by the TRX when a message needs to be passed over the A-bis-interface to the BSC. The TEI shall be in the range 0-63.

Test Case

Initial Setup

The TRX shall be in the TEI unassigned state.

Description

Conditions triggering the TEI assignment procedure shall be set up.

The TRX should respond with a UI frame containing the message IDENTITY REQUEST and an AI in the range 0-63 to start initialising the link for acknowledged mode of operation.

A UI frame containing the message IDENTITY CHECK REQUEST and the AI-value received from the TRX shall be input from the BSSTE, followed by a UI frame containing the message IDENTITY ASSIGN and the same AI after twice the expiry of T202.

The TRX should then proceed with a multiple frame establishment in the normal way.

Message Flow

TRX BSSTE UI (ID REQ, AI) 1 -------------------------------------------------> UI (ID CHK REQ, AI) <------------------------------------------------- 2 - T201 - UI (ID ASS, AI) T201 <------------------------------------------------- 3 - The frames from the BSSTE will be:

2. UI frame with: SAPI=63, C=1, P=0, TEI=127 Info=IDENTITY CHECK REQUEST AI=0-63, RI=0 (not used) 3. UI frame with: SAPI=63, C=1, P=0, TEI=127 Info=IDENTITY ASSIGN AI=0-63, RI=0 (not used) Conformance Requirements

The frames from the TRX shall be:

Page 76 GSM 11.23 v.4.4.0: May 1996

1. UI frame with: SAPI=63, C=0, P=0, TEI=127 Info=IDENTITY REQUEST AI=0-63, RI=0 (not used) Requirements Reference


6.2.2.2 Denied TEI allocation - fixed TEI

Test Purpose

To check that the TRX correctly re transmits the TEI identity request after a given guard period. The TEI shall be in the range 0-63.

NOTE: GSM 08.56 states that the parameter N202 is not used. This means that the re transmission shall occur an infinite number of times.

Test Case

Initial Setup

The TRX shall be in the TEI unassigned state.

Description


The TRX should respond with a UI frame on the A-bis-interface containing the message IDENTITY REQUEST and an AI in the range 0-63 to start initialising the link for acknowledged mode of operation.


After the expiry of T202 the UI frame last sent from the TRX shall be repeated by the TRX with the same content.

Before the expiry of T202 again, the BSSTE shall input a UI frame containing the message IDENTITY DENIED and the AI-value received from the TRX.

At the expiry of T202 (started at the last UI frame sent by the TRX), the TRX should then repeat the last UI frame again.

Before the expiry of T202 again, the BSSTE shall input a UI frame containing the message IDENTITY ASSIGN and the AI-value received from the TRX.


Message Flow

TRX BSSTE UI (ID REQ, AI) 1 -------------------------------------------------> - | T202 UI (ID REQ, AI) | 2 -------------------------------------------------> - | T202 UI (ID REQ, AI) | 4 -------------------------------------------------> - UI (ID ASS, AI) <------------------------------------------------- 5 The frames from the BSSTE will be:

3. UI frame with: SAPI=63, C=1, P=0, TEI=127 Info=IDENTITY DENIED AI=0-63, RI=0 (not used) 5. UI frame with: SAPI=63, C=1, P=0, TEI=127 Info=IDENTITY ASSIGN AI=0-63, RI=0 (not used) Conformance Requirements


1,2,4. UI frame with: SAPI=63, C=0, P=0, TEI=127 Info=IDENTITY REQUEST AI=0-63, RI=0 (not used) Requirement Reference


6.2.2.3 Successful TEI allocation - additional TEI

Test Purpose

To check the correct TEI identity request by the TRX when a message needs to be passed over the A-bis-interface to the BSC. The TEI shall be in the range 64-126.

Test Case

Initial Setup

The TRX shall have a TEI in range 0-63 assigned and an additional TEI , in the range 64-126,assigned to a physical connection via an O & M message over the A-bis interface on an already verified O & M link.

Page 78 GSM 11.23 v.4.4.0: May 1996

TRX BSSTE UI (ID REQ, AI) 1 -------------------------------------------------> UI (ID CHK REQ, AI) <------------------------------------------------- 2 - T201 - UI (ID ASS, AI) T201 <------------------------------------------------- 3 - O&M(EST TEI)- <--------------------------------------------------- O&M(EST ACK) ---------------------------------------------------> Description


The TRX should respond with a UI frame containing the message IDENTITY REQUEST and an AI in the range 64-126 to start initialising the link for acknowledged mode of operation.

A UI frame containing the message IDENTITY CHECK REQUEST and the AI-value received from the TRX shall be input from the BSSTE, followed by a UI frame containing the message IDENTITY ASSIGN and the same AI after twice the expiry of T202.


Message Flow

TRX BSSTE UI (ID REQ, AI) 1 -------------------------------------------------> UI (ID CHK REQ, AI) <------------------------------------------------- 2 - T201 - UI (ID ASS, AI) T201 <------------------------------------------------- 3 - The frames from the BSSTE will be:

2. UI frame with: SAPI=63, C=1, P=0, TEI=127 Info=IDENTITY CHECK REQUEST AI=64-126, RI=0 (not used) 3. UI frame with: SAPI=63, C=1, P=0, TEI=127 Info=IDENTITY ASSIGN AI=64-126, RI=0 (not used) Conformance Requirements


1. UI frame with: SAPI=63, C=0, P=0, TEI=127 Info=IDENTITY REQUEST

AI=64-126, RI=0 (not used) Requirements Reference


6.2.2.4 Denied TEI allocation - additional TEI

Test Purpose

To check that the TRX correctly retransmits the TEI identity request for an additional TEI assignment, after a given guard period. The TEI shall be in the range 64-126.

NOTE: GSM 08.56 states that the parameter N202 is not used. This means that the retransmission shall occur an infinite number of times.

Test Case

Initial Setup

The TRX shall have a TEI in range 0-63 assigned and an additional TEI , in the range 64-126,assigned to a physical connection via an O & M message over the A-bis interface on an already verified O & M link.

TRX BSSTE UI (ID REQ, AI) 1 -------------------------------------------------> UI (ID CHK REQ, AI) <------------------------------------------------- 2 - T201 - UI (ID ASS, AI) T201 <------------------------------------------------- 3 - O&M(EST TEI)- <--------------------------------------------------- O&M(EST ACK) ---------------------------------------------------> Description


The TRX should respond with a UI frame on the A-bis-interface containing the message IDENTITY REQUEST and an AI in the range 64-126 to start initialising the link for acknowledged mode of operation.


After the expiry of T202 the UI frame last sent from the TRX shall be repeated by the TRX with the same content.

Before the expiry of T202 again, the BSSTE shall input a UI frame containing the message IDENTITY DENIED and the AI-value received from the TRX.

At the expiry of T202 (started at the last UI frame sent by the TRX), the TRX should then repeat the last UI frame again.

Before the expiry of T202 again, the BSSTE shall input a UI frame containing the message IDENTITY ASSIGN and the AI-value received from the TRX.

Page 80 GSM 11.23 v.4.4.0: May 1996


Message Flow

TRX BSSTE UI (ID REQ, AI) 1 -------------------------------------------------> - | T202 UI (ID REQ, AI) | 2 -------------------------------------------------> - | T202 UI (ID REQ, AI) | 3---------------------------------------------------> - UI (ID ASS, AI) <------------------------------------------------- 4 The frames from the BSSTE will be:

4. UI frame with: SAPI=63, C=1, P=0, TEI=127 Info=IDENTITY ASSIGN AI=64-126, RI=0 (not used) Conformance Requirements


1,2,3. UI frame with: SAPI=63, C=0, P=0, TEI=127 Info=IDENTITY REQUEST AI=64-126, RI=0 (not used) Requirement Reference


6.3 LAYER 3

Concerning the BSC, the Layer 3 on the A-bis-interface is tested in connection with Layer 3 on the A-interface as BSC network functions in section 9.1 in this equipment specification.

Concerning the BTS, the Layer 3 on the A-bis-interface is tested in connection with Layer 3 on the radio interface as BTS network functions in section 10.1 in this equipment specification.

7 Interfacing with the mobile services switching centre

This section specifies the interface between the Mobile services Switching Centre (MSC) and the Base Station System (BSS) as described in the GSM 08.0x-series of specifications, the BSS/MSC-interface. The interface is referred to as the A-interface or the MSC-interface as seen from the BSS. See section 1 for further information. This section tests the A-interface, and applies to an integrated BSS as well as to a BSC.

7.1 Physical interface layer 1

Layer 1 shall utilise digital transmission at a rate of 2048 kbit/s with a frame structure of 32 x 64 kbit/s time slots. The detailed structure of the Layer 1 on the A-interface shall be according to GSM 08.04.

The Layer 1 testing of a 2048 kbit/s PCM link is a national or operator specific matter.

7.2 Signalling transport mechanism, layer 2

Layer 2 on the A-interface is based on the CCITT signalling system no 7 Message Transfer Part (MTP) and the Signalling Connection Control Part (SCCP). The detailed Layer 2 specification is given in GSM 08.06.

MTP shall be tested according to the relevant parts of the following CCITT recommendations.

Q.780 (Signalling System no 7 test specification - general) Q.781 (MTP level 2 test specification) Q.782 (MTP level 3 test specification) Testing of SCCP is a national or operator specific matter.

7.3 Layer 3 protocol

The functional split of network functions between the BSS and the MSC is given in GSM 08.02. The BSS’s main responsibility on Layer 3 is the management of the local radio resources (Radio Resource management - RR). The detailed specifications for the Layer 3 procedures used on the A-interface are given in GSM 08.08.

The Layer 3 on the A-interface is tested in connection with Layer 3 on the radio interface or the A-bis-interface as BSS or BSC network functions in sections 8.1 and 9.1 in this specification, respectively.

Page 82 GSM 11.23 v.4.4.0: May 1996

8 Base station system network aspects

This section applies to an integrated BSS.

8.1 Base station system network functions

8.1.1 General

The signalling network functions provided by the GSM system are described in GSM 03.01. The Layer 3 protocol on the radio interface is specified in GSM 04.08. For the MSC-interface the Layer 3 protocol is specified in GSM 08.08.

Of the Layer 3 network functions in the BSS this section tests the network functions which are performed in the BSS in operation with a radio interface and an MSC-interface, i.e. the BSS being a black box with 2 interfaces and some processing inside. This section tests then the relations between the Layer 3 messages occurring at the 2 interfaces.

The functional split between the MSC and the BSS is given in GSM 08.02. The functions to be performed in the BSS consist mainly of:

- management of radio channels - management of terrestrial channels - mapping between radio and terrestrial channels - channel coding/decoding - transcoding/rate adaptation - enciphering/deciphering The logical functions which can be tested at Layer 3, i.e. the management of radio and terrestrial channels and the mapping between them are tested in sections 8.1.2 and 8.1.3, the transcoding/rate adaptation functions are tested in GSM 11.24 section 8.1.4. The channel coding/decoding functions and the ciphering functions are tested implicitly in GSM 11.21 sections 6 and 7.

According to GSM 08.08 the BSS Layer 3 (or in fact layers 4-7) functions are split into the following functional entities on the MSC side:

- BSSAP (BSS Application Part) - BSSMAP (BSS Management Application Part) - DTAP (Direct Transfer Application Part) - BSSOMAP (BSS Operation and Maintenance Application Part) In this section, only the BSSAP (BSSMAP + DTAP) is tested. The BSSOMAP is tested in sections 8 and 9 in this specification. This section also tests the internal functions in the BSS addressed by the BSSAP. All tests are carried out under perfect transmission conditions and under no limiting conditions.

Internal BSC/BTS-interfaces in the BSS may exist as an option for the GSM operator. In case such interfaces exist, the functional split between the 2 different functional entities is defined in GSM 08.52.

Seen from the radio interface (see GSM 04.07), the Layer 3 (or in fact layers 3-7) is divided into the following functional entities:

- Radio Resource management (RR) - Mobility Management (MM) - Connection Management (CM) - Call Control (CC) - Supplementary Services support (SS) - Short Message Services support (SMS) Of these network functions only the Radio Resource management (RR) is executed in the BSS and may interact with BSSMAP. All other radio interface Layer 3 messages are DTAP messages.

The Layer 3 network functions of the BSS are tested mainly as BSSMAP and RR functions in terms of elementary procedures according to GSM 04.08 and GSM 08.08. DTAP messages are tested for transparency. The elementary procedures are sub-procedures of the structured procedures which will normally occur between a Mobile Station and the network.

The structured procedures are:

1. Location updating 2. Mobile originated call establishment 3. Mobile terminated call establishment 4. Call clearing 5. DTMF protocol control 6. Handover 7. In-call modification 8. Mobile originated call re-establishment Examples of such structured procedures can be found in GSM 04.08 section 7.3.

The BSSMAP and RR tests as a whole are intended to cover all normal and abnormal cases of significance within each elementary procedure. However, all possible error causes are not tested, normally only if they imply different message sequences.

Structured procedures are not tested due to their optional nature and because testing of abnormal cases in structured procedures would be enormous. It is, however, of major importance to verify the correct functioning of the implemented structured procedures in addition to the verification of the elementary procedures before putting a BSS into operation.

The term Main Signalling Link (MSL) used in the following tests is defined in GSM 04.08 and can be either a FACCH or an SDCCH.

8.1.2 Testing of the DTAP

The DTAP protocol provides transparent messages through the BSS from the radio interface to the MSC-interface and from the MSC-interface to the radio interface. The messages are defined in GSM 04.08. The tests in this section are performed under perfect transmission conditions and under no limiting load conditions.

The main signalling link on the radio interface and the SCCP connection on the MSC-interface shall be established prior to the tests defined in this section.

8.1.2.1 Messages from MSC to MS

Test Purpose

All downlink messages listed in GSM 04.10 (Supplementary Services - SS) and GSM 04.11 (Point-to-point Short Message Service - SMS), and all messages listed in GSM 04.08 of the types:

- Packet switched call control messages - Circuit switched call control messages - Mobility management messages are DTAP messages and may be tested for transparency from the MSC to the MS when the main signalling link is set up. There may be additional messages in the future.

Test Case

Initial Setup

RR connection exists.

Page 84 GSM 11.23 v.4.4.0: May 1996

Description

A message shall be applied on the MSC-interface from the BSSTE. The message shall be a DTAP message. The response on the radio interface shall be recorded in the BSSTE.

The test shall be repeated at least until one MM message and one CC message have been tested.

Conformance Requirement

Each message input on the MSC-interface shall also be output on the appropriate signalling link on the radio interface.

Requirement reference

GSM 08.08 § 2.2

8.1.2.2 Messages from MS to MSC

Test Purpose

All uplink messages listed in GSM 04.10 (Supplementary Services - SS) and GSM 04.11 (Point-to-point Short Message Service - SMS), and all messages listed in GSM 04.08 of the types:

- Packet switched call control messages - Circuit switched call control messages - Mobility management messages are DTAP messages and may be tested for transparency from the MS to the MSC when the main signalling link is set up. There may be additional messages in the future.

Test Case

Initial Setup

RR connection exists.

Description

A message shall be input on the appropriate signalling link on the radio interface from the BSSTE. The message shall have a protocol discriminator indicating that the message is not an RR message. The response on the MSC-interface shall be recorded in the BSSTE.

The test shall be repeated at least until one MM message and one CC message have been tested.

Conformance Requirement:

Each message input on the radio interface shall also be output on the MSC-interface.


GSM 08.08 § 2.2

8.1.3 Testing of the BSSMAP and RR functions

The tests described in this section are to verify that messages sent to the Base Station System using the BSSMAP/RR have the correct consequential actions, and that combinations of certain events cause the correct messages to be sent using the BSSMAP/RR on the radio interface or the A-interface by the BSS. Time constraints have to be met.

The following procedures are to be tested:

RR/BSSMAP:

1. System information 2. Service requests in SABM frames 3. Random access by MS and immediate assignment 4. Paging 5. Measurement report 6. Assignment 7. External handover as seen from the old BSS 8. External handover as seen from the new BSS 9. Internal handover 10. Frequency redefinition 11. Transmission mode change 12. Ciphering mode setting 13. Additional assignment 14. Partial release 15. Classmark change / Classmark interrogation 16. Channel release 17. Radio link failure

BSSMAP:

18. Blocking 19. Resource indication 20. Reset 21. Handover candidate enquiry 22. Trace invocation 23. Flow control 24. Data link control for SAPI not equal to 0 25. Queuing indication

Short message cell broadcast:

26. Short message cell broadcast NOTE: The Short Message Service Cell Broadcast (SMSCB) messages defined in GSM 04.12

are excluded from the protocol model defined in GSM 04.07, and are consequently neither DTAP messages nor BSSMAP messages, but may generally have to be treated as BSSMAP messages.

Details of the correct operation of these procedures are to be found in GSM 04.08 and GSM 08.08.

For each of the procedures a figure showing the message exchange between MS, BSS and MSC under normal conditions is included, i.e. under no abnormal or failure conditions. It should be noted that a single arrow from MS to MSC through the BSS, or vice versa, indicates a transparent DTAP message and if a message is split into 2 parts, this indicates a non-transparent BSSMAP or RR message.

The detailed message contents are also indicated, but only parameters of importance for the test are specified. If not specified, the parameters are either not included in the message or are "don’t care". The parameters shall, however, always be relevant to the procedure. It should be noted that all mandatory and optional information fields are indicated for the overview, whereas in an implementation some of the optional fields may occur or not depending on the context or on operator choices. Some optional fields may also be mutually exclusive.

In this section, timers at Layer 3 as defined in GSM 04.08 or GSM 08.08 are only tested for functionality, i.e. that different actions are taken by the BSS if a timer expires or not. Testing of the timing accuracy of timers are outside the scope of this recommendation. For testing of timer accuracy, see GSM 11.21.

Concerning erroneous messages (i.e. with undefined protocol discriminators, undefined messages types, or too short messages, or with undefined contents etc.) some optional procedures are defined for the

Page 86 GSM 11.23 v.4.4.0: May 1996

radio interface in GSM 04.08 section 8. For the A-interface some procedures are defined in GSM 08.08 section 3.1.19.

8.1.3.1 System information

The system information procedure is used by the BSS to modify the information contents to be transmitted on the SACCH when a dedicated resource has been set up or on the BCCH when no dedicated resource has been set up (or in fact always). The BSS will send SYSTEM INFORMATION messages type 1-4 on the BCCH and SYSTEM INFORMATION messages type 5-6 on the SACCH. The system information is always controlled by O&M. The timing requirements for when to send the different SYSTEM INFORMATION messages are described in GSM 05.02.

NOTE: System Information 2bis, 2ter, 5bis and 5terbis only appear in E-GSM and DCS1800 may also be sent on the appropriate channels as indicated in GSM 04.08 § 3.2.2.1 and GSM 05.05 (e.g. support of E-GSM, DCS1800, multi band operation).

8.1.3.1.1 Dedicated resource set up

Test Purpose

To check the System Information messages 5 and 6 are modified when an O&M messages is sent to the BSS commanding to modify the current broadcast information to go on the SACCH.

Test Case

Initial Setup

A dedicated resource shall be set up between the radio interface and the MSC-interface. The response on any interface shall be recorded.

Description

1. An O&M message as defined by the operator or the manufacturer shall be input on the OMC-interface commanding the BSS to modify the broadcast information to go on the SACCH. The response on any interface shall be recorded.

2. The step 1 shall be repeated until all the SYSTEM INFORMATION messages type 5 and 6

(optionallyincluding 5bis, 5ter) are verified. Message flow

MS BSS MSC O&M SYS INFO <----------------------------- SYS INFO <----------------------------- The messages from the BSSTE will be:

1. O&M MESSAGES Conformance Requirement:

In the case of step 1, SYSTEM INFORMATION messages of the type 5 to 6 (includingoptionally, type 5bis, 5ter) shall occur on the radio interface on the SACCH. The information contents including the restoctets shall correspond to what is set by O&M.


GSM 05.02 GSM 04.08 §9.1.31 to 9.1.40

8.1.3.1.2 No dedicated resource established

Test Purpose

To check the System Information messages 1-8 are modified when an O&M messages is sent to the BSS commanding to modify the broadcast information to go on the BCCH and SACCH.

The System Information messages 5&6 (includingoptionally 5bis, 5ter) shall be checked by establishing a dedicated resource after the change of the System Information messages.

Test Case

Initial Setup

BCCH is available

Description

1. An O&M message as defined by the operator or the manufacturer shall be input on the OMC-interface commanding the BSS to modify the broadcast information to go on the BCCH and SACCH. The response on any interface shall be recorded.

2. The step 1 shall be repeated until all the SYSTEM INFORMATION messages type 1 to 4, 7 and 8

(includingoptionally type 2bis, 2ter) are verified. 3. A dedicated resource shall be set up between the radio interface and the MSC-interface. The

response on any interface shall be recorded. 4. Step 3 - shall be repeated until all the SYSTEM INFORMATION messages type 5 and 6 -

(includingoptionally type 5bis, 5ter) are verified. Message flow

MS BSS MSC O&M SYS INFO <----------------------------- SYS INFO <----------------------------- The messages from the BSSTE will be:

1. O&M MESSAGES Conformance Requirement:

In the case of step 1, SYSTEM INFORMATION messages of the type 1 to 4, 7 and 8 (includingoptionally type 2bis, 2ter) shall occur on the radio interface on the BCCH. The information contents including the rest octets shall correspond to what is set by O&M.

In the case of step 2, SYSTEM INFORMATION messages of the type 5 to 6 (including,optionally type 5bis, 5ter) shall occur on the radio interface on the SACCH. The information contents shall correspond to what is set by O&M.

Page 88 GSM 11.23 v.4.4.0: May 1996

Requirement reference:

GSM 05.02 GSM 04.08 §9.1.31 to 9.1.40

8.1.3.2 Service requests in SABM frames

8.1.3.2.1 Allowed messages

Test Purpose

When the MS first accesses the network on a signalling link, it is to indicate to the network the requested service. The requests can be one of the following Layer 3 messages:

LOCATION UPDATING CM SERVICE REQUEST PAGING RESPONSE IMSI DETACH CM REESTABLISHMENT REQUEST These Layer 3 messages are transferred in the LAPDm SABM frame setting up the LAPDm signalling link. The CM SERVICE REQUEST may concern a normal call or e.g. a Short Message Service (SMS).

Test Case

Initial Setup

The random access by MS and the immediate assignment procedure shall be carried out to assign a dedicated resource.

Description

1. A LAPDm SABM frame shall be input on the radio interface with an information field as given above. The response on any interface shall be recorded.

2. Step 1 shall be repeated for all the Layer 3 messages indicated above. Message flow

MS BSS MSC SABM(L3 message) - - - - - - - - - - - - - - > UA(L3 message) < - - - - - - - - - - - - - - COMPL L3 INFO (L3 message) ----------------------------> The messages from the BSSTE will be:

1.,2. SABM on the Air interface including one of the above initial L3 messages


In the case of steps 1 and 2, the exact Layer 3 message contained in the SABM frame shall occur also contained in a COMPLETE LAYER 3 INFORMATION message on the MSC-interface, and a LAPDm UA frame acknowledging the SABM shall occur on the radio interface.

The messages from the BSS shall be:

1.,2. COMPLETE L3 INFORMATION on the A interface, coded as specified in GSM 08.08 § 3.2.1.32 with

L3 information = radio interface initial L3 message

1.,2. LAPDm UA frame on the Air interface, coded as specified in GSM 04.06


GSM 04.08 §3.1.5. GSM 08.06 §6.1.1 GSM 08.08 §3.1.16. 8.1.3.2.2 Not allowed messages

Test Purpose

To check that Layer 3 messages contained in the SABM are not transferred on the A interface when not being one of the messages defined below

LOCATION UPDATING CM SERVICE REQUEST PAGING RESPONSE IMSI DETACH CM REESTABLISHMENT REQUEST Test Case

Initial Setup

The random access by MS and the immediate assignment procedure shall be carried out to assign a dedicated resource.

Description

1. A LAPDm SABM frame shall be input on the radio interface with an information field not defined above. The response on any interface shall be recorded.

Message flow

MS BSS MSC SABM(L3 message) - - - - - - - - - - - - - - > UA(L3 message) < - - - - - - - - - - - - - - The messages from the BSSTE will be:

1. SABM on the Air interface including an initial L3 message not defined above


In the case of step 1, a LAPDm UA frame acknowledging the SABM shall occur on the radio interface and no message shall occur on any other interface.


1. LAPDm UA frame on the Air interface, coded as specified in GSM 04.06

Page 90 GSM 11.23 v.4.4.0: May 1996


GSM 04.08 §3.1.5. GSM 08.06 §6.1.1

GSM 08.08 §3.1.16

8.1.3.3 Random access by MS and immediate assignment

The purpose of the immediate assignment procedure is to establish a RR connection between MS and network on a dedicated channel, typically an SDCCH or a FACCH (the main signalling link). The procedure is always triggered by the MS, and can be triggered by a paging request or a mobile originated transaction.

NOTE 1: The immediate assignment procedure could also be triggered by other establishment causes.. This transaction are not tested explicitly.

NOTE 2: The extended immediate assignment procedure is not tested explicitly because it is not specified when the BSS may use it.

8.1.3.3.1 Normal Case - SDCCH

Test Purpose

To check the normal immediate assignment procedure in case of SDCCH assignment.

Test Case

Initial Setup

An O&M message as defined by the operator or the manufacturer shall be input on the OMC-interface commanding the BSS to set the timer T3101 to an appropriate value A. The BSS shall be configured to use the SDCCH as the main signalling link.

Description

1. The BSSTE shall input a CHANNEL REQUEST message on the radio interface on the RACH. The response on any interface shall be recorded.

2. If an IMMEDIATE ASSIGNMENT message is received from the BSS on the CCCH, a LAPDm

SABM frame containing CM SERVICE REQUEST shall be input on the radio interface on the main signalling link by the BSSTE before the time T3101. The response on any interface shall be recorded.

Message flow

MS BSS MSC CH REQ ----------------------------> IMM ASS <---------------------------- - SABM(CM SERV REQ) | - - - - - - - - - - - - - - > T3101 UA(CM SERV REQ) | < - - - - - - - - - - - - - - - SCCP establishment COMPL L3 INFO (CM SERV REQ) ---------------------------> The messages from the BSSTE will be:

1 CHANNEL REQUEST on the Air interface, coded as specified in GSM 04.08 §9.1.8 with Establishment cause = originating call Random reference = PAR1

2. SABM(CM SERVICE REQUEST) on the Air interface, coded as specified in GSM 04.08 §9.2.9 and GSM 04.06.


In the case of step 1, an IMMEDIATE ASSIGNMENT message shall occur on the radio interface on the CCCH including relevant channel assignment information. The channel assigned shall be an SDCCH.

The IA rest octets shall correspond to what is set by O&M.

In the case of step 2, a LAPDm UA frame acknowledging the SABM shall occur on the radio interface on the SDCCH. Then an SCCP connection shall be established and the exact CM SERVICE REQUEST message contained in the SABM shall occur on the MSC-interface. LAPDm UI fill frames shall occur continuously on the radio interface on the SDCCH.


1. IMMEDIATE ASSIGNMENT on the Air interface, coded as specified in GSM 04.08 §9.1.18 with Channel Description = SDCCH Request reference = PAR1 IA Rest Octets

2. CM SERVICE REQUEST in UA LAPDm frame on the Air interface, coded as specified in

GSM 04.08 §9.2.9 and in GSM 04.06. Requirement reference:

GSM 04.06 §3.8.2. GSM 04.08 §3.3.1.2, §3.3.1.3, 3.3.1.4. GSM 08.08 §3.1.16.

8.1.3.3.2 Normal Case - TCH

Test Purpose

To check the normal immediate assignment procedure in case of TCH assignment.

This test should be performed only if the BSS supports the TCH/FACCH assignment in the immediate assignment procedure.

Page 92 GSM 11.23 v.4.4.0: May 1996

Test Case

Initial Setup

An O&M message as defined by the operator or the manufacturer shall be input on the OMC-interface commanding the BSS to set the timer T3101 to an appropriate value A. The BSS shall be configured to use the FACCH as the main signalling link.

Description



SABM frame containing CM SERVICE REQUEST shall be input on the radio interface on the main signalling link by the BSSTE before the time T3101. The response on any interface shall be recorded.

3. After having established the SCCP connection, an ASSIGNMENT REQUEST message shall be

input on the MSC-interface requesting a TCH/FACCH for the use of speech and signalling. The response on any interface shall be recorded.

4. A CHANNEL MODE MODIFY ACKNOWLEDGE message shall be input on the radio interface on

the FACCH. Message flow

MS BSS MSC CH REQ ----------------------------> IMM ASS <---------------------------- - SABM(CM SERV REQ) | - - - - - - - - - - - - - - > T3101 UA(CM SERV REQ) | < - - - - - - - - - - - - - - - COMPL L3 INFO (CM SERV REQ) ---------------------------> ASSIGNMENT REQUEST <--------------------------- CHANNEL MODE MODIFY <---------------------------- CHANNEL MODE MODIFY ACK ----------------------------> ASSIGNMENT COMPLETE ---------------------------> The messages from the BSSTE will be:

1 CHANNEL REQUEST on the Air interface, coded as specified in GSM 04.08 §9.1.8 with: Establishment cause = originating call Random reference = PAR1


3. ASSIGNMENT REQUEST on the A interface, coded as specified in GSM 08.08 §3.2.1.1 with:

Channel type = TCH

4. CHANNEL MODE MODIFY ACKNOWLEDGE on the Air interface, coded as specified in GSM

04.08 §9.1.6, with: Channel description = TCH Channel mode = speech


In the case of step 1, an IMMEDIATE ASSIGNMENT message shall occur on the radio interface on the CCCH including relevant channel assignment information. The channel assigned shall be an TCH/FACCH.

The IA rest octets shall correspond to what is set by O&M.

In the case of step 2, a LAPDm UA frame acknowledging the SABM shall occur on the radio interface on the FACCH. Then an SCCP connection shall be established and the exact CM SERVICE REQUEST message contained in the SABM shall occur on the MSC-interface. LAPDm UI fill frames shall occur continuously on the radio interface on the FACCH.

In the case of step 3, after the ASSIGNMENT REQUEST message a CHANNEL MODE MODIFY message shall occur on the radio interface on the FACCH requesting a change from signalling to speech. The transmission of LAPDm UI fill frames shall stop.

In the case of step 4, an ASSIGNMENT COMPLETE message shall occur on the MSC-interface.


1. IMMEDIATE ASSIGNMENT on the Air interface, coded as specified in GSM 04.08 §9.1.18 with Channel Description = TCH Request reference = PAR1 IA Rest Octets

2. CM SERVICE REQUEST in UA LAPDm frame on the Air interface, coded as specified in GSM 04.08 §9.2.9 and in GSM 04.06

3. CHANNEL MODE MODIFY on the Air interface, coded as specified in GSM 04.08 §9.1.5, with Channel description = TCH Channel mode = speech

4. ASSIGNMENT COMPLETE on the A interface, coded as specified in GSM 08.08 §3.2.12 Requirement reference:

GSM 04.06 §3.8.2. GSM 04.08 §3.3.1.2, §3.3.1.3, §3.3.1.4, §3.4.6. GSM 08.08 §3.1.16.

8.1.3.3.3 T3101 expiry case

Test Purpose

To check the behaviour of the BSS in case T3101elapses before the main signalling link is established.

Page 94 GSM 11.23 v.4.4.0: May 1996

Test Case

Initial Setup


Description



SABM frame containing CM SERVICE REQUEST shall be input on the radio interface on the main signalling link by the BSSTE after the expiry of timer T3101 (T3101=A). The response on any interface shall be recorded.

Message flow

MS BSS MSC CH REQ ----------------------------> IMM ASS <---------------------------- - | T3101 | SABM(CM SERV REQ) - - - - - - - - - - - - - - - > The messages from the BSSTE will be:




In the case of step 1, an IMMEDIATE ASSIGNMENT message shall occur on the radio interface on the CCCH including relevant channel assignment information. The channel assigned shall be an SDCCH.

In the case of step 2, no messages shall occur on any interface.


1. IMMEDIATE ASSIGNMENT on the Air interface, coded as specified in GSM 04.08 §9.1.18 with Channel Description = SDCCH Request reference = PAR1


GSM 04.06 §3.8.2 GSM 04.08 §3.3.1.5. GSM 08.08 §3.1.16.

8.1.3.3.4 No radio resources available

Test Purpose

To check the immediate assignment procedure in case no radio resources available.

Test Case

Initial Setup


An O&M message as defined by the operator or the manufacturer shall be input on the OMC-interface by the BSSTE requesting the BSS to take all radio resources out of service.

Description

The BSSTE shall input a CHANNEL REQUEST message on the radio interface on the RACH. The response on any interface shall be recorded.

Message flow

MS BSS MSC CH REQ ----------------------------> IMM ASS REJECT <---------------------------- The messages from the BSSTE will be:



In the case of step 1, an IMMEDIATE ASSIGNMENT REJECT message may occur on the radio interface on the CCCH. The IAR rest octets shall correspond to the specified bit pattern. Nothing shall occur on the MSC-interface.


1. IMMEDIATE ASSIGNMENT REJECT on the Air interface, coded as specified in GSM 04.08 §9.1.20, with Request reference = PAR1 IAR Rest Octets


GSM 04.08 §3.3.1.3.2. GSM 08.08 §3.1.16.

Page 96 GSM 11.23 v.4.4.0: May 1996

8.1.3.3.5 Immediate assignment extended

Test Purpose

To check the immediate assignment extended procedure in case of two CHANNEL REQUEST messages are following in a short period.

Test Case

Initial Setup

The BSS shall be configured to use the SDCCH as the main signalling link.

Description

1. The BSSTE shall input two CHANNEL REQUEST messages with different random references on the radio interface on the RACH. The response on any interface shall be recorded.

Message flow

MS BSS MSC CH REQ (1) ----------------------------> CH REQ (2) ----------------------------> IMM ASS EXT <---------------------------- The messages from the BSSTE will be:

1 CHANNEL REQUEST on the Air interface, coded as specified in GSM 04.08 §9.1.8 with Establishment Cause = Originating Call Random reference = PAR1

2 CHANNEL REQUEST on the Air interface, coded as specified in GSM 04.08 §9.1.8 with Establishment Cause = Originating Call Random reference = PAR2


In the case of step 1, an IMMEDIATE ASSIGNMENT EXTENDED message shall occur on the radio interface on the CCCH including relevant channel assignment information. The IAX Rest Octets shall correspond to the specified bit pattern.


1. IMMEDIATE ASSIGNMENT EXTENDED on the Air interface, coded as specified in GSM 04.08 §9.1.19, with Request reference1 = PAR1 Request reference2 = PAR2 IAX Rest Octets


GSM 04.08 §. GSM 08.08 §

8.1.3.4 Paging

8.1.3.4.1 Normal case

Test Purpose

The paging procedure is used to trigger a channel access by a Mobile Station. This procedure is used for Mobile terminating calls and is initiated by the MSC.

NOTE: The PAGING messages from the MSC concern one single Mobile Station, but the PAGING REQUEST messages from the BSS may concern several. The grouping of pagings in the BSS is not specified and is therefore not tested.

Test Case

Initial Setup

An O&M-message as defined by the operator or the manufacturer shall be input on the OMC-interface commanding configuring a certain control channel configuration.

Description

1. 9 PAGING messages, 1 with an IMSI and 8 with a TMSI, for 9 Mobile Stations belonging to the same paging group shall be input on the MSC-interface for a cell relevant to the BSS. The response on any interface shall be recorded.

Message flow

MS BSS MSC PAGING (IMSI) <---------------------------- PAG REQ PAGING (TMSI) <-------------------------- <---------------------------- PAG REQ PAGING (TMSI) <-------------------------- <---------------------------- PAG REQ <-------------------------- The messages from the BSSTE will be:

1. PAGING on the A interface, coded as specified in GSM 08.08 §3.2.1.19 Conformance Requirement

In the case of step 1, PAGING REQUEST messages type 1, 2 or 3 shall occur on the radio interface of the addressed cell on the paging subchannel on the PCH corresponding to the MS. On all other paging subchannels, in the same cell as well as in other cells, fill PAGING REQUEST messages (type of identity = no identity) or other valid Layer 3 messages shall occur on the radio interface.


1. PAGING REQUEST TYPE 1 on the Air interface, coded as specified in GSM 04.08 §9.1.22 1. PAGING REQUEST TYPE 2 on the Air interface, coded as specified GSM 04.08 §9.1.23 1. PAGING REQUEST TYPE 3 on the Air interface, coded as specified GSM 04.08 §9.1.24

Page 98 GSM 11.23 v.4.4.0: May 1996


GSM 04.08 §3.3.2 . GSM 08.08 §3.1.10.

8.1.3.4.2 Paging reorganisation

Test Purpose

The purpose of this test is to check the paging reorganisation procedure.

Initial Setup

The mobile station shall be paged periodically during this test.

Test Case

1. The BSS shall be commanded by a O&M message to change the multi frame number. The response on any interface shall be recorded.

2. After a time tx the O&M change of multi frame number is finished. The response on any interface

shall be recorded. Message flow

MS BSS MSC

(periodical) Paging

<--------------------------------------------------------

Paging Request |

<--------------------------------------------------- |

|

O&M change the multi frame number |

| |

Paging Request | tx |

<--------------------------------------------------- V |

----- |

|

Paging Request |

<--------------------------------------------------- |

V

-----

The messages from the BSSTE will be:

O&M message


In step 1, a Paging request with page mode = paging reorganisation shall occur on the Um-interface.

In step 2, a Paging request with page mode = normal/extended paging shall occur on the Um-interface.


1. Paging request - GSM 04.08, 9.1.22-24 Page mode - paging reorganisation 2. Paging request - GSM 04.08, 9.1.22-24 Page mode - normal/extended paging Requirement reference

GSM 04.08, 3.3.2.1

8.1.3.4.3 Channel needed

Test Purpose

The purpose of this test is to check the transmission of the channel needed element.

Initial Setup

No special requirements

Test Case

1. The MSC shall send a PAGING message with the information element channel needed to the BSS. The response on any interface shall be recorded.

Message flow

MS BSS MSC PAGING <---------------------------- PAGING REQUEST <-------------------------- The messages from the BSSTE will be:

1. Paging - GSM 08.08, 3.2.1.19 Channel needed Conformance Requirements

In step 1, a PAGING REQUEST with the channel needed element shall occur on the Um-interface.

NOTE: If the mobile station receives a PAGING REQUEST TYPE 2 the type of the channel for the mobile station 3 is in the "P2 REST OCTETS"

If the mobile station receives a PAGING REQUEST TYPE 3 the type of the channel for the mobile station 3 and 4 are in the "P3 REST OCTETS"


1. Paging request - GSM 04.08, 9.1.22-24 Channel needed

Page 100 GSM 11.23 v.4.4.0: May 1996


GSM 04.08, 3.3.2.1

8.1.3.5 Measurement reporting

Test Purpose

The measurement report procedure provides the information required by the BSS from the MS in order to perform RF power control and handover decisions. For further information see GSM 04.08 section 3.4.1.2.

NOTE: The procedures for handover and RF power control are national or operator specific matters and are not tested explicitly.

8.1.3.6 Assignment

The purpose of the assignment task is to ensure that the correct dedicated radio resource can be allocated to a Mobile Station that requires it.


Test Purpose

To verify the normal assignment procedure.

Test Case

Initial Setup

A dedicated resource shall be established between the radio interface and the MSC-interface. The resource shall not be a TCH.

O&M-messages as defined by the operator or the manufacturer shall be input on the OMC-interface setting the timer T10 to an appropriate value A, restricting the BSS to choose only one dedicated channel and disabling queuing of assignment requests, if supported.

Description

1. An ASSIGNMENT REQUEST message shall be input on the MSC-interface by the BSSTE requesting a TCH. The response on any interface shall be recorded.

2. After the receipt of the ASSIGNMENT COMMAND message on the radio interface, a LAPDm

SABM frame shall be input on the radio interface on the new main signalling link. The response on any interface shall be recorded.

3. After the receipt of the UA LAPDm frame on the radio interface, the BSSTE inputs an

ASSIGNMENT COMPLETE message on the radio interface on the main signalling link within a time A. The response on any interface shall be recorded.

Message flow

MS BSS MSC ASS REQ <---------------------------- ASS CMD <---------------------------- - SABM | - - - - - - - - - - - - - - > | UA T10 < - - - - - - - - - - - - - - | ASS COM | ----------------------------> - ASS COM ----------------------------> The messages from the BSSTE will be:

1. ASSIGNMENT REQUEST on the A interface, coded as specified in GSM 08.08 §3.2.1.1 Channel type = TCH

2. SABM LAPDm frame on the Air interface, coded as specified in GSM 04.06. 3. ASSIGNMENT COMPLETE on the Air interface, coded as specified: GSM 04.08 §9.1.3 Conformance Requirement

In the case of step 1, an ASSIGNMENT COMMAND message shall occur at the radio interface on the main signalling link. The assigned channel indicated shall correspond to the restrictions set by O&M.

In the case of step 2, a LAPDm UA frame shall occur on the radio interface on the new main signalling link.



1. ASSIGNMENT COMMAND on the Air interface, coded as specified in GSM 04.08 §9.1.2, with Channel Description = TCH

2. UA LAPDm frame on the Air interface, coded as specified in GSM 04.06. 3. ASSIGNMENT COMPLETE on the A interface, coded as specified in GSM 08.08 §3.2.1.2 Requirement reference

GSM 04.08 §3.4.3.1, §3.4.3.2. GSM 08.08 §3.1.1.1.

8.1.3.6.2 T10 expiry

Test Purpose

To verify the assignment procedure in case of T10 expiry.

Page 102 GSM 11.23 v.4.4.0: May 1996

Test Case

Initial Setup


O&M-messages as defined by the operator or the manufacturer shall be input on the OMC-interface setting the timer T10 to an appropriate value A, restricting the BSS to choose only one dedicated channel and disabling queuing of assignment requests, if supported.

Description


2. After the receipt of the ASSIGNMENT COMMAND message on the radio interface, a LAPDm

SABM frame shall be input on the radio interface on the new main signalling link. The response on any interface shall be recorded.

3. After the receipt of the UA LAPDm frame on the radio interface, the BSSTE shall wait expiry of T10

(time A) before sending an ASSIGNMENT COMPLETE message on the radio interface on the main signalling link.

Message flow

MS BSS MSC ASS REQ <---------------------------- ASS CMD <---------------------------- - SABM | - - - - - - - - - - - - - - > | UA T10 < - - - - - - - - - - - - - - | | ASS FAILURE ----------------------------> ASS COM ----------------------------> The messages from the BSSTE will be:


2. SABM LAPDm frame on the Air interface, coded as specified in GSM 04.06. 3. ASSIGNMENT COMPLETE on the Air interface, coded as specified: GSM 04.08 §9.1.3 Conformance Requirement



In the case of step 3, an ASSIGNMENT FAILURE message shall occur at the MSC-interface with the cause value: "radio interface message failure".

NOTE: In step 3, the ASS FAIL message triggers exactly the same function in the MSC as a CLEAR REQ message.



2. UA LAPDm frame on the Air interface, coded as specified in GSM 04.06. 3. ASSIGNMENT FAILURE on the A interface, coded as specified in GSM 08.08 §3.2.1.3, with

Cause = "radio interface message failure"


GSM 04.08 §3.4.3.3. GSM 08.08 §3.1.1.2.

8.1.3.6.3 Terrestrial resources already allocated

Test Purpose

To verify the assignment procedure when the terrestrial resource requested by the MSC is already allocated to another call.

Test Case

Initial Setup

O&M-messages as defined by the operator or the manufacturer shall be input on the OMC-interface restricting the BSS to choose only one dedicated channel and disabling queuing of assignment requests, if supported.

A call shall be established between the MS and the MSC, allocating the terrestrial circuit B.

A second dedicated resource shall be established between the radio interface and the MSC-interface. The resource shall not be a TCH.

Description

1. An ASSIGNMENT REQUEST message shall be input on the MSC-interface by the BSSTE requesting a TCH. The requested terrestrial circuit shall be the circuit B allocated for the established call. The response on any interface shall be recorded.

Message flow

MS BSS MSC ASS REQ <---------------------------- ASS FAILURE ----------------------------> The messages from the BSSTE will be:


Page 104 GSM 11.23 v.4.4.0: May 1996

CIC = B


In the case of step 1, an ASSIGNMENT FAILURE message shall occur at the MSC-interface with the cause value: "terrestrial resource already allocated".


1. ASSIGNMENT FAILURE on the A interface, coded as specified in GSM 08.08 §3.2.1.3 Cause = "terrestrial resource already allocated".


GSM 08.08 §3.1.1.3.

8.1.3.6.4 Reverse to old channel

Test Purpose

To verify the assignment procedure in case of reverse to old channel.

Test Case

Initial Setup



Description


2. After the receipt of the ASSIGNMENT COMMAND message on the radio interface, an

ASSIGNMENT FAILURE message shall be input on the radio interface on the old main signalling link.

Message flow

MS BSS MSC ASS REQ <---------------------------- ASS CMD <---------------------------- ASS FAILURE ----------------------------> ASS FAILURE ----------------------------> The messages from the BSSTE will be:


2. ASSIGNMENT FAILURE on the Air interface, coded as specified: GSM 04.08 §9.1.4 Conformance Requirement:


In the case of step 2, an ASSIGNMENT FAILURE message shall occur at the MSC-interface with the cause value: "radio interface failure, reversion to old channel".



2. ASSIGNMENT FAILURE on the A interface, coded as specified in GSM 08.08 §3.2.1.3, with Cause = "radio interface failure, reversion to old channel"


GSM 04.08 §3.4.3.3. GSM 08.08 §3.1.1.2.

8.1.3.7 External handover as seen from the old BSS

The handover procedure for a BSS where a call is established allows an MS to continue the call in a new BSS. The test in this section concerns the old BSS and covers the procedures defined in GSM 08.08 as:

- handover required indication - handover execution


Test Purpose

To verify the normal external handover procedure.

Test Case

Initial Setup

A call shall be set up between the radio interface and the MSC-interface.

One or two O&M-messages as defined by the operator or the manufacturer shall be input on the OMC-interface setting the thresholds for handover required, and requiring response request.

One or two O&M-messages as defined by the operator or the manufacturer shall be input on the OMC-interface by the BSSTE setting the timer T7 to an appropriate value A and the timer T8 to an appropriate value B.

Description

1. Conditions triggering an external handover decision in the BSS shall be established. The response on any interface shall be recorded.

2. After 3 occurrences of the HANDOVER REQUIRED message on the MSC-interface a HANDOVER

COMMAND shall be input on the MSC-interface. The response on any interface shall be recorded.

Page 106 GSM 11.23 v.4.4.0: May 1996

3. Before the time B has elapsed after the input HANDOVER COMMAND on the MSC-interface the BSSTE shall input a CLEAR COMMAND message with the cause value "handover successful" on the MSC-interface. The response on any interface shall be recorded.

Message flow

MS BSS MSC HAND RQD - ----------------------------> T7 HAND RQD - ----------------------------> HAND RQD ----------------------------> HAND CMD - <---------------------------- HAND CMD | <-------------------------- | T8 CLEAR CMD - <---------------------------- CLEAR COM ----------------------------> The messages from the BSSTE will be:

2. HANDOVER COMMAND on the A interface, coded as specified in GSM 08.08 §3.2.1.11 Layer 3 information = HAND CMD

3. CLEAR COMMAND GSM 08.08 3.2.1.21 Cause = "Handover successful"


In the case of step 1, HANDOVER REQUIRED messages shall occur repeatedly with an interval T7=A on the MSC-interface. The message shall contain the correct cause, and the preferred list of target cells and the radio environment information corresponding to what has been simulated by the BSSTE.

In the case of step 2, no more HANDOVER REQUIRED messages shall occur on the MSC-interface after receiving the HANDOVER COMMAND and a HANDOVER COMMAND message shall occur on the radio interface on the main signalling link.

In the case of step 3, a CLEAR COMPLETE message shall occur on the MSC-interface and the radio resources in the BSS shall be available for use by other calls.


1. HANDOVER REQUIRED on the A interface, coded as specified in GSM 08.08 §3.2.1.9 Response request = yes

2. HANDOVER COMMAND on the Air interface, coded as specified in GSM 04.08 §9.1.15 3. CLEAR COMPLETE on the A interface, coded as specified in GSM 08.08 §3.2.1.22 Requirement reference

GSM 04.08 §3.4.4.1 GSM 08.08 §3.1.5.1, §3.1.5.3

8.1.3.7.2 T8 expiry

Test Purpose

To verify that the old BSS sends a Clear Request at the expiry of T8.

Test Case

Initial Setup




Description



COMMAND shall be input on the MSC-interface. The response on any interface shall be recorded. 3. After the time B has elapsed the response on any interface shall be recorded. Message flow

MS BSS MSC HAND RQD - ----------------------------> T7 HAND RQD - ----------------------------> HAND RQD ----------------------------> HAND CMD - <---------------------------- HAND CMD | <---------------------------- | T8 - CLEAR REQUEST ----------------------------> The messages from the BSSTE will be:




Page 108 GSM 11.23 v.4.4.0: May 1996


In the case of step 3, a CLEAR REQUEST message shall occur on the MSC-interface with the cause value "radio interface message failure".



2. HANDOVER COMMAND on the Air interface, coded as specified in GSM 04.08 §9.1.15 3. CLEAR REQUEST on the A interface, coded as specified in GSM 08.08 §3.2.1.20, with: Cause = "radio interface message failure" Requirement reference

GSM 04.08 §3.4.4 GSM 08.08 §3.1.5.3.3

8.1.3.7.3 Reversion to old channel

Test Purpose

To verify the behaviour of the old BSS when the mobile return on the old channel.

Test Case

Initial Setup




Description



COMMAND shall be input on the MSC-interface. The response on any interface shall be recorded. 3. The BSSTE shall re-establish the main signalling link and input a HANDOVER FAILURE message

on the radio interface. The response on any interface shall be recorded.

Message flow

MS BSS MSC HAND RQD - ----------------------------> T7 HAND RQD - ----------------------------> HAND RQD ----------------------------> HAND CMD <---------------------------- HAND CMD <---------------------------- HAND FAILURE ---------------------------> HAND FAILURE ----------------------------> The messages from the BSSTE will be:


3. HANDOVER FAILURE on the Air interface, coded as specified in GSM 04.08 §9.1.17 with

RR cause = PAR1 Conformance Requirement



In the case of step 3, a HANDOVER FAILURE message shall occur on the MSC-interface with the cause value "radio interface failure, reversion to old channel". It is recommended to include the air interface RR cause element (PAR1) in this message.



2. HANDOVER COMMAND on the Air interface, coded as specified in GSM 04.08 §9.1.15 3. HANDOVER FAILURE on the A interface, coded as specified in GSM 08.08 §3.2.1.16, with

Cause = "radio interface failure, reversion to old channel" RR cause = PAR1 (optional)


GSM 04.08 §3.4.4.4 GSM 08.08 §3.1.5.3.2

8.1.3.8 External handover as seen from the new BSS

8.1.3.8.1 Non-synchronised network

This procedure allows the MSC to request resources from a BSS in a manner similar to that used for the assignment case and terminates the handover seen from the MS. It is used during handover with the new

Page 110 GSM 11.23 v.4.4.0: May 1996

BSS for allocation of the necessary resources before the MS accesses the BSS and covers the following procedures:

- handover resource allocation, defined in GSM 08.08 - physical channel establishment, defined in GSM 04.08 - handover completion, defined in GSM 04.08 8.1.3.8.1.1 Normal Case

Test Purpose

To verify the normal external handover procedure.

Test Case

Initial Setup

O&M-messages as defined by the operator or the manufacturer shall be input on the OMC-interface setting the timer T3105 to an appropriate value B, the parameter Ny1 to an appropriate value C, restricting the BSS to choose only one dedicated channel and disabling queuing on handover requests, if supported.

Description

1. A HANDOVER REQUEST message shall be input on the MSC-interface. The message shall contain an indication of the type of channel needed and the terrestrial resource to be used. The channel shall be a TCH and the terrestrial resource to be used shall be A. The response on any interface shall be recorded.

2. HANDOVER ACCESS messages shall be input continuously on the radio interface on the correct

physical channel with the same handover reference number (PAR1) as in the HANDOVER REQUEST ACKNOWLEDGE message output in step 1. The response on any interface shall be recorded.

3. LAPDm SABM frame shall be input on the radio interface on the main signalling link before the time

C x B. The response on any interface shall be recorded. 4. A HANDOVER COMPLETE message shall be input on the radio interface on the main signalling

link. The response on any interface shall be recorded.

Message flow

MS BSS MSC HAND REQ <---------------------------- HAND REQ ACK ----------------------------> HAND ACC ----------------------------> HAND ACC ----------------------------> . . PHYS INFO HAND DET <---------------------------*---------------------------> PHYS INFO T3105 <---------------------------- - . . Ny1 PHYS INFO <---------------------------- SABM - - - - - - - - - - - - - - > UA < - - - - - - - - - - - - - - HAND COM ----------------------------> HAND COM ----------------------------> The messages from the BSSTE will be:

1. HANDOVER REQUEST on the A interface, coded as specified in GSM 08.08 §3.2.1.8, with Channel type = TCH Circuit identity code = A

2. HANDOVER ACCESS on the Air interface, coded as specified in GSM 04.08 §9.1.14, with

Handover reference = PAR1 3. SABM LAPDm frame on the Air interface, coded as specified in GSM 04.06. 4. HANDOVER COMPLETE on the Air interface, coded as specified in GSM 04.08 §9.1.16 Conformance Requirement

In the case of step 1, a HANDOVER REQUEST ACKNOWLEDGE message shall occur at the MSC-interface. No messages shall occur on the radio interface.

In the case of step 2, a HANDOVER DETECT message shall occur on the MSC-interface and PHYSICAL INFORMATION messages shall occur on the radio interface on the main signalling link with an interval of B.

In the case of step 3, a LAPDm UA frame shall occur on the radio interface on the main signalling link.

In the case of step 4, a HANDOVER COMPLETE message shall occur on the MSC-interface.


Page 112 GSM 11.23 v.4.4.0: May 1996

1. HANDOVER REQUEST ACKNOWLEDGE on the A interface, coded as specified in GSM 08.08 §3.2.1.10, with Layer 3 information = HAND CMD (as in GSM 04.08 9.1.15)

2. HANDOVER DETECT on the A interface, coded as specified in GSM 08.08 §3.2.1.40 2. PHYSICAL INFORMATION on the Air interface, coded as specified in GSM 04.08 §9.1.28 3. UA LAPDm frame on the Air interface, coded as specified in GSM 04.06. 4. HANDOVER COMPLETE on the A interface, coded as specified in GSM 08.08 §3.2.1.12 Requirement reference

GSM 04.08 §3.4.4.2.2, §3.4.4.3 GSM 08.08 §3.1.5.2.1

8.1.3.8.1.2 No LAPDm connection

Test Purpose

To verify the external handover procedure when the mobile does not send a SABM LAPDm frame.

Test Case

Initial Setup


Description


2. HANDOVER ACCESS messages shall be input on the radio interface on the correct physical

channel with the same handover reference number (PAR1) as in the HANDOVER REQUEST ACKNOWLEDGE message output in step 1. The response on any interface shall be recorded. No further messages shall be input.

Message flow

MS BSS MSC HAND REQ <---------------------------- HAND REQ ACK ----------------------------> HAND ACC ----------------------------> HAND ACC ----------------------------> . . PHYS INFO HAND DET <---------------------------*---------------------------> PHYS INFO T3105 <---------------------------- - . . Ny1 PHYS INFO <---------------------------- CLEAR REQUEST ----------------------------> The messages from the BSSTE will be:



Handover reference = PAR1 Conformance Requirement


In the case of step 2, a HANDOVER DETECT message shall occur on the MSC-interface and C+1 PHYSICAL INFORMATION messages shall occur on the radio interface on the main signalling link with an interval of B. Then, a CLEAR REQUEST message shall occur on the MSC-interface with the cause value "radio interface message failure".



2. HANDOVER DETECT on the A interface, coded as specified in GSM 08.08 §3.2.1.40 2. PHYSICAL INFORMATION on the Air interface, coded as specified in GSM 04.08 §9.1.28 2. CLEAR REQUEST on the A interface, coded as specified in GSM 08.08. §3.2.1.20 Requirement reference

GSM 04.08 §3.4.4.2.2, §3.4.4.4 GSM 08.08 §3.1.5.3.1

Page 114 GSM 11.23 v.4.4.0: May 1996

8.1.3.8.1.3 Wrong Handover Reference

Test Purpose

To verify the external handover procedure when the mobile sends a wrong Handover Reference in the HANDOVER ACCESS message.

Test Case

Initial Setup


Description


2. HANDOVER ACCESS messages shall be input on the radio interface on the correct physical

channel with a different handover reference number (PAR1) than the one sent in the HANDOVER REQUEST ACKNOWLEDGE message output in step 1. The response on any interface shall be recorded.

Message flow

MS BSS MSC HAND REQ <---------------------------- HAND REQ ACK ----------------------------> HAND ACC ----------------------------> HAND ACC ----------------------------> The messages from the BSSTE will be:



Handover reference = PAR2 Conformance Requirement


In the case of step 2, the BSS shall ignore the incoming HANDOVER ACCESS messages and no messages shall occur on any interface.




GSM 04.08 §3.4.4.2.2 GSM 08.08 §3.1.5.2.1, §3.1.5.3.1

8.1.3.8.1.4 Wrong physical channel

Test Purpose

To verify the external handover procedure when the mobile sends the HANDOVER ACCESS message on a wrong physical channel.

Test Case

Initial Setup


Description


2. HANDOVER ACCESS messages shall be input on the radio interface, but on the wrong physical

channel according to the HANDOVER REQUEST ACKNOWLEDGE message output in step 1. The response on any interface shall be recorded. No further messages shall be input.

Message flow

MS BSS MSC HAND REQ <---------------------------- HAND REQ ACK ----------------------------> HAND ACC ----------------------------> HAND ACC ----------------------------> The messages from the BSSTE will be:


2. HANDOVER ACCESS on the Air interface, coded as specified in GSM 04.08 §9.1.14



Page 116 GSM 11.23 v.4.4.0: May 1996

In the case of step 2, no message shall occur on any interface.


1. HANDOVER REQUEST ACKNOWLEDGE on the A interface, coded as specified in GSM 08.08 §3.2.1.10, with Layer 3 information = HAND CMD (as in GSM 04.08 §9.1.15)


GSM 04.08 §3.4.4.4 GSM 08.08 §3.1.5.2.1

8.1.3.8.1.5 No radio resources available

Test Purpose

To verify the external handover procedure when there are no radio resources available.

Test Case

Initial Setup

O&M-messages as defined by the operator or the manufacturer shall be input on the OMC-interface restricting the BSS to choose only one dedicated channel and disabling queuing on handover requests, if supported.

An O&M-message as defined by the operator or the manufacturer shall be input on the OMC-interface commanding the BSS to put all TCHs out of service.

Description


Message flow

MS BSS MSC HAND REQ <---------------------------- HAND FAILURE ----------------------------> The messages from the BSSTE will be:



In the case of step 1, a HANDOVER FAILURE message shall occur on the MSC-interface with the cause value: "No radio resource available".


1. HANDOVER FAILURE on the A interface, coded as specified in GSM 08.08 §3.2.1.16 Cause = "No radio resource available"


GSM 08.08 §3.1.5.2.2

8.1.3.8.1.6 Clear Command from the MSC

Test Purpose

To verify the external handover procedure when the MSC sends a CLEAR COMMAND before the mobile has completed the handover.

Test Case

Initial Setup


Description


2. After the HANDOVER REQUEST ACKNOWLEDGE message from the BSS, a CLEAR COMMAND

message with the cause value "call control" shall be input on the MSC-interface. The response on any interface shall be recorded.

Message flow

MS BSS MSC HAND REQ <---------------------------- HAND REQ ACK ----------------------------> CLEAR COMMAND <---------------------------- CLEAR COMPLETE ----------------------------> The messages from the BSSTE will be:


2. CLEAR COMMAND on the A interface, coded as specified in GSM 08.08 §3.2.1.21

Cause = as in text Conformance Requirement


Page 118 GSM 11.23 v.4.4.0: May 1996

In the case of step 2, a CLEAR COMPLETE message shall occur on the MSC-interface.


1. HANDOVER REQUEST ACKNOWLEDGE on the A interface, coded as specified in GSM 08.08 §3.2.1.10, with Layer 3 information = HAND CMD (as in GSM 04.08 §9.1.15)

2. CLEAR COMPLETE on the A interface, coded as specified in GSM 08.08 §3.2.1.22 Requirement reference

GSM 08.08 §3.1.5.3.1, §3.1.5.3.2

8.1.3.8.1.7 No terrestrial resource available.

Test Purpose

To verify the external handover procedure when there are no terrestrial resources available.

Test Case

Initial Setup

O&M-messages as defined by the operator or the manufacturer shall be input on the OMC-interface restricting the BSS to choose only one dedicated channel and disabling queuing on handover requests, if supported.

An O&M-message as defined by the operator or the manufacturer shall be input on the OMC-interface commanding the BSS to block the terrestrial resource A.

Description


Message flow

MS BSS MSC HAND REQ <---------------------------- HAND FAILURE ----------------------------> BLOCK ----------------------------> The messages from the BSSTE will be:



In the case of step 1, a HANDOVER FAILURE message shall occur on the MSC-interface with the cause value: " Requested terrestrial resource unavailable". A single global BLOCK message shall be sent for that concerned terrestrial circuit.


1. HANDOVER FAILURE on the A interface, coded as specified in GSM 08.08 §3.2.1.16 Cause = " Requested terrestrial resource unavailable"

1. BLOCK on the A-interface, coded as specified in GSM 08.08 §3.2.1.4 CIC = A Cause = "Requested terrestrial resource unavailable"


GSM 08.08 §3.1.2.2, §3.1.5.2.3

8.1.3.8.1.8 Handover - CLM2

Test Purpose

Before a MSC controlled Handover is started the MSC gets the Classmark Information from the MS proceeding the Classmark Interrogation Procedure. The HANDOVER REQUEST message is sent by the MSC with "Classmark Information 2 " element and a different encryption algorithm. The BSS shall choose the appropriate algorithm and inform the MSC about the selection.

Initial Setup

Set up a dedicated resource between Um-interface and A-interface and proceed the Classmark Interrogation procedure.

Test Case

1. The BSSTE sends a HANDOVER REQUEST message on the A-interface. The response on any interface shall be recorded.

MS BSS MSC HANDOVER REQ <---------------------------- HANDOVER REQUEST ACK ----------------------------> The messages from the BSSTE will be:

1. HANDOVER REQUEST - GSM 08.08, 3.2.1.8 Encryption information Classmark information 2 Conformance Requirements

In case of step 1, a HANDOVER REQUEST ACKNOWLEDGE message shall occur on the A-interface


1. HANDOVER REQUEST ACKNOWLEDGE - GSM 08.08, 3.2.1.10 Chosen encryption algorithm Requirement reference

GSM 04.08 §3.4.4 GSM 08.08 §3.1.5

Page 120 GSM 11.23 v.4.4.0: May 1996

8.1.3.8.1.9 Handover - CLM2 and CLM3

Test Purpose

Before a MSC controlled Handover is started the MSC gets the Classmark Information from the MS proceeding the Classmark Interrogation Procedure. The HANDOVER REQUEST message is sent by the MSC with "Classmark Information 2" and "Classmark Information 3" element and a different encryption algorithm. The BSS shall choose the appropriate algorithm and inform the MSC about the selection.

Initial Setup

Set up a dedicated resource between Um-interface and A-interface and proceed the Classmark Interrogation procedure.

Test Case

1. The BSSTE sends a HANDOVER REQUEST message on the A-interface. The response on any interface shall be recorded.

MS BSS MSC HANDOVER REQ <---------------------------- HANDOVER REQUEST ACK ----------------------------> The messages from the BSSTE will be:

1. HANDOVER REQUEST - GSM 08.08, 3.2.1.8 Encryption information Classmark information 2 Classmark information 3 Conformance Requirements

In case of step 1, a HANDOVER REQUEST ACKNOWLEDGE message shall occur on the A-interface


1. HANDOVER REQUEST ACKNOWLEDGE - GSM 08.08, 3.2.1.10 Chosen encryption algorithm Requirement reference

GSM 04.08 §3.4.4

GSM 08.08 §3.1.5

8.1.3.8.2 Synchronised network

Test Purpose

NOTE: All test specified for the Non-synchronised case also apply for Synchronised, Pseudo-synchronised and Pre- synchronised Networks.

However, it should be mentioned that only 4 Handover Access Information messages will be transmitted by the BSSTE and that no Physical Information messages will be transmitted by the BTS.

For further information see

GSM 04.08 - chapter 3.4.4.2.1 - Synchronised Networks GSM 04.08 - chapter 3.4.4.2.3 - Pseudo-synchronised Networks GSM 04.08 - chapter 3.4.4.2.4 - Pre-synchronized Networks

8.1.3.9 Internal handover

8.1.3.9.1 Internal inter-cell handover

Internal inter-cell handover occurs between channels pertaining to different cells of the same BSS. It only applies to multi-cell BSSs.

The use of this handover mechanism is optional for the GSM PLMN operator. However, if used, conformance to this test is mandatory.

The MSC may also invoke an internal inter-cell handover procedure. However, in that case the procedure is as for external handover.

Concerning synchronized or non-synchronized networks, the same applies to internal inter-cell handover as for external handover.

8.1.3.9.1.1 Normal case

Test Purpose

To verify the normal internal handover procedure.

Test Case

Initial Setup

O&M-messages as defined by the operator or the manufacturer shall be input on the OMC-interface setting the timer T3105 to an appropriate value B, the timer T8 to an appropriate value D, the parameter Ny1 to an appropriate value C, restricting the BSS to choose only one dedicated channel and commanding that the handover procedure will be controlled by the BSS.

A call shall be set up on a TCH between the radio interface and the MSC-interface.

Description

1. Conditions triggering an inter-cell handover decision in the BSS shall be established. The conditions are up to the operator and the manufacturer. The response on any interface shall be recorded.

2. HANDOVER ACCESS messages shall be input on the radio interface (of the new cell) on the main

signalling link. The response on any interface shall be recorded. 3. A LAPDm SABM frame shall be input on the radio interface (of the new cell) on the main signalling

link within a time B x C. The response on any interface shall be recorded. 4. Following immediately after step 3, a HANDOVER COMPLETE message shall be input on the radio

interface on the main signalling link (of the new cell). The response on any interface shall be recorded.

Page 122 GSM 11.23 v.4.4.0: May 1996

Message flow

MS BSS MSC HAND CMD <---------------------------- - HAND ACC | ----------------------------> | HAND ACC | ----------------------------> | . | . | PHYS INFO | <---------------------------- - | PHYS INFO T3105 | <---------------------------- - | . | T8 Ny1 | PHYS INFO | <---------------------------- | SABM | - - - - - - - - - - - - - - > | UA | < - - - - - - - - - - - - - - | HAND COM | ----------------------------> - HAND PERF ----------------------------> The messages from the BSSTE will be:

2. HANDOVER ACCESS on the Air interface, coded as specified in GSM 04.08 §9.1.14 Handover reference = PAR1

3. A SABM LAPDm frame on the Air interface, coded as specified in GSM 04.06. 4. A HANDOVER COMPLETE message on the Air interface, coded as specified in GSM 04.08

§9.1.16. Conformance Requirement

In the case of step 1, a HANDOVER COMMAND message shall occur on the radio interface (of the old cell) on the main signalling link.

In the case of step 2, a PHYSICAL INFORMATION message shall occur on the radio interface (of the new cell) on the main signalling link and repeatedly C times with an interval of B.

In the case of step 3, a LAPDm UA frame shall occur on the radio interface (of the new cell) on the main signalling link.

In the case of step 4, a HANDOVER PERFORMED message with an appropriate cause value shall occur on the MSC-interface.


1. HANDOVER COMMAND on the Air interface, coded as specified in GSM 04.08 §9.1.15 Handover reference = PAR1

2. PHYSICAL INFORMATION on the Air interface, coded as specified in GSM 04.08 §9.1.28 3. A UA LAPDm frame on the Air interface, coded as specified in GSM 04.06.

4. HANDOVER PERFORMED on the A interface, coded as specified in GSM 08.08 §3.2.1.25 Requirement reference

GSM 04.08 §3.4.4 GSM 08.08 §3.1.7

8.1.3.9.1.2 No LAPDm connection

Test Purpose

To verify the internal handover procedure when the MS does not establish the LAPDm on the signalling link.

Test Case

Initial Setup

O&M-messages as defined by the operator or the manufacturer shall be input on the OMC-interface setting the timer T3105 to an appropriate value B, the timer T8 to an appropriate value D, the parameter Ny1 to an appropriate value C, and restricting the BSS to choose only one dedicated channel and commanding the BSS to control the handover procedure.

A call shall be set up on a TCH between the radio interface and the MSC-interface.

Description

1. Conditions triggering an inter-cell handover decision in the BSS shall be established. The conditions are up to the operator and the manufacturer. The response on any interface shall be recorded.

2. HANDOVER ACCESS messages shall be input on the radio interface (of the new cell) on the main

signalling link. The response on any interface shall be recorded. Message flow

MS BSS MSC HAND CMD <---------------------------- - HAND ACC | ----------------------------> | HAND ACC | ----------------------------> | . | . | PHYS INFO | <---------------------------- - | PHYS INFO T3105 | <---------------------------- - | . | T8 . | Ny1 | PHYS INFO | <---------------------------- | CLEAR REQUEST ----------------------------> The messages from the BSSTE will be:

Page 124 GSM 11.23 v.4.4.0: May 1996

2. HANDOVER ACCESS on the Air interface, coded as specified in GSM 04.08 §9.1.14 Handover reference = PAR1


In the case of step 1, a HANDOVER COMMAND message shall occur on the radio interface (of the old cell) on the main signalling link.

In the case of step 2, a PHYSICAL INFORMATION message shall occur on the radio interface (of the new cell) on the main signalling link and repeatedly C times with an interval of B. After the expiry of T8 or Ny1 times T3105 (B x C) a CLEAR REQUEST message concerning the old channel or the new channel, respectively, shall occur on the MSC-interface with the cause value: "Radio interface message failure".



2. PHYSICAL INFORMATION on the Air interface, coded as specified in GSM 04.08 §9.1.28 CLEAR REQUEST on the A interface, coded as specified in GSM 08.08 §3.2.1.20

Cause = "Radio interface message failure" Requirement reference

GSM 04.08 §3.4.4 GSM 08.08 §3.1.7, §3.1.5.3.3

8.1.3.9.2 Internal intra-cell handover

The use of this handover mechanism is optional for the GSM PLMN operator. However, if used, conformance to this test is mandatory.

Definition

The internal intra-cell handover procedure is used when a BSS for which ever internal reason decides to change the channel on which it communicates with an MS. In principle, internal intra-cell handover may be carried out in 2 ways:

1. As an assignment procedure 2. As a handover procedure The choice of procedure is left to the manufacturer or the operator. The MSC may also invoke an internal intra-cell handover procedure. However, in that case the procedure is as for external handover.

8.1.3.9.2.1. Intra-cell handover by the assignment procedure

8.1.3.9.2.1.1 Normal case

Test Purpose

To verify the normal intra-cell by assignment procedure.

Test Case

Initial Setup

A call shall be set up on a TCH between the radio interface and the MSC-interface, and O&M-messages as defined by the operator or the manufacturer shall be input on the OMC-interface setting the timer T10 to an appropriate value A and restricting the BSS to choose only one dedicated channel.

Description

1. Conditions triggering an internal intra-cell handover decision in the BSS shall be established. The conditions are up to the operator and the manufacturer. The response on any interface shall be recorded.

2. A LAPDm SABM frame shall be input on the radio interface on the new main signalling link within a

time T10. The response on any interface shall be recorded. 3. An ASSIGNMENT COMPLETE message shall be input on the radio interface on the new main

signalling link also before the time T10. The response on any interface shall be recorded. Message flow

MS BSS MSC ASS CMD <---------------------------- - SABM | - - - - - - - - - - - - - - > | UA | T10 < - - - - - - - - - - - - - - | ASS COM | ----------------------------> - HAND PERF ----------------------------> The messages from the BSSTE will be:

2. A SABM LAPDm frame on the Air interface, coded as specified in GSM 04.06. 3. A ASSIGNMENT COMPLETE on the Air interface, coded as specified in GSM 04.08 §9.1.2 Conformance Requirement

In the case of step 1, an ASSIGNMENT COMMAND message shall occur on the radio interface on the main signalling link.


In the case of step 3, a HANDOVER PERFORMED message shall occur on the MSC-interface with an appropriate cause value.



2. A UA LAPDm frame on the Air interface, coded as specified in GSM 04.06. 3. HANDOVER PERFORMED on the A interface, coded as specified in GSM 08.08 §3.2.1.25 Requirement reference:

GSM 04.08 §3.4.3 GSM 08.08 §3.1.6

Page 126 GSM 11.23 v.4.4.0: May 1996

8.1.3.9.2.1.2 T10 expiry

Test Purpose

To verify the intra-cell by assignment procedure when the mobile does not connect the new TCH within T10.

Test Case

Initial Setup


Description

1. Conditions triggering an internal intra-cell handover decision in the BSS shall be established. The conditions are up to the operator and the manufacturer. No further messages shall be input. The response on any interface shall be recorded.

2. A LAPDm I frame shall be input on the radio interface on the new main signalling link. The response

on any interface shall be recorded. Message flow

MS BSS MSC ASS CMD <---------------------------- - | T10 | - CLEAR REQUEST ------------------------------> The messages from the BSSTE will be:

2. I LAPDm frame on the Air interface. Conformance Requirement

In the case of step 1, an ASSIGNMENT COMMAND message shall occur on the radio interface on the main signalling link. Then, after the expiry of T10, a CLEAR REQUEST message shall occur on the MSC-interface with the cause value: "radio interface message failure".




CLEAR REQUEST on the A interface, coded as specified in GSM 04.08 §3.2.1.20, with cause = as in text Requirement reference

GSM 04.08 §3.4.3 GSM 08.08 §3.1.6

8.1.3.9.2.1.3 Reverse to old channel

Test Purpose

To verify the intra-cell by assignment procedure when the mobile returns to the old channel.

Test Case

Initial Setup


Description


2. A LAPDm SABM frame shall be input on the radio interface on the old main signalling link within a

time T10. The response on any interface shall be recorded. 3. An ASSIGNMENT FAILURE message with an appropriate cause value shall be input on the radio

interface on the old main signalling link also before the time T10. The response on any interface shall be recorded.

Message flow

MS BSS MSC ASS CMD <---------------------------- - SABM | - - - - - - - - - - - - - - > | UA | T10 < - - - - - - - - - - - - - - | ASS FAIL | ----------------------------> - The messages from the BSSTE will be:

2. A SABM LAPDm frame on the Air interface, coded as specified in GSM 04.06. 3. ASSIGNMENT FAILURE on the Air interface, coded as specified in GSM 04.08 §3.2.1.3 Conformance Requirement

In the case of step 1, an ASSIGNMENT COMMAND message shall occur on the radio interface on the main signalling link.

In the case of step 2, a LAPDm UA frame shall occur on the radio interface on the old main signalling link.




Page 128 GSM 11.23 v.4.4.0: May 1996

2. A UA LAPDm frame on the Air interface, coded as specified in GSM 04.06. Requirement reference

GSM 04.08 §3.4.3. GSM 08.08 §3.1.6

8.1.3.9.2.1.4 CLM2

Test Purpose

When the MSC sends an ASSIGNMENT REQUEST with Classmark Information Type 2 the BSS has to answer with an ASSIGNMENT COMPLETE containing the chosen algorithm.

Initial Setup

A dedicated resource shall be set up between Um-interface and A-interface

Test Case

1. The BSSTE sends a ASSIGNMENT REQUEST message on the A-interface. The response on any interface shall be recorded.

2. The BSSTE sends a ASSIGNMENT COMPLETE message including "chosen encryption algorithm"

information element. The response on any interface shall be recorded. Message flow

MS BSS MSC ASSIGNMENT REQUEST <------------------------------ ASSIGNMENT COMMAND <---------------------------- ASSIGNMENT COMPLETE ----------------------------> ASSIGNMENT COMPLETE ------------------------------> The messages from the BSSTE will be:

1. ASSIGNMENT REQUEST - GSM 08.08, 3.2.1.1 Layer 3 header information Classmark information 2 2. ASSIGNMENT COMPLETE - GSM 04.08, 9.1.3 Conformance Requirements

In case of step 1, a ASSIGNMENT COMMAND message shall occur on the Um-interface.

In case of step 2, a ASSIGNMENT COMPLETE message shall occur on the A-interface


1. ASSIGNMENT COMMAND - GSM 04.08, 9.1.2 Cipher mode setting 2. ASSIGNMENT COMPLETE - GSM 08.08, 3.2.1.2 Chosen encryption algorithm


GSM 04.08 §3.4.3

GSM 08.08 §3.1.1

8.1.3.9.2.2 Intra-cell handover by the handover procedure

8.1.3.9.2.2.1 Normal case

Test Purpose

To verify the normal intra-cell handover by handover procedure.

Test Case

Initial Setup


Description


2. 4 HANDOVER ACCESS messages shall be input on the radio interface on the new main signalling

link, followed by a LAPDm SABM frame within a time T8. The response on any interface shall be recorded.

3. An HANDOVER COMPLETE message shall be input on the radio interface on the new main

signalling link also before the expiry of T8. The response on any interface shall be recorded. Message flow

MS BSS MSC HAND CMD <---------------------------- - HAND ACC | ----------------------------> | HAND ACC | ----------------------------> | HAND ACC | ----------------------------> | HAND ACC | T8 ----------------------------> | SABM | - - - - - - - - - - - - - - > | UA | < - - - - - - - - - - - - - - | HAND COM | ----------------------------> - HAND PERF ----------------------------> The messages from the BSSTE will be:

Page 130 GSM 11.23 v.4.4.0: May 1996

2. HANDOVER ACCESS on the Air interface, coded as specified in GSM 04.08 §9.1.14, with Handover reference = PAR1

SABM LAPDm frame on the Air interface, coded as specified in GSM 04.06. 3. HANDOVER COMPLETE on the Air interface, coded as specified in GSM 04.08 §9.1.16 Conformance Requirement

In the case of step 1, a HANDOVER COMMAND message shall occur on the radio interface on the main signalling link.


In the case of step 3, a HANDOVER PERFORMED message shall occur on the MSC-interface with an appropriate cause value.



2 UA LAPDm frame on the Air interface, coded as specified in GSM 04.06. 3. HANDOVER PERFORMED on the A interface, coded as specified in GSM 08.08 §3.2.1.25 Requirement reference

GSM 04.08 §3.4.4 GSM 08.08 §3.1.6

8.1.3.9.2.2.2 T8 expiry

Test Purpose

To verify the intra-cell handover by handover procedure when the mobile does not connect the new TCH within T8.

Test Case

Initial Setup


Description

1. Conditions triggering an internal intra-cell handover decision in the BSS shall be established. The conditions are up to the operator and the manufacturer. No further messages shall be input. The response on any interface shall be recorded.

2. A LAPDm I frame shall be input on the radio interface on the new main signalling link. The response

on any interface shall be recorded.

Message flow

MS BSS MSC HAND CMD <---------------------------- - | | T8 | - CLEAR REQ ----------------------------> The messages from the BSSTE will be:

2. A I LAPDm frame on the Air interface. Conformance Requirement

In the case of step 1, a HANDOVER COMMAND message shall occur on the radio interface on the main signalling link. Then, after the expiry of T8, a CLEAR REQUEST message shall occur on the MSC-interface with the cause value: "radio interface message failure".




CLEAR REQUEST on the A interface, coded as specified in GSM 08.08 §3.2.1.20, with Cause = "radio interface message failure"


GSM 04.08 §3.4.4 GSM 08.08 §3.1.6

8.1.3.9.2.2.3 Reverse to old channel

Test Purpose

To verify the intra-cell handover by handover procedure when the mobile return to the old channel.

Test Case

Initial Setup


Description


2. LAPDm SABM frame shall be input on the radio interface on the old main signalling link within a

time T8. The response on any interface shall be recorded.

Page 132 GSM 11.23 v.4.4.0: May 1996

3. A HANDOVER FAILURE message with an appropriate cause value shall be input on the radio interface on the old main signalling link also before the expiry of T8. The response on any interface shall be recorded.

Message flow

MS BSS MSC HAND CMD <---------------------------- - SABM | - - - - - - - - - - - - - - > | UA | < - - - - - - - - - - - - - - | HAND FAIL | ----------------------------> - The messages from the BSSTE will be:

2. SABM LAPDm frame on the Air interface, coded as specified in GSM 04.06. 3. HANDOVER FAILURE on the Air interface, coded as specified in GSM 08.08 §3.2.1.16, with

Cause = "Reverse to old channel" Conformance Requirement

In the case of step 1, a HANDOVER COMMAND message shall occur on the radio interface on the main signalling link.

In the case of step 2, a LAPDm UA frame shall occur on the radio interface on the old main signalling link.




2 UA LAPDm frame on the Air interface, coded as specified in GSM 04.06. Requirement reference

GSM 04.08 §3.4.4 GSM 08.08 §3.1.6

8.1.3.10 Frequency redefinition

Test Purpose

The frequency redefinition procedure enables the BSS to change the frequencies and hopping sequences of the allocated channels. The procedure is used only in a BSS using Slow Frequency Hopping (SFH).

Test Case

Initial Setup

A call shall be established between the radio interface and the MSC-interface. SFH shall be enabled, if supported.

Description

1. The BSSTE shall request the BSS to redefine the hopping sequences using the O&M message as defined by the operator or the manufacturer on the OMC-interface. The response on any interface shall be recorded.

Message flow

MS BSS MSC O&M FREQ REDEF <---------------------------- The messages from the BSSTE will be:

1. O&M MESSAGES Conformance Requirement

In the case of step 1, a FREQUENCY REDEFINITION message shall occur on the radio interface. The frequency list and hopping sequences of the message shall correspond to the new parameters commanded from O&M.

The messages from the BSS shall be

1. FREQUENCY REDEFINION on the Air interface, coded as specified: GSM 04.08 9.1.13 Requirement reference

GSM 04.08 §3.4.5

8.1.3.11 Transmission mode change

Test Purpose

To verify the transmission mode change procedure which allows the network to request the Mobile Station to modify the transmission mode (channel coding, transcoding/rate adaptation) for a dedicated channel.

NOTE : In GSM 08.08 there are no defined cases for when the CHANNEL MODE MODIFY message shall be applied. The message is restricted to being mapped to ASSIGNMENT REQUEST messages on the A-interface, and it is a national or operator specific matter to define the cases when this mapping shall occur (e.g. when the needed RF channel or full/half-rate channel is the same, but with a different transcoding or rate adaptation). This test applies when such a mapping exists. Possibly the modes may be different.

Test Case

Initial Setup

The assignment procedure in section 8.1.3.6 shall first be performed with a full-rate data traffic channel using 9.6 kbit/s (TCH/F9.6).

Description

1. An ASSIGNMENT REQUEST message shall be input on the MSC-interface by the BSSTE assigning a full-rate data TCH using 4.8 kbit/s (TCH/F4.8) to the same Mobile Station. The response on any interface shall be recorded.

Page 134 GSM 11.23 v.4.4.0: May 1996

2. After the receipt of a CHANNEL MODE MODIFY message on the radio interface, the BSSTE shall input a CHANNEL MODE MODIFY ACKNOWLEDGE message on the radio interface on the main signalling link. The response on any interface shall be recorded.

NOTE: The abnormal cases are considered tested by the normal assignment procedure in

section 8.1.3.6;

Message flow

MS BSS MSC ASS REQ (Channel type = TCH/F4.8) <---------------------------- CH MODE MOD <----------------------------- CH MODE MOD ACK (Channel mode = TCH/F4.8) -----------------------------> ASS COM ----------------------------> The messages from the BSSTE will be

1 ASSIGNMENT REQUEST , coded as specified in GSM 08.08 §3.2.1.1 Channel type = TCH/F4.8 2 CHANNEL MODE MODIFY ACK , coded as specified in GSM 04.08 §9.1.6 Channel type = TCH/F4.8 Conformance Requirements

In step 1, a CHANNEL MODE MODIFY message shall occur at the radio interface on the main signalling link requesting the TCH/F4.8.

In step 2, an ASSIGNMENT COMPLETE message shall occur on the MSC-interface.


1. CHANNEL MODE MODIFY, coded as specified in GSM 04.08 §9.1.5, with Channel mode = TCH/F4.8.

2. ASSIGNMENT COMPLETE, coded as specified in GSM 08.08 §3.2.1.2 Requirement reference

GSM 04.08 §3.4.6. GSM 08.08 §3.1.1.

8.1.3.12 Ciphering mode setting

NOTE: The purpose of the ciphermode control procedure is, after authentication, to initialise and synchronise the stream ciphering devices in the MS and BSS. The MS and the MSC know already from the authentication procedure the cipher key Kc, and in this procedure this key is passed to the BSS.

Any failure during the ciphermode control procedure will be regarded as a lower layer failure and will therefore not be tested explicitly.

8.1.3.12.1 Cipher Mode Complete

Test Purpose

To verify the ciphering mode setting procedure, the procedure is completed by a Cipher Mode Complete message from the Mobile Station.

Test Case

Initial Setup

A dedicated resource shall be established between the radio interface and the MSC-interface. Ciphering shall not be activated.

Description

1. A CIPHER MODE COMMAND message shall be input on the MSC-interface containing the Algorithm identifier octet set to ’GSM user data encryption version 1’ and the key Kc in the Encryption information element as specified in GSM 08.08 §3.2.2.10. The response on any interface shall be recorded.

2. At the reception on the Air interface of the message CIPHERING MODE COMMAND, the BSSTE

shall start deciphering and enciphering on the radio interface and then input a CIPHERING MODE COMPLETE message on the radio interface on the main signalling link. The response on any interface shall be recorded.

3. The BSSTE shall input any arbitrary DTAP message on the MSC-interface. The response on any

interface shall be recorded. Message flow

MS BSS MSC CIPHER MODE CMD <---------------------------- CIPH MODE CMD <---------------------------- start deciphering BSS Layer 2 frame ----------------------------> start enciphering BSS CIPH MODE COM ----------------------------> CIPHER MODE COM ----------------------------> DTAP message <-------------------------------------------------------- The messages from the BSSTE will be:

1. CIPHER MODE COMMAND on the a interface, coded as specified in GSM 08.08 §3.2.1.30, with in the Encryption Information Algorithm identifier = 'GSM user data encryption version 1' Key Kc.

2. CIPHERING MODE COMPLETE on the Air interface, coded as specified in GSM 04.08 §9.1.10. 3. DTAP MESSAGE

Page 136 GSM 11.23 v.4.4.0: May 1996


In step 1, a CIPHERING MODE COMMAND message shall occur on the radio interface on the main signalling link. The message shall not be enciphered.

In step 2, the CIPHER MODE COMPLETE message shall occur on the MSC-interface.

In step 3, the chosen DTAP message shall occur on the radio interface on the main signalling link. The message shall be enciphered.


1. CIPHERING MODE COMMAND, coded as specified in GSM 04.08 §9.1.9 with

Ciphering mode setting = 'Start Ciphering'. 2. CIPHER MODE COMPLETE, coded as specified in GSM 08.08 §3.2.1.31. 3. DTAP message. Requirement reference

04.08 §3.4.7. 08.08 §3.1.14.

8.1.3.12.2 DTAP message

Test Purpose

To verify the ciphering mode setting procedure, the procedure is completed by a DTAP message from the Mobile Station.

Test Case

Initial Setup

A dedicated resource shall be established between the radio interface and the MSC-interface. Ciphering shall not be activated.

Description

1. A CIPHER MODE COMMAND message shall be input on the MSC-interface containing the Algorithm identifier octet set to 'GSM user data encryption version 1' and the key Kc in the Encryption information element as specified in GSM 08.08 §3.2.2.10. The response on any interface shall be recorded.

2. The BSSTE shall start deciphering and enciphering on the radio interface and then input an I frame

containing any DTAP message on the radio interface on the main signalling link. The response on any interface shall be recorded.

3. The BSSTE shall input any arbitrary DTAP message on the MSC-interface. The response on any

interface shall be recorded.

Message flow

MS BSS MSC CIPHER MODE CMD <---------------------------- CIPH MODE CMD <---------------------------- start deciphering BSS Layer 2 frame ----------------------------> start enciphering BSS DTAP message 1 ----------------------------> DTAP message 1 ----------------------------> DTAP message 2 DTAP message 2 <---------------------------- <--------------------------- The messages from the BSSTE will be:

1. CIPHER MODE COMMAND on the A interface, coded as specified in GSM 08.08 §3.2.1.30, with in the Encryption Information Algorithm identifier = 'GSM user data encryption version 1'. Key Kc.

2. DTAP MESSAGE 1 on the radio interface. 3. DTAP MESSAGE 2 on the MSC interface. Conformance Requirements

In step 1, a CIPHERING MODE COMMAND message shall occur on the radio interface on the main signalling link. The message shall not be enciphered.

In step 2, the chosen DTAP message shall correctly be deciphered and shall occur on the MSC-interface.

In step 3, the chosen DTAP message shall occur on the radio interface on the main signalling link. The message shall be enciphered.


1. CIPHERING MODE COMMAND, coded as specified in GSM 04.08 §9.1.9 with The Ciphering mode setting = 'Start Ciphering'.


04.08 §3.4.7 08.08 §3.1.14

8.1.3.12.3 IMEISV request without starting encryption

Test Purpose

The purpose of this test is to make sure that an IMEISV request is accepted by the BSS, even when encryption is not required.

Initial Setup

A dedicated resource shall be set up between the A-interface and the Um-interface. Ciphering shall not be activated.

Page 138 GSM 11.23 v.4.4.0: May 1996

Test Case

1. A CIPHER MODE COMMAND Message shall be input on the A-interface containing the Ciphering Response Mode set to 1 and no encryption is required. The response on any interface shall be recorded.

2. The BSSTE shall input the CIPHER MODE COMPLETE message on the Um-interface. The

response on any interface shall be recorded. Message flow

MS BSS MSC CIPHER MODE CMD <---------------------------- CIPHER MODE CMD <---------------------------- CIPHER MODE COM ----------------------------> CIPHER MODE COM ----------------------------> The messages from the BSSTE will be:

1. CIPHER MODE COMMAND - GSM 08.08, 3.2.1.30 Layer 3 header information Encryption information (encryption not required) Cipher response mode (IMEISV must be included by the MS) 2. CIPHER MODE COMPLETE - GSM 04.08, 9.1.10 Mobile equipment identity (including IMEISV) Conformance Requirements

In step 1, a CIPHER MODE COMMAND shall occur on the Um-interface asking for no encryption and requesting IMEISV.

In step 2, a CIPHER MODE COMPLETE message shall occur on the A-interface


1. CIPHER MODE COMMAND - GSM 04.08, 9.1.9 Ciphering mode setting (no ciphering) Cipher response (IMEISV shall be included) 2. CIPHER MODE COMPLETE - GSM 08.08, 3.2.1.31 Layer 3 Message Contents (including IMEISV) Requirement reference

GSM 08.08, 3.1.14 GSM 04.08, 3.4.7 8.1.3.12.4 IMEISV request with invalid answer

Test Purpose

The purpose of this test is to make sure that the BSS does not consider erroneous a lack of IMEISV in the Cipher Mode Complete message from MS side.

Initial Setup


Test Case

1. A CIPHER MODE COMMAND Message shall be input on the A-interface containing the Ciphering Response Mode set to 1. The response on any interface shall be recorded.


message does not contain IMEISV as requested with Ciphering Response Mode in the CIPHER MODE COMMAND. The response on any interface shall be recorded.

Message flow


1. CIPHER MODE COMMAND - GSM 08.08, 3.2.1.30 Layer 3 header information Encryption information Cipher response mode (IMEISV must be included by MS) 2. CIPHER MODE COMPLETE - GSM 04.08, 9.1.10 (no mobile equipment identity included) Conformance Requirements

In step 1, a CIPHER MODE COMMAND shall occur on the Um-interface.



1. CIPHER MODE COMMAND - GSM 04.08, 9.1.9 Ciphering mode setting Cipher response (IMEISV shall be included) 2. CIPHER MODE COMPLETE - GSM 08.08, 3.2.1.31 Layer 3 Message Contents (not including IMEISV) Requirement reference

GSM 08.08, 3.1.14 GSM 04.08, 3.4.7

Page 140 GSM 11.23 v.4.4.0: May 1996

8.1.3.12.5 IMEISV not requested with invalid answer

Test Purpose

The purpose of this test is to make sure that the BSS does not consider erroneous a Cipher Mode Complete message from MS side including IMEISV even if not requested.

Initial Setup


Test Case

1. A CIPHER MODE COMMAND Message shall be input on the A-interface containing the Ciphering Response Mode set to 0. The response on any interface shall be recorded.


message does contain Layer 3 Message Contents with IMEISV. The response on any interface shall be recorded.

Message flow


1. CIPHER MODE COMMAND - GSM 08.08, 3.2.1.30 Layer 3 header information Encryption information Cipher response mode (IMEISV must not be included) 2. CIPHER MODE COMPLETE - GSM 04.08, 9.1.10 Mobile equipment identity (including IMEISV) Conformance Requirements

In step 1, a CIPHER MODE COMMAND shall occur on the Um-interface.



1. CIPHER MODE COMMAND - GSM 04.08, 9.1.9 Ciphering mode setting Cipher response (IMEISV shall not be included) 2. CIPHER MODE COMPLETE - GSM 08.08, 3.2.1.31 Layer 3 Message Contents (including IMEISV) Requirement reference

GSM 08.08, 3.1.14

GSM 04.08, 3.4.7 8.1.3.13 Additional assignment

The purpose of the additional assignment procedure is to allocate additional resources to a Mobile Station that is already communicating with the network, e.g. assigning another independent half-rate traffic channel. The procedure is always initiated by the network.

The additional assignment procedure is only intended for future evolution and may be enhanced in the future. The procedure is specified on the radio interface, but the support on the A-interface is for further study. Consequently, the procedure is not tested.

8.1.3.14 Partial release

The partial release procedure is used to release parts of the full assigned radio resources when they are no longer needed. The partial release procedure is used in connection with the additional assignment procedure as tested in section 8.1.3.13 . The procedure is always initiated by the network.

The partial release procedure is only intended for future evolution and may be enhanced in the future. The procedure is specified on the radio interface, but the support on the A-interface is for further study. Consequently, the procedure is not tested.

8.1.3.15 Classmark

8.1.3.15.1 Classmark change

NOTE: The classmark change procedure is used by the MS to indicate to the network a change in its classmark, e.g. change in TX power capabilities due to addition of a power amplifier when a handportable MS is plugged into a car.

Test Purpose

To verify that when the BSS receives a CLASSMARK CHANGE message from a Mobile Station, it sends to the MSC a CLASSMARK UPDATE.

Test Case

Initial Setup


Description

1. A CLASSMARK CHANGE message shall be input on the radio interface with an appropriate new classmark. The response on any interface shall be recorded.

Message flow

MS BSS MSC CLASS CH -----------------------------> CLASS UPD ----------------------------> The messages from the BSSTE will be:

1. CLASSMARK CHANGE, coded as specified in GSM 04.08 §9.1.11, with Mobile station classmark 2

Page 142 GSM 11.23 v.4.4.0: May 1996


In step 1, a CLASSMARK UPDATE message shall occur on the MSC-interface.


1. CLASSMARK UPDATE, coded as specified in GSM 08.08 §3.2.1.29 with Classmark information 2 = the Mobile Station classmark 2 from the MS.


GSM 04.08 §3.4.10. GSM 08.08 §3.1.13.

8.1.3.15.2 Classmark Interrogation

Test Purpose

The Classmark interrogation procedure allows the network to request additional classmark information from the mobile station. The test checks the BSS capability to support this procedure.

Initial Setup

A dedicated resource shall be set up between Um-interface and A-interface

Test Case

1. The BSSTE sends a CLASSMARK REQUEST message on the A-interface. The response on any interface shall be recorded.

2. The BSSTE sends a CLASSMARK CHANGE message including "mobile station classmark 3"

information element.The response on any interface shall be recorded. Message flow

MS BSS MSC CLASSMARK REQUEST <---------------------------- CLASSMARK ENQUIRY <---------------------------- CLASSMARK CHANGE ----------------------------> CLASSMARK UPDATE ----------------------------> The messages from the BSSTE will be:

1. CLASSMARK REQUEST - GSM 08.08, 3.2.1.46 2. CLASSMARK CHANGE - GSM 04.08, 9.1.11 Classmark Information Type 2 Classmark Information Type 3 Conformance Requirements

In case of step 1, a CLASSMARK ENQUIRY message shall occur on the Um-interface.

In case of step 2, a CLASSMARK UPDATE message shall occur on the A-interface


1. CLASSMARK ENQUIRY - GSM 04.08, 9.1.12 2. CLASSMARK UPDATE - GSM 08.08, 3.2.1.29 Classmark Information Type 2 Classmark Information Type 3 Requirement reference

GSM 04.08 §3.4.11 GSM 08.08 §3.1.13 8.1.3.16 Channel release

The channel release task is used to release the full assigned radio resource at the end of a call, or because of some Base Station System generated reason (maintenance, equipment failure etc.).


Test Purpose

To verify the channel release procedure when the MS disconnects the main signalling link within T3109.

Test Case

Initial Setup


A dedicated resource shall be set up between the radio interface and the MSC-interface. There shall be no limiting radio conditions.

Description

1. A CLEAR COMMAND with the cause value "call control" shall be input on the MSC-interface. The response on any interface shall be recorded.

2. After the CHANNEL RELEASE message output in step 3, LAPDm DISC frames shall continuously

be input on the radio interface on the main signalling link. The response on any interface shall be recorded.

Page 144 GSM 11.23 v.4.4.0: May 1996

Message flow

MS BSS MSC CLEAR CMD (cause = CallControl) <---------------------------- CH REL CLEAR COM <---------------------------*---------------------------> DISC | - - - - - - - - - - - - - - > T3109 UA | < - - - - - - - - - - - - - - - | T3111 | - deactivate channels The messages from the BSSTE will be:

1. CLEAR COMMAND, coded as specified in GSM 08.08 §3.2.1.21, with Cause = 'Call Control'.

2. LAPDm DISC frames every T200, coded as specified in GSM 04.06. Conformance Requirements

In step 1, a CHANNEL RELEASE message shall occur on the radio interface on the main signalling link (the BSS shall then start its timer T3109). A CLEAR COMPLETE message shall occur on the MSC-interface.

In step 2, a LAPDm UA frame shall occur on the radio interface on the main signalling link as a response to the first DISC frame (the BSS shall then stop the timer T3109 and start the timer T3111), then a LAPDm DM frame as a response to all consequent DISC frames within a time T3111=B. After the time T3111=B no further responses shall occur.


1 CHANNEL RELEASE, coded as specified in GSM 04.08 §9.1.7. CLEAR COMPLETE, coded as specified in GSM 08.08 §3.2.1.22. 2 LAPDm UA frame, coded as specified in GSM 04.06. LAPDm DM frames, coded as specified in GSM 04.06. Requirement reference

GSM 04.08 §3.5.1. GSM 08.08 §3.1.9.

8.1.3.16.2 T3109 expiry

Test Purpose

To verify the channel release procedure when the MS does not disconnect the main signalling link within T3109.

Test Case

Initial Setup



Description

1. A CLEAR COMMAND with the cause value "call control" shall be input on the MSC-interface. The response on any interface shall be recorded.

2. After the CHANNEL RELEASE message output in step 3, a LAPDm DISC frame shall be input on

the radio interface on the main signalling link after a period T3109=A. The response on any interface shall be recorded.

Message flow

MS BSS MSC CLEAR CMD (cause = CallControl) <---------------------------- CH REL CLEAR COM <---------------------------*---------------------------> | T3109 | - DISC | - - - - - - - - - - - - - - > T3111 | - deactivate channels The messages from the BSSTE will be:

1. CLEAR COMMAND, coded as specified in GSM 08.08 §3.2.1.21, with Cause = 'Call Control'.

2. LAPDm DISC frame, coded as specified in GSM 04.06. Conformance Requirements

In step 1, a CHANNEL RELEASE message shall occur on the radio interface on the main signalling link (the BSS shall then start its timer T3109) and a CLEAR COMPLETE message shall occur on the MSC-interface.

In step 2, no messages shall occur on any interface.


1. CHANNEL RELEASE, coded as specified in GSM 04.08 §9.1.7. CLEAR COMPLETE, coded as specified in GSM 08.08 §3.2.1.22.

Page 146 GSM 11.23 v.4.4.0: May 1996


GSM 04.08 §3.5.1. GSM 08.08 §3.1.9.

8.1.3.16.3 Radio resources out of service

Test Purpose

To verify the channel release procedure when the used radio resources are set out of service on the OMC interface.

Test Case

Initial Setup


Description

1. An O&M-message as defined by the operator or the manufacturer shall be input on the OMC-interface taking the used radio resources out of service. The response on any interface shall be recorded.

Message flow

MS BSS MSC CLEAR REQ (cause = O&M Intervention) ----------------------------> The messages from the BSSTE will be:

1. O&M MESSAGES Conformance Requirements

In step 1, a CLEAR REQUEST message, coded as described in GSM 08.08 §3.2.1.20 shall occur on the MSC-interface with the cause value: "O&M intervention".


GSM 08.08 §3.1.9.2

8.1.3.17 Radio link failure

Test Purpose

To verify the radio link failure procedure which is used when a failure is detected on the radio path by the BSS.

Test Case

Initial Setup

A dedicated resource shall be set up between the radio interface and the MSC-interface.

Description

1. Conditions triggering a lower layer failure in the BSS shall be set up. The response on any interface shall be recorded.

Message flow

MS BSS MSC failure CLEAR REQ ---------------------------->

NOTE 1: Examples of lower layer failures are the expiry of timer T100 (no SACCH reception) and a data link (Layer 2) failure on the radio interface.


In step 1, a CLEAR REQUEST message, coded as specified in GSM 08.08 § 3.2.1.20 and with the cause value "radio interface failure" shall occur on the MSC-interface.

NOTE 2: On reception of the CLEAR REQUEST message, the MSC will invoke the normal channel release procedure of section 8.1.3.16.1. The BSS has then some flexibility with respect to commanding the MS to release or not.


GSM 04.08 §3.5.2. GSM 08.08 §3.1.9.

8.1.3.18 Blocking

8.1.3.18.1 Single circuit blocking

The assignment procedure depends upon the MSC choosing the terrestrial resource to be used. The MSC therefore needs to be informed of any terrestrial circuits that are out of service in the Base Station System. This is obtained by a simple block/unblock procedure. A block/unblock message is sent from the BSS to the MSC and concerns a single terrestrial circuit.

8.1.3.18.1.1 Normal Case

Test Purpose

To verify the Blocking procedure in the normal case.

Test Case

Initial Setup

With an O&M-message as defined by the operator or the manufacturer on the OMC-interface the BSS shall be instructed to set the timer T1 to an appropriate value B.

Description

1. With an O&M-message as defined by the operator or the manufacturer on the OMC-interface the BSS shall be commanded to block the terrestrial circuit A.

Page 148 GSM 11.23 v.4.4.0: May 1996

When a BLOCK message occurs on the MSC-interface, a BLOCK ACKNOWLEDGE message shall be input within a period T1=B on the MSC-interface. The response on any interface shall be recorded.

2. A dedicated resource shall be established between the radio interface and the MSC-interface. An ASSIGNMENT REQUEST message, shall be input on the MSC-interface allocating the

terrestrial circuit A. The response on any interface shall be recorded. Message flow

MS BSS MSC BLOCK (CIC A) - ----------------------------> T1 BLOCKING ACK (CIC A) - <---------------------------- ASS REQ (CIC A) <---------------------------- ASS FAIL (Cause = Terrestrial Resource unavailable) ----------------------------> BLOCK (CIC A) ----------------------------> The messages from the BSSTE will be:

1 O&M MESSAGES1. BLOCKING ACKNOWLEDGE, coded as specified in GSM 08.08 §3.2.1.5, with CIC = terrestrial circuit A.

2. ASSIGNMENT REQUEST, coded as specified in GSM 08.08 §3.2.1.1., with

CIC = terrestrial circuit A. Conformance Requirements

In step 1, a single BLOCK message shall occur for terrestrial circuit A on the MSC-interface. After the BLOCKING ACKNOWLEDGE no further BLOCK messages shall occur.

In step 2, an ASSIGNMENT FAILURE message followed by a single BLOCK message with the cause value "O&M intervention" for terrestrial circuit A shall occur on the MSC-interface.


1. BLOCK, coded as specified in GSM 08.08 §3.2.1.4, with CIC = terrestrial circuit A. Cause = "O&M intervention".

2. ASSIGNMENT FAILURE, coded as specified in GSM 08.08 §3.2.1.3, with

Cause = "requested terrestrial resource unavailable" BLOCK, coded as specified in GSM 08.08 §3.2.1.4, with

CIC = terrestrial circuit A. Cause = "O&M intervention".


GSM 08.08 §3.1.2, §3.1.1.3

8.1.3.18.1.2 Blocking a terrestrial circuit already used on a call.

Test Purpose

To verify that the BSS does not release a call when the allocated terrestrial circuit is blocked on the OMC.

Test Case

Initial Setup


A call shall be set up between the radio interface and the MSC-interface using an appropriate terrestrial circuit A.

Description

1. With an O&M-message as defined by the operator or the manufacturer on the OMC-interface the BSS shall be commanded to block the terrestrial circuit A. The response on any interface shall be recorded.

2. The call on the terrestrial circuit A shall be cleared. The response on any interface shall be

recorded. No further messages shall be input on the MSC-interface. 3. A dedicated resource shall be established between the radio interface and the MSC-interface. An ASSIGNMENT REQUEST message, shall be input on the MSC-interface allocating the


MS BSS MSC BLOCK (CIC A) - ----------------------------> T1 BLOCK (CIC A) - ----------------------------> ASS REQ (CIC A) <---------------------------- ASS FAIL (Cause = Terrestrial Resource unavailable) ----------------------------> BLOCK (CIC A) - ----------------------------> The messages from the BSSTE will be:

1. O&M MESSAGES 3. ASSIGNMENT REQUEST, coded as specified in GSM 08.08 §3.2.1.1., with


In step 1, 2 BLOCK messages with an interval of T1=B between them for terrestrial circuit A shall occur on the MSC-interface. The call shall continue.

In step 2, no BLOCK message shall occur at the MSC-interface, after the call has been cleared.

Page 150 GSM 11.23 v.4.4.0: May 1996

In step 3, an ASSIGNMENT FAILURE message followed by a BLOCK message for terrestrial circuit A shall occur on the MSC-interface.


1. BLOCK, coded as specified in GSM 08.08 §3.2.1.4, with CIC = terrestrial circuit A. Cause = "O&M intervention"

3. ASSIGNMENT FAILURE, coded as specified in GSM 08.08 §3.2.1.3, with

Cause = "requested terrestrial resource unavailable" BLOCK, coded as specified in GSM 08.08 §3.2.1.4, with

CIC = terrestrial circuit A. Cause = "O&M intervention"


GSM 08.08 §3.1.2, §3.1.1.3.

8.1.3.18.1.3 No response to the Unblocking message.

Test Purpose

To verify that the BSS will repeat a second time the UNBLOCK message in case an UNBLOCK ACKNOWLEDGE message is not received before T1 expiry.

The test shall also check that, whatever the outcome of possible repetitions, the concerned terrestrial circuit remain "unblocked".

NOTE: The situation may be reflected to the OMC which shall resolve the possible conflict.

Test Case

Initial Setup

With O&M-messages as defined by the operator or the manufacturer on the OMC-interface the BSS shall be instructed to set the timer T1 to an appropriate value B and the BSS shall be commanded to block the terrestrial circuit A.

Description

1. With an O&M-message as defined by the operator or the manufacturer from the BSSTE over the OMC-interface the BSS shall be commanded to unblock the terrestrial circuit A. The response on any interface shall be recorded.


terrestrial circuit A. The response on any interface shall be recorded.

Message flow

MS BSS MSC UNBLOCK (CIC A) - ----------------------------> T1 UNBLOCK (CIC A) - ----------------------------> ASS REQ (CIC A) <---------------------------- ASS CMD <------------------------- The messages from the BSSTE will be:

1. O&M MESSAGES 2. ASSIGNMENT REQUEST, coded as specified in GSM 08.08 §3.2.1.1., with


In step 1, 2 UNBLOCK messages, with an interval of T1=B between them for terrestrial circuit A shall occur on the MSC-interface.

In step 2, an ASSIGNMENT COMMAND message shall occur on the radio interface on the main signalling link.


1. UNBLOCK, coded as specified in GSM 08.08 §3.2.1.6 with CIC = terrestrial circuit A.

2. ASSIGNMENT COMMAND , coded as specified in GSM 04.08 §9.1.2


GSM 08.08 §3.1.2.2

8.1.3.18.1.4 Unblocking, Normal case.

Test Purpose

To verify that the BSS can allocate a terrestrial circuit after having received the Unblocking Acknowledge message from the MSC.

Test Case

Initial Setup

With O&M-messages as defined by the operator or the manufacturer on the OMC-interface the BSS shall be instructed to set the timer T1 to an appropriate value B and the BSS shall be commanded to block the terrestrial circuit A.

Description

1. With an O&M-message as defined by the operator or the manufacturer from the BSSTE over the OMC-interface the BSS shall be commanded to unblock the terrestrial circuit A. Then an

Page 152 GSM 11.23 v.4.4.0: May 1996

UNBLOCKING ACKNOWLEDGE message input on the MSC-interface within a time T1=B for the terrestrial circuit A. The response on any interface shall be recorded.



MS BSS MSC UNBLOCK (CIC A) - ----------------------------> T1 UNBLOCKING ACK (CIC A) - <---------------------------- ASS REQ (CIC A) <---------------------------- ASS CMD <---------------------------- The messages from the BSSTE will be:

1. O&M MESSAGES UNBLOCKING ACKNOWLEDGE, coded as specified in GSM 08.08 §3.2.1.7, with:

CIC = terrestrial circuit A. 2. ASSIGNMENT REQUEST, coded as specified in GSM 08.08 §3.2.1.1., with


In step 1, a single UNBLOCK message shall occur for terrestrial circuit A on the MSC-interface. After the UNBLOCKING ACKNOWLEDGE no further UNBLOCK messages shall occur.

In step 2, an ASSIGNMENT COMMAND message shall occur on the radio interface on the main signalling link.


1. UNBLOCK, coded as specified in GSM 08.08 §3.2.1.6, with: CIC = terrestrial circuit A.

2. ASSIGNMENT COMMAND, coded as specified in GSM 04.08 §9.1.2. Requirement reference

GSM 04.08 §3.4.3 GSM 08.08 §3.1.2.

8.1.3.18.1.5 MSC Reset during Blocking procedure.

Test Purpose

To verify the BSS behaviour when the MSC answers by a Reset message to the Blocking message.

Test Case

Initial Setup


Description

1. With an O&M-message as defined by the operator or the manufacturer on the OMC-interface the BSS shall be commanded to block the terrestrial circuit A.

When a BLOCK message occurs on the MSC-interface, a RESET message shall be input within a

period T1=B on the MSC-interface. The response on any interface shall be recorded. Message flow

MS BSS MSC BLOCK (CIC A) - ----------------------------> | RESET - | <---------------------------- | T1 BLOCK (CIC A) | - ----------------------------> T2 | RESET ACK - ---------------------------> The messages from the BSSTE will be:

1. O&M MESSAGES RESET, coded as specified in GSM 08.08 §3.2.1.23 Conformance Requirements

In step 1, 2 BLOCK messages shall occur on the MSC-interface concerning the terrestrial circuit A. After some seconds, given by the timer T2, after the input RESET message a RESET ACKNOWLEDGE message shall occur on the MSC-interface. Then no further BLOCK messages shall occur. See also section 8.1.3.20 in this specification (reset).


1. BLOCK, coded as specified in GSM 08.08 §3.2.1.4, with: CIC = terrestrial circuit A. Cause: "O&M intervention".

RESET ACKNOWLEDGE, coded as specified in GSM 08.08 §3.2.1.24. Requirement reference

GSM 08.08 §3.1.2 & 3.1.4.1.2

8.1.3.18.2 Circuit group blocking

8.1.3.18.2.1 Circuit group block - Normal case

Test Purpose

Test the BSS capability to proceed the CIRCUIT GROUP BLOCK procedure.

Page 154 GSM 11.23 v.4.4.0: May 1996

Initial Setup

With O&M-messages as defined by the operator or the manufacturer on the OMC-interface the BSS shall be instructed to set the timer T20 to an appropriate value B.

Test Case

1. With an O&M message, the BSS shall be commanded to block a group of terrestrial circuits. The response on any interface shall be recorded.

2. The BSSTE sends a CIRCUIT GROUP BLOCKING ACKNOWLEDGE message within a period

T2=B. The response on any interface shall be recorded. Message Flow

MS BSS MSC O&M block a group of terrestrial circuits CIRCUIT GROUP BLOCK ----------------------------> CIRCUIT GROUP BLOCK ACK <---------------------------- The messages from the BSSTE will be:

2. CIRCUIT GROUP BLOCKING ACKNOWLEDGE - GSM 08.08, 3.2.1.42 Circuit Identity Code Circuit Identity Code List Conformance Requirements

In case of step 1 the BSS sends a CIRCUIT GROUP BLOCKING message with cause : "O&M intervention".

In case of step 2 no further messages are expected.

The messages from the BSS will be:

1. CIRCUIT GROUP BLOCKING - GSM 08.08, 3.2.1.41 Cause = "O&M intervention" Circuit Identity Code Circuit Identity Code List Requirement reference

GSM 08.08 Chapter 3.1.2

8.1.3.18.2.2 Circuit group unblock - Normal case

Test Purpose

Test the BSS capability to proceed the CIRCUIT GROUP UNBLOCK Procedure.

Initial Setup

With an O&M message, the BSS shall be commanded to block a group of terrestrial circuits.

Test Case

1. The blocked group of terrestrial circuits shall be unblocked with an O&M message. The response on any interface shall be recorded.

2. The BSSTE sends a CIRCUIT GROUP UNBLOCKING ACKNOWLEDGE message. The response

on any interface shall be recorded. Message Flow

MS BSS MSC O&M block and then unblock the same group of terrestrial circuits CIRCUIT GROUP UNBLOCK ----------------------------> CIRCUIT GROUP UNBLOCK ACK <---------------------------- The messages from the BSSTE will be:

2. CIRCUIT GROUP UNBLOCKING ACKNOWLEDGE - GSM 08.08, 3.2.1.44 Circuit Identity Code Circuit Identity Code List Conformance Requirements

In case of step 1 the BSS sends a CIRCUIT GROUP UNBLOCKING message relating to the concerned group of terrestrial circuits.

In case of step 2 no further messages are expected.


1. CIRCUIT GROUP UNBLOCKING - GSM 08.08, 3.2.1.43 Circuit Identity Code Circuit Identity Code List Requirement reference


8.1.3.19 Resource indication

8. 1.3.19.1 Spontaneous indication

Test Purpose

To verify the resource indication procedure in the BSS.

The purpose of the resource indication task is to inform the MSC about the amount of idle channels in the BSS, separately for half rate and full rate TCHs, giving information about the interference level on the various channels.

Page 156 GSM 11.23 v.4.4.0: May 1996

Test Case

Initial Setup

The BSS shall be active, with possible calls established between the MS and the MSC.

Description

1. An O&M message as defined by the operator or the manufacturer shall be input on the OMC-interface setting the thresholds for the RESOURCE INDICATION messages. Then a RESOURCE REQUEST message indicating "spontaneous indication" shall be input on the MSC-interface. The response on any interface shall be recorded.

2. The environment shall be set up to trigger a spontaneous RESOURCE INDICATION message from

the BSS. The response on any interface shall be recorded. Message flow

MS BSS MSC RES REQ <---------------------------- RES IND ----------------------------> threshold reached RES IND ----------------------------> The messages from the BSSTE will be:

1. O&M MESSAGES RESOURCE REQUEST, coded as specified in GSM 08.08 §3.2.1.17.

Periodicity = 00 (none) Resource indication method = 00 (spontaneous)


In step 1, a first RESOURCE INDICATION message without any resource information to the MSC shall be sent immediately as an acknowledgement to the RESOURCE REQUEST.

In step 2, a RESOURCE INDICATION message shall occur spontaneously on the MSC-interface reflecting the environment simulated by the BSSTE.


1. RESOURCE INDICATION, coded as specified in GSM 08.08 §3.2.1.18. Resource indication method = 00 (spontaneous) 2. RESOURCE INDICATION, coded as specified in GSM 08.08 §3.2.1.18. Resource indication method = 00 (spontaneous) Resource available Requirement reference

GSM 08.08 §3.1.3.

8.1.3.19.2 One single indication

Test Purpose



Test Case

Initial Setup


Description

1. An O&M message as defined by the operator or the manufacturer shall be input on the OMC-interface setting the thresholds for the RESOURCE INDICATION messages. Then a RESOURCE REQUEST message indicating "one single indication" shall be input on the MSC-interface.

Message flow

MS BSS MSC RES REQ <---------------------------- RES IND ----------------------------> The messages from the BSSTE will be:


Periodicity = 00 (none) Resource indication method = 01 (one single indication)


In step 1, a RESOURCE INDICATION message with some resource information shall occur immediately on the MSC-interface reflecting the environment simulated by the BSSTE.


1. RESOURCE INDICATION, coded as specified in GSM 08.08 §3.2.1.18. Resource indication method = 01 (one single indication) Resource available Requirement reference

GSM 08.08 §3.1.3.

8.1.3.19.3 Periodic indication

Test Purpose


Page 158 GSM 11.23 v.4.4.0: May 1996


Test Case

Initial Setup


Description

1. An O&M message as defined by the operator or the manufacturer shall be input on the OMC-interface setting the thresholds for the RESOURCE INDICATION messages. Then a RESOURCE REQUEST message indicating "periodic indication" and a periodicity of T3=B>0 shall be input on the MSC-interface.

Message flow

MS BSS MSC RES REQ <---------------------------- RES IND - ----------------------------> T3 RES IND - ----------------------------> The messages from the BSSTE will be:

1. RESOURCE REQUEST, coded as specified in GSM 08.08 §3.2.1.17. Periodicity = T3 = B >0 Resource indication method = 02 (periodic indication)


In step 1, RESOURCE INDICATION messages shall occur repeatedly on the MSC-interface with an interval T3=B reflecting the environment simulated by the BSSTE.


1. RESOURCE INDICATION, coded as specified in GSM 08.08 §3.2.1.18. Resource indication method = 02 (periodic indication) Resource available


GSM 08.08 §3.1.3.

8.1.3.19.4 No indication

Test Purpose



Test Case

Initial Setup


An O&M message as defined by the operator or the manufacturer shall be input on the OMC-interface setting the thresholds for the RESOURCE INDICATION messages. Then a RESOURCE REQUEST message indicating "periodic indication" and a periodicity of T3=B>0 shall be input on the MSC-interface, so that RESOURCE INDICATION messages shall occur repeatedly on the MSC-interface with an interval T3=B.

Description

1. A RESOURCE REQUEST message indicating "no indication" shall be input on the MSC-interface. The response on any interface shall be recorded.

Message flow

MS BSS MSC RES REQ <---------------------------- RES IND - ----------------------------> T3 RES IND - ----------------------------> RES REQ <---------------------------- RES IND ----------------------------> The messages from the BSSTE will be:


Periodicity = 00 (none) Resource indication method = 03 (no indication)


In step 1, the BSS shall return immediately a single RESOURCE INDICATION without any resource information as an acknowledgement and the stop the transfer of resource information, i.e. no further RESOURCE INDICATION messages shall occur on the MSC-interface.


1. RESOURCE INDICATION, coded as specified in GSM 08.08 §3.2.1.18.

Resource indication method = 03 (no indication)


GSM 08.08 §3.1.3.

Page 160 GSM 11.23 v.4.4.0: May 1996

8.1.3.19.5 Extended resource indicator

Test Purpose

Test the BSS capability to proceed the RESOURCE INDICATION Procedure, correctly analysing the Extended Resource Indicator IE.

Initial Setup


Test Case

1. The BSSTE sends a RESOURCE REQUEST with the optional information element Extended Resource Indicator on the A-interface. The response on any interface shall be recorded.

Message Flow

MS BSS MSC RESOURCE REQUEST <---------------------------- RESOURCE INDICATION ----------------------------> The messages from the BSSTE will be:

1. RESOURCE REQUEST - GSM 08.08, 3.2.1.17 Periodicity = 00 (none) Resource indication method = 01 (one single indication) Extended Resource Indicator = 01(total number of accessible channel is requested;

Subsequent mode = no resource information requested) Conformance Requirements

In case of step 1 the BSS sends a RESOURCE INDICATION message with the information element Total Resource accessible.


1. RESOURCE INDICATION - GSM 08.08, 3.2.1.18 Resource indication method = 01 (one single indication) Resource available

Total Resource accessible Requirement reference


8.1.3.20 Reset

8.1.3.20.1 Global reset

The purpose of the reset procedure is to initialise the BSS or the MSC in the event of a failure. In such a case transaction references are lost in the BSS or in the MSC, and a reset message has to be sent to the other end so that all affected calls can be released in that end.

8.1.3.20.1.1 Global reset at the BSS

Test Purpose

In the event of a failure in the BSS which has resulted in the loss of transaction reference information, the BSS resets and the MSC is told to release all calls, to erase all references and to put all circuits into the idle state for the BSS in question.

Test Case

Initial Setup



Description

1. Conditions triggering a RESET message to the MSC shall be set up. How to do it is up to the operator or to the manufacturer. Nothing shall be input on the MSC-interface, and the reset conditions shall seize. The BSSTE will not release the dedicated resources of the established call. The response on any interface shall be recorded.

2. Within a time T4 after the third RESET message from the BSS on the MSC-interface, a RESET

ACKNOWLEDGE message shall be input on the MSC-interface. The response on any interface shall be recorded.

3. A DTAP message shall be input on the main signalling channel of the established call on the radio

interface. The response on any interface shall be recorded. Message flow

MS BSS MSC RESET - ----------------------------> release calls RESET - ----------------------------> RESET - ----------------------------> - T=B RESET ACK T2 - <---------------------------- - DTAP -----------------------> The messages from the BSSTE will be:

1. O&M MESSAGES 2. RESET ACKNOWLEDGE, coded as specified in GSM 08.08 §3.2.1.24. 3. DTAP MESSAGE Conformance Requirements

In step 1, RESET messages with an appropriate cause value shall occur repeatedly on the MSC-interface with an interval of B seconds. At least 3 messages shall be observed. On the radio interface a CHANNEL RELEASE message may occur.

Page 162 GSM 11.23 v.4.4.0: May 1996

In step 2, no more RESET messages shall occur from the BSS after the reception of the RESET ACKNOWLEDGE message.

In step 3, no message shall occur on any interface.


1. RESET, coded as specified in GSM 08.08 §3.2.1.23, with Cause = the appropriate value.

CHANNEL RELEASE, coded as specified in GSM 04.08 §9.1.7, with Cause = the appropriate RR cause


GSM 08.08 §3.1.4.1.1, §3.1.4.1.3.1.

8.1.3.20.1.2 Global reset at the MSC

Test Purpose

In the event of a failure in the MSC which has resulted in the loss of transaction reference information, the MSC resets all transactions with the BSS, and the BSS is told to release all calls and to erase all references.

Test Case

Initial Setup


An O&M-message as defined by the operator or the manufacturer shall be input on the OMC-interface instructing the BSS to set the timer T13 to an appropriate value A.

Description

1. A RESET message shall be input on the MSC-interface. The BSSTE will not release the dedicated resources of the established call. The response on any interface shall be recorded.

2. A STATUS ENQUIRY message shall be input on the radio interface on the main signalling link of

the established call. The response on any interface shall be recorded. Message flow

MS BSS MSC RESET - <---------------------------- | T13| release calls | RESET ACK - ----------------------------> STATUS ENQUIRY ----------------------> The messages from the BSSTE will be:

1. RESET, coded as specified in GSM 08.08 §3.2.1.23.

2. STATUS ENQUIRY message, coded as specified in GSM04.08 §9.3.28.. Conformance Requirements

In step 1, T13=A seconds after the input RESET message a RESET ACKNOWLEDGE message shall occur at the MSC-interface. On the radio interface a CHANNEL RELEASE message may occur.

In step 2, no messages shall occur on any interface.


1. RESET ACKNOWLEDGE, coded as specified in GSM 08.08 §3.2.1.23. CHANNEL RELEASE, coded as specified in GSM 04.08 §9.1.7, with

Cause = the appropriate RR cause Requirement reference

GSM 08.08 §3.1.4.1.2.

8.1.3.20.2 Reset circuit

The purpose of the reset circuit procedure is to restore the information in the MSC or BSS in case of a failure which has affected only a small part of the equipment, in case the SCCP connection has been released during the failure.

8.1.3.20.2.1 Reset circuit at the BSS

Test Purpose

If a circuit has to be set idle at the BSS due to abnormal SCCP connection release, the MSC is told to clear the possible call and to set its corresponding circuit idle.

Test Case

Initial Setup

A call shall be set up between the radio interface and the MSC-interface using the terrestrial circuit A.


Description

1. Conditions triggering a RESET CIRCUIT message to the MSC concerning the terrestrial circuit A shall be set up. How to do it is up to the operator or to the manufacturer. Nothing shall be input on the MSC-interface, and the reset conditions shall seize. The BSSTE will not release the dedicated resources of the established call. The response on any interface shall be recorded.

2. Within a time T19 after the second RESET CIRCUIT message from the BSS on the MSC-interface,

a RESET CIRCUIT ACKNOWLEDGE message shall be input on the MSC-interface concerning the terrestrial circuit A. The response on any interface shall be recorded.

3. A DTAP message shall be input on the radio interface on the main signalling channel of the

established call. The response on any interface shall be recorded.

Page 164 GSM 11.23 v.4.4.0: May 1996

Message flow

MS BSS MSC RESET CIRC (CIC A) - ----------------------------> T19=B RESET CIRC (CIC A) - ----------------------------> T19 RESET CIRC ACK - <---------------------------- DTAP -----------------------> The messages from the BSSTE will be:

1. O&M MESSAGES 2. RESET CIRCUIT ACKNOWLEDGE, coded as specified in GSM 08.08 §3.2.1.39, with

CIC = terrestrial circuit A. 3. DTAP MESSAGE Conformance Requirements

In step 1, two RESET CIRCUIT messages shall occur on the MSC- interface with an interval of B seconds.

A CHANNEL RELEASE message may occur on the radio interface.

In step 2, no more RESET CIRCUIT messages shall occur from the BSS after the reception of the RESET CIRCUIT ACKNOWLEDGE message.

In step 3, no message shall occur on any interface.


1. RESET CIRCUIT, coded as in GSM 08.08 §3.2.1.38, with CIC parameter = terrestrial circuit A. Cause = appropriate cause

CHANNEL RELEASE, coded as specified in GSM 04.08 §9.1.7, with Cause = the appropriate RR cause Requirement reference

GSM 08.08 §3.1.4.2.1.

8.1.3.20.2.2 Reset circuit at the MSC

Test Purpose

If a circuit has to be set idle at the MSC due to abnormal SCCP connection release, the BSS is told to clear the possible call and to set its corresponding circuit idle.

Test Case

Initial Setup

A call shall be set up between the radio interface and the MSC-interface using the terrestrial circuit A.

An O&M-message as defined by the operator or the manufacturer shall be input on the OMC-interface instructing the BSS to set the timer T1 to an appropriate value B.

Description

1. A RESET CIRCUIT message shall be input on the MSC-interface concerning the terrestrial circuit A. The BSSTE will not release the dedicated resources of the established call. The response on any interface shall be recorded.

2. A STATUS ENQUIRY message shall be input on the radio interface on the main signalling link of

the established call. The response on any interface shall be recorded. 3. A BLOCK message shall be input on the A-interface instructing the BSS to block the terrestrial

circuit A. The response on any interface shall be recorded.An O&M-message as defined by the operator or the manufacturer shall be input on the OMC-interface instructing the BSS to block the terrestrial circuit A.

4. Then aA RESET CIRCUIT message shall be input on the MSC-interface concerning the terrestrial

circuit A. The response on any interface shall be recorded 54. The test is stopped by inputting a BLOCKING ACKNOWLEDGE message concerning the terrestrial

circuit A on the MSC-interface. Message flow

MS BSS MSC RESET CIRC <---------------------------- release circuit RESET CIRC ACK ----------------------------> STATUS ENQUIRY ----------------------------> BLOCK <---------------------------- BLOCK_ACK ----------------------------> RESET CIRC <---------------------------- BLOCK ----------------------------> The messages from the BSSTE will be:

1. RESET CIRCUIT, coded as specified in GSM 08.08 §3.2.1.38, with CIC = terrestrial circuit A.

2. STATUS ENQUIRY message, coded as specified in GSM04.08 §9.3.28. 3. O&M MESSAGES 3. BLOCK, coded as specified in GSM 08.08 §3.2.1.4, with CIC = terrestrial circuit A. 4. RESET CIRCUIT, coded as specified in GSM 08.08 §3.2.1.38, with CIC = terrestrial circuit A. 54. BLOCK ACKNOWLEDGE, coded as specified in GSM 08.08 §3.2.1.5, with

CIC = terrestrial circuit A.

Page 166 GSM 11.23 v.4.4.0: May 1996


In step 1, a RESET CIRCUIT ACKNOWLEDGE message shall occur at the MSC-interface concerning the terrestrial circuit A.

In the case of step 2, aA CHANNEL RELEASE message may occur on the radio interface on the main signalling link.

In case of step 2, no message shall occur on the A interface.

In the case of step 3, a BLOCK_ACK message with the cause value "O&M intervention" shall occur on the MSC-interface with an interval of T1=B concerning the terrestrial circuit A.

In the case of step 4, a BLOCK message shall occur on the A-interface concerning the terrestrial circuit A.


1. RESET CIRCUIT ACKNOWLEDGE, coded as specified in GSM 08.08 §3.2.1.39, with CIC = terrestrial circuit A.

CHANNEL RELEASE, coded as specified in GSM 04.08 §9.1.7, with Cause = the appropriate RR cause

3. BLOCK ACKNOWLEDGE, coded as specified in GSM 08.08 §3.2.1.5, with CIC = terrestrial circuit A. 43. BLOCK, coded as specified in GSM 08.08 §3.2.1.4, with

CIC = terrestrial circuit A. Requirement reference

GSM 08.08 §3.1.4.2.2.

8.1.3.21 Handover candidate enquiry

The purpose of the handover candidate enquiry procedure is for the MSC to get information about MSs which are possible handover candidates to a given cell. This is useful in case the MSC for traffic reasons wants to handover 1 or several MSs. The criteria for the choice of handover candidates by the BSS are, however, not specified. These are left to the operator or manufacturer.

8.1.3.21.1 Handover candidate enquiry for 3 MSs.

Test Purpose

To verify that the BSS sends Handover required messages for up 3 MSs.

Test Case

Initial Setup

2 network originated calls shall be set up between the radio interface and the MSC-interface in cell A.

The measurement reports transmitted by the BSSTE in both calls shall emulate cell B as a possible handover candidate. Cell B shall be external to the BSS under test. The exact emulation is left to the manufacturer or the operator.

Description

1. A HANDOVER CANDIDATE ENQUIRY regarding the cell B shall be input on the MSC-interface with a maximum number of MSs of 3. The response on any interface shall be recorded.

Message flow

MS BSS MSC HAND CAND ENQ <-------------------------- HAND RQD MS1 --------------------------> HAND RQD MS2 --------------------------> HAND CAND RES --------------------------> The messages from the BSSTE will be:

1. HANDOVER CANDIDATE ENQUIRY, coded as specified in GSM 08.08 §3.2.1.14, with: Number of MSs = 3. Cell identifier list = B,.. Cell identifier = A


In the case of step 1, 2 HANDOVER REQUIRED messages with the cause value "response to MSC invocation" shall occur on the MSC-interface followed by a HANDOVER CANDIDATE RESPONSE message indicating 2 handover candidates.


1. HANDOVER REQUIRED, coded as specified in GSM 08.08 §3.2.1.9, with Cause = "response to MSC invocation" Cell identifier list (preferred) = B,..

HANDOVER CANDIDATE RESPONSE, coded as specified in GSM 08.08 §3.2.1.15, with

Number of MSs = 2 Cell identifier = A


GSM 08.08 §3.1.8.

8.1.3.21.2 Handover candidate enquiry for 1 MS.

Test Purpose

To verify that the BSS sends Handover required messages for up 1 MS.

Test Case

Initial Setup



Page 168 GSM 11.23 v.4.4.0: May 1996

Description

1. A HANDOVER CANDIDATE ENQUIRY regarding the cell B shall be input on the MSC-interface with a maximum number of MSs of 1. The response on any interface shall be recorded.

Message flow

MS BSS MSC HAND CAND ENQ <-------------------------- HAND RQD MS1 --------------------------> HAND CAND RES --------------------------> The messages from the BSSTE will be:



In step 1, 1 HANDOVER REQUIRED messages with the cause value "response to MSC invocation" shall occur on the MSC-interface followed by a HANDOVER CANDIDATE RESPONSE message indicating 1 handover candidates.






GSM 08.08 §3.1.8.

8.1.3.21.3 Repetition of the Handover candidate enquiry message.

Test Purpose

To verify the BSS behaviour when the Handover required message is repeated.

Test Case

Initial Setup



Description

1. A HANDOVER CANDIDATE ENQUIRY regarding the cell B shall be input on the MSC-interface with a maximum number of MSs of 3.

After the first HANDOVER REQUIRED message occurring on the MSC-interface then another

HANDOVER CANDIDATE ENQUIRY message shall be input on the MSC-interface. The response on any interface shall be recorded.

Message flow

MS BSS MSC HAND CAND ENQ <-------------------------- HAND RQD MS1 --------------------------> HAND CAND ENQ <-------------------------- HAND RQD MS2 --------------------------> HAND CAND RES --------------------------> The messages from the BSSTE will be:



In the case of step 1, 2 HANDOVER REQUIRED messages with the cause value "response to MSC invocation" shall occur on the MSC-interface followed by a HANDOVER CANDIDATE RESPONSE message indicating 2 handover candidates. The second HANDOVER CANDIDATE ENQUIRY shall be discarded.






GSM 08.08 §3.1.8.2

8.1.3.22 Trace invocation

The purpose of the trace invocation procedure is for the MSC, on behalf of the OMC, to request the BSS that it should start producing a trace record on a particular transaction, or vice versa.

8.1.3.22.1 Trace invoked by the MSC

The MSC may, on behalf of the OMC, request the BSS to start producing a trace record on a particular transaction. For further details see GSM 08.08 and GSM 12.20.

Page 170 GSM 11.23 v.4.4.0: May 1996

This procedure is not acknowledged and cannot be tested as a BSSMAP procedure.

NOTE: The procedure might, however, be tested as an O&M procedure concerning the SMAP in GSM 11.21.

8.1.3.22.2 Trace invoked by the BSS

Test Purpose

The BSS may, on behalf of the OMC, request the MSC to start producing a trace record on a particular transaction.

Test Case

Initial Setup

The BSS shall be in active state.

Description

1. An O&M message as defined by the operator or the manufacturer shall be input on the OMC-interface requesting the BSS to request the MSC to start producing a trace record on a transaction using the terrestrial circuit A. The response on any interface shall be recorded.

Message flow

MS BSS MSC BSS INVOKE TRACE ----------------------------> The messages from the BSSTE will be:

1. O&M MESSAGE Conformance Requirements

In step 1, a BSS INVOKE TRACE message shall occur on the MSC-interface on the terrestrial circuit A.


1. BSS INVOKE TRACE, coded as specified in GSM 08.08 §3.2.1.28. Requirement reference:

GSM 08.08 §3.1.11. GSM 12.20

8.1.3.23 Flow control

Flow control in the BSS and MSC are supported by overload messages which result in some form of reduction of the traffic coming from the other side.

8.1.3.23.1 Overload in the MSC

When the MSC processor is overloaded, an overload message is sent to the BSS, and the BSS will try to reduce the load.

The method of reducing the load is a national or operator specific matter. Consequently, the procedure is not tested.

8.1.3.23.2 Overload in the BSS

When an overload situation occurs in the BSS, an overload message is sent to the MSC. The overload situation can be caused by processor overload, CCCH scheduling overload or MTP congestion. For further information see GSM 08.08 §3.1.12.

This situation will take part of the load testing of a BSS and is outside the scope of the standardised acceptance tests in this specification. Load testing of the BSS is a national or operator specific matter.

8.1.3.24 Data link control for SAPI not equal to 0

In order to support radio interface data links with SAPI not equal to 0 (e.g. Short Message Services with SAPI=3), specific control of these links is needed between the BSS and the MSC. This does not apply to SAPI=0.

Note: SMS Transaction using SAPI 3 can be performed either on SDCCH (no parallel call) or on SACCH (parallel call). Hereafter only SACCH-cases has been mentioned explicitly.

8.1.3.24.1. MSC-originated transaction

When a Layer 3 message indicating a SAPI other than 0 originates from the network through the MSC, this will be transferred to the MS as a DTAP message through the BSS. The SAPI "n" signalling link will be established if it is not already. This procedure applies only to the Short Message service (SMS) using SAPI=3.

8.1.3.24.1.1 Normal case - parallel call

Test Purpose

To verify the BSS behaviour in the case of a mobile terminating short message transfer with an active parallel call.

Test Case

Initial Setup

A call (SAPI=0) shall be set up between the radio interface and the MSC-interface (active traffic-channel).

Description

1 A DTAP message shall be input on the MSC-interface indicating SAPDLCI=3. The response on any interface shall be recorded.

2 A LAPDm UA frame acknowledging the output SABM shall be input on the radio interface on the

SACCH within a time T200. The response on any interface shall be recorded.

Page 172 GSM 11.23 v.4.4.0: May 1996

Message flow

MS BSS MSC DTAP message (DLCI=3) <---------------------------- SABM (SAPI=3) <- - - - - - - - - - - - - - - UA (SAPI=3) - - - - - - - - - - - - - - -> DTAP message (SAPI=3) <----------------------------- The messages from the BSSTE will be:

1 DTAP MESSAGE, with DLCI = 3. 2 LAPDm UA frame, coded as specified in GSM 04.06. Conformance Requirements

In step 1, a LAPDm SABM frame shall occur on the radio interface on the SACCH.

In step 2, the DTAP message shall occur on the radio interface on the SACCH.


1 LAPDm SABM frame, coded as defined in GSM 04.06, with SAPI = 3.

2. DTAP MESSAGE, with

SAPI = 3. Requirement reference

GSM 04.06 GSM 04.08 GSM 04.11 Annex F GSM 08.08 §3.1.18

8.1.3.24.1.2 MS failure.

Test Purpose

To verify the BSS behaviour when the MS does not answer to the SABM frame.

Test Case

Initial Setup

A call (SAPI=0) shall be set up between the radio interface and the MSC-interface (active traffic channel).

Description

1. A DTAP message shall be input on the MSC-interface indicating DLCI=3. No further messages shall be input. The response on any interface shall be recorded.

Message flow

MS BSS MSC DTAP message (DLCI=3) <---------------------------- SABM (SAPI=3) <- - - - - - - - - - - - - - - - T200 | SABM (SAPI=3) <- - - - - - - - - - - - - - - N200 times SABM (SAPI=3) <- - - - - - - - - - - - - - - CLEAR REQUEST ----------------------------> The messages from the BSSTE will be:

1 DTAP message, with DLCI =3. Conformance Requirements

In step 1, N200+1 LAPDm SABM frames indicating SAPI=3 shall occur on the radio interface on the SACCH with an interval of T200. Then a CLEAR REQUEST message concerning the whole call with the cause value "radio link message failure" shall occur on the MSC-interface.


1. N200+1 LAPDm SABM frame, coded as defined in GSM 04.06, with SAPI =3.

CLEAR REQUEST, coded as specified in GSM 08.08 §3.2.1.20, with cause = "radio link message failure".


GSM 04.06 GSM 04.08 GSM 04.11 Annex F GSM 08.08 §3.1.18

8.1.3.24.1.3 SAPI 3 transactions rejected in the OMC.

Test Purpose

To verify the BSS when the SAPI 3 transactions are rejected in the OMC.

Test Case

Initial Setup

A call (SAPI=0) shall be set up between the radio interface and the MSC-interface.

An O&M message as defined by the operator or the manufacturer shall be input on the OMC-interface instructing the BSS to reject all SAPI=3 transactions.

Page 174 GSM 11.23 v.4.4.0: May 1996

Description

1. A DTAP message shall be input on the MSC-interface indicating DLCI=3. The response on any interface shall be recorded.

Message flow

MS BSS MSC DTAP message (DLCI=3) <---------------------------- SAPI n REJECT ----------------------------> The messages from the BSSTE will be:

1. DTAP message, with DLCI = 3. Conformance Requirements

In step 1, a SAPI "n" REJECT message shall occur on the MSC-interface with the cause value "O&M intervention".


2. SAPI "n" REJECT, coded as specified in GSM 08.08 §3.2.1.34, with DLCI = 3 Cause = "O&M intervention".


GSM 08.08 §3.1.18.1.2

8.1.3.24.2. MS-originated transaction - parallel call

Test Purpose

When a Layer 3 message indicating a SAPI other than 0 originates from the MS, the MS will first send a CM SERVICE REQUEST on the main signalling link requesting the SAPI "n" service. Then, after the acceptance of the service from the network, the MS will establish the SAPI "n" link and send the Layer 3 message as a DTAP message. This procedure applies only to the Short Message Service (SMS) on the SACCH with SAPI=3.

8.1.3.24.2.1 Normal case

Test Purpose

To verify the BSS behaviour in the case of mobile originating short message transfer with an active parallel call.

Test Case

Initial Setup

A call (SAPI=0) shall be set up between the radio interface and the MSC-interface (active traffic channel). The state of the BSSTE shall be as if a Short Message Service has been accepted.

Description

1. A LAPDm SABM frame indicating SAPI=3 shall be input on the radio interface on the SACCH. The response on any interface shall be recorded.

2. A Short Message Service DTAP message with SAPI=3 shall be input on the radio interface. The

response on any interface shall be recorded. Message flow

MS BSS MSC SABM (SAPI=3) - - - - - - - - - - - - - - -> UA (SAPI=3) <- - - - - - - - - - - - - - - DTAP message (SAPI=3) ---------------------------------------------------------> The messages from the BSSTE will be:

1. LAPDm SABM frame, coded as specified in GSM 04.06, with SAPI = 3.

2. DTAP message, with SAPI = 3. Conformance Requirements

In step 1, a LAPDm UA frame indicating SAPI=3 shall occur on the radio interface on the SACCH.

In step 2, the DTAP message shall occur transparently on the MSC-interface.


1. LAPDm UA frame, coded as specified in GSM 04.06, with SAPI = 3.

2. DTAP message with DLCI = 3. Requirement reference:

GSM 04.06. GSM 04.08. GSM 04.11 Annex F GSM 08.08 §3.1.18.

8.1.3.25 Queuing indication

The queuing indication is only used if the BSS uses a queuing mechanism for the assignment of TCHs. Its purpose is to inform the MSC about a delay in the allocation of the necessary dedicated resources. The use of such a queuing mechanism is a national or operator specific matter.

8.1.3.25.1 Assignment case

Test Purpose

If the BSS does not have an available TCH as requested by the MSC in the assignment resource allocation procedures as tested in section 8.1.3.6, the resource request is put into a queue, and an indication is given to the MSC.

Page 176 GSM 11.23 v.4.4.0: May 1996

Test Case

Initial Setup

An O&M message as defined by the operator or the manufacturer shall be input on the OMC-interface setting the timer T10 to an appropriate value A, the timer T11 to an appropriate value B.

The BSS shall be put into a state so that an additional resource request (assignment or handover) for a specific channel will cause queuing. How to do it is up to the operator or to the manufacturer.


Description

1. A dedicated resource shall be established between the radio interface and the MSC-interface. An ASSIGNMENT REQUEST message shall be input on the MSC-interface requesting a traffic

channel. The response on any interface shall be recorded. 2. The call shall be released, and then step 1 shall be repeated. Message flow

MS BSS MSC ASS REQ <---------------------------- QUEUE IND - ----------------------------> | T11 | CLEAR REQ - ----------------------------> release call ASS REQ ASS CMD - <---------------------------- <---------------------------| T10 | CLEAR REQ - -----------------------------> The messages from the BSSTE will be:

1,2. ASSIGNMENT REQUEST, coded as specified in GSM 08.08 §3.2.1.1. Conformance Requirements

In the case of step 1, a QUEUING INDICATION message shall occur on the MSC-interface concerning the requested TCH. After a time T11=B, a CLEAR REQUEST message shall occur on the MSC-interface concerning the queued resource request.

NOTE: The CLEAR REQUEST in step 1 has the same function as an ASSIGNMENT FAILURE with the cause value "no radio resource available".

In the case of step 2, an ASSIGNMENT COMMAND message shall occur on the radio interface on the main signalling link concerning the requested TCH. After a time T10=A, a CLEAR REQUEST message shall occur on the MSC-interface with the cause value "radio interface message failure", if the BSSTE does not complete the assignment procedure.


1. QUEUING INDICATION, coded as specified in GSM 08.08 §3.2.1.33. 1,2. CLEAR REQUEST, coded as specified in GSM 08.08 §3.2.1.20.

Cause = as in text 2. ASSIGNMENT COMMAND, coded as in GSM 04.08 §9.1.2. Requirement reference:

GSM 04.08 §3.4.3 GSM 08.08 §3.1.17.

8.1.3.25.2 Handover case.

Test Purpose

If the BSS does not have an available TCH as requested by the MSC in the handover resource allocation procedures as tested in section 8.1.3.8, the resource request is put into a queue, and an indication is given to the MSC.

Test Case

Initial Setup

An O&M message as defined by the operator or the manufacturer shall be input on the OMC-interface setting the timer Tqho to an appropriate value A.

An O&M message as defined by the operator or the manufacturer shall be input on the OMC-interface configuring the BSS for "response request".

The BSS shall be put into a state so that an additional resource request (assignment or handover) for a specific channel will cause queuing. How to do it is up to the operator or to the manufacturer.


Description

1. A HANDOVER REQUEST message shall be input on the MSC-interface. The response on any interface shall be recorded.

2. The call shall be released, and then step 1 shall be repeated.

Page 178 GSM 11.23 v.4.4.0: May 1996

Message flow

MS BSS MSC HAND REQ <---------------------------- QUEUE IND - ----------------------------> | Tqho | HAND FAIL - ----------------------------> release call HAND REQ <---------------------------- HAND REQ ACK ----------------------------> The messages from the BSSTE will be:

1,2. HANDOVER REQUEST, as coded in GSM 08.08 §3.2.1.8. Conformance Requirements

In the case of step 1, a QUEUING INDICATION message shall occur on the MSC-interface concerning the requested TCH. After a time Tqho=A, a HANDOVER FAILURE message with the cause value "no radio resource available" shall occur on the MSC-interface.

In the case of step 2, a HANDOVER REQUEST ACKNOWLEDGE message shall occur on the MSC-interface concerning the requested TCH.


1. QUEUING INDICATION, coded as specified in GSM 08.08 §3.2.1.33. 1. HANDOVER FAILURE, coded as specified in GSM 08.08 §3.2.1.16.

Cause = as in text 2. HANDOVER REQUEST ACKNOWLEDGE, coded as defined in GSM 08.08 §3.2.1.10. Requirement reference

GSM 08.08 §3.1.17.

8.1.3.26 Short Message Service Cell Broadcast (SMSCB)

NOTE: As the procedure to initiate the SMS Cell Broadcast function in the BSS is not specified, this function will not be tested for the BSS as a whole.

8.1.3.27 Unequipped circuit

8.1.3.27.1 Unequipped circuit - normal case

Test Purpose

The purpose of this test is to check the BSS behaviour in case an UNEQUIPPED CIRCUIT message is received indicating a circuit(s) that is known to the recipient.

Initial Setup

No special requirements.

Test Case

1. The MSC sends a UNEQUIPPED CIRCUIT message on the A-interface containing a circuit identity code for a circuit which is known at the BSS. The response on any interface shall be recorded.

2. After a short period the MSC sends a HANDOVER REQUEST message on the A-interface

containing the unequipped circuit identity code. The response on any interface shall be recorded. Message Flow

MS BSS MSC UNEQUIPPED CIRCUIT <---------------------------- short delay HANDOVER REQUEST <---------------------------- HANDOVER FAILURE ----------------------------> UNEQUIPPED CIRCUIT ----------------------------> The messages from the BSSTE will be:

1. UNEQUIPPED CIRCUIT - GSM 08.08, 3.2.1.47 Circuit identity code = A (known circuit at BSS)

2. HANDOVER REQUEST - GSM 08.08, 3.2.1.8

Circuit identity code = A Conformance Requirements

In case of step 1 the BSS shall take this circuit out of service and reports it to the O&M system.

In case of step 2 the BSS must return a HANDOVER FAILURE message, followed by an UNEQUIPPED CIRCUIT message.


2. HANDOVER FAILURE - GSM 08.08, 3.2.1.16 Circuit identity code = A

UNEQUIPPED CIRCUIT - GSM 08.08, 3.2.1.47

Circuit identity code = A Requirement reference

GSM 08.08 Chapter 3.1.19.6

8.1.3.27.2 Unequipped circuit used in assignment request message

Test Purpose

The purpose of this test is to check the BSS behaviour when an unknown circuit identity code is requested at the BSS in an ASSIGNMENT REQUEST message.

Initial Setup

A dedicated resource shall be established between the Um-interface and the A-interface. The resource shall not be a TCH.

Page 180 GSM 11.23 v.4.4.0: May 1996

Test Case

1. The BSSTE sends a ASSIGNMENT REQUEST message with unknown Circuit Identity=A. The response on any interface shall be recorded.

Message Flow

MS BSS MSC ASSIGNMENT REQUEST <---------------------------- ASSIGNMENT FAILURE ----------------------------> UNEQUIPPED CIRCUIT ----------------------------> The messages from the BSSTE will be:

1. ASSIGNMENT REQUEST - GSM 08.08, 3.2.1.1 Circuit Identity Code = A (unknown) Conformance Requirements

In case of step 1 the BSS sends an ASSIGNMENT FAILURE message followed by an UNEQUIPPED CIRCUIT message.


1. ASSIGNMENT FAILURE - GSM 08.08, 3.2.1.3 UNEQUIPPED CIRCUIT - GSM 08.08, 3.2.1.47 Circuit Identity Code = A Requirement reference

GSM 08.08 Chapter 3.1.19.6

8.1.3.27.3 Unequipped circuit used in handover request message

Test Purpose

The purpose of this test is to check the BSS behaviour when an unknown circuit identity code is requested at the BSS in a HANDOVER REQUEST message.

Initial Setup


Test Case

1. The BSSTE sends a HANDOVER REQUEST message with unknown Circuit Identity = A. The response on any interface shall be recorded.

Message Flow

MS BSS MSC HANDOVER REQUEST <---------------------------- HANDOVER FAILURE ----------------------------> UNEQUIPPED CIRCUIT ----------------------------> The messages from the BSSTE will be:

1. HANDOVER REQUEST - GSM 08.08, 3.2.1.8 Circuit Identity Code = A (unknown) Conformance Requirements

In case of step 1 the BSS sends a HANDOVER FAILURE message followed by an UNEQUIPPED CIRCUIT message.


1. HANDOVER FAILURE - GSM 08.08, 3.2.1.16 UNEQUIPPED CIRCUIT - GSM 08.08, 3.2.1.47 Circuit Identity Code = A Requirement reference

GSM 08.08 Chapter 3.1.19.6

8.1.3.27.4 Unequipped circuit used in blocking acknowledge message

Test Purpose

The purpose of this test is to check the BSS behaviour when an unknown circuit identity code is used in a BLOCKING ACKNOWLEDGE message from MSC side

Initial Setup

With an O&M message, the BSS shall be commanded to block the terrestrial circuit A.

Test Case

1. The BSSTE sends a BLOCKING ACKNOWLEDGE message with unknown Circuit Identity as acknowledge to the received BLOCK message. The response on any interface shall be recorded.

Message Flow

MS BSS MSC O&M block a terrestrial circuit BLOCK ACK <---------------------------- UNEQUIPPED CIRCUIT ----------------------------> The messages from the BSSTE will be:

1. BLOCKING ACKNOWLEDGE - GSM 08.08, 3.2.1.5 Circuit Identity Code = B (unknown)

Page 182 GSM 11.23 v.4.4.0: May 1996


In case of step 1 the BSS sends an UNEQUIPPED CIRCUIT message.


1. UNEQUIPPED CIRCUIT - GSM 08.08, 3.2.1.47 Circuit Identity Code = B Requirement reference

GSM 08.08 Chapter 3.1.19.6

8.1.3.27.5 Unequipped circuit used in unblocking acknowledge message

Test Purpose

The purpose of this test is to check the BSS behaviour when an unknown circuit identity code is used in an UNBLOCKING ACKNOWLEDGE message from MSC side.

Initial Setup

With an O&M message, the BSS shall be commanded to block the terrestrial circuit A. Then the blocked terrestrial circuit shall be unblocked.

Test Case

1. The BSSTE sends an UNBLOCKING ACKNOWLEDGE message with unknown Circuit Identity as acknowledge to the received UNBLOCKING message. The response on any interface shall be recorded.

Message Flow

MS BSS MSC O&M block and then unblock the same terrestrial circuit UNBLOCK ACK <---------------------------- UNEQUIPPED CIRCUIT ----------------------------> The messages from the BSSTE will be:

1. UNBLOCKING ACKNOWLEDGE - GSM 08.08, 3.2.1.7 Circuit Identity Code = B (unknown) Conformance Requirements

In case of step 1 the BSS sends an UNEQUIPPED CIRCUIT message.



GSM 08.08 Chapter 3.1.19.6

8.1.3.27.6 Unequipped circuit used in reset circuit message

Test Purpose

The purpose of this test is to check the BSS behaviour when an unknown circuit identity code is used in a RESET CIRCUIT message from MSC side.

Initial Setup


Test Case

1. The BSSTE sends a RESET CIRCUIT message with unknown Circuit Identities. The response on any interface shall be recorded.

Message Flow

MS BSS MSC RESET CIRCUIT <---------------------------- UNEQUIPPED CIRCUIT ----------------------------> The messages from the BSSTE will be:

1. RESET CIRCUIT - GSM 08.08, 3.2.1.38 Circuit Identity Code = B (unknown) Cause (O&M intervention) Conformance Requirements

In case of step 1 the BSS sends a UNEQUIPPED CIRCUIT message.



GSM 08.08 Chapter 3.1.19.6

8.1.3.27.7 Unequipped circuit used in circuit group blocking acknowledge message

Test Purpose

The purpose of this test is to check the BSS behaviour when an unknown circuit identity code is used in an CIRCUIT GROUP BLOCKING ACKNOWLEDGE message from MSC side.

Initial Setup

With an O&M message, the BSS shall be commanded to block a group of terrestrial circuits.

Test Case

1. The BSSTE sends a CIRCUIT GROUP BLOCKING ACKNOWLEDGE message with unknown Circuit Identities as acknowledge to the received CIRCUIT GROUP BLOCKING message. The response on any interface shall be recorded.

Page 184 GSM 11.23 v.4.4.0: May 1996

Message Flow

MS BSS MSC O&M block a group of terrestrial circuits CIRCUIT GROUP BLOCK ACK <---------------------------- UNEQUIPPED CIRCUIT ----------------------------> The messages from the BSSTE will be:

1. CIRCUIT GROUP BLOCKING ACKNOWLEDGE - GSM 08.08, 3.2.1.42 Circuit Identity Code (unknown) Circuit Identity Code List (unknown) Conformance Requirements



1. UNEQUIPPED CIRCUIT - GSM 08.08, 3.2.1.47 Circuit Identity Code (unknown) Circuit Identity Code List (unknown) Requirement reference

GSM 08.08 Chapter 3.1.19.6

8.1.3.27.8 Unequipped Circuit used in circuit group unblocking acknowledge message

Test Purpose

The purpose of this test is to check the BSS behaviour when an unknown circuit identity code is used in a CIRCUIT GROUP UNBLOCKING ACKNOWLEDGE message from MSC side

Initial Setup

With an O&M message, the BSS shall be commanded to block a group of terrestrial circuits. Then the blocked group of terrestrial circuits shall be unblocked.

Test Case

1. The BSSTE sends a CIRCUIT GROUP UNBLOCKING ACKNOWLEDGE message with unknown Circuit Identities as acknowledge to the received CIRCUIT GROUP UNBLOCKING message. The response on any interface shall be recorded.

Message Flow

MS BSS MSC O&M block and then unblock the same group of terrestrial circuits CIRCUIT GROUP BLOCK ACK <---------------------------- UNEQUIPPED CIRCUIT ----------------------------> The messages from the BSSTE will be:

1. CIRCUIT GROUP UNBLOCKING ACKNOWLEDGE - GSM 08.08, 3.2.1.44 Circuit Identity Code (unknown) Circuit Identity Code List (unknown) Conformance Requirements



1. UNEQUIPPED CIRCUIT - GSM 08.08, 3.2.1.47 Circuit Identity Code (unknown) Circuit Identity Code List (unknown) Requirement reference

GSM 08.08 Chapter 3.1.19.6

8.1.3.27.9 Unequipped circuit used in unequipped circuit message

Test Purpose

The purpose of this test is to check the BSS behaviour when an unknown circuit identity code is used in an UNEQUIPPED CIRCUIT message from MSC side

Initial Setup


Test Case

1. The MSC sends a UNEQUIPPED CIRCUIT message, containing a circuit identity code for a circuit which is unknown at the BSS side, on the A-interface. The response on any interface shall be recorded.

Message Flow

MS BSS MSC UNEQUIPPED CIRCUIT <---------------------------- The messages from the BSSTE will be:

1. UNEQUIPPED CIRCUIT - GSM 08.08, 3.2.1.47

Circuit identity code (unknown at BSS)


In case of step 1 the BSS shall not start any actions, i.e. not returning any UNEQUIPPED CIRCUIT message.


1. no messages


GSM 08.08 Chapter 3.1.19.6

Page 186 GSM 11.23 v.4.4.0: May 1996

8.1.3.28 Confusion

8.1.3.28.1 Confusion - reserved element used

Test Purpose

The purpose of this test is to check the BSS behaviour to handle messages with erroneous contents. Here the DLCI information element for a LOCATION UPDATING ACCEPT message from MSC side has a reserved value.

Initial Setup

Establish a radio connection between MS and BSS. The MS then sends a LOCATION UPDATE REQUEST to the MSC.

Test Case

1. The MSC sends a LOCATION UPDATING ACCEPT message (DTAP) containing a DLCI in the BSSAP header with a reserved value on the A-interface. The response on any interface shall be recorded.

Message Flow

MS BSS MSC LOCATION UPDATING ACCEPT <---------------------------- CONFUSION ----------------------------> The messages from the BSSTE will be:

1. LOCATION UPDATING ACCEPT - GSM 04.08, 9.2.13 the DLCI in the BSSAP header is not equal to the values 0 or 1 - GSM 08.06, 6.3 Conformance Requirements

In case of step 1 the BSS must return a CONFUSION message. The error pointer shall indicate the reserved DLCI value


2. CONFUSION - GSM 08.08, 3.2.1.45


GSM 08.08 Chapter 2.4

8.1.3.28.2 Confusion - zero length value

Test Purpose

The purpose of this test is to check the BSS behaviour to handle messages with erroneous contents. Here the length octet in the BSSAP header of a LOCATION UPDATING ACCEPT message from MSC side has a zero value.

Initial Setup


Test Case

1. The MSC sends a LOCATION UPDATING ACCEPT message (DTAP) containing a zero length value in the BSSAP header, on the A-interface. The response on any interface shall be recorded.

Message Flow


1. LOCATION UPDATING ACCEPT - GSM 04.08, 9.2.13 the length value information in the BSSAP header is equal to 0 - GSM 08.06, 6.3 Conformance Requirements

In case of step 1 the BSS must return a CONFUSION message. The error pointer shall indicate the zero length value


2. CONFUSION - GSM 08.08, 3.2.1.45



8.1.3.28.3 Confusion, inconsistent length value

Test Purpose

The purpose of this test is to check the BSS behaviour to handle messages with erroneous contents. Here the length octet in the BSSAP header of a LOCATION UPDATING ACCEPT message from MSC side has a inconsistent value, relating to the SCCP length value.

Initial Setup


Test Case

1. The MSC sends a LOCATION UPDATING ACCEPT message (DTAP) containing a inconsistent length value in the BSSAP header relating to the SCCP length value, on the A-interface. The response on any interface shall be recorded.

Page 188 GSM 11.23 v.4.4.0: May 1996

Message Flow


1. LOCATION UPDATING ACCEPT - GSM 04.08, 9.2.13 the length value in the BSSAP header is inconsistent to the relating SCCP length value - GSM 08.06, 6.3 Conformance Requirements

In case of step 1 the BSS must return a CONFUSION message. The error pointer shall indicate the mismatching length value


2. CONFUSION - GSM 08.08, 3.2.1.45



9 Base station controller network aspects

The use of the A-bis-interface is optional for a GSM PLMN operator. However, if one or more transceiver units of a BSS are not colocated with the control functions of the BSS, the BSS shall be split into the 2 functional entities Base Station Controller (BSC) and Base Transceiver Station(s) (BTS(s)). See also section 1 in this specification.

The tests in this section apply to the BSC, if used.

9.1 Base station controller network functions

9.1.1 General

The interface between the Base Station Controller (BSC) and the Base Transceiver Station (BTS) is defined in GSM 08.5x and 08.6x. The interface supports the transcoding/rate adaptation functions positioned in the BTS, or in the BSC or at the MSC site.

This section verifies the network functions of a BSC.

Specifically, the Layer 3 tests in this section verify mainly the Layer 3 protocols related to the A-bis-interface. In order to test the complete Layer 3 (3-7) protocols in a BSC, the complete set of tests of the BSS as a whole defined in section 8.1.3 shall therefore be carried out after the tests defined in this section with the modification that radio interface messages not existing on the A-bis-interface shall be replaced by the appropriate A-bis-interface messages according to the test Descriptions for the BTS in section 10.1.3 and defined in GSM 08.58.

The functional split between the BSC and the BTS is defined in detail in GSM 08.52. Of the main BSS network functions listed in section 8.1.1 the BSC can roughly be defined to include the following:

Functions in the BSC:

management of radio channels management of terrestrial channels mapping between radio and terrestrial channels handover execution Functions in the BSC or BTS:

transcoding/rate adaptation The logical functions which can be tested at Layer 3 are tested in sections 9.1.2 and 9.1.3. The transcoding and rate adaptation functions are tested in GSM TS 11.24.

As for the BSS seen as a whole, the Layer 3 messages on each interface of the BSC can be divided into 2 categories:

transparent messages non-transparent messages All the messages which are transparent to the BSS as a whole (DTAP messages) are consequently transparent also to the BSC. Messages which are non-transparent to the BSS as a whole may also be transparent to the BSC.

As for the BSS as a whole (see section 8.1.3), the non-transparent Layer 3 procedures are tested as elementary procedures, not as structured procedures. The tests are intended to cover all normal and abnormal cases of significance within each elementary procedure. However, all possible error cases are not tested, normally only if they imply different message sequences. The tests in this section are performed under perfect transmission conditions and under no limiting conditions.

Page 190 GSM 11.23 v.4.4.0: May 1996

9.1.2 Transparent messages

On the A-bis-interface, "transparent" messages are treated in a specific way. See sections 9.1.3.5 and 9.1.3.6 for testing of messages transparent to the BSC in the downlink (MSC to BTS) and uplink (BTS to MSC) directions, respectively.

9.1.3 Non-transparent messages

The tests described in this section are to verify that messages sent to the Base Station Controller (BSC) using the RR or A-bis-interface non-transparent Layer 3 procedures have the correct consequential actions, and that combinations of certain events cause the correct messages to be sent via the RR or A-bis-interface non-transparent Layer 3 procedures on the A-interface or A-bis-interface by the BSC. Time constraints have to be met.

BSSMAP procedures for the BSC are not tested explicitly here, but are tested using the tests for the BSS as whole and the radio interface to A-bis-interface message mapping given by the tests of the BTS in section 10.1.

The following non-transparent Layer 3 procedures are to be tested in the BSC:

Radio link layer management:

1. Link establishment indication 2. Link establishment request 3. Link release indication 4. Link release request 5. Transmission of transparent L3-message in acknowledged mode 6. Reception of transparent L3-message in acknowledged mode 7. Transmission of transparent L3-message in unacknowledged mode 8. Reception of transparent L3-message in unacknowledged mode 9. Link error indication

Dedicated channel management:

10. Channel activation 11. Channel mode modify 12. Handover detection 13. Start of encryption 14. Measurement reporting 15. Deactivate SACCH 16. Radio channel release 17. MS power control 18. Transmission power control 19. Connection failure 20. Physical context request 21. Sacch information modify

Common channel management:

22. Channel request by MS 23. Paging 24. Delete indication 25. CCCH load indication 26. Broadcast information modify 27. Immediate assignment 28. Short Message Service Cell Broadcast (SMSCB)

TRX management:

29. Radio resource indication 30. SACCH filling information modify

31. Flow control 32. Error reporting

Details of the correct operation of these procedures are to be found in GSM 08.08 and GSM 08.58. GSM 04.08 is also implicitly applicable.

The same overall requirements as for the tests of the BSS as a whole in section 8.1.3 apply.

9.1.3.1 Link establishment indication

Test Purpose

The link establishment indication procedure is used by the BTS to indicate to the BSC that a LAPDm Layer 2 link on the radio path has been established in a multi-frame mode on the initiative of an MS. The BSC can use this indication to set up an SCCP connection to the MSC.

The ESTABLISH INDICATION messages may contain an information element. If there is an information element, this is one of the following Layer 3 service request messages (see GSM 08.06, section 6.1.1):

LOCATION UPDATING REQUEST CM SERVICE REQUEST PAGING RESPONSE IMSI DETACH INDICATION CM REESTABLISHMENT REQUEST

The CM SERVICE REQUEST message may concern a normal call or e.g. a Short Message Service (SMS).

Test Case

Initial Setup

An O&M-message as defined by the operator or the manufacturer shall be input over the OMC-

interface by the BSSTE setting the timer T3101 to an appropriate value A.

The channel activation procedure in section 9.1.3.10 ending with an IMMEDIATE ASSIGN COMMAND message shall be performed.

Description

1. When the BSC sends an IMMEDIATE ASSIGN COMMAND message on the A-bis-interface, the BSC also starts timer T3101. Before expiry of timer T3101, the BSSTE shall input an ESTABLISH INDICATION message on the A-bis-interface. The response on any interface shall be recorded.

2. Step 1 shall be repeated, but the ESTABLISH INDICATION message shall not be generated by the

BSSTE. 3. Step 1 shall be repeated, but with the ESTABLISH INDICATION message containing each of the

above service requests in turn.

Page 192 GSM 11.23 v.4.4.0: May 1996

Message Flow

BTS BSC MSC IMM ASS CMD <----------------------------- - EST IND T3101 -----------------------------> - SCCP establishment or IMM ASS CMD <----------------------------- - RF CHAN REL T3101 expiry <----------------------------- x or IMM ASS CMD <----------------------------- - EST IND(L3 message) T3101 -----------------------------> - SCCP establishment COMPL L3 INFO (L3 message) ----------------------------> The messages from the BSSTE will be:

1. ESTABLISH INDICATION - GSM 08.58 8.3.6 Channel number Link identifier Layer 3 information = none

3. ESTABLISH INDICATION - GSM 08.58 8.3.6 Channel number Link identifier Layer 3 information = LOC UPD REQ, CM SERV REQ, PAG RES, IMSI DET IND, CM

REEST REQ.


In the case of step 1, the mobile originated transaction shall proceed in a normal way, i.e. an SCCP connection shall be established by the BSC to the MSC and the dedicated channel allocated by the BSC shall be maintained.

In the case of step 2, an RF CHANNEL RELEASE message may occur on the A-bis-interface after the timeout of T3101=A. No messages shall be generated on the MSC-interface by the BSC and the SCCP connection shall not be established.

In the case of step 3, the mobile originated call setup shall proceed in a normal way, i.e. an SCCP connection shall be established by the BSC to the MSC and the relevant service request message shall occur on the MSC-interface exactly as contained in the ESTABLISH INDICATION message.

The messages from the BSC shall be:

2. RF CHANNEL RELEASE - GSM 08.58 8.4.14 Channel number

3. COMPLETE LAYER 3 INFORMATION (LOCATION UPDATING REQUEST) GSM 08.08 3.2.1.32 Cell identifier

Layer 3 information = LOC UPD REQ (Location updating type Ciphering key sequence number Location area identification Mobile Station classmark 1 Mobile identity) Chosen channel (optional)

3. COMPLETE LAYER 3 INFORMATION (CM SERVICE REQUEST) GSM 08.08 3.2.1.32 Cell identifier Layer 3 information = CM SERV REQ (CM service type Ciphering key sequence number Mobile Station classmark 2 Mobile identity) Chosen channel (optional)

3. COMPLETE LAYER 3 INFORMATION (PAGING RESPONSE) GSM 08.08 3.2.1.32 Cell identifier Layer 3 information = PAG RES (Ciphering key sequence number Mobile Station classmark 2 Mobile identity) Chosen channel (optional)

3. COMPLETE LAYER 3 INFORMATION (IMSI DETACH INDICATION) GSM 08.08 3.2.1.32 Cell identifier Layer 3 information = IMSI DET IND (Mobile Station classmark 1 Mobile identity) Chosen channel (optional)

3. COMPLETE LAYER 3 INFORMATION (CM REESTABLISHMENT REQUEST) GSM 08.08 3.2.1.32 Cell identifier Layer 3 information = CM REEST REQ (Ciphering key sequence number Location area identification Mobile Station classmark 2 Mobile identity) Chosen channel (optional)


This operation is described in GSM 08.58, section 3.1.

9.1.3.2 Link establishment request

Test Purpose

The link establishment request procedure is used by the BSC to request the establishment by the BTS of a LAPDm link over the radio path. This procedure applies only to the Short Message Service (SMS) with SAPI=3 (see GSM 04.06 5.4.1.1).

Page 194 GSM 11.23 v.4.4.0: May 1996

Test Case

Initial Setup

1. A dedicated resource shall be set up between the MSC-interface and the A-bis-interface without a SAPI 3 link established.

Description

1. Then any DTAP message indicating SAPI=3 shall be input on the MSC-interface. The response on any interface shall be recorded.

2. An ESTABLISH CONFIRM message shall be input on the A-bis-interface. The response on any

interface shall be recorded. Message Flow

BTS BSC MSC Any DTAP message (SAPI=3) <---------------------------- EST REQ <---------------------------- EST CONF ----------------------------> Any DTAP message (SAPI=3) <-------------------------------- The messages from the BSSTE will be:

1. DTAP Message 2. ESTABLISH CONFIRM - GSM 08.58 8.3.5

Channel number Link identifier


In the case of step1, the BSC shall output an ESTABLISH REQUEST message on the Abis-interface.

In the case of step 2, the DTAP message will appear on the Abis-interface.


1. ESTABLISH REQUEST - GSM 08.58 8.3.4 Channel number Link identifier

2. DTAP MESSAGE Requirements Reference

The operation is described in GSM 08.58, section 3.2.

9.1.3.3 Link release indication

Test Purpose

The link release indication procedure is used by the BTS to indicate to the BSC that a Mobile Station has disconnected the LAPDm link on the radio interface.

Depending on the link affected (SAPI=0 or SAPI=3) and on the context the BSC’s reaction will be different. The test is only performed for SAPI=3 concerning a Short Message Service (SMS).

Test Case

Initial Setup

A dedicated resource shall be set up between the A-bis-interface and the MSC-interface.

Description

1. A RELEASE INDICATION message indicating SAPI=3 shall be input on the A-bis-interface. The response on any interface shall be recorded.

2. Then any DTAP message indicating SAPI=3 shall be input on the MSC-interface. The BSC shall

establish the SAPI 3 link as described in section 9.1.3.2. The response on any interface shall be recorded.

Message Flow

BTS BSC MSC REL IND (SAPI=3) ------------------------------> Any DTAP message (SAPI=3) <---------------------------------- EST REQ (SAPI=3) <------------------------------- The messages from the BSSTE will be:

1. RELEASE INDICATION - GSM 08.58 8.3.9 Channel number Link identifier

2. DTAP Message Conformance Requirements

In the case of step 2, an ESTABLISH REQUEST message indicating SAPI = 3 shall occur on the A-bis-interface for the relevant link.


2. ESTABLISH REQUEST - GSM 08.58 8.3.4 Channel number Link identifier


The operation is defined in GSM 08.58, section 3.3.

Page 196 GSM 11.23 v.4.4.0: May 1996

9.1.3.4 Link release request

Test Purpose

The link release request procedure is used by the BSC to request a BTS to disconnect the LAPDm link on the radio interface.

Test Case

Initial Setup

A dedicated resource shall be set up between the MSC-interface and the A-bis-interface, and a Short Message Service shall be set up to the same mobile station.

Description

1. An ERROR INDICATION message, with the cause value set to "unsolicited DM response, multiple frame established state", "sequence error" or "timer T200 expired (N200+1) times", shall be input on the A-bis-interface concerning the SAPI=3 link of the Short Message Service. The response on any interface shall be recorded.

2. A RELEASE CONFIRM message shall be input on the A-bis-interface. The response on any

interface shall be recorded. 3. Then any DTAP message indicating SAPI=3 shall be input on the MSC-interface. The BSC shall

establish the SAPI 3 link as described in section 9.1.3.2. The response on any interface shall be recorded.

Message Flow

BTS BSC MSC ERR IND (SAPI=3) ---------------------------> REL REQ (SAPI=3) <--------------------------- REL CONF (SAPI=3) ---------------------------> Any DTAP message (SAPI=3) <------------------------------ EST REQ (SAPI=3) <--------------------------- The messages from the BSSTE will be:

1. ERROR INDICATION - GSM 08.58, 8.3.3 Channel number Link identifier RLM cause = as in text

2. RELEASE CONFIRM - GSM 08.58, 8.3.8


3. DTAP Message Conformance Requirements

In the case of step 1, a RELEASE REQUEST message indicating SAPI=3 shall occur on the A-bis-interface for the correct link.

In the case of step 3, an ESTABLISH REQUEST message indicating SAPI = 3 shall occur on the A-bis-interface for the relevant link.


1. RELEASE REQUEST - GSM 08.58, 8.3.7. Channel number Link identifier Release mode

3. ESTABLISH REQUEST - GSM 08.58 8.3.4



This operation is defined in GSM 08.58, section 3.4.

9.1.3.5 Transmission of transparent L3-message in acknowledged mode

Test Purpose

This procedure is used to send a message which is transparent to the BTS over the radio path in acknowledged mode. The procedure applies to all downlink DTAP messages.

Test Case

Initial Setup

The link establishment indication procedure as in 9.1.3.1 shall be performed.

Description

1. A DTAP downlink message shall be input on the A interface by the BSSTE.

The response on any interface shall be recorded.

2. Step 1 shall be repeated until at least one MM message and one CC message have been tested. These messages are listed in GSM 04.08 section 4.3, 4.4, 4.5 and in GSM04.08 section 5.2, 5.3, 5.4, 5.5.

BTS BSC MSC Any DTAP message <---------------------------- DATA REQ ( DTAP message) <----------------------------- Conformance Requirements

A DATA REQUEST message including the appropriate DTAP message as Layer 3 information parameter shall occur on the Abis-interface.

The message from BSC shall be:

DATA REQUEST - GSM 08.58, 8.3.1. Channel number Link identifier Layer 3 information = DTAP message

Page 198 GSM 11.23 v.4.4.0: May 1996



9.1.3.6 Reception of transparent L3-message in acknowledged mode

Test Purpose

This procedure is used to indicate reception in acknowledged mode of a L3 transparent message on the air interface. . The procedure applies to all uplink DTAP messages.

Test Case

Initial Setup

The link establishment indication procedure as in 9.1.3.1 shall be performed.

Description

1. A DATA INDICATION message carrying a DTAP message as Layer 3 information parameter shall be input on the Abis-interface by the BSSTE. The response on any interface shall be recorded.

2. Step 1 shall be repeated at least until one MM message and one CC message have been tested.

Message Flow

BTS BSC MSC DATA IND (any DTAP message) ----------------------------> DTAP message --------------------------> The messages from the BSSTE will be: DATA INDICATION - GSM 08.58, 8.3.2.

Channel number Link identifier Layer 3 information = DTAP message


The BSC shall output the appropriate DTAP message within a SCCP DT1 message on the A interface.

The message of the BSC shall be:

DTAP message



9.1.3.7 Transmission of transparent L3-message in unacknowledged mode

Test Purpose

This procedure is used to send a message which is transparent to the BTS over the radio path in unacknowledged mode by coding it into a UNIT DATA REQUEST message on the A-bis-interface. The signalling procedure is given in GSM 08.58, section 3.7.

NOTE: As there are no such messages defined, and there are no restrictions defined on how the BSC shall generate such messages towards the BTS, testing of such a procedure does not apply to the BSC.

9.1.3.8 Reception of transparent L3-message in unacknowledged mode

Test Purpose

This procedure is used to receive a message which is transparent to the BTS over the radio path in unacknowledged mode by coding it into a UNIT DATA INDICATION message on the A-bis-interface. The signalling procedure is given in GSM 08.58, section 3.8.

NOTE: As there are no such messages defined, and there are no restrictions defined on how the BSC shall react to such messages from the BTS, testing of such a procedure does not apply to the BSC.

9.1.3.9 Link error indication

Test Purpose

The link error indication procedure is used by the BTS to indicate to the BSC abnormal situations, like protocol errors and complete lack of LAPDm acknowledgements. The signalling procedure is given in GSM 08.58, section 3.9.

NOTE 1: The response of a BSC to an ERROR INDICATION message depends on the context and may be manufacturer dependent. Consequently this procedure is not tested.

NOTE 2: The CLEAR REQUEST message and the channel release procedure might be used.

9.1.3.10 Channel activation

Test Purpose

The channel activation procedure is used to activate a channel in the BTS for an MS which then will be commanded to the channel by an IMMEDIATE ASSIGNMENT, an IMMEDIATE ASSIGNMENT EXTENDED, an ASSIGNMENT COMMAND, an ADDITIONAL ASSIGNMENT or a HANDOVER COMMAND message over the radio interface.

Test Case

Initial Setup

1. No channel shall be activated in the BSC. Description

1. A CHANNEL REQUIRED message shall be input on the A-bis-interface. The response on the A-bis-interface shall be recorded. No further messages shall be input.

2. A CHANNEL ACTIVATION ACKNOWLEDGE message shall then be input over the A-bis-interface.


Page 200 GSM 11.23 v.4.4.0: May 1996

3. Steps 1 and 2 shall be repeated, but the CHANNEL ACTIVATION ACKNOWLEDGE message

shall be replaced by a CHANNEL ACTIVATION NEGATIVE ACKNOWLEDGEMENT message with an appropriate cause value. The response on any interface shall be recorded.

4. Steps 1-3 shall be repeated, but the CHANNEL REQUIRED message shall be replaced by a

HANDOVER REQUEST message on the MSC-interface. 5. An O&M-message as defined by the operator or the manufacturer shall be input on the OMC- interface taking all channels out of service. Then step 1 shall be repeated. Message Flow

BTS BSC MSC CH RQD ----------------------------------> CH ACTIV <----------------------------------- CH ACTIV ACK ----------------------------------> IMM ASS CMD <----------------------------------- Message Flow (Handover case - step 4)

BTS BSC MSC HAND REQ <------------------------------ CH ACTIV <----------------------------- CH ACTIV ACK ----------------------------> HAND REQ ACK -------------------------------> The messages from the BSSTE will be:

1, 3, 5. CHANNEL REQUIRED - GSM 08.58, 8.5.3. Channel number Request reference = PAR1 Access Delay Physical context (optional)

2, 4. CHANNEL ACTIVATION ACKNOWLEDGE - GSM 08.58, 8.4.2. Channel number Frame number

3, 4. CHANNEL ACTIVATION NEGATIVE ACKNOWLEDGE - GSM 08.58, 8.4.3. Channel number Cause

4. HANDOVER REQUEST - GSM 08.08, 3.2.1.8. Channel type Encryption information Classmark information (1 or 2) Cell identifier (serving) Priority (optional) Circuit identity code (optional) Downlink DTX flag (optional) Cell identifier (target) Interference band to be used (optional)

Cause (optional) Classmark information 3 (optional) Current channel

5. O&M MESSAGE Conformance Requirements

In the case of step 1, a CHANNEL ACTIVATION message shall occur on the A-bis-interface. No further messages shall occur on any interface.

In the case of step 2, an IMMEDIATE ASSIGN COMMAND message shall occur on the A-bis-interface indicating normal or extended immediate assignment.

In the case of step 3, no IMMEDIATE ASSIGN COMMAND message shall occur on the A-bis-interface.

In the case of step 4, a HANDOVER REQUEST ACKNOWLEDGE message shall occur on the MSC-interface instead of the IMMEDIATE ASSIGN COMMAND message on the A-bis-interface. Otherwise the same requirements as in steps 1-3 apply.

In the case of step 5, an IMMEDIATE ASSIGN COMMAND message may occur on the A-bis-interface indicating immediate assignment rejection. No message shall occur on the MSC-interface.


1, 3, 4. CHANNEL ACTIVATION - GSM 08.58, 8.4.1. Channel number Activation type Channel mode Channel identification (optional) Encryption information (optional) Handover reference (conditional) - only case 4 BS power (optional) MS power (optional) Timing advance (conditional) BS power parameters (optional) MS power parameters (optional) Physical context (optional) SACCH information (optional)

2,5 IMMEDIATE ASSIGN COMMAND - GSM 08.58, 8.5.6 Channel number Full Immediate assign info = as in text

4. HANDOVER REQUEST ACKNOWLEDGE - GSM 08.08, 3.2.1.10. Layer 3 information Chosen channel (optional) Chosen encryption algorithm (optional) Circuit pool (optional)



NOTE: The operations "Channel request by the MS"(GSM08.58 section 5.1) and "Immediate assignment procedure (GSM 08.58 section 5.3) are also implicitly tested.

Page 202 GSM 11.23 v.4.4.0: May 1996

9.1.3.11 Channel mode modify

Test Purpose

The channel mode modify procedure is used by the BSC to request a change of the channel mode of an active channel. The channel mode is related to transcoding and rate adaptation functions and includes consequently also channel coding functions.

NOTE: The channel mode modify procedure is always invoked by an ASSIGNMENT REQUEST message from the MSC, but it is not specified in which cases the mapping shall be a channel mode modification rather than an assignment or handover. It is a national or operator specific matter to define this mapping, and the test applies when this mapping exists, possibly with other modes than indicated here. See also note for the BSS as a whole in section 8.1.3.11.

Test Case

Initial Setup

A call shall be established between the A-bis-interface and the MSC-interface on a TCH/F9.6.

Description

1. An ASSIGNMENT REQUEST message shall be input on the MSC-interface requesting a TCH/F4.8 for the call previously set up. The response on any interface shall be recorded.

2. A MODE MODIFY ACKNOWLEDGE message shall be input on the A-bis-interface. The response

on any interface shall be recorded. 3. A DATA INDICATION (CHANNEL MODE MODIFY ACKNOWLEDGE) message shall be input on

the A-bis-interface. The response on any interface shall be recorded. 4. Step 2 shall be repeated, but requesting a TCH/F2.4 and a MODE MODIFY NEGATIVE

ACKNOWLEDGEMENT message with the cause value "radio resource not available" shall be input on the A-bis-interface. The response on any interface shall be recorded.

NOTE: The test is carried out with the assumption that the mode is first modified in the BTS

and then in the MS. There are no restrictions on the order of these 2 procedures. It could also be imagined that the order is reversed, in which case steps 3 and 4 should be swapped, and also that the BSC does not wait for acknowledgement from e.g. the BTS before commanding the MS to modify the mode.

Message Flow

BTS BSC MSC ASS REQ <---------------------------- MODE MOD <--------------------------- MODE MOD ACK --------------------------> DATA REQ (CH MODE MOD) <--------------------------- DATA IND (CH MODE MOD ACK) ---------------------------> ASS COM ---------------------------->


1, 4 ASSIGNMENT REQUEST - GSM 08.08, 3.2.1.1. Channel type = TCH/F4.8, TCH/F2.4 Layer 3 header information (optional) Priority (optional) Circuit identity code (optional) Downlink DTX flag (optional) Interference band to be used (optional) Classmark information 2 (optional)

2. MODE MODIFY ACKNOWLEDGE - GSM 08.58, 8.4.10. Channel number

3. DATA INDICATION - GSM 08.58, 8.3.2 Channel number Link identifier Layer 3 information = CHANNEL MODE MODIFY ACKNOWLEDGE

with Channel Description Channel mode = TCH/F4.8

4. MODE MODIFY NEGATIVE ACKNOWLEDGE - GSM 08.58, 8.4.11. Channel number Cause = as in text


In the case of step 1, a MODE MODIFY message shall occur on the A-bis-interface. The new mode shall be TCH/F4.8.

In the case of step 2, a DATA REQUEST message including a CHANNEL MODE MODIFY message as Layer3 information parameter shall occur on the A-bis-interface. The new mode shall be TCH/F4.8.


In the case of step 4, an ASSIGNMENT FAILURE message with the cause value "no radio resource available" shall occur on the MSC-interface.


1, 4. MODE MODIFY - GSM 08.58, 8.4.9. Channel number Channel mode = TCH/F4.8, TCH/F2.4

2. DATA REQUEST - GSM 08.58, 8.3.1 Channel number Link identifier Layer 3 information = CHANNEL MODE MODIFY with

Channel Description Channel mode = TCH/F4.8

3. ASSIGNMENT COMPLETE - GSM 08.08, 3.2.1.2. RR cause (optional) Cell identifier (optional) Chosen channel (optional) Chosen encryption algorithm (optional) Circuit pool (optional)

5. ASSIGNMENT FAILURE - GSM 08.08, 3.2.1.3. Cause = as in text

Page 204 GSM 11.23 v.4.4.0: May 1996

RR cause (optional) Circuit pool (optional) Circuit pool list (optional)

Requirement Reference


9.1.3.12 Handover detection

Test Purpose

This procedure is used between the target BTS and BSC when an MS which has been handed over accesses the new BTS. When a handover access is detected by the BTS, the BSC is notified. The MSC shall be notified as well.

Test Case

Initial Setup

The channel activation procedure concerning handover in section 9.1.3.10 shall be carried out.

Description

After the HANDOVER REQUEST ACKNOWLEDGE message on the MSC-interface, a HANDOVER DETECTION message shall be input on the A-bis-interface. The response on any interface shall be recorded.

Message Flow

BTS BSC MSC Channel activation ( Handover) HAND DET ---------------------------> HAND DETECT --------------------------> The messages from the BSSTE will be:

2. HANDOVER DETECTION - GSM 08.58, 8.4.7. Channel number Access delay (optional)


In the case of step 2, a HANDOVER DETECT message shall occur on the MSC-interface.


2. HANDOVER DETECT - GSM 08.08, 3.2.1.40. Requirements Reference


9.1.3.13 Encryption

9.1.3.13.1 Start of encryption

Test Purpose

The purpose of the start of encryption procedure is after authentication to initialise and synchronise the stream ciphering devices in the BSS and in the MS. The MS and MSC already know the cipher key Kc from the authentication procedure.

Test Case

1. A dedicated resource shall be set up between the MSC-interface and the A-bis-interface. Ciphering shall not be activated.

2. A CIPHER MODE COMMAND message shall be input on the MSC-interface containing the

permitted A5/x ciphering algorithms and the key Kc. The response on the any interface shall be recorded.

3. The BSSTE shall input a DATA INDICATION message including a CIPHERING MODE

COMPLETE message as Layer 3 information parameter on the A-bis-interface. The response on any interface shall be recorded.

Message Flow

BTS BSC MSC CIPHER MODE CMD <---------------------------------- ENCR CMD <--------------------------- DATA IND (CIPH MODE COM) ---------------------------> CIPHER MODE COM ----------------------------------> The messages from the BSSTE will be:

2. CIPHER MODE COMMAND - GSM 08.08, 3.2.1.30 Layer 3 header information (optional) Encryption information Cipher mode response (optional)

3. DATA INDICATION - GSM 08.58, 8.3.2 Channel number Link identifier Layer 3 information = CIPHERING MODE COMPLETE with

Mobile identity (optional) Conformance Requirements

In the case of step 2, an ENCRYPTION COMMAND message shall occur on the A-bis-interface.

In the case of step 3, a CIPHER MODE COMPLETE message shall occur on the MSC-interface.


2. ENCRYPTION COMMAND - GSM 08.58, 8.4.6. Channel number Encryption information Link identifier

Page 206 GSM 11.23 v.4.4.0: May 1996

Layer 3 information (CIPHER MODE CMD)

3. CIPHER MODE COMPLETE - GSM 08.08, 3.2.1.31. Layer 3 messages contents (optional) Chosen encryption algorithm (optional)



9.1.3.13.2 Stop of encryption

Test Purpose

This procedure is used to stop encryption on a channel.

Test Case

1. A dedicated resource shall be set up between the MSC-interface and the A-bis-interface. Ciphering shall be activated.

2. A CIPHER MODE COMMAND message shall be input on the MSC-interface containing "no

encryption" algorithm. The response on the any interface shall be recorded. 3. The BSSTE shall input a DATA INDICATION message including a CIPHERING MODE

COMPLETE message as Layer3 information parameter on the A-bis-interface. The response on any interface shall be recorded.

Message Flow

BTS BSC MSC CIPHER MODE CMD <---------------------------------- ENCR CMD <--------------------------- DATA IND (CIPH MODE COM) ---------------------------> CIPHER MODE COM ----------------------------------> The messages from the BSSTE will be :


3. DATA INDICATION - GSM 08.58, 8.3.1 Channel number Link identifier Layer 3 information = CIPHERING MODE COMPLETE with

Mobile identity (optional) Conformance Requirements


In the case of step 3, a CIPHER MODE COMPLETE message shall occur on the MSC-interface.

The messages from the BSC shall be :

2. ENCRYPTION COMMAND - GSM 08.58, 8.4.6. Channel number Encryption information Link identifier Layer 3 information (CIPHER MODE CMD)

3. CIPHER MODE COMPLETE - GSM 08.08, 3.2.1.31. Layer 3 messages contents (optional) Chosen encryption algorithm (optional)



9.1.3.13.3 Failure case

Test Purpose

To check the BSC behaviour when the BTS is unable to handle the requested ciphering algorithm.

Test Case

1. A dedicated resource shall be set up between the MSC-interface and the A-bis-interface. Ciphering shall not be activated.

2. A CIPHER MODE COMMAND message shall be input on the MSC-interface containing an A5/x

ciphering algorithm which is not supported by the BTS. The response on the any interface shall be recorded.

3. The BSSTE shall input the ERROR REPORT message with the cause value set to "encryption

algorithm not implemented" on the A-bis-interface. The response on any interface shall be recorded.

Message Flow

BTS BSC MSC CIPHER MODE CMD <---------------------------------- ENCR CMD <--------------------------- ERR REP ---------------------------> CIPHER MODE REJ ----------------------------------> The messages from the BSSTE will be :


3. ERROR REPORT - GSM 08.58, 8.6.4 Cause = as in text Message identifier (optional) Channel number (optional) Link identifier (optional) Erroneous message (optional)

Page 208 GSM 11.23 v.4.4.0: May 1996



In the case of step 3, a CIPHER MODE REJECT message with the cause value set to "ciphering algorithm not supported" shall occur on the MSC-interface.

The messages from the BSC shall be :

2. ENCRYPTION COMMAND - GSM 08.58, 8.4.6. Channel number Encryption information Link identifier Layer 3 information (CIPHER MODE CMD)

3. CIPHER MODE REJECT - GSM 08.08, 3.2.1.48. Cause = as in text




The Mobile Station reports regularly on the SACCH to the BTS on measurements it has performed on the downlink radio channel. Similarly, the BTS measures the uplink radio channel. This information is signalled to the BSC and is used in the BSC in the handover and RF power control algorithms. Optionally, the BTS may preprocess the measurement results. The handover and RF power control algorithms are a national or operator specific matter.

Since the handover and power control algorithms are a national or operator specific matter, no test can be defined for the BSC’s response to the various measurement results received.

The fact that the MEASUREMENT RESULT (or PREPROCESSED MEASUREMENT RESULT) messages are registered in the BSC is implicitly verified in sections 9.1.3.17-18 (MS power control and transmission power control).

9.1.3.14.1 Basic measurement reporting

Testing of this procedure is not applicable to the BSC.

9.1.3.14.2 Preprocessed measurement reporting (optional)

Testing of this procedure is not applicable to the BSC.

9.1.3.14.3 Preprocessing configuration (optional)

Test Purpose

If the BTS shall utilise preprocessing, it must first be configured for this kind of operation.

Test Case

Initial Setup

None

Description

An O&M message as defined by the operator or the manufacturer shall be input on the OMC-interface commanding measurement preprocessing in the BTS. The response on any interface shall be recorded.

Message Flow

BTS BSC MSC O&M PREPROC CONFIG <---------------------------- The messages from the BSSTE will be:


In the case of step 1, a PREPROCESS CONFIGURE message shall occur on the A-bis-interface with appropriate preprocessing parameters.


1. PREPROCESS CONFIGURE - GSM 08.58, 8.4.17. Channel number Preprocessing parameters


This operation is described in GSM 08.58, section 4.5.2.1.

9.1.3.15 Deactivate SACCH

Test Purpose

The deactivate SACCH procedure is used by the BSC to order the BTS to deactivate the SACCH.

Test Case

Initial Setup

A call shall be set up between the A-bis-interface and the MSC-interface. The radio conditions shall be nonlimiting. An O&M message as defined by the operator or the manufacturer shall be input on the OMC-interface setting timer T3109 to value A.

Description 1. A CLEAR COMMAND message shall be input on the MSC-interface for the call in question. The

response on any interface shall be recorded. 2. The test shall be stopped by inputting an RF CHANNEL RELEASE ACKNOWLEDGE message on

the A-bis-interface. 3. A new call shall be set up between the MSC-interface and the A-bis-interface of the BSC. Then, the

connection failure test in section 9.1.3.19 shall be carried out, and steps 2-3 shall be repeated.

Page 210 GSM 11.23 v.4.4.0: May 1996

BTS BSC MSC CLEAR COMMAND <----------------------------------- DEACT SACCH CLEAR COMPLETE <------------------------------*----------------------------------> DATA REQ (CH REL) | <------------------------------- | T3109 | RF CH REL | <-------------------------------- RF CH REL ACK -------------------------------> The messages from the BSSTE will be:

1,3. CLEAR COMMAND - GSM 08.08, 3.2.1.21. Layer 3 header information (optional) Cause

2,3. RF CHANNEL RELEASE ACKNOWLEDGE - GSM 08.58, 8.4.19. Channel number


In the case of step 1, a DEACTIVATE SACCH message and a DATA REQUEST message including a CHANNEL RELEASE message as Layer 3 information parameter shall occur on the A-bis-interface, and a CLEAR COMPLETE message shall occur on the MSC-interface. After the time T3109=A an RF CHANNEL RELEASE message shall occur on the A-bis-interface.

In the case of step 3, a DEACTIVATE SACCH message and optionally a DATA REQUEST message including a CHANNEL RELEASE message as Layer 3 information parameter shall occur on the A-bis-interface, and a CLEAR COMPLETE message shall occur on the MSC-interface. After the time T3109=A an RF CHANNEL RELEASE message shall occur on the A-bis-interface.


1,3. CLEAR COMPLETE - GSM 08.08, 3.2.1.22. 1,3. DEACTIVATE SACCH - GSM 08.58, 8.4.5.

Channel number 1,3. DATA REQUEST - GSM 08.58, 8.3.1 Channel number Link identifier Layer 3 information = CHANNEL RELEASE with

RR cause BA range (optional)

1,3. RF CHANNEL RELEASE - GSM 08.58, section 8.4.14.

Channel number Requirements Reference


9.1.3.16 Radio channel release

Test Purpose

The radio channel release procedure is used to release a radio channel which is no longer needed (normally after a successful handover or a normal assignment).

NOTE: Only the case after a successful handover is tested explicitly.

Test Case

Initial Setup

A call shall be set up between the A-bis-interface and the MSC-interface.

Description

A CLEAR COMMAND message with the cause value "handover successful" shall be input on the MSC-interface. The response on any interface shall be recorded.

An RF CHANNEL RELEASE ACKNOWLEDGE message shall be input on the A-bis-Interface


Message flow

BTS BSC MSC CLEAR CMD <-------------------------------- RF CH REL <--------------------------- RF CH REL ACK ---------------------------> CLEAR COM --------------------------------> The messages from the BSSTE will be:

2. CLEAR COMMAND - GSM 08.08, 3.2.1.21. Layer 3 header information (optional) Cause = as in text

3. RF CHANNEL RELEASE ACKNOWLEDGE - GSM 08.08, 8.4.19. Channel number


In the case of step 2, an RF CHANNEL RELEASE message shall occur on the A-bis-interface, and possibly a CLEAR COMPLETE message shall occur on the MSC-interface.

In the case of step 3, if not already occurred in step 2, a CLEAR COMPLETE message shall occur on the MSC-interface.


2. RF CHANNEL RELEASE - GSM 08.58, 8.4.14. Channel number

Page 212 GSM 11.23 v.4.4.0: May 1996

2/3. CLEAR COMPLETE - GSM 08.08, 3.2.1.22 Requirements Reference


9.1.3.17 MS power control (optional)

Test Purpose

The MS power control procedure is used between BSC and BTS in order to set the MS output power.

Test Case

1. A dedicated resource shall be set up between the MSC-interface and the A-bis-interface. 2. MEASUREMENT RESULT messages shall be input on the A-bis-interface. The parameters

included in the MEASUREMENT RESULT messages, in downlink and uplink, shall be varied in such a way during the test that the MS power control algorithm, agreed between the manufacturer and the operator, is thoroughly tested. The response on any interface shall be recorded.

Message Flow

BTS BSC MSC MEAS RES ---------------------------> MS POW CONTR <--------------------------- The messages from the BSSTE will be:

2. MEASUREMENT RESULT - GSM 08.58, 8.4.8. Channel number Measurement result number Uplink measurements BS power Layer 1 information (optional) Layer 3 information (MEAS REP) (optional) MS timing offset (optional)


In the case of step 2, MS POWER CONTROL messages shall occur on the A-bis-interface containing information such that the requirements on the MS power control algorithm, agreed between the manufacturer and the operator, are fulfilled.


2. MS POWER CONTROL - GSM 08.58, 8.4.15. Channel number MS power MS power parameters (optional)



9.1.3.18 Transmission power control (optional)

Test Purpose

This procedure is used between BSC and BTS to set the TRX power on a physical radio channel to the desired level.

Test Case

Initial Setup

1. An O&M-message as defined by the operator or the manufacturer shall be input on the OMC-interface setting the parameters for TRX power control in the BSC.

2. A call shall be set up between the A-bis-interface and MSC-interface. Description

A certain number of MEASUREMENT RESULT messages shall be input on the A-bis-interface with measurement values leading to a power change according to the RF power control and handover algorithm. The algorithms are a national or operator specific matter. The response on any interface shall be recorded.

BTS BSC MSC MEAS RES ---------------------------> BS POW CONTR <--------------------------- The messages from the BSSTE will be:

1. O&M MESSAGES 3. MEASUREMENT RESULT - GSM 08.58, 8.4.8.

Channel number Measurement result number Uplink measurements BS power Layer 1 information (optional) Layer 3 information (MEAS REP) (optional) MS timing offset (optional)


In the case of step 3, no message shall be occur on the MSC-interface, but a BS POWER CONTROL message shall occur on the A-bis-interface with TRX power level parameters bringing the TRX power level within thresholds.


3. BS POWER CONTROL - GSM 08.58, 8.4.16. Channel number BS power BS power parameters (optional)



Page 214 GSM 11.23 v.4.4.0: May 1996

9.1.3.19 Connection failure

Test Purpose

The connection failure procedure indicates to the BSC that a radio interface failure (or equipment failure etc.) has occurred. The BSC takes then appropriate actions.

Test Case

Initial Setup

A dedicated resource shall be set up between the MSC-interface and the A-bis-interface. Description 1. A CONNECTION FAILURE INDICATION message shall be input on the A-bis-interface. The

response on any interface shall be recorded. Message Flow

BTS BSC MSC CONN FAIL IND ---------------------------> CLEAR REQ -------------------------------->

NOTE: Also when a data link error occurs (ERROR IND), an indication shall be given to the upper MM sublayer. The procedure may also be used in this case.


1. CONNECTION FAILURE INDICATION - GSM 08.58, 8.4.4. Channel number Cause


In the case of step 1, a CLEAR REQUEST message with the cause value "radio interface message failure" shall occur on the MSC-interface.


1. CLEAR REQUEST - GSM 08.08, 3.2.1.20. Cause = as in text



9.1.3.20 Physical context request (optional)

Test Purpose

The physical context request procedure allows the BSC to obtain information on the transmission /reception process of a radio channel prior to a channel change. This information may be forwarded to a new TRX in a BTS controlled by the BSC. The physical context request procedure is internal to the BSS.

The physical context request procedure is optional for implementation in the BSC.

Test Case

Initial Setup

A call shall be established between the A-bis-interface and the MSC-interface of the BSSTE.

Description

1. The BSC shall be stimulated to send a PHYSICAL CONTEXT REQUEST message by e.g. initiating internal handover or using an O&M message as defined by the operator or the manufacturer over the OMC-interface. The response on any interface shall be recorded.

2. The test is stopped by inputting a PHYSICAL CONTEXT CONFIRM message on the A-bis-

interface.

NOTE: According to GSM 08.58 the physical context of the old channel may be forwarded to the new TRX (no requirement). If this is the case, a test checking that the correct physical context is moved to the new TRX could be developed.

Message Flow

BTS BSC MSC PHYS CONT REQ <-------------------------- PHYS CONT CONF --------------------------> The messages from the BSSTE will be:

3. PHYSICAL CONTEXT CONFIRM - GSM 08.58, 8.4.13. Channel number BS power MS power Timing Advance Physical context (optional)


In the case of step 2, a PHYSICAL CONTEXT REQUEST message concerning the correct channel shall occur on the A-bis-interface.


2. PHYSICAL CONTEXT REQUEST - GSM 08.58, 8.4.12. Channel number



9.1.3.21 SACCH Info modify

TBD

Test Purpose

The SACCH info modify procedure is used by the BSC to modify the SACCH filling information (System Info) sent on an individual SACCH channel. The SACCH filling information as given in the SACCH INFO

Page 216 GSM 11.23 v.4.4.0: May 1996

MODIFY message shall be used on the indicated channel until the channel is released or the information is changed by another SACCH INFO MODIFY message.

Test Case

Initial Setup

None

Description

An O&M message as defined by the operator or the manufacturer shall be input on the OMC-interface commanding the BSC to modify or to stop the SACCH filling information on an individual SACCH channel.The response on any interface shall be recorded. This shall be repeated until all the SYSTEM INFORMATION messages type 5 and 6 (optionally type 5bis, 5ter - see § 8.1.3.1) are verified.

Message Flow

BTS BSC MSC O&M SACCH INFO MODIFY <----------------------------- The messages from the BSSTE will be:


In the case of step 1, a SACCH FILLING message shall occur on the A-bis-interface with the new system information to go in the SYSTEM INFORMATION messages type 5, 5bis (optionally), 5ter (optionally), 6.


2. SACCH INFO MODIFY - GSM 08.58, 8.4.20. Channel number System information type = 5, 5bis (optionally), 5ter (optionally), 6 Layer 3 information (SYS INFO) (optional) Starting time (optional)



9.1.3.22 Channel request by MS

The response of a BSC to a channel request by MS is covered by the test of channel activation in section 9.1.3.10.

9.1.3.23 Paging

Test Purpose

The paging procedure is used to trigger a channel access by a Mobile Station. This procedure is used for mobile terminating calls and is initiated by the MSC via the BSC. The BSC determines the paging group to be used based on the IMSI of the MS to be paged. The paging group value is sent to the BTS together with the PAGING COMMAND message. Based on the paging group information the BTS will execute the transmission of the message in the correct paging block.

Test Case

Initial Setup

An O&M-message as defined by the operator or the manufacturer shall be input over the OMC-interface by the BSSTE instructing the BSC to configure a certain DRX paging mode of operation in the BSS.

Description

A PAGING message for a specific Mobile Station shall be input on the MSC-interface. The response on any interface shall be recorded.

Message Flow

BTS BSC MSC PAGING <-------------------------------- PAGING CMD <---------------------------- The messages from the BSSTE will be:

1. O&M MESSAGE 2. PAGING - GSM 08.08, section 3.2.1.19.

IMSI TMSI (optional) Cell identifier list Channel needed (optional)


In the case of step 2, a PAGING COMMAND message shall occur on the A-bis-interface with a mobile identity corresponding to the TMSI/IMSI in the PAGING message.


2. PAGING COMMAND - GSM 08.58, 8.5.5. Channel number Paging group MS identity Channel needed (optional)



9.1.3.24 Delete indication

Test Purpose

The delete indication procedure is used by the BTS to indicate to the BSC that an IMMEDIATE ASSIGN COMMAND message has been deleted due to overload on the downlink CCCH. For further information see GSM 08.58, section 5.3.

Test Case

The use of such an indication in the BSC is not specified. Consequently, the procedure is not tested.

Page 218 GSM 11.23 v.4.4.0: May 1996

9.1.3.25 CCCH load indication

Test Purpose

The CCCH load indication procedure is used by the BTS to inform the BSC that the load on one CCCH exceeds a certain threshold. For further information see GSM 08.58, section 5.4.

Test Case

The use of this information in the BSC is not specified, and is not tested.

9.1.3.26 Broadcast information modify

Test Purpose

The broadcast information modify procedure is used by the BSC to set new BCCH parameters to be transmitted from the BTS or to stop the transmission of system information messages on the radio interface.

Test Case

Initial Setup

None

Description

An O&M message as defined by the operator or the manufacturer shall be input on the OMC-interface setting the system information to be sent or stopped on the BCCH. The response on any interface shall be recorded. This shall be repeated until all SYSTEM INFORMATION types 1 to 4 (including, for DCS1800 only,optionally type 2bis, 2ter - see § 8.1.3.1)) and 7, 8 are verified.

Message Flow

BTS BSC MSC O&M BCCH INFO <---------------------------- The messages from the BSSTE will be:


In the case of step 1, a BCCH INFORMATION message shall occur on the A-bis-interface with the new BCCH parameters.


1. BCCH INFORMATION - GSM 08.58, 8.5.1. Channel number System information type = 1, 2, 3, 4, 2bis (optional) ,2ter (optional)(DCS1800), 7, 8 Full BCCH information (SYS INFO) (optional) Starting time (optional)



9.1.3.27 Immediate assignment

Test Purpose

When the MS initially accesses the BTS, the BSC immediately assigns a dedicated resource.

Test Case

The immediate assignment procedure is seen as implicitly tested by the channel activation procedure (random access by MS) in section 9.1.3.10.




NOTE: As the procedure to initiate the SMS Cell Broadcast function in the BSC is not specified, this function will not be tested.

9.1.3.29 Radio resource indication

Test Purpose

The radio resource indication procedure is used by the BTS to report to the BSC on the interference levels on idle channels.

Test Case

Initial Setup

None

Description

1. The BSSTE shall continuously input RF RESOURCE INDICATION messages to the BSC over the A-bis-interface with an interval of A.

2. An O&M message as defined by the operator or the manufacturer shall be input on the OMC-

interface setting the thresholds for the spontaneous RESOURCE INDICATION messages. Then a RESOURCE REQUEST message indicating "spontaneous indication" shall be input on the MSC-interface. The response on any interface shall be recorded.

3. The environment shall be set up to trigger a spontaneous RESOURCE INDICATION message from

the BSC. The response on any interface shall be recorded. 4. A RESOURCE REQUEST message indicating "one single indication" shall be input on the MSC-

interface. The response on any interface shall be recorded. 5. A RESOURCE REQUEST message indicating "periodic indication" and a periodicity of T3=B>0

shall be input on the MSC-interface. The response on any interface shall be recorded. 6. A RESOURCE REQUEST message indicating "no indication" shall be input on the MSC-interface.


Page 220 GSM 11.23 v.4.4.0: May 1996

Message Flow

BTS BSC MSC RF RES IND ------------------------------> . RES REQ . <---------------------------- RES IND RF RES IND -----------------------------> -------------------------------> | A RF RES IND T3 ------------------------------> | RES IND A RF RES IND -----------------------------> ------------------------------> | A RF RES IND T3 ------------------------------> | RES IND . -----------------------------> . . . The messages from the BSSTE will be:

1. RF RESOURCE INDICATION - GSM 08.58, section 8.6.1. Resource information

2. O&M MESSAGES 2. RESOURCE REQUEST - GSM 08.08, section 3.2.1.17.

Periodicity Resource indication method = as in text Cell identifier Extended resource indicator (optional)

4-6. RESOURCE REQUEST - GSM 08.08, section 3.2.1.17. Periodicity = none, B, none Resource indication method = as in text Cell identifier Extended resource indicator (optional)


In the case of step 3, a RESOURCE INDICATION message shall occur on the MSC-interface reflecting the information in the latest RF RESOURCE INDICATION message.

In the case of step 4, a RESOURCE INDICATION message shall occur immediately on the MSC-interface reflecting the information in the latest RF RESOURCE INDICATION message.

In the case of step 5, RESOURCE INDICATION messages shall occur repeatedly on the MSC-interface with an interval T3=B each reflecting the information in the latest RF RESOURCE INDICATION messages.

In the case of step 6, no further RESOURCE INDICATION messages shall occur on the MSC-interface.


3-5. RESOURCE INDICATION - GSM 08.08, section 3.2.1.18. Resource indication method Resource available (optional) Cell identifier Total resource accessible (optional)


This operation is described in GSM 08.58, section 6.1. and GSM 08.08, section 3.1.3.

9.1.3.30 SACCH filling information modify

Test Purpose

The SACCH filling information modify procedure is used by the BSC to change the system information content generally to be transmitted on the SACCHs or to stop the transmission of the system information messages on the radio interface..

Test Case

Initial Setup

None

Description

An O&M message as defined by the operator or the manufacturer shall be input on the OMC-interface commanding the BSC to modify or to stop the system information to be transmitted on the SACCH. The response on any interface shall be recorded. This shall be repeated until all the SYSTEM INFORMATION messages type 5 and 6 (including, for DCS1800 only,optionally type 5bis, 5ter - see § 8.1.3.1) are verified.

Message Flow

BTS BSC MSC O&M SACCH FILL <----------------------------- The messages from the BSSTE will be:


In the case of step 1, a SACCH FILLING message shall occur on the A-bis-interface with the new system information to go in the SYSTEM INFORMATION messages type 5, 5bis (optionally), 5ter (optionally) (DCS1800), and 6.


2. SACCH FILLING - GSM 08.58, 8.6.2. System information type = 5, 5bis (optionally), 5ter (optionally) (DCS1800), 6 Layer 3 information (SYS INFO) (optional) Starting time (optional)




The flow control procedure on the A-bis-interface is used to indicate to the BSC if there is some kind of overload situation in the BTS, e.g. on the TRX processor, on the downlink CCCH or on the ACCH, by

Page 222 GSM 11.23 v.4.4.0: May 1996

sending an OVERLOAD message to the BSC. The BSC will then try to reduce the load on the BTS. The signalling procedure is given in GSM 08.58, section 6.3.

The method of reducing the load is a national or operator specific matter. Consequently, the procedure is not tested.

9.1.3.32 Error reporting

The error reporting procedure is used by the BTS in order to report to the BSC when it detects an erroneous message. The signalling procedure is given in GSM 08.58, section 6.4 .

Testing of this procedure does not apply to the BSC.

10 Base transceiver station network aspects

The use of the A-bis-interface is optional for a GSM PLMN operator. However, if one or more transceiver units of a BSS are not colocated with the control functions of the BSS, the BSS shall be split into the 2 functional entities Base Station Controller (BSC) and Base Transceiver Station(s) (BTS(s)). See also section 1 in this specification.

The tests in this section apply to the BTS(s), if used.

10.1 Base transeiver station network aspects functions

10.1.1 General

The interface between the Base Station Controller (BSC) and the Base Transceiver Station (BTS) is defined in GSM 08.5x and 08.6x. The interface supports the transcoding/rate adaptation functions positioned in the BTS, or in the BSC or at the MSC site.

This section verifies the network functions of a BTS.

The non-transparent part of Layer 3 shall be tested. The transparent part of Layer 3 shall simply be tested for transparency.

The functional split between the BSC and the BTS is defined in detail in GSM 08.52. Of the main BSS network functions listed in section 8.1.1 the BTS can roughly be defined to include the following:

Functions in the BTS:

- channel coding/decoding - enciphering/deciphering - scheduling of paging messages

Functions in the BSC or BTS:

- transcoding/rate adaptation

As for the BSS seen as a whole, the Layer 3 messages on each interface of the BTS can be divided into 2 categories:

- transparent messages - non-transparent messages

All the messages which are transparent to the BSS as a whole (DTAP messages) are consequently transparent also to the BTS. Messages which are non-transparent to the BSS as a whole may also be transparent to the BTS.

As for the BSS as a whole (see section 8.1.3), the non-transparent Layer 3 procedures are tested as elementary procedures, not as structured procedures. The tests are intended to cover all normal and abnormal cases of significance within each elementary procedure. However, all possible error cases are not tested, normally only if they imply different message sequences. The tests in this section are performed under perfect transmission conditions and under no limiting conditions.

10.1.2 Transparent messages

Messages which are "transparent" to the BTS are treated in a specific way on the A-bis-interface. See sections 10.1.3.5 and 10.1.3.6 (transparent messages) for downlink (BSC to MS) and uplink (MS to BSC) messages, respectively.

10.1.3 Non-transparent messages

The tests described in this section are to verify that messages sent to the Base Transceiver Station (BTS) using the RR or A-bis-interface non-transparent Layer 3 procedures have the correct consequential

Page 224 GSM 11.23 v.4.4.0: May 1996

actions, and that combinations of certain events cause the correct messages to be sent via the RR or A-bis-interface non-transparent Layer 3 procedures on the radio interface or A-bis-interface by the BSC. Time constraints have to be met.

The following non-transparent Layer 3 procedures are to be tested in the BTS:

Radio link layer management:

1. Link establishment indication 2. Link establishment request 3. Link release indication 4. Link release request 5. Transmission of transparent L3-message in acknowledged mode 6. Reception of transparent L3-message in acknowledged mode 7. Transmission of transparent L3-message in unacknowledged mode 8. Reception of transparent L3-message in unacknowledged mode 9. Link error indication

Dedicated channel management:

10. Channel activation 11. Channel mode modify 12. Handover detection 13. Start of encryption 14. Measurement reporting 15. Deactivate SACCH 16. Radio channel release 17. MS power control 18. Transmission power control 19. Connection failure 20. Physical context request

Common channel management:

21. Channel request by MS 22. Paging 23. Delete indication 24. CCCH load indication 25. Broadcast information modify 26. Immediate assignment 27. Short Message Service Cell Broadcast (SMSCB)

TRX management:

28. Radio resource indication 29. SACCH filling information modify 30. Flow control 31. Error reporting

Details of the correct operation of these procedures are to be found in GSM 04.08 and GSM 08.58. GSM 08.08 is also implicitly applicable.

The same overall requirements as for the tests of the BSS as a whole in section 8.1.3 apply.

10.1.3.1 Link establishment indication

The link establishment indication procedure is used by the BTS to indicate to the BSC that a Layer 2 link on the radio path has been established in a multi-frame mode at the initiative of the MS.

The establishment may be with or without contention resolution, i.e. with or without an information field in the SABM from the MS. The Layer 3 messages contained in the SABM information field may be one of the following:

LOCATION UPDATING REQUEST CM SERVICE REQUEST PAGING RESPONSE IMSI DETACH INDICATION CM REESTABLISHMENT REQUEST

The CM SERVICE REQUEST may concern a normal call or e.g. a Short Message Service (SMS).

10.1.3.1.1 SDCCH, Contention Resolution

Test Purpose

To check the correct behaviour of the BTS upon the reception on the SDCCH channel of a first SABM containing each of the Layer 3 messages above in turn.

This test shall be repeated for each initial L3 message defined above.

Test Case

Initial Setup

The channel activation procedure in section 10.1.3.10 shall be initiated requesting an SDCCH.

Description

1. An SABM frame indicating SAPI=0 containing the L3Msg shall be input on the radio interface on the main signalling link (the SDCCH). The response on any interface shall be recorded.

L3Msg = LOCATION UPDATING REQUEST, CM SERVICE REQUEST, PAGING RESPONSE,

IMSI DETACH INDICATION, or CM REESTABLISHMENT REQUEST.

Message Flow

MS BTS BSC first SABM - - - - - - - - - - - - - - > UA < - - - - - - - - - - - - - - EST IND ---------------------------> UI(FillFrames) < - - - - - - - - - - - - - - The messages from the BSSTE will be:

1. SABM(L3Msg), coded as specified in GSM 04.06 and 04.08


In the case of step 1, a LAPDm UA frame containing the same L3Msg than the one in the SABM shall occur on the radio interface on the main signalling link (SDCCH) acknowledging the SABM, and an

Page 226 GSM 11.23 v.4.4.0: May 1996

ESTABLISH INDICATION message on the A-bis-interface containing the same L3Msg. Then, LAPDm UI fill frames shall occur continuously on the SDCCH.

The messages from the BTS shall be:

1. LAPDm UA frame containing the same L3Msg message, coded as specified in GSM 04.06. ESTABLISH INDICATION containing the same L3Msg message, coded as specified in GSM 08.58. LAPDm UI frames containing filling frame, coded as specified in GSM 04.06.


GSM 08.58 § 3.1

10.1.3.1.2 FACCH, Contention Resolution, Channel Mode modify, Sapi3

Test Purpose

To check the correct behaviour of the BTS upon the reception on the FACCH channel of a first SABM containing a LOCATION UPDATING REQUEST message, a CHANNEL MODE MODIFY message, and a SABM on the Sapi3.

Test Case

Initial Setup

If supported by the BTS as an operator or manufacturer choice, the channel activation procedure in section 10.1.3.10 shall be initiated requesting an TCH/FACCH for signalling only.

Description

1. An SABM frame indicating SAPI=0 containing LOCATION UPDATING REQUEST shall be input on the radio interface on the main signalling link (the FACCH). The response on any interface shall be recorded.

2. MODE MODIFY message shall be input on the A-bis-interface requesting a TCH/FACCH, but for

speech and signalling. The response on any interface shall be recorded. 3. Another LAPDm SABM frame, but with SAPI=3, and without L3 information message, concerning a

Short Message Service (SMS) shall be input on the radio interface on the SACCH. The response on any interface shall be recorded.

Message Flow

MS BTS BSC first SABM(LOCUP) - - - - - - - - - - - - - - > UA(LOCUP) < - - - - - - - - - - - - - - EST IND(LOCUP) ---------------------------> UI(FillFrames) < - - - - - - - - - - - - - - MODE MODIFY <--------------------------- MODE MODIFY ACK <stop UI(FillFrames) ---------------------------> SABM(Sapi3) - - - - - - - - - - - - - - > UA(Sapi3) < - - - - - - - - - - - - - - EST IND(Sapi3) ---------------------------> The messages from the BSSTE will be:

1. SABM(LOCATION UPDATING REQUEST), coded as specified in GSM 04.06 and 04.08

2. MODE MODIFY, coded as specified in GSM 08.58

3. SABM on sapi 3, coded as specified in GSM 04.06


In the case of step 1, a LAPDm UA frame containing LOCATION UPDATING REQUEST shall occur on the radio interface on the main signalling link (FACCH) acknowledging the SABM, and an ESTABLISH INDICATION message on the A-bis-interface containing LOCATION UPDATING REQUEST. Then, LAPDm UI fill frames shall occur continuously on the FACCH.

In the case of step 2, a MODE MODIFY ACKNOWLEDGE message shall occur on the A-bis-interface and the transmission of LAPDm UI fill frames on the TCH/FACCH shall stop.

In the case of step 3, a LAPDm UA frame without information field shall occur on the radio interface on the SACCH acknowledging the SABM and an ESTABLISH INDICATION message indicating SAPI=3 shall occur on the A-bis-interface without information field.


1. LAPDm UA frame containing the same LOCATION UPDATING REQUEST message, coded as specified in GSM 04.06.

ESTABLISH INDICATION containing the same LOCATION UPDATING REQUEST message, coded as specified in GSM 08.58.

2. MODE MODIFY ACKNOWLEDGE, coded as specified in GSM 08.58. 3. LAPDm UA frame on the Sapi 3 without L3 information message, coded as specified in GSM 04.06. ESTABLISHMENT INDICATION without L3 information message, coded as specified in GSM

08.58. Link Identifier : Sapi = 3.

Page 228 GSM 11.23 v.4.4.0: May 1996


GSM 08.58 § 3.1

10.1.3.1.3 No Contention Resolution, Normal Case

Test Purpose

To check the correct behaviour of the BTS upon the reception on the Main signalling channel of a SABM without information field.

Test Case

Initial Setup

As appropriate, the channel activation procedure in section 10.1.3.10 shall be initiated requesting a SDCCH or an TCH/FACCH (signalling).

Description

1. An SABM frame indicating SAPI=0 without an information field in the SABM shall be input on the radio interface on the main signalling link. The response on any interface shall be recorded.

Message Flow

MS BTS BSC SABM - - - - - - - - - - - - - - > UA < - - - - - - - - - - - - - - EST IND ---------------------------> UI(FillFrames) < - - - - - - - - - - - - - - The messages from the BSSTE will be:

1. SABM, coded as specified in GSM 04.06


In the step 1, a LAPDm UA frame without information field shall occur on the radio interface on the main signalling link acknowledging the SABM, and an ESTABLISH INDICATION message on the A-bis-interface without information field. Then, LAPDm UI fill frames shall occur continuously on the main signalling link.


1. LAPDm UA frame without information field, coded as specified in GSM 04.06. ESTABLISH INDICATION without information field, coded as specified in GSM 08.58. LAPDm UI frames containing filling frame, coded as specified in GSM 04.06.


GSM 08.58 § 3.1

10.1.3.2 Link establishment request

The link establishment request procedure is used by the BSC to request the establishment by the BTS of a LAPDm link over the radio path. This procedure applies only to the Short Message Service (SMS) with SAPI=3.

10.1.3.2.1 Normal Case

Test Purpose

To check the normal procedure.

Test Case

Initial Setup

A dedicated resource shall be set up between the radio interface and the A-bis-interface.

Description

1. Then an ESTABLISH REQUEST message indicating SAPI=3 shall be input on the A-bis-interface. The response on any interface shall be recorded.

2. Then a UA frame with SAPI=3 shall be input on the radio interface before the time T200 (on

SACCH if the main signalling link is TCH/FACCH or on SDCCH if the main signalling link is SDCCH). The response on any interface shall be recorded.

Message Flow

MS BTS BSC EST REQ (SAPI=3) <---------------------------- SABM (SAPI=3) <- - - - - - - - - - - - - - - UA (SAPI=3) - - - - - - - - - - - - - - -> EST CONF (SAPI=3) ----------------------------> The messages from the BSSTE will be:

1. ESTABLISH REQUEST on the Abis interface, coded as specified in 08.58 §8.3.4 Link identifier : Sapi = 3

2. LAPDm UA frame on Sapi 3 without L3 information message, coded as specified in GSM 04.06.


In the case of step 1, a SABM frame with SAPI=3 shall occur on the radio interface (on SACCH if the main signalling link is TCH/FACCH or on SDCCH if the main signalling link is SDCCH).

Page 230 GSM 11.23 v.4.4.0: May 1996

In the case of step 2, an ESTABLISH CONFIRM message indicating SAPI=3 shall occur on the A-bis-interface.


1. SABM, coded as specified in GSM 04.06

2. ESTABLISH CONFIRM, coded as specified in GSM 08.58 §8.3.5. Link identifier : Sapi = 3.


GSM 08.58 § 3.2

10.1.3.2.2 T200 x (N200 + 1) times expiry

Test Purpose

To check the BTS behaviour when the MS ignores the SABM N200+1 times.

Test Case

Initial Setup


Description

1. Then an ESTABLISH REQUEST message indicating SAPI=3 shall be input on the interface. The response on any interface shall be recorded.

Message Flow

MS BTS BSC EST REQ (SAPI=3) <---------------------------- SABM (SAPI=3) | <- - - - - - - - - - - - - - - | | T200 expiry : N200+1 times SABM (SAPI=3) | <- - - - - - - - - - - - - - - | | REL IND (SAPI=3) ----------------------------> ERR IND ----------------------------> The messages from the BSSTE will be:

1 ESTABLISH REQUEST, coded as specified in GSM 08.58 §8.3.4 Link identifier : Sapi = 3


In the case of step 1, N200+1 SABM frames with SAPI=3 shall occur on the radio interface with an interval of T200 followed by a RELEASE INDICATION message and an ERROR INDICATION message with the cause value "timer T200 expired N200+1 times" on the A-bis-interface.


1. N200 + 1 LAPDm SABM frames indicating Sapi 3 and without L3 information message, coded as specified in GSM 04.06.

RELEASE INDICATION, coded as specified in GSM 08.58 §8.3.9

Link identifier : Sapi = 3

ERROR INDICATION, coded as specified in GSM 08.58 §8.3.3 Link identifier : Sapi = 3 RLM cause = as in text


GSM 08.58 § 3.1

10.1.3.3 Link release indication

Test Purpose

The link release indication procedure is used by the BTS to indicate to the BSC that a Mobile Station has disconnected the LAPDm link on the radio interface.

Test Case

Initial Setup


Description

1. The LAPDm DISC frame shall be input on the radio interface on the main signalling link. The response on any interface shall be recorded.

2. Another DISC frame shall be input on the radio interface. The response on any interface shall be

recorded.

NOTE: Any LAPDm frame or combination of LAPDm frames (collision cases) which is to be interpreted as a valid DISC frame according to GSM 04.06 shall be equivalent to a DISC frame also in this test.

Page 232 GSM 11.23 v.4.4.0: May 1996

Message Flow

MS BTS BSC DISC - - - - - - - - - - - - - - -> UA <- - - - - - - - - - - - - - - REL IND ----------------------------> DISC - - - - - - - - - - - - - - -> DM <- - - - - - - - - - - - - - - The messages from the BSSTE will be:

1,2. DISC frame, coded as specified in GSM 04.06


In the case of step 1, a LAPDm UA frame shall occur on the radio interface on the main signalling link and a RELEASE INDICATION message shall occur on the A-bis-interface.

In the case of step 2, a LAPDm DM frame shall occur on the radio interface. Nothing shall occur on the A-bis-interface.


1. UA frame coded as specified in GSM 04.06. RELEASE INDICATION, coded as specified in GSM 08.58 §8.3.9 2. DM frame coded as specified in GSM 04.06.


GSM 08.58 § 3.3

10.1.3.4 Link release request

The link release request procedure is used by the BSC to request a BTS to disconnect the LAPDm link on the radio interface. This applies only to Short Message Services (SMS) on the SACCH if the main signalling link is TCH/FACCH or on the SDCCH if the main signalling link is SDCCH, using SAPI=3.


Test Purpose

To check the normal procedure of the link release request.

Test Case

Initial Setup

A dedicated resource shall be set up between the radio interface and the A-bis-interface, and a Short Message Service (SAPI=3) shall be set up to the same Mobile Station.

Description

1. Then a RELEASE REQUEST message shall be input on the A-bis-interface concerning the SAPI=3 Short Message Service. The response on any interface shall be recorded.

2. Then a LAPDm UA frame shall be input on the radio interface on the SACCHif the main signalling

link is TCH/FACCH or on the SDCCH if the main signalling link is SDCCH, within a time T200. The response on any interface shall be recorded.

Message Flow

MS BTS BSC REL REQ <---------------------------- DISC <- - - - - - - - - - - - - - - UA - - - - - - - - - - - - - - -> REL CONF ----------------------------> The messages from the BSSTE will be:

1. RELEASE REQUEST, coded as specified in GSM 08.58 §8.3.7 Link identifier : Sapi = 3 Release mode = normal

2. UA frame coded as specified in GSM 04.06.


In the case of step 1, DISC frames with SAPI=3 shall occur on the radio interface on the SACCH if the main signalling link is TCH/FACCH or on the SDCCH if the main signalling link is SDCCH.

In the case of step 2, a RELEASE CONFIRM message shall occur on the A-bis-interface.


1. DISC frame on Sapi 3, coded as specified in GSM 04.06 2. RELEASE CONFIRM, coded as specified in GSM 08.58 §8.3.8



GSM 08.58 § 3.4

10.1.3.4.2 T200 x (N200 + 1) times expiry

Test Purpose

To check the BTS behaviour in case of T200 x (N200 + 1) times expiry in the procedure of the link release request.

Page 234 GSM 11.23 v.4.4.0: May 1996

Test Case

Initial Setup

A dedicated resource shall be set up between the radio interface and the A-bis-interface, and a Short Message Service (SAPI=3) shall be set up to the same Mobile Station.

Description

1. Then a RELEASE REQUEST message shall be input on the A-bis-interface concerning the SAPI=3 Short Message Service. The response on any interface shall be recorded.

Message Flow

MS BTS BSC REL REQ <---------------------------- DISC | <- - - - - - - - - - - - - - - | | T200 expiry : N200+1 times DISC | <- - - - - - - - - - - - - - - | | REL IND ----------------------------> ERR IND ----------------------------> The messages from the BSSTE will be:

1. RELEASE REQUEST, coded as specified in GSM 08.58 §8.3.7 Link identifier : Sapi = 3 Release mode = normal


In the case of step 1, N200+1 LAPDm DISC frames with SAPI=3 shall occur on the radio interface on the SACCH if the main signalling link is TCH/FACCH or on the SDCCH if the main signalling link is SDCCH, with an interval of T200 followed by a RELEASE INDICATION message and an ERROR INDICATION message with the cause value "timer T200 expired N200+1 times" on the A-bis-interface.


1. DISC frame, N200+1 times, every T200, coded as specified in GSM 04.06. 2. RELEASE INDICATION, coded as specified in GSM 08.58 §8.3.9


3. ERROR INDICATION, coded as specified in GSM 08.58 §8.3.3 Link identifier : Sapi = 3 RLM cause = as in text


GSM 08.58 § 3.4

10.1.3.5 Transmission of transparent L3-message in acknowledged mode

Test Purpose

This procedure is used to send a message which is transparent to the BTS over the radio path in acknowledged mode. The procedure applies at least to all downlink DTAP messages.

The test shall be carried out exactly as for the BSS as a whole in section 8.1.2.1, with the exception that the "transparent" message shall be mapped on to a DATA REQUEST message on the A-bis-interface containing the transparent message. The DATA REQUEST message is defined below.

NOTE: Throughout the rest of the Layer 3 test descriptions of the BTS, the downlink message transparent to the BTS is coded as such for simplicity, and is not included in the DATA REQUEST message.

Test Case

Initial Setup


Description

1. Then a DATA REQUEST message containing the DTAP AUTHENTICATION REQUEST message shall be input on the A-bis-interface. The response on any interface shall be recorded.

2. A LAPDm RR frame shall be input on the radio interface on the main signalling link within a time

T200. The response on any interface shall be recorded.

Message Flow

MS BTS BSC DATA REQ (AUTH REQ) <---------------------------- I (AUTH REQ) <- - - - - - - - - - - - - - - RR - - - - - - - - - - - - - - -> The messages from the BSSTE will be:

1. DATA REQUEST coded as specified in GSM 08.58 §8.3.1 Layer 3 information = AUTH REQ

2. LAPDm RR frame, coded as specified in GSM 04.06.


In the case of step 1, a LAPDm I frame containing the AUTHENTICATION REQUEST message shall occur on the radio interface on the main signalling link.



Page 236 GSM 11.23 v.4.4.0: May 1996

1. LAPDm I frame, coded as specified in GSM 04.06 Information field = AUTH REQ


GSM 08.58 § 3.5

10.1.3.6 Reception of transparent L3-message in acknowledged mode

Test Purpose

This procedure is used to receive a message which is transparent to the BTS over the radio path in acknowledged mode. The procedure applies at least to all uplink DTAP messages.

The test shall be carried out exactly as for the BSS as a whole in section 8.1.2.2, with the exception that the "transparent" message shall be mapped on to a DATA INDICATION message on the A-bis-interface containing the transparent message. The DATA INDICATION message is defined below.

NOTE: Throughout the rest of the Layer 3 test Descriptions of the BTS the uplink message transparent to the BTS is coded as such for simplicity, and is not included in the DATA INDICATION message.

Test Case

Initial Setup


Description

1. A LAPDm I frame containing the DTAP STATUS message shall be input in the radio interface on the main signalling link.

Message Flow

MS BTS BSC I (STATUS) - - - - - - - - - - - - - - -> RR <- - - - - - - - - - - - - - - DATA IND (STATUS) ----------------------------> The messages from the BSSTE will be:

1. LAPDm I frame, coded as specified in GSM 04.06. Information field = STATUS


In the case of step 1, a LAPDm RR frame shall occur on the radio interface on the main signalling link, a DATA INDICATION message containing the DTAP STATUS message shall occur on the A-bis-interface.


1. LAPDm RR frame, coded as specified in GSM 04.06 DATA INDICATION, coded as specified in GSM 08.58 §8.3.2

Layer 3 Information = STATUS


GSM 08.58 § 3.6

10.1.3.7 Transmission of transparent L3-message in unacknowledged mode.

Test Purpose

This procedure is used to send a message which is transparent to the BTS over the radio path in unacknowledged mode by coding it into a UNIT DATA REQUEST message on the Abis-interface.

The signalling procedure is given in GSM 08.58 § 3.7.

NOTE: As there are no such messages defined, and there are no restrictions defined on how the BSC shall generate such messages towards the BTS, testing of such procedures dooes not apply to the BTS.

Test Case

Initial Setup

Description

be:


be:

10.1.3.8 Reception of transparent L3-message in unacknowledged mode

Test Purpose

This procedure is used to receive a message which is transparent to the BTS over the radio path in unacknowledged mode by coding it into a UNIT DATA INDICATION message on the Abis-interface.

The signalling procedure is given in GSM 08.58 § 3.8.

NOTE: As there are no such messages defined, and there are no restrictions defined on how the BSC shall react to such messages from the BTS, testing of such procedures does not apply to the BTS.

Test Case

Page 238 GSM 11.23 v.4.4.0: May 1996

Initial Setup

Description

be:


be:

10.1.3.9 Link error indication

The link error indication procedure is used by the BTS to indicate to the BSC abnormal situations by an ERROR INDICATION message, like protocol errors, complete lack of LAPDm acknowledgements or receipt of SABMs in the LAPDm multiple frame established state.

The link error indication procedure is tested implicitly by several other tests.

10.1.3.10 Channel activation

Test Purpose

The channel activation procedure is used to activate a channel in the BTS for an MS which then will be commanded to the channel by an IMMEDIATE ASSIGNMENT, an IMMEDIATE ASSIGNMENT EXTENDED, an ASSIGNMENT COMMAND, an ADDITIONAL ASSIGNMENT or a HANDOVER COMMAND message.

Test Case

Initial Setup

No channels shall be activated in the BTS.

Description

1. A CHANNEL ACTIVATION message shall be input on the A-bis-interface concerning the channel A. The response on any interface shall be recorded.

2. Step 1 shall be repeated for the same channel A. Message Flow

MS BTS BSC CH ACTIV <--------------------------- CH ACTIV ACK ---------------------------> CH ACTIV <--------------------------- CH ACTIV NACK ---------------------------> The messages from the BSSTE will be:

1,2. CHANNEL ACTIVATION, coded as specified in GSM 08.58 §8.4.1 Channel number = A Activation type Channel mode Channel identification (optional) Encryption identification (optional) Handover reference (optional) BS power (optional) MS power (optional) Timing advance (conditional) BS power parameters (optional) MS power parameters (optional) Physical context (optional) SACCH information (optional)


In the case of step 1, a CHANNEL ACTIVATION ACKNOWLEDGE message shall occur on the A-bis-interface. The BTS may start the transmission on the SACCH on the radio interface as specified in GSM 08.58 § 4.1.2 to 4.1.4.

In the case of step 2, a CHANNEL ACTIVATION NEGATIVE ACKNOWLEDGE message shall occur on the A-bis-interface with the cause value "radio channel already activated/allocated".


1. CHANNEL ACTIVATION ACKNOWLEDGE coded as specified in GSM 08.58 §8.4.2 Channel number = A Frame number

2. CHANNEL ACTIVATION NEGATIVE ACKNOWLEDGE coded as specified in GSM 08.58 §8.4.3 Channel number = A Cause = as in text


GSM 08.58 § 4.1.2 to 4.1.4

10.1.3.11 Channel mode modify

The channel mode modify procedure is used by the BSC to request a change of the channel mode of an active channel in a BTS. The channel mode is related to transcoding and rate adaptation functions and includes consequently also channel coding functions.


Test Purpose

To check that the BTS is able to perform a channel mode modify procedure.

Test Case

Initial Setup

A call shall be established between the A-bis-interface and the radio interface of the BSSTE on a TCH/F9.6.

Page 240 GSM 11.23 v.4.4.0: May 1996

Description

1. A MODE MODIFY message shall be input on the A-bis-interface requesting a TCH/F4.8 for the call previously set up. The response on any interface shall be recorded.

Message Flow

MS BTS BSC MODE MOD <---------------------------- MODE MOD ACK ----------------------------> The messages from the BSSTE will be:

1. MODE MODIFY, coded as specified in GSM 08.58 §8.4.9 Channel number Channel mode = TCH/F4.8


In the case of step 1, a MODE MODIFY ACKNOWLEDGE message shall occur on the A-bis-interface.


1. MODE MODIFY ACKNOWLEDGE, coded as specified in GSM 08.58 §8.4.10 Channel number


GSM 08.58 § 4.2

10.1.3.11.2 Abnormal Case

Test Purpose

To check the BTS behaviour when the new mode requested by the BSC is not supported by the BTS.

Test Case

Initial Setup

A call shall be established between the A-bis-interface and the radio interface of the BSSTE on a TCH/F9.6.

Description

1. A MODE MODIFY message shall be input on the A-bis-interface requesting a TCH/F2.4 for the call previously set up, but the BTS shall be unable to allocate such a channel. The response on any interface shall be recorded.

Message Flow

MS BTS BSC MODE MOD <---------------------------- MODE MOD NACK ----------------------------> The messages from the BSSTE will be:

1. MODE MODIFY, coded as specified in GSM 08.58 §8.4.9. Channel mode = TCH/F2.4


In the case of step 1, a MODE MODIFY NEGATIVE ACKNOWLEDGE message shall occur on the A-bis-interface with an appropriate cause value.


1. MODE MODIFY NEGATIVE ACKNOWLEDGE, coded as specified in GSM 08.58 §8.4.11. Cause = as in text


GSM 08.58 § 4.2

10.1.3.12 Handover detection

10.1.3.12.1 Non-synchronised case

Test Purpose

This procedure is used between the target BTS and BSC when an MS which has been handed over accesses the new BTS.

Test Case

Initial Setup

An O&M message as defined by the operator or the manufacturer shall be input on the OMC-interface setting the timer T3105 to an appropriate value A and the parameter Ny1 to an appropriate value B.

The BSSTE shall perform the channel activation procedure (handover) in section 10.1.3.10 specifying non-synchronised handover.

Description

1. The BSSTE shall generate HANDOVER ACCESS messages with the expected handover reference number on the radio interface on the main signalling link. The response on any interface shall be recorded.

Page 242 GSM 11.23 v.4.4.0: May 1996

2. Case 1 : No further message is generated by the BSSTE. The response on any interface shall be recorded.

Case 2 : A correct layer 2 frame (e.g. a LAPDm SABM frame on Sapi 0 without information field) is generated on the radio interface by the BSSTE before the time T3105 after the reception of the Nth PHYSICAL INFORMATION message (N < Ny1). The response on any interface shall be recorded.

Message Flow

MS BTS BSC Channel activation (handover) HAND ACC ----------------------------> HAND ACC ----------------------------> . . HAND DET ---------------------------> CASE 1 : PHYS INFO <---------------------------- - | PHYS INFO T3105 | <---------------------------- - | . | . | Ny1+1 PHYS INFO - | <---------------------------- | T3105 | - | . CONN FAIL IND ---------------------------> CASE 2 : PHYS INFO <---------------------------- - | PHYS INFO T3105 | <---------------------------- - | . | . | N < Ny1 PHYS INFO - | <---------------------------- Correct layer 2 frame (eg SABM) ----------------------------> . EST IND ---------------------------> The messages from the BSSTE will be:

1. HANDOVER ACCESS, coded as specified in GSM 04.08 §9.1.14 Handover reference : the one defined in the CHANNEL ACTIVATION message.


In the case of step 1, a HANDOVER DETECTION message shall occur on the A-bis-interface.

In case of step 2, case 1, Ny1+1=B+1 PHYSICAL INFORMATION messages with an interval of T3105=A on the radio interface on the main signalling link. After the expiry of the last T3105 timer, a CONNECTION FAILURE INDICATION message with a cause value set to "handover access failure" shall occur on the A-bis-interface to notify the BSC of the non reception of a correctly decoded layer 2 frame.

In case of step 2, case 2, N PHYSICAL INFORMATION messages with an interval of T3105 shall occur on the main signalling link on the radio interface until the reception of the SABM frame. Then an ESTABLISH INDICATION message is sent on the A-bis interface and the BTS may start the transmission on the SACCH on the radio interface as specified in GSM 08.58 § 4.1.3.


1. HANDOVER DETECTION, coded as specified in GSM 08.58 §8.4.7. Channel number,

Access Delay : value C measured by the BTS. PHYSICAL INFORMATION, coded as specified in 04.08 §9.1.2.8

Timing advance : value C. 2. Case 1 : CONNECTION FAILURE INDICATION, coded as specified in GSM 08.58, § 8.4.4

Channel number, Cause = as in text. Case 2 : ESTABLISH INDICATION, coded as specified in GSM 08.58, § 8.3.6 Channel number, Link identifier.


GSM 08.58 § 4.3

10.1.3.12.2 Synchronised case

Test Purpose

This procedure is used between the target BTS and BSC when a MS which has been handed over accesses the new BTS.

Test Case

Initial Setup

An O&M message as defined by the operator or the manufacturer shall be input on the OMC-interface indicating if the BTS shall trigger the handover detection procedure on the reception on the main signalling link, of a correctly decoded access burst (case 1) or a correctly decoded frame (case 2).

The BSSTE shall perform the channel activation procedure (handover) in section 10.1.3.10 specifying synchronised handover.

Description

1. Case 1 : The BSSTE shall generate HANDOVER ACCESS messages with the expected handover reference number on the radio interface on the main signalling link. The response on any interface shall be recorded.

Case 2 : A correct layer 2 frame is generated on the radio interface by the BSSTE. The response on any interface shall be recorded.

Page 244 GSM 11.23 v.4.4.0: May 1996

Message Flow

MS BTS BSC Channel activation (handover) CASE 1 : HAND ACC ----------------------------> HAND ACC ----------------------------> . . HAND DET ---------------------------> CASE 2 : Correct layer 2 frame ----------------------------> . HAND DET ---------------------------> The messages from the BSSTE will be:

1. Case 1 : HANDOVER ACCESS, coded as specified in GSM 04.08 § 9.1.14 Handover reference : the one defined in the CHANNEL ACTIVATION message.

Case 2 : LAPDm frame on Sapi 0, coded as specified in GSM 04.06. Conformance Requirements

In the case of step 1, (case 1 and case 2), a HANDOVER DETECTION message shall occur on the A-bis-interface.


1. HANDOVER DETECTION, coded as specified in GSM 08.58 § 8.4.7. Channel number, Access delay : value C measured by the BTS.


GSM 08.58 § 4.3

10.1.3.13 Start of encryption

The purpose of the start of encryption procedure is after authentication to initialise and synchronise the stream ciphering devices in the BTS and in the MS. The MS and MSC already know the cipher key Kc from the authentication procedure.

10.1.3.13.1 Ciphering mode complete

Test Purpose

To check the encryption procedure completion.

Test Case

Initial Setup

A dedicated resource shall be set up between the radio interface and the A-bis-interface. No ciphering shall be activated.

Description

1. An ENCRYPTION COMMAND message shall be input on the A-bis-interface containing the requested A5/x ciphering algorithm and the key Kc. The response on any interface shall be recorded.

2. The BSSTE shall start deciphering and enciphering and send a CIPHER MODE COMPLETE

message on the radio interface in enciphered mode. The response on any interface shall be recorded.

3. A DTAP message shall be input on the A-bis-interface. The response on any interface shall be

recorded.

Message Flow

MS BTS BSC ENCR CMD <--------------------------- ( pending L2 frames ) <- - - - - - - - - - - - - - CIPH MODE CMD <---------------------------- start deciphering BTS Layer 2 frame (ciphered) - - - - - - - - - - - - - - > start enciphering BTS CIPH MODE COM DATA IND (CIPH MODE COM) ---------------------------->--------------------------> DTAP message <------------------------------------------------------- The messages from the BSSTE will be:

1. ENCRYPTION COMMAND coded as specified in GSM 08.58 §8.4.6 Channel number Encryption information Link identifier Layer 3 information (CIPHER MODE CMD)

2. CIPHER MODE COMPLETE, enciphered, coded as specified in GSM 04.08 §9.1.10 Mobile Identity 3. DTAP MESSAGE Conformance Requirements

In the case of step 1, a CIPHER MODE COMMAND message shall occur on the radio interface. The message shall be unciphered.

In the case of step 2, a DATA IND (CIPHER MODE COMPLETE) message shall occur on the A-bis-interface

Page 246 GSM 11.23 v.4.4.0: May 1996

In the case of step 3, the DTAP message shall occur on the radio interface. The message shall be enciphered.


1. CIPHERING MODE COMMAND Cipher mode setting Cipher Response

2. DATA IND (CIPHER MODE COMPLETE) ( transparent message) GSM 08.58 § 8.3.2 Mobile Identity

3. DTAP MESSAGE


GSM 08.58 § 4.4

10.1.3.13.2 DTAP message

Test Purpose

To check the encryption procedure completion with a DTAP message at the radio interface.

Test Case

Initial Setup


Description

1. An ENCRYPTION COMMAND message shall be input on the A-bis-interface containing the key Kc. The response on any interface shall be recorded.

2. The BSSTE shall start deciphering and enciphering and send an I frame containing any uplink

DTAP message on the radio interface in enciphered mode. The response on any interface shall be recorded.


recorded.

Message Flow

MS BTS BSC ENCR CMD <--------------------------- ( pending L2 frames ) <- - - - - - - - - - - - - - CIPH MODE CMD <---------------------------- start deciphering BTS I frame (DTAP message) - - - - - - - - - - - - - - > start enciphering BTS DTAP message <------------------------------------------------------- The messages from the BSSTE will be:

1. ENCRYPTION COMMAND Channel number Encryption information Link identifier Layer 3 information (CIPHER MODE CMD)

2. Uplink DTAP message 3. Downlink DTAP message


In the case of step 1, a CIPHERING MODE COMMAND message shall occur on the radio interface. The message shall be unciphered.

In the case of step 2, the DTAP message shall occur on the A-bis-interface. The DTAP message shall be deciphered.

In the case of step 3, the DTAP message shall occur on the radio interface. The message shall be enciphered.


1. CIPHERING MODE COMMAND Cipher mode setting

2. DATA INDICATION (DTAP message) 3. DTAP MESSAGE


GSM 08.58 § 4.4

10.1.3.13.3 Start of encryption with unavailable algorithm

Test Purpose

The purpose of this test is to make sure that an unavailable algorithm is not accepted by the BTS.

Page 248 GSM 11.23 v.4.4.0: May 1996

Initial Setup

A dedicated resource shall be set up between the Um-interface and the A-bis-interface. Ciphering shall not be activated.

Test Case

1. An ENCRYPTION COMMAND message shall be input on the A-bis-interface containing the key Kc and an unavailable ciphering algorithm. The response on any interface shall be recorded.

Message Flow

MS BTS BSC ENCRYPTION CMD <--------------------------- ERROR REPORT --------------------------->

The message from the BSSTE will be:

1. ENCRYPTION COMMAND - GSM 08.58, 8.4.6 Channel Number Encryption information (with unavailable algorithm) Link Identifier Layer 3 information (CIPHER MODE CMD) Conformance Requirements

In step 1, an ERROR REPORT is sent from the BTS on the A-bis-interface and no messages shall occur on the Um-interface.

The message from the BTS shall be:

1. ERROR REPORT - GSM 08.58, 8.6.4 Cause: Encryption algorithm not implemented Requirement reference

GSM 08.58, 4.4

10.1.3.13.4 Stop ciphering

Test Purpose

To check the encryption procedure completion.

Test Case

Initial Setup

A dedicated resource shall be set up between the radio interface and the A-bis-interface. Ciphering shall be activated (see § 10.1.3.13.1 or .10.1.3.13.2).

Description

1. An ENCRYPTION COMMAND message shall be input on the A-bis-interface containing a ciphering algorithm set to "no encryption". The response on any interface shall be recorded.

2. The BSSTE shall stop deciphering and enciphering and send a CIPHERING MODE COMPLETE

message on the radio interface in non-ciphered mode. The response on any interface shall be recorded.


recorded. Message Flow

MS BTS BSC ENCR CMD <--------------------------- CIPH MODE CMD <---------------------------- stop deciphering BTS Layer 2 frame (non-ciphered) - - - - - - - - - - - - - - > stop enciphering BTS CIPH MODE COM DATA IND (CIPH MODE COM) --------------------------->---------------------------> DTAP message <-------------------------------------------------------- The messages from the BSSTE will be:

1. ENCRYPTION COMMAND coded as specified in GSM 08.58 § 8.4.6 Channel number Encryption information Link identifier Layer 3 information (CIPHER MODE CMD)

2. CIPHERING MODE COMPLETE, enciphered, coded as specified in GSM 04.08 § 9.1.10 Mobile Identity

3. DTAP MESSAGE Conformance Requirements

In the case of step 1, a CIPHERING MODE COMMAND message shall occur on the radio interface. The message shall be ciphered.

In the case of step 2, a DATA IND (CIPHER MODE COMPLETE) message shall occur on the A-bis-interface.

In the case of step 3, the DTAP message shall occur on the radio interface. The message shall not be ciphered.


1. CIPHERING MODE COMMAND Cipher mode setting Cipher Response

2. DATA IND (CIPHER MODE COMPLETE) (transparent message) GSM 08.58 § 8.3.2 Mobile Identity

3. DTAP MESSAGE Requirement reference

GSM 08.58 § 4.4

Page 250 GSM 11.23 v.4.4.0: May 1996

10.1.3.13.5 Failure case

Test Purpose

To check the BTS behaviour when it is not able to handle a requested ciphering algorithm.

Test Case

Initial Setup


Description

1. An ENCRYPTION COMMAND message shall be input on the A-bis-interface containing the requested A5/x ciphering algorithm (A5/x is not supported by the BTS) and the key Kc. The response on any interface shall be recorded.

Message Flow

MS BTS BSC ENCR CMD <--------------------------- ERR REP ---------------------------> The messages from the BSSTE will be:

1. ENCRYPTION COMMAND coded as specified in GSM 08.58 § 8.4.6 Channel number Encryption information Link identifier Layer 3 information (CIPHER MODE CMD)


In the case of step 1, an ERROR REPORT message with the cause set to "encryption algorithm not implemented" shall occur on the A-bis-interface.


1. ERROR REPORT, coded as specified in GSM 08.58 § 8.6.4 Cause Message identifier (optional) Channel number (optional) Link identifier (optional) Erroneous message (optional)


GSM 08.58 § 4.4


The Mobile Station reports regularly on the SACCH to the BTS on measurements it has performed on the downlink radio channel. Similarly, the BTS measures the uplink radio channel. This information is signalled to the BSC and is used in the BSC in the handover and RF power control algorithms. Optionally, the BTS may preprocess the measurement results. The handover and RF power control algorithms are a national or operator specific matter.

10.1.3.14.1 Basic measurement reporting

Test Purpose

This procedure is used by the BTS to report to the BSC raw measurement results received from an MS and results of measurements performed by the BTS on the corresponding uplink channel. This procedure shall always be implemented in a BTS.

Test Case

Initial Setup

A dedicated TCH/FACCH resource shall be established by the BSSTE between the radio interface and the A-bis-interface. A SAPI=3 link shall be set up on the SACCH.

Description

1. The BSSTE shall input a MEASUREMENT REPORT message on the radio interface on the SACCH. The response on any interface shall be recorded.

2. An I frame indicating SAPI=3 shall be input on the radio interface on the SACCH. The response on

any interface shall be recorded. 3. Step 1 shall be repeated.

Message Flow

MS BTS BSC MEAS REP - ----------------------------> | MEAS RES SACCH multiframe - ---------------------------> | I (SAPI = 3) | - ----------------------------> SACCH multiframe | | DATA IND SACCH multiframe - ---------------------------> | MEAS REP - ----------------------------> MEAS RES ---------------------------> The messages from the BSSTE will be:

1,3. MEASUREMENT REPORT Measurement results


In the case of step 1, a MEASUREMENT RESULT message shall occur on the A-bis-interface containing measurement results for the uplink performed in the BTS and the reported measurement results in the MEASUREMENT REPORT message from the MS.

In the case of step 2, a MEASUREMENT RESULT message shall occur on the A-bis-interface containing measurement results for the uplink performed by the BTS only and a DATA INDICATION message shall occur on the A-bis-interface.

Page 252 GSM 11.23 v.4.4.0: May 1996

In the case of step 3, a MEASUREMENT RESULT message shall occur on the A-bis-interface containing measurement results for the uplink performed in the BTS and the reported measurement results in the MEASUREMENT REPORT message from the MS.


1,3. MEASUREMENT RESULT Channel number Measurement result number Uplink measurements BS power Layer 1 information Layer 3 information (MEAS REP) MS Timing offset (optional)

2. MEASUREMENT RESULT, coded as specified in GSM 08.58 §8.4.8

Channel number Measurement result number Uplink measurements BS power Layer 1 information MS Timing offset (optional) DATA INDICATION, coded as specified in GSM 08.58 § 8.3.2 Channel number Link identifier L3 Information


GSM 08.58 § 5.1

10.1.3.14.2 Preprocessed measurement reporting (optional)

This procedure is used by the BTS to report to the BSC preprocessed measurement results received from an MS and performed by the BTS. This procedure is optional for implementation in a BTS.

The exact preprocessing parameters are not specified, but are a national or operator specific matter. Consequently, the procedure is not tested.

10.1.3.14.3 Preprocessing configuration (optional)

The preprocessing configuration procedure is used by the BSC to configure the BTS for a certain preprocessing procedure. This procedure is optional for implementation in a BTS.

The exact preprocessing parameters are not specified, but are a national or operator specific matter. Consequently, the procedure is not tested.

10.1.3.15 Deactivate SACCH

Test Purpose

The deactivate SACCH procedure is used by the BSC to order the BTS to deactivate the SACCH.

Test Case

Initial Setup

A dedicated resource shall be established between the radio interface and the A-bis-interface.

Description

1. A DEACTIVATE SACCH message shall be input on the A-bis-interface. The response on any interface shall be recorded.

Message Flow

MS BTS BSC DEACT SACCH <---------------------------- stop SACCH The messages from the BSSTE will be:

1. DEACTIVATE SACCH, coded as specified in GSM 08.58 §8.4.5 Channel number


In the case of step 1, no further RF transmissions shall occur on the SACCH.


GSM 08.58 § 4.6

10.1.3.16 Radio channel release

Test Purpose

The radio channel release procedure is used to release a radio channel which is no longer needed (e.g. after a successful handover or after a normal assignment).

Test Case

Initial Setup

A call shall be set up between the radio interface and the A-bis-interface.

Description

1. An RF CHANNEL RELEASE message shall be input on the A-bis-interface. The response on any interface shall be recorded.

2. After some time a LAPDm I frame shall be input on the radio interface. The response on any

interface shall be recorded.

Page 254 GSM 11.23 v.4.4.0: May 1996

Message Flow

MS BTS BSC RF CH REL <--------------------------- deactivate channels RF CH REL ACK ---------------------------> The messages from the BSSTE will be:

1. RF CHANNEL RELEASE, coded as specified in GSM 08.58 §8.4.14 Channel number

2. LAPDm I frame, coded as specified in GSM 04.06


In the case of step 1, an RF CHANNEL RELEASE ACKNOWLEDGE message shall occur on the A-bis-interface.


The messages from the BTS shall be

1. RF CHANNEL RELEASE ACKNOWLEDGE, coded as specified in GSM 08.58 §8.4.19 Channel number


GSM 08.58 § 4.7

10.1.3.17 MS power control

Test Purpose

The MS power control procedure enables the BSC to control the MS output power.

Test Case

NOTE: In this test there is no correlation between the measurement reports from the BTS and the actual power level values ordered by the BSSTE, acting as a BSC.

Initial Setup


Description

1. An MS POWER CONTROL message with a given MS power level shall be input on the A-bis-interface. The response on any interface shall be recorded during at least the time needed by the BTS to transmit 10 SACCH downlink blocks on the radio interface.

2. Continuing from step 1, the BSSTE shall input a new MS POWER CONTROL message with a

different MS power level on the A-bis-interface. The response on any interface shall be recorded during at least the time needed by the BTS to transmit 10 SACCH downlink blocks on the radio interface.

Message Flow

MS BTS BSC MS POW CONTR <--------------------------- L1-header in SACCH < - - - - - - - - - - - - - - The messages from the BSSTE will be:

1,2. MS POWER CONTROL, coded as specified in GSM 08.58 §8.4.15 Channel number MS power MS power parameters (optional)


In the case of step 1, the correct power level shall be included in each Layer 1 header of the SACCH downlink block transmitted by the BTS.

In the case of step 2, the correct power level shall be included in each Layer 1 header of the SACCH downlink block transmitted by the BTS.


GSM 08.58 § 4.8

10.1.3.18 Transmission power control (optional)

Test Purpose

This procedure is used between BSC and BTS to set the TRX power on a physical radio channel to the desired level.

Test Case

Initial Setup


Description

1. A BS POWER CONTROL message shall be input on the A-bis-interface. The response on any interface shall be recorded.

Message Flow

MS BTS BSC BS POW CONTR <--------------------------- Adjust BSS power The messages from the BSSTE will be:

Page 256 GSM 11.23 v.4.4.0: May 1996

1. BS POWER CONTROL, coded as specified in GSM 08.58 §8.4.16 Channel number BS power BS power parameters


In the case of step 1, no message shall occur on any interface. The TRX power level on the radio interface shall be set according to the level in the BS POWER CONTROL message. This is also verified by the Layer 1 tests in section 2.1.8.


GSM 08.58 § 4.9

10.1.3.19 Connection failure

Test Purpose

The purpose of the connection failure procedure is to indicate to the BSC that a radio interface failure (or equipment failure etc.) has occurred. The BSC will then take appropriate actions. See also § 10.1.3.12.1, case 1.

Test Case

Initial Setup

Description

1. An O&M message as defined by the operator or the manufacturer shall be input on the A-bis-interface setting the thresholds for radio link failure (including RADIO-LINK-TIMEOUT).

2. A dedicated resource shall be set up between the A-bis-interface and the radio interface. Then no

further inputs shall be made by the BSSTE for a period exceeding the timer RADIO-LINK-TIMEOUT. The response on any interface shall be recorded.

Message Flow

MS BTS BSC failure CONN FAIL IND ----------------------------> The messages from the BSSTE will be:

1. O&M MESSAGES


In the case of step 2, a CONNECTION FAILURE INDICATION message with the cause value "radio interface failure" shall occur on the A-bis-interface.


2. CONNECTION FAILURE INDICATION, coded as specified in GSM 08.58 §8.4.4 Channel number Cause = as in text


GSM 08.58 § 4.10

10.1.3.20 Physical context request (optional)

Test Purpose

The physical context request procedure is an optional procedure which allows the BSC to obtain information on the transmission /reception process of a radio channel prior to a channel change. This information may be forwarded to a new TRX in a BTS controlled by the BSC. The physical context request procedure is internal to the BSS.

Test Case

Initial Setup

A call shall be established between the A-bis-interface and the radio interface.

Description

1. A PHYSICAL CONTEXT REQUEST message shall be input on the A-bis-interface. The response on any interface shall be recorded.

Message Flow

MS BTS BSC PHYS CONT REQ <---------------------------- PHYS CONT CONF ----------------------------> The messages from the BSSTE will be:

1. PHYSICAL CONTEXT REQUEST, coded as specified in GSM 08.58 §8.4.12 Channel number


In the case of step 1, a PHYSICAL CONTEXT CONFIRM message concerning the correct channel shall occur on the A-bis-interface.


1. PHYSICAL CONTEXT CONFIRM, coded as specified in GSM 08.58 , § 8.4.13 Channel number BS power MS power Timing Advance Physical context (optional)


GSM 08.58 § 4.11

Page 258 GSM 11.23 v.4.4.0: May 1996

10.1.3.21 Channel request by MS

Test Purpose

The channel request by MS procedure is used when an MS performs random access by a CHANNEL REQUEST message on the radio interface.

Test Case

Initial Setup

The BTS shall be in the idle state.

Description

1. A CHANNEL REQUEST message shall be input on the radio interface. The response on any interface shall be recorded.

Message Flow

MS BTS BSC CH REQ ----------------------------> CH RQD ---------------------------> The messages from the BSSTE will be:

1. CHANNEL REQUEST, coded as specified in GSM 04.08 §9.1.8 Establishment cause & Random reference = PAR1


In the case of step 1, a CHANNEL REQUIRED message shall occur on the A-bis-interface.


1. CHANNEL REQUIRED, coded as specified in GSM 08.58 §8.5.3 Channel number Request reference = PAR1 Access delay Physical context (optional)


GSM 08.58 § 5.1

10.1.3.22 Paging

Test Purpose

The paging procedure is used to trigger a channel access by a Mobile Station. This procedure is used for mobile terminating calls and is initiated by the MSC via the BSC. The BSC determines the paging group to be used based on the IMSI of the MS to be paged. The paging group value is sent to the BTS together

with the PAGING COMMAND message. Based on the paging group information the BTS will execute the transmission of the message in the correct paging block.

NOTE: PAGING messages on the A-interface and PAGING COMMAND messages on the A-bis-interface relate to one Mobile Station only, but the PAGING REQUEST messages on the radio interface may relate to several.

The grouping of paging messages in the BTS is up to the manufacturer or the operator and is not tested explicitly.

Test Case

Initial Setup


An O&M-message as defined by the operator or the manufacturer shall be input on the A-bis-interface instructing the BTS to configure a certain control channel configuration.

Description

1. 9 PAGING COMMAND messages, 1 with IMSI and 8 with TMSI, for 9 Mobile Stations belonging to the same paging group shall be input on the A-bis-interface. The response on any interface shall be recorded.

Message Flow

MS BTS BSC PAG CMD (IMSI) <---------------------------- PAG REQ PAG CMD (TMSI) <-------------------------- <---------------------------- PAG REQ PAG CMD (TMSI) <-------------------------- <---------------------------- PAG REQ . <-------------------------- . The messages from the BSSTE will be:

1. PAGING COMMAND, coded as specified in GSM 08.58 §8.5.5 Channel number Paging group MS identity = IMSI, TMSI, TMSI, TMSI, TMSI, TMSI, TMSI, TMSI, TMSI Channel needed (optional)


In the case of step 1, PAGING REQUEST messages type 1, 2 or 3 shall occur on the radio interface on the correct paging subchannel of the PCH. On all other paging subchannels fill PAGING REQUEST messages (type of identity = no identity) or other valid Layer 3 messages shall occur.

The messages from the BTS may be:

1. PAGING REQUEST TYPE 1, coded as specified in GSM 04.08 §9.1.22 Page mode Channel needed Mobile identity

Page 260 GSM 11.23 v.4.4.0: May 1996

Mobile identity (optional) P1 rest octets

1. PAGING REQUEST TYPE 2, coded as specified in GSM 04.08 §9.1.23 Page mode Channel needed TMSI TMSI Mobile identity (optional) P2 rest octets

1. PAGING REQUEST TYPE 3, coded as specified in GSM 04.08 §9.1.24 Page mode Channel needed TMSI TMSI TMSI TMSI P3 rest octets


GSM 08.58 § 5.2

10.1.3.23 Delete indication

The delete indication procedure is used by the BTS to indicate to the BSC that an IMMEDIATE ASSIGN COMMAND, has been deleted due to overload on the downlink CCCH. For further information see GSM 08.58.

This procedure may be tested generating an overload situation on the downlink CCCH. Load testing of a BTS is outside the scope of this specification. Load testing of a BTS is a national or operator specific matter.

10.1.3.24 CCCH load indication

The CCCH load indication procedure is used by the BTS to inform the BSC that the load on one CCCH exceeds a certain threshold. For further information see GSM 08.58.

The fact that the BTS is able to generate such a message may be tested by imposing a certain load on the CCCH. Load testing of the BTS is, however, outside the scope of this specification. Load testing of the BTS is a national or operator specific matter.

10.1.3.25 Broadcast information modify

Test Purpose

The broadcast information modify procedure is used by the BSC to set new BCCH parameters to be transmitted from the BTS or to stop the transmission of the SYSTEM INFORMATION messages on the radio interface (on BCCH). The signalling procedure is specified in GSM 08.58 and the timing requirements for the SYSTEM INFORMATION messages are specified in GSM 05.02.

Test Case

Initial Setup


Description

1. A BCCH INFORMATION message shall be input on the A-bis-interface setting the system information to go on the BCCH. The message concerned shall be SYSTEM INFORMATION type 1. The response on any interface shall be recorded.

2. Step 1 shall be repeated for SYSTEM INFORMATION types 2-4 (including, for DCS 1800

only,optionally type 2bis, 2ter - see § 8.1.3.1) and 7-8. 3. Step 1 shall be repeated for SYSTEM INFORMATION types 1-4 (optionally type 2bis, 2ter - see §

8.1.3.1), 2bis (DCS 1800 only), 7 and 8 to stop the transmission of the messages on the radio interface (on BCCH).

Message Flow

MS BTS BSC BCCH INFO <---------------------------- SYS INFO 1-4 <---------------------------- The messages from the BSSTE will be:

1. BCCH INFORMATION, coded as specified in GSM 08.58 §8.5.1 Channel number System information type = 1 Full BCCH information (SYS INFO) Starting time (optional)

2. BCCH INFORMATION, coded as specified in GSM 08.58 §8.5.1 Channel number System information type = 2, 3, 4, 7, 8 (optionally 2bis, 2ter - see § 8.1.3.1)and (for DCS

1800 only) 2bis. Full BCCH information (SYS INFO) Starting time (optional)

3. BCCH INFORMATION, coded as specified in GSM 08.58 § 8.5.1

Channel number System information type = 1-4, 7, 8 (optionally 2bis, 2ter - see § 8.1.3.1)and (for DCS 1800

only) 2bis. Starting time (optional)


In the case of step 1, a SYSTEM INFORMATION message of the type 1 shall occur continuously on the radio interface on the BCCH with the new system information parameters.

In the case of step 2, SYSTEM INFORMATION messages of the type 2-4 and 7-8 (optionally 2bis, 2ter - see § 8.1.3.1) (including, for DCS 1800 only, type 2bis) shall occur continuously on the radio interface on the BCCH with the new system information parameters.

In the case of step 3, the transmission of SYSTEM INFORMATION messages of the type 1 and 7-8 (optionally 2bis, 2ter - see § 8.1.3.1) (and, for DCS 1800 only, type 2bis) shall stop on the radio interface on the BCCH.


1. SYSTEM INFORMATION TYPE 1, coded as specified in GSM 04.08 §9.1.31 Cell channel Description

Page 262 GSM 11.23 v.4.4.0: May 1996

RACH control parameters SI 1 rest octets

2. SYSTEM INFORMATION TYPE 2, coded as specified in GSM 04.08 §9.1.32 Neighbour cells Description NCC permitted RACH control parameters

DCS 1800 only - begin:

2. SYSTEM INFORMATION TYPE 2bis, coded as specified in GSM 04.08 §9.1.33 Neighbour cells Description (extension) RACH control parameters SI 2bis rest octets

DCS 1800 only -end:

2. SYSTEM INFORMATION TYPE 3, coded as specified in GSM 04.08 §9.1.35 Cell identity Location area identification Control channel Description Cell options Cell selection parameters RACH control parameters SI 3 rest octets

2. SYSTEM INFORMATION TYPE 4, coded as specified in GSM 04.08 §9.1.36 Location area identification Cell selection parameters RACH control parameters (CBCH) channel Description (optional) (CBCH) mobile allocation (optional) SI 4 rest octets

2. SYSTEM INFORMATION TYPE 7, coded as specified in GSM 04.08 § 9.1.41 SI 7 rest octets

2. SYSTEM INFORMATION TYPE 8, coded as specified in GSM 04.08 § 9.1.42

SI 8 rest octets


GSM 08.58 § 5.5

10.1.3.26 Immediate assignment

When the MS initially accesses the BTS, a dedicated resource is immediately allocated by the BSC.


Test Purpose

To check the normal behaviour of the BTS for the immediate assignment procedure..

Test Case

Initial Setup


Description

1. An IMMEDIATE ASSIGN COMMAND message shall be input on the A-bis-interface requesting a normal immediate assignment. The response on any interface shall be recorded.

Message Flow

MS BTS BSC IMM ASS CMD <---------------------------- IMM ASS <---------------------------- The messages from the BSSTE will be:

1. IMMEDIATE ASSIGN COMMAND, coded as specified in GSM 08.58 §8.5.6 Channel number Full Immediate assign info = IMM ASS


In the case of step 1, an IMMEDIATE ASSIGNMENT message shall occur on the radio interface. The page mode may be set by the BTS.


1. IMMEDIATE ASSIGNMENT, coded as specified in GSM 04.08 §9.1.18 Page mode Channel Description Request reference Timing advance Mobile allocation Starting time (optional) IA rest octets


GSM 08.58 § 5.7

10.1.3.26.2 Extended immediate assignment procedure

Test Purpose

To check the normal behaviour of the BTS for the extended immediate assignment procedure..

NOTE : The IMMEDIATE ASSIGNMENT EXTENDED message is either built by the BSC and sent to the BTS in the IMMEDIATE ASSIGN COMMAND message or built by the BTS from two IMMEDIATE ASSIGN COMMAND messages received from the BSC.

Page 264 GSM 11.23 v.4.4.0: May 1996

Only the first case is tested. Concerning the second one, the grouping of access grant messages is up to the manufacturer or the operator and is not tested.

Test Case

Initial Setup

The channel activation procedure in section 10.1.3.10 shall be initiated requesting an SDCCH twice.

Description

1. An IMMEDIATE ASSIGN COMMAND message shall be input on the A-bis-interface requesting an extended immediate assignment. The response on any interface shall be recorded.

Message Flow

MS BTS BSC IMM ASS CMD <---------------------------- IMM ASS EXT <---------------------------- The messages from the BSSTE will be:

1. IMMEDIATE ASSIGN COMMAND, coded as specified in GSM 08.58 §8.5.6 Channel number Full Immediate assign info = IMM ASS EXT


In the case of step 1, an IMMEDIATE ASSIGNMENT EXTENDED message shall occur on the radio interface. The page mode may be set by the BTS.


1. IMMEDIATE ASSIGNMENT EXTENDED, coded as specified in GSM 04.08 §9.1.19 Page mode Channel Description 1 Request reference 1 Timing advance 1 Channel Description 2 Request reference 2 Timing advance 2 Mobile allocation Starting time (optional) IAX rest octets


GSM 08.58 § 5.7

10.1.3.26.3 Reject immediate assignment procedure

Test Purpose

To check the normal behaviour of the BTS for the reject immediate assignment procedure..

Test Case

Initial Setup


Description

1. An IMMEDIATE ASSIGNMENT COMMAND message shall be input on the A-bis-interface requesting an immediate assignment type "rejection". The response on any interface shall be recorded.

NOTE : The IMMEDIATE ASSIGNMENT REJECT message is either built by the BSC and sent

to the BTS in the IMMEDIATE ASSIGN COMMAND message or built by the BTS from two or more IMMEDIATE ASSIGN COMMAND messages received from the BSC.

Only the first case is tested. Concerning the second one, the grouping of access grant messages is up to the manufacturer or the operator and is not tested.

Message Flow

MS BTS BSC IMM ASS CMD <---------------------------- IMM ASS REJ <---------------------------- The messages from the BSSTE will be:

1. IMMEDIATE ASSIGN COMMAND, coded as specified in GSM 08.58 §8.5.6 Channel number Full Immediate assign info = IMM ASS REJ


In the case of step 1, an IMMEDIATE ASSIGNMENT REJECT message shall occur on the radio interface. The page mode may be set by the BTS.


1. IMMEDIATE ASSIGNMENT REJECT, coded as specified in GSM 04.08 §9.1.20 Page mode Request reference Wait indication Request reference Wait indication Request reference Wait indication Request reference

Page 266 GSM 11.23 v.4.4.0: May 1996

Wait indication IAR rest octets


GSM 08.58 § 5.7


10.1.3.27.1 SMS broadcast request

Test Purpose

This procedure is used by the BSC to request the transmission of an SMS Cell Broadcast block on the CBCH by the BTS. The signalling procedure is given in GSM 08.58.

Test Case

Initial Setup

The BTS shall be configured with a CBCH active with SDCCH/4 or SDCCH/8.

Description

1. An SMS BROADCAST REQUEST message shall be input on the A-bis-interface. The response on any interface shall be recorded.

Message Flow

MS BTS BSC SMSCB REQ <--------------------------- block on CBCH (TB = 0, 1, 2 or 3) < - - - - - - - - - - - - - - The messages from the BSSTE will be:

1. SMS BROADCAST REQUEST , coded as specified in GSM 08.58 , §8.5.7 Channel number SMSCB information


In the case of step 1, a block shall occur on the radio interface on the CBCH exactly as given in the SMSCB information element in the SMS BROADCAST REQUEST message input on the A-bis-interface (see GSM 05.02 for the definition of TB).


GSM 08.58 § 5.6

10.1.3.27.2 SMS broadcast command

Test Purpose

This procedure is used by the BSC to request the transmission of four SMS Cell Broadcast blocks on the CBCH by the BTS. The signalling procedure is given in GSM 08.58.

Test Case

Initial Setup

The BTS shall be configured with a CBCH active with SDCCH/4 or SDCCH/8.

Description

1. An SMS BROADCAST COMMAND message shall be input on the A-bis-interface. The response on any interface shall be recorded.

Message Flow

MS BTS BSC SMS CB CMD <--------------------------- block on CBCH (TB = 0) < - - - - - - - - - - - - - - block on CBCH (TB = 1) < - - - - - - - - - - - - - - block on CBCH (TB = 2) < - - - - - - - - - - - - - - block on CBCH (TB = 3) < - - - - - - - - - - - - - - The messages from the BSSTE will be:

1. SMS BROADCAST COMMAND, coded as specified in GSM 08.58 , §8.5.8 Channel number CB command type SMSCB message


In the case of step 1, 4 blocks shall occur on the radio interface on the CBCH. Each of them is made up of one octet header built by the BTS and 22 octets corresponding to the segmentation of the SMSCB message element in the SMS BROADCAST COMMAND message input on the A-bis-interface, eventually completed with filling octets set to 2B.


GSM 08.58 § 5.6

10.1.3.28 Radio resource indication

Test Purpose

The radio resource indication procedure provides interference levels on idle channels in a BTS to the BSC. The periodicity with which this is reported is set by the OMC (Timer T).

Page 268 GSM 11.23 v.4.4.0: May 1996

Test Case

Initial Setup

The BTS shall be configured with a set of half-rate channels and a set of full-rate channels.

Description

1. An O&M-message as defined by the operator or the manufacturer over the A-bis-interface shall set timer T to a value B. The response on any interface shall be recorded.

Message Flow

MS BTS BSC RF RES IND - ---------------------------> T RF RES IND - ---------------------------> . . The messages from the BSSTE will be:

1. O&M MESSAGES


In the case of step 1, RF RESOURCE INDICATION messages shall occur repeatedly on the A-bis-interface with an interval B indicating the resources used for half-rate and full-rate channels.


1. RF RESOURCE INDICATION, coded as specified in GSM 08.58 §8.6.1 Resource information = as in text


GSM 08.58 § 6.1

10.1.3.29 SACCH filling information modify

Test Purpose

The SACCH filling information modify procedure is used by the BSC to change the system information content to be transmitted on the SACCH to a specific Mobile Station or to stop the transmission of SYSTEM INFORMATION messages on the radio interface (on SACCH).

Test Case

Initial Setup


Description

1. A SACCH FILLING message modifying the system information to be transmitted on the SACCH shall be input on the A-bis-interface. The response on any interface shall be recorded until all the SYSTEM INFORMATION messages type 5-6 are verified (optionally 5bis, 5ter - see § 8.1.3.1) (and 5 bis for DCS 1800).

2. Step 1 shall be repeated for SYSTEM INFORMATION type 5-6 (optionally 5bis, 5ter - see §

8.1.3.1)bis (DCS 1800 only) to stop the transmission of the message on the radio interface (on BCCH).

Message Flow

MS BTS BSC SACCH FILLING <---------------------------- SYS INFO 5-6 <----------------------------- . . The messages from the BSSTE will be:

1. SACCH FILLING, coded as specified in GSM 08.58 §8.6.2 System information type = 5, 6 (optionally 5bis, 5ter - see § 8.1.3.1)and, for DCS 1800 only,

5bis. Layer 3 information (SYS INFO) Starting time (optional)

2. SACCH FILLING, coded as specified in GSM 08.58 § 8.6.2 System information type = 5, 6 (optionally 5bis, 5ter - see § 8.1.3.1)5bis (DCS 1800). Starting time (optional)


In the case of step 1, a SYSTEM INFORMATION message of the type 5-6 (optionally 5bis, 5ter - see § 8.1.3.1) (including, for DCS1800 only, type 5bis) shall occur on the radio interface on the SACCH.

In the case of step 2, the transmission of the SYSTEM INFORMATION message of the type 5, 6 (optionally 5bis, 5ter - see § 8.1.3.1)bis (DCS1800 only) shall stop on the radio interface on the SACCH.


1. SYSTEM INFORMATION TYPE 5, coded as specified in GSM 04.08 §9.1.37 Neighbour cells Description

2. SYSTEM INFORMATION TYPE 6, coded as specified in GSM 04.08 §9.1.40 Cell Identity Location area identification Cell options NCC permitted

DCS 1800 only - begin:

1. SYSTEM INFORMATION TYPE 5bis, coded as specified in GSM 04.08 §9.1.38 Neighbour cell description (extension)

DCS 1800 only - end:

Page 270 GSM 11.23 v.4.4.0: May 1996

2. SYSTEM INFORMATION TYPE 5bis , coded as specified in GSM 04.08 §9.1.38 Neighbour cell description (extension)


GSM 08.58 § 6.2


The flow control procedure on the A-bis-interface is used to indicate to the BSC if there is some kind of overload situation in the BTS, e.g. on the TRX processor, on the downlink CCCH or on the ACCH. The BSC will then try to reduce the load on the BTS. The signalling procedure is given in GSM 08.58.

The overload situation will take part of the load testing of a BTS and is outside the scope of the standardised acceptance tests in this specification. Load testing of a BTS is a national or operator specific matter.

10.1.3.31 Error reporting

Test Purpose

The error reporting procedure is used by the BTS in order to report to the BSC when it detects an erroneous message. The erroneous messages are defined in GSM 08.58.

Test Case

Initial Setup


Description

1. An erroneous message shall be input on the A-bis-interface. The response on any interface shall be recorded.

NOTE: The test is carried out for the erroneous messages on the A-bis-interface only. It

should be noted that the ERROR REPORT message might also be used for erroneous messages on the radio interface. It is not specified, however.

Message Flow

MS BTS BSC erroneous message <---------------------------- ERROR REP ----------------------------> Conformance Requirements

In the case of step 1, an ERROR REPORT message shall occur on the A-bis-interface with an appropriate cause value. The information elements of the message shall correspond to the erroneous message input.


1. ERROR REPORT, coded as specified in GSM 08.58 §8.6.4 Cause

Message identifier (optional) Channel number (optional) Link identifier (optional) Erroneous message (optional)


GSM 08.58 § 6.4

Page 272 GSM 11.23 v.4.4.0: May 1996

11 GSM Phases interworking

To obtain compatibility between phase 2 mobile stations and phase 1 infrastructure, it has been attempted to design phase 2 as an extension of the phase 1 protocols. Basically meaning that the phase 1 protocols are contained as a subset of the phase 2 protocols and that for most phase 1 functionality, phase 1 and phase 2 signalling are identical.

This approach in general has been followed. However the requirement for introduction of the new phase 2 features has in some cases required deviation from this general rule. Furthermore, due to freedom in the phase 1 technical specifications there might be different phase 1 infrastructure implementations. Therefore it has not been possible to ensure interworking with all potential implementations in all cases.

Within the scope of this ETR the following definitions are used :

- a phase 1 mobile station is a mobile station which is compliant with the protocols defined by the phase 1 specifications;

- a phase 2 mobile station is a mobile station which is compliant with the protocols defined by the phase 2 specifications;

- a phase 1 infrastructure is an infrastructure which is compliant with the protocols defined by the phase 1 specifications;

- an upgraded phase 1 infrastructure is a phase 1 infrastructure which has been upgraded according to ETR 111, GSM 09.90.

11.1 Interworking between phase 1 mobile and phase 2 network

According to GSM phase 2 specifications phase 1 is a subset of phase 2. Therefore no new tests concerning the interworking between phase 1 mobile stations and phase 2 infrastructure are necessary. However the tests of phase 1 specifications should work with phase 2 Base Station Subsystem equipment.

11.2 Interworking between phase 2 mobile and phase 1 network

11.2.1 Scope

The tests of this section are intended to verify the interworking between phase 2 mobiles stations and phase 1 infrastructure.

11.2.2 References

This section are based on ETR 111, GSM 09.90 , Version 4.1.0, "Interworking between Phase 1 infrastructure and Phase 2 Mobile Stations (MS)".

11.2.3 Radio Interface

11.2.3.1 Information Elements

11.2.3.1.1 Mobile Classmark 1

11.2.3.1.1.1 Revision Level

The REVISION LEVEL field in the MOBILE STATION CLASSMARK 1 information element indicates that the mobile station supports the 04.08 protocols defined for phase 2. This value was marked as RESERVED FOR FURTHER USE in the phase 1 specifications. Moreover, this REVISION LEVEL field has been reduced from 3 bits to 2 bits. The bit which has been freed is marked as spare for phase 2. The remaining bits are still used to indicate the REVISION LEVEL of the mobile station.

On reception of a MOBILE STATION CLASSMARK 1 element with the REVISION LEVEL field set to one of the two following values: ’00’ or ’01’, an upgraded phase 1 infrastructure is not allowed to consider this information element as invalid and shall process the message which contains this MOBILE STATION CLASSMARK 1 information element.

In addition, it would be advisable that whatever the value of the REVISION LEVEL field an upgraded phase 1 infrastructure should not consider this information element as invalid and should process the message containing the MOBILE STATION CLASSMARK 1 information element.

11.2.3.1.1.1.1 Location updating - revision level 00

Test Purpose

The MS sends a LOCATION UPDATING REQUEST message. The REVISION LEVEL field of the MOBILE STATION CLASSMARK 1 information element is set to ’00’ (used by phase 1 mobile stations).

Test Case

Initial Setup

A dedicated resource shall be established between the radio interface and the A-interface.

Description

1. A LOCATION UPDATING REQUEST message shall be input on the radio interface by the BSSTE containing MOBILE STATION CLASSMARK 1 with REVISION LEVEL set to ’00’. The response on any interface shall be recorded.

Message flow

MS BSS MSC LOC UDP REQ -----------------------------> COMPL L3 INFO (LOC UDP REQ) ----------------------------> The messages from the BSSTE will be:

1. LOCATION UPDATING REQUEST, coded as specified in GSM 04.08 §9.2.15. Conformance Requirements

In step 1, a LOCATION UPDATING REQUEST message shall occur on the A-interface.


1. LOCATION UPDATING REQUEST contained in Complete Layer 3 Information, coded as specified in GSM 04.08 §9.2.15 with Mobile Station Classmark 1, Revision Level = '00'.


GSM 04.08 §4.4.4.

Page 274 GSM 11.23 v.4.4.0: May 1996


Test Purpose

The MS sends a LOCATION UPDATING REQUEST message. The REVISION LEVEL field of the MOBILE STATION CLASSMARK 1 information element is set to ’01’ (used by phase 2 mobile stations).

Test Case

Initial Setup


Description


Message flow





1. LOCATION UPDATING REQUEST contained in Complete Layer 3 Information, coded as specified in GSM 04.08 §9.2.15 with Mobile Station classmark 1, Revision Level = '01'.


GSM 04.08 §4.4.4.


Test Purpose

The MS sends a LOCATION UPDATING REQUEST message. The REVISION LEVEL field of the MOBILE STATION CLASSMARK 1 information element is set to '10' (reserved for further use).

Test Case

Initial Setup


Description


Message flow





1. LOCATION UPDATING REQUEST contained in Complete Layer 3 Information, coded as specified in GSM 04.08 §9.2.15 with Mobile Station classmark 1, Revision Level = '10' (for further use).


GSM 04.08 §4.4.4.


Test Purpose

The MS sends a LOCATION UPDATING REQUEST message. The REVISION LEVEL field of the MOBILE STATION CLASSMARK 1 information element is set to '11' (reserved for further use).

Test Case

Initial Setup


Description

1. A LOCATION UPDATING REQUEST message shall be input on the radio interface by the BSSTE containing MOBILE STATION CLASSMARK 1 with REVISION LEVEL set to '11'. The response on any interface shall be recorded.

Page 276 GSM 11.23 v.4.4.0: May 1996

Message flow





1. LOCATION UPDATING REQUEST contained in Complete Layer 3 Information, coded as specified in GSM 04.08 §9.2.15 with Mobile Station classmark 1, Revision Level = '11' (for further use).


GSM 04.08 §4.4.4.

11.2.3.1.1.2 Encryption algorithm A5/1

The ENCRYPTION ALGORITHM field of the MOBILE STATION CLASSMARK 1 information element has been reduced from 2 bits to 1 bit. The bit which has been freed is marked as spare for phase 2. The other bit is used to indicate whether the mobile station supports the standard A5/1 encryption algorithm.

An upgraded phase 1 infrastructure should only check in the ENCRYPTION ALGORITHM field the bit which indicates support of the standard A5/1 algorithm. It is up to the upgraded phase 1 infrastructure to decide how to treat mobile station which do not indicate the support of the standard A5/1 algorithm.

11.2.3.1.1.2.1 Location updating - encryption algorithm A5/1

Test Purpose

The MS sends a LOCATION UPDATING REQUEST message. The ENCRYPTION ALGORITHM field of the MOBILE STATION CLASSMARK 1 information element is set to '1' (A5/1 is not supported).

Test Case

Initial Setup


Description

1. A LOCATION UPDATING REQUEST message shall be input on the radio interface by the BSSTE containing MOBILE STATION CLASSMARK 1 with ENCRYPTION ALGORITHM '1'. The response on any interface shall be recorded.

Message flow





1. LOCATION UPDATING REQUEST contained in Complete Layer 3 Information, coded as specified in GSM 04.08 §9.2.15 with Mobile Station classmark 1, Encryption algorithm = '1' (A5/1 is not supported).


GSM 04.08 §4.4.4.

11.2.3.1.2 Mobile classmark 2

11.2.3.1.2.1 Revision level

A new value is used for the REVISION LEVEL field of the MOBILE STATION CLASSMARK 2 information element to indicate that the mobile station supports the 04.08 protocols defined for phase 2. This value was marked as RESERVED FOR FURTHER USE in the phase 1 specifications. Moreover, this REVISION LEVEL field has been reduced from 3 bits to 2 bits. The bit which has been freed is marked as spare for phase 2. The remaining bits are still used to indicate the REVISION LEVEL of the mobile station.

On reception of a MOBILE STATION CLASSMARK 2 element with the REVISION LEVEL field set to one of the two following values: '00' or '01', an upgraded phase 1 infrastructure is not allowed to consider this information element as invalid and shall process the message which contains this MOBILE STATION CLASSMARK 2 information element.

In addition, it would be advisable that whatever the value of the REVISION LEVEL field an upgraded phase 1 infrastructure should not consider this information element as invalid and should process the message containing the MOBILE STATION CLASSMARK 2 information element.

11.2.3.1.2.1.1 CM Service - revision level 00

Test Purpose

The MS sends a CM SERVICE REQUEST message. The REVISION LEVEL field of the MOBILE STATION CLASSMARK 2 information element is set to '00' (used by phase 1 mobile stations).

Test Case

Initial Setup


Page 278 GSM 11.23 v.4.4.0: May 1996

Description

1. A CM SERVICE REQUEST message shall be input on the radio interface by the BSSTE containing MOBILE STATION CLASSMARK 2 with REVISION LEVEL set to ’00’. The response on any interface shall be recorded.

Message flow

MS BSS MSC CM SERV REQ -----------------------------> COMPL L3 INFO (CM SERV REQ) ----------------------------> The messages from the BSSTE will be:

1. CM SERVICE REQUEST, coded as specified in GSM 04.08 §9.2.9. Conformance Requirements

In step 1, a CM SERVICE REQUEST message shall occur on the A-interface.


1. CM SERVICE REQUEST contained in Complete Layer 3 Information, coded as specified in GSM 04.08 §9.2.9 with Mobile Station classmark 2, Revision Level = '00'.


GSM 04.08 §4.5.1


Test Purpose

The MS sends a CM SERVICE REQUEST message. The REVISION LEVEL field of the MOBILE STATION CLASSMARK 2 information element is set to '01' (used by phase 2 mobile stations).

Test Case

Initial Setup


Description

1. A CM SERVICE REQUEST message shall be input on the radio interface by the BSSTE containing MOBILE STATION CLASSMARK 2 with REVISION LEVEL set to '01'. The response on any interface shall be recorded.

Message flow





1. CM SERVICE REQUEST contained in Complete Layer 3 Information, coded as specified in GSM 04.08 §9.2.9 with Mobile Station classmark 2, Revision Level = '01'.


GSM 04.08 §4.5.1


Test Purpose

The MS sends a CM SERVICE REQUEST message. The REVISION LEVEL field of the MOBILE STATION CLASSMARK 2 information element is set to '10' (for further use).

Test Case

Initial Setup


Description


Message flow


1. CM SERVICE REQUEST, coded as specified in GSM 04.08 §9.2.9.

Page 280 GSM 11.23 v.4.4.0: May 1996




1. CM SERVICE REQUEST contained in Complete Layer 3 Information, coded as specified in GSM 04.08 §9.2.9 with Mobile Station classmark 2, Revision Level = '10' (for further use).


GSM 04.08 §4.5.1


Test Purpose

The MS sends a CM SERVICE REQUEST message. The REVISION LEVEL field of the MOBILE STATION CLASSMARK 2 information element is set to '11' (for further use).

Test Case

Initial Setup


Description


Message flow





1. CM SERVICE REQUEST contained in Complete Layer 3 Information, coded as specified in GSM 04.08 §9.2.9 with Mobile Station classmark 2, Revision Level = '11' (for further use).


GSM 04.08 §4.5.1

11.2.3.1.2.2 Encryption algorithm A5/1

The ENCRYPTION ALGORITHM field of the MOBILE STATION CLASSMARK 2 information element has been reduced from 2 bits to 1 bit. The bit which has been freed is marked as spare for phase 2. The other bit is used to indicate whether the mobile station supports the standard A5/1 encryption algorithm.

An upgraded phase 1 infrastructure should only check in the ENCRYPTION ALGORITHM field the bit which indicates support of the standard A5/1 algorithm. It is up to the upgraded phase 1 infrastructure to decide how to treat mobile station which do not indicate the support of the standard A5/1 algorithm.

11.2.3.1.2.2.1 CM Service - encryption algorithm A5/1

Test Purpose

The MS sends a CM SERVICE REQUEST message. The ENCRYPTION ALGORITHM field of the MOBILE STATION CLASSMARK 2 information element is set to ’1’ (A5/1 is not supported).

Test Case

Initial Setup


Description

1. A CM SERVICE REQUEST message shall be input on the radio interface by the BSSTE containing MOBILE STATION CLASSMARK 2 with ENCRYPTION ALGORITHM ’1’. The response on any interface shall be recorded.

Message flow





1. CM SERVICE REQUEST contained in Complete Layer 3 Information, coded as specified in GSM 04.08 §9.2.15 with Mobile Station classmark 2, Encryption algorithm = '1' (A5/1 is not supported).


GSM 04.08 §4.4.4.

Page 282 GSM 11.23 v.4.4.0: May 1996

11.2.3.1.2.3 Frequency capability

The FREQUENCY CAPABILITY field of the MOBILE STATION CLASSMARK 2 information element has been reduced from 3 bits to 1 bit. The 2 bits which have been freed are marked as spare for phase 2. The remaining bit is used to indicate whether the mobile station supports the extension band for GSM.

An upgraded phase 1 infrastructure is not allowed to reject a FREQUENCY CAPABILITY field which contains the value ’1’. Moreover the upgraded phase 1 infrastructure should assume that the mobile station supports band number 0.

11.2.3.1.2.3.1 CM Service

Test Purpose

The MS sends a CM SERVICE REQUEST message. The FREQUENCY CAPABILITY field of the MOBILE STATION CLASSMARK 2 information element is set to ’1’ (Extension band is supported).

Test Case

Initial Setup


Description

1. A CM SERVICE REQUEST message shall be input on the radio interface by the BSSTE containing MOBILE STATION CLASSMARK 2 with FREQUENCY CAPABILITY ’1’. The response on any interface shall be recorded.

Message flow





1. CM SERVICE REQUEST contained in Complete Layer 3 Information, coded as specified in GSM 04.08 §9.2.15 with Mobile Station classmark 2, Frequency capability = '1' (Extension band is supported).


GSM 04.08 §4.4.4.

11.2.3.1.2.4 SS Screening Indicator

In the MOBILE STATION CLASSMARK 2 information element, 2 bits marked as spare in phase 1 are now used to indicate some supplementary service attributes.(SS SCREENING INDICATOR)

An upgraded phase 1 infrastructure is not allowed to reject messages simply because a bit which is defined as spare in phase 1 in the phase 2 specification is set to ’1’.

11.2.3.1.2.4.1 CM Service - SS Screening Indicator 01

Test Purpose

The MS sends a CM SERVICE REQUEST message. The SS SCREENING INDICATOR field of the MOBILE STATION CLASSMARK 2 information element is set to ’01’.

Test Case

Initial Setup


Description

1. A CM SERVICE REQUEST message shall be input on the radio interface by the BSSTE containing MOBILE STATION CLASSMARK 2 with SS SCREENING INDICATOR ’01’. The response on any interface shall be recorded.

Message flow





1. CM SERVICE REQUEST contained in Complete Layer 3 Information, coded as specified in GSM 04.08 §9.2.15 with Mobile Station classmark 2, SS screening indicator = '01'.


GSM 04.08 §4.4.4.

Page 284 GSM 11.23 v.4.4.0: May 1996


Test Purpose

The MS sends a CM SERVICE REQUEST message. The SS SCREENING INDICATOR field of the MOBILE STATION CLASSMARK 2 information element is set to ’10’.

Test Case

Initial Setup


Description


Message flow







GSM 04.08 §4.4.4.


Test Purpose

The MS sends a CM SERVICE REQUEST message. The SS SCREENING INDICATOR field of the MOBILE STATION CLASSMARK 2 information element is set to '11'.

Test Case

Initial Setup


Description


Message flow







GSM 04.08 §4.4.4.

11.2.3.1.2.5 PS Capability

In the MOBILE STATION CLASSMARK 2 information element, a bit marked as spare in phase 1 is now used to indicate that the mobile station supports the pseudo-synchronised handover procedure. (PS CAPABILITY)

An upgraded phase 1 infrastructure is not allowed to reject messages simply because a bit which is defined as spare in phase 1 in the phase 2 specification is set to '1'.

11.2.3.1.2.5.1 CM Service - PS Capability

Test Purpose

The MS sends a CM SERVICE REQUEST message. The PS CAPABILITY field of the MOBILE STATION CLASSMARK 2 information element is set to '1'.

Test Case

Initial Setup


Page 286 GSM 11.23 v.4.4.0: May 1996

Description

1. A CM SERVICE REQUEST message shall be input on the radio interface by the BSSTE containing MOBILE STATION CLASSMARK 2 with PS CAPABILITY ’1’. The response on any interface shall be recorded.

Message flow





1. CM SERVICE REQUEST contained in Complete Layer 3 Information, coded as specified in GSM 04.08 §9.2.15 with Mobile Station classmark 2, PS capability = '1'.


GSM 04.08 §4.4.4.

11.2.3.1.2.6 Encryption Algorithm A5/2, A5/3

The last octet of the MOBILE STATION CLASSMARK 2 information element has been modified to indicate which encryption algorithms are supported by the mobile station. This octet was marked as spare in the phase 1 specifications.


11.2.3.1.2.6.1 CM Service - Encryption Algorithm A5/2

Test Purpose

The MS sends a CM SERVICE REQUEST message. The octet 5, coded '01' of the MOBILE STATION CLASSMARK 2 information element indicates that the encryption algorithm A5/2 is supported by the MS (A5/2 available, A5/3 not available).

Test Case

Initial Setup


Description

1. A CM SERVICE REQUEST message shall be input on the radio interface by the BSSTE containing MOBILE STATION CLASSMARK 2 with OCTET 5 ’01’. The response on any interface shall be recorded.

Message flow





1. CM SERVICE REQUEST contained in Complete Layer 3 Information, coded as specified in GSM 04.08 §9.2.15 with Mobile Station classmark 2, A5/2 available, A5/3 not available '01'.


GSM 04.08 §4.4.4.

11.2.3.1.2.6.2 CM Service - Encryption Algorithm A5/3

Test Purpose

The MS sends a CM SERVICE REQUEST message. The octet 5, coded '10' of the MOBILE STATION CLASSMARK 2 information element indicates that the encryption algorithm A5/3 is supported by the MS (A5/3 available, A5/2 not available).

Test Case

Initial Setup


Description

1. A CM SERVICE REQUEST message shall be input on the radio interface by the BSSTE containing MOBILE STATION CLASSMARK 2 with OCTET 5 '10'. The response on any interface shall be recorded.

Page 288 GSM 11.23 v.4.4.0: May 1996

Message flow





1. CM SERVICE REQUEST contained in Complete Layer 3 Information, coded as specified in GSM 04.08 §9.2.15 with Mobile Station classmark 2, A5/3 available, A5/2 not available '10'.


GSM 04.08 §4.4.4.

11.2.3.1.2.6.3 CM Service - Encryption Algorithm A5/2, A5/3

Test Purpose

The MS sends a CM SERVICE REQUEST message. The octet 5, coded '11' of the MOBILE STATION CLASSMARK 2 information element indicates that the encryption algorithm A5/2 and A5/3 is supported by the MS (A5/2 available, A5/3 available).

Test Case

Initial Setup


Description

1. A CM SERVICE REQUEST message shall be input on the radio interface by the BSSTE containing MOBILE STATION CLASSMARK 2 with OCTET 5 '11'. The response on any interface shall be recorded.

Message flow


1. CM SERVICE REQUEST, coded as specified in GSM 04.08 §9.2.15.




1. CM SERVICE REQUEST contained in Complete Layer 3 Information, coded as specified in GSM 04.08 §9.2.15 with Mobile Station classmark 2, A5/2 available, A5/3 available '11'.


GSM 04.08 §4.4.4.

11.2.3.1.3 Location Updating Type

In the LOCATION UPDATING TYPE information element, a bit marked as spare in phase 1 is now used to indicate whether a follow-on request is pending at the mobile station.


11.2.3.1.3.1 Location Updating - Location -Updating Type

The MS sends a LOCATION UPDATING REQUEST message. The LOCATION UPDATING TYPE information element indicates follow-on request is pending at the mobile station (FOR = '1')

Test Purpose

The MS sends a LOCATION UPDATING REQUEST message. The LOCATION UPDATING TYPE information element indicates follow-on request is pending at the mobile station (FOR = '1')

Test Case

Initial Setup


Description

1. A LOCATION UPDATING REQUEST message shall be input on the radio interface by the BSSTE containing LOCATION UPDATING TYPE with FOLLOW-ON REQUEST set to '1'. The response on any interface shall be recorded.

Message flow


1. LOCATION UPDATING REQUEST, coded as specified in GSM 04.08 §9.2.15.

Page 290 GSM 11.23 v.4.4.0: May 1996




1. LOCATION UPDATING REQUEST contained in Complete Layer 3 Information, coded as specified in GSM 04.08 §9.2.15 with Location Updating Type, Follow-On Request '1'.


GSM 04.08 §4.4.4.

11.2.3.2 Radio Resource Procedures

11.2.3.2.1 Assignment Procedure

After reception of an ASSIGNMENT COMMAND message, the mobile station may send an ASSIGNMENT FAILURE message containing the new error causes: CHANNEL MODE UNACCEPTABLE or FREQUENCY NOT IMPLEMENTED.

An upgraded phase 1 infrastructure is not allowed to consider as erroneous or invalid ASSIGNMENT FAILURE message containing the new error causes.

11.2.3.2.1.1 Assignment Failure - RR cause 09

Test Purpose

The mobile station sends an ASSIGNMENT FAILURE message on the old main signalling link containing the new error RR cause '09' = CHANNEL MODE UNACCEPTABLE.

Test Case

Initial Setup



Description

1. An ASSIGNMENT REQUEST message shall be input on the A-interface by the BSSTE requesting a TCH. The response on any interface shall be recorded.



Message flow



2. ASSIGNMENT FAILURE on the Air interface, coded as specified: GSM 04.08 §9.1.4 RR cause '09' = CANNEL MODE UNACCEPTABLE



In the case of step 2, an ASSIGNMENT FAILURE message shall occur at the A-interface. The RR cause on the A-interface must not be as like as on the radio interface.


1. ASSIGNMENT COMMAND on the radio interface, coded as specified in GSM 04.08 §9.1.2, with Channel Description = TCH

2. ASSIGNMENT FAILURE on the A-interface, coded as specified in GSM 08.08 §3.2.1.3, with RR cause = CHANNEL MODE UNACCEPTABLE or another one


GSM 04.08 §.3.4.3 GSM 08.08 §.3.1.1.2

11.2.3.2.1.2 Assignment Failure - RR cause 0A0

Test Purpose

The mobile station sends an ASSIGNMENT FAILURE message on the old main signalling link containing the new error RR cause '0A0' = FREQUENCY NOT IMPLEMENTED.

Test Case

Initial Setup


Page 292 GSM 11.23 v.4.4.0: May 1996


Description

1. An ASSIGNMENT REQUEST message shall be input on the A-interface by the BSSTE requesting a TCH. The response on any interface shall be recorded.



Message flow



2. ASSIGNMENT FAILURE on the Air interface, coded as specified: GSM 04.08 §9.1.4 RR cause '0A0' = FREQUENCY NOT IMPLEMENTED



In the case of step 2, an ASSIGNMENT FAILURE message shall occur at the A-interface. The RR cause on the A-interface must not be as like as on the radio interface.


1. ASSIGNMENT COMMAND on the radio interface, coded as specified in GSM 04.08 §9.1.2, with Channel Description = TCH

2. ASSIGNMENT FAILURE on the A-interface, coded as specified in GSM 08.08 §3.2.1.3, with RR cause = FREQUENCY NOT IMPLEMENTED or another one


GSM 04.08 §.3.4.3 GSM 08.08 §.3.1.1.2

11.2.3.2.2 Handover Procedure

After reception of an HANDOVER COMMAND message, the mobile station may send an HANDOVER FAILURE message containing the new error causes: CHANNEL MODE UNACCEPTABLE or FREQUENCY NOT IMPLEMENTED

An upgraded phase 1 infrastructure is not allowed to consider as erroneous or invalid HANDOVER FAILURE message containing the new error causes.

11.2.3.2.2.1 Handover Failure - RR cause 09

Test Purpose

The mobile station sends an HANDOVER FAILURE message on the old main signalling link containing the new error RR cause ’09’ = CHANNEL MODE UNACCEPTABLE.

Test Case

Initial Setup



Description


2. After reception of HANDOVER REQUIRED on the A-interface a HANDOVER COMMAND shall be

input on the A-interface. The response on any interface shall be recorded. 3. The BSSTE shall re-establish the main signalling link and input a HANDOVER FAILURE message

on the radio interface. The response on any interface shall be recorded. Message flow

MS BSS MSC HAND RQD ----------------------------> HAND CMD <---------------------------- HAND CMD <---------------------------- HAND FAILURE ---------------------------> HAND FAILURE ----------------------------> The messages from the BSSTE will be:



RR cause = CHANNEL MODE UNACCEPTABLE Conformance Requirement

In the case of step 1, HANDOVER REQUIRED messages shall occur A-interface. The message shall contain the correct cause, and the preferred list of target cells and the radio environment information corresponding to what has been simulated by the BSSTE.


Page 294 GSM 11.23 v.4.4.0: May 1996

In the case of step 3, a HANDOVER FAILURE message shall occur on the A-interface. The RR cause on the A-interface must not be as like as on the radio interface.



2. HANDOVER COMMAND on the radio interface, coded as specified in GSM 04.08 §9.1.15 3. HANDOVER FAILURE on the A interface, coded as specified in GSM 08.08 §3.2.1.16, with

RR cause = CHANNEL MODE UNACCEPTABLE or another one Requirement reference

GSM 04.08 § GSM 08.08 §

11.2.3.2.2.2 Handover Failure - RR cause 0A0

Test Purpose

The mobile station sends an HANDOVER FAILURE message on the old main signalling link containing the new error RR cause '0A9' = FREQUENCY NOT IMPLEMENTED.

Test Case

Initial Setup



Description


2. After reception of HANDOVER REQUIRED on the A-interface a HANDOVER COMMAND shall be

input on the A-interface. The response on any interface shall be recorded. 3. The BSSTE shall re-establish the main signalling link and input a HANDOVER FAILURE message

on the radio interface. The response on any interface shall be recorded.

Message flow

MS BSS MSC HAND RQD ----------------------------> HAND CMD <---------------------------- HAND CMD <---------------------------- HAND FAILURE ---------------------------> HAND FAILURE ----------------------------> The messages from the BSSTE will be:



RR cause = FREQUENCY NOT IMPLEMENTED Conformance Requirement

In the case of step 1, HANDOVER REQUIRED messages shall occur A-interface. The message shall contain the correct cause, and the preferred list of target cells and the radio environment information corresponding to what has been simulated by the BSSTE.


In the case of step 3, a HANDOVER FAILURE message shall occur on the MSC-interface. The RR cause on the A-interface must not be as like as on the radio interface.



2. HANDOVER COMMAND on the radio interface, coded as specified in GSM 04.08 §9.1.15 3. HANDOVER FAILURE on the A interface, coded as specified in GSM 08.08 §3.2.1.16, with

RR cause = FREQUENCY NOT IMPLEMENTED or another one Requirement reference

GSM 04.08 § GSM 08.08 §

11.2.3.3 Transmission Mode Change

A phase 2 mobile station shall return on a receipt of a CHANNEL MODE MODIFY message in case of no change a CHANNEL MODE MODIFY ACKNOWLEDGE message including a CHANNEL MODE information element describing the old mode.

An upgraded phase 1 infrastructure, which expects a description of the new mode, shall check whether the mode included in the CHANNEL MODE MODIFY ACKNOWLEDGE message is the mode that was ordered in the CHANNEL MODE MODIFY message, and if not it shall conclude to a failure of the transmission mode change procedure.

Page 296 GSM 11.23 v.4.4.0: May 1996

11.2.3.3.1 Channel Mode Modify

Test Purpose

Standard Mobile Originating Call setup for a data channel 9.6 kbit. An ASSIGNMENT REQUEST message is sent with the "channel type" element for a full rate data channel 4.8 kbit.

The CHANNEL MODE MODIFY ACKNOWLEDGE message is sent with the "channel mode" information element describing the old mode (9.6 kbit).

Test Case

Initial Setup

The assignment procedure shall first be performed with a full-rate data traffic channel using 9.6 kbit/s (TCH/F9.6).

Description

1. An ASSIGNMENT REQUEST message shall be input on the A-interface by the BSSTE assigning a full-rate data TCH using 4.8 kbit/s (TCH/F4.8) to the same Mobile Station. The response on any interface shall be recorded.

2. After the receipt of a CHANNEL MODE MODIFY message on the radio interface, the BSSTE shall

input a CHANNEL MODE MODIFY ACKNOWLEDGE message on the radio interface on the main signalling link. The response on any interface shall be recorded.

Message flow

MS BSS MSC ASS REQ (Channel type = TCH/F4.8) <---------------------------- CH MODE MOD <----------------------------- CH MODE MOD ACK (Channel mode = TCH/F9.6) -----------------------------> ASS COM ----------------------------> The messages from the BSSTE will be

1 ASSIGNMENT REQUEST , coded as specified in GSM 08.08 §3.2.1.1 2 CHANNEL MODE MODIFY ACK , coded as specified in GSM 04.08 §9.1.6 Conformance Requirements

In step 1, a CHANNEL MODE MODIFY message shall occur at the radio interface on the main signalling link requesting the TCH/F4.8.

In step 2, an ASSIGNMENT COMPLETE message shall occur on the MSC-interface with the old channel mode.


1. CHANNEL MODE MODIFY, coded as specified in GSM 04.08 §9.1.5, with Channel mode = TCH/F4.8.

2. ASSIGNMENT COMPLETE, coded as specified in GSM 08.08 §3.2.1.2 Channel mode = TCH/F9.6.


GSM 04.08 §3.4.6. GSM 08.08 §3.1.1.

11.2.3.4 Messages

11.2.3.4.1 Classmark Change

The new information element MOBILE STATION CLASSMARK 3 may be included by a phase 2 mobile station in the CLASSMARK CHANGE message.

An upgraded phase 1 infrastructure is not allowed to consider as erroneous or invalid a mobile station simply because it has sent a CLASSMARK CHANGE message including the MOBILE STATION CLASSMARK 3 information element.

11.2.3.4.1.1 Classmark Change - Mobile Station Classmark 3

Test Purpose

After a call has been established on a SDCCH, the MS sends a CLASSMARK CHANGE message including the MOBILE STATION CLASSMARK 3 information element.

The BSS should send a CLASSMARK UPDATE message including the MOBILE STATION CLASSMARK 3 information element on the A-Interface. If the BSS sends the CLASSMARK UPDATE message without the MOBILE STATION CLASSMARK 3 information element, the test verdict is INCONCLUSIVE. In all other cases, the test verdict is FAIL.

Test Case

Initial Setup

A call shall be set up between the radio interface and the A-interface.

Description

1. A CLASSMARK CHANGE message with MOBILE STATION CLASSMARK 3 element shall be input on the radio interface with an appropriate new classmark. The response on any interface shall be recorded.

Message flow

MS BSS MSC CLASS CH -----------------------------> CLASS UPD ----------------------------> The messages from the BSSTE will be:

1. CLASSMARK CHANGE, coded as specified in GSM 04.08 §9.1.11. Conformance Requirements

In step 1, a CLASSMARK UPDATE message shall occur on the A-interface.

Page 298 GSM 11.23 v.4.4.0: May 1996


1. CLASSMARK UPDATE, coded as specified in GSM 08.08 §3.2.1.29 with

Classmark information = Mobile Station Classmark 2 and Mobile Station Classmark 3 from the MS.


GSM 04.08 §3.4.10. GSM 08.08 §3.1.13.

11.2.4 Abis Interface

No cross phase problems are found for the Abis-interface.

11.2.5 A Interface

No cross phase problems are found for the A-interface.

History

June 1994 v 4.0.0 SMG#11 1994-27-06 to 1994-01-07

May 1995 v 4.1.0 SMG#14 1995-03-04 to 1995-07-04

December 1995 v 4.2.0 SMG#16 1995-10-16 to 1995-10-20

March 1996 v 4.3.0 SMG#17 1996-29-02 to 1996-04-03

May 1996 v 4.4.0 SMG#18 1996-05-09 to 1996-05-12

Documents

ETSI TC SMG TDoc SMG 388/96 Meeting #19 Kista, 24 - 28 ... · PDF file7.1 Physical interface layer 1 ... 8.1.3.3.4 No radio resources available ... 8.1.3.7.3 Reversion to old channel