Table of Contents

1.0 Functional description (FN)

1.1 Feature title 3 1.2 Feature synopsis 3 1.3 Functional overview 3 1.3.1 Phase 2 SDCCH Handover 3 Figure 1:Basic SDCCH External Intra-MSC Handover 4 1.3.2 Directed Retry 5 Figure 2:Directed Retry Resulting In An Internal Intra-BSS Handover 6 Figure 3:Directed Retry Resulting In An External Intra MSC-A Handover 7 1.4 Feature description 8 1.4.1 Phase 2 SDCCH Handover 8 Table 1:MAP and HCF Abnormal Dialogue Responses 9 1.4.2 BSSMAP Procedure Issues with SDCCH Handover 13 Figure 4:Clear intra MSC-A Handover Due to Assignment Request 14 Figure 5:Queue Assignment Request and continue with intra MSC-A HO 15 Figure 6:Clear intra MSC-A Handover Due to Ciphering 16 1.4.3 Directed Retry 17 1.4.4 Message Protocols 19 1.5 Supplementary information: Engineering/Hardware 20 1.5.1 Engineering hardware information 20 1.6 Supplementary information: DDOC sections 20 1.6.1 Logs (LG) 20 1.6.2 Data schema (DS) 20 1.6.3 Man machine interface (MM) 20 1.6.4 Operational measurements (OM) 20 1.6.5 AMA/Billing information (AM) 20 1.7 Feature impact 20 1.7.1 Interactions 20 1.7.2 Restrictions/limitations 20 1.8 Denitions & abbreviations 21 1.9 References 21 1.9.1 Phase 2 References 21 1.9.2 Phase 1 References 22

2.0 Design description (DD)

23

2.1 Functional requirements specication 23 2.1.1 Functional overview 23 2.1.2 Source requirements reference 24 2.1.3 Context 24 2.1.4 Interface agreements 24 2.2 Glossary 24 2.3 References 25 2.3.1 Phase 2 References 25 2.4 Design approach 26 2.4.1 Changed Class Processors and Procvars for Directed Retry 27 2.4.2 New and Changed Procvars and class processors for Intra MSC SDCCH Handover 37 2.5 Feature impact 45

ad7896.aa09.TOC

2 2.6 Initialization 45 2.7 Implementation information 45 2.7.1 New modules 45 2.7.2 New subsystems 45 2.7.3 Modied modules 45 2.7.4 Target Product CM Load (PCL) 45 2.7.5 Run time relationships 45 2.8 Supplementary information 46 2.8.1 DMS-Bus backward capability 46 2.8.2 Impact on system recovery 46 Table 2: 46 Table 3: 46 2.8.3 Software upgrade checklist 47 2.8.4 Treatments 47 Table 4: 47

3.0 Engineering information (EI)

3.1 Hardware specics 49 3.1.1 Gating hardware 49 3.1.2 Hardware provisioning 49 3.2 Firmware specics 49 3.3 Pack diagnostic specics 49 3.4 Related features 50 3.5 Comments for testing & loadbuilding 50 3.6 Test equipment 50 3.7 Other comments 50 3.8 Store 50 3.8.1 Impact 50 3.8.2 Store estimates section 50 3.8.3 Store measurements section 51 Table 5: 51

49

4.0 Operational measurement changes (OM)

4.1 OM Group Related Information 53 4.1.1 New/modied OM group list 53 4.1.2 OM Group 53 Table 6: 53 Figure 7:SXDRHO logic flow 55 Figure 8:IRSDCCH logic flow 56 4.2 OM Register Information 57 4.2.1 New/modied registers 57 4.2.2 Register name: SXDRHO 57 Table 7: 57 4.2.3 Register name: IRSDCCH 58 4.3 OM Integration Coverage 58

53

5.0 Real Time (RT)

5.1 FR Template 59 5.1.1 Product Line 59 5.1.2 Category 60 5.1.3 Processor Elements 60 5.1.4 Feature Information 61 ad7896.aa09.TOC

59

Table of Contents 5.1.5 Comments 61 5.2 CM Design Finish Template 61 5.3 Design Test Template 62 5.3.1 CM Feature Interaction 62 5.3.2 CM Direct Impact 62 5.3.3 CM Maintenance and Network Maintenance 5.3.4 XPM 64 5.3.5 LPP 66

63

6.0 Design test plan (DT)

6.1 Strategy 69 6.1.1 Test approach 69 6.1.2 Test exceptions 70 6.2 Test requirements 70 6.2.1 Conguration diagrams 70 6.2.2 Hardware requirements 70 6.2.3 Data requirements 70 6.2.4 Firmware requirements 70 6.2.5 Tool requirements 70 6.3 Activity tests 70

69

ad7896.aa09.TOC

ad7896.aa09.TOC

1 TASK IDENTIFICATION (ID) ======================== TASKID : AD7896DDOC01 TITLE : SDCCH & DIRECTED RETRY UPDATED: 9509202020 SYSTEM : DMSGSM FREL : 06 PROJECT: GSM PROJECT MANAGER: VASERFIRER.A PRIME NAME : YUAN.L ABSTRACT :

DEPT: 2Z00 DEPT: 2Z30 DEPT: 2Z53

This feature implements support of a call involving a Stand-alone Dedicated Control Channel (SDCCH) and handover from an SDCCH to a TCH (Directed Retry).

________________________________________________________________________ SECTIONS ======== Functional Description Design Description Engineering Information Data Schema Operational Measurements Man Machine Interface Logs References Real Time Designer Test plan Test Plan AMA/Billing FN DD EI DS OM MM LG RF RT DT TP AM NEEDED ====== Y Y Y <N>O <Y>O <N>O <N>O <N>O Y Y <N>O <N>O O = Optional Sections

Restricted distribution Internal Use Only (BNR & NT) Required if parms/data tables affected

Restricted distribution Restricted distribution Restricted distribution For use by system test group only Required if AMA/SMDR/Billing affected

________________________________________________________________________ DDOC STATUS: DT ________________________________________________________________________ CODE COVERAGE % for AD7896SOFT01: 100

ad7896.aa09id

ad7896.aa09id

1.

Functional description (FN)

1.1

Feature title
SDCCH Handover & Directed Retry

1.2

Feature synopsis
This feature provides the following GSM Phase 2 functionality: Stand-alone Dedicated Control Channel (SDCCH) Handover Directed Retry

1.3

Functional overview
The following subsections present an overview of the functionality provided by this feature. Discussions in this document are always presented one functional aspect at a time. This feature builds on top of feature AD7741, which provides the framework for Phase 2 Inter MSC handover and the basic Phase 2 Inter MSC Trafc Channel (TCH) Handover functionality. 1.3.1 Phase 2 SDCCH Handover Stand-alone Dedicated Control Channel (SDCCH) handover is the handover of the signalling only resources (no terrestrial voice trunk is used) outside of a voice or data call, such as during the pre-assignment stage of a call, Short Message Service, CISS (Call Independent Supplementary Service), Call Forwarding Management, etc. This feature also supports SDCCH handovers during location updates.

ad7896fn.aa09

4 Functional description (FN)

This feature enhances DMSMSCs Handover Control Function (HCF) to support basic Intra MSC SDCCH Handover. The following types of handover shall be restricted from the MSC: Basic Inter MSC SDCCH Handover from MSC-A to MSC-B Subsequent Inter MSC SDCCH Handover from MSC-B to MSC-B' Subsequent SDCCH Handback from MSC-B back to MSC-A
Figure 1 shows the message ow for Intra-MSC SDCCH handover delivered by this feature.

Figure 1 Basic SDCCH External Intra-MSC Handover

MS

BSSnew

MSC
HO Required

BSSold

MS

HO Request

HO Request Ack HO Command HO Command

HO Access HO Detect

HO Complete HO Complete

Clear Cmd/Cmp

ad7896fn.aa09

Functional description (FN) 5

1.3.2

Directed Retry The Directed Retry Handover is the handover of a SDCCH to a TCH. The directed retry procedure allows the network to select the optimum cell for the Mobile Station. If at the time of trafc channel Assignment, a handover becomes necessary, due to either radio conditions or congestion, then the Mobile Station may be handed over to a different cell. The types of Directed Retry supported by this feature are: Internal Intra-BSS Directed Retry External Intra MSC-A Directed Retry
Figure 2 and Figure 3 show the message ows for each type of Directed Retries

delivered by this feature and each will be discussed in detail later.

ad7896fn.aa09

6 Functional description (FN) Figure 2 Directed Retry Resulting In An Internal Intra-BSS Handover MSC
CL3i[CMSR]/PGRSP

BSS

Assignment Request

Handover Performed (Optional)

Assignment Complete (Including Cell ID)

ad7896fn.aa09

Functional description (FN) 7 Figure 3 Directed Retry Resulting In An External Intra MSC-A Handover BSSnew MSC-A BSSold

CL3i[CMSR]/PGRSP

Assignment Request

Assignment Failure [Directed Retry]

Handover Required [Directed Retry] HO Request

HO Request Ack Handover Command HO Detect

HO Complete Clear Command

Clear Complete

ad7896fn.aa09

8 Functional description (FN)

1.4

Feature description
A detailed description of the functionality provided by this feature is provided in this section. The two major functional aspects delivered by this feature are presented: SDCCH Handover Directed Retry

1.4.1

Phase 2 SDCCH Handover The HCF functionality necessary to handover a dedicated control channel in intra MSC scenarios is provided by this feature. This section presents the DMS MSCs behavior during Intra-MSC SDCCH handover procedures. 1.4.1.1 Message Processing Details The individual messages which together comprise the SDCCH handover procedures are discussed in detail. The following information is presented (where applicable) about each message and the impact on the overall handover procedure: Message Message content Sending of Message Successful sending of message Abnormal local operation Abnormal responses from the far end Reception of Message Successful reception of message Abnormal local operation Abnormal responses from the far end Message ows are provided to graphically display the DMSMSCs behavior. The ows build upon each other as new messages are introduced. As a result, the entire handover procedure is detailed by the time the last message is discussed. The messages ows cover only the major Success and Failure cases which concern the HCF. Also keep in mind that an ABORT message may be received at MSC-A at anytime.

ad7896fn.aa09

Functional description (FN) 9

The conventions used in this document to indicate abnormal dialogues between the HCF and MAP are shown in the following table.
Table 1 MAP and HCF Abnormal Dialogue Responses Indication
Abort Cancel Error Reject

Explanation
Used by MAP and HCF to abort a transaction Used by MAP to locally cancel a transaction Used by HCF toward MAP in error cases Used by HCF toward MAP in reject cases

1.4.1.2 Intra MSC SDCCH Handover This feature supports Intra MSC SDCCH handover without phase restrictions, i.e. handover between two Phase 2 mobiles, two Phase 1 mobiles or between mixed phase mobiles. The messaging related to a basic Intra MSC SDCCH handover is identical to a regular handover involving a TCH channel. There are some deviations, however, in the processing of SDCCH handovers from a TCH handover. First of all, no circuit connection updating is required because there is no connection to update. Secondly, no facility allocation to the target BSS is required. Note that Intra MSC SDCCH handovers can not be initiated prior to the sending of the rst BSSMAP or DTAP message from the MSC. 1.4.1.2.1 Handover Request

For SDCCH handovers, the HANDOVER REQUEST message that the MSC sends to the BSS indicates that a SDCCH channel is required in the Speech or Data Indicator octet of the Channel Type information element. If the value in the Speech or Data Indicator is signalling then SDCCH channel resources are set up with the target BSS instead of TCH resources. If the SDCCH handover occurs during a location update, the Classmark 1 information element is included in the HANDOVER REQUEST message; On the other hand, if the SDCCH handover occurs during a call, then the Classmark 2 information element is included in the HANDOVER REQUEST message.

ad7896fn.aa09

10 Functional description (FN)

1.4.1.2.1.1 Sending Handover Request When the old BSS, currently supporting the MS, determines that the MS requires a handover, it will send an HANDOVER REQUIRED message to the MSC. The HANDOVER REQUIRED message contains a list of possible cells, to which the MS can be handed over. When the MSC receives the HANDOVER REQUIRED message, it generates a HANDOVER REQUEST message to the selected BSS with the Channel Type set to signalling in the case of a SDCCH handover.

BSSOLD
HO Required

MSC

BSSnew

HO Request (Channel Type=Signalling) Start T_201

Wait for BSS Response

ad7896fn.aa09

Functional description (FN) 11

1.4.1.2.2

Receiving Handover Detect & Handover Complete

When HANDOVER DETECT is received during a SDCCH Handover, no action is taken, regardless of the value of the Use_Handover_Detect_ntwk_conn ofce parm. A normal TCH handover would perform the connection update upon receipt of the HANDOVER DETECT (if the Use_Handover_Detect_ntwk_conn is set to Y), or the HANDOVER COMPLETE message. In the case of SDCCH Handover, no connection update is required.

BSSOLD

MSC
HO Detect

BSSnew

HO Complete

Clear Cmd/Cmp

ad7896fn.aa09

12 Functional description (FN)

1.4.1.3 Restrict Inter MSC SDCCH Handover Inter MSC SDCCH Handovers shall be restricted from the DMS-MSC. If the DMS-MSC is MSC-A, a HO Required Reject shall be sent back to the old BSS. In this case, PREPARE HO[HO REQUEST] shall not be sent to MSC-B. If the DMS-MSC is MSC-B, an ERROR shall be sent back to MSC-A.

ad7896fn.aa09

Functional description (FN) 13

1.4.2

BSSMAP Procedure Issues with SDCCH Handover 1.4.2.1 Assignment during SDCCH Handover In the following scenarios, if a HANDOVER FAILURE is received from the BSS after the MSC-A has sent out a HANDOVER REQUEST, then there is no need to send the CLEAR CMD/CMP to the BSS. The same action is applied when the HANDOVER REQUEST ACK is never received by the MSC.

ad7896fn.aa09

14 Functional description (FN)

1.4.2.1.1

Assignment Request During Intra-MSC Handover

1.4.2.1.1.1 Assignment Request During Intra MSC-A Handover Intra-MSC handover on MSC-A is aborted if an ASSIGNMENT REQUEST message is received before HANDOVER REQUEST ACK is received from the new BSS. MSC-A sends the ASSIGNMENT REQUEST message to the old BSS, then it clears the connection with the new BSS via the CLEAR COMMAND message. Refer to Figure 4 for the message ow.
Figure 4 Clear intra MSC-A Handover Due to Assignment Request MSC-A BSSold BSSnew

HO Required HO Request

Any Assignment received before HO Request Ack causes the HO to be aborted in favor of the Assignment. MSC-A sends clear to new BSS if HO Request Ack is received after it has sent out Assignment Request to old BSS

Assignment Request HO Request Ack

Clear cmd/Cmp Assignment Complete

ad7896fn.aa09

Functional description (FN) 15

Intra-MSC handover on MSC-A is continued if an ASSIGNMENT REQUEST message is received after HANDOVER REQUEST ACK is received from the new BSS. In this case, MSC-A queues the ASSIGNMENT REQUEST message. After the handover is completed (MSC-A receives the HO COMPLETE message) the ASSIGNMENT REQUEST message is sent to the new BSS. Refer to Figure 5 for the message ow.
Figure 5 Queue Assignment Request and continue with intra MSC-A HO BSSold
HO Required HO Request HO Request Ack

MSC-A

BSSnew

Any Assignment received after HO Request Ack causes the Assignment to be queued until HO Complete is received.
HO Command HO Detect

HO Complete Clear Command/cmp Assignment Request Assignment Complete

ad7896fn.aa09

16 Functional description (FN)

1.4.2.2 Ciphering During SDCCH Handover In the following scenarios, if a HANDOVER FAILURE is received from the BSS after the MSC-A has sent out a HANDOVER REQUEST, then there is no need to send the CLEAR CMD/CMP to the BSS. The same action is applied when the HANDOVER REQUEST ACK is never received by the MSC. 1.4.2.3 Ciphering During Intra-MSC Handover Ciphering During Intra MSC-A Handover Intra-MSC handover on MSC-A is aborted if an CIPHER MODE COMMAND message is received before HANDOVER REQUEST ACK is received from the new BSS. MSC-A sends the CIPHER MODE COMMAND message to the old BSS, then it clears the connection with the new BSS via the CLEAR COMMAND message. Refer to Figure 6 for the message ow.
Figure 6 Clear intra MSC-A Handover Due to Ciphering MSC-A BSS-Bold BSS-Bnew

HO Required HO Request

Any Ciphering received before HO Request Ack causes the HO to be aborted in favor of the Ciphering. MSC-A sends clear to new BSS if HO Request Ack is received after it has sent out Cipher Mode Command to the old BSS

Cipher Mode Command HO Request Ack

Clear cmd/Cmp Cipher Mode Complete

ad7896fn.aa09

Functional description (FN) 17

1.4.3

Directed Retry 1.4.3.1 Internal Intra-BSS Directed Retry An internal Intra-BSS Directed Retry is handled by the BSS. After the MSC dispatches an ASSIGNMENT REQUEST toward the BSS, then the MSC awaits an ASSIGNMENT COMPLETE message from the BSS. If the DMS-MSC happens to receive the optional HANDOVER PERFORMED message with the new lac & cell id in the context of this scenario, then the MSC accepts it and update its lac & cell id. If, however, the DMS-MSC does not receive the optional HANDOVER PERFORMED message, then the new lac & cell id are included in the ASSIGNMENT COMPLETE message. Note that the new lac & cell id are included either in the HANDOVER PERFORMED message or in the ASSIGNMENT COMPLETE message, but not in both. Refer to Figure 2 for the message ow.

1.4.3.2 Internal Intra-BSS Directed Retry Within MSC-Bs Serving Area This scenario is handled as an ordinary ASSIGNMENT routine within MSC-Bs Area. Refer to Feature AD7741.

1.4.3.3 External Intra-MSC Directed Retry Within MSC-As Serving Area For an external Intra-MSC Directed Retry, if the MSC receives an ASSIGNMENT FAILURE[Directed Retry] after it sends out the ASSIGNMENT REQUEST message toward the BSS, then the MSC restarts the assignment timer TNT2 and awaits a HANDOVER REQUIRED[Directed Retry] message from the BSS. Since the ASSIGNMENT FAILURE[Directed Retry] message in this scenario is optional, there is no need to restart the assignment timer TNT2 if the MSC does not receive an ASSIGNMENT FAILURE[Directed Retry] message. In both cases, the assignment timer TNT2 should be stopped at the MSC when the HANDOVER REQUIRED[Directed Retry] arrives. The MSC continues with the Intra-MSC handover as usual until a HANDOVER COMPLETE message arrives from the new BSS. The MSC treats the HANDOVER COMPLETE as an implicit ASSIGNMENT COMPLETE message. However, if a HANDOVER FAILURE is received from the new BSS, or if the restarted assignment timer TNT2 expires awaiting a HANDOVER REQUIRED[Directed Retry] message, then the MSC treats it as an implicit ASSIGNMENT FAILURE message with cause value other than Directed Retry. The MSC treats CLEAR COMPLETE timer expiry as ASSIGNMENT COMPLETE as well, because all the transactions with the old BSS are considered nished.
ad7896fn.aa09

18 Functional description (FN)

Refer to Figure 3 for the message ow.

1.4.3.4 Restrict Inter MSC Directed Retry The DMS-MSC does not support Inter MSC Directed Retry. If the DMS-MSC is MSC-A, a HO Required Reject shall be sent back to the old BSS. Since initial assignment is restricted by feature AD7741, Inter MSC Directed Retry on MSC-B shall not happen.

ad7896fn.aa09

Functional description (FN) 19

1.4.4

Message Protocols Refer to feature AD7741 for the detailed message contents.

ad7896fn.aa09

20 Functional description (FN)

1.5

Supplementary information: Engineering/Hardware

1.5.1 Engineering hardware information Not applicable

1.6

Supplementary information: DDOC sections

1.6.1 Logs (LG) Not applicable 1.6.2 Data schema (DS) Not applicable 1.6.3 Man machine interface (MM) Not applicable 1.6.4 Operational measurements (OM) This feature adds two new OM registers SXDRHO and IRSDCCH to the MSCHO group to indicate the number of successful external Directed Retry handover occurrences within a MSC and the number of Inter MSC SDCCH handover occurrences blocked by the MSC. Refer to the OM section of this document. 1.6.5 AMA/Billing information (AM) Not applicable

1.7

Feature impact
1.7.1 Interactions
Phase 1 Handover

No impact is made by this feature to GSM Phase 1 Handover functionality as this feature only applies to Phase 2. 1.7.2 Restrictions/limitations Inter MSC Directed Retry is not support by this feature.
ad7896fn.aa09

Functional description (FN) 21

1.8

Denitions & abbreviations

ACM BSSAPDU

Address Complete Message. BSS AssociatedApplication Protocol Data Unit. MAP parameter which contains BSSMAP or DTAP messages. Handover Control Function The Handover Control Function is the entity responsible for controlling all the processing and resource management associated with all handover procedures. Initial Address Message. Mobile Application Part MAP provides the set of signalling functions which makes use of CCS7 to provide the services needed by voice and non-voice applications (like the HCF) in the PLMN (network). Stand alone Dedicated Control Channel used for the transmitting of messages between nodes when a circuit connection, or Trafc Channel, is not required. Trafc Channel used when a circuit connection for user voice or data is required.

HCF

IAM MAP

SDCCH

TCH

1.9

References
1.9.1 Phase 2 References
GSM

03.09 08.08

v 4.4.0: European Digital Cellular Telecommunications System (Phase 2); Handover Procedures. v 4.7.0: European Digital Cellular Telecommunications System (Phase 2); Mobile Switching CentreBase Station System (MSC-BSS) Interface Layer 3 Specication. v 4.9.0: European Digital Cellular Telecommunications System (phase 2); Mobile Application Part (MAP) specication. v 4.0.0: European Digital Cellular Telecommunications System (Phase 2); Application of the Base Station Application Part (BSSAP) on the E-Interface.

GSM

GSM

09.02 09.08

GSM

ad7896fn.aa09

22 Functional description (FN) GSM

09.10

v 4.2.1: European Digital Cellular Telecommunications System (Phase 2); Information Element Mapping Between Mobile Station - Base Station System and BSS - Mobile services Switching Centre (MS-BSS-MSC) Signalling Procedure and The Mobile Application Part (MAP) Inter MSC RR Procedures
MAP

AD7742 AD7889 AD7741 AD7891

Phase 2 Handover

Phase 2 Inter MSC Handover & Inter MSC Assignment

MAP MSC

Screening Table

1.9.2

Phase 1 References
AD4633 AD4635 AD4648 AD4650 MAP

Support Handover Operations I for Handover

GSM MAP ASE Support

Handover Remote Signalling Interface High-Level Handover Control Function Numerous other Phase 1 Features provided background reference for basic handover functionality.

ad7896fn.aa09

23

2. Design description (DD)

2.1 Functional requirements specication
The following subsections present an overview of the functionality provided by this feature. The following conventions are used: Message name: Code: Software enhancements:
HANDOVER REQUEST bssmap_hdb

Bold type or lines

2.1.1

Functional overview This feature adds functionality to the BSSMAP sublayer to handle the requirements of the following Phase 2 operations: Phase 2 Intra MSC SDCCH (Stand-alone Dedicated Control Channel)
Handover.

This feature enhances DMSMSCs Handover Control Function (HCF) to support Intra MSC SDCCH Handover. Phase 2 Intra MSC-A Directed Retry. This feature provides the ability to handover from a SDCCH to a TCH through directed retry. Only Intra MSC-A directed retry is implemented by this feature. Blocking Inter MSC SDCCH handover, Inter MSC Directed Retry Inter MSC SDCCH handover is blocked by this feature because of the removal of the initial inter MSC assignment for this release. Inter MSC Directed Retry is also blocked by this feature.

ad7896dd.aa09

24

2.1.2

Source requirements reference The following documents offer high level design and/or functional input for this feature:
Title
GSM06 HLD: Phase 2 BSSMAP and Handover Preliminary Design Notes: Phase 2 BSSMAP and HO GSM Phase 2 Recommendations

File Name
gp2r6hld gp2hohld Phase2

Library
PLS FMDOC PLS FMDOC PLS FMDOC

This feature builds upon functionality delivered by the following features:

Title
Handover Remote Signalling Interface Handover Local Signalling Interface

File Name
AD4648 AD4647

Library
PLS DOC PLS DOC

2.1.3

Context This feature does not change the interface with any external components.

2.1.4

Interface agreements N/A.

2.2

Glossary
HCF

Handover Control Function The Handover Control Function is the entity responsible for controlling all the processing and resource management associated with all handover procedures. Mobile Application Part MAP provides the set of signalling functions which makes use of CCS7 to provide the services needed by voice and non-voice applications (like the HCF) in the PLMN (network). Application Service Entity Invocation State Machine Trafc Channel used when a circuit connection for user voice or data is required.

MAP

ASE ISM TCH

ad7896dd.aa09

25 SDCCH

Stand alone Dedicated Control Channel used for the transmitting of messages between nodes when a circuit connection, or Trafc Channel, is not required.
BSS

BSSAPDU

Associated Application Protocol Data Unit. MAP parameter which contains BSSMAP or DTAP messages.

2.3

References
2.3.1 Phase 2 References
GSM

03.09 08.08

v 4.4.0: European Digital Cellular Telecommunications System (Phase 2); Handover Procedures. v 4.7.0: European Digital Cellular Telecommunications System (Phase 2); Mobile Switching CentreBase Station System (MSC-BSS) Interface Layer 3 Specication. v 4.8.0: European Digital Cellular Telecommunications System (phase 2); Mobile Application Part (MAP) specication. v 2.0.0: European Digital Cellular Telecommunications System (Phase 2); Application of the Base Station Application Part (BSSAP) on the E-Interface. v 4.0.0: European Digital Cellular Telecommunications System (Phase 2); Information Element Mapping Between Mobile Station - Base Station System and BSS - Mobile services Switching Centre (MS-BSS-MSC) Signalling Procedure and The Mobile Application Part (MAP) Inter MSC RR Procedures Phase 2 MAP Handover Phase 2 Inter MSC Handover & Assignment

GSM

GSM

09.02 09.08

GSM

GSM

09.10

AD7742 AD7889 AD7741

ad7896dd.aa09

26

2.4

Design approach
The details of implementing this feature are presented in the following sections. The following conventions are used: Message name: Cause values: Code: Software enhancements: Code which is moved:
HANDOVER REQUEST Data Missing bssmap_hdb

Bold type or lines

Slanted code is moved

The intent of this document is to list all required software changes in a Change gure. This provides the reader and implementer an easy consistent reference for the required changes. By referencing each Change gure, the gures can also serve as a implementation checklist. The implementation approach is as follows: Implement and test basic Phase 2 Intra MSC SDCCH HO 2. Implement and test basic Phase 2 Intra MSC-A Directed Retry 3. Blocking Inter MSC SDCCH HO 4. Blocking Inter MSC Directed Retry
1.

ad7896dd.aa09

27

2.4.1

Changed Class Processors and Procvars for Directed Retry 2.4.1.1 asg_fail_a_pvar

The asg_fail_a_pvar is modied for external Intra MSC-A Directed Retry purposes. If the MSC receives an ASSIGNMENT FAILURE[Directed Retry] after it sends out an ASSIGNMENT REQUEST message toward the BSS, then the MSC restarts the assignment timer TNT2 and awaits a HANDOVER REQUIRED[Directed Retry] message from the BSS. The ASSIGNMENT FAILURE[Directed Retry] message in this scenario is optional.

Module: Section:

GRRPVAR GRRPVAR2

Impact: t New Additions t Code Moved

Modified t All New t Code Obsoleted

After decoding, if the cause value is Directed Retry then reset the TNT2 timer set RR state to DT1 turn on the Directed Retry flag skip the transition to upper layers endif return

2.4.1.2

gsm_rr_directed_retry_conf_proc

The gsm_rr_directed_retry_conf_proc is modied for external Intra MSC-A Directed Retry purposes. The MSC starts a directed retry in the form of a handover and continues with the Intra-MSC handover as usual until a HANDOVER COMPLETE message arrives from the new BSS. The MSC treats the HANDOVER COMPLETE as an implicit ASSIGNMENT COMPLETE message. However, if a HANDOVER FAILURE is received from the new BSS, or if the restarted assignment timer TNT2 expires awaiting a HANDOVER REQUIRED[Directed Retry] message, then the MSC treats it as an implicit ASSIGNMENT FAILURE message with cause value other than Directed Retry. Failed or aborted handovers anytime during a directed retry are also considered as implicit assignment failures.
ad7896dd.aa09

Change 1: asg_fail_a_pvar

Go Back

28

The gsm_rr_directed_retry_conf_proc handles both the success and the failure scenarios for directed retrys. The processing is similar to that of the assignment procedure except that no decoding is necessary for this procedure.

Module: Section:

GRRDRPR GRRDRPR

Impact: t New Additions t Code Moved

t Modified All New t Code Obsoleted

invoke the appropriate procvar according to the class extension return

2.4.1.3

directed_retry_success

The directed_retry_success pvar has been added to process the success scenario of the directed retry. Since this is an implicit assignment complete, the processing is similar to that of the assignment proc.
Module: Section: Impact: t New Additions t Code Moved
Modified t All New t Code Obsoleted

GRRPVAR GRRPVAR2

set assign_complete flag set gsm_control_channel type set success in the HSB peg emergency OM if necessary reset the bssmap_cause transition to the upper layers return

ad7896dd.aa09

Change 3: directed_retry_success

Go Back

Change 2: gsm_rr_directed_retry_conf_proc

Go Back

29

2.4.1.4

directed_retry_failure

The directed_retry_failure pvar has been added to process the failure scenario of the directed retry. Since this is an implicit assignment failure, the processing is similar to that of the assignment proc.
Module: Section: Impact: t New Additions t Code Moved
Modified t All New t Code Obsoleted

GRRPVAR GRRPVAR2

reset the bssmap_cause set failure in the HSB transition to upper layers return

ad7896dd.aa09

Change 4: directed_retry_failure

Go Back

30

2.4.1.5

gsm_ho_required_ind_proc

The HO Required indication class processor has been modied to process an external Intra MSC-A Directed Retry. If the cause value is Directed Retry, then make sure the timer TNT2 is stopped, RR state is DT1 and the Directed Retry ag is set.
Module: Section: Impact: t New Additions t Code Moved
Modified t All New t Code Obsoleted

GHOBSSPR GHOB1REQ

Upon successful decoding of the HO Required message, If the cause value is Directed Retry then Stop the TNT2 timer Set the RR state to DT1 Set the bssmap cause value to Directed Retry Continue with the handover return

ad7896dd.aa09

Change 5: gsm_ho_required_ind_proc

Go Back

31

2.4.1.6

gsm_ho_connection_update_resp_proc

The connection update response proc is modied to transition to the directed retry conrmation proc if the bssmap cause value is Directed Retry.
Module: Section: Impact: t New Additions t Code Moved
Modified t All New t Code Obsoleted

GPIDSTPR GPIHCONN

When the connection update timer expires, If bssmap_cause is Directed Retry then set the class extension to directed retry success Transition to RR Directed Retry Conf Class Proc endif

return

ad7896dd.aa09

Change 6: gsm_ho_connection_update_resp_proc

Go Back

32

2.4.1.7

set_ho_idle_pvar

During a directed retry, if the handover fails or gets aborted, it is treated as an assignment failure. In this case, transition to the directed retry conrmation class processor needs to be made and the upper layers need to be informed. This procvar is called from the gsm_ho_mm1_ho_resource_conf_proc with personality A and ho_state being begin.
Module: Section: Impact: t New Additions t Code Moved
Modified t All New t Code Obsoleted

GHOPVAR GHOHCFPV

If the bssmap_cause is directed retry then set the class extension to Directed Retry Failure Transition to RR Directed Retry Conf Class Proc endif

return

ad7896dd.aa09

Change 7: set_ho_idle_pvar

Go Back

33

2.4.1.8

release_held_and_ho_idle_pvar

During a directed retry, if the handover fails or gets aborted, it is treated as an assignment failure. In this case, transition to the directed retry conrmation class processor needs to be made and the upper layers need to be informed. This procvar is called from the gsm_ho_mm1_ho_resource_conf_proc with personality A and ho_state being execute.
Module: Section: Impact: t New Additions t Code Moved
Modified t All New t Code Obsoleted

GHOPVAR GHOHCFPV

If the bssmap_cause is directed retry then set the class extension to Directed Retry Failure Transition to RR Directed Retry Conf Class Proc endif

return

ad7896dd.aa09

Change 8: release_held_and_ho_idle_pvar

Go Back

34

2.4.1.9

mm1_ho_cmd_error_begin_pvar

During a directed retry, if the handover fails or gets aborted, it is treated as an assignment failure. In this case, transition to the directed retry conrmation class processor needs to be made and the upper layers need to be informed. This procvar is called from the gsm_ho_mm1_ho_command_conf_proc with ho_state being begin.
Module: Section: Impact: t New Additions t Code Moved
Modified t All New t Code Obsoleted

GHOPVAR GHOHCFPV

If the bssmap_cause is directed retry then set the class extension to Directed Retry Failure Transition to RR Directed Retry Conf Class Proc endif

return

ad7896dd.aa09

Change 9: mm1_ho_cmd_error_begin_pvar

Go Back

35

2.4.1.10 mm1_ho_det_ho_cmd_error_execute_pvar During a directed retry, if the handover fails or gets aborted, it is treated as an assignment failure. In this case, transition to the directed retry conrmation class processor needs to be made and the upper layers need to be informed. This procvar is called from the gsm_ho_mm1_ho_command_conf_proc with ho_state being execute.
Module: Section: Impact: t New Additions t Code Moved
Modified t All New t Code Obsoleted

GHOPVAR GHOHCFPV

If the bssmap_cause is directed retry then set the class extension to Directed Retry Failure Transition to RR Directed Retry Conf Class Proc endif

return

ad7896dd.aa09

Change 10: mm1_ho_det_ho_cmd_error_execute_pvar

Go Back

36

2.4.1.11 ho_det_release_held_and_ho_idle_pvar During a directed retry, if the handover fails or gets aborted, it is treated as an assignment failure. In this case, transition to the directed retry conrmation class processor needs to be made and the upper layers need to be informed. This procvar is called from the gsm_ho_mm1_ho_command_conf_proc with ho_state being execute.
Module: Section: Impact: t New Additions t Code Moved
Modified t All New t Code Obsoleted

GHOPVAR GHOHCFPV

If the bssmap_cause is directed retry then set the class extension to Directed Retry Failure Transition to RR Directed Retry Conf Class Proc endif

return

ad7896dd.aa09

Change 11: ho_det_release_held_and_ho_idle_pvar

Go Back

37

2.4.2

New and Changed Procvars and class processors for Intra MSC SDCCH Handover 2.4.2.1 local_signalling_allocation

This procedure has been modied to set the Channel Type information element to signalling in the HANDOVER REQUEST message if the BSSMAP_HDB.gsm_control_channel indicates SDCCH.
Module: Section: Impact: t New Additions t Code Moved
Modified t All New t Code Obsoleted

GRRUTIL GHOUTL1

Copy the handover request message template to the scratch pad make sure that Handover HDB has been allocated reserve a call slot in the LIU check for data If the BSSMAP_HDB.gsm_control_channel indicates SDCCH, then set he Channel Type information element to signalling check if the call is a Type 2 emergency call encode the ho request message Send ho request return

ad7896dd.aa09

Change 12: local_signalling_allocation

Go Back

38

2.4.2.2

gsm_ho_required_ind_proc

This procedure has been modied for Phase 2 to remove the restriction of checking a TCH has been allocated (receipt of an Assignment Complete is indicative of having reached this state) upon any request for handover. Since handovers can occur during the pre-assignment phase in Phase 2, the gsm_control_channel information need to be passed in the HO_Dist: HO REQUIRED message from MM1 to MM2 call and not be hardcoded anymore.
Module: Section: Impact: t New Additions t Code Moved
Modified t All New t Code Obsoleted

GHOBSSPR GHOB1REQ

Check iam_after_ho_compl If the BSS is Phase2, then remove the checking for assign_complete before processing the handover Check HO State decode the ho required message Copy the gsm_control_channel information and the bssmap_cause from the BSSMAP HDB to the HO_Dist: HO Required message, so that the new MM2 call retains the same information. If the Directed Retry flag is set, set the channel type to SACCH; otherwise, leave it as it is.

ad7896dd.aa09

Change 13: gsm_ho_required_ind_proc

Go Back

39

2.4.2.3

setup_mm2_and_translate_pvar

This pvar is modied to copy the gsm_control_channel information & the bssmap_cause from the HO_Dist: HO REQUIRED message to the BSSMAP HDB on MM2 call.
Module: Section: Impact: t New Additions t Code Moved
Modified t All New t Code Obsoleted

GHOPVAR GHOHCFPV

Setup the BSSMAP HDB with information in the HO_Dist: HO REQUIRED message Copy the gsm_control_channel & the bssmap_cause from the HO_Dist: HO REQUIRED message to the BSSMAP HDB if the channel type is SACCH, then assign TRUE to assign_compl bool. Set RR State Set HO State .

ad7896dd.aa09

Change 14: setup_mm2_and_translate_pvar

Go Back

40

2.4.2.4
REQUIRED

grrtypes

Add the gsm_control_channel & the bssmap_cause in the HO_Dist: HO message.

Module: Section: Impact: t New Additions t Code Moved
Modified t All New t Code Obsoleted

GRRTYPES GRRTYPES

%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%% % TYPE GSM_HOD_HOREQ_FMT % This type is used for defining the formats of the % HO_Dist:HO Required Message Contents %%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%% TYPE gsm_hod_horeq_fmt STRUCT personality bssmap_personality_type, serving_lac gsm_lac_type, serving_cell_id gsm_ci_value_type, classmark_info ms_class2_work_area_type, encrypt_info encry_work_area_type, cc_prime_address mobility_mgmt_address_type, saved_supv saved_supervision_type, mscnumber t_tbcd_isdn_address_string, facility_integ integrity_value, mm_pathend pathend, % cell_list and esmr_cell_list have to be overlayed % starting from the same offset (see note in HANDOVER HDB). OVLY {0 TO 1} {0}: cell_list {1}: esmr_cell_list esmr_ho_info_list ENDOVLY, trid radio_channel bss_info mstrace_invoked mstrace_data emergency_call gsm_control_channel bssmap_cause

cell_id_list_work_area_type esmr_cell_id_list_work_area_type, esmr_ho_info_list_work_area_type unsignedint, g_channel_type, bss_info_type, mstrace_invocation_t, %AD7177 mstrace_bssmap_data_t, %AD7177 bool, gsm_control_channel_type gsm_bssmap_cause_value

ENDSTRUCT;

ad7896dd.aa09

Change 15: grrtypes

Go Back

41

Rename clear_cause to bssmap_cause so that it can be reused for directed retry purposes.
Module: Section: Impact: t New Additions t Code Moved
Modified t All New t Code Obsoleted

GRRTYPES GRRTYPES

TYPE gsm_bssmap_hdb_data_type AREA REFINES gsm_mobility_data . . . bssmap_cause gsm_bssmap_cause_value, . . . ENDAREA;

2.4.2.5

pi_facility_deallocation_pvar

This procedure has been modied so that if the BSSMAP_HDB.gsm_control_channel indicates SDCCH, then do_nothing.
Module: Section: Impact: t New Additions t Code Moved
Modified t All New t Code Obsoleted

GPIPVAR GPIPVAR1

If the gsm_control_channel in the BSSMAP HDB indicates SDCCH, then return; deallocate voice facility

ad7896dd.aa09

Change 17: pi_facility_deallocation_pvar

Go Back

Change 16: grrtypes

Go Back

42

2.4.2.6

ho_detect_pvar

Depending on the value of the ofce parameter Use_Handover_Detect_ntwk_conn, a normal TCH handover would perform connection update upon receipt of the HANDOVER DETECT or HANDOVER COMPLETE message. In the case of SDCCH HO, no connection update is required, so all connection update related processing can be skipped.
Module: Section: Impact: t New Additions t Code Moved
Modified t All New t Code Obsoleted

GHOPVAR GHOHCFPV

Set the handover detect event state to active If the channel type is TCH, then do the following. Do nothing for SDCCH If use_handover_detect_ntwk_conn then Set the handover detect event state to active Set the connection update state to active build and send the HO_Dist: Connection Update message endif

return

ad7896dd.aa09

Change 18: ho_detect_pvar

Go Back

43

2.4.2.7

mm2_ho_cmd_req_loc_rem

The mm2_ho_cmd_req_loc_rem is invoked from the MM2 HO Command Conrmation class processor for personality A and handover type being local. This class processor has been modied to transition to the upper layers from MM1 to MM2 call and peg the SDCCH OMs and send out the HODIST:HO COMPLETE message to MM1 for SDCCH handovers. This procvar has also been modied to skip the facility allocation procedure for SDCCH handovers.

Module: Section:

GHOPVAR GHOHCFPV

Impact: t New Additions t Code Moved

Modified t All New t Code Obsoleted

locate the handover hdb Start the appropriate handover timer. Invoke pi allocation procedure for TCH, do_nothing for SDCCH. Do the following for SDCCH handovers: Set the Handover state generate an info log if call is being traced Set the personality Transfer the upper layers from MM1 to MM2 Set the cause value to indicate the handover was successful Send HO_Dist: HO Complete message to the old MM1 call Set the handover state to idle Set the ho_detected flag to false Set the handover type to none return mob_force_condense

return;

ad7896dd.aa09

Change 19: mm2_ho_cmd_req_loc_rem

Go Back

44

2.4.2.8

local_ho_resource_req_loc_pvar

This procvar has been modied to invoke different utilities based on the channel type. For SDCCH handovers, facility allocation is not needed.

Module: Section:

GHOPVAR GHOHCFPV

Impact: t New Additions t Code Moved

Modified t All New t Code Obsoleted

Invoke facility allocation for TCH, do_nothing for SDCCH. Allocate the signalling interface to the mobile. return;

2.4.2.9

translation_pvar_a

This procvar is invoke from translate_on_next_cell where different avors of handovers are determined. This is where Inter MSC Directed Retrys and Inter MSC SDCCH handovers are blocked.

Module: Section:

GHOLA GHOXLAIM

Impact: t New Additions t Code Moved

Modified t All New t Code Obsoleted

If this is an Inter MSC SDCCH handover or Directed Retry, put gsm_call_control into the cause_value send a HO_Dist: HO_NO_GO to MM1 endif;

ad7896dd.aa09

Change 21: translation_pvar_a

Go Back

Change 20: local_ho_resource_req_loc_pvar

Go Back

45

2.5

Feature impact
N/A.

2.6

Initialization
Same initialization requirements as all BSSMAP sublayer development.

2.7

Implementation information
2.7.1 New modules
GRRDRPR

2.7.2

New subsystems None

2.7.3

Modied modules GHOBSSPR GPIDSTPR GRRPVAR GRRTYPES GHOLA GPIPVAR GHOPVAR GRRUTIL Target Product CM Load (PCL) N/A

2.7.4

2.7.5

Run time relationships N/A

ad7896dd.aa09

46

2.8

Supplementary information
2.8.1 DMS-Bus backward capability

Table 2
Am I changing the format or content of any existing DMS-Bus message? Am I adding any new DMS-Bus message or deleting any existing DMS-Bus message? Do any of the above messages that I am affecting originate in or are destined for the Message Switch Node software directly or indirectly? N N N

2.8.2

Impact on system recovery

Table 3
1. Does your feature affect any recovery time of any DMS maintainable entities by >1%?(Y/N) N Fill the following if the answer is Yes.

Entity

Action

Old time

New time

Comment

(A) bootload (B) RTS (C) restart/initialization (D) software patch download and application (E) recovery during CM restart 2. Does this feature change the relation between office recovery time and office size? (Y/N) N If yes, give details.

3.

Does this feature introduce new scenarios that require a restart of any type? (Y/N) If yes, explain (restart type and why).

4.

Does this feature automate any manual recovery action?(Y/N) If yes, give details (action affected & how).

5.

Does this feature inhibit/disable a previously automated recovery action?(Y/N)

ad7896dd.aa09

47 Table 3
If yes, give details (action affected & how).

6.

Does this feature affect recovery of just a particular product in the DMS family?(Y/N) If yes, give details.

7.

Does this feature change the dependencies between various DMS maintenance entities?(Y/N) If yes, give details.

8.

Does this feature change or add the initialization code in such a way that the total restart time changes by more than 1%? (Y/N) If yes, give details.

2.8.3

Software upgrade checklist

Table 4

Software Upgrade Checklist

1. 2. Does the application introduce new software that must be initialized over a s/w upgrade? Does the application introduce new h/w that: a) b) c) 3. 4. requires EXECs to be loaded as part of the RTS sequence? has a status (i.e. INSV, OFFL, MANB,...) initialized by a RESTART? has a status that must survive a software upgrade?

YES / NO
NO NO

NO NO NO NO

Does the application require that Table Data, Non-tabular Configuration Data or Dynamic Data be preserved over a software upgrade? Does the application require that calls be supported over a software upgrade?

2.8.4

Treatments None

ad7896dd.aa09

48

ad7896dd.aa09

49

3. Engineering information (EI)

3.1 Hardware specics
3.1.1 Gating hardware Feature Gating: N/A

Product Release Gating: N/A

Affected Existing: N/A

3.1.2

Hardware provisioning Hardware provisioning rules or recommendations:N/A Specify the DIRPSYS (Disk Drive) provisioning and sizing considerations associated with this feature: Disk sizing provisioning: N/A Design change document: N/A DCD class: N/A

3.2 3.3

Firmware specics
PM loads and associated PMs:N/A

Pack diagnostic specics

PEC CODE of affected pack: N/A
ad7896ei.aa09

50 Engineering information (EI)

% of coverage improvement: N/A % of currently deployed packs that will fail: N/A Impact of failure: N/A Urgency of failure: N/A

3.4

Related features
This feature needs the following features (NEEDS/USES)to function properly (refers only to features outside the GSM DRU or internal features developed in the current release):N/A This feature is part of a group of features USED BY feature:N/A

3.5

Comments for testing & loadbuilding

Small amount of testing involving two Captive ofce MSCs with simulated BSSs is required to be complete.

3.6

Test equipment
N/A

3.7

Other comments
N/A

3.8

Store
3.8.1 Impact This feature requires additional Program Store. 3.8.2 Store estimates section

ad7896ei.aa09

Engineering information (EI) 51

3.8.2.1 Synopsis

Table 5
SOS or XPM based processor: For SOS based processors: a) specify family (68000, BRISC, ALL): b) affected node types (e.g. CM LTS, MS LIU): For XPM based processor: a) specify processor (e.g. MP, SH, EP, ISP, or DCH): b) affected node types (e.g. LGC, DTC7, SMU): Maximum IPL DS impact of Activity is:) (specify KBytes or KWords) Range of Datafill DS impact of Activity is: a) minimum (specify KBytes or KWords) b) maximum (specify KBytes or KWords) Maximum IPL PS impact of Activity is: (in KBytes) 0 <5k 0 <1k CM SOS All

3.8.2.2 Additional comments

3.8.3

Store measurements section 3.8.3.1 Data store formulae

SOS based processor measured on 68000 or 88000 based family:

both

Increased store (I) or Existing store (E) being documented after the fact (i.e. no change)? (I/E): I 3.8.3.2 Data structure details Module name: 3.8.3.3 Synopsis N/A
ad7896ei.aa09

52 Engineering information (EI)

Variable/dynamic increase of data store Store cost per item: or: or DDOC: An item is: Store allocation granularity: (number of items allocated at a time) Formula for calculating store increase: 3.8.3.4 Additional comments NONE _ WORDS per item BYTES per item describes item size.

ad7896ei.aa09

53

4. Operational measurement changes (OM)

4.1 OM Group Related Information
4.1.1 New/modied OM group list
Table 6 GROUP NAME (acronym)
MSCHO

GROUP NAME (expanded)

MSC Handover

NEW, CHANGED or DELETED

CHANGED

REASON
New Registers

4.1.2

OM Group MSC Handover 4.1.2.1 Group structure Key eld: N/A Info eld: N/A Number of tuples: 4.1.2.2 Datall N/A 4.1.2.3 Register list SXDRHO IRSDCCH

ad7896om.aa09

54 Operational measurement changes (OM)

4.1.2.4 Associated OM groups N/A 4.1.2.5 Validation formula N/A 4.1.2.6 Associated products DMS-MSC 4.1.2.7 OMSHOW example >omshow mscho active MSCHO CLASS: ACTIVE START:1994/12/01 13:30:00 THU; STOP: 1994/12/01 11:23:13 THU; SLOWSAMPLES: 0; FASTSAMPLES: 9;

SXDRHO SXDRHO2 IRSDCCH IRSDCCH2 0 0 0 0

ad7896om.aa09

Operational measurement changes (OM) 55

4.1.2.8 OM Logic ow or pseudocode

Figure 7 SXDRHO logic ow

HO_COMPLETE received

Peg SXDRHO

SXDRHO =65535?
Yes Peg SXDRHO2. Zero SXDRHO.

No

Pegging for SXDRHO/ SXDRHO2 complete.

ad7896om.aa09

56 Operational measurement changes (OM) Figure 8 IRSDCCH logic ow

translations on A, remote

Peg IRSDCCH

IRSDCCH =65535?
Yes Peg IRSDCCH2. Zero IRSDCCH.

No

Pegging for IRSDCCH/ IRSDCCH2 complete.

ad7896om.aa09

Operational measurement changes (OM) 57

4.2

OM Register Information
4.2.1 New/modied registers
Table 7 NEW ACTIVATED CHANGED ZEROED DELETED
NEW NEW

REGISTER NAME (acronym)

SXDRHO IRSDCCH

REGISTER NAME (expanded)

Successful External Directed Retry Handovers Inter SDCCH Handovers

GSM Rel NUMBER

CSP04/GSM06 CSP04/GSM06

4.2.2

Register name: SXDRHO

4.2.2.1 Register type Peg 4.2.2.2 Register description This is the number of successful external Directed Retry handover occurrences within a MSC. 4.2.2.3 Associated register None 4.2.2.4 Validation formula None 4.2.2.5 Associated logs Log number: None 4.2.2.6 EXT register SXDRHO2
ad7896om.aa09

58 Operational measurement changes (OM)

4.2.3

Register name: IRSDCCH

4.2.3.1 Register type Peg 4.2.3.2 Register description This is the number of Inter MSC SDCCH handover occurrences blocked by the MSC. 4.2.3.3 Associated register None 4.2.3.4 Validation formula None 4.2.3.5 Associated logs Log number: None 4.2.3.6 EXT register IRSDCCH2

4.3

OM Integration Coverage

N/A

ad7896om.aa09

59

5. Real Time (RT)

5.1 FR Template

5.1.1

Product Line PROD_ID: SMSC: X SHLR: Product Name: DMS-MSC(Mobile Switching Centre): X SHLR(Home Location Register): Ofce Type MSC: X HLR: STP: Other: Comments:

ad7896rt.aa09

60 Real Time (RT)

5.1.2

Category Call Processing: Billing: Maintenance: VLR: Mobility Management: X OMC: MAP (Mobile Application Part): BSSAP: Network Maintenance: Table Control: Other: Comments:

5.1.3

Processor Elements Central Control Not Applicable: All CM: X 68000 Series SuperNode: 88000 Series SuperNode: 68000 Series SNSE: 88000 Series SNSE: CPS: MS: ENET: JNET: Other: Comments: Peripherals: Not Applicable: X All LPP: LIU7: APU: All LCM: LCME: Other: EIU: VPU: XLIU: FRIU: Other: XLCM: RLCC: PRLCM:

ad7896rt.aa09

Real Time (RT) 61

All XPM: All XPM+: MP: FP: Other: Other LCD: RCT: File Processor (FP): AP: MPC/EMPC: Other: Comments: 5.1.4 Feature Information

SP: ISP/EISP: SIGP: EP: UP: DCH/EDCH:

RCU: Access Node:

1. Is this feature going to be tariffed? Yes: No: X 2. Will this feature be optional?Yes: No: X If yes, how is optionality achieved (i.e.: packaging, datall, etc.)? 3. Will realtime used decrease or increase due to this feature? Decrease: Increase: No Change: X

4. Will there be a new or changed calltype as a result of this feature? New: Changed: Not Applicable: X

5.1.5

Comments

5.2

CM Design Finish Template

Not Applicable: Will there be a large impact to realtime? Yes: No:

ad7896rt.aa09

62 Real Time (RT)

Predict Output:

5.3

Design Test Template

If the entire Design Test Template does not apply to your feature, X Not Applicable. Not Applicable:

5.3.1

CM Feature Interaction Complete this template for all CM features impacting Call Processing. Does this feature impact the realtime of other Yes: No: features? If yes, for each feature impacted complete the following template: Feature: Testing Processor: Testing Tool Used: Insync? Yes: What causes the code to run?: Cost to the feature in ms:

No:

5.3.2

CM Direct Impact Only complete this template if the feature impacts CM Call Processing or Billing and will be tariffed. Answer the following 3 questions as appropriate. 1. Is the feature optional? Yes: No: If yes, complete the template below: How is optionality achieved (i.e.; packaging, datall, etc.)? Types of lines, trunks, or calls affected: What causes the code to run?

ad7896rt.aa09

Real Time (RT) 63

Testing Processor: Testing Tool Used: Insync? Yes: No: Cost of the optionality for the feature in ms:

2. Can the feature be assigned to a line or customer Yes: No: group? If yes, complete the template below: Testing Processor: Testing Tool Used: Insync? Yes: No: Types of lines/customer groups affected: Cost of feature present on line or cust grp (but not activated): ms Min: ms Max: Explain difference between Min and Max times:

3. Measure the cost of the feature. What function or use of the feature is being tested? Testing Processor: Testing Tool Used: Insync? Yes: Types of calls affected:

No:

Cost of feature characteristic described for the function or use of the feature above: ms Min: ms Max: Explain difference between Min and Max time: Comments:

5.3.3

CM Maintenance and Network Maintenance Show the time spent in Maintenance or Network Maintenance by this feature for each process affected.

ad7896rt.aa09

64 Real Time (RT)

Process: What are the triggers for your code to run? Briey describe the conditions under which the feature affects the realtime of the process: Testing Processor: Insync?Yes: Testing Tool: No:

1. If your feature is changing an existing process answer the following questions: What was the cost per transaction prior to your feature in ms: What is the cost per transaction including your feature in ms:

2. If your feature is creating a new process answer the following question: What is the cost per transaction in ms: List the variables that could impact the number of transactions per event: (This may include differences in datall, hardware, etc.) Comments:

5.3.4

XPM List the Task(s), Processor(s), and Priority(s) in which the feature code will run Task ProcessorTask Priority

If your work impacts tasks with a priority of 4 or greater, then answer the following questions. Only work done at priority of 4 and above should be included in the answers to these questions. 1. Does your code create a new call type?Yes: No:

ad7896rt.aa09

Real Time (RT) 65

If yes, for each new call type/XPM/processor combination complete the following template: Calltype: XPM Name: Processor Name: Timing method: Call timing (ms/orig): (ms/term):

2. Does your code create a new call processingYes: No: feature? If yes, for each new calltype/XPM/processor combination complete the following template for each processor impacted. Feature: Calltype: XPM Name: Processor name: Timing Method: Call Timing w/o activation(ms/orig): (ms/term): Call Timing with activation(ms/orig): (ms/term):

3. Does your code impact the call timing of a Yes: No: calltype (other than as reported above)? If yes, for each call type/XPM/processor combination impacted complete the following template. Calltype: XPM Name: Processor Name: Timing Method: Call timing w/o code in load(ms/orig): (ms/term):

ad7896rt.aa09

66 Real Time (RT)

Call Timing with code in load(ms/orig): (ms/term): Briey describe interaction:

4. Does your code impact overhead processor Yes: No: occupancy? (Run in the absence of call processing trafc and failure conditions) If yes, for each XPM impacted complete the following template: XPM Name: Processor Name: Timing Method: No load occupancy w/o code in load: (%) (Priority 4 and above) No load occupancy with code in load: (%) (Priority 4 and above) How would conguration/datall impact these results?

5. Is the impact of your code completely covered Yes: No: by the previous questions? If no, for each XPM/Processor combination complete the following template: XPM Name: Processor Name: When/how often does your code run?: When it runs, how much processing time does it use? (Include an explanation of the estimation technique and important variables.)

5.3.5

LPP The template for LPP is still under review. Until a formal template is provided, please comment below on all realtime issues this feature may have for the LPP. Please be as specic as possible and include methods of measurement in your descriptions.

ad7896rt.aa09

Real Time (RT) 67

ad7896rt.aa09

68 Real Time (RT)

ad7896rt.aa09

69

6. Design test plan (DT)

Activity Name ActID. Designer Name Designers Manager Tester Name Testers Manager Design Test Plan Review Date (yymmdd) SDCCH Handover & Directed Retry AD7896 Lena Yuan Pat Sollee Lih-en Shee Richie Brock 951117

Total Number of Testcases Total No. of Successful Testcases Total No. of Failed Testcases Total No. of Unexecuted Testcases Test Facilities Used Real Time Hours to Perform Testing (in hours)

18 18 0 0 HPSOS and Captive Office MSCs 150

6.1

Strategy
6.1.1 Test approach Testing of Feature AD7896 veries that all desired SDCCH & Directed Retry functionalities are implemented correctly and that no errors are introduced into the DMS-MSC software. Desired functionalities of Feature AD7896 is summarized by the following points:
ad7896dt.aa09

70 Design test plan (DT)

6.1.2

Basic Intra MSC SDCCH Handover. Restrict Inter MSC SDCCH Handover. Basic Intra MSC Directed Retry. Restrict Inter MSC Directed Retry.

Test exceptions None

6.2

Test requirements
6.2.1 Conguration diagrams Standard MSC lab conguration, including ANSI IBN7, IBNMF, and BSS Trunk agents. 6.2.2 Hardware requirements Standard DMS-MSC. 6.2.3 Data requirements None 6.2.4 Firmware requirements Not Applicable. 6.2.5 Tool requirements Tools required for testing include:
CALLTRAK GATE HPSOS HOHOHO LOGUTIL STEAM LIBRARY TOOL TEAM

6.3

Activity tests

ad7896dt.aa09

Design test plan (DT) 71

ad7896dt.aa09

72 Design test plan (DT)

#@Beginning of the formatted section in PLS. (Test cases below this line will be committed to the TC database when you use TCC COmmit. DO NOT COPY, DELETE OR CHANGE THIS PARAGRAPH).

ad7896dt.aa09

Design test plan (DT) 73 @TCID: 1 Status: This test case is not yet committed to the TC database Taskid:ad7896SOFT01 Type: PRSs: Result:S Load:GSM06ao Date:951117 TITLE: Assignment during Intra MSC-A SDCCH HO, after HO Req Ack

TEST CASE DESCRIPTION: This is a race condition between Assignment Request and Ho Request Ack. In this scenario, Assignment Request comes after Ho Request Ack, and gets queued. Verify that Assignment Request is sent out after the handover completes.
Setup:

t setup MS-> PET7 t Intra MSC-A handover during pre-assignment stage t Inject setup message after Ho Request Ack
Verify:

t Assignment gets queued and dequeued t Verify LAC & cell id in the billing record t verify speech t Verify calltrak indicates new software is being correctly invoked t No SWERRs t No unexpected Logs t No Traps

ad7896dt.aa09

74 Design test plan (DT) @TCID: 2 Status: This test case is not yet committed to the TC database Taskid:ad7896SOFT01 Type: PRSs: Result:S Load:GSM06ao Date:951117 TITLE: Ciphering during Intra MSC-A SDCCH HO, before HO Req Ack

TEST CASE DESCRIPTION: This is a race condition between Cipher Mode Command and Ho Request Ack. In this scenario, Cipher Mode Command comes before Ho Request Ack, and handover gets aborted.
Setup:

t Setup MS-MS t make sure Cipher Mode Command comes before Ho Request Ack
Verify:

t Verify handover gets aborted t Verify speech t No SWERRs t No unexpected Logs t No Traps

ad7896dt.aa09

Design test plan (DT) 75 @TCID: 3 Status: This test case is not yet committed to the TC database Taskid:ad7896SOFT01 Type: PRSs: Result:S Load:GSM06ao Date:951117 TITLE: Assignment during Intra MSC-A SDCCH HO, before HO Req Ack

TEST CASE DESCRIPTION: This is a race condition between Assignment Request and Ho Request Ack. In this scenario, Assignment Request comes before Ho Request Ack, and handover gets aborted.
Setup:

t Setup MS->PET7 t Send setup message before Ho Request Ack

Verify:

t Verify handover gets aborted t verify speech t No SWERRs t No unexpected Logs t No Traps

ad7896dt.aa09

76 Design test plan (DT) @TCID: 4 Status: This test case is not yet committed to the TC database Taskid:ad7896SOFT01 Type: PRSs: Result:S Load:GSM06ao Date:951117 TITLE: blocking A-Nodal SDCCH HO

TEST CASE DESCRIPTION: This testcase veries that Inter MSC-A handover gets blocked.
Setup:

t Setup MS->ANSI t Start Inter MSC-A SDCCH handover

Verify:

t Handover gets aborted t OM pegged t No SWERRs t No other unexpected Logs t No Traps

ad7896dt.aa09

Design test plan (DT) 77 @TCID: 5 Status: This test case is not yet committed to the TC database Taskid:ad7896SOFT01 Type: PRSs: Result:S Load:GSM06ao Date:951117 TITLE: Intra BSS Directed Retry without HOPERF

TEST CASE DESCRIPTION: This test case is to verify the successful IntraBSS directed retry.
Setup:

t Setup MS->MS t Include the new lac & cell id in the Assignment Complete message
Verify:

t Verify speech t Verify LAC & cell id in the billing record t OM pegged t No SWERRs t No other unexpected Logs t No Traps

ad7896dt.aa09

78 Design test plan (DT) @TCID: 6 Status: This test case is not yet committed to the TC database Taskid:ad7896SOFT01 Type: PRSs: Result:S Load:GSM06ao Date:951117 TITLE: Intra BSS Directed Retry with HOPERF

TEST CASE DESCRIPTION: This testcase is to verify the successful IntraBSS directed retry with the optional HOPERF message.
Setup:

t Setup MS->MS t Include the new lac & cell id in the HOPERF message
Verify:

t Verify speech t Verify LAC & cell id in the billing record t OM pegged t No SWERRs t No other unexpected Logs t No Traps

ad7896dt.aa09

Design test plan (DT) 79 @TCID: 7 Status: This test case is not yet committed to the TC database Taskid:ad7896SOFT01 Type: PRSs: Result:S Load:GSM06ao Date:951117 TITLE: Intra-MSC Directed Retry, TNT2 expires

TEST CASE DESCRIPTION: This testcase is to verify the call gets taken down when Intra MSC directed retry fails because of TNT2 expiry.
Setup:

t Setup MS-MS t start Intra MSC directed retry t let TNT2 expire (ex: not send HO required)
Verify:

t Call gets taken down t No SWERRs t No other unexpected Logs t No Traps

ad7896dt.aa09

80 Design test plan (DT) @TCID: 8 Status: This test case is not yet committed to the TC database Taskid:ad7896SOFT01 Type: PRSs: Result:S Load:GSM06ao Date:951117 TITLE: blocking B-Nodal SDCCH HO

TEST CASE DESCRIPTION: This testcase veries that B-Nodal handover gets blocked.
Setup:

t Start B-Nodal SDCCH handover

Verify:

t Handover gets aborted t No SWERRs t No other unexpected Logs t No Traps

ad7896dt.aa09

Design test plan (DT) 81 @TCID: 9 Status: This test case is not yet committed to the TC database Taskid:ad7896SOFT01 Type: PRSs: Result:S Load:GSM06ao Date:951117 TITLE: blocking B-Nodal directed retry

TEST CASE DESCRIPTION: This testcase veries that B-Nodal handover gets blocked.
Setup:

t Start B-Nodal directed retry

Verify:

t Handover gets aborted t Initial assignment on MSC-B is blocked t No SWERRs t No other unexpected Logs t No Traps

ad7896dt.aa09

82 Design test plan (DT) @TCID: 10 Status: This test case is not yet committed to the TC database Taskid:ad7896SOFT01 Type: PRSs: Result:S Load:GSM06ao Date:951117 TITLE: blocking A-Nodal directed retry

TEST CASE DESCRIPTION: This testcase veries that A-Nodal handover gets blocked.
Setup:

t Start A-Nodal directed retry

Verify:

t Handover gets aborted t Call gets taken down t No SWERRs t No other unexpected Logs t No Traps

ad7896dt.aa09

Design test plan (DT) 83 @TCID: 11 Status: This test case is not yet committed to the TC database Taskid:ad7896SOFT01 Type: PRSs: Result:S Load:GSM06ao Date:951117 TITLE: Successful Intra-MSC Directed Retry with the optional AFAIL

TEST CASE DESCRIPTION: This testcase is to verify an Intra-MSC Directed Retry with the optional AFAIL message.
Setup:

t Setup MS-MS t start Intra MSC directed retry t Include AFAIL[Directed Retry] in the message ow
Verify:

t Verify speech t Verify LAC & cell id in the billing record t OM pegged t No SWERRs t No other unexpected Logs t No Traps

ad7896dt.aa09

84 Design test plan (DT) @TCID: 12 Status: This test case is not yet committed to the TC database Taskid:ad7896SOFT01 Type: PRSs: Result:S Load:GSM06ao Date:951117 TITLE: Intra-MSC Directed Retry, get HO Fail instead of HO Req Ack

TEST CASE DESCRIPTION: This testcase is to verify the call gets taken down when Intra MSC directed retry fails HO Fail is received instead of HO Req Ack.
Setup:

t Setup MS-MS t start Intra MSC directed retry t Send HO Fail instead of HO Req Ack
Verify:

t Handover gets aborted t Call gets taken down t No SWERRs t No other unexpected Logs t No Traps

ad7896dt.aa09

Design test plan (DT) 85 @TCID: 13 Status: This test case is not yet committed to the TC database Taskid:ad7896SOFT01 Type: PRSs: Result:S Load:GSM06ao Date:951117 TITLE: Successful Intra-MSC Directed Retry without the optional AFAIL

TEST CASE DESCRIPTION: This testcase is to verify an Intra-MSC Directed Retry without the optional AFAIL message.
Setup:

t Setup MS-MS t start Intra MSC directed retry t Do not include AFAIL[Directed Retry] in the message ow
Verify:

t Verify speech t Verify LAC & cell id in the billing record t OM pegged t No SWERRs t No other unexpected Logs t No Traps

ad7896dt.aa09

86 Design test plan (DT) @TCID: 14 Status: This test case is not yet committed to the TC database Taskid:ad7896SOFT01 Type: PRSs: Result:S Load:GSM06ao Date:951117 TITLE: Successful Intra-MSC Directed Retry without Clear Complete

TEST CASE DESCRIPTION: This testcase is to verify an Intra-MSC Directed Retry without a clear complete message from the old BSS. The MSC considers this as a successful directed retry.
Setup:

t Setup MS-MS t start Intra MSC directed retry t Do not send Clear Complete from the old BSS
Verify:

t Verify speech t Verify LAC & cell id in the billing record t OM pegged t No SWERRs t No other unexpected Logs t No Traps

ad7896dt.aa09

Design test plan (DT) 87 @TCID: 15 Status: This test case is not yet committed to the TC database Taskid:ad7896SOFT01 Type: PRSs: Result:S Load:GSM06ao Date:951117 TITLE: Intra MSC SDCCH HO, SMS

TEST CASE DESCRIPTION: This testcase is to verify an Intra-MSC SDCCH HO for a SMS call.
Setup:

t Setup MS-MS, SMS t start Intra MSC SDCCH HO

Verify:

t Verify handover gets completed t Verify LAC & cell id in the billing record t SMS call stays alive t No SWERRs t No other unexpected Logs t No Traps

ad7896dt.aa09

88 Design test plan (DT) @TCID: 16 Status: This test case is not yet committed to the TC database Taskid:ad7896SOFT01 Type: PRSs: Result:S Load:GSM06ao Date:951117 TITLE: Intra-MSC Directed Retry with AFAIL[directed retry] but no directed retry cause in HO Required

TEST CASE DESCRIPTION: This testcase is to verify an Intra-MSC directed retry gets aborted if the directed retry cause in HO Required is missing after AFAIL[directed retry] is received.
Setup:

t Setup MS-MS, SMS t start Intra MSC directed retry t Send HO Required without the directed retry cause
Verify:

t Verify handover gets aborted t Verify call gets taken down t No SWERRs t No other unexpected Logs t No Traps

ad7896dt.aa09

Design test plan (DT) 89 @TCID: 17 Status: This test case is not yet committed to the TC database Taskid:ad7896SOFT01 Type: PRSs: Result:S Load:GSM06ao Date:951117 TITLE: CMM after an Intra MSC-A directed retry

TEST CASE DESCRIPTION: This testcase is to verify CMM after an Intra MSC-A directed retry.
Setup:

t Setup MS-MS t start Intra MSC directed retry t start CMM

Verify:

t Verify speech t Verify LAC & cell id in the billing record t OM pegged t No SWERRs t No other unexpected Logs t No Traps

ad7896dt.aa09

90 Design test plan (DT) @TCID: 18 Status: This test case is not yet committed to the TC database Taskid:ad7896SOFT01 Type: PRSs: Result:S Load:GSM06ao Date:951117 TITLE: directed retry after an assignment being retried

TEST CASE DESCRIPTION: This testcase is to verify an Intra MSC-A directed retry after an assignment is being retried.
Setup:

t Setup MS-MS t Retry Assignment t start Intra MSC directed retry

Verify:

t Verify speech t Verify LAC & cell id in the billing record t OM pegged t No SWERRs t No other unexpected Logs t No Traps

ad7896dt.aa09

91 Design test plan (DT)

ad7896dt.aa09

92 Design test plan (DT)

#@End of the formatted section in PLS. You can specify below (or in the test exceptions section) test cases that you do not want to commit to the TC database using TCC COmmit. DO NOT COPY, DELETE OR CHANGE THIS PARAGRAPH.

ad7896dt.aa09

93

ad7896.aa09.IX

94

ad7896.aa09.IX