CHANGE REQUEST 1 (4)

FORM
NET/RN/BSC

BSC CHANGE REQUEST

1. CHANGE INFORMATION

CR Title: Allowing common BCCH on EGSM BTS in multi band PGSM/EGSM segment

Nature of the Change:

Correction
Adding missing information
x Adding a new feature or function or parameter
Dropping a feature or function
Other ____

Originated by:
Standardization CR# ____
x Marketing (Customer)
Specification
Implementation
Testing
Release planning

Reason for the change: The BSC does not allow BCCH BTS on EGSM in a
segment of both PGSM and EGSM BTSs. This was originally to ensure that in a mixed
band configuration also the PGSM MSs have access to such a multi band cell.
However, the current behaviour of the BSC seems to be an unnecessary restriction.
There are cases where an operator has mainly EGSM frequencies and would like to
utilise this band for BCCH and still use also some additional PGSM frequencies in the
segment for traffic. This prevents the PGSM MSs from accessing cells with BCCH on
EGSM but it is up to the operator to ensure or not to ensure the access for the PGSM
terminals with an appropriate frequency configuration. And any mobiles that do not
support EGSM will now be very rare museum pieces.
In a PGSM/EGSM segment with BCCH BTS on EGSM the BSC uses a common CA list
for the GSM900 band resources. This leads to a restriction of max 16 frequencies on
a CA list whenever both PGSM and EGSM frequencies exist.

There is a related PDTool proposal: BSS20712 Common BCCH improvement, see

additional information section below. This CR relates also to another CR “Allowing
using of PGSM900 and EGSM900 frequencies in the same BTS-object when the
BCCH uses EGSM900 frequency” (PDTool proposal BSS20826 Common BCCH fail
recovery improvement).

Needed changes:

GUPDAT:
Currently, in BTS and TRX unlock procedures GUPDAT does not allow PGSM TRXs in
a segment if the BCCH of the segment is on EGSM. Similarly, GUPDAT does not
allow PGSM frequencies on MA, DFCA MA and DFCA unsynchronised mode MA list if
the BCCH of the segment is on EGSM and the respective hopping method is in use
Template version 1.6
 CHANGE REQUEST 2 (4)
FORM
NET/RN/BSC

in the segment. These checkings are now to be removed. In other words the change
means removing checkings that currently result in error code
egsm_bcch_and_pgsm_fr_in_seg_ec = 15788 and error text “EGSM BCCH
FREQUENCY AND PGSM FREQUENCY ARE NOT ALLOWED TO USE IN SAME
SEGMENT”.

ROLLER:
Similar checkings as in GUPDAT above are to be removed from ROLLER in
background database activation (check_background_data_r).
Additionally, when the BCCH of a segment is on EGSM, ROLLER includes all the
PGSM and EGSM frequencies of the segment to a common CA list that is used for all
the GSM900 BTSs of the segment.

RCSPRB:
The decisions where RCSPRB assumes PGSM resources of a segment automatically
as unusable due to BCCH on EGSM have to be changed.
In the case related to Common BCCH Control specific load based TCH handover
RCSPRB from now on examines also PGSM resource usability if PGSM resources
exist in the segment. When starting the handover from an EGSM BTS RCSPRB can
assume the PGSM resources automatically as usable for the MS in question.
As another change, from now on RCSPRB does not start any reservation duration
based SDCCH handover towards a PGSM BTS in a segment with BCCH on EGSM.

RRMPRB:
Traditionally, within a segment, RRMPRB in some cases prefers EGSM resources to
PGSM resources. From now on, in this new case of PGSM/EGSM segment with BCCH
on EGSM RRMPRB should not give any priority for EGSM resources. Instead, in this
case RRMPRB should treat EGSM and PGSM BTSs as equal resources in a segment.
In a segment with BCCH on EGSM and with additional PGSM resources there should
basically be no need to make load based TCH handovers between EGSM and PGSM
BTSs (in either direction). However, no actions are taken in RRMPRB to explicitly
prevent these handovers.

SYIPRB, AOMPRB and ABIPRB:

So far the use of 1024 range method in the coding of cell allocation (CA) frequency
list for system information messages has been necessary and allowed with
EGSM900 frequencies only and especially only when the frequency number 0 has
been included in the list. Now this is to be changed. Both PGSM900 and EGSM900
frequencies are to be allowed in a CA frequency list in a segment where there are
resources of both of these bands with the BCCH on EGSM900. In such a case the
1024 range method is always needed. In SYIPRB, AOMPRB and ABIPRB the related
procedures have to be modified to be more general and allow and adapt the use of
the 1024 range method when both PGSM900 and EGSM900 frequencies are
included irrespective of the use of frequency number 0.
This text for SYIPRB, AOMPRB and ABIPRB has been added as one part of the
correction for the failure report PR 21124ES09P (BSS20712: EGSM and PGSM
frequencies can't be in the same BTS object).

Template version 1.6

 CHANGE REQUEST 3 (4)
FORM
NET/RN/BSC

Impact to schedules: S11.5, Common BCCH Control

Change will affect the following customer documents: Common BCCH Control
in BSC

Change will affect the following Interface Specifications: No

Change will affect the following Network Element(s):

Network Element Committed Responsible person
[yes/no]
BSC [release] Yes
BTS [release] No
IMS GW [release] No Tero Pajunen
LMU [release] No
SGSN [release] No
NetAct [release] No Merja Hemmi
NetAct Planner [release] No Merja Hemmi
NetAct RAC (Radio Access No Merja Hemmi
Configurator) [release]
Transmission Planner No Merja Hemmi
[release]
Other ____ No

Change will affect packaging: No

Raised by: 15.6.2005 Jyrki Rämä, updated 24.8.2005

Updated 29.12.2005 by Jyrki Rämä: added missing information
on SYIPRB, AOMPRB and ABIPRB.

Additional information:

"Common BCCH proposal.htm

Missing.htm"

2. FILLED IN BY CHANGE MANAGER

CR ID: CD11.5_CR23

Checked by: [name and date]

FILLED WHEN CR IS APPROVED:

Approved by: [Name of the board or person and date. If there are
several alternatives how the change can be implemented, mention which one is
approved.]

Template version 1.6

 CHANGE REQUEST 4 (4)
FORM
NET/RN/BSC

Responsible Project Manager: [Name of Project Manager responsible for

planning and following the implementation of the change]

Change will affect the following RS/IS document(s): [document name, project
and name of the person responsible for implementing the change, target date when
ready]

Change will be implemented in the following build: [SW build number]

FILLED WHEN CR IS REJECTED:

Rejected by: [name of the board or person and date]

Reason for rejection:

Template version 1.6