source: smg2 - 株式会社qt smg2 crs to gsm 08.58, 08.08 and 04.18 (gsm-3g handover) introduction...

ETSI/TC/SMG#31bis TD SMG 195/00Frankfurt, Germany Agenda Item: 317 April 2000

Source: SMG2

CRs to GSM 08.58, 08.08 and 04.18 (GSM-3G handover)

Introduction :

This document contains 5 CRs to GSM 08.58, 08.08 and 04.18 agreed by SMG2and forwarded to SMG for approval.

TDoc SMG TDocSMG2

SPEC CR Rev PHASE VERS SUBJECT CAT W.I.

P-00-195 644/00 04.18 A091 R99 8.3.1 RR Intersystem Handover Command B HandoverP-00-195 848/00 04.18 A101 R99 8.3.1 Downlink and Uplink information for Measurement

Reporting and Enhanced Measurement Reporting on3G Cells

B Handover

P-00-195 907/00 08.08 A199 R99 8.3.1 GSM-3G Handover; BSSAP aspects B HandoverP-00-195 852/00 08.08 A205 R99 8.3.1 GSM-3G Handover: ’Service based handover’ B HandoverP-00-195 640/00 08.58 A052 1 R99 8.3.1 New System Information message B Handover

ETSI STC SMG2 Tdoc 644/00Meeting no 35Chicago, U.S.A.3 - 7 April 2000

Revised Tdoc 2B00-37

CHANGE REQUEST Please see embedded help file at the bottom of thispage for instructions on how to fill in this form correctly.

Current Version: 8.2.004.18 CR A091GSM (AA.BB) or 3G (AA.BBB) specification number ↑ Agenda Item; 7.1.5.9

For submission to: SMG#31bis for approval X strategic (for SMGlist expected approval meeting # here

↑for information non-strategic use only)

Form: CR cover sheet, version 2 for 3GPP and SMG The latest version of this form is available from: ftp://ftp.3gpp.org/Information/CR-Form-v2.doc

Proposed change affects: (U)SIM ME X UTRAN / Radio X Core Network(at least one should be marked with an X)

Source: Ericsson Date: 000401

Subject: Inter System Handover Command

Work item: Handover GSM to UMTS

Category: F Correction Release: Phase 2A Corresponds to a correction in an earlier release Release 96

(only one category B Addition of feature X Release 97shall be marked C Functional modification of feature Release 98with an X) D Editorial modification Release 99 X

Release 00

Reason forchange:

New Handover Command message for Handover to UTRAN

Clauses affected: 9.1, 10.4 , new chapters 9.1.15a and 10.5.2.48

Other specs Other 3G core specifications → List of CRs:affected: Other GSM core

specificationsX → List of CRs: TS 08.08

MS test specifications → List of CRs:BSS test specifications → List of CRs:O&M specifications → List of CRs:

Othercomments:

help.doc

<--------- double-click here for help and instructions on how to create a CR.

9.1 Messages for Radio Resources managementTable 9.1/GSM 04.18 summarizes the messages for Radio Resources management.

Table 9.1/GSM 04.18: Messages for Radio Resources management

Channel establishment messages: Reference ADDITIONAL ASSIGNMENT 9.1.1 IMMEDIATE ASSIGNMENT 9.1.18 IMMEDIATE ASSIGNMENT EXTENDED 9.1.19 IMMEDIATE ASSIGNMENT REJECT 9.1.20

Ciphering messages: Reference CIPHERING MODE COMMAND 9.1.9 CIPHERING MODE COMPLETE 9.1.10

Handover messages: Reference ASSIGNMENT COMMAND 9.1.2 ASSIGNMENT COMPLETE 9.1.3 ASSIGNMENT FAILURE 9.1.4 PDCH ASSIGNMENT COMMAND 9.1.13a HANDOVER ACCESS 9.1.14 HANDOVER COMMAND 9.1.15 HANDOVER COMPLETE 9.1.16 HANDOVER FAILURE 9.1.17 INTER SYSTEM HANDOVER TO UTRAN COMMAND 9.1.15a RR-CELL CHANGE ORDER 9.1.21e PHYSICAL INFORMATION 9.1.28 RR INITIALISATION REQUEST 9.1.28a HANDOVER ACCESS 9.1.14 HANDOVER COMMAND 9.1.15 HANDOVER COMPLETE 9.1.16 HANDOVER FAILURE 9.1.17 PHYSICAL INFORMATION 9.1.28

Channel release messages: Reference CHANNEL RELEASE 9.1.7 PARTIAL RELEASE 9.1.26 PARTIAL RELEASE COMPLETE 9.1.27

Paging messages: Reference PAGING REQUEST TYPE 1 9.1.22 PAGING REQUEST TYPE 2 9.1.23 PAGING REQUEST TYPE 3 9.1.24 PAGING RESPONSE 9.1.25

(continued...)

*** Next modified section ***

9.1.15a Inter SystemHandover TO UTRAN Command

This message is sent on the main DCCH by the network to the mobile station to change the dedicatedchannel in GSM to a dedicated channel configuration in UTRAN. See table 9.15/GSM 04.18.

Message type: INTER SYSTEM HANDOVER COMMAND

Significance: dual

Direction: network to mobile station

Table 9.15/GSM 04.18: INTER SYSTEM HANDOVER COMMAND message content

IEI Information element Type / Reference Presence Format lengthRR management Protocol Discriminator M V 1/2Protocol Discriminator 10.2Skip Indicator Skip Indicator M V 1/2

10.3.1Inter System to UTRANHandover Command

Message Type M V 1

Message 10.4

Handover to UTRAN Command Handover To UTRAN Command10.5.2.48

M V 19


10.4 Message TypeThe message type IE and its use are defined in TS 24.007 [20]. Tables 10.1/GSM 04.18 and10.1a/GSM 04.18 define the value part of the message type IE used in the Radio Resource managementprotocol.

Table 10.1/GSM 04.18 (page 1 of 2): Message types for Radio Resource management

8 7 6 5 4 3 2 1

0 0 1 1 1 - - - Channel establishment messages: 1 0 0 - RR INITIALISATION REQUEST 0 1 1 - ADDITIONAL ASSIGNMENT 1 1 1 - IMMEDIATE ASSIGNMENT 0 0 1 - IMMEDIATE ASSIGNMENT EXTENDED 0 1 0 - IMMEDIATE ASSIGNMENT REJECT

0 0 1 1 0 - - - Ciphering messages: 1 0 1 - CIPHERING MODE COMMAND 0 1 0 - CIPHERING MODE COMPLETE

0 0 1 1 0 - - - Configuration change messages: 0 0 0 - CONFIGURATION CHANGE COMMAND 0 0 1 - CONFIGURATION CHANGE ACK. 0 1 1 - CONFIGURATION CHANGE REJECT

0 0 1 0 1 - - - Handover messages: 1 1 0 - ASSIGNMENT COMMAND 0 0 1 - ASSIGNMENT COMPLETE 1 1 1 - ASSIGNMENT FAILURE 0 1 1 - HANDOVER COMMAND 1 0 0 - HANDOVER COMPLETE 0 0 0 - HANDOVER FAILURE 1 0 1 - PHYSICAL INFORMATION

0 0 0 0 1 0 0 0 - RR-CELL CHANGE ORDER 0 0 1 0 0 0 1 1 - PDCH ASSIGNMENT COMMAND

0 0 0 0 1 - - - Channel release messages: 1 0 1 - CHANNEL RELEASE 0 1 0 - PARTIAL RELEASE 1 1 1 - PARTIAL RELEASE COMPLETE

0 0 1 0 0 - - - Paging and Notification messages: 0 0 1 - PAGING REQUEST TYPE 1 0 1 0 - PAGING REQUEST TYPE 2 1 0 0 - PAGING REQUEST TYPE 3 1 1 1 - PAGING RESPONSE 0 0 0 - NOTIFICATION/NCH 1 0 1 - Reserved (see NOTE) 1 1 0 - Reserved (see NOTE) 0 0 0 0 1 0 1 1 - Reserved (see NOTE)

(continued)

NOTE: This value was allocated but never used in earlier phases of theprotocol.

Table 10.1/GSM 04.18 (page 2 of 2): Message types for Radio Resource management

8 7 6 5 4 3 2 1 0 0 0 1 1 - - - System information messages: 0 0 0 - SYSTEM INFORMATION TYPE 8 0 0 1 - SYSTEM INFORMATION TYPE 1 0 1 0 - SYSTEM INFORMATION TYPE 2 0 1 1 - SYSTEM INFORMATION TYPE 3 1 0 0 - SYSTEM INFORMATION TYPE 4 1 0 1 - SYSTEM INFORMATION TYPE 5 1 1 0 - SYSTEM INFORMATION TYPE 6 1 1 1 - SYSTEM INFORMATION TYPE 7

0 0 0 0 0 - - - System information messages: 0 1 0 - SYSTEM INFORMATION TYPE 2bis 0 1 1 - SYSTEM INFORMATION TYPE 2ter 1 0 1 - SYSTEM INFORMATION TYPE 5bis 1 1 0 - SYSTEM INFORMATION TYPE 5ter 1 0 0 - SYSTEM INFORMATION TYPE 9 0 0 0 - SYSTEM INFORMATION TYPE 13

0 0 1 1 1 - - - System information messages: 1 0 1 - SYSTEM INFORMATION TYPE 16 1 1 0 - SYSTEM INFORMATION TYPE 17

0 1 0 0 0 - - - System information messages: 0 0 1 - SYSTEM INFORMATION TYPE 19

0 0 0 1 0 - - - Miscellaneous messages: 0 0 0 - CHANNEL MODE MODIFY 0 1 0 - RR STATUS 1 1 1 - CHANNEL MODE MODIFY ACKNOWLEDGE 1 0 0 - FREQUENCY REDEFINITION 1 0 1 - MEASUREMENT REPORT 1 1 0 - CLASSMARK CHANGE 0 1 1 - CLASSMARK ENQUIRY 0 0 1 1 0 1 1 0 - EXTENDED MEASUREMENT REPORT 0 0 1 1 0 1 1 1 - EXTENDED MEASUREMENT ORDER 0 0 1 1 0 1 0 0 - GPRS SUSPENSION REQUEST

VGCS uplink control messages:

0 0 0 0 1 0 0 1 - VGCS UPLINK GRANT 0 0 0 0 1 1 1 0 - UPLINK RELEASE 0 0 0 0 1 1 0 0 - Reserved (see NOTE) 0 0 1 0 1 0 1 0 - UPLINK BUSY 0 0 0 1 0 0 0 1 - TALKER INDICATION

1 1 0 0 0 - - - Inter System Handover Command messages 0 0 0 - Handover To UTRAN Command

Bit 8 is reserved for possible future use as an extension bit, see TS 24.007.NOTE: This value was allocated but never used in earlier phases of the protocol.


10.5.2.48 Handover To UTRAN Command

The purpose of Handover To UTRAN Command information element is to provide information to themobile of handover to UTRAN.The Handover to UTRAN Command information element contains allinformation needed by the mobile for handover to UTRAN.The Handover To UTRAN Command IE is coded as defined in TS 25.331.The Handover To UTRAN Command is a type 3 IE with length 19.

ETSI SMG2 meeting Document 2-00-848Chicago, Illinois, 3-7 April 2000 Agenda item e.g. for 3GPP use the format TP-99xxx

or for SMG, use the format P-99-xxx


Current Version: 8.3.104.18 CR A101 r1GSM (AA.BB) or 3G (AA.BBB) specification number ↑ ↑ CR number as allocated by MCC support team


↑for information non-strategic X use only)



Source: Vodafone AirTouch, Ericsson, Nokia, Siemens,Qualcomm Europe.

Date: 06-April-00.

Subject: Downlink and Uplink information for Measurement Reporting and Enhanced MeasurementReporting on 3G Cells.

Work item: GSM↔3G handover.



Release 00

Reason forchange:

As the networks grow more complex the mobile should be able to report moreneighbours in a flexible way, including UMTS FDD, UMTS TDD and cdma2000neighbours.

Clauses affected:


specifications→ List of CRs: CR 05.08 Axxx.


Othercomments:

1.7 Applicability of implementationsThe applicability of procedures of this technical specification for the mobile station is dependent on theservices and functions which are to be supported by a mobile station. For the MS, the Revision levelindicating Release ’99 is linked to the full support of the RR protocol and procedures in GSM 04.18Release ’99.

*** Next modified sub-clause ***

2 Normative referencesThe following documents contain provisions which, through reference in this text, constitute provisions of the presentdocument.

- References are either specific (identified by date of publication, edition number, version number, etc.) ornon-specific.

- For a specific reference, subsequent revisions do not apply.

- For a non-specific reference, the latest version applies.

- A non-specific reference to an ETS shall also be taken to refer to later versions published as an EN with thesame number.

- For this Release 1999 document, references to GSM documents are for Release 1999 versions (version 8.x.y).

[1] GSM 01.02: "Digital cellular telecommunications system (Phase 2+); General description of aGSM Public Land Mobile Network (PLMN)".

[2] GSM 01.04: "Digital cellular telecommunications system (Phase 2+); Abbreviations andacronyms".

….[77] IETF RFC 1034: "Domain names - Concepts and Facilities " (STD 7).

[78] GSM 04.65: "Digital cellular telecommunications system (Phase 2+); General Packet RadioService (GPRS); Subnetwork Dependent Convergence Protocol (SNDCP)".

[79] TS 24.008: "3rd Generation Partnership Project; Technical Specification Group Core Network;Mobile Radio Interface Layer 3 specification; Core Network Protocols - Stage 3".

[80] TIA/EIA-IS-2000-5-A: “Upper Layer (Layer 3) Signaling Standard for cdma2000 SpreadSpectrum Systems”.

[81] TIA/EIA-IS-833: “Multi-Carrier Specification for Spread Spectrum Systems on GSM MAP (MC-MAP) (Lower Layers Air Interface)”

*** Next modified sub-clause ***

3.4.1 SACCH procedures3.4.1.1 GeneralIn dedicated mode and group transmit mode, the SACCH is used in signalling layer at least formeasurement results transmission from the mobile station.The SACCH has the particularity that continuous transmission must occur in both directions at least onthe channel carrying the main signalling link. For that purpose, in the mobile station to networkdirection, measurement result messages are sent at each possible occasion when nothing else has to besent (see section 3.4.1.2). Similarly, SYSTEM INFORMATION TYPE 5, 6 and optionally 5bis, 5termessages are sent in the network to mobile station direction in UI frames when nothing else has to besent.

The network may in adddition send MEASUREMENT INFORMATION messages on the SACCH,which may order the MS to use the enhanced measurement report..In a multislot configuration the SYSTEM INFORMATION TYPE 5, 6 and optionally 5bis, and 5terand MEASUREMENT INFORMATION messages shall be sent on the SACCH associated with thechannel carrying the main signalling link.In a multislot configuration the mobile station shall ignore all messages received on the SACCH(s) thatare not associated with the channel carrying the main signalling link.On a VGCS channel, the network may send additional or alternative system information messages forboth mobile stations in group transmit mode and those in group receive mode (see section 3.4.15.2.1).A mobile station with extended measurement capabilities which receives EXTENDEDMEASUREMENT ORDER (EMO) messages on the SACCH, shall perform and report extendedmeasurements, see section 3.4.1.3.The SYSTEM INFORMATION TYPE 5bis message shall be sent if and only if the EXT IND bit in theNeighbour Cell Description information element in both the SYSTEM INFORMATION TYPE 5 andTYPE 5bis messages indicates that each information element only carries part of the BA.

A GSM 900 mobile station which only supports the primary GSM band P-GSM 900 (cf. GSM 05.05)may consider the EXT-IND bit in the Neighbour Cells Description IE in the SYSTEMINFORMATION TYPE 5 message bit as a spare bit, assume that the information element carries thecomplete BA, and ignore any SYSTEM INFORMATION TYPE 5bis messages.

NOTE: The network should take into account limitations of certain mobile stations to understandSYSTEM INFORMATION TYPE 5ter and TYPE 5bis messages, the EXT-IND bit inthe Neighbour Cells Description, and formats used in the Neighbour Cells Descriptioninformation element and Cell Channel Description information element used inSYSTEM INFORMATION messages, see section 10.5.2.1b, and section 10.5.2.22.

As specified in GSM 05.08, problems occurring in the reception of SACCH frames are interpreted as aloss of communication means and appropriate procedures are then triggered as specified in section3.4.13.3.4.1.2 Measurement report and Enhanced Measurement Report

When in dedicated mode or group transmit mode, the mobile station regularly sends eitherMEASUREMENT REPORT or ENHANCED MEASUREMENT REPORT messages to the network.These messages contain measurement results about reception characteristics from the current cell andfrom neighbour cells. The BA (list) which is the basis for the measurements is derived frominformation received on the BCCH in System Information 2 and optionally 2bis and/or 2ter and on theSACCH in System Information 5 and optionally 5bis and/or 5ter.The MEASUREMENTINFORMATION message may add information for the GSM Neighbour List and provide 3GNeighbour list. The Mobile Station shall use ENHANCED MEASUREMENT REPORT messagesinstead of MEASUREMENT REPORT messages if that is indicated by the parameter Report_Type andif at least one BSIC is allocated to each BA (list) frequency.In addition, the MS which implements ECSD options shall use fast inband procedure for downlinkquality reporting if the use of such procedure has been ordered by the BSC.

When the information is received in more than one message the mobile station shall only combineinformation relating to the BA (list) from messages received on the same channel and indicating thesame value of the BCCH allocation sequence number without any message indicating a different valueof the BCCH allocation sequence number received in between. When the information is received inmore than one message the mobile station shall only combine information relating to 3G Radio AccessTechnology from messages indicating the same value of the 3G allocation sequence number withoutany message indicating a different value of the 3G allocation sequence number. If neighbouring cellinformation for the serving cell is not available, the mobile station indicates this in theMEASUREMENT REPORT message. These measurement results are obtained as specified inGSM 05.08.These messages are sent on the slow ACCH, in unacknowledged mode.If no other message is scheduled on the SACCH at the instant when a layer 2 frame is due to be sent,then the mobile station shall send a MEASUREMENT REPORT message or an ENHANCEDMEASUREMENT REPORT or an EXTENDED MEASUREMENT REPORT message (see section3.4.1.3) in that frame. The interval between two successive layer 2 frames containingMEASUREMENT REPORT or ENHANCED MEASUREMENT REPORT messages shall not exceedone layer 2 frame.

*** Next modified clause ***

9.1 Messages for Radio Resources managementTable 9.1/GSM 04.18 summarizes the messages for Radio Resources management.

Table 9.1/GSM 04.18: Messages for Radio Resources management

Channel establishment messages: Reference ADDITIONAL ASSIGNMENT 9.1.1 IMMEDIATE ASSIGNMENT 9.1.18 IMMEDIATE ASSIGNMENT EXTENDED 9.1.19 IMMEDIATE ASSIGNMENT REJECT 9.1.20 Ciphering messages: Reference CIPHERING MODE COMMAND 9.1.9 CIPHERING MODE COMPLETE 9.1.10

Handover messages: Reference ASSIGNMENT COMMAND 9.1.2 ASSIGNMENT COMPLETE 9.1.3 ASSIGNMENT FAILURE 9.1.4 PDCH ASSIGNMENT COMMAND 9.1.13a HANDOVER ACCESS 9.1.14 HANDOVER COMMAND 9.1.15 HANDOVER COMPLETE 9.1.16 HANDOVER FAILURE 9.1.17 RR-CELL CHANGE ORDER 9.1.21e PHYSICAL INFORMATION 9.1.28 RR INITIALISATION REQUEST 9.1.28a HANDOVER ACCESS 9.1.14 HANDOVER COMMAND 9.1.15 HANDOVER COMPLETE 9.1.16 HANDOVER FAILURE 9.1.17 PHYSICAL INFORMATION 9.1.28

Channel release messages: Reference CHANNEL RELEASE 9.1.7 PARTIAL RELEASE 9.1.26 PARTIAL RELEASE COMPLETE 9.1.27

Paging messages: Reference PAGING REQUEST TYPE 1 9.1.22 PAGING REQUEST TYPE 2 9.1.23 PAGING REQUEST TYPE 3 9.1.24 PAGING RESPONSE 9.1.25

(continued...)

Table 9.1/GSM 04.18 (concluded): Messages for Radio Resources management

System information messages: Reference SYSTEM INFORMATION TYPE 1 9.1.31 SYSTEM INFORMATION TYPE 2 9.1.32 SYSTEM INFORMATION TYPE 2bis 9.1.33 SYSTEM INFORMATION TYPE 2ter 9.1.34 SYSTEM INFORMATION TYPE 3 9.1.35 SYSTEM INFORMATION TYPE 4 9.1.36 SYSTEM INFORMATION TYPE 5 9.1.37 SYSTEM INFORMATION TYPE 5bis 9.1.38 SYSTEM INFORMATION TYPE 5ter 9.1.39 SYSTEM INFORMATION TYPE 6 9.1.40 SYSTEM INFORMATION TYPE 7 9.1.41 SYSTEM INFORMATION TYPE 8 9.1.42 SYSTEM INFORMATION TYPE 9 9.1.43 SYSTEM INFORMATION TYPE 13 9.1.43a SYSTEM INFORMATION TYPE 14 9.1.43b

Specific messages for VBS/VGCS: Reference NOTIFICATION/FACCH 9.1.21a NOTIFICATION/NCH 9.1.21b

TALKER INDICATION 9.1.44 UPLINK ACCESS 9.1.45 UPLINK BUSY 9.1.46 UPLINK FREE 9.1.47 UPLINK RELEASE 9.1.48 VGCS UPLINK GRANT 9.1.49

Measurement specific messages: Reference..EXTENDED MEASUREMENT ORDER 9.1.51..EXTENDED MEASUREMENT REPORT 9.1.52 MEASUREMENT REPORT 9.1.21 MEASUREMENT INFORMATION 9.1.53 ENHANCED MEASUREMENT REPORT 2 9.1.54

Miscellaneous messages: Reference CHANNEL MODE MODIFY 9.1.5 CHANNEL MODE MODIFY ACKNOWLEDGE 9.1.6 CHANNEL REQUEST 9.1.8 CLASSMARK CHANGE 9.1.11 CLASSMARK ENQUIRY 9.1.12 FREQUENCY REDEFINITION 9.1.13 SYNCHRONIZATION CHANNEL INFORMATION 9.1.30 RR STATUS 9.1.29 GPRS SUSPENSION REQUEST 9.1.13b

Configuration Change messages: Reference CONFIGURATION CHANGE COMMAND 9.1.12b CONFIGURATION CHANGE ACKNOWLEDGE 9.1.12c CONFIGURATION CHANGE REJECT 9.1.12d

*** Next modified clause ***

9.1.53 MEASUREMENTINFORMATIONThis message is sent on the SACCH or on the main DCCH by the network to the mobile station., toorder the mobile station to send measurement report 2 message. See figure 9.1.53.1/GSM 04.18. If notall information fits into one message, the remaining information will be sent in other instances of thismessage.

Message type: MEASUREMENT INFORMATION

Significance: dual

Direction: network to mobile station

This message can contain a combination of information for e.g. 3G Neighbour Cell Description,Real Time differences, BSICs, Measurement parameters or 3G Measurement parameters.

3G Neighbour Cell Description:

One or more instances of the Measurement Information message may provide 3G Neighbour CellDescription information. This is used to build the 3G Neighbour Cell list. The maximum size of the3G Neighbour Cell list is (0..126).

Building of the 3G Neighbour Cell list:

For each 3G Neighbour Cell Description received:1. The order of indices is FDD Cell indices followed by the TDD Cell indices followed by CDMA2000 Cell indices. The ordering of Cell indices within the same radio Access Technology shallbe based on: 1.a For UMTS FDD: FDD ARFCNs are included as received in the order of each 3GNeighbour Cell description. Then for each FDD ARFCN, theconcatenated Scrambling codes / Time Diversity parameters are orderedby increasing numbers. 1.b For UMTS TDD: TDD ARFCNs are included as received in the order of each 3GNeighbour Cell description. Then for each TDD ARFCN, theconcatenated Cell Parameter / Sync Case / Time diversity parameters are orderedby increasing numbers. 1.c For CDMA 2000: Parameters defining each cell are included as received in the order ofeach 3G Neighbour Cell description.

Any 3G Neighbour Cell Description received is added to the Neighbour Cell list, starting with theindex equal to the parameter Index_Start_3G. If this parameter is not present then the value 0 shallbe used.

Any change/addition for each 3G Neighbour Cell shall overwrite any old data held by the mobilestation for this 3G Neighbour Cell (this means that the value corresponding to 3G Neighbour Cellnot included shall not be modified, with the exceptions described in 3.4.1.2).

If the MS receives some 3G Neighbour Cell Description on some non-supported Radio AccessTechnologies, this shall not be considered as an error. However, indices in the 3G Neighbour Celllist are incremented.

BSIC Description:

One or more instances of the Measurement Information message may provide BSIC informationand gap bit indicators. This is used to build the GSM Neighbour Cell list. The maximum number ofindexes for the BSIC list is equal to 127.

Building of the GSM Neighbour Cell list:

The BSICs are associated to the frequencies in the BA (list). The BSICs may be received before thecorresponding BA (list). The first BSIC in each instance applies to the frequency in the BA (list)referenced by the parameter Start_Index_BA. For each successive BSIC, there is a bit indicating ifthe BSIC applies to the same frequency as the previous BSIC or to the next frequency in the BA(list).

Any change/addition for each GSM Neighbour Cell shall overwrite any old data held by the mobilestation for this GSM Neighbour Cell (this means that the values corresponding to a GSM NeighbourCell not included shall not be modified, with the exceptions described in 3.4.1.2).

Real Time Difference Description:

One or more instances of the Measurement Information message may provide Real Time Differenceinformation. This is used to build the Real Time Difference list. The maximum number of indexesfor the Real Time Difference list is equal to 127.

Building of the Real Time Difference list:

Each frequency in the BA (list) can be associated to 0, 1 or more Real Time Difference parameters.The Real Time Difference parameters may be received before the corresponding BA (list). The firstReal Time Difference parameter in each instance applies to the frequency in the BA (list)referenced by the parameter Start_Index_BA. In the recursive structure, a bit indicates (with 1 or 0)if the same or the subsequent BA (list) frequency is referenced. In the first case, a RTD parameter isincluded after this bit.

Any change/addition for each Real Time Difference shall overwrite any old data held by the mobilestation for this Real Time Difference (this means that the values corresponding to Real TimeDifference not included shall not be modified, with the exceptions described in 3.4.1.2).

Priority Description

Each Priority bit of this field relates to the index of the Neighbour Cells.

If the MS has no 3G Neighbour cell list:Then this relates to the GSM Neighbour Cell list.

If the MS has a 3G Neighbour cell list:Then this relates to the concatenated GSM Neighbour Cell list and 3G Neighbour cell list. For theconcatenation the value of the parameter Absolute_Index_Start_EMR is added to the 3G Neighbourcell indexes. In this concatenation the indices exceeding the value 126 are ignored. If there are lessindices than 126, the value 0 shall be assumed for the missing bits.

<Measurement information> ::=

< RR short PD : bit > -- See GSM 04.07< Message type : bit (5) > -- See 10.4< Short layer 2 header : bit (2) > -- See GSM 04.06

< BA_IND : bit >< 3G_BA_IND : bit >< Report_Type : bit >< REPORTING_RATE : bit >< UNKNOWN_BSIC_REPORTING : bit >

{ L | H < 3G Neighbour Cells Description : 3G Neighbour Cells Description > }

{ L | H < Real Time Difference Description : Real Time Difference Description > } -- (GSMRAT){ L | H < BSIC Description : BSIC Description > }

{ L | H < PRIORITY Description : PRIORITY Description > }{ L | H < MEASUREMENT Parameters Description : MEASUREMENT ParametersDescription > }{ L | H < 3G MEASUREMENT Parameters Description : 3G MEASUREMENTParameters Description > }

< spare padding > ;

< 3G Neighbour Cells Description > : :={{ 0 | 1 < Count : bit (3)> }{ 0 | 1 < Index_Start_3G : bit (7)> } { 0 | 1 < Absolute_Index_Start_EMR : bit (7)> }{ 0L | 1H < UMTS FDD Description : UMTS FDD Description > }{ 0L | 1H < UMTS TDD Description : UMTS TDD Description > }{ 0L | 1H < CDMA2000 Description : CDMA2000 Description > }}

< UMTS FDD Description > : :={{ 0 | 1 < Bandwidth_FDD : bit (3) > }{ 1H { < Repeated UMTS FDD Neighbour Cells : Repeated UMTS FDD Neighbour Cellsstruct > } ** 0L }}< Repeated UMTS FDD Neighbour Cells struct > ::={ 0 < FDD-ARFCN : bit (14) > | 1 < FDD-ARFCN-INDEX : bit (3) > }< Number_of_Scrambling_Codes_and_Diversity : bit (5) >< Range-1024-Format Scrambling Codes and Diversity Field :bit(p(Number_of_Scrambling_Codes_and_Diversity)) > ; -- p(x) defined in tablexxx/GSM 04.18

< UMTS TDD Description > : :={{ 0 | 1 < Bandwidth_TDD : bit (3) > }{ H { < Repeated UMTS TDD Neighbour Cells : Repeated UMTS TDD Neighbour Cellsstruct > } ** L }}< Repeated UMTS TDD Neighbour Cells struct > ::={ 0 < TDD-ARFCN : bit (14) > | 1 < TDD-ARFCN-INDEX : bit (3) > }< Number_of_Cell Parameters_and_sync cases_and_Diversity : bit (5) >< Range-512-Format Cell Parameters and syncs cases and Diversity :bit(q(Number_of_Scrambling_Codes_and_Diversity) > ; -- q(x) defined in tablexxx/GSM04.18

< CDMA 2000 Description > ::={ <cdma2000 frequency band : bit(5)> <cdma2000 frequency : bit(11)>

< number_cdma2000_cells : bit (5) >

{<Pilot PN offset : bit(9)> -- this information is enough for 1X Common Pilot

{0|1{000{<TD_MODE : bit (2)> <TD_POWER_LEVEL : bit(3)>} -- additional information for 1X Common Pilot with Transmit Diversity

|001{<QOF : bit(2)> <WALSH_LEN_A : bit(3)> <AUX_PILOT_WALSH : bit(val(WALSH_LEN_A)+6)>} -- additional information for 1X Auxiliary Pilot

|010{< QOF : bit(2)> <WALSH_LEN_B : bit(3)> <AUX_TD_WALSH : bit(val(WALSH_LEN_B)+6)> <AUX_TD_POWER_LEVEL : bit(2)> <TD_MODE : bit(2)>} -- additional information for 1X Auxiliary Pilot with Transmit Diversity

|011{<SR3_PRIM_PILOT : bit(2)> <SR3_PILOT_POWER1 : bit(3)> <SR3_PILOT_POWER2 : bit(3)>} -- additional information for 3X Common Pilot

|110{<SR3_PRIM_PILOT : bit(2)> <SR3_PILOT_POWER1 : bit(3)> <SR3_PILOT_POWER2 : bit(3)> <QOF : bit(2)> <WALSH_LEN_C : bit(3)> <AUX_WALSH_LEN : bit(val(WALSH_LEN_C)+6)> {0|1< QOF1 : bit(2)> < WALSH_LENGTH1 : bit(3)> < AUX_PILOT_WALSH1 : bit(val(WALSH_LENGTH1)+6)>} {0|1< QOF2 : bit(2)> <WALSH_LENGTH2 : bit(3)> <AUX_PILOT_WALSH2 : bit(val(WALSH_LENGTH2)+6)>}} -- additional information for 3X Auxiliary Pilot } } } * val(number_cdma2000_cells) }

< Real Time Difference Description > : :={0 | 1 { 0 | 1 < START_INDEX_BA : bit (7) > } --default value=1 < N1: bit(7)> < RTD : bit (6) > { 0 | 1 < RTD : bit(6) >} * (val(N1)) -- 0 means same frequency}

{0 | 1 { 0 | 1 < START_INDEX_BA : bit (7) > } --default value=1 < N2: bit(7)> < RTD : bit (12) > { 0 | 1 < RTD : bit(12) >} * (val(N2)) -- 0 means same frequency} ;

< BSIC Description > ::= { 0 | 1 < Start_BSIC_Index : bit (7) > } < BSIC : bit (6) > < Number_Remaining_BSIC: bit (7) > { < Frequency_Scrolling : bit > < BSIC : bit (6) > } * (val(Number_Remaining_BSIC)) ;

< PRIORITY Description > : :={Number_Cells : bit(7) ;{ PRIORITY: bit } * (val(Number_Cells)}

< MEASUREMENT PARAMETERS Description > : :={ { 0 | 1 < Multiband_Reporting : bit (2) > } { 0 | 1 < Serving_Band_Reporting : bit (2) > } { 0 | 1 < SCALE : bit(2) > }

{ 0 | 1 { 0 | 1 < 900_Offset : bit (3) > } { 0 | 1 < 900_Threshold_Reporting : bit (3) > } }




{ 0 | 1 { 0 | 1 < 850_Offset : bit (3) > } { 0 | 1 < 850_Threshold_Reporting : bit (3) > } }}

< 3G MEASUREMENT PARAMETERS Description > : :={ { < Qsearch_D : bit (4) > }

{ 0 | 1 { 0 | 1 < FDD_MULTIMODE_REPORTING : bit (2) > } -- FDDParameters { 0 | 1 < FDD_Offset : bit (3) > } { 0 | 1 < FDD_Threshold_Reporting : bit (3) > } }

{ 0 | 1 { 0 | 1 < TDD_MULTIMODE_REPORTING : bit (2) > } -- TDDParameters { 0 | 1 < TDD_Offset : bit (3) > } { 0 | 1 < TDD_Threshold_Reporting : bit (3) > } }

{ 0 | 1 { 0 | 1 < CDMA2000_MULTIMODE_REPORTING : bit (2) > } --CDMA2000 Parameters { 0 | 1 < CDMA2000_Offset : bit (3) > } { 0 | 1 < CDMA2000_Threshold_Reporting : bit (3) > } }}

Figure 9.1.53.1/GSM 04.18: Measurement Information message content

BA-IND (1 bit), BCCH allocation sequence number indication.The BA-IND is needed to allow the network to discriminate measurements results related to differentneighbour lists sent to the MS. The value of this parameter is reflected in the ENHANCEDMEASUREMENT REPORT message and in the MEASUREMENT REPORT message.

Report_Type (1bit)This parameter is used to indicate to the mobile to use the Enhanced Measurement report or

Measurement report messages for reporting:Bit0 The MS shall use the Enhanced Measurement Report message for reporting if at least one BSIC isallocated to each BA (list) frequency.1 The MS shall use the Measurement Report message for reporting.

REPORTING_RATE (1 bit)This parameter is used for measurements, see GSM 05.08.bit0 SACCH rate reporting1 Reduced reporting rate allowed

UNKNOWN_BSIC_REPORTING (1 bit)This field specifies if cells with unknown BSIC and allowed NCC part of BSIC are allowed to bereported or not, see GSM 05.08.bit0 Report on cells with unknown BSIC and allowed NCC part of BSIC is not allowed.1 Report on cells with unknown BSIC and allowed NCC part of BSIC is allowed.

3G Neighbour Cells Description:Count (3 bits)When 3G-BA-IND is received in a changed state, this parameter indicates the number of instances of3G Neighbour Cells Description which shall be received before the MS reports on this newinformation. Two different instances of 3G Neighbour Cells description are two 3G Neighbour CellsDescription with different Index_Start_3G.

3G-BA-IND (1 bit), 3G allocation sequence number indication.The 3G-BA-IND is needed to allow the network to discriminate measurements results related todifferent 3G neighbour lists sent to the MS. The value of this parameter is reflected in the ENHANCEDMEASUREMENT REPORT message and in the MEASUREMENT REPORT message.Index_Start_3G (7 bit)This optional information element indicates the binary value of the first index to use to build thisinstance of the 3G Neighbour Cell list. When missing, the value 0 is assumed.Absolute_Index_Start_EMR (7 bit)This parameter indicates in binary the value to be added to the indexes of the 3G Neighbour list for 3Genhanced measurement reporting. This parameter does not impact the 3G measurement reporting. Ifthis parameter is absent, the same value than received in a previous instance (with the exceptionsdefined in 3.4.1.2) is assumed.

UMTS FDD Description:

Bandwidth_FDD (3bit field)This optional information element is defined in 3G TS 25.331.

FDD_ARFCN (14 bit field)Bits 1-9 of this optional information element are defined in GSM 05.05. Any parameter received withbits 10, 11, 12, 13 or 14 equal to 1 do not trigger measurements in this version of the protocol.However this leads to index increasing.Number_of_Scrambling_Codes_and_Diversity (n) (5 bit field)This optional field defines the decimal value of the number of Scrambling Codes/Diversity parameters(0–31).Range-1024-Format Scrambling Codes and Diversity Field (p bit field)This field allows to compute a set of 10-bit-long Scrambling Codes and Diversity Parameters, re-usingthe Range 1024format compression algorithm, see Annex J: ‘Algorithm to encode frequency list information’. Thecomputationformulas for decoding are given in the ‘Range 1024 format’ sub-clause, 10.5.2.13.3. The consecutiveparameters of thisfield are concatened, starting with the bit FDD_Indic0, and then w1, w2… Each parameter starts with

the MostSignificant Bit. FDD_Indic0, information 0 indicator (1 bit): 0 information ‘0000000000’ is not a member of the set 1 information ‘0000000000’ is a member of the set NOTE: This bit FDD_Indic0 is equivalent than the bit F0 bit in the frequency listinformation element.

For each (10-bit-long) decoded Parameter, bits 1-9 are the Scrambling Codes and bit 10 is thecorresponding Diversity Parameter.

The total number of bits p of this field depends on the value of the parameterNumber_of_Scrambling_Codes_and_Diversity = n, as follows (with p=0 if n=0):

n p n p n p n p n p n p1 11 6 53 11 89 16 123 21 153 26 1832 20 7 61 12 96 17 129 22 159 27 1893 29 8 68 13 103 18 135 23 165 28 1954 37 9 75 14 110 19 141 24 171 29 2015 45 10 82 15 117 20 147 25 177 30 207

UMTS TDD Description:

Bandwidth_TDD (3bit field)This optional information element is defined in 3G TS 25.331.TDD_ARFCN (14 bit field)Bits 1-10 of this optional information element are defined in GSM 05.05. Any parameter received withbits 11, 12, 13 or 14 equal to 1 do not trigger measurements in this version of the protocol. Howeverthis leads to index increasing.Number_of_Cell Parameters_and_Sync Sases_and_Diversity (m) (5 bit field)This optional field defines the decimal value of the number of Cell Parameters/Sync Case/TimeDiversity parameters (0–31).Range-512-Format Cell Parameters and syncs cases and Diversity (q bit field)This field allows to compute a set of 9-bit-long Scrambling Codes and Diversity Parameters, re-usingthe Range 512format compression algorithm, see Annex J: ‘Algorithm to encode frequency list information’. Thecomputationformulas for decoding are given in the ‘Range 512 format’ sub-clause, 10.5.2.13.4, with w0=0. Theconsecutive parameters of this field are concatened, starting with the bit TDD_Indic0, and then w1,w2… Each parameter starts with the Most Significant Bit. TDD_Indic0, information 0 indicator (1 bit): 0 information ‘000000000’ is not a member of the set 1 information ‘000000000’ is a member of the set NOTE: This bit TDD_Indic0 is equivalent than the bit F0 bit in the frequency listinformation element.

For each (9-bit-long) decoded Parameter, bits 1-7 are the Cell Parameters, bit 8 is the Sync Case and bit9 is the Diversity bit..

The total number of bits q of this field depends on the value of the parameter Number_of_CellParameters_and_Sync Cases_and_Diversity = m, as follows (with q=0 if m=0):

m q m q m q m q m q m q1 10 6 47 11 78 16 106 21 132 26 1572 18 7 54 12 84 17 112 22 137 27 1613 26 8 60 13 90 18 117 23 142 28 1664 33 9 66 14 96 19 122 24 147 29 1715 40 10 72 15 102 20 127 25 152 30 176

CDMA 2000 Description:

cdma2000 frequency band, a binary representation of cdma2000 BAND_CLASS, as defined inTIA/EIA-IS-2000-5-A. The mobile station shall ignore all the information relative to a cdma2000frequency band that it can not support.cdma2000 frequency, a binary representation of cdma2000 CDMA_FREQ, as defined in TIA/EIA-IS-2000-5-A. The mobile station shall ignore all the information relative to a cdma2000 frequency thatit can not support.number_cdma2000_cells (5 bit field)This field indicates the number of CDMA 2000 neighbour cells.

cdma2000 Pilot PN offset, a binary representation of the PN offset of the Pilot PN sequence (in unitsof 64 cdma2000 1x-chips), PILOT_PN, as defined in TIA/EIA-IS-2000-5-A.TD_MODE, an indication of transmit diversity mode is specified in TIA/EIA-IS-2000-5-A. Themobile station shall ignore TD_MODE if it does not support 1X Common Pilot with TransmitDiversity.TD_POWER_LEVEL, power level of the Transmit Diversity Pilot relative to that of the ForwardPilot Channel as specified in TIA/EIA/IS-2000-5-A. The mobile station shall ignoreTD_POWER_LEVEL if it does not support 1X Common Pilot with Transmit Diversity.QOF, quasi-orthogonal function index is defined in TIA/EIA/IS-2000-5-A. The mobile station shallignore QOF if it does not support the quasi-orthogonal function.WALSH_LEN_A, WALSH_LEN_B and WALSH_LEN_C, a three bit field to indicate the length ofthe Walsh code for the pilot that is used in as the Auxiliary Pilot, and specified as WALSH_LEN inTIA/EIA/IS-2000-5-A. The mobile station shall ignore WALSH_LEN if it does not support 1XAuxiliary Pilot.AUX_PILOT_WALSH indicates the walsh code corresponding to the Auxiliary Pilot, as specified inTIA/EIA/IS-2000-5-A. The mobile station shall ignore AUX_PILOT_WALSH if it does not support1X Auxiliary Pilot.AUX_TD_WALSH indicates the walsh code corresponding to the Auxiliary Transmit Diversity Pilot,as specified in TIA/EIA/IS-2000-5-A. The mobile station shall ignore AUX_TD_WALSH if it does notsupport 1X Auxiliary Pilot with Transmit Diversity.AUX_TD_POWER_LEVEL, power level of the Auxiliary Transmit Diversity Pilot relative to that ofthe Forward Pilot Channel as specified in TIA/EIA/IS-2000-5-A. The mobile station shall ignoreAUX_TD_POWER_LEVEL if it does not support 1X Auxiliry Pilot with Transmit Diversity.SR3_PRIM_PILOT, position of the primary SR3 pilot as specified in TIA/EIA/IS-2000-5-A. Themobile station shall ignore SR3_PRIM_PILOT if it does not support 3X Common Pilot.SR3_PILOT_POWER1, relative power level between the primary SR3 pilot and the pilot on thelower frequency of the two remaining SR3 frequencies, as specified in TIA/EIA/IS-2000-5-A. Themobile station shall ignore SR3_PILOT_POWER1 if it does not support 3X Common Pilot.SR3_PILOT_POWER2, relative power level between the primary SR3 pilot and the pilot on thehigher frequency of the two remaining SR3 frequencies, as specified in TIA/EIA/IS-2000-5-A. Themobile station shall ignore SR3_PILOT_POWER2 if it does not support 3X Common Pilot.QOF1, WALSH_LEN1 and AUX_PILOT_WALSH1 are the corresponding quantities for pilot onthe lower frequency of the two remaining SR3 frequencies, as specified in TIA/EIA/IS-2000-5-A. Themobile station shall ignore QOF1, WALSH_LEN1 and AUX_PILOT_WALSH1 if it does not support3X Auxiliary Pilot.QOF2, WALSH_LENGTH2 and AUX_PILOT_WALSH2 are the corresponding quantities for piloton the higher frequency of the two remaining SR3 frequencies, as specified in TIA/EIA/IS-2000-5-A.The mobile station shall ignore QOF2, WALSH_LEN2 and AUX_PILOT_WALSH2 if it does notsupport 3X Auxiliary Pilot.

PRIORITY DescriptionPriority bit:0 Normal reporting priority1 High reporting priority

Real Time Difference Description

START_INDEX_BA (7 bit field)This field indicates the BA (list) index for the first RTD parameter.

RTD (6 or 12 bit field) are defined in GSM 05.08.

MEASUREMENT PARAMETERS DescriptionThe fields of this Description are used for measurements, see GSM 05.08. They are defined in GSM05.08.Any parameter present overwrites any old data held by the mobile station for this parameter. Thismeans that the value corresponding to a parameter not included is not modified, with the exceptiondefined in 3.4.1.2. In this last case, default values are:For the SCALE field: ‘00’ (normal range).

3G MEASUREMENT PARAMETERS DescriptionThe fields of this Description are used for measurements, see GSM 05.08. They are defined in GSM05.08.Any parameter present overwrites any old data held by the mobile station for this parameter. Thismeans that the value corresponding to a parameter not included is not modified, with the exceptiondefined in 3.4.1.2.

Table 9.1.53.1/GSM 04.18: Measurement Information information element details.

9.1.54 ENHANCEDMEASUREMENT REPORTThis message containing measurement results is sent on the SACCH by the mobile to the network. Seefigure 9.1.54.1/GSM 04.18.This message may contain reports on GSM and/or 3G Radio Access Technologies. Measurements aredefined in GSM 05.08.

Report on GSM Radio Access Technology:

The GSM Neighbour Cell list, defined in 9.1.53, shall be used.

Report on others Radio Access Technologies:

The 3G Neighbour Cell list, defined in 9.1.53, shall be used.

The 3G Neighbour cell list is concatenated to the GSM Neighbour Cell list. For the concatenation thevalue of the parameter Absolute_Index_Start_EMR is added to the 3G Neighbour cell indexes. In thisconcatenation the indices exceeding the value 126 are ignored. If this leads to GSM RAT and 3Goverlapping indices, these overlapping indices shall be considered as GSM RAT indices.

Message type: ENHANCED MEASUREMENT REPORT

Significance: dual

Direction: mobile station to network

<Enhanced Measurement report 2> ::=

< RR short PD : bit > -- See GSM 04.07< Message type : bit (5) > -- See 10.4< Short layer 2 header : bit (2) > -- See GSM 04.06

< BA_USED : bit >< 3G_BA_USED : bit >< BSIC_Seen : bit >

{ 0 | 1 < SCALE : bit(2) > }

< Serving cell data : < Serving cell data struct >>

{ 1H { < Repeated Unknown_BSIC_Information : Repeated Unknown_BSIC_Informationstruct > } ** 0L }}

< NCELL_NUMBER : bit (7) >

{0 | 1 < REPORTING_QUANTITY : bit (6) > }* (val(NCELL_NUMBER)) - - bitmap typereporting

-- Only 3 more bits are available in this message< spare padding > ;

< Serving cell data struct > ::=< DTX_USED : bit >< RXLEV_VAL : bit (6) >< RX_QUAL_FULL : bit (3) >< MEAN_BEP : bit (5) >< CV_BEP : bit (3) >< NBR_RCVD_BLOCKS : bit (5) > ;

< Repeated Unknown_BSIC_Information struct > ::=< BCCH-FREQ-NCELL : bit (5) >< BSIC : bit (6) >< RXLEV-NCELL : bit (6) > ;

Figure 9.1.54.1/GSM 04.18: Enhanced Measurement Report Information messagecontent

BA_USED (1 bit field),The value of the BA-IND field of the neighbour cells description information element or elementsdefining the BCCH allocation used. Range 0 to 1.

3G_BA_USED (1 bit field)The value of the 3G-BA-IND field of the neighbour cells description information element or elementsdefining the 3G allocation used. Range 0 to 1.

BSIC_Seen (1 bit field)This parameters indicates if a GSM RAT cell with unknown BSIC and allowed NCC part BSIC is oneof the six strongest, see GSM 05.08.Bit0 Unknown and allowed BSIC not seen1 Unknown and allowed BSIC seen

SCALE (2 bit field)The value of this optional field is defined in GSM 05.08.

Serving cell reportingParameters RXLEV_VAL (6 bits), RX_QUAL_FULL (3 bits), MEAN_BEP (5 bits), CV_BEP (3bits), NBR_RCVD_BLOCKS (5 bits) are defined in GSM 05.08.

DTX_USED (1 bit field)This bit indicates whether or not the mobile station used DTX during the previous measurementperiod.0 DTX was not used1 DTX was used.

Neighbour cell reporting

Repeated Unknown BSIC

BCCH-FREQ-NCELL (5 bits). This field represents the index of the BA (list), see 10.5.2.20.BSIC (6 bits). Base station identity code of the corresponding index in the BA (list).RXLEV (6 bits). GSM RAT reporting quantity, see GSM 05.08.

NCELL_NUMBERThis field indicates the number of Neighbour Cells.

Reporting_Quantity (6 bits):

Measurement quantities are defined in GSM 05.08.:

Table 9.1.54.1/GSM 04.18: Enhanced Measurement Report 2 information elementdetails.

NEXT CHANGES in Chapter 10.4

Table 10.1a/GSM 04.18: Message types for Radio Resource management messagesusing the RR short protocol discriminator

+---------------------------------------------------+�� ON/FACCH ��

+---------------------------------------------------+

5 4 3 2 10 0 0 0 0 System Information Type 100 0 0 0 1 Notification/FACCH0 0 0 1 0 Uplink Free0 0 1 0 0 Enhanced Measurement Report 2 (uplink)0 0 1 0 1 Measurement Information (downlink)

NEXT CHANGES

10.5.2.20 Measurement ResultsThe purpose of the Measurement Results information element is to provide the results of themeasurements made by the mobile station on the serving cell and the neighbour cells.The Measurement Results information element is coded as shown in figure 10.5.47/GSM 04.18 andtable 10.5.47/GSM 04.18.The Measurement Results is a type 3 information element with 17 octets length.

8 7 6 5 4 3 2 1Measurement Results IEI octet 1

BA-USED

DTXUSED

RXLEV-FULL-SERVING-CELL octet 2

3G-BA-USED0spare

MEAS-VALID

RXLEV-SUB-SERVING-CELL octet 3

0spare

RXQUAL-FULLSERVING-CELL

RXQUAL-SUBSERVING-CELL

NO-NCELL

M(highpart)

octet 4

NO-NCELL-M(low part) RXLEV-NCELL 1

octet 5

BCCH-FREQ-NCELL 1 BSIC-NCELL 1(high part)

octet 6

BSIC-NCELL 1(low part)

RXLEV-NCELL 2(high part)

octet 7

RXLEVNCELL

2(lowpart)

BCCH-FREQ-NCELL 2BSIC-NCELL

2(high part)

octet 8

(continued)

Figure 10.5.47/GSM 04.18 Measurement Results information element



octet 9

RXLEV-NCELL 3

(low part)BCCH-FREQ-NCELL 3

BSIC-NCELL

3(highpart)

octet 10



octet 11

RXLEV-NCELL 4(low part)

BCCH-FREQ-NCELL 4 octet 12

BSIC-NCELL 4RXLEV-NCELL

5(high part)

octet 13


BCCH-FREQ-NCELL 5(high part)

octet 14

BCCH-FREQ-NCELL5 (lowpart)

BSIC-NCELL 5

RXLEVNCELL

6(highpart)

octet 15


BCCH-FREQ-NCELL 6(high part)

octet 16

BCCH-FREQ-NCELL 6(low part)

BSIC-NCELL 6 octet 17

Figure 10.5.47/GSM 04.18 Measurement Results information element (continued)

Table 10.5.47/GSM 04.18: Measurement Results information element

BA-USED (octet 2), the value of the BA-IND field of the neighbour cells descriptioninformation element or elements defining the BCCH allocation used for the coding ofBCCH-FREQ-NCELL fields. Range 0 to 1.DTX-USED (octet 2) This bit indicates whether or not the mobile station used DTX duringthe previous measurement period.Bit 70 DTX was not used1 DTX was usedRXLEV-FULL-SERVING-CELL and RXLEV-SUB-SERVING-CELL, (octets 2 and 3)Received signal strength on serving cell, measured respectively on all slots and on a subsetof slots (see GSM 05.08)The RXLEV-FULL-SERVING-CELL and RXLEV-SUB-SERVING-CELL fields arecoded as the binary representation of a value N. N corresponds according to the mappingdefined in GSM 05.08 to the received signal strength on the serving cell.Range: 0 to 63MEAS-VALID (octet 3)This bit indicates if the measurement results for the dedicated channel are valid or notBit 70 The measurement results are valid1 the measurement results are not valid3G-BA-USED (octet 3)The value of the 3G-BA-IND field of the neighbour cells description information element orelements defining the BCCH allocation used for the coding of 3G BCCH-FREQ-NCELLfields. Range 0 to 1.

RXQUAL-FULL-SERVING-CELL and RXQUAL-SUB-SERVING-CELL (octet 4)Received signal quality on serving cell, measured respectively on all slots and on a subset ofthe slots (see TS. GSM 05.08)

(continued...)

Table 10.5.47/GSM 04.18: Measurement Results information element (continued)

CELL fields are coded as the binary representation of the received signal quality on theserving cell.

Range: 0 to 7 (See GSM 05.08)

NO-NCELL-M, Number of neighbouring cell measurements (octets 4 and 5)

Bits

1 8 7

0 0 0 No neighbour cell measurement result

0 0 1 1 " " " "

0 1 0 2 " " " "

0 1 1 3 " " " "

1 0 0 4 " " " "

1 0 1 5 " " " "

1 1 0 6 " " " "

1 1 1 Neighbour cell information not available for serving cell

RXLEV-NCELL i, Received signal strengthResult of measurement on the i’thneighbouring cell (octet 5, 7, 8, 9, 10, 11, 12, 13, 14, 15 and 16)

If the i’th neighbouring cell is a GSM RAT cell, Tthe RXLEV-NCELL field is coded asthe binary representation of a value N. N corresponds according to the mappingdefined in TS. GSM 05.08 to the received signal strength on the i’th neighbouringcell. See note 1 & 2.

If the I’th neighbouring cell is a UMTS FDD cell, the field ‘RXLEV-NCELL’ in Figure10.5.47 carries the CPICH Ec/No parameter, defined in 3G TS 25.331.

If the I’th neighbouring cell is a UMTS TDD cell, the field ‘RXLEV-NCELL’ field inFigure 10.5.47 carries the RSCP parameter, defined in 3G TS 25.331.

If the I’th neighbouring cell is a CDMA 2000 cell, the field ‘RXLEV-NCELL’ in Figure10.7.47 field carries the PILOT_STRENGTH CDMA 2000 reporting quantityparameter defined in TIA/EIA-IS-2000-5-A[TBD].

Range: 0 to 63.

(continued...)

Table 10.5.47/GSM 04.18: Measurement Results information element (concluded)

- Report on GSM Radio Access Technology cells:

BCCH-FREQ-NCELL i, BCCH carrier of the i’th neighbouring cell (octet 6, 8,10, 12, 14,15, 16 and 17)

The BCCH-FREQ-NCELL i field is coded as the binary representation of the position,starting with 0, of the i’th neighbouring cells BCCH carrier in the BCCH channel list. TheBCCH channel list is composed of one or two BCCH channel sub lists, each sub list isderived from the set of frequencies defined by reference neighbour cells descriptioninformation element or elements. In the latter case the set is the union of the two setsdefined by the two neighbour cells description information elements.

In each BCCH channel sub list the absolute RF channel numbers are placed in increasingorder of ARFCN, except that ARFCN 0, if included in the set, is put in the last position in thesub list. The BCCH channel list consists either of only the sub list derived from the neighbourcells description information element(s) in System Information 2/5 (and possible 2bis/5bis) orof that sub list immediately followed by the sub list derived from the neighbour cellsdescription information element in System Information 2ter/5ter for the case SystemInformation 2ter/5ter is also received. If the set of ARFCNs defined by the referenceneighbour cells description information element or elements includes frequencies that themobile station does not support then these ARFCNs shall be included in the list.The notation 2/5 etc. means that the rules above apply to the neighbour cells descriptioninformation elements received in System Information 2, 2bis and 2ter and to those receivedin System Information 5, 5bis and 5ter separately.

See note 1 & 2.

Range: 0 to 3130.

- Report on 3G Radio Access Technology cells:

The index BCCH-FREQ-NCELL 31 is allocated to indicate report(s) on 3G Radio AccessTechnology cells.

The indices of the 3G Neighbour Cell list defined in sub-clause 9.1.53 shall be used as areference. If a 3G cell is indicated, the corresponding ‘RXLEV-NCELL’ field in Figure 10.5.47carries the position of the i'th 3G neighbouring cell.Range: 0 to 63.

BSIC-NCELL i, Base station identity code of the i'th neighbouring cell (octet 6, 7, 8, 9, 10, 11,13, 15 and 17)

For the GSM Radio Access Technology, Tthe BSIC-NCELL i field is coded as the binaryrepresentation of the base station identity code of the i'th neighbouring cell. See note 1 & 2.

Range: 0 to 63.

NOTE 1: If the field extends over two octets the highest numbered bit of the lowestnumbered octet is the most significant and the lowest numbered bit of the highest numberedoctet is the least significant.

NOTE 2: If NO-NCELL-M < 6 the remaining RXLEV-NCELL i, BS-FREQ-NCELL i andBSIC-NCELL i fields (NO-NCELL-M < i <= 6) shall be coded with a "0" in each bit.

ETSI SMG2 Meeting #35 Document 907/0003-07 April 2000, Schaumburg, Illinois U.S.A Agenda Item: 7.1.5.9


Current Version: 8.3.008.08 CR A199GSM (AA.BB) or 3G (AA.BBB) specification number ↑ ↑ CR number as allocated by MCC support team

For submission to: SMG#31” for approval X strategic (for SMGlist expected approval meeting # here

↑for information non-strategic use only)


Proposed change affects: (U)SIM ME UTRAN / Radio X Core Network X(at least one should be marked with an X)

Source: Nokia, Ericsson, Vodafone Air Touch Date: 20.3.2000

Subject: GSM to 3G Handover: BSSAP aspects

Work item: GSM-3G Handover



Release 00

Reason forchange:

Intersystem handover from GSM to UMTS.

Clauses affected: 1.1, 3.1.5a, 3.1.19.1, 3.2.1.8, 3.2.1.9, 3.2.1.10, 3.2.1.11, 3.2.2, 3.2.2.5, 3.2.2.17,3.2.2.27, 3.2.2.58, 3.2.2.62, 3.2.3, 3.2.3.6, 5


specifications→ List of CRs:


Othercomments:

A separate CR is needed for UMTS to GSM handover in order to specify the extra fieldsin the ‘old BSS to new BSS’ container (these fields carry eg the UMTS signallingchannel’s CK and IK).

help.doc


1.1 Normative referencesThe following documents contain provisions which, through reference in this text, constitute provisionsof the present document.

- References are either specific (identified by date of publication, edition number, versionnumber, etc.) or non-specific.

- For a specific reference, subsequent revisions do not apply.

- For a non-specific reference, the latest version applies.

- A non-specific reference to an ETS shall also be taken to refer to later versions published as anEN with the same number.

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

[2] GSM 03.03: "Digital cellular telecommunications system (Phase 2+); Numbering,addressing and identification".

[3] GSM 03.09: "Digital cellular telecommunications system (Phase 2+); Handoverprocedures".

[4] GSM 03.34: "Digital cellular telecommunications system (Phase 2+); High SpeedCircuit Switched Data (HSCSD)"

[5] GSM 03.71 : "Digital cellular telecommunications system (Phase 2+); LocationServices (LCS); Functional Description – Stage 2"

[6] GSM 04.08: "Digital cellular telecommunications system (Phase 2+); Mobileradio interface layer 3 specification".

[7] GSM 04.21: "Digital cellular telecommunications system (Phase 2+); Rateadaption on the Mobile Station - Base Station System (MS - BSS) interface".

[8] GSM 05.01: "Digital cellular telecommunications system (Phase 2+); Physicallayer on the radio path; General description".

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

[10] GSM 05.03: "Digital cellular telecommunications system (Phase 2+); Channelcoding".

[11] GSM 05.04: "Digital cellular telecommunications system (Phase 2+);Modulation".

[12] GSM 05.05: "Digital cellular telecommunications system (Phase 2+); Radiotransmission and reception".

[13] GSM 05.08: "Digital cellular telecommunications system (Phase 2+); Radiosubsystem link control".

[14] GSM 05.90: "Digital cellular telecommunications system; GSM Electro MagneticCompatibility (EMC) considerations"

[15] GSM 05.10: "Digital cellular telecommunications system (Phase 2+); Radiosubsystem synchronization".

[16] GSM 08.02: "Digital cellular telecommunications system (Phase 2+); BaseStation System - Mobile-services Switching Centre (BSS - MSC) interface;Interface principles".

[17] GSM 08.06: "Digital cellular telecommunications system (Phase 2+); Signallingtransport mechanism specification for the Base Station System - Mobile-servicesSwitching Centre (BSS - MSC) interface".

[18] GSM 08.20: "Digital cellular telecommunications system (Phase 2+); Rateadaption on the Base Station System - Mobile-services Switching Centre (BSS -MSC) interface".

[19] GSM 08.71: "Digital cellular telecommunications system (Phase 2+); LocationServices (LCS); Serving Mobile Location Centre - Base Station System (SMLC-BSS) interface; Layer 3 specification".

[20] GSM 12.00: "Digital cellular telecommunications system (Phase 2); Objectivesand structure of Network Management (NM)".

[21] GSM 12.01: "Digital cellular telecommunications system (Phase 2); Commonaspects of GSM Network Management (NM)".

[22] GSM 12.02: "Digital cellular telecommunications system (Phase 2); Subscriber,Mobile Equipment (ME) and services data administration".

[23] GSM 12.03: "Digital cellular telecommunications system (Phase 2); Securitymanagement".

[24] GSM 12.04: "Digital cellular telecommunications system (Phase 2); Performancedata measurements".

[25] GSM 12.05: "Digital cellular telecommunications system (Phase 2+); Subscriberrelated event and call data".

[26] GSM 12.06: "Digital cellular telecommunications system (Phase 2); GSMNetwork change control".

[27] GSM 12.11: "Digital cellular telecommunications system (Phase 2); Maintenanceof the Base Station System (BSS)".

[28] GSM 12.20: "Digital cellular telecommunications system (Phase 2); NetworkManagement (NM) procedures and messages".

[29] GSM 12.21: "Digital cellular telecommunications system (Phase 2); NetworkManagement (NM) procedures and message on the A-bis interface".

[30] GSM 12.22: "Digital cellular telecommunications system (Phase 2); Interworkingof GSM Network Management (NM) procedures and messages at the BaseStation Controller (BSC)".

[31] UMTS 25.413: "UTRAN Iu Interface RANAP Signalling".

[32] GSM 04.18: " Digital cellular telecommunications system (Phase 2+); Mobileradio interface layer 3 specification, Radio Resource Control Protocol ".

[33] UMTS 25.331: RRC protocol specification

3.1.5a.1.2 Handover from GSM to another SystemUsing this protocol the BSS should support handover transitions to other systems from an SDCCH, aFull Rate TCH a Half Rate TCH and Multiple Full Rate TCHs.There are three procedures which are used for inter-system handover. They are:

- Inter-System Handover Required Indication;

- Inter-System Handover Resource Allocation;

- Inter-System Handover Execution.

The first and part of the third of these procedures are specified in this specification. The second andother part of the third procedures are specified in the relevant specification of the target system.For any HANDOVER REQUIRED message at most one HANDOVER COMMAND message may besent.In the case of inter-MSC handover the term "the MSC" in this subclause is taken to mean the relevantMSC in the handover operation.The inter-system handover procedures are specified in the following subclauses.All messages concerned with inter-system handover are sent using the connection oriented mode of theSCCP.3.1.5a.1 Generation of theHANDOVER REQUIRED message for intersystem handoverThe HANDOVER REQUIRED message contains the following information elements:

- Message Type;

- Cause;

- Cell Identifier List (preferred).

It should also containIn case of Inter System Handover it contains the information element: “SourceRNC to target RNC transparent information”.The “Source RNC to target RNC transparent information” is used to pass information from the old BSSto the targetnew RNC. The information in the “Source RNC to target RNC transparent information” istransparent for the MSC. When At presence of the “Source RNC to target RNC transparentinformation” is present in the HANDOVER REQUIRED message the MSC shall pass it unchanged toRNCthe Target RNC when initiating the Handover resource allocation procedure. The Target RNC isidentified by the associated Target ID information contained in the to Cell Identifier List IE(preferred)”. The Target ID information is structured routing information as required by the core network [31].Theinformation contained in the “Source RNC to target RNC transparent information” information elementis coded as required by the target system [31].Sec. 3.2.1.9. gives coding details of the above message.The "Cause" field indicates the reason for the HANDOVER REQUIRED message e.g. "intersystemhandover".”downlink quality”.The Cell Identification Discriminator field within the Cell Identifier List IE indicates the reson forin theHANDOVER REQUIRED message can be used to deduce that this is an, i.e intersystem handover.If present the "Response Request" Information Element indicates, that the BSS requires an indication ifthe HANDOVER REQUIRED message does not result in a HANDOVER COMMAND message.The Cell Identifier List IE (preferred)" shall contain the (and optionally the PLMN ID and/or LAC)RNC-ID of the target RNCcontains the RNC-ID (and additionally the LAC or LAC and PLMN-IDdepending on the configuration of the network) of the target for intersystem handover It is mandatory for the BSS to to be able to produce this the RNC-ID. It is mandatory for the MSC tobe able to receive and interpret this Information Element for routing purpose.The old BSS may recommend to the target RNC to allow pre-emption or not allow pre-emption bysending the “prec” bit. The target RNC may take this information into account when performing theHandover resource allocation procedure.The HANDOVER REQUIRED message shall be updated and repeated by the BSS with a periodicityof T7 until:

- A HANDOVER COMMAND message is received from the MSC, or;

- A RESET message is received, or;

- The reason for the original HANDOVER REQUIRED message disappears e.g. the MStransmission improves, or;

- All communication is lost with the MS as defined in GSM 04.18, and the transaction isabandoned, or;

- The transaction ends, e.g., call clearing.

3.1.5a.2 Inter-System Handover Resource Allocation Failure

If the MSC receives a HANDOVER REQUIRED message indicating an unknown target RNC then theMSC shall send a HANDOVER REQUIRED REJECT message to the old BSS with a cause valueindicating ‘invalid cell’If the MSC or the target system is unable to allocate resources for the handover attempt, the MSC shallsend a HANDOVER REQUIRED REJECT message to the old BSS with an appropriate cause value.

3.1.5.3 Handover executionHandover execution in the context of the BSS/MSC interface is the process whereby an MSC instructsan MS to tune to a new dedicated radio resource or to a group of radio resources, which may be on adifferent cell.

3.1.5a.3.4 Operation of the procedure during Iintersystem handoverExecution

The correct operation of the procedure is as follows:The BSSMAP HANDOVER COMMAND message is generated by the MSC and transmitted over theBSSAP connection to the old BSS which is currently supporting the concerned MS. At the old BSStimer T8 is started on the receipt of the BSSMAP HANDOVER COMMAND message which containsthe Layer 3 Information IE including radio interface handover command message. A radio interfaceINTER SYSTEM HANDOVER COMMAND message is then sent by the old BSS, to the concernedMS.When the MS accesses the radio resource(s) of the new RNC then:

the new RNC shall cause a Handover Detect indication to be sent to the MSC;

When the MS is successfully in communication with the network, then the new RNC shall causea Handover Complete indication to be sent to the MSC and terminate the procedure.

The relevant radio interface layer 3 procedures are described in UMTS 04.1825.331 [3233] and GSMTS 04.18.The MSC always terminates this procedure by use of a clear sequence as follows:

The MSC sends a CLEAR COMMAND to the old BSS. On receipt of a CLEAR COMMANDfrom the MSC the old BSS shall stop timer T8 and release all involved resources that wereallocated to the MS that had been handed over and returns a CLEAR COMPLETE message tothe MSC.

On receipt of the CLEAR COMPLETE, the MSC shall initiate the release of the SCCPconnection to the old BSS and thereby terminate association with the old BSS for this process.

3.1.5a.4 Inter System Handover Failure

If a HANDOVER FAILURE radio interface message is received from the MS on the old (main)channel by the old BSS, the old BSS shall then send to the MSC the BSSMAP message HANDOVERFAILURE. If the radio interface HANDOVER FAILURE message is the result of the MS returning tothe old BSS after failing to establish on the new BSS, then the cause value "radio interface failure,reversion to old channel" shall be included in the BSSMAP message HANDOVER FAILURE.Furthermore, it is recommended that the air interface RR cause be included as well in this message.If the MSC receives the BSSMAP HANDOVER FAILURE message from the old BSS (with any causevalue, the handover procedure at the target is then terminated by the MSC.The call between the MS and the old BSS and between the old BSS and the MSC shall continue as ifthere had been no handover attempt.

3.1.5a.5 Abnormal Conditions

Whilst the handover execution procedure is in operation, any other messages received at the old BSSrelating to this connection and concerning assignment, handover, or cipher mode control should bediscarded.Whilst the handover execution procedure is in operation the old BSS should not attempt to invoke anyother procedure related to this call e.g. handover required indication.

If at the old BSS a CLEAR COMMAND message from the MSC or a HANDOVER FAILUREmessage from the MS is not received before the expiry of timer T8 then the old BSS shall release thededicated radio resources. A BSSMAP message CLEAR REQUEST is also sent to the MSC with acause "Radio Interface Message Failure". The terrestrial resource in the old BSS shall remain assigneduntil a CLEAR COMMAND is received from the MSC, at which point the old BSS shall mark theterrestrial resources as IDLE and return a CLEAR COMPLETE message to the MSC. The MSC shallsubsequently release the SCCP connection to the old BSS and thereby terminate association with theold BSS for this process.In the case of a handover from a Group call channel, if at the old BSS a CLEAR COMMAND orHANDOVER SUCCEEDED message from the MSC or a HANDOVER FAILURE message from theMS is not received before the expiry of timer T8 then the old BSS shall release the uplink and send aUPLINK RELEASE INDICATION to the MSC.The MSC shall also initiate release of the resources allocated by the new BSS during the handoverresource allocation procedure by sending a CLEAR COMMAND to the new BSS. The new BSS shallrelease all the resources that were assigned for that aborted handover and return a CLEARCOMPLETE to the MSC. The MSC shall subsequently release the SCCP connection to the new BSSand thereby terminate association with the new BSS for this process.

3.1.19.1 Definitions of Types of Information ElementsThe following definitions shall be used in subclause 3.1.19 and only in this subclause.Essential Elements

These are the conditional elements when the condition for their reception is fulfilled, plus theMandatory elements excluding the Cause value information element (3.2.2.5).

Mandatory ElementsThese are the Information Elements marked as ’M’ in subclause 3.2.1.

Non-Essential ElementsNon-essential elements are all the information elements that are not defined as essential.

Conditional ElementsIn the indicated messages the following elements are conditional:

Circuit identity code in 3.2.1.1 and 3.2.1.8.

Circuit pool list in 3.2.1.3, 3.2.1.9, 3.2.1.16, and 3.2.1.55.

NOTE: A conditional IE is an IE whose presence or absence in a message can be determined byinformation contained in the rest of the message.

Transparent ElementsThe following elements are defined as transparent:

for the BSS: TMSI;RR cause;Layer 3 information in the BSSMAP HANDOVER COMMAND message;

andLayer 3 message contents; and for the MSC: Resource situation.Layer 3 information in the BSSMAP HANDOVER REQUEST

ACKNOWLEDGE message; and“Old BSS to new BSS information” in the BSSMAP HANDOVER REQUIRED message“Source RNC to target RNC information” in the BSSMAP HANDOVER REQUIREDmessage“Source RNC to target RNC information” in the BSSMAP HANDOVER REQUESTmessage

Non-Transparent ElementsNon-transparent elements are all the information elements that are not defined as transparent.

3.2.1 Message Contents3.2.1.8 HANDOVER REQUESTThis message is sent from the MSC to the BSS via the relevant SCCP connection to indicate that theMS is to be handed over to that BSS.

INFORMATION ELEMENT REFERENCE DIRECTION TYPE LEN

Message Type 3.2.2.1 MSC-BSS M 1

Channel Type 3.2.2.11 MSC-BSS M 5-10

Encryption Information 3.2.2.10 MSC-BSS M (1) 3-n

Classmark Information 1 Or 3.2.2.30 MSC-BSS M# 2 Classmark Information 2 3.2.2.19 MSC-BSS M (6) 4-5

Cell Identifier (Serving) 3.2.2.17 MSC-BSS M 5-10

Priority 3.2.2.18 MSC-BSS O 3

Circuit Identity Code 3.2.2.2 MSC-BSS O (7) 3

Downlink DTX Flag 3.2.2.26 MSC-BSS O (3) 2

Cell Identifier (Target) 3.2.2.17 MSC-BSS M (16) 3-10

Interference Band To Be Used 3.2.2.21 MSC-BSS O 2

Cause 3.2.2.5 MSC-BSS O (9) 3-4

Classmark Information 3 3.2.2.20 MSC-BSS O (4) 3-14

Current Channel type 1 3.2.2.49 MSC-BSS O (8) 2

Speech Version (Used) 3.2.2.51 MSC-BSS O (10) 2

Group Call Reference 3.2.2.55 MSC-BSS O (5) 3-8

Talker Flag 3.2.2.54 MSC-BSS O (11) 1

Configuration Evolution Indication 3.2.2.57 MSC-BSS O (12) 2

Chosen Encryption Algorithm(Serving)

3.2.2.44 MSC-BSS O (2) 2

Old BSS to New BSS Information 3.2.2.59 MSC-BSS O(13) 2-n

LSA Information 3.2.2.23 MSC-BSS O(14) 3+4n

LSA Access Control Suppression 3.2.2.61 MSC-BSS O (15) 2

Source RNC to target RNCtransparent information

3.2.2.6462 MSC-BSS O (17) n-m

1 If the MSC has not sent a CIPHER MODE COMMAND for this RR connection (or hashad all such CIPHER MODE COMMANDs rejected with CIPHER MODE REJECTmessages) then the MSC shall indicate that the only “permitted algorithm” is “noencryption”.

2 If this information element is included, it shall be equal to the last received “ChosenEncryption Algorithm” information element.

3 This element may be included in the case of a speech TCH, and only in this case. If notincluded, this has no impact on the DTX function in the BSS.

4 This element is included if the MSC has received such information.

5 This element is included if the MS is in a voice broadcast or voice group call.

6 One of these two elements is sent.

7 This element is included when the channel type Information Element indicates speech ordata, and only in those cases. In case of Voice Group Call talker handover, this elementmay contain the Circuit Identity Code already allocated during the VBS/VGCSassignment procedure, meaning that the already allocated terrestrial resource of the newcell is used.

8 This element is included at least when the message is sent as a reaction to reception of aHANDOVER REQUIRED message containing a “Current channel type 1” informationelement. In this case it shall be equal to the received element.

9 This information element should always be included. Its cause value should be the sameas indicated in the corresponding Handover Required message.

10 This element is included at least when the message is sent as a reaction to reception of aHANDOVER REQUIRED message containing a “Speech version (used)” informationelement. In this case it shall be equal to the received element.

11 This information element is included for voice group call, when this is included itindicates that the mobile is a talker in the call else the mobile is a listener.

12 The information is indicated by the MSC if known

13 This element is included if and only if the message is sent as a reaction to the receptionof a HANDOVER REQUIRED message containing an “old BSS to new BSSinformation” information element. Its contents shall be equal to the received element.

14 This information element is included when the subscriber has localised service areasupport.

15 15 This information element is included if LSA access control function shall besuppressed in the BSS.

16 If intersystem handover from GSM to UMTS is performed, this information elementindicates the target RNC-ID..

17 This information element shall be included when intersystem handover is performed..This element is included if and only if the message is sent as a reaction to the receptionof a HANDOVER REQUIRED message containing an “Source RNC to Target RNCtransparent information” IEinformation element. Its contents shall be equal to thereceived element. Note; Only provided in the HANDOVER REQUEST message on theMAP-E interface.

Typical Cause values are:uplink quality,uplink strength,downlink quality,downlink strengthdistance,better cell,response to MSC invocationO and M intervention,directed retry,switch circuit pool,traffic,preemption,

intersystem handover..

3.2.1.9 HANDOVER REQUIREDThis message is sent from the BSS to the MSC to indicate that for a given MS which already hasdedicated radio resource(s) assigned, a handover is required for the reason given by the cause element.The message is sent via the BSSAP SCCP connection associated with the dedicated resource(s).


Message Type 3.2.2.1 BSS-MSC M 1

Cause 3.2.2.5 BSS-MSC M 3-4

Response Request 3.2.2.28 BSS-MSC O 1

Cell Identifier List 3.2.2.27 BSS-MSC M (4) 2n+3 (Preferred) To

7n+3

Circuit Pool List 3.2.2.46 BSS-MSC O (1) V

Current Channel Type 1 3.2.2.49 BSS-MSC O (2) 2

Speech Version (Used) 3.2.2.51 BSS-MSC O (3) 2

Queueing Indicator 3.2.2.50 BSS-MSC O 2

Old BSS to New BSS Information 3.2.2.59 BSS-MSC O 2-n

Source RNC to target RNCtransparent information

3.2.2.6462 BSS-MSC O (5) n-m

1 Shall be included when cause "switch circuit pool" and the MSC allocates the A interfacecircuit.

2 This information element should always be included.

3 3 This information element should always be included when the channel mode isspeech, and only in this case.

4 If intersystem handover from GSM to UMTS is performed, this information elementindicates the target.Only one RNC identity is included for Intersystem Handover toUTRAN.

5 This information element shall be included when intersystem handover is performed.Source RNC to target RNC information is a general container to carry UTRAN specificinformation from BSS to RNC.

Typical Cause values are:uplink quality,uplink strength,downlink quality,downlink strength,distance,better cell,response to MSC invocation,O&M intervention,directed retry,switch circuit pool,traffic,preemption,

intersystem handover..

3.2.1.10 HANDOVER REQUEST ACKNOWLEDGEThis message is sent from the BSS to the MSC and indicates that the request to support a handover atthe target BSS can be supported by the BSS, and also to which radio channel(s) the MS should bedirected.The message is sent via the BSSAP SCCP connection associated with the dedicated resource.


Message Type 3.2.2.1 BSS-MSC M 1

Layer 3 Information 3.2.2.24 BSS-MSC M (1) 11-n

Chosen Channel 3.2.2.33 BSS-MSC O (4) 2

Chosen Encryption Algorithm 3.2.2.44 BSS-MSC O (5) 2

Circuit Pool 3.2.2.45 BSS-MSC O (2) 2

Speech Version (Chosen) 3.2.2.51 BSS-MSC O (6) 2

Circuit Identity Code 3.2.2.2 BSS-MSC O (3) 3

LSA Identifier 3.2.2.15 BSS-MSC O (7) 5

1 This information field carries a radio interface HANDOVER COMMAND message. Incase of Intersystem handover to UMTS the information field contains a HANDOVERTO UTRAN COMMAND message as defined in TS 04.18 and3G TS 25.331. In case ofInter BSC handover a RR HANDOVER COMMAND as defined in TS 04.18.

2 Shall be included when several circuit pools are present on the BSS MSC interface and acircuit was allocated by the HANDOVER REQUEST message.

3 The Circuit identity code information element is included mandatorily by the BSS if theBSS allocates the A interface circuits and a circuit is needed.

4 Included at least when the channel rate/type choice was done by the BSS.

5 Included at least when the encryption algorithm has been selected by the BSS.

6 Included at least when the speech version choice was done by the BSS.

7 Shall be included if a potential current LSA in the target cell has been identified (seeGSM 03.73). Not included means that there is no potential current LSA in the targetcell.

3.2.1.11 HANDOVER COMMANDThis message is sent from the MSC to the BSS via the relevant SCCP connection and contains thetarget channel to which the MS should retune.



Layer 3 Information 3.2.2.24 MSC-BSS M (1) 11-n

Cell Identifier 3.2.2.17 MSC-BSS O 3-10

1 1 This information field carries a radio interface HANDOVER COMMAND message. .In case of Intersystem handover to UMTS the information field contains a HANDOVERTO UTRAN COMMAND message as defined in 3G TS 04.18 and TS 25.331. In case ofInter BSC handover a RR HANDOVER COMMAND as defined in TS 04.18.

3.2.2 Signalling elementcodingThis paragraph contains the CODING of the signalling elements used.The following conventions are assumed for the sequence of transmission of bits and bytes:

- Each bit position is marked as 1 to 8. Bit 1 is the least significant bit and is transmitted first.

- In an element octets are identified by number, octet 1 is transmitted first, then octet 2 etc.

When a field extends over more than one octet, the order of bit values progressively decreases as theoctet number increases. The least significant bit of the field is represented by the lowest numbered bitof the highest numbered octet of the field.

- For variable length elements a length indicator is included, this indicates the number of octetsfollowing in the element.

- All fields within Information Elements are mandatory unless otherwise specified. TheInformation Element Identifier shall always be included.

All spare bits are set to 0.The elements used and their CODING are:

ElementIdentifierCoding

Element name Reference

0000 0001 Circuit Identity Code 3.2.2.20000 0010 Reserved *0000 0011 Resource Available 3.2.2.40000 0100 Cause 3.2.2.50000 0101 Cell Identifier 3.2.2.170000 0110 Priority 3.2.2.180000 0111 Layer 3 Header Information 3.2.2.90000 1000 IMSI 3.2.2.60000 1001 TMSI 3.2.2.70000 1010 Encryption Information 3.2.2.100000 1011 Channel Type 3.2.2.110000 1100 Periodicity 3.2.2.120000 1101 Extended Resource Indicator 3.2.2.130000 1110 Number Of MSs 3.2.2.80000 1111 Reserved *0001 0000 Reserved *0001 0001 Reserved *0001 0010 Classmark Information Type 2 3.2.2.190001 0011 Classmark Information Type 3 3.2.2.200001 0100 Interference Band To Be Used 3.2.2.210001 0101 RR Cause 3.2.2.220001 0110 Reserved *0001 0111 Layer 3 Information 3.2.2.240001 1000 DLCI 3.2.2.250001 1001 Downlink DTX Flag 3.2.2.260001 1010 Cell Identifier List 3.2.2.270001 1011 Response Request 3.2.2.280001 1100 Resource Indication Method 3.2.2.290001 1101 Classmark Information Type 1 3.2.2.300001 1110 Circuit Identity Code List 3.2.2.31

(continued)

The elements used and their CODING are (concluded):



0001 1111 Diagnostic 3.2.2.320010 0000 Layer 3 Message Contents 3.2.2.350010 0001 Chosen Channel 3.2.2.330010 0010 Total Resource Accessible 3.2.2.140010 0011 Cipher Response Mode 3.2.2.340010 0100 Channel Needed 3.2.2.360010 0101 Trace Type 3.2.2.370010 0110 Triggerid 3.2.2.380010 0111 Trace Reference 3.2.2.390010 1000 Transactionid 3.2.2.400010 1001 Mobile Identity 3.2.2.410010 1010 OMCId 3.2.2.420010 1011 Forward Indicator 3.2.2.430010 1100 Chosen Encryption Algorithm 3.2.2.440010 1101 Circuit Pool 3.2.2.450010 1110 Circuit Pool List 3.2.2.460010 1111 Time Indication 3.2.2.470011 0000 Resource Situation 3.2.2.480011 0001 Current Channel type 1 3.2.2.490011 0010 Queueing Indicator 3.2.2.500100 0000 Speech Version 3.2.2.510011 0011 Assignment Requirement 3.2.2.520011 0101 Talker Flag 3.2.2.540011 0110 Connection Release Requested 3.2.2.30011 0111 Group Call Reference 3.2.2.550011 1000 EMLPP Priority 3.2.2.560011 1001 Configuration Evolution Indication 3.2.2.570011 1010 Old BSS to New BSS Information 3.2.2.580011 1011 LSA Identifier 3.2.2.150011 1100 LSA Identifier List 3.2.2.160011 1101 LSA Information 3.2.2.230011 1110 Location information 3.2.2.600011 1111 LSA access control suppression 3.2.2.610100 0001 (Note.) Source RNC to target RNC transparent

containerinformation3.2.2.62

Note. This encoding aligns with the RANAP specified tagging.The coding is defined in relevantRANAP specification TS 25.413.

* Information Element codes marked as "reserved" are reserved for use by previousversions of this interface specification

3.2.2.5 CauseThe cause element is used to indicate the reason for a particular event to have occurred and is coded asshown below.The cause value is a single octet element if the extension bit (bit 8) is set to 0. If it is set to 1 then thecause value is a 2 octet field. If the value of the first octet of the cause field is 1XXX 0000 then thesecond octet is reserved for national applications, (XXX will still indicate the class).

8 7 6 5 4 3 2 1

Element identifier octet 1Length octet 2

0/1 ext Cause Value octet 3(octet 4)

The length indicator is a binary representation of the length of the following element.

Cause Value:Class (000) : Normal eventClass (001) : Normal eventClass (010) : Resource unavailableClass (011) : Service or option not availableClass (100) : Service or option not implementedClass (101) : invalid message (eg parameter out of range)Class (110) : protocol errorClass (111) : interworking

In the following table, "reserved for international use" means that this codepoint should not be useduntil a meaning has been assigned to it following the process of international standardisation."Reserved for national use" indicates codepoints that may be used by operators without the need forinternational standardisation.

��

��

�� !��

"�#��

��

�� $%&�%'(� )�*��+��)�%��

��

�� $%&�%'(� )�*��)�%��

��

�� ,�%'-�.��%(/

��

�� ,�%'-��( �'+(0

��

�� 1&2'�%'-�.��%(/

��

�� 1&2'�%'-��( �'+(0

��

�� 1%�(�'*�

��

�� '$��%'(� ��'(%&'

��

�� ,&'��(&��%'�&*�(%&'

��

�� *&'( &�

��

�� $%&�%'(� )�*��)�%�� 3� �� %&'�(&

�� &�$�*0�''��

�� 4�'$&�� **��)��

��

�� 5�((� ��

��

�� 1% �*(�$��( /

��

�� 6&%'�$�+ &�,�*��*0�''��

��

�� ))%*

��

�� 7

��(&�� 7�� $�)& �%'(� '�(%&'��

�� 7

��

�� 7

��(&�� 7�� $�)& �'�(%&'��

�� 7

��

�� .�%,��'(�)�%��

��

�� &� �$%&� ��&� *��%��

��

�� .��(�$�(� ��( %�� &� *�

�� '��%��

�� 4�&�� &�$

��

�� &*��& �&�� &�$

��

�� 5��'&(��.�%,,�$

��

��

��

�� !��

�� '&(��.�%,,�$

��

�� '��%$�*��

��

�� ))%*��&�$

��

�� ,(%&'

��

�� 7

��(&�� 7�� $�)& �'�(%&'��

�� 7

�� .��(�$�( �'�*&$%'+8 �(��$�,(%&'

�� '��%��

��

�� % *�%(�,&&��%��(*0

��

�� 2%(*0�*% *�%(�,&&�

��

�� .��(�$��,��*0�� %&'��'��%��

��

�� '&(��&2�$

��

�� 7

��(&�� 7�� $�)& �%'(� '�(%&'��

�� 7

��

�� %,0� %'+��+& %(0��'&(��,,& (�$

��

�� 7

��(&�� 7�� $�)& �%'(� '�(%&'��

�� 7

�� 7

��(&�� 7�� $�)& �'�(%&'��

�� 7

�� ( %��*% *�%(�� $/��&*�(�$

��

�� '��%$��+��*&'(�'(�

��

�� ')& ��(%&'��'(�& �)%��$��%��%'+

��

�� '*& �*(��

��

�� '-'&2'��+��(/,�

��

�� '-'&2'� ')& ��(%&'��'(

��

�� 7

��(&�� 7�� $�)& �%'(� '�(%&'��

�� 7

��

�� 7

��(&�� 7�� $�)& �'�(%&'��

�� 7

��

��

�� !��

�� &(&*&�� & ��(2��'�5��'$��

��

�� !9��8!5��*��'&'��:%�(�'(

��

�� 7

��(&�� 7�� $�)& �%'(� '�(%&'��

�� 7

��

�� 7

��(&�� 7�� $�)& �'�(%&'��

�� 7

��

�� '(� �/�(��0�'$&��

��

�� 7

��(&�� 7�� $�)& �%'(� '�(%&'��

�� 7

��

�� 7

��(&�� 7�� $�)& �'�(%&'��

�� 7

3.2.2.17 Cell IdentifierThis element uniquely identifies a cell within a BSS and is of variable length containing the followingfields:

��;��"��#��

��'(�%$�'(%)%� �� &*(�(��

��'+(0�� &*(�(��

��,� �� %$�'(%)%*�(%&'�� &*(�(��

�� $%�* %�%'�(& ��

��%$�'(%)%*�(%&'�� &*(�(��<n

The coding of octet 2 is a binary number indicating the length of the remaining element. The lengthdepends on the Cell identification discriminator (octet 3).The coding of "Cell identification discriminator" (bits 1 to 4 of octet 3) is a binary number indicating ifthe whole or a part of Cell Global Identification, CGI, according to GSM 03.03 is used for cellidentification in octet 4-n. The "Cell identification discriminator" is coded as follows:

0000 The whole Cell Global Identification, CGI, is used to identify the cell.0001 Location Area Code, LAC, and Cell Identity, CI, is used to identify the cell.0010 Cell Identity, CI, is used to identify the cell.0011 No cell is associated with the transaction.0100 Identification is indicated (handover from GSM to UMTS)1000 Intersystem Handover to UTRAN.PLMN-ID(MCC,MNC), , LAC(Location Area

Code) and RNC-ID, is used to identify the target RNC.

All other values are reserved.The coding of octet 4-n depends on the Cell identification discriminator (octet 3). Below the coding isshown for each Cell identification discriminator:Note that no coding is specified for a Cell identification discriminator value of "0011" as no additionalinformation is required.Coding of Cell Identification forCell identification discriminator = 0000For GSM 900 and DCS 1800:

��;��"��#��

��$%+�� $%+�� &*(�(��

�� $%+�� &*(�(��

��$%+�� $%+�� &*(�(�#

�� &*(�(�"

��*&'(=�� &*(�(�;

�� &*(�(�>

�� *&'(�� &*(�(��

The octets 4-8 are coded as shown in GSM 04.08, Table ‘Location Area Identification informationelement’ .The octets 9-10 are coded as shown in GSM 04.08, Table ‘Cell Identity information element’.For PCS 1900 for NA:

��;��"��#��

��$%+�� $%+�� &*(�(��

��$%+�� $%+�� &*(�(��

��$%+�� $%+�� &*(�(�#

�� &*(�(�"

��*&'(=�� &*(�(�;

�� &*(�(�>

�� *&'(�� &*(�(��

The octets 4-8 are coded as shown in GSM 04.08, Table ‘Location Area Identification informationelement’.The octets 9-10 are coded as shown in GSM 04.08, Table ‘Cell Identity information element’.Coding of Cell Identification forCell identification discriminator = 0001

��;��"��#��

�� &*(�(��

��*&'(=�� &*(�(��

�� &*(�(�#

�� *&'(�� &*(�(�"

Coding of Cell Identification forCell identification discriminator = 0010

��;��"��#��

�� &*(�(��

�� *&'(�� &*(�(��

The octets 4-5 are coded as shown in GSM 04.08, Table ‘Cell Identity information element’Coding of the Target ID forCell identification discriminator = 01001000For intersystem handover from GSM to UMTS:

��;��"��#� 5 4 3 2 1

��$%+�� $%+�� &*(�(��

��$%+�� $%+�� &*(�(��

��$%+�� $%+�� &*(�(�#

�� &*(�(�"

��*&'(=�� &*(�(�;

� CI-value �octet 9

�� *&'(�� &*(�(��

��< 1�� octet 1199

��< 1�*&'(=�� &*(�(�12 10

The octets 4 - 8 are coded as shown in GSM 04.08, Table ‘Location Area Identification informationelement’.The octets 9-10 are coded as shown in GSM 04.08, Table ‘Cell Identity information element’.The octet 5 bits 5-8 are filled by '1111' if 2 digit MNC is used.The octets 11 -– 12 9 - 10 are coded as the RNC-ID, specified in UMTS 25.413 in section 9.2.1.25 inthe Table "Target ID". The least significant bit is octet 107 bit 1 and most significant bit is octet 98 bit8. If the RNC-ID does not fill the field reserved for it, the rest of the bits are filled by '0'.

3.2.2.24 Layer 3 InformationThis is a variable length element used to pass radio interface messages from one network entity toanother.

��;��"��#��

��'(�%$�'(%)%� �� &*(�(��

��'+(0�� &*(�(��

��/� ��%')& ��(%&'�� &*(�(��<n

Octet 1 identifies the element. Octet 2 gives the length of the following layer 3 information.Octet j (j = 3, 4, ..., n) is the unchanged octet j-2 of a radio interface layer 3 message as defined in GSM04.018 or in UMTS 25.331, n-2 is equal to the length of that radio interface layer 3 message.

3.2.2.27 Cell Identifier ListThis element uniquely identifies cells and is of variable length containing the following fields:

��;��"��#��

��'(�%$�'(%)%� �� &*(�(��

��'+(0�� &*(�(��

��,� �� %$�'(%)%*�(%&'�� &*(�(��

�� $%�* %�%'�(& ��

��%$�'(%)%*�(%&'�� &*(�(��<4+m

: ::

��%$�'(%)%*�(%&'�'�� ==�(&��?'�

The coding of octet 2 is a binary number indicating the Length of the remaining element. The Lengthdepends on the Cell identification discriminator (bits 1 to 4 of octet 3) as well as the number of cells tobe identified.The coding of the Cell identification discriminator is a binary number indicating if the whole or a partof Cell Global identification, CGI, according to GSM 03.03 is used for cell identification of the cells inthe list. The Cell identification discriminator is coded as follows:

0000 The whole Cell Global Identification, CGI, is used to identify the cells.0001 Location Area Code, LAC, and Cell Identify, CI, is used to identify the cells.0010 Cell Identity, CI, is used to identify the cells.0011 No cell is associated with the transaction.

0100 Location Area Identification, LAI, is used to identify all cells within a LocationArea.

0101 Location Area Code, LAC, is used to identify all cells within a location area.0110 All cells on the BSS are identified.1000 Intersystem Handover to UTRAN. PLMN-ID, LAC, and RNC-ID, are encoded to

identify the target RNC.01111001 Intersystem Handover to UTRAN. The RNC-ID is coded to identify the target

RNC.Target RNC Identification is indicated (handover from GSM to UMTS)1010 Intersystem Handover to UTRAN. LAC and RNC-ID are encoded to

identify the target RNC.

All other values are reserved.Values 0100, 0101 and 0110 are only applicable for page message.The coding of the Cell Identifications 1 to n (octets 4 to 4+nm) depends on the Cell identificationdiscriminator (octet 3). Below the coding of the i-th Cell Identification is shown for each Cellidentification discriminator (with "i" in the range 1 to n):Note that no coding is specified for Cell identification discriminator values of "0011" and "0110" as noadditional information is required.Coding of the i-th Cell Identification forCell identification discriminator = 0000For GSM 900 and DCS 1800:

��;��"��#��

��$%+�� $%+�� &*(�(�:?�

�� $%+�� &*(�(�:?�

��$%+�� $%+�� &*(�(�:?�

�� &*(�(�:?�

��*&'(=�� &*(�(�:?�

�� &*(�(�:?#

�� *&'(�� &*(�(�:?"

Where x = 3 + 7(i-1).The octets (x+1)-(x+5) are coded as shown in GSM 04.08, Table ‘Location Area Identificationinformation element’.The octets (x+6)-(x+7) are coded as shown in GSM 04.08, Table ‘Cell Identity information element’.For PCS 1900 for NA:

��;��"��#��

��$%+�� $%+�� &*(�(�:?�

��$%+�� $%+�� &*(�(�:?�

��$%+�� $%+�� &*(�(�:?�

�� &*(�(�:?�

��*&'(=�� &*(�(�:?�

�� &*(�(�:?#

�� *&'(�� &*(�(�:?"

Where x = 3 + 7(i-1).The octets (x+1)-(x+5) are coded as shown in GSM 04.08, Table ‘Location Area Identificationinformation element’.The octets (x+6)-(x+7) are coded as shown in GSM 04.08, Table ‘Cell Identity information element’ .Coding of i-th Cell Identification forCell identification discriminator = 0001

��;��"��#��

�� &*(�(�:?�

��*&'(=�� &*(�(�:?�

�� &*(�(�:?�

�� *&'(�� &*(�(�:?�

Where x = 3 + 4(i-1)The octets (x+1)-(x+2) are coded as shown in GSM 04.08, Table ‘Location Area Identificationinformation element’.The octets (x+3)-(x+4) are coded as shown in GSM 04.08, Table ‘Cell Identity information element’.Coding of i-th Cell Identification forCell identification discriminator = 0010

��;��"��#��

�� &*(�(�:?�

�� *&'(�� &*(�(�:?�

Where x = 3 + 2(i-1)The octets (x+1)-(x+2) are coded as shown in GSM 04.08, Table ‘Cell Identity information element’ .Coding of i-th Cell Identification forCell identification discriminator = 0100For GSM 900 and DCS 1800:

��;��"��#��

��$%+�� $%+�� &*(�(�:?�

�� $%+�� &*(�(�:?�

��$%+�� $%+�� &*(�(�:?�

�� &*(�(�:?�

��*&'(=�� &*(�(�:?�

Where x = 3 + 5(i-1)The octets (x+1)-(x+5) are coded as shown in GSM 04.08, Table ‘Location Area Identificationinformation element’.For PCS 1900 for NA:

��;��"��#��

��$%+�� $%+�� &*(�(�:?�

��$%+�� $%+�� &*(�(�:?�

��$%+�� $%+�� &*(�(�:?�

�� &*(�(�:?�

��*&'(=�� &*(�(�:?�

Where x = 3 + 5(i-1)The octets (x+1)-(x+5) are coded as shown in GSM 04.08, Table ‘Location Area Identificationinformation element’.Coding of i-th Cell Identification forCell identification discriminator = 0101

��;��"��#��

�� &*(�(�:?�

��*&'(=�� &*(�(�:?�

Where x = 3 + 2(i-1)The octets (x+1)-(x+2) are coded as shown in GSM 04.08, Table ‘Location Area Identificationinformation element’ .The appropriate coding for not identified cells is "0" for all bits of LAC and CI for all possible CellIdentification Discriminator values.Coding of the Target ID forCell identification discriminator = 01111000For intersystem handover from GSM to UMTS:

��;��"��#��

��$%+�� $%+�� &*(�(��

��$%+�� $%+�� &*(�(��

��$%+�� $%+�� &*(�(�#

�� &*(�(�"

��*&'(=�� &*(�(�;

� CI value �octet 9

�� CI value cont �octet 10

��< 1�� &*(�(�11 9

��< 1�*&'(=�� &*(�(�12 10

The octets 4 - 8 are coded as shown in GSM 04.08, Table ‘Location Area Identification informationelement’.The octets 9-10 are coded as shown in GSM 04.08, Table ‘Cell Identity information element’.The octet 5 bits 5-8 are filled by '1111' if 2 digit MNC is used.The octets 11 -– 129-10 are coded as the RNC-ID, specified in UMTS 25.413 in section 9.2.1.25 in theTable "Target ID". The least significant bit is octet 107 bit 1 and most significant bit is octet 98 bit 8. Ifthe RNC-ID does not fill the field reserved for it, the rest of the bits are filled by '0'.

Coding of the Target ID forCell identification discriminator = 1001For intersystem handover from GSM to UMTS:

��;��"��#��

RNC-ID �&*(�(�4

��RNC-ID . �&*(�(�5

The octets –4 - 5 are coded as the RNC-ID, specified in UMTS 25.413 in section 9.2.1.25 in the Table"Target ID". The least significant bit is octet 57 bit 1 and most significant bit is octet 84 bit 8. If theRNC-ID does not fill the field reserved for it, the rest of the bits are filled by '0'.

Coding of the Target ID forCell identification discriminator = 1010For intersystem handover from GSM to UMTS:

��;��"��#��

�� &*(�(�4

��*&'(=�� &*(�(�5

��< 1�� &*(�(�6

��< 1�*&'(=�� &*(�(�7

The octets 4 – 5 are coded as shown in GSM 04.08, Table ‘Location Area Identification informationelement’.The octets –6-7 are coded as the RNC-ID, specified in UMTS 25.413 in section 9.2.1.25 in the Table"Target ID". The least significant bit is octet 7 bit 1 and most significant bit is octet 68 bit 8. If theRNC-ID does not fill the field reserved for it, the rest of the bits are filled by '0'.3.2.2.58 Old BSS to New BSS informationThis information element is defined as a general container for passing Field Elements transparentlybetween BSSs via the MSC.These Field Elements are passed in the “Old BSS to New BSS information elements” octets field. Theerror handling performed by the receiving entity for the “Old BSS to New BSS information elements”field is that specified in section 3.1.19.7.

+------------------------------------------------------------+¦ 8 7 6 5 4 3 2 1 ¦ ¦+-----------------------------------------------+------------¦¦ Element identifier ¦ octet 1 ¦+-----------------------------------------------+------------¦¦ Length ¦ octet 2 ¦+-----------------------------------------------+------------¦¦ Old BSS to New BSS information elements ¦ octet 3-n ¦+------------------------------------------------------------+

The length indicator (octet 2) is a binary number indicating the absolute length of the contents after thelength indicator octet and may be set to zero.

The Old BSS to New BSS information elements field is made up of 0 or more Field Elements listed inthe table shown below.Field elements may occur in any order in the Old BSS to New BSS information elements field.The construction of the Field Elements allows the receiver to ignore unknown Field Elements.Due to backward compatibility issues Field Elements in the “Old BSS to New BSS information” mayduplicate Information Elements in the HANDOVER REQUEST, when this occurs and the new BSSdetects an inconsistency between this information then the information contained in the “Old BSS toNew BSS information” shall take precedence as long as the coding is understood by the new BSS.Reception of an erroneous “Old BSS to New BSS information” shall not cause a rejection of theHANDOVER REQUEST message; the “Old BSS to New BSS information” information element shallbe discarded and the handover resource allocation procedure shall continue.

FIELD ELEMENT REFERENCE LENExtra information 3.2.3.1 3Current Channel Type 2 3.2.3.2 4Target cell radio information 3.2.3.3 3GPRS Suspend information 3.2.3.4 19MultiRate configuration information 3.2.3.5 3-8UE Capability Information 3.2.3.6 n

3.2.2.62 Source RNC to target RNC transparent containerThis information element is defined as a general container for passing (e.g. UE Capability Information,Target Cell ID) RNC specific information transparently through the core network from BSS to RNC.

+------------------------------------------------------------+¦ 8 7 6 5 4 3 2 1 ¦ ¦+-----------------------------------------------+------------¦¦ Element identifier ¦ octet 1 ¦+-----------------------------------------------+------------¦¦ Length ¦ octet 2 ¦+-----------------------------------------------+------------¦¦ Source RNC to target RNC information container¦ octet 3-n ¦+------------------------------------------------------------+

The Source RNC to Target RNC Information container structure and encoding is defined in relevantRANAP specification TS 25.413.Editor’s note : still need to define if any RANAP ‘tag’ is included or excluded.

3.2.3 SIGNALING FIELDELEMENT CODINGThe coding rules for signalling field elements are the same as the signalling element coding rules whichare defined in section 3.2.2.Signalling field elements shall always include a Field Length indicator. A Field Length indicator witha value of zero shall not be considered as an error.

FieldElementIdentifierCoding

Field Element name Reference

0000 0001 Extra information 3.2.3.10000 0010 Current Channel Type 2 3.2.2.20000 0011 Target cell radio information 3.2.3.30000 0100 GPRS Suspend information 3.2.3.40000 0101 MultiRate configuration information 3.2.3.50000 0110 UE Capability information 3.2.3.6

All other values are for future use.

3.2.3.6 UE Capability InformationThe UE Capability Information element is structured and encoded according to TS 25.331coded as follows:

��

��Field Element identifier �RFWHW��

��/HQJWK�� RFWHW��

��UE capability information �RFWHW��-n

Octets 3-n are encoded as octets 3-n of the UE capability information element defined in TS GSM04.18.

5 VocabularyThis clause contains definition of terms:BSSBase Station System. This is the equipment which is accessed through the interface defined in the08-series of Technical Specifications. It contains the functionality described in GSM 08.02, andsupports one or more cells. See GSM 01.04.BSSAPThe Base Station System Application Part, this is the subsystem that contains the process dealing withradio resource control and management known as the Base Station System Management ApplicationPart (BSSMAP) and transparent transfer of call control and mobility management information knownas the Direct Transfer Application Part (DTAP). The BSSAPs at the BSS and the MSC are connectedby means of SCCP connections.DTAPThe DTAP, Direct Transfer Application Part is a process which allows the direct transfer of messagesbetween individual MSs and the MSC with no interpretation of layer 3 information at the BSS.BSSMAPBase Station System Management Application Part. This is the process within the BSS that controlsradio resources in response to instructions from the MSC.INTERNAL HANDOVERAn internal handover is a handover which takes place between channels on a cell or cells controlled bya single BSS. This handover operates without reference to the MSC (although the MSC will beinformed on completion). Handovers of this type in one cell are called internal intra cell handovers andbetween cells are called internal inter cell handovers.Handovers between channels on the same cell or between cells on the same BSS which are controlledby the MSC are external handovers and use identical procedures to those for inter-BSS handovers.INTERSYSTEM HANDOVERAn intersystem handover is a handover which takes place between different radio access systems (e.g.GSM BSS and UTRAN). This handover is MSC controlled.DIRECTED RETRYDirected Retry is the process of assigning a Mobile Station to a TCH in a cell other than the servingcell, e.g. in situations of congestion. It is triggered by the assignment procedure and employs internal orexternal handover procedures.VGCS/VBSVGCS/VBS call controlling SCCP connection: The VGCS/VBS call controlling SCCP connection isan SCCP connection which supports the signalling for call SETUP of a VGCS/VBS call. One of theseconnections is needed to support each instance of a VGCS/VBS call within a BSS.VGCS/VBS resource controlling SCCP connection: The VGCS/VBS resource controlling SCCPconnection is an SCCP connection which supports the allocation of resources for a VGCS/VBS call.One or more of these connections is needed to support each instance of a VGCS/VBS call. The eactnumber of these SCCP connections is equal to the number of cells to which the VGCS/VBS call is tobe supported.

ETSI STC SMG2 Meeting Document 2-00-8523-7 April 2000, Chicago, Illinois Agenda Item:7.1.5.9


Current Version: 8.3.008.08 CR A205r1GSM (AA.BB) or 3G (AA.BBB) specification number ↑ ↑ CR number as allocated by MCC support team


↑for information non-strategic Use only)


Proposed change affects: (U)SIM ME UTRAN / Radio X Core Network X(at least one should be marked with an X)

Source: Vodafone AirTouch and Nokia. Date: 4/3/2000

Subject: GSM-3G Handover: ‘Service based handover’

Work item: GSM-3G Handover



Release 00

Reason forchange:

Intersystem handover from GSM to UMTS may be needed for a variety of reasons. Inparticular, the bandwidth desired for the service may require a UMTS channel, if one isavailable. However, the actual service is only known by the MSC. The MSC usesabstract parameters in the ‘Channel Type’ information element to convey the GSMchannel requirements. As the Channel Type only describes channels that are plausiblefor GSM to support, how can the “request to handover to UMTS in order to provide,say, 384 kbps video” be communicated to the BSC?

This CR proposes the addition of a new information element in the Assignment Request andHandover Request messagesa few bits to the Channel Type IE in order to communicate thedesire (or otherwise) for intersystem handover. These bits indicate the MSC’s desire for ahandover to another system. UTRAN-FDD; UTRAN-TDD and CDMA-2000 are all groupedunder the same codepoint because (a) they all provide roughly the same non-GSM services and(b) for any particular GSM BSC, it is unlikely that the both mobile and BSC can providehandover to more than one type of 3G system.The CR also allows the BSC to be requested, or commanded, to keep a dual mode handset inGSM coverage (eg to keep voice calls in GSM and thus keep UMTS bandwidth free for highbandwidth data services).Note that additional octets can be added to Channel Type in the future to accomodate furtherRadio Access Technologies.

Clauses affected: 3.2.2.11

Other specs Other 3G core specifications → List of CRs:affected: Other GSM core → List of CRs:

specificationsMS test specifications → List of CRs:BSS test specifications → List of CRs:O&M specifications → List of CRs:

Othercomments:


3.2.1 Message Contents3.2.1.1 ASSIGNMENT REQUESTThis message is sent from the MSC to the BSS via the relevant SCCP connection in order to request theBSS to assign radio resource(s), the attributes of which are defined within the message.The message may also include the terrestrial circuit to be used.




Layer 3 Header Information 3.2.2.9 MSC-BSS O (3) 4










Service Handover 3.2.2.75 MSC-BSS O 3

1 This element is included when the MSC allocates the A interface circuits and the channeltype Information Element indicates speech or data, and only in those cases.


3 This information element doesn’t serve any useful purpose. MSCs should not send theinformation element unless it is required by the recipients (due to the need to interworkwith older versions of the protocol). It is expected that in future versions of 08.08, thisinformation element will be deleted from this message.

4 These elements may be included if the information is known by the MSC.

5 This may be included by the MSC for either a talking or listening subscriber in a groupcall.

6 This information element is included for group calls, when this is included it indicatesthat the mobile is a talker in the call else the mobile is a listener.

7 The information is indicated by the MSC if known.

8 This information element is included if LSA access control function shall be suppressedin the BSS.

*** Next Change ***

3.2.1.8 HANDOVER REQUESTThis message is sent from the MSC to the BSS via the relevant SCCP connection to indicate that theMS is to be handed over to that BSS.




Encryption Information 3.2.2.10 MSC-BSS M (1) 3-n

Classmark Information 1 Or 3.2.2.30 MSC-BSS M# 2 Classmark Information 2 3.2.2.19 MSC-BSS M (6) 4-5

Cell Identifier (Serving) 3.2.2.17 MSC-BSS M 5-10




Cell Identifier (Target) 3.2.2.17 MSC-BSS M 3-10


Cause 3.2.2.5 MSC-BSS O (9) 3-4


Current Channel type 1 3.2.2.49 MSC-BSS O (8) 2

Speech Version (Used) 3.2.2.51 MSC-BSS O (10) 2




Chosen Encryption Algorithm(Serving)

3.2.2.44 MSC-BSS O (2) 2

Old BSS to New BSS Information 3.2.2.59 MSC-BSS O(13) 2-n

LSA Information 3.2.2.23 MSC-BSS O(14) 3+4n


Service Handover 3.2.2.75 MSC-BSS O 3

1 If the MSC has not sent a CIPHER MODE COMMAND for this RR connection (or hashad all such CIPHER MODE COMMANDs rejected with CIPHER MODE REJECTmessages) then the MSC shall indicate that the only “permitted algorithm” is “noencryption”.

2 If this information element is included, it shall be equal to the last received “ChosenEncryption Algorithm” information element.


4 This element is included if the MSC has received such information.

5 This element is included if the MS is in a voice broadcast or voice group call.

6 One of these two elements is sent.

7 This element is included when the channel type Information Element indicates speech ordata, and only in those cases. In case of Voice Group Call talker handover, this elementmay contain the Circuit Identity Code already allocated during the VBS/VGCSassignment procedure, meaning that the already allocated terrestrial resource of the newcell is used.

8 This element is included at least when the message is sent as a reaction to reception of aHANDOVER REQUIRED message containing a “Current channel type 1” informationelement. In this case it shall be equal to the received element.

9 This information element should always be included. Its cause value should be the sameas indicated in the corresponding Handover Required message.

10 This element is included at least when the message is sent as a reaction to reception of aHANDOVER REQUIRED message containing a “Speech version (used)” informationelement. In this case it shall be equal to the received element.

11 This information element is included for voice group call, when this is included itindicates that the mobile is a talker in the call else the mobile is a listener.

12 The information is indicated by the MSC if known

13 This element is included if and only if the message is sent as a reaction to the receptionof a HANDOVER REQUIRED message containing an “old BSS to new BSSinformation” information element. Its contents shall be equal to the received element.

14 This information element is included when the subscriber has localised service areasupport.

15 This information element is included if LSA access control function shall be suppressedin the BSS.

Typical Cause values are:uplink quality,

uplink strength,

downlink quality,

downlink strength

distance,

better cell,

response to MSCinvocation

Oand M intervention,

directed retry,

switch circuit pool,

traffic,

preemption.

*** Next Change ***

3.2.2 Signalling elementcodingThis paragraph contains the CODING of the signalling elements used.The following conventions are assumed for the sequence of transmission of bits and bytes:

- Each bit position is marked as 1 to 8. Bit 1 is the least significant bit and is transmitted first.

- In an element octets are identified by number, octet 1 is transmitted first, then octet 2 etc.

When a field extends over more than one octet, the order of bit values progressively decreases as theoctet number increases. The least significant bit of the field is represented by the lowest numbered bitof the highest numbered octet of the field.

- For variable length elements a length indicator is included, this indicates the number of octetsfollowing in the element.

- All fields within Information Elements are mandatory unless otherwise specified. TheInformation Element Identifier shall always be included.

All spare bits are set to 0.The elements used and their CODING are:



0000 0001 Circuit Identity Code 3.2.2.20000 0010 Reserved *0000 0011 Resource Available 3.2.2.40000 0100 Cause 3.2.2.50000 0101 Cell Identifier 3.2.2.170000 0110 Priority 3.2.2.180000 0111 Layer 3 Header Information 3.2.2.90000 1000 IMSI 3.2.2.60000 1001 TMSI 3.2.2.70000 1010 Encryption Information 3.2.2.100000 1011 Channel Type 3.2.2.110000 1100 Periodicity 3.2.2.120000 1101 Extended Resource Indicator 3.2.2.130000 1110 Number Of MSs 3.2.2.80000 1111 Reserved *0001 0000 Reserved *0001 0001 Reserved *0001 0010 Classmark Information Type 2 3.2.2.190001 0011 Classmark Information Type 3 3.2.2.200001 0100 Interference Band To Be Used 3.2.2.210001 0101 RR Cause 3.2.2.220001 0110 Reserved *0001 0111 Layer 3 Information 3.2.2.240001 1000 DLCI 3.2.2.250001 1001 Downlink DTX Flag 3.2.2.260001 1010 Cell Identifier List 3.2.2.270001 1011 Response Request 3.2.2.280001 1100 Resource Indication Method 3.2.2.290001 1101 Classmark Information Type 1 3.2.2.300001 1110 Circuit Identity Code List 3.2.2.31

(continued)

The elements used and their CODING are (concluded):



0001 1111 Diagnostic 3.2.2.320010 0000 Layer 3 Message Contents 3.2.2.350010 0001 Chosen Channel 3.2.2.330010 0010 Total Resource Accessible 3.2.2.140010 0011 Cipher Response Mode 3.2.2.340010 0100 Channel Needed 3.2.2.360010 0101 Trace Type 3.2.2.370010 0110 Triggerid 3.2.2.380010 0111 Trace Reference 3.2.2.390010 1000 Transactionid 3.2.2.400010 1001 Mobile Identity 3.2.2.410010 1010 OMCId 3.2.2.420010 1011 Forward Indicator 3.2.2.430010 1100 Chosen Encryption Algorithm 3.2.2.440010 1101 Circuit Pool 3.2.2.450010 1110 Circuit Pool List 3.2.2.460010 1111 Time Indication 3.2.2.470011 0000 Resource Situation 3.2.2.480011 0001 Current Channel type 1 3.2.2.490011 0010 Queueing Indicator 3.2.2.500100 0000 Speech Version 3.2.2.510011 0011 Assignment Requirement 3.2.2.520011 0101 Talker Flag 3.2.2.540011 0110 Connection Release Requested 3.2.2.30011 0111 Group Call Reference 3.2.2.550011 1000 eMLPP Priority 3.2.2.560011 1001 Configuration Evolution Indication 3.2.2.570011 1010 Old BSS to New BSS Information 3.2.2.580011 1011 LSA Identifier 3.2.2.150011 1100 LSA Identifier List 3.2.2.160011 1101 LSA Information 3.2.2.230011 1110 LCS QoS 3.2.2.600011 1111 LSA access control suppression 3.2.2.610100 0011 LCS Priority 3.2.2.620100 0100 Location Type 3.2.2.630100 0101 Location Estimate 3.2.2.640100 0110 Positioning Data 3.2.2.650100 0111 LCS Cause 3.2.2.660100 1000 LCS Client Type 3.2.2.670100 1001 APDU 3.2.2.680100 1010 Network Element Identity 3.2.2.690100 1011 GPS Assistance Data 3.2.2.700100 1100 Deciphering Keys 3.2.2.710100 1101 Return Error Request 3.2.2.720100 1110 Return Error Cause 3.2.2.730100 1111 Segmentation 3.2.2.740101 0000 Service Handover 3.2.2.75

* Information Element codes marked as "reserved" are reserved for use by previousversions of this interface specification

*** Next Change ***

3.2.2.75 Service HandoverThe Service Handover defines information to use for handover to UTRAN.It is coded as follows:

��;��"��#��

��'(�%$�'(%)%� �� &*(�(��

��'+(0�� &*(�(��

��Service Handover information �&*(�(��

Octet 2 is a binary indication of the length of the remainder of the element in octets.Service Handover information is coded as follows:

Bits 4-8: Spare.

Bits 1-3:1 2 30 0 0 Handover to UTRAN should be performed0 0 1 Handover to UTRAN should not be performed0 1 0 Handover to UTRAN shall not be performedAll other values are interpreted as no information available.

ETSI SMG2#35 meeting Document 640/00Schaumburg, Illinois, USA3 -7 April, 2000

Agenda Item7.1.5.9

e.g. for 3GPP use the format TP-99xxxor for SMG, use the format P-99-xxx


Current Version: 8.3.008.58 CR A052Agenda Item; 7.1.5.9

GSM (AA.BB) or 3G (AA.BBB) specification number ↑ ↑ CR number as allocated by MCC support team


↑for information non-strategic X use only)



Source: Ericsson Date: 290300

Subject: Enhanced measurement reporting capability

Work item: GSM-UMTS Interworking



Release 00

Reason forchange:

New messages introduced.

Clauses affected:


specifications→ List of CRs: 04.18


Othercomments:

8.4.8 MEASUREMENT RESULTThis message from BTS to BSC is used to report to BSC the results of radio channel measurements made by BTS(uplink) and to convey the measurement reports from MS received on SACCH and in the L1 headers.

� �� 94

��+��$%�* %�%'�(& �� >=�� !�� +��(/,�� >=�� !�� 0�''��'�� >=�=�� !�� '(� ��(�� >=�=�"�� !�� '�� ,�%'-�� '(�� >=�=�� !� �@A�� 5��&2� �� >=�=�� !�� ')& ��(%&'�� >=�=�� B�� !�� ')&C��, or EXT ��>=�=�� B�� !� �� or ENH MEAS REP) �� %�%'+��))��(�� >=�=�"�� B�� !��

1) The L1 Information element contains the last received L1-header (MS Power and Timing Advance) fromMS and the L3 Information element contains the complete MEASurement REPort message, orEXTended MEASurement REPort message or ENHanced MEASurement REPort message freceivedfrom MS. They are included only if received since last (EXTended/ENHanced) MEASurement RESultmessage.

2) MS Timing Offset can be optionally included to increase the accuracy of possible distancemeasurements.

9.3.10 L1 InformationThis element carries the information used in the L1 header of SACCH blocks.

8 7 6 5 4 3 2 1

��'(�%$�'(%)%� ��

��,&2� �� $�� <

��*(��%�%'+��$��'*�� <

Octets 2-3 contain the L1 header information of SACCH blocks. The information fields and codings are as defined inGSM 04.04.9.3.11 L3 Information (message name)This element contains a link layer service data unit (L3 message). It is used to forward a complete L3 message asspecified in GSM 04.08 between BTS and BSC.

8 7 6 5 4 3 2 1

��'(�%$�'(%)%� ��

��'+(0��

�� '$%*�(& ��

��%'-��/� �� %*��1�(��'%(��

. (i.e. a layer 3 message .��

��$�)%'�$�%'�9��=�;B�� '

The Length Indicator field (octets 2-3) indicates in binary the remaining length of the element (octets 4-n). The mostsignificant bit is bit 8 of octet 2 and the least significant bit is bit 1 of octet 3.Octets 4-n contain the complete L3 message as defined in GSM 04.08. In the message format section, the 04.08message name to be included is indicated within brackets.

9.3.29 SACCH InformationThis element is used to carry the SACCH filling information (System Information messages, orEXTENDED MEASUREMENT ORDER message or MEASUREMENT INFORMATION message)that is to be used on a specific channel.The MEASUREMENT INFORMATION message isperiodically sent on SACCH.

69 GSM 08.58 V8.3.0 (2000-02)

8 7 6 5 4 3 2 1

��'(�%$�'(%)%� ��

��'+(0��

�� &)��+��

��/,��&)��(��+��

��'+(0�&)��(��+��

��(��+��

. . j

. .

. .

��/,��&)�'D(0��+��

��'+(0�&)�'D(0��+�� ?�

�� 'D(0��+��

. .

The Length field (octet 2) indicates in binary the total remaining length of the element (octets 3 - N).The Number of SI messages field (octet 3) indicates in binary the number of messages contained in theelement.The coding of each of these messages consists of a type field (Type of n’th msg), a length field (Lengthof n’th message) and a message field (n’th message).The "Type of n’th msg" field indicates the type of SYSTEM INFORMATION, or an EXTENDEDMEASUREMENT ORDER message or a MEASUREMENT INFORMATION message that follows inthe "n’th message" field. It is coded as follows:Value Message0 0 0 0 0 1 0 1 SYSTEM INFORMATION 50 0 0 0 0 1 1 0 SYSTEM INFORMATION 60 0 0 0 1 1 0 1 SYSTEM INFORMATION 5bis0 0 0 0 1 1 1 0 SYSTEM INFORMATION 5ter0 1 0 0 0 1 1 1 EXTENDED MEASUREMENT ORDER0 1 0 0 1 0 0 0 MEASUREMENT INFORMATIONAll other values are reserved.The "Length of n’th SI message" field indicates in binary the length of the "n’th message" field thatfollows.The "n’th message" field contains a complete SACCH message as defended in GSM 04.018.9.3.30 System Info TypeThis element is used to indicate the type of SYSTEM INFORMATION message, or an EXTENDEDMEASUREMENT ORDER message or a MEASUREMENT INFORMATION message as defined inGSM 04.018 .

8 7 6 5 4 3 2 1

��'(�%$�'(%)%� ��

��/�� ')&�/,��

The Sys Info Field (octet 2) indicates the type of message. It is coded as follows:Value Message0 0 0 0 0 0 0 0 SYSTEM INFORMATION 80 0 0 0 0 0 0 1 SYSTEM INFORMATION 10 0 0 0 0 0 1 0 SYSTEM INFORMATION 20 0 0 0 0 0 1 1 SYSTEM INFORMATION 30 0 0 0 0 1 0 0 SYSTEM INFORMATION 40 0 0 0 0 1 0 1 SYSTEM INFORMATION 50 0 0 0 0 1 1 0 SYSTEM INFORMATION 60 0 0 0 0 1 1 1 SYSTEM INFORMATION 70 0 0 0 1 0 0 0 SYSTEM INFORMATION 16

70 GSM 08.58 V8.3.0 (2000-02)

0 0 0 0 1 0 0 1 SYSTEM INFORMATION 170 0 0 0 1 0 1 0 SYSTEM INFORMATION 2bis0 0 0 0 1 0 1 1 SYSTEM INFORMATION 2ter0 0 0 0 1 1 0 1 SYSTEM INFORMATION 5bis0 0 0 0 1 1 1 0 SYSTEM INFORMATION 5ter0 0 0 0 1 1 1 1 SYSTEM INFORMATION 100 1 0 0 0 1 1 1 EXTENDED MEASUREMENT ORDER0 1 0 0 1 0 0 0 MEASUREMENT INFORMATION

All other values are reserved.

source: smg2 - 株式会社qt smg2 crs to gsm 08.58, 08.08 and 04.18 (gsm-3g handover) introduction...

Documents