CHAPTER 2PCU ARCHITECTURE
CHAPTER 3BSS/PCU COMMANDS AND
STATISTICS
CHAPTER 4PCU STATISTICS
CHAPTER 5GSN ARCHITECTURE
CHAPTER 1 GPRS REVIEW
CHAPTER 7SGSN STATISTICS
ATTRIBUTES
CHAPTER 8GGSN STATISTICS
ATTRIBUTES
CHAPTER 9APPENDIX
CHAPTER 10GLOSSARY
CHAPTER 6SGSN CONFIGURATION
PARAMETERS
�MOTOROLA LTD. 2000 GPRS01: GPRS Architecture
FOR TRAINING PURPOSES ONLY
i
ISSUE 1 REVISION 2
GPRS01GPRS Architecture
� Motorola 1993, 1994, 1995, 1996, 1997, 1998, 1999All Rights ReservedPrinted in the U.K.
ISSUE 1 REVISION 2
�MOTOROLA LTD. 2000GPRS01: GPRS Architecture
FOR TRAINING PURPOSES ONLY
ii
Copyrights, notices and trademarks
CopyrightsThe Motorola products described in this document may include copyrighted Motorola computerprograms stored in semiconductor memories or other media. Laws in the United States and othercountries preserve for Motorola certain exclusive rights for copyright computer programs, including theexclusive right to copy or reproduce in any form the copyright computer program. Accordingly, anycopyright Motorola computer programs contained in the Motorola products described in this documentmay not be copied or reproduced in any manner without the express written permission of Motorola.Furthermore, the purchase of Motorola products shall not be deemed to grant either directly or byimplication, estoppel or otherwise, any license under the copyrights, patents or patent applications ofMotorola, except for the rights that arise by operation of law in the sale of a product.
RestrictionsThe software described in this document is the property of Motorola. It is furnished under a licenseagreement and may be used and/or disclosed only in accordance with the terms of the agreement.Software and documentation are copyright materials. Making unauthorized copies is prohibited bylaw. No part of the software or documentation may be reproduced, transmitted, transcribed, storedin a retrieval system, or translated into any language or computer language, in any form or by anymeans, without prior written permission of Motorola.
AccuracyWhile reasonable efforts have been made to assure the accuracy of this document, Motorolaassumes no liability resulting from any inaccuracies or omissions in this document, or from the useof the information obtained herein. Motorola reserves the right to make changes to any productsdescribed herein to improve reliability, function, or design, and reserves the right to revise thisdocument and to make changes from time to time in content hereof with no obligation to notify anyperson of revisions or changes. Motorola does not assume any liability arising out of the applicationor use of any product or circuit described herein; neither does it convey license under its patentrights of others.
Trademarks
and MOTOROLA are trademarks of Motorola Inc.UNIX is a registered trademark in the United States and other countries, licensed exclusively throughX/Open Company Limited.Tandem , Integrity , Integrity S2 , and Non-Stop-UX are trademarks of Tandem ComputersIncorporated.X Window System , X and X11 are trademarks of the Massachusetts Institute of Technology.Looking Glass is a registered trademark of Visix Software Ltd.OSF/Motif is a trademark of the Open Software Foundation.Ethernet is a trademark of the Xerox Corporation.Wingz is a trademark and INFORMIX is a registered trademark of Informix Software Ltd.SUN, SPARC, and SPARCStation are trademarks of Sun Microsystems Computer Corporation.IBM is a registered trademark of International Business Machines Corporation.HP is a registered trademark of Hewlett Packard Inc.
ISSUE 1 REVISION 2 General information
�MOTOROLA LTD. 2000 GPRS01: GPRS Architecture
FOR TRAINING PURPOSES ONLY
1
General information
Important notice
If this manual was obtained when you attended a Motorola training course, it will not beupdated or amended by Motorola. It is intended for TRAINING PURPOSES ONLY. If itwas supplied under normal operational circumstances, to support a major softwarerelease, then corrections will be supplied automatically by Motorola in the form ofGeneral Manual Revisions (GMRs).
Purpose
Motorola Global System for Mobile Communications (GSM) Technical Education manualsare intended to support the delivery of Technical Education only and are not intended toreplace the use of Customer Product Documentation.
Failure to comply with Motorola’s operation, installation and maintenanceinstructions may, in exceptional circumstances, lead to serious injury or death.
WARNING
These manuals are not intended to replace the system and equipment training offered byMotorola, although they can be used to supplement and enhance the knowledge gainedthrough such training.
ISSUE 1 REVISION 2General information
�MOTOROLA LTD. 2000GPRS01: GPRS Architecture
FOR TRAINING PURPOSES ONLY
2
Cross references
Throughout this manual, cross references are made to the chapter numbers and sectionnames. The section name cross references are printed bold in text.
This manual is divided into uniquely identified and numbered chapters that, in turn, aredivided into sections. Sections are not numbered, but are individually named at the topof each page, and are listed in the table of contents.
Text conventions
The following conventions are used in the Motorola GSM manuals to represent keyboardinput text, screen output text and special key sequences.
Input
Characters typed in at the keyboard are shown like this.
Output
Messages, prompts, file listings, directories, utilities, and environmentalvariables that appear on the screen are shown like this.
Special key sequences
Special key sequences are represented as follows:
CTRL–c Press the Control and c keys at the same time.
ALT–f Press the Alt and f keys at the same time.
| Press the pipe symbol key.
CR or RETURN Press the Return (Enter) key. The Return key isidentified with the ↵ symbol on both the X terminal andthe SPARCstation keyboards. The SPARCstationkeyboard Return key is also identified with the wordReturn.
ISSUE 1 REVISION 2 First aid in case of electric shock
�MOTOROLA LTD. 2000 GPRS01: GPRS Architecture
FOR TRAINING PURPOSES ONLY
3
First aid in case of electric shock
Warning
Do not touch the victim with your bare hands until the electric circuit isbroken.Switch off. If this is not possible, protect yourself with dry insulatingmaterial and pull or push the victim clear of the conductor.
WARNING
Artificialrespiration
In the event of an electric shock it may be necessary to carry out artificial respiration.Send for medical assistance immediately.
Burns treatment
A warning is used to alert the reader to possible hazards that could cause loss of life,physical injury, or ill health. This includes hazards introduced during maintenance, forexample, the use of adhesives and solvents, as well as those inherent in the equipment.
1. Do not attempt to remove clothing adhering to the burn.
2. If help is available, or as soon as artificial respiration is no longer required, coverthe wound with a dry dressing.
3. Do not apply oil or grease in any form.
ISSUE 1 REVISION 2Reporting safety issues
�MOTOROLA LTD. 2000GPRS01: GPRS Architecture
FOR TRAINING PURPOSES ONLY
4
Reporting safety issues
Introduction
A caution means that there is a possibility of damage to systems, or individual items ofequipment within a system. However, this presents no danger to personnel.
Procedure
Whenever a safety issue arises:
1. Make the equipment concerned safe, for example, by removing power.
2. Make no further attempt to tamper with the equipment.
3. Report the problem directly to GSM Customer Network Resolution Centre+44 (0)1793 430040 (telephone) and follow up with a written report by fax+44 (0)1793 430987 (fax).
4. Collect evidence from the equipment under the guidance of the Customer NetworkResolution Centre.
ISSUE 1 REVISION 2 Warnings and cautions
�MOTOROLA LTD. 2000 GPRS01: GPRS Architecture
FOR TRAINING PURPOSES ONLY
5
Warnings and cautions
Introduction
The following describes how warnings and cautions are used in this manual and in allmanuals of the Motorola GSM manual set.
Warnings
Definition
A warning is used to alert the reader to possible hazards that could cause loss of life,physical injury, or ill health. This includes hazards introduced during maintenance, forexample, the use of adhesives and solvents, as well as those inherent in the equipment.
Example and format
Do not look directly into fibre optic cables or optical data in/out connectors.Laser radiation can come from either the data in/out connectors orunterminated fibre optic cables connected to data in/out connectors.
WARNING
Cautions
Definition
A caution means that there is a possibility of damage to systems, or individual items ofequipment within a system. However, this presents no danger to personnel.
Example and format
Do not use test equipment that is beyond its calibration due date when testingMotorola base stations.
CAUTION
ISSUE 1 REVISION 2General warnings
�MOTOROLA LTD. 2000GPRS01: GPRS Architecture
FOR TRAINING PURPOSES ONLY
6
General warnings
Introduction
Observe the following warnings during all phases of operation, installation andmaintenance of the equipment described in the Motorola GSM manuals. Failure tocomply with these warnings, or with specific warnings elsewhere in the Motorola GSMmanuals, violates safety standards of design, manufacture and intended use of theequipment. Motorola assumes no liability for the customer’s failure to comply with theserequirements.
Warning labelsPersonnel working with or operating Motorola equipment must comply with any warninglabels fitted to the equipment. Warning labels must not be removed, painted over orobscured in any way.
Specificwarnings
Warnings particularly applicable to the equipment are positioned on the equipment andwithin the text of this manual. These must be observed by all personnel at all times whenworking with the equipment, as must any other warnings given in text, on the illustrationsand on the equipment.
High voltageCertain Motorola equipment operates from a dangerous high voltage of 230 V ac singlephase or 415 V ac three phase mains which is potentially lethal. Therefore, the areaswhere the ac mains power is present must not be approached until the warnings andcautions in the text and on the equipment have been complied with.
To achieve isolation of the equipment from the ac supply, the mains input isolator mustbe set to off and locked.
Within the United Kingdom (UK) regard must be paid to the requirements of theElectricity at Work Regulations 1989. There may also be specific country legislationwhich need to be complied with, depending on where the equipment is used.
RF radiationHigh RF potentials and electromagnetic fields are present in the base station equipmentwhen in operation. Ensure that all transmitters are switched off when any antennaconnections have to be changed. Do not key transmitters connected to unterminatedcavities or feeders.
Refer to the following standards:
� ANSI IEEE C95.1-1991, IEEE Standard for Safety Levels with Respect to HumanExposure to Radio Frequency Electromagnetic Fields, 3kHz to 300GHz.
� CENELEC 95 ENV 50166-2, Human Exposure to Electromagnetic Fields HighFrequency (10kHz to 300GHz).
Laser radiationDo not look directly into fibre optic cables or optical data in/out connectors. Laserradiation can come from either the data in/out connectors or unterminated fibre opticcables connected to data in/out connectors.
ISSUE 1 REVISION 2 General warnings
�MOTOROLA LTD. 2000 GPRS01: GPRS Architecture
FOR TRAINING PURPOSES ONLY
7
Liftingequipment
When dismantling heavy assemblies, or removing or replacing equipment, the competentresponsible person must ensure that adequate lifting facilities are available. Whereprovided, lifting frames must be used for these operations. When equipments have to bemanhandled, reference must be made to the Manual Handling of Loads Regulations1992 (UK) or to the relevant manual handling of loads legislation for the country in whichthe equipment is used.
Do not ...... substitute parts or modify equipment.
Because of the danger of introducing additional hazards, do not install substitute parts orperform any unauthorized modification of equipment. Contact Motorola if in doubt toensure that safety features are maintained.
Battery supplies
Do not wear earth straps when working with standby battery supplies.
Toxic material
Certain Motorola equipment incorporates components containing the highly toxic materialBeryllium or its oxide Beryllia or both. These materials are especially hazardous if:
� Beryllium materials are absorbed into the body tissues through the skin, mouth, ora wound.
� The dust created by breakage of Beryllia is inhaled.
� Toxic fumes are inhaled from Beryllium or Beryllia involved in a fire.
See the Beryllium health and safety precautions section for further information.
ISSUE 1 REVISION 2Human exposure to radio frequency energy (PCS1900 only)
�MOTOROLA LTD. 2000GPRS01: GPRS Architecture
FOR TRAINING PURPOSES ONLY
8
Human exposure to radio frequency energy (PCS1900 only)
IntroductionThis equipment is designed to generate and radiate radio frequency (RF) energy. Itshould be installed and maintained only by trained technicians. Licensees of the FederalCommunications Commission (FCC) using this equipment are responsible for insuringthat its installation and operation comply with FCC regulations designed to limit humanexposure to RF radiation in accordance with the American National Standards InstituteIEEE Standard C95.1-1991, IEEE Standard for Safety Levels with Respect to HumanExposure to Radio Frequency Electromagnetic Fields, 3kHz to 300GHz.
DefinitionsThis standard establishes two sets of maximum permitted exposure limits, one forcontrolled environments and another, that allows less exposure, for uncontrolledenvironments. These terms are defined by the standard, as follows:
Uncontrolled environment
Uncontrolled environments are locations where there is the exposure of individuals whohave no knowledge or control of their exposure. The exposures may occur in livingquarters or workplaces where there are no expectations that the exposure levels mayexceed those shown for uncontrolled environments in the table of maximum permittedexposure ceilings.
Controlled environmentControlled environments are locations where there is exposure that may be incurred bypersons who are aware of the potential for exposure as a concomitant of employment, byother cognizant persons, or as the incidental result of transient passage through areaswhere analysis shows the exposure levels may be above those shown for uncontrolledenvironments but do not exceed the values shown for controlled environments in thetable of maximum permitted exposure ceilings.
Maximumpermittedexposures
The maximum permitted exposures prescribed by the standard are set in terms ofdifferent parameters of effects, depending on the frequency generated by the equipmentin question. At the frequency range of this Personal Communication System equipment,1930-1970MHz, the maximum permitted exposure levels are set in terms of powerdensity, whose definition and relationship to electric field and magnetic field strengths aredescribed by the standard as follows:
Power density (S)
Power per unit area normal to the direction of propagation, usually expressed in units ofwatts per square metre (W/m2) or, for convenience, units such as milliwatts per squarecentimetre (mW/cm2). For plane waves, power density, electric field strength (E) andmagnetic field strength (H) are related by the impedance of free space, 377 ohms. Inparticular,
� ���
���� ���� ��
where E and H are expressed in units of V/m and A/m, respectively, and S in units ofW/m2. Although many survey instruments indicate power density units, the actualquantities measured are E or E2 or H or H2.
ISSUE 1 REVISION 2 Human exposure to radio frequency energy (PCS1900 only)
�MOTOROLA LTD. 2000 GPRS01: GPRS Architecture
FOR TRAINING PURPOSES ONLY
9
Maximumpermittedexposureceilings
Within the frequency range, the maximum permitted exposure ceiling for uncontrolledenvironments is a power density (mW/cm2) that equals f/1500, where f is the frequencyexpressed in MHz, and measurements are averaged over a period of 30 minutes. Themaximum permitted exposure ceiling for controlled environments, also expressed inmW/cm2, is f/300 where measurements are averaged over 6 minutes. Applying theseprinciples to the minimum and maximum frequencies for which this equipment is intendedto be used yields the following maximum permitted exposure levels:
Uncontrolled Environment Controlled Environment
1930MHz 1970MHz 1930MHz 1970MHz
Ceiling 1.287mW/cm2 1.313mW/cm2 6.433mW/cm2 6.567mW/cm2
If you plan to operate the equipment at more than one frequency, compliance should beassured at the frequency which produces the lowest exposure ceiling (among thefrequencies at which operation will occur).
Licensees must be able to certify to the FCC that their facilities meet the above ceilings.Some lower power PCS devices, 100 milliwatts or less, are excluded from demonstratingcompliance, but this equipment operates at power levels orders of magnitude higher, andthe exclusion is not applicable.
Whether a given installation meets the maximum permitted exposure ceilings depends, inpart, upon antenna type, antenna placement and the output power to which thisequipment is adjusted. The following example sets forth the distances from the antennato which access should be prevented in order to comply with the uncontrolled andcontrolled environment exposure limits as set forth in the ANSI IEEE standards andcomputed above.
ISSUE 1 REVISION 2Human exposure to radio frequency energy (PCS1900 only)
�MOTOROLA LTD. 2000GPRS01: GPRS Architecture
FOR TRAINING PURPOSES ONLY
10
Examplecalculation
For a base station with the following characteristics, what is the minimum distance fromthe antenna necessary to meet the requirements of an uncontrolled environment?
Transmit frequency 1930MHz
Base station cabinet output power, P +39.0dBm (8 watts)
Antenna feeder cable loss, CL 2.0dB
Antenna input power Pin P–CL = +39.0–2.0 = +37.0dB (5watts)
Antenna gain, G 16.4dBi (43.65)
Using the following relationship:
� ������
���
Where W is the maximum permissible power density in W/m2 and r is the safe distancefrom the antenna in metres, the desired distance can be calculated as follows:
� �����
���� �
������ �
��� ������ � �����
where W = 12.87 W/m2 was obtained from table listed above and converting frommW/cm2 to W/m2.
The above result applies only in the direction of maximum radiation of theantenna. Actual installations may employ antennas that have defined radiationpatterns and gains that differ from the example set forth above. The distancescalculated can vary depending on the actual antenna pattern and gain.
NOTE
Power densitymeasurements
While installation calculations such as the above are useful and essential in planning anddesign, validation that the operating facility using this equipment actually complies willrequire making power density measurements. For information on measuring RF fields fordetermining compliance with ANSI IEEE C95.1-1991, see IEEE Recommended Practicefor the Measure of Potentially Hazardous Electromagnetic Fields - RF and Microwave,IEEE Std C95.3-1991. Copies of IEEE C95.1-1991 and IEEE C95.3-1991 may bepurchased from the Institute of Electrical and Electronics Engineers, Inc., Attn:Publication Sales, 445 Hoes Lane, P.O. Box 1331, Piscattaway, NJ 08855-1331,(800) 678-IEEE or from ANSI, (212) 642-4900. Persons responsible for installation of thisequipment are urged to consult these standards in determining whether a giveninstallation complies with the applicable limits.
Other equipmentWhether a given installation meets ANSI standards for human exposure to radiofrequency radiation may depend not only on this equipment but also on whether theenvironments being assessed are being affected by radio frequency fields from otherequipment, the effects of which may add to the level of exposure. Accordingly, the overallexposure may be affected by radio frequency generating facilities that exist at the timethe licensee’s equipment is being installed or even by equipment installed later.Therefore, the effects of any such facilities must be considered in site selection and indetermining whether a particular installation meets the FCC requirements.
ISSUE 1 REVISION 2 Beryllium health and safety precautions
�MOTOROLA LTD. 2000 GPRS01: GPRS Architecture
FOR TRAINING PURPOSES ONLY
11
Beryllium health and safety precautions
Introduction
Beryllium (Be), is a hard silver/white metal. It is stable in air, but burns brilliantly inOxygen.
With the exception of the naturally occurring Beryl ore (Beryllium Silicate), all Berylliumcompounds and Beryllium metal are potentially highly toxic.
Health issues
Beryllium Oxide is used within some components as an electrical insulator. Captive withinthe component it presents no health risk whatsoever. However, if the component shouldbe broken open and the Beryllium Oxide, which is in the form of dust, released, thereexists the potential for harm.
Inhalation
Inhalation of Beryllium Oxide can lead to a condition known as Berylliosis, the symptomsof Berylliosis are similar to Pneumonia and may be identified by all or any of thefollowing:
Mild poisoning causes fever, shortness of breath, and a cough that producesyellow/green sputum, or occasionally bloodstained sputum. Inflammation of the mucousmembranes of the nose, throat, and chest with discomfort, possibly pain, and difficultywith swallowing and breathing.
Severe poisoning causes chest pain and wheezing which may progress to severeshortness of breath due to congestion of the lungs. Incubation period for lung symptomsis 2-20 days.
Exposure to moderately high concentrations of Beryllium in air may produce a veryserious condition of the lungs. The injured person may become blue, feverish with rapidbreathing and raised pulse rate. Recovery is usual but may take several months. Therehave been deaths in the acute stage.
Chronic response. This condition is more truly a general one although the lungs aremainly affected. There may be lesions in the kidneys and the skin. Certain featuressupport the view that the condition is allergic. There is no relationship between thedegree of exposure and the severity of response and there is usually a time lag of up to10 years between exposure and the onset of the illness. Both sexes are equallysusceptible. The onset of the illness is insidious but only a small number of exposedpersons develop this reaction.
First aid
Seek immediate medical assistance. The casualty should be removed immediately fromthe exposure area and placed in a fresh air environment with breathing supported withOxygen where required. Any contaminated clothing should be removed. The casualtyshould be kept warm and at rest until medical aid arrives.
ISSUE 1 REVISION 2Beryllium health and safety precautions
�MOTOROLA LTD. 2000GPRS01: GPRS Architecture
FOR TRAINING PURPOSES ONLY
12
Skin contact
Possible irritation and redness at the contact area. Persistent itching and blisterformations can occur which usually resolve on removal from exposure.
First aid
Wash area thoroughly with soap and water. If skin is broken seek immediate medicalassistance.
Eye contact
May cause severe irritation, redness and swelling of eyelid(s) and inflammation of themucous membranes of the eyes.
First aid
Flush eyes with running water for at least 15 minutes. Seek medical assistance as soonas possible.
Handlingprocedures
Removal of components from printed circuit boards (PCBs) is to take place only atMotorola approved repair centres.
The removal station will be equipped with extraction equipment and all other protectiveequipment necessary for the safe removal of components containing Beryllium Oxide.
If during removal a component is accidently opened, the Beryllium Oxide dust is to bewetted into a paste and put into a container with a spatula or similar tool. The spatula/toolused to collect the paste is also to be placed in the container. The container is then to besealed and labelled. A suitable respirator is to be worn at all times during this operation.
Components which are successfully removed are to be placed in a separate bag, sealedand labelled.
Disposalmethods
Beryllium Oxide or components containing Beryllium Oxide are to be treated ashazardous waste. All components must be removed where possible from boards and putinto sealed bags labelled Beryllium Oxide components. These bags must be given to thesafety and environmental adviser for disposal.
Under no circumstances are boards or components containing Beryllium Oxide to be putinto the general waste skips or incinerated.
Product life cycleimplications
Motorola GSM and analogue equipment includes components containing Beryllium Oxide(identified in text as appropriate and indicated by warning labels on the equipment).These components require specific disposal measures as indicated in the preceding(Disposal methods) paragraph. Motorola will arrange for the disposal of all suchhazardous waste as part of its Total Customer Satisfaction philosophy and will arrangefor the most environmentally ‘friendly’ disposal available at that time.
ISSUE 1 REVISION 2 General cautions
�MOTOROLA LTD. 2000 GPRS01: GPRS Architecture
FOR TRAINING PURPOSES ONLY
13
General cautions
Introduction
Observe the following cautions during operation, installation and maintenance of theequipment described in the Motorola GSM manuals. Failure to comply with thesecautions or with specific cautions elsewhere in the Motorola GSM manuals may result indamage to the equipment. Motorola assumes no liability for the customer’s failure tocomply with these requirements.
Caution labels
Personnel working with or operating Motorola equipment must comply with any cautionlabels fitted to the equipment. Caution labels must not be removed, painted over orobscured in any way.
Specific cautions
Cautions particularly applicable to the equipment are positioned within the text of thismanual. These must be observed by all personnel at all times when working with theequipment, as must any other cautions given in text, on the illustrations and on theequipment.
Fibre optics
The bending radius of all fibre optic cables must not be less than 30 mm.
Static discharge
Motorola equipment contains CMOS devices that are vulnerable to static discharge.Although the damage caused by static discharge may not be immediately apparent,CMOS devices may be damaged in the long term due to static discharge caused bymishandling. Wear an approved earth strap when adjusting or handling digital boards.
See Devices sensitive to static for further information.
ISSUE 1 REVISION 2Devices sensitive to static
�MOTOROLA LTD. 2000GPRS01: GPRS Architecture
FOR TRAINING PURPOSES ONLY
14
Devices sensitive to static
Introduction
Certain metal oxide semiconductor (MOS) devices embody in their design a thin layer ofinsulation that is susceptible to damage from electrostatic charge. Such a charge appliedto the leads of the device could cause irreparable damage.
These charges can be built up on nylon overalls, by friction, by pushing the hands intohigh insulation packing material or by use of unearthed soldering irons.
MOS devices are normally despatched from the manufacturers with the leads shortedtogether, for example, by metal foil eyelets, wire strapping, or by inserting the leads intoconductive plastic foam. Provided the leads are shorted it is safe to handle the device.
Special handlingtechniques
In the event of one of these devices having to be replaced observe the followingprecautions when handling the replacement:
� Always wear an earth strap which must be connected to the electrostatic point(ESP) on the equipment.
� Leave the short circuit on the leads until the last moment. It may be necessary toreplace the conductive foam by a piece of wire to enable the device to be fitted.
� Do not wear outer clothing made of nylon or similar man made material. A cottonoverall is preferable.
� If possible work on an earthed metal surface. Wipe insulated plastic work surfaceswith an anti-static cloth before starting the operation.
� All metal tools should be used and when not in use they should be placed on anearthed surface.
� Take care when removing components connected to electrostatic sensitivedevices. These components may be providing protection to the device.
When mounted onto printed circuit boards (PCBs), MOS devices are normally lesssusceptible to electrostatic damage. However PCBs should be handled with care,preferably by their edges and not by their tracks and pins, they should be transferreddirectly from their packing to the equipment (or the other way around) and never leftexposed on the workbench.
ISSUE 1 REVISION 2 Motorola GSM manual set
�MOTOROLA LTD. 2000 GPRS01: GPRS Architecture
FOR TRAINING PURPOSES ONLY
15
Motorola GSM manual set
Introduction
The following manuals provide the information needed to operate, install and maintain theMotorola GSM equipment.
Generic manuals
The following are the generic manuals in the GSM manual set, these manuals arerelease dependent:
Classificationnumber Name Order number
GSM-100-101 System Information: General 68P02901W01. . . . . . . . . . . . . . . . . . . GSM-100-201 Operating Information: GSM System Operation 68P02901W14. . . GSM-100-202 Operating Information: Scaleable OMC System
Administration 68P02901W19. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . GSM-100-311 Technical Description: OMC in a GSM System 68P02901W31. . . . GSM-100-313 Technical Description: OMC Database Schema 68P02901W34. . . GSM-100-320 Technical Description: BSS Implementation 68P02901W36. . . . . . . GSM-100-321 Technical Description: BSS Command Reference 68P02901W23. GSM-100-403 Installation & Configuration: GSM System
Configuration 68P02901W17. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . GSM-100-423 Installation & Configuration: BSS Optimization 68P02901W43. . . . GSM-100-413 Installation & Configuration: Scaleable OMC
Clean Install 68P02901W47. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . GSM-100-501 Maintenance Information: Alarm Handling at
the OMC 68P02901W26. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . GSM-100-520 Maintenance Information: BSS Timers 68P02901W58. . . . . . . . . . . GSM-100-521 Maintenance Information: Device State Transitions 68P02901W57GSM-100-523 Maintenance Information: BSS Field
Troubleshooting 68P02901W51. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . GSM-100-503 Maintenance Information: GSM Statistics
Application 68P02901W56. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . GSM-100-721 Software Release Notes: BSS/RXCDR 68P02901W72. . . . . . . . . . GSM-100-712 Software Release Notes: Scaleable OMC System 68P02901W74.
Index of Operations 68P02900W81. . . . . . . . . . . . . . . . . . . . . . . . . . .
Related manuals
The following are related Motorola GSM manuals:
Classificationnumber Name Order number
GSM-001-103 System Information: BSS Equipment Planning 68P02900W21. . . . GSM-002-103 System Information: DataGen 68P02900W22. . . . . . . . . . . . . . . . . . GSM-002-703 Software Release Notes: DataGen 68P02900W76. . . . . . . . . . . . . . GSM-005-103 System Information: Advance Operational Impact 68P02900W25. GSM-008-403 Installation & Configuration: Network Health Analyst 68P02900W36GSM-008-703 Software Release Notes: Network Health Analyst 68P02900W77. GSM-006-202 Operating Information: OMC System
Administration (OSI) 68P02901W10. . . . . . . . . . . . . . . . . . . . . . . . . . GSM-006-413 Installation & Configuration: OSI Clean Install 68P02901W39. . . . . GSM-006-712 Software Release Notes: OMC OSI System 68P02901W70. . . . . .
ISSUE 1 REVISION 2Motorola GSM manual set
�MOTOROLA LTD. 2000GPRS01: GPRS Architecture
FOR TRAINING PURPOSES ONLY
16
Service manuals
The following are the service manuals in the GSM manual set, these manuals are notrelease dependent. The internal organization and makeup of service manual sets mayvary, they may consist of from one to four separate manuals, but they can all be orderedusing the overall catalogue number shown below:
Classificationnumber Name Order number
GSM-100-020 Service Manual: BTS 68P02901W37. . . . . . . . . . . . . . . . . . . . . . . . . . GSM-100-030 Service Manual: BSC/RXCDR 68P02901W38. . . . . . . . . . . . . . . . . . GSM-105-020 Service Manual: M-Cell2 68P02901W75. . . . . . . . . . . . . . . . . . . . . . . GSM-106-020 Service Manual: M-Cell6 68P02901W85. . . . . . . . . . . . . . . . . . . . . . . GSM-201-020 Service Manual: M-Cellcity 68P02901W95. . . . . . . . . . . . . . . . . . . . . GSM-202-020 Service Manual: M-Cellaccess 68P02901W65. . . . . . . . . . . . . . . . . . GSM-203-020 Service Manual: M-Cellarena 68P02902W36. . . . . . . . . . . . . . . . . . . GSM-206-020 Service Manual: M-Cellarenamacro 68P02902W15. . . . . . . . . . . . . . . GSM-205-020 Service Manual: Horizonmacro Indoor 68P02902W06. . . . . . . . . . . GSM-204-020 Service Manual: Horizonmacro Outdoor 68P02902W12. . . . . . . . . . GSM-207-020 Service Manual: Horizonoffice 68P02902W46. . . . . . . . . . . . . . . . . . GSM-101-SERIES ExCell4 Documentation Set 68P02900W50. . . . . . . . . . . . . . . . . . . . GSM-103-SERIES ExCell6 Documentation Set 68P02900W70. . . . . . . . . . . . . . . . . . . . GSM-102-SERIES TopCell Documentation Set (GSM900) 68P02901W80. . . . . . . . . . . GSM-104-SERIES TopCell Documentation Set (DCS1800) 68P02902W80. . . . . . . . . . GSM-200-SERIES M-Cellmicro Documentation Set 68P02901W90. . . . . . . . . . . . . . . . .
Classificationnumber
The classification number is used to identify the type and level of a manual. For example,manuals with the classification number GSM-100-2xx contain operating information.
Order number
The Motorola 68P order (catalogue) number is used to order manuals.
Orderingmanuals
All orders for Motorola manuals must be placed with your Motorola Local Office orRepresentative. Manuals are ordered using the order (catalogue) number. Remember,specify the manual issue required by quoting the correct suffix letter.
ISSUE 1 REVISION 2 GMR amendment
�MOTOROLA LTD. 2000 GPRS01: GPRS Architecture
FOR TRAINING PURPOSES ONLY
17
GMR amendment
Introduction toGMRs
Changes to a manual that occur after the printing date are incorporated into the manualusing General Manual Revisions (GMRs). GMRs are issued to correct Motorola manualsas and when required. A GMR has the same identity as the target manual. Each GMR isidentified by a number in a sequence that starts at 01 for each manual at each issue.GMRs are issued in the form of loose leaf pages, with a pink instruction sheet on thefront.
GMR procedure
When a GMR is received, check on the GMR amendment record page of this manualthat previous GMRs, if any, have been incorporated. If not, contact your administrator orMotorola Local Office to obtain the missing GMRs. Remove and replace pages in thismanual, as detailed on the GMR pink instruction sheet.
ISSUE 1 REVISION 2GMR amendment record
�MOTOROLA LTD. 2000GPRS01: GPRS Architecture
FOR TRAINING PURPOSES ONLY
18
GMR amendment record
Instructions
When a GMR is inserted in this manual, the amendment record below must be filled in torecord the insertion. Retain the pink instruction sheet that accompanies each GMR andinsert it in a suitable place in this manual for future reference.
Amendmentrecord
Record the insertion of GMRs in this manual in the following table:
GMR number Incorporated by (signature) Date
01
02
03
04
05
06
07
08
09
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
ISSUE 1 REVISION 2 GMR amendment record
�MOTOROLA LTD. 2000 GPRS01: GPRS Architecture
FOR TRAINING PURPOSES ONLY
19
ISSUE 1 REVISION 2
�MOTOROLA LTD. 2000 GPRS01: GPRS Architecture
FOR TRAINING PURPOSES ONLY
iii
Chapter 1GPRS Review i. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Objectives 1–1. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
GPRS Network Overview 1–2. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . The GPRS Support Node Network (GSN) 1–2. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . OMC–G 1–2. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . The Base Station System (BSS) 1–2. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . The Mobile Station (MS) 1–2. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
GPRS Application Protocols 1–4. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Base Station System GPRS Protocol (BSSGP) 1–4. . . . . . . . . . . . . . . . . . . . . . . . . . . Logical Link Control (LLC) 1–4. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Subnetwork Dependant Convergence Protocol (SNDCP) 1–4. . . . . . . . . . . . . . . . . . . Network Service (NS) 1–6. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . GPRS Tunnelling Protocol (GTP) 1–6. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Internet Protocol (IP) 1–6. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . User Datagram Protocol/Transmission Control Protocol (UDP/TCP) 1–6. . . . . . . . . .
GPRS Review 1–8. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . System Overview 1–8. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . GPRS 52 Multiframe 1–10. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Um Air Interface 1–12. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Timeslot Configuration 1–14. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Packet Traffic Channels 1–16. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . MS Classes with Multislot Capability 1–18. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Fixed Allocation Timeslot Assignment 1–20. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Mobility Management 1–22. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Timing Advance 1–24. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Continuous Timing Advance 1–26. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Mobile Originated Packet Transfer 1–28. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Downlink Mobile Terminated Packet Transfer 1–30. . . . . . . . . . . . . . . . . . . . . . . . . . . . . Uplink Packet Transfer 1–32. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Mobile Terminated Packet Transfer 1–34. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Radio Link Control (RLC) 1–36. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . RLC Data ACK/NACK 1–38. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Release of Uplink 1–40. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . GPRS Attach 1–42. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . GPRS Detach 1–46. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Paging for GPRS Downlink Transfer 1–48. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . PDP Context Activation 1–50. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . PDP Context Modification Procedure 1–54. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . PDP Context Deactivation 1–54. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . PDP Context Deactivation Initiated by GGSN Procedure 1–54. . . . . . . . . . . . . . . . . . . Routing Area Update Procedure 1–56. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Combined RA/LA Update in the case of Inter SGSN RA Update Procedure 1–58. .
ISSUE 1 REVISION 2 Objectives
�MOTOROLA LTD. 2000 GPRS01: GPRS Architecture
FOR TRAINING PURPOSES ONLY
1–1
ObjectivesOn completion of this chapter the student will be able to:
� Identify the functional entities of GPRS
� Describe the GPRS network with regards to GSM
� Identify the GPRS/GSM control channels
ISSUE 1 REVISION 2GPRS Network Overview
�MOTOROLA LTD. 2000GPRS01: GPRS Architecture
FOR TRAINING PURPOSES ONLY
1–2
GPRS Network OverviewThe diagram opposite shows a simplified General Packet Radio Service (GPRS)network. Each network component is illustrated once, however, many of the componentswill occur several times throughout a network.
The principal network component groups are:
The GPRSSupport NodeNetwork (GSN)
The GPRS Support Node Network (GSN) is the main element in the GPRSinfrastructure. It is a high performance, broadband packet switching node that providesconnection and interworking with various data networks, mobility management anddelivery of data packets to mobile stations. The GSN Network is made of the followingcomponent groups.
� CommHub – The GSN CommHub is the central connection point for thecomponents in a GPRS system. It provides LAN connectivity between GPRScomponents through Ethernet and WAN connectivity to data networks outside theGPRS system.
� ISS – The Integrated Support Services provides GPRS system components withthe current time, domain name translation and network information.
� GGSN – The Gateway GPRS Support Node provides network access to externalhosts so they can communicate with MSs. It also decapsulates and forwardsexternal data networks packets to the appropriate data network.
� SGSN – The Serving GPRS Support Node detects and tracks GPRS MSs in itsservice area and provides a reliable, secure data channel as the MS movesbetween cells.
OMC–GThe OMC-G enables operators to use an NT graphical user interface (GUI) whenmanaging the GPRS components. System operators use the OMC–G to configure andmonitor system components and view performance data.
The Base StationSystem (BSS)
The Base Station System provides the radio frequency link between the GPRS networkinfrastructure and mobile subscribers throughout the operational area. A BSS consists ofthree components:
� Base Station Controller (BSC)
� Base Station Transceiver (BTS)
� Packet Control Unit (PCU) – The Packet Control Unit (PCU) performs radiofunctions and GPRS network functions. It has interfaces to the OMC-R, BSC andthe SGSN.
The MobileStation (MS)
The MSs can belong to three classes A, B or C the class determines whether GPRS andCircuit Switched services can be carried out at the same time or not. The mobiles arealso divided in to multi slot classes that determine the mobile capability of sending andreceiving over multiple slots in a TDMA frame.
ISSUE 1 REVISION 2 GPRS Network Overview
�MOTOROLA LTD. 2000 GPRS01: GPRS Architecture
FOR TRAINING PURPOSES ONLY
1–3
For TrainingPurposesOnly
Coursecode –Section ?
MSCBSC
SGSN
GGSN
BTSInternet
Com
mH
ub
ISS
GSN Network
Frame Relay
PCUAbis
GDS
A
Gb
Gi Router
RXCDR
ISSUE 1 REVISION 2GPRS Application Protocols
�MOTOROLA LTD. 2000GPRS01: GPRS Architecture
FOR TRAINING PURPOSES ONLY
1–4
GPRS Application Protocols
Base StationSystem GPRSProtocol(BSSGP)
Base Station System GPRS Protocol uses Frame relay protocol to provide the radiorelated Qualiity Of Service (QOS) and routing information required to transmit user databetween an SGSN and a BSS. In the SGSN, it forms an interface between Radio LinkControl (RLC)/ Media Access Control (MAC) derived information from the BSS andLogical Link Control (LLC) frames from the SGSN. In the BSS, it acts as an interfacebetween LLC frames from the SGSN and RLC/MAC from the BSS.
The functions of the BSSGP protocol are to:
� Provide a connectionless link between the SGSN and the BSS.
� Transfer data unconfirmed between the SGSN and the BSS.
� Provide tools for the bi-directional control of the flow of data between the SGSNand the BSS.
� Handle paging requests from the SGSN to the BSS.
� Give support for the flushing of old messages from the BSS, for example when anMS changes BSSs.
� Support multiple layer 2 links between the SGSN and the BSS.
Logical LinkControl (LLC)
The LLC provides a highly reliable logical connection between the SGSN and the MS andas such spans the Gb and Um interfaces. In addition the LLC has been designed to beindependent of the underlying radio interface protocols. The LLC includes functions for:
� Provision of one or more logical link connections discriminated between by meansof the Service Access Point Identifier (SAPI).
� Sequence Control
� Error detection and Recovery
� Flow Control
� Ciphering
SubnetworkDependantConvergenceProtocol(SNDCP)
Network Layer protocols are intended to be capable of operating over services derivedfrom a wide variety of submetworks and data links. GPRS supports several network layerprotocols providing protocol transparency for the users of the service. Introduction of newnetwork layer protocols to be transferred over GPRS shall be possible without anychanges to GPRS. Therefore, all functions related to the transfer of Network layerProtocol Data Units (N–PDUs) shall be carried out in a transparent way by GPRSnetwork entities using Subnetwork Dependant Convergence Protocol (SNDCP). Anotherfunction of SNDCP is to improve channel efficiency fulfilled by protocol compression anddata compression.
ISSUE 1 REVISION 2 GPRS Application Protocols
�MOTOROLA LTD. 2000 GPRS01: GPRS Architecture
FOR TRAINING PURPOSES ONLY
1–5
GSM RF
LLC
SNDCP
IP
GSM RF
RLC/
MAC
BSSGP
Network
Service
L1 Bis
BSSGP
Network
Service
L1 Bis
LLC
SNDCP
L1
L2
IP
TCP/
UDP
GTP
RLC/
MAC
L1
L2
IP
TCP/
UDP
GTP
IP
MS BSS SGSN GGSN
ISSUE 1 REVISION 2GPRS Application Protocols
�MOTOROLA LTD. 2000GPRS01: GPRS Architecture
FOR TRAINING PURPOSES ONLY
1–6
Network Service(NS)
The Network Service (NS) transports the BSSGP PDUs. The Network Service Controlentity is responsible for the following functions:
� NS SDU transmission: The NS SDUs shall be transmitted on the NS–VCs. The NSSDUs are encapsulated into Network Service Control PDUs, which in turn areencapsulated into Sub–Network Service PDUs.
� Load sharing: The load sharing function distributes the NS SDU traffic amongst theavailable (i.e. unblocked) NS–VCs of a group.
� NS–VC management: A blocking procedure is used by an NS entity to inform anNS peer entity when an NS–VC becomes unavailable for NS user traffic. Anunblocking procedure is used for the reverse operation. A reset procedure is usedbetween peer NS entities in order to set an NS–VC to a determined state, afterevents resulting in possibly inconsistent states of the NS–VC at both sides of theGb interface. A test procedure is used to check that an NS–VC is operatingproperly between peer NS entities.
GPRS TunnellingProtocol (GTP)
GPRS Tunnelling Protocol (GTP) allows multiprotocol packets to be tunnelled throughthe GPRS backbone between GPRS Support Nodes (GSNs). GTP tunnels user data andsignalling between GSNs in the GPRS network. GTP uses Transmission ControlProtocol/Internet Protocol (TCP/IP) and User Datagram Protocol/Internet Protocol(UDP/IP) protocols to communicate between SGSN and GGSN. GTP simultaneouslysupports two operation modes for information transfer between the GGSN and theSGSN: acknowledged and unacknowledged.
Internet Protocol(IP)
Internet Protocol is the GPRS protocol used for routing user data and control signallingwithin the GSN, as well as from the Internet.
User DatagramProtocol/Transmission ControlProtocol(UDP/TCP)
User Datagram Protocol (UDP) carries GTP PDUs for protocols that do not need areliable data link. UDP also provides protection against corrupted GTP PDUs.
Transmission Control Protocol (TCP)_carries GTP PDUs for protocols requiring reliabledata link. TCP also provides flow control and protection against lost and corrupted GTPPDUs.
ISSUE 1 REVISION 2 GPRS Application Protocols
�MOTOROLA LTD. 2000 GPRS01: GPRS Architecture
FOR TRAINING PURPOSES ONLY
1–7
GSM RF
LLC
SNDCP
IP
GSM RF
RLC/
MAC
BSSGP
Network
Service
L1 Bis
BSSGP
Network
Service
L1 Bis
LLC
SNDCP
L1
L2
IP
TCP/
UDP
GTP
RLC/
MAC
L1
L2
IP
TCP/
UDP
GTP
IP
MS BSS SGSN GGSN
ISSUE 1 REVISION 2GPRS Review
�MOTOROLA LTD. 2000GPRS01: GPRS Architecture
FOR TRAINING PURPOSES ONLY
1–8
GPRS Review
SystemOverview
GPRS is a set of new GSM Bearer and Teleservices providing Packet modeTransmission with the PLMN and external networks. It allows the MSs to send andreceive data in an end to end packet transfer without using resources used for circuitswitches.
GPRS will be able to provide both Point to Point (PTP) and Point to Multipoint (PTM).
The GSM radio is broken down for efficient use by data users.
� Multiple MSs may use a single timeslot
� Multiple MSs may share multiple timeslots
� A single MS may use multiple timeslots (up to eight)
� Different MSs may use uplink or downlink radio resource
� Each radio may use one of four channel coding schemes to get up to 21.4kbps ofdata per timeslot
The channel coder firmware will support CS1 and CS2 for GPRS at GSNI.
Scheme Data Rate Supported
CS1 9.05 YES
CS2 13.4 YES
CS3 15.6 NO
CS4 21.4 NO
ISSUE 1 REVISION 2 GPRS Review
�MOTOROLA LTD. 2000 GPRS01: GPRS Architecture
FOR TRAINING PURPOSES ONLY
1–9
System Overview
� Multiple MSs may use a single TS
� Multiple MSs may share multiple TS
� A single MS may use multiple TS (up to 8)
� Different MSs may use one of four channel coding schemes
� Each radio may use one of four channel coding schemes
Scheme Data Rate Supported
CS1 9.05 YES
CS2 13.4 YES
CS3 15.6 FUTURE
CS4 21.4 FUTURE
ISSUE 1 REVISION 2GPRS Review
�MOTOROLA LTD. 2000GPRS01: GPRS Architecture
FOR TRAINING PURPOSES ONLY
1–10
GPRS 52Multiframe
The 52 frame structure shown opposite is a new frame. Its structure is totally differentfrom the existing 51 and 26 frame structures.
The 52 Multiframe does not have a rigid structure. Essentially the different channels areidentified by message type. The Multiframe can carry control channels or data channels.
CONTROL CHANNELS TRAFFIC CHANNELS
PBCCH PDTCH
PPCH PACCH
PAGCH
PNCH
ISSUE 1 REVISION 2 GPRS Review
�MOTOROLA LTD. 2000 GPRS01: GPRS Architecture
FOR TRAINING PURPOSES ONLY
1–11
52 Multiframe structure
B0
B1
B2
�
B3
B4
B5
�
B6
B7
B8
�
B9
B10
B11
�
�
��= IDLE FRAMEB(n)= 4 Frame radio block
ISSUE 1 REVISION 2GPRS Review
�MOTOROLA LTD. 2000GPRS01: GPRS Architecture
FOR TRAINING PURPOSES ONLY
1–12
Um Air Interface
GPRS uses one or more timeslots per call known as Packet Data Channel (PDCH).PDCHs are physical channels which consist of various logical channels.
Packet Common Control Channel (PCCH) – comprises logical channels for commoncontrol signalling of packet data.
Packet Random Access Channel (PRACH) – Ul only.
Uplink only, mapped on to the PDCH or the PACH. Used by the MS to initiate uplinktransfer, e.g. sending data or paging response.
Packet Paging Channel (PPCH) – downlink only
PPCH is used to page an MS prior to downlink transfer.
Packet Access Grant Channel (PAGCH) – downlink only
PAGCH used in packet transfer establishment phase to send resource assignment to anMS prior to packet transfer.
Note: Resource Assignment for a downlink assignment can be sent on the PACCH if theMS is currently involved in a Packet Transfer.
Packet Broadcast Control Channel (PBCCH) – downlink only
PBCCH broadcasts Packet Data specific information if the PBCCH is not allocated thenthe BCCH is used to broadcast Packet Data Specific Information.
ISSUE 1 REVISION 2 GPRS Review
�MOTOROLA LTD. 2000 GPRS01: GPRS Architecture
FOR TRAINING PURPOSES ONLY
1–13
Um Air Interface
CCH
CCCH BCCHCCCHCCCH BCCHCCCH
RACH PCH/AGCH CBCH
RACH PPCH PAGCHRACH PNCH
PCCCH
PCCH
PBCCH
ISSUE 1 REVISION 2GPRS Review
�MOTOROLA LTD. 2000GPRS01: GPRS Architecture
FOR TRAINING PURPOSES ONLY
1–14
TimeslotConfiguration
The BSS will support the GPRS carrier per cell. This carrier can be either the BCCH orNon–BCCH.
GPRS timeslots are divided into Reserved and Switchable timeslots.
Reserved GPRS Timeslot
A reserved GPRS timeslot is a timeslot that is used only for GPRS services.
Switchable GPRS Timeslot
A switchable timeslot is a timeslot that can be switched from GPRS service to circuitswitched service and vice versa.
GPRS vs CS
For switchable GPRS timeslots, circuit switched services always have priority. So, if thenumber of idle TCHs falls to zero and the BSS needs to set up a circuit switched callthen the BSS will reconfigure a switchable GPRS TS to a circuit switched timeslot.
Timeslot Configuration
Reserved GPRS timeslots are placed above Switchable GPRS timeslots which areplaced above circuit switched.
ISSUE 1 REVISION 2 GPRS Review
�MOTOROLA LTD. 2000 GPRS01: GPRS Architecture
FOR TRAINING PURPOSES ONLY
1–15
Timeslot configuration
TCH
TCH
TCH
SW
SW
RES
RES
RES
TCH= Circuit switched TSSW= GPRS Switchable TSRES= GPRS Reserved TS
TS0
TS1
TS2
TS3
TS4
TS5
TS6
TS7
ISSUE 1 REVISION 2GPRS Review
�MOTOROLA LTD. 2000GPRS01: GPRS Architecture
FOR TRAINING PURPOSES ONLY
1–16
Packet TrafficChannels
One Packet Data Traffic Channel (PDTCH) is mapped to one physical channel. Up to 8PDTCH with different TS but some frequency parameters can be allocated to one MS atthe same time.
Packet Associated Control Channel (PACCH)
One Packet Associated Control Channel (PACCH) is mapped on to one physicalchannel. PACCH is dynamically allocated on a block basis. It provides signallinginformation including acknowledgements, power control and timing advance information.The PACCH can also be used for resource allocation messages, whilst the MS is alreadycarrying out packet transfer.
If a single PDTCH is assigned to an MS then the PACCH will be assigned on the samephysical channel. If multiple PDTCHs are assigned to a mobile then the PACCH isalways allocated on one of the Packet Data Channels (PDCHs) on which the PDTCHsare allocated.
PACCH is bi-directional in nature. In other words whilst the assignment might be uplinkor downlink, if PDTCHs are assigned on the uplink then one corresponding downlinktimeslot must be monitored for the possible occurrences of the PACCH. At the sametime, the MS can use the uplink assignment to send a PACCH at any time.
PDTCHs Dynamic Allocation
Dynamic Allocation allows multiple MSs to use the same uplink resource. This isaccomplished by using the Uplink State Flag (USF) , a 3 bit flag that can be used to allowup to 7 mobiles to access the same resource.
If, for example, a mobile is allocated in the assignment command timeslot 0, 2 and 3 thenthe mobile will monitor the downlink PDCH timeslots 0, 2 and 3 for its assigned USFvalue.
If the mobile receives the USF on a downlink block then on the next uplink block themobile will transmit and also on the next 3 blocks if USF granularity is set to 1.
UL PDTCH Fixed Allocation
Fixed Allocation uses the Packet Uplink Assignment to communicate a detailed fixeduplink resource allocation to the MS. This fixed allocation consists of a start frame, slotassignment and block assignment bitmap to represent the assigned blocks per timeslot.
PACCH the MS will transmit a ul PACCH at any time. To gain a dl PACCH the fixedallocation will purposely have gaps to allow the MS to monitor all PDCH for a PACCHaddressed to it. To this purpose the network will leave sets of 3 timeslot gaps in theuplink fixed allocation for the purpose of transmission of the dl PACCH.
During transfer of RLC/MAC blocks a mobile station may request to continue theTempoary Block Flow (TBF) by transmitting a Packet Resource Request on the ulPACCH. The network then responds with a Packet Resource Reassignment on the dlPACCH.
ISSUE 1 REVISION 2 GPRS Review
�MOTOROLA LTD. 2000 GPRS01: GPRS Architecture
FOR TRAINING PURPOSES ONLY
1–17
UL PDTCH Fixed Allocation
ÈÈÈÈÈÈÈÈÈÈÈÈ
ÈÈÈÈÈÈÈÈÈÈÈÈÈÈÈ
ÈÈÈÈÈÈÈÈÈÈÈÈÈÈÈ
ÈÈÈÈÈÈÈÈÈÈÈÈÈÈÈ
ÈÈÈÈÈÈÈÈÈÈÈÈÈÈÈ
ÈÈÈÈÈÈÈÈÈÈÈÈÈÈÈ
ÈÈÈÈÈÈÈÈÈÈÈÈ
ÈÈÈÈÈÈÈÈÈÈÈÈ
ÈÈÈÈÈÈÈÈÈÈÈÈ
ÈÈÈÈÈÈÈÈÈÈÈÈ
ÈÈÈÈÈÈÈÈÈÈÈÈ
ÈÈÈÈÈÈÈÈÈÈÈÈÈÈÈÈÈÈÈÈÈÈÈÈÈÈÈÈÈÈ
ÈÈÈÈÈÈÈÈÈÈÈÈÈÈÈÈÈÈÈÈÈÈÈÈÈÈÈÈÈÈ
TS0 TS1 TS2 TS3 TS4 TS5 TS6 TS7
B0 B1 B2 � B3 B4 B5 � B6 B7 B8 � B9 B10 B11 �
ÈÈÈÈÈÈÈÈÈÈÈÈÈÈÈ
B0 B1 B2 � B3 B4 B5 � B6 B7 B8 � B9 B10 B11 �
ÈÈÈÈÈÈÈÈÈÈÈÈ
= MS assigned blocks + timeslots
ISSUE 1 REVISION 2GPRS Review
�MOTOROLA LTD. 2000GPRS01: GPRS Architecture
FOR TRAINING PURPOSES ONLY
1–18
MS Classes withMultislotCapability
Phase 2+ Mobiles have the capability to use multiple slots in one TDMA frame in bothuplink and downlink. They are split into classes 1 through 29.
The mobiles are split into two types:
� Type 1 MS are not required to transmit and receive at the same time
� Type 2 MS are required to transmit and receive at the same time
Tt = Time to transmit.
Tr = Time to receive.
a = A measurement report is made
b = No measurement report made
a) = 1 with frequency hopping = 0 without frequency hoppingb) = 1 with frequency hopping or change from Rx to Tx = 0 without frequency hopping or no change from Rx to Txc) = 1 with frequency hopping or change from Tx to Rx = 0 without frequency hopping and no change from Tx to Rx
Type 1 MS are not required to transmit and receive at the same timeType 2 MS are required to be able to transmit and receive at the same time.
ISSUE 1 REVISION 2 GPRS Review
�MOTOROLA LTD. 2000 GPRS01: GPRS Architecture
FOR TRAINING PURPOSES ONLY
1–19
MS Classes with Multislot capabilitiesMultislot Maximum number of slots Minimum number of slots Type
Rx Tx Sum Tta Ttb Tra TrbDefault
1 1 1 2 3 2 4 2 1
2 2 1 3 3 2 3 1 1
3 2 2 3 3 2 3 1 1
4 3 1 4 3 1 3 1 1
5 2 2 4 3 1 3 1 1
6 3 2 4 3 1 3 1 1
7 3 3 4 3 1 3 1 1
8 4 1 5 3 1 2 1 1
9 3 2 5 3 1 2 1 1
10 4 2 5 3 1 2 1 1
11 4 3 5 3 1 2 1 1
12 4 4 5 2 1 2 1 1
13 3 3 NA NA a) 3 a) 2
14 4 4 NA NA a) 3 a) 2
15 5 5 NA NA a) 3 a) 2
16 6 6 NA NA a) 2 a) 2
17 7 7 NA NA a) 1 0 2
18 8 8 NA NA 0 0 0 2
19 6 2 NA 3 b) 2 c) 1
20 6 3 NA 3 b) 2 c) 1
21 6 4 NA 3 b) 2 c) 1
22 6 4 NA 2 b) 2 c) 1
23 6 6 NA 2 b) 2 c) 1
24 8 2 NA 3 b) 2 c) 1
25 8 3 NA 3 b) 2 c) 1
26 8 4 NA 3 b) 2 c) 1
27 8 4 NA 2 b) 2 c) 1
28 8 6 NA 2 b) 2 c) 1
29 8 8 NA 2 b) 2 c) 1
ISSUE 1 REVISION 2GPRS Review
�MOTOROLA LTD. 2000GPRS01: GPRS Architecture
FOR TRAINING PURPOSES ONLY
1–20
Fixed AllocationTimeslotAssignment
Fixed allocation presents particular restrictions to the allocation of Packet Data Channels(PDCHs) to multislot mobiles. In particular, the assignment must not conflict with therules for Packet Associated Control Channel (PACCH) monitoring or transmission andmeasurements of neighbour cells.
If for instance a multislot mobile station Class 4 is assigned a 3 timeslot Temporary BlockFlow (TBF) downlink and no uplink TBF. In this example the Packet DownlinkAssignment does not assign Measurement Mapping Parameters to the mobile so the MSmust make neighbour cell power measurement in 24 out of every 26 TDMA frames.
For multislot Class 4 mobiles the time needed for the MS to make a neighbour cell signalmeasurement and then get ready to transmit is 3 timeslots. Therefore the mobile canmake a measurement in every TDMA frame.
If the mobile is polled on timeslot 1, with a Relative Reserved Block Period (RRBP) ofzero (to send PACCH from next RLC/MAC Block on timeslot 1), then the mobile willtransmit a PACCH on timeslot 1. This transmission obeys the time needed for the mobileto transmit for multislot Class 4 which is 1 TS. It also conforms to the time needed tocarry out neighbour cell measurements.
ISSUE 1 REVISION 2 GPRS Review
�MOTOROLA LTD. 2000 GPRS01: GPRS Architecture
FOR TRAINING PURPOSES ONLY
1–21
Fixed Allocation Timeslot Assignment
ÉÉÉÉ
ÄÄÄÄÄÄÄÄ
ÉÉÉÉ
ÉÉÉÉ
ÄÄÄÄ
ÉÉÉÉÉÉÉÉ
ÉÉÉÉÉÉÉÉ
ÄÄÄÄ
ÉÉÉÉ
ÉÉÉÉÉÉÉÉ
ÄÄÄÄ
ÉÉÉÉ
ÉÉÉÉ
ÉÉÉÉÉÉÉÉ
ÉÉÉÉ
ÉÉÉÉ
ÉÉÉÉ
ÉÉÉÉÉÉÉÉ
ÉÉÉÉÉÉÉÉ
ÉÉÉÉ
ÉÉÉÉ
ÉÉÉÉ
ÉÉÉÉ
ÉÉÉÉÉÉÉÉ
ÉÉÉÉ
ÉÉÉÉÉÉÉÉ
ÉÉÉÉ
ÉÉÉÉ
ÉÉÉÉ
ÉÉÉÉÉÉÉÉ
ÉÉÉÉ
ÉÉÉÉÉÉÉÉ
ÉÉÉÉ
0 1 2 3 4 5 6 7
ÉÉÉÉÉÉÉÉ
ÉÉÉÉ
ÉÉÉÉ
ÉÉÉÉ0 1 2 3 4 5 6 7
RLC/MAC Block
poll
Downlink
Uplink
Ttb= 1 Tra= 3
Multislot class 4 (Rx= 3, Tx= 1, Sum= 4, 3 timeslot downlink TBF, with a poll on timeslot 1 (the natural timeslot)
ISSUE 1 REVISION 2GPRS Review
�MOTOROLA LTD. 2000GPRS01: GPRS Architecture
FOR TRAINING PURPOSES ONLY
1–22
MobilityManagement
Mobility Management (MM) activities are related to a GPRS subscriber and characterisedby 3 MM states. Each state describes a different level of functionality and informationallocated. These information sets are denoted by MM contexts at the SGSN and theMS.
Idle
In GPRS IDLE the subscriber is not attached to the GPRS Mobility Management. TheMS and SGSN context hold no location or routing information for the mobile. The GPRSMobile is seen as not reachable for PTP data transfers. PLMN selection and reselectionare performed by the MS.
Standby State (Stby)
In Stby state the subscriber is attached to the GPRS Mobility Management. The MS andthe SGSN have established MM contexts for the subscribers IMSI.
The subscriber may now receive pages for data transfers. Transmission and reception ofdata is not possible in this state.
� MS performs GPRS cell reselection and routing area
� MS updates SGSN if it enters a new RA
� MS may activate or deactivate PDP contexts
Ready State
The Ready state corresponds to the Stby state extended by location information for thesubscriber at call level. The MS performs MM procedures to notify the network with theactual selected cell. GPRS cell selection and reselection may be done by the MS, oroptionally controlled by the network.
An identifier of the cell is placed in the BSSGP header of the packet data from the MS.
The MS may send and receive PTP PDUs in this state. The network initiates no networkpages for an MS in the Ready State.
– MS may activate or deactivate PDP contexts
– MS may stay in the Ready State with or without Radio Resources allocated.
ISSUE 1 REVISION 2 GPRS Review
�MOTOROLA LTD. 2000 GPRS01: GPRS Architecture
FOR TRAINING PURPOSES ONLY
1–23
Idle/Stby/Ready
IDLE
READY
STANDBY
GPRS Attach
GPRS Detach
PDU transmission
READY timer expiryorForce to STANDBY
STANDBYtimer expiry
IDLE
READY
STANDBY
GPRS Attach
GPRS Detachor
Cancel Location
PDU reception
READY timerexpiryorForce toSTANDBYorAbnormal RLCcondition
MM State Model of MS MM State Model of SGSN
STANDBYtimer expiry
or cancellocation
ISSUE 1 REVISION 2GPRS Review
�MOTOROLA LTD. 2000GPRS01: GPRS Architecture
FOR TRAINING PURPOSES ONLY
1–24
Timing Advance
Packet Data Transmission is inherently ‘bursty’, by this the data transfer is notcontinuous. This presents problems with maintaining the correct timing advance for anMS during a data transfer.
ISSUE 1 REVISION 2 GPRS Review
�MOTOROLA LTD. 2000 GPRS01: GPRS Architecture
FOR TRAINING PURPOSES ONLY
1–25
Timing advance
Data Transmission
ISSUE 1 REVISION 2GPRS Review
�MOTOROLA LTD. 2000GPRS01: GPRS Architecture
FOR TRAINING PURPOSES ONLY
1–26
ContinuousTiming Advance
The initial timing advance is based on the single access burst carrying the PacketChannel Request. The estimated timing advance value is passed to the MS via thePacket Immediate Assignment. This value is used by the MS until continuous timingadvance update provides a new value.
In continuous timing advance the mobile sends in a special access burst in an idle slot forthe network to derive the timing advance. In the downlink the network sends a timingadvance value via the Packet Associated Control Channel (PACCH) which is transmittedduring the idle timeslots of the 52 multiframe.
Timing Advance Index gives the MS the position to send the access burst. For example,TAI = 1 refers to idle timeslot 2. The network will then update the MS timing advance inthe next Timing Advance Message and also the next 3 TA messages. The mobile onlyhas to read the message once.
ISSUE 1 REVISION 2 GPRS Review
�MOTOROLA LTD. 2000 GPRS01: GPRS Architecture
FOR TRAINING PURPOSES ONLY
1–27
Timing advance
B0 B1 B2 0 B3 B4 B5 1 B6 B7 B8 2 B9 B10 B11 3
52-multiframe number n:Uplink TAI=0 TAI=1
Downlink TA message 1
B0 B1 B2 4 B3 B4 B5 5 B6 B7 B8 6 B9 B10 B11 7
52-multiframe number n + 1:Uplink TAI=2 TAI=3
TAI message 1
Downlink TA message 1 TAI message 1
B0 B1 B2 8 B3 B4 B5 9 B6 B7 B8 10 B9 B10 B11 11
52-multiframe number n + 2:Uplink TAI=4 TAI=5
Downlink TA message 2 TAI= message 2
B0 B1 B2 12 B3 B4 B5 13 B6 B7 B8 14 B9 B10 B11 15
52-multiframe number n + 3:Uplink TAI=6 TAI=7
Downlink TA message 2 TAI= message 2
B0 B1 B2 16 B3 B4 B5 17 B6 B7 B8 18 B9 B10 B11 19
52-multiframe number n + 4:Uplink TAI=8 TAI=9
Downlink TA message 3
B0 B1 B2 20 B3 B4 B5 21 B6 B7 B8 22 B9 B10 B11 23
52-multiframe number n + 5:Uplink TAI=10 TAI=11
TAI message 3
Downlink TA message 3 TAI message 3
B0 B1 B2 24 B3 B4 B5 25 B6 B7 B8 26 B9 B10 B11 27
52-multiframe number n + 6:Uplink TAI=12 TAI=13
Downlink TA message 4 TAI= message 4
B0 B1 B2 28 B3 B4 B5 29 B6 B7 B8 30 B9 B10 B11 31
52-multiframe number n + 7:Uplink TAI=14 TAI=15
Downlink TA message 4 TAI= message 4
B0 – B11= Radio blocks idle bursts are numbered from 0 to 31
ISSUE 1 REVISION 2GPRS Review
�MOTOROLA LTD. 2000GPRS01: GPRS Architecture
FOR TRAINING PURPOSES ONLY
1–28
MobileOriginatedPacket Transfer
On entry into a cell, the mobile will read System Information Messages 3,4,7 or 8. Thecell, if it supports GPRS, will transmit System Information message 13 and optionally 14and 15.
The MS initiates the Packet Access Procedure by the sending of a Channel Requestmessage on the RACH. The RSS forwards the RACH to the Pack Control Unit (PCU).The PCU then generates the Immediate Assignment allocating a Packet Data Channel(PDCH) from its pool of resources.
The MS now sends on the PDCH a Packet Resource Request requesting FixedAllocation , which will indicate the priority of the data, the number of octets of data theMS uses to transfer and the requested bandwidth, e.g. 500 Kbps.
The PCU will respond with the Packet Resource Assignment on the Packet AssociatedControl Channel (PACCH). This message assigns timeslots to the mobile and theallocated blocks to transmit on. Also within the message will be the Temporary FlowIndentifier (TFI) to identify the Temporary Block Flow (TBF) for transmitting the airinterface.
TFI Temporary Flow Indentifier
TBF Temporary Block Flow
ISSUE 1 REVISION 2 GPRS Review
�MOTOROLA LTD. 2000 GPRS01: GPRS Architecture
FOR TRAINING PURPOSES ONLY
1–29
Mobile Originated Packet Transfer (No PBCCH)
PCU RSS MS
SYSTEM INFORMATION BCCH
PACKET CHANNEL REQUEST RACH
GSL TO RSL
PACKET IMMEDIATE ASSIGNMENT AGCH
PACKET RESOURCE REQUEST PACCH
PACKET RESOURCE ASSIGNMENT PACCH
DATA BLOCK PDTCH
DATA BLOCK PDTCH
SYSTEM INFORMATION
ISSUE 1 REVISION 2GPRS Review
�MOTOROLA LTD. 2000GPRS01: GPRS Architecture
FOR TRAINING PURPOSES ONLY
1–30
Downlink MobileTerminatedPacket Transfer
As before, on entry to the cell the mobile will read system information messages on theBCCH. If GPRS is present in the cell then the system information messages will indicatethis and also the presence of system information message 13. The Information message13 gives the information of power control, priority access, classes allowed. Informationmessage 14 gives information of reference frequency lists and mobile allocationsapplicable to packet access in a cell. Information message 15 gives information onpacket power control interference measurements.
If the mobile is in the Standby state then the network may page the mobile to transferPDUs. Paging sent from the SGSN will be handled by the Packet Control Unit (PCU)and dependent on the state of the mobile will result in paging by routing area or in a cell.
The mobile will respond with an RACH with a cause value indicating GPRS. The RSSwill pass this channel request to the PCU which will allocate a PDCH for 2 phase access.This is sent to the mobile on the AGCH.
The set up is now as before as mobile originated Packet Transfer.
ISSUE 1 REVISION 2 GPRS Review
�MOTOROLA LTD. 2000 GPRS01: GPRS Architecture
FOR TRAINING PURPOSES ONLY
1–31
Downlink Mobile Terminated Packet Transfer (No PBCCH)
PCU RSS MS
SYSTEM INFORMATION 3, 13 BCCH
PACKET PAGING REQUEST (PCH)
PACKET RESOURCE REQUEST PACCH
PACKET RESOURCE ASSIGNMENT PACCH
PDU (PDTCH)
PDU (PDTCH)
SYSTEM INFORMATION
PAGING
PACKET CHANNEL REQUEST (RACH)
PACKET IMMEDIATE ASSIGNMENT (AGCH)
ISSUE 1 REVISION 2GPRS Review
�MOTOROLA LTD. 2000GPRS01: GPRS Architecture
FOR TRAINING PURPOSES ONLY
1–32
Uplink PacketTransfer
Once the Access and Assignment is complete, the mobile awaits its allocated blocks onthe allocated Packet Data Channels (PDCHs). Once the allocated blocks arrive the MSshall begin to transmit Radio Link Control (RLC) data blocks on its Packet Data TrafficChannels (PDTCHs).
These RLC data blocks are all uniquely identified by the Temporary Flow Indentifier (TFI).The unique identification on the TFI is included in every RLC data or control block relatedto the Temporary Block Flow (TBF). Because each radio block contains an identifier(TFI) all received blocks are correctly associated a particular LLC frame and a particularMS.
The network will acknowledge transfers by sending Packet Uplink ACK/NACK messageson the Packet Associated Control Channel (PACCH) during gaps in the uplink allocation.The message contains the status of the received RLC data blocks. The message mayalso update the timing advance, power control parameters and assign uplink resources toa fixed mobile.
The mobile will continue transmitting the RLC data blocks, retransmitting those datablocks indicated by the network until it reaches its last RLC data block.
ISSUE 1 REVISION 2 GPRS Review
�MOTOROLA LTD. 2000 GPRS01: GPRS Architecture
FOR TRAINING PURPOSES ONLY
1–33
Uplink Packet Transfer
MSNetwork
DATA BLOCK
ACCESS AND ASSIGNMENT
DATA BLOCK
DATA BLOCK
DATA BLOCK
TEMP ACK/NACK
DATA BLOCK
DATA BLOCK
DATA BLOCK
DATA BLOCK
DATA BLOCK
DATA BLOCK
DATA BLOCK
DATA BLOCK
TEMP ACK/NACK
DATA BLOCK
DATA BLOCK (LAST)
FINAL PACKET ACK//NACK
PACKET RESOURCE ASSIGNMENT
ISSUE 1 REVISION 2GPRS Review
�MOTOROLA LTD. 2000GPRS01: GPRS Architecture
FOR TRAINING PURPOSES ONLY
1–34
MobileTerminatedPacket Transfer
As before with Mobile Originate Packet Transfer the network assigns a unique TemporaryFlow Identifier (TFI) with regards to the downlink Temproary Block Flow (TBF) and a setof Packet Data Channels (PDCHs) to be used for the downlink transfer and a TBF statingtime (optional ).
The MS on reception of the downlink assignment will either attempt to decode everydownlink block on its assigned PDCHs or it is sent on TBF starting time, wait on theCCCH until the TDMA framenumber indicated by the TBF starting time.
When the mobile receives an Radio Link Control (RLC) data block addressed to itself andwith a polling indication in the uplink radio block specified in the header, then the mobilewill transmit an ACK/NACK or control message (mobile will only transmit a RLC/MACcontrol message instead of ACK/NACK, at most, every fourth time it is polled).
The network initiates a release of a downlink TBF by sending an RLC data block with theFinal Bit Indicator (FBI) and a valid polling indication. The mobile shall transmit a PacketACK/NACK in the uplink radio block specified.
ISSUE 1 REVISION 2 GPRS Review
�MOTOROLA LTD. 2000 GPRS01: GPRS Architecture
FOR TRAINING PURPOSES ONLY
1–35
Mobile terminated packet transfer
PCU MS
ACCESS AND ASSIGNMENT
FINAL PACKET ACK/NACK PACCH
DATA BLOCK PDTCH
DATA BLOCK (POLLING) PDTCH
TEMP PACKET ACK/NACK PACCH
DATA BLOCK PDTCH
DATA BLOCK (LAST/POLLING)
ISSUE 1 REVISION 2GPRS Review
�MOTOROLA LTD. 2000GPRS01: GPRS Architecture
FOR TRAINING PURPOSES ONLY
1–36
Radio LinkControl (RLC)
The Radio Link Control (RLC) function is responsible for:
� Interface allowing transfer of UC PDUs between the Logical Link Control (LLC)Layer and the Media Access Control (MAC) function
� Segmentation of LLC PDUs into RLC data blocks and re-assembly of RLC datablocks into LLC PDUs
� Backwards Error Correction (BEC) Procedures enabling selective retransmissionof RLC data blocks
An RLC connection comprises two peer entities. Each RLC endpoint has a receiver thatreceives RLC data blocks. Each RLC endpoint has a transmitter that transmits RLC datablocks.
ISSUE 1 REVISION 2 GPRS Review
�MOTOROLA LTD. 2000 GPRS01: GPRS Architecture
FOR TRAINING PURPOSES ONLY
1–37
Radio link control (RLC)
RLC
MAC
PhysicalLayer
LLC
RLC
MAC
PhysicalLayer
LLC
RLC
MAC
PhysicalLayer
FH FCSINFORMATION FIELD
BH INFO FIELD BCS BH INFO FIELD BCS BH INFO FIELD BCS
NORMALBURST
NORMALBURST
NORMALBURST
NORMALBURST
LLC
RLC/MAC
PHYSICALLAYER
ISSUE 1 REVISION 2GPRS Review
�MOTOROLA LTD. 2000GPRS01: GPRS Architecture
FOR TRAINING PURPOSES ONLY
1–38
RLC DataACK/NACK
The Radio Link Control (RLC) peers each have a receive and transmit window of 0 –127. The window size is 64 blocks. The sending side can transmit blocks within awindow of 64 blocks and the receiving side periodically sends temporary ACK/NACKmessages. Every such message acknowledges all correctly received blocks and canrequest erroneously received RLC data blocks for retransmission.
Each RLC data block contains a block sequence number (BSN) in the range 0 – 127. Inthe send side a variable V(s) denotes the next in sequence RLC data block to be sent, onthe receive side a variable V(R) denotes the next in sequence RLC block to be received.
Acknowledge state variables, the send side has an acknowledge variable V(a) thatcontains the BSN of the oldest RLC block that has not been acknowledged. On theReceive side the variable V(Q) denotes the oldest RLC data block that has not beenreceived.
The send side maintains an Acknowledge state array V(B), an array of 128 elementsindicating the acknowledgement status of transmitted RLC data blocks that are eitherpending – ACK or NACKED or INVALID.
The order of transmitted RLC blocks is the oldest RLC block that has been NACKED. Ifthe sliding window is still open, i.e. V(S) <V(A) +K then the next RLC data block withBSN = V(S) shall be transmitted and the V(B) array element set to PENDING – ACK.
Once the V(S) = V(A) + K, in other words the window is stalled. Then the send side shalltransmit the oldest element in V(B) that has the value PENDING – ACK.
ISSUE 1 REVISION 2 GPRS Review
�MOTOROLA LTD. 2000 GPRS01: GPRS Architecture
FOR TRAINING PURPOSES ONLY
1–39
Radio Link Control (RLC) data Ack/Nack
MS PCU
BSN= 2
RLC BLOCK BSN= 0
RLC BLOCK BSN= 1
ACK 0, 1 NACK 2
RLC BLOCK BSN= 2
BSN= 3
BSN= 65
BSN= 2
BSN= 3
ACK 2 – 65
BSN= 66
Va= 0
Va= 2
Stalled
Vq= 2
ISSUE 1 REVISION 2GPRS Review
�MOTOROLA LTD. 2000GPRS01: GPRS Architecture
FOR TRAINING PURPOSES ONLY
1–40
Release of Uplink
Temporary Block Flow (TBF)
The mobile station sends in the Radio Link Control (RLC) data block a Countdown Value(CV) to indicate to the network the last RLC data block that will be sent in the uplink TBF.The CV is calculated as a value dependant on the number of Timeslots assigned on theuplink and the total number of RLC data blocks in the TBF and a broadcast parameterBS – CV – MAX.
BS – CV – MAX is the number of blocks the countdown will begin before the last block istransmitted. For example, as BS – CV – MAX of 4 would mean that the last 4 blocks willcount down to 0. A CV of 15 is the norm value for RLC data blocks.
ISSUE 1 REVISION 2 GPRS Review
�MOTOROLA LTD. 2000 GPRS01: GPRS Architecture
FOR TRAINING PURPOSES ONLY
1–41
Release of uplink
15 3 2 1 0
BS_CV_MAX= 4
ISSUE 1 REVISION 2GPRS Review
�MOTOROLA LTD. 2000GPRS01: GPRS Architecture
FOR TRAINING PURPOSES ONLY
1–42
GPRS Attach
The procedure as shown opposite details a combined GPRS and IMSI attach. Takingeach state in turn:
1. The MS initiates the procedure by issuing an ‘Attach Request’ which includes;
IMSI or P–TMSI
– Old RAI (Routing Area Identification)
– Classmark (multislot capabilities, GPRS cipher algorithms)
– CKSN (Cipher Key Sequence Number)
– Attach Type (GPRS/IMSI/both)
– DRX (discontinuous reception)
– Old P–TMSI signature (if one exists)
2. The New SGSN sees from the RAI sent by the MS that it was previously attachedto the Old SGSN, therefore the New SGSN sends an ‘Identity Request’ messageto the Old SGSN. The response back from the Old SGSN will include the IMSIand Authentication Triplets.
3. If the MS is unknown to the New and Old SGSNs, then an ‘Identity Request’ issent, and the response should contain its IMSI.
4. Authentication and ciphering procedures may be initiated to ensure MS and datasecurity.
5. A further check can be made of the MS against its IMEI.
6. If the SGSN has changed since the MNS was last attached to the network:
A. The SGSN sends an ‘Update Location’ to the HLR:
– SGSN number
– SGSN address
– IMSI
B. HLR send cancel location to Old SGSN
C. The Old SGSN acknowledges before removing Mobility Management (MM) andPDP contexts.
D. HLR inserts subscriber information into New SGSN
– IMSI
– GPRS Subscription data
E. New SGSN acknowledges and creates new MM context
F. HLR updates its own records and returns an acknowledgement to the New SGSN.
7. Assuming the Gs interface exists then the VLR will be updated by use of ‘LocationUpdate’ by the SGSN. This is particularly true when considering a combinedGPRS/IMSI attach:
A. Location Update:
– New LAI
– IMSI
– SGSN number
– Location Update Type
ISSUE 1 REVISION 2 GPRS Review
�MOTOROLA LTD. 2000 GPRS01: GPRS Architecture
FOR TRAINING PURPOSES ONLY
1–43
Attach
MS BSSNEWSGSN
OLDSGSN GGSN EIR
NEWMSC/VLR HLR
OLDMSC/VLR
1. Attach Request
2. Identification Request
2. Identification Response
3. Identity Request
3. Identity Response
4. Authentication
5. IMEI Check
6a. Update Location
6b. Cancel Location
6c. Cancel Location Ack
6d. Insert Subscriber Data
6e. Insert Subscriber Data Ack
6f. Update Location Ack
7a. Location Updating Request
7b. Update Location
7c. Cancel Loc Ack
7d. Cancel Loc Ack
7e. Insert Subscriber Data
7f. Insert Subscriber Data
7g. Update Location Ack
7h. Location Updating Accept
8. Attach Accept
9. Attach Complete
10. TMSI Reallocation Complete
ISSUE 1 REVISION 2GPRS Review
�MOTOROLA LTD. 2000GPRS01: GPRS Architecture
FOR TRAINING PURPOSES ONLY
1–44
B. New VLR indicates to HLR of a location update
HLR takes over and cancels the location in the Old VLR (c and D), before insertingnew subscriber information in the New VLR (e). Finally the HLR acknowledges tothe New VLR.
C. The New VLR acknowledges the ‘Location Update’ back to the SGSN.
8. The SGSN sends an ‘Attach Accept’ to the MS containing:
– P–TMSI
– VLR TMSI
9. If the P–TMSI or VLR TMSI have been changed by the SGSN then the MS needsto acknowledge.
10. If the VLR TMSI has been changed and acknowledged by the MS, then the SGSNneeds to acknowledge back to the VLR.
ISSUE 1 REVISION 2 GPRS Review
�MOTOROLA LTD. 2000 GPRS01: GPRS Architecture
FOR TRAINING PURPOSES ONLY
1–45
Attach
MS BSSNEWSGSN
OLDSGSN GGSN EIR
NEWMSC/VLR HLR
OLDMSC/VLR
1. Attach Request
2. Identification Request
2. Identification Response
3. Identity Request
3. Identity Response
4. Authentication
5. IMEI Check
6a. Update Location
6b. Cancel Location
6c. Cancel Location Ack
6d. Insert Subscriber Data
6e. Insert Subscriber Data Ack
6f. Update Location Ack
7a. Location Updating Request
7b. Update Location
7c. Cancel Loc Ack
7d. Cancel Loc Ack
7e. Insert Subscriber Data
7f. Insert Subscriber Data
7g. Update Location Ack
7h. Location Updating Accept
8. Attach Accept
9. Attach Complete
10. TMSI Reallocation Complete
ISSUE 1 REVISION 2GPRS Review
�MOTOROLA LTD. 2000GPRS01: GPRS Architecture
FOR TRAINING PURPOSES ONLY
1–46
GPRS Detach
With respect to the diagrams shown opposite we should consider the three defineddetach procedures.
The top diagram on the opposite page details the Detach procedure that is initiated bythe MS.
1. The MS initiates by sending Detach Request
– Detach Type
– Switch Off (switch off or not)
2. If GPRS detach then the PDP context needs to be deleted in the GGSN
3. If IMSI detach, the SGSN sends IMSI detach to the VLR
4. If the MS wishes to remain IMSI attached and remove its GPRS context in theVLR
5. If the switch off parameter indicated that the MS was being switched off, then the‘Detach Accept’ is not sent.
If the detach is initiated by the SGSN, then the sequence is similar to that above, exceptthat the initial message detailed in 1 above is started by the SGSN. Stages 2 and 4above are used as shown in the middle diagram on the opposite page.
The detach sequence could be started by the HLR as shown in bottom diagram on theoppsite page, by the use of a ‘Cancel Location’ MAP message. Following the ‘CancelLocation’ message, the procedure is much the same as for the SGSN initiated detachprocedure.
ISSUE 1 REVISION 2 GPRS Review
�MOTOROLA LTD. 2000 GPRS01: GPRS Architecture
FOR TRAINING PURPOSES ONLY
1–47
Detach
MS BSS SGSN GGSN MSC/VLR
1. Detach Request2. Delete PDP Context Request
2. Delete PDP Context Response
3. IMSI Detach Indication
4. GPRS Detach Indication5. Detach Accept
MS BSS SGSN GGSN MSC/VLR
1. Detach Request2. Delete PDP Context Request
2. Delete PDP Context Response
3. GPRS Detach Indication4. Detach Accept
MS BSS SGSN GGSN MSC/VLR
3. Delete PDP Context Request
4. GPRS Detach Indication
1. Cancel Location2. Detach Request
3. Delete PDP Context Response
5. Detach Request
6. Cancel Location Ack
HLR
HLR
HLR
ISSUE 1 REVISION 2GPRS Review
�MOTOROLA LTD. 2000GPRS01: GPRS Architecture
FOR TRAINING PURPOSES ONLY
1–48
Paging for GPRSDownlinkTransfer
An MS has to be paged by the SGSN before a downlink transfer can occur. The pagingprocess is shown opposite and detailed below:
1. SGSN receives Protocol Data Units (PDUs) for an MS from the network and pagesthe MS.
2. The SGSN sends a BSSGP Paging Request:
– IMSI
– P–TMSI
– Area (Routing Area)
– Channel Needed (indicates GPRS paging)
– QoS (Quality of Service)
– DRX
3. The BSS pages the MS with:
– P–TMSI
– Channel Needed
4. The MS shall respond by use of a Receive Ready or Information frame
5. The BSS, upon receipt of the Logical Link Control (LLC) frame, adds an identifierof the cell and sends the complete LLC frame to the SGSN.
ISSUE 1 REVISION 2 GPRS Review
�MOTOROLA LTD. 2000 GPRS01: GPRS Architecture
FOR TRAINING PURPOSES ONLY
1–49
GPRS Paging Area
MS BSS SGSN
1. PDP PDU
2. Paging Request
3. GPRS Page Request
4. Any LLC Frame
5. Any LLC Frame
ISSUE 1 REVISION 2GPRS Review
�MOTOROLA LTD. 2000GPRS01: GPRS Architecture
FOR TRAINING PURPOSES ONLY
1–50
PDP ContextActivation
PDP Context Activation is shown in the diagram oppsite and follows the sequence shownhere:
1. The MS sends an ‘Activate PDP Context Request’ containing:
– NSAPI
– PDP type
– PDP Address (leaves blank to request dynamic address)
– Access Point Name (reference point to external network, viaDNS)
– QoS Requested
– PDP Configuration Options
2. Security Functions may be executed
3. The SGSN then determines the GGSN to address via a combination of:
– IMSI + NSAPI (= TID)
– (GGSN will allocate dynamic PDP Address if left blank above)
‘Create PDP Context Request’ containing:
– PDP Type
– PDP Address
– Access Point Name
– QoS Negotiated
– TID
– Selection Mode (subscribed or non–subscribed APN)
– PDP Configuration Options
‘Create PDP Context Response’ containing:
– TID
– PDP Address
– BB Protocol (TCP or UDP over Gn)
– Reordering Required (reorder of N–PDUs from GGSN before delivery)
– PDP configuration options
– QoS Negotiated
– Cause
4. The SGSN inserts the NSAPI along with the GGSN address in its PDP context. Ifthe MS requested a dynamic address then it is inserted into the SGSNs PDPcontext. SGSN returns:
– PDP Type
– PDP Address
– NSAPI
– QoS Negotiated
– Radio Priority Level
– PDP Configuration Options
The SGSN is now able to route PDUs between the GGSN and MS.
ISSUE 1 REVISION 2 GPRS Review
�MOTOROLA LTD. 2000 GPRS01: GPRS Architecture
FOR TRAINING PURPOSES ONLY
1–51
PDP Context
MS SGSN GGSN
1. Activate PDP Context Request
2. Security Functions3.Create PDP Context Request
3.Create PDP Context Response
3.Activate PDP Context Accept
PDP Context Activation Procedure
ISSUE 1 REVISION 2GPRS Review
�MOTOROLA LTD. 2000GPRS01: GPRS Architecture
FOR TRAINING PURPOSES ONLY
1–52
In the diagram opposite the network is requesting PDP context activation. In thisinstance the GGSN has received PDP PDUs from an external network and because noPDP context has been previously established then the network has to start thesequence.
The network may employ techniques such as:
Mobile station Not Reachable for GPRS flag (MNRG), the SGSN, GGSN and HLR,which will prevent the GGSN from trying to contact the mobile when it is switched offor out of coverage area.
The GGSN may decide to discard future PDP PDUs as a result of previousunsuccessful delivery attempts.
The GGSN may store the address of the SGSN for a particular PDP context and soeliminate the need for communicating with the HLR.
1. The GGSN has received PDP PDU for an MS and has decided to initiate theNetwork–Requested PDP Context Activation procedure.
2. The GGSN may need to request routing information from the HLR for a mobile it isunaware of the supporting SGSN. The response from the HLR would include:
IMSISGSN AddressMobile State Not Reachable Reason (containing MNRG flag)
3. GGSN sends a ‘PDU Notification Request’ containing:
IMSIPDP TypePDP Address
With the SGSN responding to the request to indicate that it will communicate with theMS.
4. The SGSN sends a ‘Request PDP Context Activation’ containing:
PDP TypePDP Address
5. The PDP context activation procedure detailed earlier is now used to complete theprocess, before PDUs can be transported.
ISSUE 1 REVISION 2 GPRS Review
�MOTOROLA LTD. 2000 GPRS01: GPRS Architecture
FOR TRAINING PURPOSES ONLY
1–53
PDP Context
MS SGSN HLR
Successful Network-requested PDP Context Activation Procedure
GGSN
1. PDP PDU
3.PDU Notfication Request
2. Send Routeing Info for GPRS Ack
2. Send Routeing Info for GPRS
3.PDU Notfication Response
4.Request PDP Context Activation
5. PDP Context Activation Procedure
ISSUE 1 REVISION 2GPRS Review
�MOTOROLA LTD. 2000GPRS01: GPRS Architecture
FOR TRAINING PURPOSES ONLY
1–54
PDP ContextModificationProcedure
In the upper diagram opposite the PDP context can be modified by the procedure shown.This would be requested in particular instances, e.g. change of Quality of Service (QoS)parameters, possibly because the GGSN was unable to provide the full range ofparameters. Thus:
1. The SGSN could request an ‘Update PDP Context Request’
TIDQos Negotiated
2. The GGSN will return with:
TIDQoS Negotiated
3. The SGSN sends a ‘Modify PDP Context’
NSAPIQoS NegotiatedRadio Priority Level
4. The MS should acknowledge the new parameters before they take effect.
PDP ContextDeactivation
The next diagrams detail how the PDP context may be deactivated
PDP Context Deactivation Initiated by MS Procedure:
1. MS sends a ‘Deactivate PDP Context Request’ containing the NSAPI to theSGSN.
2. Security Functions (optional)
3. The SGSN sends a ‘Delete PDP Context Request’ containing TID. GGSNremoves PDP context and sends a valid response.
4. The SGSN sends a ‘response’ to the MS containing the NSAPI.
PDP ContextDeactivationInitiated byGGSN Procedure
1. The GGSN sends a ‘ Delete PDP Context Request’ containing the TID.
2. The SGSN sends a ‘Deactivate PDP Context’ message together with the NSAPI tothe MS, which deletes the PDP context and responds with the same NSAPI to theSGSN.
3. The SGSN then responds with the TID to the GGSN. If the PDP Address wasdynamic, then the GGSN releases the PDP Address for use by a subsequentactivation.
ISSUE 1 REVISION 2 GPRS Review
�MOTOROLA LTD. 2000 GPRS01: GPRS Architecture
FOR TRAINING PURPOSES ONLY
1–55
Altering PDP Context
MS GGSN
4. Modify PDP Context Accept
1.Update PDP Context Request
2.Update PDP Context Response
3. Modify PDP Context Request
PDP Context Modification Procedure
SGSN
MS GGSN
3. Delete PDP Context Request
PDP Context Deactivation Initiated by MS Procedure
SGSN
MS GGSN
1. Delete PDP Context Request
3. Delete PDP Context Accept
PDP Context Deactivation Initiated by GGSN
SGSN
2. Security Functions
3. Delete PDP Context Response
1. Deactivate PDP Context Request
4. Deactivate PDP Context Accept
2. Deactivate PDP Context Accept
2. Deactivate PDP Context Request
ISSUE 1 REVISION 2GPRS Review
�MOTOROLA LTD. 2000GPRS01: GPRS Architecture
FOR TRAINING PURPOSES ONLY
1–56
Routing AreaUpdateProcedure
When an MS is on the move it will cross cell boundaries and will need to update the cellinformation held as part of its Mobility Management (MM) context in the MS and SGSN.
Routing Area updates will be required for an MS on the move and enters a new routingarea (RA) or when a periodic RA update timer has expired.
The RA size is dependent upon network implementation. A RA is identified as a subsetof a single LA and so cannot span more than one location area (LA).
The following rules apply to routing area:
� RAI (Routing Area Identity) = MCC + MNC + LAC + RAC
– (MCC – Mobile Country Code)
� LAI (Location Area Identity) = MCC + MNC + LAC
– (MNC – Mobile Network Code)
� CGI (Cell Global Identity) = LAI + CI
– (LAC – Location Area Code)
– (RAC – Routing Area Code)
If a mobile moves between cells which are supported by a single SGSN and is in theREADY or STANDBY MM state, then it performs an intra–SGSN Routing area Update asshown opposite and detailed below:
1. The MS sends a ‘Routing Area Update Request’ containing:
– Old RAI
– Old P–TMSI
– Update Type (RA update indicated)
2. Security Functions may be executed
3. The SGSN validates the MS and may issue a new P–TMSI
4. If a new P–TMSI is allocated then the MS needs to acknowledge receipt of this.
If the routing area update fails over a number of times, then the MS should enter theIDLE state.
ISSUE 1 REVISION 2 GPRS Review
�MOTOROLA LTD. 2000 GPRS01: GPRS Architecture
FOR TRAINING PURPOSES ONLY
1–57
MS BSS SGSN
2. Security Functions
3. Routeing Area Update Accepts
4. Routeing Area Update Acknowledge
1. Routeing Area Update Request
ISSUE 1 REVISION 2GPRS Review
�MOTOROLA LTD. 2000GPRS01: GPRS Architecture
FOR TRAINING PURPOSES ONLY
1–58
Combined RA/LAUpdate in thecase of InterSGSN RA UpdateProcedure
If the moving MS crosses cell/Routing Area (RA) boundaries which are supported bydifferent SGSNs, then an Inter SGSN RA Update should be performed.
There may be a need to update the Routing Area (RA) and additionally the LA may needto be updated for the IMSI attached mobile. To prevent excess messages to theVLR/HLR, then the LA update can be combined into the GPRS RA update.
A combined RA/LA update is shown opposite and detailed below:
1. The MS sends a ‘Routing Area Update Request’ containing:
– Old RAI
– Old P–TMSI Signature (allocated by SGSN)
– Update Type
The BSS shall add an identifier of the cell where the message was received beforepassing the message to the SGSN.
2. The New SGSN shall be able to determine the Old SGSN from the old RoutingArea identity (RAI) and the new RAI and Location Area Identity (LAI) from the cellidentifier added by the BSS.
The new SGSN context request to the Old SGSN containing:
– Old RAI
– Temporary Logical Link Identity (TLLI)
– Old P–TMSI Signature
– New SGSN Address
In order to get the MM and PDP contexts for the MS.
The Old SGSN responds with:
– MM Context
– PDP Contexts
– LLC Acknowledge
The Old SGSN stores the New SGSN Address until the old MM context is cancelled toallow the Old SGSN to forward data packets to the new SGSN. The Old SGSN starts atimer.
3. Security Functions. Optional
4. New SGSN sends ‘SGSN Context Acknowledge’ to Old SGSN.
5. The Old SGSN starts tunnelling of buffered N–PDUs to the New SGSN. AdditionalN–PDUs received from the GGSN before timer in 2) above expires is alsotunneled.
6. The New SGSN sends ‘Update PDP Context’ to GGSN:
– New SGSN Address, TID and Negotiated Quality of Service (QoS).
– GGSN responds with TID.
ISSUE 1 REVISION 2 GPRS Review
�MOTOROLA LTD. 2000 GPRS01: GPRS Architecture
FOR TRAINING PURPOSES ONLY
1–59
Combined RA/LA Update
MS BSSNEWSGSN
OLDSGSN GGSN
NEWMSC/VLR HLR
OLDMSC/VLR
1. Routing Area Update request
2. SGSN Context Request
2. SGSN Context Response
3. Security Functions
4. SGSN context Acknowledge
5. Forward packets
6. Update PDP Context Request
7. Update location
12a. Update Location
12d. Insert Subscriber Data
12e. Insert Subscriber Data Ack
14 Routing Area Update Accept
15. Routing Area Update Complete
16. TMSI Reallocation Complete
6. Update PDP Context Response
8. Cancel Location
8. Cancel Location Ack
9. Insert Subscriber Data
9. Insert Subscriber Data Ack
10. Update Location Ack
11. Location Updating Request
12b. Cancel Location
12c Cancel Location Ack
12f. Update Location Ack
13. Location Updating Accept
ISSUE 1 REVISION 2GPRS Review
�MOTOROLA LTD. 2000GPRS01: GPRS Architecture
FOR TRAINING PURPOSES ONLY
1–60
7. The New SGSN informs the HLR of the change of SGSN by sending ‘UpdateLocation’:
– SGSN Number
– SGSN Address
– IMSI
8. HLR sends a ‘Cancel Location’ to the Old SGSN in order to remove the MM andPDP contexts.
9. The HLR ‘Inserts Subscriber Data’ into the New SGSN:
– IMSI
– GPRS Subscription Data
10. The HLR acknowledges the ‘Update Location’ with IMSI to New SGSN.
11. The New SGSN ‘Location Update Request’ to the VLR to update the LA,containing:
– New LAI
– IMSI
– SGSN Number
– Location Update Type
12. If the Location Update is Inter–MSC the New VLR informs the HLR. The HLRcancels the old location and inserts the new data into the New VLR.
13. If the location update is successful the new VLR allocates a new TMSI to theSGSN.
14. The New SGSN establishes MM and PDP contexts for the MS and responds tothe MS with:
– P–TMSI
– VLR TMSI
– LLC Acknowledge
– P–TMSI Signature
15. MS confirms allocation of TMSI and P–TMSI and LLC acknowledge.
16. The New SGSN sends TMSI reallocation complete message to VLR.
�MOTOROLA LTD. 2000 GPRS01: GPRS Architecture
FOR TRAINING PURPOSES ONLY
i
Chapter 2
PCU Architecture
ISSUE 1 REVISION 2
�MOTOROLA LTD. 2000 GPRS01: GPRS Architecture
FOR TRAINING PURPOSES ONLY
iii
Chapter 2PCU Architecture i. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Objectives 2–1. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Packet Control Unit (PCU) 2–2. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . The GPRS solution 2–4. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Device Equipage 2–6. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . BSC Site Device Equipage Hierarchy 2–6. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . PCU Site Device Equipage Hierarchy 2–8. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Packet Interface Control Processor 2–10. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . PCU System Processor 2–12. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Packet Resource Processor 2–14. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Initial Configuration 2–16. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Cell INS/OOS 2–18. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . GSL and RSL State Changes 2–20. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Carrier State Changes 2–22. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Carrier Activation 2–24. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Mobile Originated Packet Access and Transfer 2–26. . . . . . . . . . . . . . . . . . . . . . . . . . . . Mobile Terminated Packet Access and Transfer 2–28. . . . . . . . . . . . . . . . . . . . . . . . . . . Gb Interface 2–30. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Frame Relay Functional Unit 2–32. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Gb Functional Unit 2–34. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Gb Router (GR) 2–36. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Gateway Transmit Manager 2–36. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Network Service Test 2–36. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Flow Control Buffer Manager (FBM) 2–36. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Fault Management 2–38. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Fault Detection and Handling System 2–40. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . System Audit Process 2–42. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Configuration Management 2–44. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . PCU Central Authority (pCA) 2–46. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
ISSUE 1 REVISION 2 Objectives
�MOTOROLA LTD. 2000 GPRS01: GPRS Architecture
FOR TRAINING PURPOSES ONLY
2–1
ObjectivesOn completion of this section the student will be able to:
� Understand the generic function of the Packet Control Unit (PCU) Entities
� Identify the functional units of the:
– PCU System Processor
– Packet Resource Processor
– Packet Interface Control Processor
– PCI to PCI Bridge
� Identify the signalling between functional entities of the PCU and the BSS andSGSN
ISSUE 1 REVISION 2Packet Control Unit (PCU)
�MOTOROLA LTD. 2000GPRS01: GPRS Architecture
FOR TRAINING PURPOSES ONLY
2–2
Packet Control Unit (PCU)The new BSS functionality for GPRS mainly resides at the Packet Controller Unit (PCU).The PCU includes the handling of frame relay, Network Services Signalling, BSSGPsignalling, routing of signalling messages, Radio Link Control (RLC) and Media AccessControl (MAC) preload and transferring of user data.
User data is routed to the PCU via the CCU uplink from the BTS to the BSC and thenover E1 to the PCU. At the PCU the RLC Blocks are reformulated in Logical Link Control(LLC) frames and forwarded to the SGSN.
BSSGP signalling and NS signalling shall occur between the PCU and the SGSN usingframe relay protocol. There is also signalling between existing functional process at theBSC such as the BSP and the PCU via the E1 Span, as well as between the PCU andChannel Coders.
ISSUE 1 REVISION 2 Packet Control Unit (PCU)
�MOTOROLA LTD. 2000 GPRS01: GPRS Architecture
FOR TRAINING PURPOSES ONLY
2–3
SGSN
PCUBSC
BTS
NS – SIG
BSSGP SIG
GSL
GDS (TRAU)
RSL
RTF
GDS (LAPD)
ISSUE 1 REVISION 2Packet Control Unit (PCU)
�MOTOROLA LTD. 2000GPRS01: GPRS Architecture
FOR TRAINING PURPOSES ONLY
2–4
The GPRSsolution
The GPRS solution is a compact PCI based solution. The CPCI–PCU cabinet isconnected to the BSC using E1 spans and the SGSN by E1 using frame relay as thenetwork service.
The Packet Control Unit (PCU) comprises 3 different boards which are defined below:
MPROC
The MPROC is the system slot processor which is responsible for bus arbitration andCPCI clock generation. It shall contain interface and BSSGP protocol functions and shallbe called the PCU System Processor. Only one PCU System Processor (PSP) may beequipped at a PCU.
DPROC
The DPROC boards are non–system slot boards which have two PMC sockets and canhost two different functions. The DPROC can be configured as either a Packet InterfaceControl Processor (PICP) or as a Packet Resource Processor (PRP).
If configured as the PICP the DPROC shall contain up to 2 PMC modules to provide theE1 interfaces. The E1 interface can support the Gb interface or the GPRS Data Stream(GDS) interface, including the GPRS Signalling Link (GSL).
If configured as a PRP, the DPROC performs Air Interface scheduling and either one ortwo of the PMC sockets may also be used for the PMC modules which provide GDS linksfor data only not signalling. A single processor can support a pool of 120 radio timeslotsof which 30 radio timeslots can be active at any one time.
Bridge
The Bridge known as the PCI to PCI Bridge (PPB) allows an MPROC to be linked to aseparate bus. The PPB and MPROC are paired boards.
ISSUE 1 REVISION 2 Packet Control Unit (PCU)
�MOTOROLA LTD. 2000 GPRS01: GPRS Architecture
FOR TRAINING PURPOSES ONLY
2–5
PCU CageP
RP
or
PIC
P
PR
P o
r P
ICP
PR
P o
r P
ICP
PR
P o
r P
ICP
PR
P o
r P
ICP
PR
P o
r P
ICP
PS
P
PP
B
PS
P
PR
P o
r P
ICP
PR
P o
r P
ICP
PR
P o
r P
ICP
PR
P o
r P
ICP
PR
P o
r P
ICP
PR
P o
r P
ICP
1 2 3 4 5 6 7 8 15 1613 14
PP
B
9 10 11 12
ISSUE 1 REVISION 2Device Equipage
�MOTOROLA LTD. 2000GPRS01: GPRS Architecture
FOR TRAINING PURPOSES ONLY
2–6
Device Equipage
BSC Site DeviceEquipageHierarchy
Two new devices, the Packet Control Unit (PCU) and GPRS Signalling Link (GSL) maybe equipped and managed at the BSC. The PCU appears much like a remote site at theBSC and may only be equipped at the BSC.
A PCU device is equipped and managed at the BSC. A GSL device is managed at boththe BSC and the PCU site. The operator must equip the GSL at the PCU site and acorresponding GSL device will be equipped at the BSC.
ISSUE 1 REVISION 2 Device Equipage
�MOTOROLA LTD. 2000 GPRS01: GPRS Architecture
FOR TRAINING PURPOSES ONLY
2–7
BSC Site Device Equipage Hierarchy
BSC SITE
BTS SITE PCU
CELL CAGE
COMB KSW GCLK BSP BTP GPROC CSFP DHP EAS MSI
MMS*
LCF OMF BTF XBL MTL OML CBL GSL*
PATH
DRI
RTF
16Kbps RSL
Associated RTF
64Kbps RSL
CAB
*Indicates auto-equipped device
ISSUE 1 REVISION 2Device Equipage
�MOTOROLA LTD. 2000GPRS01: GPRS Architecture
FOR TRAINING PURPOSES ONLY
2–8
PCU Site DeviceEquipageHierarchy
When a Packet Control Unit (PCU) device is equipped at the BSC a CAB and CAGE willautomatically be equipped at the PCU site.
Devices managed under the PCU site use the text “pcu” rather than a location number incommands, e.g. “equip pcu DPROC”.
ISSUE 1 REVISION 2 Device Equipage
�MOTOROLA LTD. 2000 GPRS01: GPRS Architecture
FOR TRAINING PURPOSES ONLY
2–9
PCU Site – Device Equipage Hierarchy
CAB*
CAGE*
DPROC (PICP) DPROC (PRP)PSP
MSI
MMS*
GDS (LAPD)GBL
GSL
* Indicates auto-equipped device
When a PCU is equipped at the BSC, a CAB and CAGE device will beautomatically equipped at the PCU site. The PCU device exists only at theBSC. The highest device in the PCU site equippage hierarchy is the CABdevice.
GDS (TRAU)
MSI
MMS*
GDS (TRAU)
ISSUE 1 REVISION 2Device Equipage
�MOTOROLA LTD. 2000GPRS01: GPRS Architecture
FOR TRAINING PURPOSES ONLY
2–10
Packet InterfaceControlProcessor
The Packet Interface Control Processor (PICP) is a function residing on a DPROC. APICP is made up of functional units.
A Gb functional unit to terminate the Gb links, the function to determine whether anLogical Link Control (LLC) frame is user data, SGSN – MS signalling or BSSGPsignalling. The LLC frame is then routed to the appropriate board based on LLC frametype.
� Route signalling for paging messages to appropriate cell.
� Routing of flushing of queued SDU at appropriate cell
� Routing flow control of downlink traffic
� Queuing MS Packets based on priority queues
GPRS Signalling Link (GSL) LAPD functional unit for synchronisation of LAPD link overGSL between the PCU and the BSC.
A TRAU functional unit created for the synchronisation and handling of Packet ControlUnit (PCU) frames between the PCU and the BSC.
A PICP Status functional unit for debugging mechanisms, statistics and alarms.
Finally an I/O functional unit is created for routing messages between the functional unitson the PICP and the functional units on the PCU System Processor (PSP).
ISSUE 1 REVISION 2 Device Equipage
�MOTOROLA LTD. 2000 GPRS01: GPRS Architecture
FOR TRAINING PURPOSES ONLY
2–11
Packet Interface Control Processor
TRAU I/O
GSLLAPDMGR
TRAU FU
GBFU
FRAME RELAY
BSC Comm E1
BSC Comm E1
Gb link E1
Gb link E1
PMC 860 Dual E1
PPC 860 Dual E1
PMC 860 Dual E1
TOGWMFUs
Toother GB FUs
Gateway Manager
(GWM)
PP750
PICP
To PRP To PSP
GSL/TRAUFrame Relay
I/O
PICP status(alarms, stats,debugging)
PICP
ISSUE 1 REVISION 2Device Equipage
�MOTOROLA LTD. 2000GPRS01: GPRS Architecture
FOR TRAINING PURPOSES ONLY
2–12
PCU SystemProcessor
The PCU System Processor (PSP) resides on the MPROC. As well as control of busarbitration the PSP has the following functional units:
GB Manager
GB manager handling blocking/unblocking and reset
Gateway Manager (GWM)
The Gateway Manager handles the following function:
1. Code loading of objects during initialisation and reset
2. Board initialisation and startup for software processes
3. Handling database information and changing affected functional units
4. Fault management functions (i.e. fault detection, fault recovery, etc.)
5. Collection of statistics from functional units and forwarding to the CSP on theGPROC
6. Collection of cell list for BSC – BTS Dynamic Allocation purposes
7. Audit Procedures
8. Alarm Collection and Relaying
9. Cell resource sharing (i.e. balancing of cells) across equipped PRPs
The PCU GWM acts as the interface to the BSC FM, SM, IP, CM, MMI, CP, Statsprocess, CSP as well as RSS.
An I/O function is created on the PSP for communication with the Packet ResourceProcessor (PRP) and PICP functional units.
Finally a PSP status unit provision for delaying mechanisms, alarms, stats.
ISSUE 1 REVISION 2 Device Equipage
�MOTOROLA LTD. 2000 GPRS01: GPRS Architecture
FOR TRAINING PURPOSES ONLY
2–13
PCU System Processor (PSP)
GSL/TRAU Frame Relay
I/O
PICP status(alarms, stats,
debugging)
PICP
(GatewayManager)
PSP status(alarms, stats,
debugging)
PSP
Interface to: CMFM
RSSCP
CSP
Gb manager
PRP status(alarms, stats,
debugging)
Cell 1
UPLINK
PacketScheduler
Power controlTiming
Advance
DOWNLINK
Paging,Sys Info,Accessgrants
RLC Segmenting
LLC Cat
I/O
Cell 2
Cell N
PRP
FCBM
I/O
ISSUE 1 REVISION 2Device Equipage
�MOTOROLA LTD. 2000GPRS01: GPRS Architecture
FOR TRAINING PURPOSES ONLY
2–14
Packet ResourceProcessor
The Packet Resource Processor (PRP) is where all radio related processing takes place.The PRP performs all of RLC/MAC processing, air interface scheduling and framesynchronisation on the BTS facing channels. The following functional units provide thisfunctionality:
Packet Scheduler
Packet Scheduler is created to handle all scheduling of Packet Data Channels (PDCHs)on a per call per Quality of Service (QoS) level basis.
CCCH Paging Manager
The CCCH Paging Manager processes the paging messages coming from the SGSN tothe BSC/BTS.
Downlink Segmentor
Downlink Segmentor segments Logical Link Control (LLC) frames into Radio Link Control(RLC) data blocks to be transmitted over the air interface.
Uplink Concentrator
Uplink Concentrator concentrates all the RLC data blocks for a Temporary Block Flow(TBF) into a LLC frame.
Timeslot Resource Shifter (TRS)
Determines which TS are active in the PRP board to support GPRS traffic.
System Information Manager (SYM)
The Systems Information Manager builds and sends GPRS system information over theBCCH.
I/O Function
I/O function is used for routing between the functional units on the PRP and the PICPand PSP/
Flow Control Buffer Management (FBM)
Flow Control Buffer management is a functional unit residing on the PRP to handle allpackets received by the SGSN.
ISSUE 1 REVISION 2 Device Equipage
�MOTOROLA LTD. 2000 GPRS01: GPRS Architecture
FOR TRAINING PURPOSES ONLY
2–15
PCU Resource Processor
GSL/TRAU Frame Relay
I/O
PICP status(alarms, stats,
debugging)
PICP
(GatewayManager)
PSP status(alarms, stats,
debugging)
PSP
Interface to: CMFM
RSSCP
CSP
Gb manager
PRP status(alarms, stats,
debugging)
Cell 1
UPLINK
PacketScheduler
Power controlTiming
Advance
DOWNLINK
Paging,Sys Info,Accessgrants
RLC Segmenting
LLC Cat
I/O
Cell 2
Cell N
PRP
FCBM
I/O
ISSUE 1 REVISION 2Device Equipage
�MOTOROLA LTD. 2000GPRS01: GPRS Architecture
FOR TRAINING PURPOSES ONLY
2–16
InitialConfiguration
1. To begin Initialisation, the BSC IP will instruct the BSC Exec DISP to bring up theGSL as specified in the database. On the PCU at the PCU System Processor(PSP) an IP (pIP) and EXEC DLSP bring up the other side of the default GSL.
2. Once communication is established the BSC IP queries the pIP for the set ofobjects currently residing at the PCU to determine which new objects requiresending. The required set are transferred from the BSC to the PCU. Thedatabase is included in this transfer.
3. The PSP, once the download is complete, will determine which card is in each slotof the PCU and download the appropriate objects and database information toeach DPROC and PMC. The database is stored in non–volatile memory at thePSP.
4. The PSP now distributes the configured number of cells in the database across thePRPs. It also creates router tables of cell to router and distributes this table to allboards to allow communications.
5. The Gateway Manager (GWM) now initiates process startup at the PRPs andPICPs
6. The GBL interface is now initialised as the GSL is brought into service. The PSPnow indicates to the BSC CA that the PCU is enabled and registers for calls.
ISSUE 1 REVISION 2 Device Equipage
�MOTOROLA LTD. 2000 GPRS01: GPRS Architecture
FOR TRAINING PURPOSES ONLY
2–17
pIP + BSC IP bring up default GSL
BSC IP queries PCU pIP for set of objects
BSC IP download objects if required
pIP downloads appropriate objects to each DPROC + PMC
PSP distributes configured cells across PRPs
GWM starts up PRPs + PICPs
GBL initialised + GSL brought into service
PSP indicates PCU enabled + registers for cells
ISSUE 1 REVISION 2Device Equipage
�MOTOROLA LTD. 2000GPRS01: GPRS Architecture
FOR TRAINING PURPOSES ONLY
2–18
Cell INS/OOS
For cells using the BCCH, when a cell comes in service the BSC CA will send a CellState Change message to the Gateway Manager (GWM) indicating INS. The GWMresponds with an acknowledgement.
The GWM forwards this information to the GB manager who acknowledges and indicatesto the correct Packet Resource Processor (PRP) that the cell is now available for GPRS.
The Packet Resource Manager (PRP) will formulate new packet system informationmessages to the Cell Resource Manager (CRM) indicating Quality of Service (QoS)barred. The GBM also notifies the SGSN via a BSSGP Virtual Circuit (BVC) unblock thatthe cell has come into service. After acknowledgement from the SGSN the GBM willindicate that the cell is in service to the PRP, will generate system information and unbarthe QoS levels via the CRM.
Cell OOS follows the same format only that the BVC block message to the SGSN fromthe GBM is independent of the PRP acknowledgement of GPRS being unavailable in thecell.
ISSUE 1 REVISION 2 Device Equipage
�MOTOROLA LTD. 2000 GPRS01: GPRS Architecture
FOR TRAINING PURPOSES ONLY
2–19
BSC CA GWM GBM PRP SGSN CP RSS CCU
Cell StateChangeIns
Cell Ins
Cell StateChangeAck
Cell Ins Ack
GPRSAvailable
System Information
BCCH Sys Info
GPRS Available Ack
New PSI (QOS Barred)
BVC Unblock
BVC Unblock Ack
Cell Ins
Cell Ins
New PSI (QOS Un-barred)
New GPRS Sys Info
New GPRS Sys Info
ISSUE 1 REVISION 2Device Equipage
�MOTOROLA LTD. 2000GPRS01: GPRS Architecture
FOR TRAINING PURPOSES ONLY
2–20
GSL and RSLState Changes
GPRS Signalling Link (GSL) State Changes
The PCU Central Authority CA (pCA) maintains a table on the current GSLs available.When a GSL goes out of service the pCA will update the tables. When the last GSLgoes out of service the BSC FTP will create a GSL alarm and the PCU will reset. TheBSC and pCA shall attempt to restart the link. If the resynchronisation procedures areunsuccessful then the PCU is declared disabled and GPRS resources (air timeslots andterrestrial backing) are made available for circuit switched use.
RSL State Change
When an RSL changes state the PCU receives notification for all the cells under thatspecified site. If the RSL comes back into service the specified cells come back intoservice.
At BTS site initialisation the BTS initiates registration with the BSC CA for the PCU. TheBTS Cell Resource Manager (CRM) is informed when the PCU becomes available orunavailable.
ISSUE 1 REVISION 2 Device Equipage
�MOTOROLA LTD. 2000 GPRS01: GPRS Architecture
FOR TRAINING PURPOSES ONLY
2–21
GPRS Signalling Link (GSL) State Changes
Last GSL OOS
– GSL ALARM
– PCU RESET
– GB DISCONNECT
RSL State Changes
– PCU notified of cell state change
– BTS CRM QUERY BSC CA for PCU STATUS
ISSUE 1 REVISION 2Device Equipage
�MOTOROLA LTD. 2000GPRS01: GPRS Architecture
FOR TRAINING PURPOSES ONLY
2–22
Carrier StateChanges
The respective packet scheduler for the cell receives Carrier State Change messagefrom the Cell Resource Manager (CRM) when a GPRS carrier it is responsible for goesout of service. The Packet Scheduler (PS) notifies the SGSN of the cell being out ofservice via the GB manager.
If the carrier out of service is not the BCCH carrier then new system information may besent to indicate GPRS unavailable.
ISSUE 1 REVISION 2 Device Equipage
�MOTOROLA LTD. 2000 GPRS01: GPRS Architecture
FOR TRAINING PURPOSES ONLY
2–23
CRM PS/SYSINFO
GBM SGSN
CARRIER STATECHANGE
CELL OOS
BVC BLOCK
CARRIER STATECHANGE ACK
BVC BLOCK ACK
ISSUE 1 REVISION 2Device Equipage
�MOTOROLA LTD. 2000GPRS01: GPRS Architecture
FOR TRAINING PURPOSES ONLY
2–24
Carrier Activation
When the BTS CRM startup, the CRM will register with the BSC CA for PCU status. TheCA informs the CRM when the PCU becomes available.
The CRM configures all the GPRS timeslots with the RSS and Channel Coders to PacketData Channels (PDCHs). The CRM now notifies the Packet Resource Processor (PRP)that the GPRS radio timeslot activation was successful.
The PRP now requests via the PCU System Processor (PSP) for connection of theGPRS Data Stream (GDS) timeslots to radio timeslots. Additionally, the GatewayManager (GWM) connects the PCU timeslots to the appropriate GDS timeslot.
Once the connections are set up the PRP initiates synchronisation procedures with theChannel Coders. Once the site and carrier are in, the CRM, with help from the PRPgradually unbars the cell and indicates GPRS available.
ISSUE 1 REVISION 2 Device Equipage
�MOTOROLA LTD. 2000 GPRS01: GPRS Architecture
FOR TRAINING PURPOSES ONLY
2–25
BSC SM BSC CA BTS PSP PICPPRP (per cell procedures)
GPRS Carrier Status
Note that the BTS shall initiate entitynotification registrationat site init and RSLinservice
BSC CA has beennotified the PCU is in–service
PCU Available
PCU Ins
PCU Connection Requests (radio channel/PCU timeslot)
PCU Connection Requests (radio channel/PCU timeslot)
OK
PCU Connection Assignments
PCU Connection Assignments
Packet SystemInformation
(to bar mobiles)
Initiate synchronizationwith the Channel Coders
ISSUE 1 REVISION 2Device Equipage
�MOTOROLA LTD. 2000GPRS01: GPRS Architecture
FOR TRAINING PURPOSES ONLY
2–26
MobileOriginatedPacket Accessand Transfer
On initiation of uplink packet transfer the BSS shall provide the capability to handle apacket channel request on a Packet Associated Control Channel (PACCH). On receiptof a RACH the RSS forwards the RACH to the Packet Scheduler. The resource isassigned by the Packet Scheduler and the Access Grant functional unit generates theimmediate assignment which is returned to the RSS for transmission on AGCH.
After access and assignment the Uplink functional unit will collect all the radio blocks sentfrom the MS, identified by the Temporary Flow Indentifier (TFI) and reassemble all theradio blocks for each TFI into an Logical Link Control (LLC) frame. The LLC frame isthen sent to the Gb functional unit to be placed in an uplink queue to be serviced byFrame Relay and sent to the SGSN.
ISSUE 1 REVISION 2 Device Equipage
�MOTOROLA LTD. 2000 GPRS01: GPRS Architecture
FOR TRAINING PURPOSES ONLY
2–27
RSS
CHANNEL REQUEST
MS ACCESSGRANT FU
CHANNEL REQUEST (ON THE RACH)
IMMEDIATE ASSIGNMENTIMMEDIATE ASSIGNMENT (ON THE AGCH)
MS UPLINK FU
ASSEMBLE FU
GB FR SGSNACCESS ANDASSIGNMENT
PDTCH
PDTCH
PDTCH
DATA BLOCK
DATA BLOCK
DATA BLOCK
PACCH
PDTCH
PDTCH
PACCH
TEMPORARY PACKET ACK/NACK
DATA BLOCK
DATA BLOCK (LAST)
FINAL PACKETACK/NACK
ISSUE 1 REVISION 2Device Equipage
�MOTOROLA LTD. 2000GPRS01: GPRS Architecture
FOR TRAINING PURPOSES ONLY
2–28
MobileTerminatedPacket Accessand Transfer
On receipt of a Paging message from the SGSN, the pCA will forward a Packet PagingRequest over the PCH. The MS will respond with a Packet Channel Request on thePACH and following an assignment will move to the assigned Packet Data Channels(PDCHs) and send a Packet Paging Response, which has a Temporary Logical LinkIdentity (TLLI) and an Logical Link Control (LLC) frame with a TLLI.
On receipt of the LLC frame from the SGSN, the Frame Relay unit strips out the FrameRelay header and passes the frame onto the Gb functional unit, which strips off theBSSGP header and passes the frame down to the segmentation functional unit, whichsplits the frame into RLC/MAC radio blocks for sending on PDCHs assigned to themobile.
ISSUE 1 REVISION 2 Device Equipage
�MOTOROLA LTD. 2000 GPRS01: GPRS Architecture
FOR TRAINING PURPOSES ONLY
2–29
PACKET CHANNEL REQUEST
MS ACCESSGRANT FU
(ON THE RACH)
PACKET IMMEDIATE ASSIGNMENT(ON THE AGCH)
MS DL FU SEGMENTATI
ON
GB FR SGSNACCESS ANDASSIGNMENT
PDTCH
PDTCH
PDTCH
DATA BLOCK
DATA BLOCK
DATA BLOCK (POLLING)
PACCH
PDTCH
PACCH
PACCH
TEMPORARY PACKET ACK/NACK
DATA BLOCK
DATA BLOCK (LAST POLLING))
FINAL PACKET ACK/NACK
PACKET RESOURCE REQUEST
PACKET RESOURCE ASSIGNMENTOPTIONAL
PACCH
PACCH
PDTCHDATA BLOCK
ISSUE 1 REVISION 2Device Equipage
�MOTOROLA LTD. 2000GPRS01: GPRS Architecture
FOR TRAINING PURPOSES ONLY
2–30
Gb Interface
The interface to the SGSN is a new network interface for the BSS defined by GPRS asthe Gb interface. The Gb interface is a packet interface using Frame Relay PVCs. Twotypes of information flow on the Gb interface, signalling and data. Two protocols workover the Gb interface, these are the Base Station System GPRS Protocol (BSSGP)protocol and the underlying NS (Frame Relay).
Frame Relay includes Network and Link layer functions. It performs data transmission,load sharing and link layer node management.
The BSSGP layer provides Quality of Service (QoS), radio and routing and signalling fornode management between the BSS and the SGSN. The BSS provides downlink flowcontrol between the BSS and the SGSN, it consists of:
� One queue per cell provided in the BSSGP layer
� Flow Control
ISSUE 1 REVISION 2 Device Equipage
�MOTOROLA LTD. 2000 GPRS01: GPRS Architecture
FOR TRAINING PURPOSES ONLY
2–31
PCU SGSN
BSSGP
NS
FR
EI
BSSGP
NS
FR
EI
ISSUE 1 REVISION 2Device Equipage
�MOTOROLA LTD. 2000GPRS01: GPRS Architecture
FOR TRAINING PURPOSES ONLY
2–32
Frame RelayFunctional Unit
At the time of system setup of the Packet Control Unit (PCU), the Frame Relay functionalunit will be initialised. The transmit and receive buffers and the timer resources areinitialised on the Packet Interface Control Processor (PICP) for Layer 2 buffering of uplinkand downlink data on the Gb interface.
The Frame Relay functional unit will hold in Non Volatile memory a mapping of local DLCIand the physical interface (i.e. E1). The SGSN also holds a similar mapping. Each PCUwill only be able to connect to one and only one SGSN.
DLCI 0 is used to send PVC status messages. The maximum number of DLCIs that canbe indicated in the frame size of 1600 octets is 318. This means that 318 DLCIs can beset up per physical bearer. The status messages are used to confirm the end to endavailability of all PVCs on a GBL.
ISSUE 1 REVISION 2 Device Equipage
�MOTOROLA LTD. 2000 GPRS01: GPRS Architecture
FOR TRAINING PURPOSES ONLY
2–33
Frame Relay Functional Unit
– Transmit and Receive Buffers
– NVRAM MAPPING DLCI + GBL
– DLCI O PVC STATUS MESSAGES
ISSUE 1 REVISION 2Device Equipage
�MOTOROLA LTD. 2000GPRS01: GPRS Architecture
FOR TRAINING PURPOSES ONLY
2–34
Gb FunctionalUnit
The Gb functional unit is divided into the following processes:
� Gb Manager (GBM)
� Gb Router (GR)
� Gateway Transmit Manager (GTM)
� Network Service Test (NST)
� Flow Control Buffer Manager (FBM)
GBM
The GB Manager manages BSSGP Virtual Circuit (BVC) (cell) and NS–VC (PVC)management procedures. The Gb Manager (GBM) maintains internal tables monitoringthe state of BVCs and NS–VCs and the mapping between them. The GBM isresponsible for the monitoring of the Gbl link status and generating the appropriatealarms. The GBM will inform the Gateway Manager (GWM) of any change in GBLstatus.
The GBM manages the BVC and NS–VC block, reset and unblock procedures. It shallgenerate the appropriate alarms. The FR functional unit at the Packet Control Unit(PCU) shall detect when the last GBL goes out of service and reports it to the GBM,which in turn reports the event to the pFTP and informs the pFCP to generate an alarm.
The GBM is also responsible for sending Radio Status messages to the SGSN (i.e. BTSnot MS) and the handling of Routing Area (RA) capability procedures.
ISSUE 1 REVISION 2 Device Equipage
�MOTOROLA LTD. 2000 GPRS01: GPRS Architecture
FOR TRAINING PURPOSES ONLY
2–35
Gb Functional Unit
NST
Gb Manager
Flow ControlBuffer Manager
GatewayTransmitManager
Gb Router
ISSUE 1 REVISION 2Device Equipage
�MOTOROLA LTD. 2000GPRS01: GPRS Architecture
FOR TRAINING PURPOSES ONLY
2–36
Gb Router (GR)
The Gb Router (GR) validates and routes downlink PDUs. The GR routes the downlinkPDUs to the appropriate Flow Control Buffer Manager (FBM) which will pass the PDU tothe air functional units for transmission over the air.
The GR is also responsible for the routing of paging messages to the appropriate Pagingfunction on a Packet Resource Processor.
GatewayTransmitManager
The Gateway Transmit Manager (GTM) gathers and transmits uplink PDUs on thecorrect NS–VC. The air functional unit concatenates the uplink Logical Link Control(LLC) frame and the load sharing function chooses the appropriate NS–VC from theNS–VC group serving the BSSGP Virtual Circuit Identifier (BVCI) for transmission by theGbFu to the SGSN. The GTM gathers the PDUs from the various cells and passes themto the FR functional unit for transmission over a given DLCI and Gbl.
Network ServiceTest
The Network Service Test (NST) periodically tests NS–VCs to see if they are alive. TheNST also sends test messages on each alive NS–VC and responds to test messagesfrom the SGSN by sending back an acknowledgement on the same NS–VC.
Flow ControlBuffer Manager(FBM)
The Flow Control Buffer Manager ensures that opened downlink LLC frames aretransmitted over the air within their delay class limitations. The FBM performs flowcontrol using either XON/XOFF or the ‘leaky bucket’ algorithm. When using the ‘leakybucket’ algorithm the configurable parameters of the maximum size of the downlink bufferand maximum data rate the SGSN can transmit data to the mobiles will govern thealgorithm. The FBM will send at a configurable interval flow control messages to theSGDN to govern the downlink data transfer.
The FBM is also responsible for the flushing of a mobile LLC PDUs from a cell queue forthat mobile and informing the packet scheduler to delete the mobiles context for that cell.
ISSUE 1 REVISION 2 Device Equipage
�MOTOROLA LTD. 2000 GPRS01: GPRS Architecture
FOR TRAINING PURPOSES ONLY
2–37
NST
– Periodic testing of NSVCs
– Ensure queued dl LLC frames transmitted within their delay class
– Flushing of LLC frames
FBM
ISSUE 1 REVISION 2Device Equipage
�MOTOROLA LTD. 2000GPRS01: GPRS Architecture
FOR TRAINING PURPOSES ONLY
2–38
FaultManagement
The Fault Management software at the Packet Control Unit (PCU) may be split into twomain areas; the fault detection and handling system and the Central Authority (pCA).The Fault Management software is responsible for the detection of any alarms anddeciding upon any hardware /software reconfiguration in response to these alarms.
The PCU Central Authority, under the direction of the fault handling and detectionsystem, is responsible for carrying out the reconfiguration.
ISSUE 1 REVISION 2 Device Equipage
�MOTOROLA LTD. 2000 GPRS01: GPRS Architecture
FOR TRAINING PURPOSES ONLY
2–39
Fault Management
Fault Detection and Handling
CentralAuthority
ISSUE 1 REVISION 2Device Equipage
�MOTOROLA LTD. 2000GPRS01: GPRS Architecture
FOR TRAINING PURPOSES ONLY
2–40
Fault Detectionand HandlingSystem
This area of Operations and Maintenance is responsible for the detection, collection,reporting and deciding actions to be taken if faults appear in the Packet Control Unit(PCU).
The system is based around three processes:
1. The Fault Collection Process (pFCP)
This process exists at every DPROC at a site. It collects alarm reports from all processesthat exist on its particular DPROC. This process automatically acknowledges receipt ofan alarm and then passes all alarms indications up to the fault translation process.
2. Fault Translation Process (pFTP)
This process exists on the PCU System Processor (PSP) as part of the GWM functionalunit, and works with various processes to keep the integrity of the site. All alarms at thePCU are reported to the pFTP. The pFTP forwards alarms to the Agent at the BSC andgenerates messages to the pCA for device transitions, as needed, based on faultsreported.
3. System Audit Process (pSAP)
The System Audit Process exists on every DPROC at a site. This process periodicallyaudits the PCU software and any faults found are forwarded to the Fault TranslationProcess via the Fault Collection Process.
ISSUE 1 REVISION 2 Device Equipage
�MOTOROLA LTD. 2000 GPRS01: GPRS Architecture
FOR TRAINING PURPOSES ONLY
2–41
Fault Translation Process
OMC-R
AGENT
pCA
pFTP
pFCP
PCU DEVICES
ISSUE 1 REVISION 2Device Equipage
�MOTOROLA LTD. 2000GPRS01: GPRS Architecture
FOR TRAINING PURPOSES ONLY
2–42
System AuditProcess
The Packet Control Unit (PCU) System Audit Process follows much the samearchitecture as the BSS. A Site System Audit Process (pSSAP) resides on the PCUSystem Processor (PSP) as part of the Gateway Manager (GWM) functional unit. ThePSP performs the audits of the PCU and communicates directly with the BSC MMI andSAP.
The DPROCs contain a local process responsible for auditing the DPROC upon which itresides.
The SAP will detect faulty/degrading hardware and software through the use of audittests and if a failure is detected it is reported to the pfTP.
There are three types of System Audit Process:
� Site System Audit Process – one per site and will result in an audit of all availablehardware in the PCU.
� Cage System Audit Process – has the same functionality as the Site System AuditProcess. This has been provided for future multi cage PCUs.
� Device System Audit Process – responsible for auditing the device on which itresides.
The System Operator can turn the audit functionality ON/OFF on a device, cage or persite basis. The System Operator can modify the audit schedules for a specific device orcage, e.g. device audit.
ISSUE 1 REVISION 2 Device Equipage
�MOTOROLA LTD. 2000 GPRS01: GPRS Architecture
FOR TRAINING PURPOSES ONLY
2–43
System Audit Process
� Monitor the status of the PCU
� Three types of Audit process
– Site System Audit Process (pSSAP)
– Cage System Audit Process (pCSAP)
– Device Audit Process
� MMI Control (OMC, TTY)
ISSUE 1 REVISION 2Device Equipage
�MOTOROLA LTD. 2000GPRS01: GPRS Architecture
FOR TRAINING PURPOSES ONLY
2–44
ConfigurationManagement
The Configuration Management (CM) Software is responsible for managing and updatingthe main configuration database at either a BSC, BTS or PCU. This database isdownloaded as an object file and contains all the site parameters such as siteconfiguration and device functionality distribution.
The CM process at the BSC communicates with the pCM process in the same manneras a remote BTS. If database changes are listed as at the PCU then the BSC CM willforward the changes to the PCU Configuration Management (pCM). There is no MMIfunctionality at the PCU so the pCM has reduced functionality compared to the CM at theBSC.
The pCM process resides on the PCU System Processor (PSP) as part of the GatewayManager functional unit. The pCM receives the CM database object from the BSC. Aftertranslation the database object is stored on compact flash on the PSP. The translatedobject is cross–loaded to the DPROC boards equipped in the database with code objectsat initialisation.
ISSUE 1 REVISION 2 Device Equipage
�MOTOROLA LTD. 2000 GPRS01: GPRS Architecture
FOR TRAINING PURPOSES ONLY
2–45
Configuration Management
BSC CM BSC CA
PSP pCM
Compact Flash Memory
MASTERDATABASE
Slave pCM Slave pCM
Database Copy
Database Copy
DPROC DPROC
ISSUE 1 REVISION 2Device Equipage
�MOTOROLA LTD. 2000GPRS01: GPRS Architecture
FOR TRAINING PURPOSES ONLY
2–46
PCU CentralAuthority (pCA)
On site initialisation, the central authority (pCA) process is created and queries thedatabase to obtain site configuration and device equipage data. The central authority isthen responsible for creating all the necessary software processes on the DPROCS, aswell as downloading and ”bringing into service” all peripheral boards and devices. Oncompletion of site initialisation, the pCA then works as an independent process with adynamic database keeping track of the state of all devices and software functions on itssite.
If a fault indication occurs at the site and the fault detection and handling system decidesthat a device or software identity must be taken out of service, then it is the pCA that willperform this task. If the fault detection and handling system decides to bring anotherdevice or software entity into service, in response to that alarm indication then it is thepCA that will supervise the downloading/initialisation of the device or software entity. Itmay be the case that the system operator wishes to remove or insert a device fromservice with a MMI command, it is the pCA that carries out the action.
In both of the above cases, once the reconfiguration has occurred, the pCA will updatethe device state of each entity in its dynamic database.
However, if the site is re–initialised the pCA process is lost and the device states areerased. The pCA is then created by the initialisation process, the pCA reads thedatabase and the initialisation procedure starts again.
The pCA is responsible for informing the router process when software processes arecreated, destroyed or moved. This allows the router process to modify the router tableswhich are used by the executive to support the ”flexible interprocess communications”feature.
ISSUE 1 REVISION 2 Device Equipage
�MOTOROLA LTD. 2000 GPRS01: GPRS Architecture
FOR TRAINING PURPOSES ONLY
2–47
PCU Central Authority Functions
A. Site Initialisation
1. Queries for database for site configuration and equipage.
2. Downloading software to the hardware
3. Create Software on DPROCS
4. Creating routing tables
5. Creating state tables
B. Initiate and Direct Configuration Changes
1. Hardware
2. Software
3. Updating Router
4. Updating state tables
ISSUE 1 REVISION 2Device Equipage
�MOTOROLA LTD. 2000GPRS01: GPRS Architecture
FOR TRAINING PURPOSES ONLY
2–48
�MOTOROLA LTD. 2000 GPRS01: GPRS Architecture
FOR TRAINING PURPOSES ONLY
i
Chapter 3
BSS/PCU Commands
ISSUE 1 REVISION 2
�MOTOROLA LTD. 2000 GPRS01: GPRS Architecture
FOR TRAINING PURPOSES ONLY
iii
Chapter 3BSS/PCU Commands i. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Objectives 3–1. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
PCU 3–2. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . PSP 3–2. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Dependencies 3–2. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
DPROC 3–4. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
MSI 3–6. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
MMS Device 3–8. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . MMS Priority 3–8. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . GDS or GBL 3–8. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
GPRS Data Stream (GDS) 3–10. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
GPRS Signalling Link (GSL) 3–12. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
GBL Device 3–14. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
LCF 3–16. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
GPRS Carrier 3–18. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Reconfiguration of suitable GPRS PDCHs 3–20. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
BSSGP Virtual Circuit (BVC) Blocking and Unblocking 3–22. . . . . . . . . . . . . . . . . . . . . . . . . . .
BVC Reset 3–24. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Flow Control 3–26. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Network Service Block, Reset, Unblock, Test 3–28. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Network Service Test 3–30. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Network Service 3–32. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Network Service Virtual Connection Group 3–34. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Gb Addressing 3–36. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Network Service Virtual Connection 3–38. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
BSSGP Virtual Circuit Identifier (BVCI) 3–40. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
GPRS Signalling BVCI 3–42. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Routing Area 3–44. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
N3102 3–46. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
ISSUE 1 REVISION 2 Objectives
�MOTOROLA LTD. 2000 GPRS01: GPRS Architecture
FOR TRAINING PURPOSES ONLY
3–1
ObjectivesOn completion of this chapter the student will be able to:
� Describe the device/function dependancy within the database structure
� Equip and understand the database fields associated with equipping a PCU
ISSUE 1 REVISION 2PCU
�MOTOROLA LTD. 2000GPRS01: GPRS Architecture
FOR TRAINING PURPOSES ONLY
3–2
PCUEquipping a PCU at a BSS is done using the equip 0 pcu command. Equipping the PCUautomatically equips the cab and cage. Only one CAB and one cage can be equippedwith a PCU.
Restrictions to the PCU equipage are:
� PCU cannot be equipped when the GPRS feature is restricted.
� One PCU only per BSS
� PCU can only be equipped if land_layer_l_mode is set to E1
PSP
The PCU System Processor (PSP) is equipped on the MPROC at the PCU. Is thedevice that describes an MPROC board which is the master processor in the PCU.
Dependencies
� GPRS feature must be unrestricted
� PSP may only be equipped at a PCU
� Sysgen mode cannot be left if a PCU is equipped and no PSP is equipped
ISSUE 1 REVISION 2 PCU
�MOTOROLA LTD. 2000 GPRS01: GPRS Architecture
FOR TRAINING PURPOSES ONLY
3–3
equip 0 pcu
��������������� �
�������
����
equip PCU PSP
Enter the PSP identifier: 0
ISSUE 1 REVISION 2DPROC
�MOTOROLA LTD. 2000GPRS01: GPRS Architecture
FOR TRAINING PURPOSES ONLY
3–4
DPROCThe Data Processor Board is the non–system processor board at the PCU. Theseboards may have up to two PMC modules fitted dependent on the required function.
DPROCs may only be fitted and equipped in slots 1 – 6 and slots 11 – 16, the remainingslots being taken by the MPROC and the PCI to PCI Bridge (PPB).
There are two types of DPROC, Packet Interface Control Processor (PICP) and PacketResource Processor. A maximum of 6 PICPs may be equipped at the PCU and amaximum of 10 PRPs may be equipped at the PCU.
PRPs should not be equipped in slots 1 and 2 of the PCU cage as the default slot oninitialisation to bring up the GPRS Signalling Link (GSL) to gain code download is via slot1 or 2 through a PICP.
ISSUE 1 REVISION 2 DPROC
�MOTOROLA LTD. 2000 GPRS01: GPRS Architecture
FOR TRAINING PURPOSES ONLY
3–5
equip PCU DPROC
Enter the DPROC ID: <*>
* 1–6, 11–16
Enter the DPROC type: <*>
* PRP or PICP
ISSUE 1 REVISION 2MSI
�MOTOROLA LTD. 2000GPRS01: GPRS Architecture
FOR TRAINING PURPOSES ONLY
3–6
MSITo equip the PMC module the MSI device has been modified. The PMC module is usedto support the connection of the GBL to the PCU or the GPRS Data Stream (GDS) andGPRS Signalling Link (GSL) to the PCU.
These is a new MSI type called the E1–PMC to add this interface card to the MSI device.
To equip the E1–PMC MSI can only be carried out at a PCU. A maximum of 12 DPROCPICP MSIs can be equipped with a maximum of two E1–PMCs to any PICP. Each PRPmay be equiped with up to 2 MSI.
The first identifier of the E1–PMC must be unique, the second refers to the DPROC thatthe E1–PMC is mounted on.
The final prompt for the DPROC socket refers to the module identifier for the DPROCboard that the E1–PMC is being equipped. Each DPROC is capable of holding twoE1–PMCs.
ISSUE 1 REVISION 2 MSI
�MOTOROLA LTD. 2000 GPRS01: GPRS Architecture
FOR TRAINING PURPOSES ONLY
3–7
equip PCU MSI
Enter the MSI identifier: <*>* 0–23
Enter the DPROC id: <*>* 1–6, 11–16
Enter the DPROC Socket: <*>* 1,2
ISSUE 1 REVISION 2MMS Device
�MOTOROLA LTD. 2000GPRS01: GPRS Architecture
FOR TRAINING PURPOSES ONLY
3–8
MMS DeviceTo equip the two ports on the PMC module the MMS command has been extended. TheMMSs for a PMC are automatically equipped when a MSI is equipped.
MMS Priority
The MMS priority for a PICP MMS may not be set to a non–zero value, nor can the MMSat the BSC that is part of a GPRS Data Stream (GDS).
GDS or GBL
All MMSs on the same MSI must be configured for the same destination.
ISSUE 1 REVISION 2 MMS Device
�MOTOROLA LTD. 2000 GPRS01: GPRS Architecture
FOR TRAINING PURPOSES ONLY
3–9
MMS Device
PICP
PMC 860E1
PMC 860E1
E1
E1
E1
E1GBL
GDS
ISSUE 1 REVISION 2GPRS Data Stream (GDS)
�MOTOROLA LTD. 2000GPRS01: GPRS Architecture
FOR TRAINING PURPOSES ONLY
3–10
GPRS Data Stream (GDS)The GPRS Data Stream device refers to the traffic route between the PCU and the BSC.This is a E1 connection between a BSC MMS and a PCU MMS. The GPRS DataStream (GDS) may or may not have an associated GPRS Signalling Link (GSL). If theGDS carries a GSL then one timeslot is required for GSL LAPD signalling, the rest forGPRS traffic.
A maximum of 12 GDSs may be equipped and to allow default connectivity for codedownload for the PCU a GDS must be equipped and GSL equipped to the GDS (LAPD)of either:
� Timeslot 1 of span 0 of an E1–PMC Module in PMC Socket 1 of a PICP in Slot 1
� Timeslot 1 of span 0 of an E1–PMC module in PMC Socket 1 of a PICP in Slot 2
ISSUE 1 REVISION 2 GPRS Data Stream (GDS)
�MOTOROLA LTD. 2000 GPRS01: GPRS Architecture
FOR TRAINING PURPOSES ONLY
3–11
equip PCU GDS
Enter the GDS Identifier: <*>* 0–11
Enter the BSC MMS Identifier: <*> <*>
Enter the PCU MMS Identifier: <*> <*>
Enter the GDS type: <*>0 – TRAU GDS1 – LAPD GDS
ISSUE 1 REVISION 2GPRS Signalling Link (GSL)
�MOTOROLA LTD. 2000GPRS01: GPRS Architecture
FOR TRAINING PURPOSES ONLY
3–12
GPRS Signalling Link (GSL)The GPRS Signalling LInk (GSL) is a 64Kbps LAPD signalling link on a timeslot on aGPRS Data Stream (GDS). The GSL is used for signalling and code download forcommunication between the PCU and the GSL.
The maximum GSLs that may be equipped to a PCU are 6, with a maximum of twoGSLs to any GDS. The first GSL equipped to a GDS will use timeslot 1 of the GDS andthe second GSL equipped to the same GDS will use timeslot 2.
A GSL must be equipped to the default location to allow code download. The maximumnumber of GSLs equipped must not exceed the maximum number of GSLs that the LCFscan manage.
ISSUE 1 REVISION 2 GPRS Signalling Link (GSL)
�MOTOROLA LTD. 2000 GPRS01: GPRS Architecture
FOR TRAINING PURPOSES ONLY
3–13
equip PCU GSL
Enter the GSL identifier: <*>* 0–5
Enter the Unique GDS identifier: <*>* 0–11
ISSUE 1 REVISION 2GBL Device
�MOTOROLA LTD. 2000GPRS01: GPRS Architecture
FOR TRAINING PURPOSES ONLY
3–14
GBL DeviceThe GBL device refers to the configured number of timeslots on a E1 span between thePCU and the SGSN. This is the physical interface for the Frame Relay network service.One GBL is allowed per E1 span, the number of timeslots is a configurable parameter.
To maintain the Frame Relay link, unidirectional signalling incorporates periodic pollingbetween the PCU and the network. The PCU sends a STATUS ENQUIRY messageevery polling cycle (governed by T391) the network responds with a STATUS message.A count of the polling cycles is kept by the counter N391 at a set number of polling cyclescalled a FULL STATED ENQUIRY message is sent.
The network may also POLL the PCU set by a Polling Verification timer T392. The ErrorThreshold counter (N392) and the Monitored Events counter (N393) keep track of eventsand errors on the link.
ISSUE 1 REVISION 2 GBL Device
�MOTOROLA LTD. 2000 GPRS01: GPRS Architecture
FOR TRAINING PURPOSES ONLY
3–15
equip PCU GBL
Enter the GBL identifier: <*>* 0–3
Enter the 1st and 2nd MMS identifier:<*> <*>* MSI id 0–11* MMS id 0 or 1
Enter starting timeslot: <*>* 1–31
Enter the ending timeslot: <*>* 1–31
Enter the T391 timer: <*>* 5–29 seconds
Enter the T392 timer: <*>* 6–30 seconds
Enter the N391 counter: <*>* 1–255 polling cycles
Enter the N392 counter: <*>* 1–10 number of errors
Enter the N393 counter: <*>* 1–10 number of events
ISSUE 1 REVISION 2LCF
�MOTOROLA LTD. 2000GPRS01: GPRS Architecture
FOR TRAINING PURPOSES ONLY
3–16
LCFGPRS Signalling Link (GSL) Links are managed at the BSC by LCFs. To manage thisthe LCF device has been modified. The number of GSLs that an LCF can manage isreferred to by max_gsls. This maximum may not exceed 6. The LCF can manage GSLsalong with any combination of other link devices, for example RSLs, CBLs, GSLs, MTLs.
The number of GSLs supported by the LCF must not exceed the maximum number it cansupport.
The maximum number of GSLs per LCF are defined by the number of available GPROCslots and is limited to six. During LCF equipage the maximum number of MTLs , MBLsand GSLs are specified. The total number of these combined must be less than
gproc_slots – Reserved HDLC Channels
ISSUE 1 REVISION 2 LCF
�MOTOROLA LTD. 2000 GPRS01: GPRS Architecture
FOR TRAINING PURPOSES ONLY
3–17
equip bsc LCF
Enter the function ID for the LCF:
Enter the number of MTLS the LCF can manage:
Enter the number of CBLs the LCF can manage:
Enter the number of GSLs the LCF can manage:<*>* 0–6
ISSUE 1 REVISION 2GPRS Carrier
�MOTOROLA LTD. 2000GPRS01: GPRS Architecture
FOR TRAINING PURPOSES ONLY
3–18
GPRS CarrierThe BSS shall support Reserved and Switchable GPRS timeslots. A reserved GPRSTimeslot is a timeslot used for GPRS use only. A Switchable GPRS Timeslot is atimeslot that can be switched from GPRS usage to circuit switched and vice versa.
The BSS supports one GPRS carrier per cell and this carrier may be the BCCH or thenon–BCCH. The maximum number of GPRS timeslots configured depends on whether aseparate GPRS carrier is provided. If a non–BCCH carrier is chosen then up to 8timeslots may be configured for GPRS.
To support this new RTF, parameters have been added:
� max_gprs_pdch
� res_gprs_pdch
The parameter max_gprs_pdch specifies the maximum number of Packet Data Channels(PDCHs)s which will be configured on the carrier starting from the highest order timeslot.The parameter res_gprs_pdch specifies the number of PDCHs configured on the carrierthat will be reserved for GPRS use only. The number of Reserved GPRS timeslots mustnot exceed the maximum GPRS PDCH. All GPRS timeslots must have the same FHIand the same Training Sequence Code.
ISSUE 1 REVISION 2 GPRS Carrier
�MOTOROLA LTD. 2000 GPRS01: GPRS Architecture
FOR TRAINING PURPOSES ONLY
3–19
Timeslot Configuration Examples
BCCHBCCHBCCHBCCH
TCH
BCCHBCCHBCCHBCCH
TCH
SW
SW
RES
RES
RES
TCH
TCH
TCH
TCH
TCH
TCH
TCH
TCH
BCCH
TCH
TCH
TCH
TCH
TCH
TCH
TCH
SW
SW
SW
RES
RES
RES
RES
RES
TCH
TCH
TCH
TCH
TCH
TCH
TCH
SW
SW
SW
SW
SW
SW
SW
SW
0
1
2
3
4
5
6
7
Example A Example B Example C
BCCHCARRIER
CARRIER2
BCCHCARRIER
CARRIER2
BCCHCARRIER
CARRIER2
max_gprs_pdch <*> * 0 – 8res_gprs_pdch <*> * 0 – 8
ISSUE 1 REVISION 2Reconfiguration of suitable GPRS PDCHs
�MOTOROLA LTD. 2000GPRS01: GPRS Architecture
FOR TRAINING PURPOSES ONLY
3–20
Reconfiguration of suitable GPRS PDCHsThe order of priority within a cell is circuit switched calls followed by packet data calls.The BSS supports dynamic switching between Packet Data Traffic Channels (PDTCH)sand TCHs and vice versa. If it is necessary for the BSS to use any switched timeslotsthe BSS shall use them by triggering a reconfiguration frame PDTCH to TCH.
If the timeslot was in use by any GPRS mobiles, the PCU will broadcast the releasenotification on the Packet Associated Control Channels (PACCHs). If there is additionaldownlink data to send the BSS will reassign a channel using the AGCH. If the MS hasmore data to send the PCU will rely on the MS to Re RACH.
When a circuit switched call is greater than gprs_reconfig_thresh_idle_tch then the BSSwill reconfigure the channel back to a PDTCH. If the threshold of idle TCHs has beenexceeded and the cell has gprs_intraho_allwd set then the BSS will perform an intracellhandover of the mobile to an idle TCH and reconfigure the channel to a PDTCH.
ISSUE 1 REVISION 2 Reconfiguration of suitable GPRS PDCHs
�MOTOROLA LTD. 2000 GPRS01: GPRS Architecture
FOR TRAINING PURPOSES ONLY
3–21
Reconfiguration
gprs_intraho_allwd <*>
* 0 = NO INTRACELL HANDOVERS ALLOWED
1 = INTRACELL HANDOVERS ALLOWED
gprs_reconfig_thresh_idle_tch <*>
* 1–5 IDLE RESOURCES
ISSUE 1 REVISION 2BSSGP Virtual Circuit (BVC) Blocking and Unblocking
�MOTOROLA LTD. 2000GPRS01: GPRS Architecture
FOR TRAINING PURPOSES ONLY
3–22
BSSGP Virtual Circuit (BVC) Blocking and UnblockingA BSS may block a BVC because of:
� Operation and maintenance of a cell
� Equipment failure at the BSS
� Cell equipment failure at the BSS
� Cell traffic congestion
The BSS when blocking a BSSGP Virtual Circuit (BVC) will mark the BVC as blocked,discarding any traffic sent to the BVC in the uplink direction. The cell associated with theBVC will not accept any data in the downlink. The BSS sends a BVC_BLOCK PDU tothe SGSN (containing the BSSGP Virtual Circuit Identifier (BVCI) of the BVC to beblocked and a cause element) and starts the timer T1. The SGSN on receipt of theBVC_BLOCK PDU will mark the BVC as blocked and stop transmitting traffic on thatBVC. The SGSN then acknowledges the blocking of the BVC with a BVC_BLOCK_ACKPDU to the BSS. Receipt of the BVC_BLOCK_ACK PDU will stop T1.
If the BVC_BLOCK_ACK PDU is not received before expiry of T1 then the BSS shallrepeat sending the BVC_BLOCK PDU for a maximum of BVC_BLOCK RETRIED.
Unblocking operates in the same method using a BVC_UNBLOCK PDU sent to theSGSN and starting T1, the BSS will re–send the BVC_UNBLOCK PDU forBVC_UNBLOCK RETRIED. On receipt of a BVC_UNBLOCK ACK from a SGSN theBVC is marked as unblocked.
ISSUE 1 REVISION 2 BSSGP Virtual Circuit (BVC) Blocking and Unblocking
�MOTOROLA LTD. 2000 GPRS01: GPRS Architecture
FOR TRAINING PURPOSES ONLY
3–23
BVC Block/Unblock
PCU SGSN
BVC – BLOCK PDU
��
BVC – BLOCK PDU
BVC – BLOCK ACK PDU
BVC – UNBLOCK PDU
BVC – UNBLOCK ACK PDU
��
��
�� ������� � �
� � �����������������
��������� ������
� � ��� ������������ ������
��������� �������������
� � ����� ������������ ������
��������� �������������
��������
�������
ISSUE 1 REVISION 2BVC Reset
�MOTOROLA LTD. 2000GPRS01: GPRS Architecture
FOR TRAINING PURPOSES ONLY
3–24
BVC ResetThe purpose of the BVC_Reset procedure is to resynchronise the GPRS BSSGP VirtualCircuit (BVC) contexts at a BSS and SGSN. This ensures communication in a knownstate. A BVC_Reset procedure could be initiated due to a system failure, an underlyingnetwork service failure or a change in the transmission capability of the underlyingnetwork service.
The sequence is similar to the BVC block/unblock procedure. The BSS or SGSN sendsa BVC_RESET PDU to its Peer and starts the guard timer. bssgp_t2_timer if the entitydoes not receive a BVC_RESET_ACK before expiry of T2 then the entity will re–send theBVC_RESET PDU for BVC_RESET_RETRIES before stopping the procedure andinforming the O&M system. On receipt of a BVC_RESET_ACK the T2 timer is stopped.
ISSUE 1 REVISION 2 BVC Reset
�MOTOROLA LTD. 2000 GPRS01: GPRS Architecture
FOR TRAINING PURPOSES ONLY
3–25
BVC Reset
PCU SGSN
BVC – RESET PDU
�
BVC – RESET PDU
BVC – RESET PDU
�
�
�� ����������� �
� � �����������������
��������� ������
� � ������ ���������� ������
��������� �������������
������
��������
BSSGP_RESET
RETRIES
������
BVC – RESET ACK PDU
ISSUE 1 REVISION 2Flow Control
�MOTOROLA LTD. 2000GPRS01: GPRS Architecture
FOR TRAINING PURPOSES ONLY
3–26
Flow ControlThe principle of flow control is the BSS sends to the SGSN flow control parameters. TheSGSN performs flow control on each MS and BSSGP Virtual Circuit (BVC). The flowcontrol is performed first on each LLC_SDU, first by MS flow control mechanism, andthen by the BVC flow control mechanism.
The convention is that the SGSN should not transmit more data than can be contained inthe BSS buffer for a BVC or individual MS.
The variables sent are a Bucket size for each cell and MS the Bmax should be largeenough to accommodate at least one LLC–SDU. Also sent is the leak rate (R) to beapplied to the bucket. The frequency of flow control information is governed by a setableparameter C.
The formula B* = B + L(p) – (Tc – Tp) x R
Where:
B = Bucket Counter – size of last LLC SDU sent to PCU from the SGSN
B* = Predicted Value of Bucket Counter, which includes the size of the LLC PDUawaiting transmission to the PCU
L(p) = Length of LLC – SDU waiting to be transmitted from the SGSN
Tp = Time the last LLC– SDU was transferred to the PCU
Tc = Arrival time of LLC–SDU at the SGSN from the GGSN
R = Leak rate of the bucket at the PCU
When an LLC–SDU packet arrives at current time Tc, the variable B* is set to thepredicted bucket size as if the LLC–SDU was sent to the BSS. This is given by theprevious bucket size plus the new LLC–SDU size B* = B + L(p). To take account of theleakage since the last compliant LLC–SDU packet the calculation R* (Tc–Tp) is used.
If B* is less than zero then the Bucket Counter is set to the L(p) of the LLC–SDU as is Tpset to Tc and the LLC–SDU is passed as the BSS is ready to receive another LLCpacket.
If B* is not equal to zero but is less than Bmax, in other words would not exceed thebuffer, the LLC packet is passed to the BSS and B is set to B* and Tp to Tc.
ISSUE 1 REVISION 2 Flow Control
�MOTOROLA LTD. 2000 GPRS01: GPRS Architecture
FOR TRAINING PURPOSES ONLY
3–27
Flow Control
Arrival of LLC PDU pwith length L(p) at time Tc
B*= B + L(p) – (Tc – Tp) x R B* < 0?
B= L(p)
Tp= TcB* >Bmax?
B= B*
yes
no
no
Delay LLC PDU Pass LLC PDU�������� ��� �
�� � ��������������������
���������!�� � ��� �� ������� �����
��"��� �����!���������������������
�������������� � � �
��� ����������������������������
����������� ����������������������������������������������
����������������������������������������������
ISSUE 1 REVISION 2Network Service Block, Reset, Unblock, Test
�MOTOROLA LTD. 2000GPRS01: GPRS Architecture
FOR TRAINING PURPOSES ONLY
3–28
Network Service Block, Reset, Unblock, TestThe Gb Manager (GBM) manages the NS–VC block, reset and unblock procedures. AnyNS–VC failure reported by the FR functional unit will result in an NS–VC block being sentto the SGSN by the GBM and informing other PCU processes of the change in NS–VCstatus.
The NS–VC Block PDU will be sent at the expiry of ns_block_timer and forns_block_retries until receipt of NS_BLOCK–ACK PDU.
When an NS_VC comes into service, the GBM first starts a reset procedure to ensurethat both ends are at the same state. The peer entity sends an NS_RESET PDU to itspeer and starts ns_reset timer. At the expiry of the timer the peer re–sends theNS_RESET PDU for a period of time governed by ns_reset_period. Once anNS_RESET ACK has been received the ns_reset_timer is stopped and the NS_VC ismarked as blocked.
The GBM then initiates the Test Procedure on the NS_VC. After initiation of the testprocedure the GBM then unblocks the NS_VC. The peer entity sends an NS_UNBLOCKPDU and starts ns_block_timer. On expiry of the timer the peer entity sends another NSUNBLOCK PDU for NS_UNBLOCK_RETRIES. On receipt of an NS_UNBLOCK_ACKPDU the timer is stopped.
ISSUE 1 REVISION 2 Network Service Block, Reset, Unblock, Test
�MOTOROLA LTD. 2000 GPRS01: GPRS Architecture
FOR TRAINING PURPOSES ONLY
3–29
Network Service
PCU SGSN
NS_UNBLOCK PDU
NS_BLOCKACK PDU
NS_BLOCK PDU
������������� �
�� ����� �����������
���������� ������
�� ������ ������� ������
�� ������� ������� ������
�������������
�� ��� �� �����������
����������� ������
�� ��� �� ������������
��������� ������
NS_BLOCKTIMER
NS_BLOCK PDU
NS_RESET BLOCK PDU
NS_RESET ACK PDU
NS_UNBLOCK ACK PDU
NS_BLOCKTIMER
NS_RESETTIMER
NS_BLOCKTIMER
ISSUE 1 REVISION 2Network Service Test
�MOTOROLA LTD. 2000GPRS01: GPRS Architecture
FOR TRAINING PURPOSES ONLY
3–30
Network Service TestThe test procedure is used when a BSS or SGSN wishes to check the end to endcommunication with its peer entity on an NS–VC.
Both sides may initiate this procedure independently of each other. The process isinitiated on completion of a reset procedure and then periodically repeated.
The procedure is governed by the ns_test_timer, On expiry the peer entity sends anNS_ALIVE PDU on the NS–VC to be checked and starts ns_alive_timer. Upon receipt ofan NS_ALIVE_ACK PDU on the NS–VC the originator stops ns_alive_timer and restartsns_test_timer and the process begins again.
If the originator does not receive an NS_ALIVE_ACK PDU before expiry ofns–alive_timer then it will re–send an NS_ALIVE PDU for ns_alive_retries times.
ISSUE 1 REVISION 2 Network Service Test
�MOTOROLA LTD. 2000 GPRS01: GPRS Architecture
FOR TRAINING PURPOSES ONLY
3–31
Network Service Test
PCU SGSNNS_ALIVE PDU
������������� �
�� ���� �������������
���������� ������
�� � ����������������
���������� ������
�� � ������������ ������
�������
NS_ALIVE ACK PDU
NS_ALIVETIMER
NS_ALIVETIMER
NS_ALIVE PDU
ISSUE 1 REVISION 2Network Service
�MOTOROLA LTD. 2000GPRS01: GPRS Architecture
FOR TRAINING PURPOSES ONLY
3–32
Network ServiceThe Network Service performs the transport of NS SDUs between the SGSN and theBSS. The services provided are:
� Network Service SDU transfer
� Network congestion indication
� Status indication
An SGSN and a BSS may use different physical links for connecting to each other. Eachphysical link is locally (at each side of Gb interface) identified by means of a physical linkidentifier.
Each physical link supports one or more Network Service Virtual Links (NS–VL). EachNS–VL is identified by means of a Network Service Virtual Link Identifier. Thesignificance (i.e. local or end to end) depends on the configuration of the Gb interface.The NS_VLI is the association of the Frame Relay DLCI and the bearer channelidentifier.
In order to provide end to end communication between the SGSN and the BSSirrespective of the exact configuration of the Gb interface the Network Service VirtualConnection is used. The NS_VCs are end to end virtual connections between the BSSand the SGSN. At each end of the Gb interface there is a one to one correspondencebetween NS_VCs and NS_VLs. An NS_VC is identified by the means of a NetworkService Virtual Connection Identifier (NS_VCI).
ISSUE 1 REVISION 2 Network Service
�MOTOROLA LTD. 2000 GPRS01: GPRS Architecture
FOR TRAINING PURPOSES ONLY
3–33
Network Service
LLC
BSSGP
FR
L1
RELAY
BSSGP
FR
RLC
MACLI
BSSGb
SGSN
END TO END NS–VC
BSS SGSNFRAME RELAY
NETWORK
NS_VL
ATSGSN SIDE
NS_VL
ATBSS SIDE
ISSUE 1 REVISION 2Network Service Virtual Connection Group
�MOTOROLA LTD. 2000GPRS01: GPRS Architecture
FOR TRAINING PURPOSES ONLY
3–34
Network Service Virtual Connection GroupThe Network Service Virtual Connection Group groups together all the NS_VC providingcommunication between the same peer NS entities.
The network service provides a communication path between remote NS user entities.These communication paths are called BSSGP Virtual Cicuits (BVCs). Each BVC isidentified by a BSSGP Virtual Connection Identifier and is unique amongst all networkelements connected to the SGSN.
Each BVC is supported by one group of NS_VCs. Each group of NS_VCs may supportone or more BVCs.
ISSUE 1 REVISION 2 Network Service Virtual Connection Group
�MOTOROLA LTD. 2000 GPRS01: GPRS Architecture
FOR TRAINING PURPOSES ONLY
3–35
Network Service Virtual Group
BSSGP
NSCONTROL
FR
BSSGP
NSCONTROL
FR
BVCI
NS – VCI
NS – VLI NS – VLI
FRNETWORK
ISSUE 1 REVISION 2Gb Addressing
�MOTOROLA LTD. 2000GPRS01: GPRS Architecture
FOR TRAINING PURPOSES ONLY
3–36
Gb AddressingIn the diagram opposite, an example of two types of Gb interface are shown; anintermediate frame relay network and a point to point frame relay network.
In an intermediate network the Network Service Virtual Link identifier, made up of theDLCI and bearer channel identification, has only local significance. The Network ServiceVirtual Connection Identification has an end to end significance and is part of an NSVCgroup serving a BSSGP Virtual Connection Identification which identifies a cell orsignalling channel for a BSS at both ends of the Gb interface.
In a point to point frame relay network, where the BSS and SGSN are directly connected,the major change is that the DLCI and Bearer Channel identification no longer have localsignificance but have end to end significance.
ISSUE 1 REVISION 2 Gb Addressing
�MOTOROLA LTD. 2000 GPRS01: GPRS Architecture
FOR TRAINING PURPOSES ONLY
3–37
Gb Addressing
BSS #1
BSS #2
PTPCell 1
PTPCell 2
PTPCell 1
Signalling
Signalling
BVC1=2
BVC1=3
NSE1=1
BVC1=0
BVC1=2
BVC1=0
NSE1=2
NS–VC1=a
NS–VC1=b
NS–VC1=c
NS–VC1=d
NS–VC1=e
NS–VC1=f
DLCI=16
DLCI=137
DLCI=51
DLCI=43
DLCI=16
DLCI=259
Bearer Channel = 1
E1
Bearer Channel = 2
E1
Bearer Channel = 3
E1
Bearer Channel = 4
E1
Bea
rer
Cha
nnel
= 5
E1
Bea
rer
Cha
nnel
= 6
E1
DLCI=98
DLCI=17
DLCI=16
DLCI=21
DLCI=302
DLCI=511
NS–VC1=a
NS–VC1=b
NS–VC1=e
NS–VC1=c
NS–VC1=d
NS–VC1=f
SGSN
BVC1=2
BVC1=3
BVC1=0
NSE1=1
BVC1=2
BVC1=0
NSE1=2
FRAME
RELAY
NETWORK
ISSUE 1 REVISION 2Network Service Virtual Connection
�MOTOROLA LTD. 2000GPRS01: GPRS Architecture
FOR TRAINING PURPOSES ONLY
3–38
Network Service Virtual ConnectionThe NSVC command associates an NSVCI to a Network Service Virtual LinkIdentification and also specifies the committed information rate and burst size and burstexcess.
The NSVC must be mapped to a GBL before it can be mapped to an NSVC group orgroups. A DLCI must be unique within a single GBL and may be received within otherGBLs.
Parameter Minimum Maximum
NS_VCI 0 65535
DLCI 16 991
GBL_ID 0 3
An NSVCI is a unique identification between the BSS and SGSN.
ISSUE 1 REVISION 2 Network Service Virtual Connection
�MOTOROLA LTD. 2000 GPRS01: GPRS Architecture
FOR TRAINING PURPOSES ONLY
3–39
Network Service Virtual Connection (NSVC)
add_nsvc <NS_VCI><GBL_ID><DLCI>
Enter the committed Information Rate <*>* 0 –1984 in Kbps
Enter the committed Burst Size <*>* 0 – 1984 in Kbps
Enter the Burst Excess <*>* 0 – 1984 Kbps
ISSUE 1 REVISION 2BSSGP Virtual Circuit Identifier (BVCI)
�MOTOROLA LTD. 2000GPRS01: GPRS Architecture
FOR TRAINING PURPOSES ONLY
3–40
BSSGP Virtual Circuit Identifier (BVCI)The BSSGP Virtual Connection Identifier uniquely identifies a cell within a BSS or asignalling BVCI to that cell. The PCU maintains a table mapping each cell to a uniqueBVCI and all BSSGP signalling such as paging to a separate BVCI.
The BVCI is a new cell element and is included in the prompt for add_cell. A BVCI mustbe unique within a BSS.
Parameter Minimum Maximum Definition
BVCI 2 65535 Specifies the BVCI
A BVCI must be mapped to a cell before a BVCI may be mapped to an NSVC group.
ISSUE 1 REVISION 2 BSSGP Virtual Circuit Identifier (BVCI)
�MOTOROLA LTD. 2000 GPRS01: GPRS Architecture
FOR TRAINING PURPOSES ONLY
3–41
BSSGP Virtual Circuit Identifier (BVCI)
MMI–RAM 0115 –> add_cell 0 0 1 0 1 1 3
Enter the frequency type: frequency_type= pgsmEnter base station identity code: bsic= 10hEnter wait indication parameters: wait_indication_parameters= 20Enter common control channel configuration: ccch_conf= 0
:: (existing addcell prompts unchanged):
Enter rapid power down procedure active: rapid_pwr_down=0Enter rapid power down trigger threshold: rpd_trigger= 51Enter rapid power down level offset: rpd_offset= 8Enter rapid power down averaging period rpd_period= 2Enter the BVCI for this cell: bvci=120add_cell: LOCAL_CELL_ID selected is= 0add_cell: cell will be added to site: 0
COMMAND ACCEPTED
ISSUE 1 REVISION 2GPRS Signalling BVCI
�MOTOROLA LTD. 2000GPRS01: GPRS Architecture
FOR TRAINING PURPOSES ONLY
3–42
GPRS Signalling BVCIThe GB map command allows an NSVC group to be allocated for BSSGP signalling butthe command does not specify the BSSGP Virtual Circuit Identifier (BVCI) identification.Traffic BVCIs are associated with cells and are equipped with add_cell.
To equip a BVCI within a BSS for signalling the element gprs_sig_bvci has been added.This command specifies the unique value for the BVCI for BSSGP signalling.
ISSUE 1 REVISION 2 GPRS Signalling BVCI
�MOTOROLA LTD. 2000 GPRS01: GPRS Architecture
FOR TRAINING PURPOSES ONLY
3–43
SIG BVCI
change _element gprs_sig_bvci <*> PCU
* 0–65535 BVCI identifier
ISSUE 1 REVISION 2Routing Area
�MOTOROLA LTD. 2000GPRS01: GPRS Architecture
FOR TRAINING PURPOSES ONLY
3–44
Routing AreaThe Routing Area is a new definition to allow the separation of the network into routingareas. This has the advantage of allowing the tracking of mobiles within routing areas asa mobile will carry out routing area updates when crossing routing area boundaries. TheRouting Area Code is an additional one byte identifier in the cell identifier of GPRS cellsand is broadcast in System Information message 3.
To allow the mobile to quickly discover if a cell is GPRS enabled and in a different routingarea, Routing Area (RA) colour is used. RA colour has 8 possible variations and isbroadcast in system information message 3, allowing the mobile to quickly identify arouting area boundary and apply the correct response of a routing area update and alsocell reselect hystersis.
The location of an MS in STANDBY state is known in the SGSN on RA level. Thismeans that the mobile is paged in the Routing Area where the MS is located whenmobile terminated packet data arrives at the SGSN. A Routing area is a subset of oneand only one location area.
LAI = MCC + MNC + LAC
RAI = MCC + MNC + LAC + RAC
CGI = LAI + (RAC) + CI
ISSUE 1 REVISION 2 Routing Area
�MOTOROLA LTD. 2000 GPRS01: GPRS Architecture
FOR TRAINING PURPOSES ONLY
3–45
Routing Area
MCC DIG 11
2
6
3
4
5
7 6 5 4 3 2 1 0
MCC DIG 2
1 1 1 1 MCC DIG 1
MNC DIG 1MNC DIG 2
LAC
LAC
RAC
ROUTINGAREAIDENTITY
chg_element RAC <*> Cell <cell id>* 0 – 255
chg_element ra_colour<*> <site id> Cell <cell id>* 0 – 7
Oct
ets
Bits
ISSUE 1 REVISION 2N3102
�MOTOROLA LTD. 2000GPRS01: GPRS Architecture
FOR TRAINING PURPOSES ONLY
3–46
N3102To ensure that a mobile does not continue transmission of an uplink data transfer whenconnection to the network has been lost the counter N3102 and timer T3182 are used.
Every time an uplink ACK/NACK message is received by the mobile the counter N3102is incremented by a value set by gprs_ms_pan_inc up to the maximum ofgprs_ms_pan_max which sets the upper limit of counter N3102.
If the transmit window is stalled as V(S) = V(a) + K (the next RLC/MAC block to be sentis equal to the oldest RLC/MAC block pending acknowledgement, plus the window sizeK). Then the timer T3182 is started and the mobile will retransmit the oldest RLC/MACblock with a NACKED value of the oldest block pending ACK. These blocks aretransmitted with a Stall Indicator set to indicate to the network that the mobile is stalledawaiting an ACK/NACK. If T3182 expires the mobile decrements the counter N3102 bygprs_ms_pan_dec and performs an Abnormal release and then a random access to gainresources to send the uplink.
This condition repeats every time T3132 expires, until N3102 < 0 at which the mobile willperform an abnormal release and a cell reselection.
ISSUE 1 REVISION 2 N3102
�MOTOROLA LTD. 2000 GPRS01: GPRS Architecture
FOR TRAINING PURPOSES ONLY
3–47
N3102
gprs_ms_pan_dec <*><site id> Cell <cell id>* 0 – 7
gprs_ms_pan_inc <*><site id> Cell <cell id>
gprs_ms_pan_max <*> <site id> Cell <cell id>
V(s)= V(a) + K
T3182
gprs_ms_pa_max
N3102
ISSUE 1 REVISION 2N3102
�MOTOROLA LTD. 2000GPRS01: GPRS Architecture
FOR TRAINING PURPOSES ONLY
3–48
�MOTOROLA LTD. 2000 GPRS01: GPRS Architecture
FOR TRAINING PURPOSES ONLY
i
Chapter 4
PCU Statistics Application
ISSUE 1 REVISION 2
�MOTOROLA LTD. 2000 GPRS01: GPRS Architecture
FOR TRAINING PURPOSES ONLY
iii
Chapter 4PCU Statistics Application i. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
PCU Statistics Application 4–1. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Objectives 4–1. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
GPRS Performance Measurements 4–2. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Introduction to GPRS performance statistics 4–2. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Description of Gb interface 4–2. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . GBL statistics 4–2. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Description of accessibility statistics 4–3. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Accessibility statistics 4–3. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Throughput statistics 4–3. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Dynamic allocation statistics 4–3. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
GBL Statistic Diagrams 4–4. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
GBL_DL_DATA_THRPUT 4–9. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
GBL_DL_DATA_THRPUT_HIST 4–10. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
GBL_FLOW_CTRL_SENT 4–11. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
GBL_FLUSH_REQS 4–12. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
GBL_LINK_INS 4–13. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
GBL_PAGING_REQS 4–14. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
GBL_UL_DATA_THRPUT 4–15. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
GBL_UL_DATA_THRPUT_HIST 4–16. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
GBL_UNAVAILABLE 4–17. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Accessibility Statistic Diagrams 4–18. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
CHANNEL_REQS_REC 4–23. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
CHANNEL_REQS_REJECT 4–24. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
GPRS_ACCESS_PER_AGCH 4–25. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
GPRS_ACCESS_PER_PCH 4–26. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
GPRS_ACCESS_PER_RACH 4–27. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
GPRS_CHANNELS_SWITCHED 4–28. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
MS_CLASS_1_10_REQ 4–29. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
MS_CLASS_11_20_REQ 4–30. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
MS_CLASS_21_29_REQ 4–31. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Throughput Statistic Diagrams 4–33. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
AIR_DL_DATA_BLKS 4–37. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
AIR_UL_DATA_BLKS 4–38. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
DL_CHAN_ASGN_DURATION 4–39. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
TOTAL_AIR_DL_AVAILABLE_BW 4–40. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
TOTAL_AIR_UL_AVAILABLE_BW 4–41. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
UL_CHAN_ASGN_DURATION 4–42. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
ISSUE 1 REVISION 2 PCU Statistics Application
�MOTOROLA LTD. 2000 GPRS01: GPRS Architecture
FOR TRAINING PURPOSES ONLY
4–1
PCU Statistics Application
Objectives
On completion of this chapter the student will be able to:
� Understand the meaning of each Statistic pegged at the PCU.
ISSUE 1 REVISION 2GPRS Performance Measurements
�MOTOROLA LTD. 2000GPRS01: GPRS Architecture
FOR TRAINING PURPOSES ONLY
4–2
GPRS Performance Measurements
Introduction toGPRSperformancestatistics
This chapter includes descriptions of the General Packet Radio Service (GPRS)statistics. GPRS statistics are organized in the following groups:
� Gb link (GBL) statistics.
� Accessibility statistics.
� Throughput statistics.
� Dynamic allocation statistics.
Description ofGb interface
The GBL device refers to the configured number of timeslots on an E1 span between thePacket Control Unit (PCU) and the Serving GPRS Support Node (SGSN). This interfaceis referred to as the Gb interface. The Gb interface allows many users to be multiplexedover a common physical resource. GPRS signalling and user data are sent on the samephysical resource. That is, no dedicated physical resources are required to be allocatedfor signalling purposes.
GBL statistics
The GBL measurement types are listed as follows:
� GBL_DL_DATA_THRPUT
� GBL_DL_DATA_THRPUT_HIST
� GBL_FLOW_CTRL_SENT
� GBL_FLUSH_REQS
� GBL_LINK_INS
� GBL_PAGING_REQS
� GBL_UL_DATA_THRPUT
� GBL_UL_DATA_THRUT_HIST
� GBL_UNAVAILABLE
ISSUE 1 REVISION 2 GPRS Performance Measurements
�MOTOROLA LTD. 2000 GPRS01: GPRS Architecture
FOR TRAINING PURPOSES ONLY
4–3
Description ofaccessibilitystatistics
Accessiblility statistics are used to measure how effectively GPRS resources are beingaccessed. These measurements are used to assist the operator in planning thenecessary resources needed for the mobile to efficiently access the network.
Accessibilitystatistics
The accessiblility statistics are listed as follows:
� CHANNEL_REQS_REC
� CHANNEL_REQS_REJECT
� DL_CHAN_ASGN_DURATION
� GPRS_ACCESS_PER_AGCH
� GPRS_ACCESS_PER_PCH
� GPRS_ACCESS_PER_RACH
� GPRS_CHANNELS_SWITCHED
� UL_CHAN_ASGN_DURATION
Throughputstatistics
The throughput statistics are listed as follows:
� AIR_UL_DATA_BLKS
� AIR_DL_DATA_BLKS
� DL_CHAN_ASGN_DURATION
� GBL_DL_DATA_THRPUT
� GBL_DL_DATA_THRPUT_HIST
� GBL_UL_DATA_THRPUT
� GBL_UL_DATA_THRPUT_HIST
� TOTAL_AIR_UL_AVAILABLE_BW
� TOTAL_AIR_DL_AVAILABLE_BW
� UL_CHAN_ASGN_DURATION
Dynamicallocationstatistics
The dynamic allocation statistics are listed as follows:
� GPRS_DYNET_FAILURES
� GPRS_DYNET_RES_REQS
� GPRS_DYNET_SWI_REQS
ISSUE 1 REVISION 2GBL Statistic Diagrams
�MOTOROLA LTD. 2000GPRS01: GPRS Architecture
FOR TRAINING PURPOSES ONLY
4–4
GBL Statistic DiagramsFigure 4-1 to Figure 4-5 show how the GBL statistics function within the BSS/PCU.
GBL_DL_DATA_THRPUT
GBL_DL_DATA_THRPUT_TIME_PERIOD
Bearer chan 1
DLCI = 45
DLCI = 55
DLCI = 45
DLCI = 55
Figure 4-1 GBL_DL_DATA_THRPUT
ISSUE 1 REVISION 2 GBL Statistic Diagrams
�MOTOROLA LTD. 2000 GPRS01: GPRS Architecture
FOR TRAINING PURPOSES ONLY
4–5
Figure 4-2 is a ladder diagram detailing the statistic gbl_flow_ctrl_sent when it ispegged. It also shows the request and the response messages sent from the BSS/PCUto the SGSN.
BSSGP FLOW CONTROL PDU
BSSGP FLOW CONTROL ACK PDU
BSS/PCU SGSN
GBL_FLOW_CTRL_SENT
Figure 4-2 GBL_FLOW_CTRL_SENT
ISSUE 1 REVISION 2GBL Statistic Diagrams
�MOTOROLA LTD. 2000GPRS01: GPRS Architecture
FOR TRAINING PURPOSES ONLY
4–6
Figure 4-3 illustrates the statistic gbl_flush_reqs when it is pegged. It also shows therequest and the response sent from the SGSN to the PS.
FLUSH PDU FLUSH PDU
SGSN GB FU PS
GBL_FLUSH_REQS
Figure 4-3 GBL_FLUSH_REQS
ISSUE 1 REVISION 2 GBL Statistic Diagrams
�MOTOROLA LTD. 2000 GPRS01: GPRS Architecture
FOR TRAINING PURPOSES ONLY
4–7
Figure 4-4 is a ladder diagram detailing the statistic gbl_paging_reqs when it is pegged.It also shows the request and the response messages sent from the SGSN to theBSS/PCU and the mobile station.
MSBSS/PCU
Channel Request (RACH)
Immediate Assignment (AGCH)
SGSN
BSSGP PS PDU
GBL_PAGING_REQS
PACKET PAGING REQEST (PCH)
Figure 4-4 GBL_PAGING_REQS
ISSUE 1 REVISION 2GBL Statistic Diagrams
�MOTOROLA LTD. 2000GPRS01: GPRS Architecture
FOR TRAINING PURPOSES ONLY
4–8
Figure 4-5 illustrates the statistic gbl_ul_data_thrput .
GBL_UL_DATA_THRPUT
GBL_UL_DATA_THRPUT_TIME_PERIOD
Bearer chan 1
DLCI = 45
DLCI = 55
DLCI = 45
DLCI = 55
Figure 4-5 GBL_UL_DATA_THRPUT
ISSUE 1 REVISION 2 GBL_DL_DATA_THRPUT
�MOTOROLA LTD. 2000 GPRS01: GPRS Architecture
FOR TRAINING PURPOSES ONLY
4–9
GBL_DL_DATA_THRPUT
Description
This statistic measures the number of megabits transmitted on the downlink Gb link(GBL) for a given period of time. The Packet Control Unit (PCU) will then calculate theinstantaneous throughput by dividing the number of megabits received in the timeinterval. The time interval gbl_dl_thrput_time_period will be programmable.
The PCU will filter this statistic by computing a moving average of the instantaneousthroughput. The number of instantaneous throughput samplesnum_gbl_dl_data_thrput_samples used to compute the moving average will also beprogrammable.
Refer to Figure 4-5 for an illustration of this statistic.
Pegging
This statistic is pegged by calculating the number of megabits received by the PCUduring the interval, gbl_dl_thrput_time_period .
Analysis
This statistic can be used for the trend analysis of the average downlink throughput of theGBL.
Reference None.
Usage Network planning.
Congestion.
Basis GBL
Type Gauge.
ISSUE 1 REVISION 2GBL_DL_DATA_THRPUT_HIST
�MOTOROLA LTD. 2000GPRS01: GPRS Architecture
FOR TRAINING PURPOSES ONLY
4–10
GBL_DL_DATA_THRPUT_HIST
Description
This statistic is a histogram of the total downlink data throughput on the GBL for ameasurement period at the PCU.
The number of bins in the histogram is 10 and the ranges are programmable shown inTable 4-1.
Table 4-1 GBL_DL_DATA_THRPUT_HIST bins 0 – 600
Bin Range
0 0 – 30
1 31 – 71
2 71 – 110
3 111 – 140
4 141 – 170
5 171 – 230
6 231 – 300
7 301 – 400
8 401 – 500
9 501 – 600
Pegging
This statistic is pegged by calculating the number of megabits transmitted by the PCUduring the interval gbl_dl_thrput_time_period .
Analysis
This statistic can be used for the trend analysis of GBL downlink throughput.
Reference None.
Usage Network planning.
Congestion.
Quality of service monitoring: Networkaccessibility.
Basis GBL.
Type Normal Distribution.
ISSUE 1 REVISION 2 GBL_FLOW_CTRL_SENT
�MOTOROLA LTD. 2000 GPRS01: GPRS Architecture
FOR TRAINING PURPOSES ONLY
4–11
GBL_FLOW_CTRL_SENT
Description
This statistic indicates the number of flow control messages sent by the BSS to theServing GPRS Support Node (SGSN).
Each cell has a buffer that holds downlink data. When a cell buffer reaches apredetermined threshold, a flow control message is sent to the SGSN.
Flow control is performed to match the flow of downlink data with air throughput.
Refer to Figure 4-2 for an illustration of this statistic.
Pegging
This statistic pegs the number of flow control messages sent by the BSS and is peggedevery time a flow control message is sent.
Analysis
This statistic can be used for trend analysis of the number of flow control messages sentby the BSS.
Reference None.
Usage Network planning.
Congestion.
Quality of service monitoring: Networkaccessibility.
Basis Cell.
Type Counter.
ISSUE 1 REVISION 2GBL_FLUSH_REQS
�MOTOROLA LTD. 2000GPRS01: GPRS Architecture
FOR TRAINING PURPOSES ONLY
4–12
GBL_FLUSH_REQS
Description
This statistic counts the number of flush requests received on the GBL.
Refer to Figure 4-3 for an illustration of this statistic.
Pegging
This statistic is pegged each time a flush request is received on the GBL to flush theLogical Link Control (LLC) Protocol Data Unit (PDU) for a particular mobile station.
Analysis
This statistic can be used for the trend analysis of the number of flushable messagesreceived by the BSS.
Reference None.
Usage Network planning.
Congestion.
Basis BSS.
Type Counter.
ISSUE 1 REVISION 2 GBL_LINK_INS
�MOTOROLA LTD. 2000 GPRS01: GPRS Architecture
FOR TRAINING PURPOSES ONLY
4–13
GBL_LINK_INS
Description
This duration statistic will be started by the GPRS PCU each time the GBL becomes inservice (INS). The statistic GBL_LINK_INS willl stop each time the GBL has gone out ofservice.
The time available for this statistic will be reported in milliseconds.
Pegging
The timer for this statistic will start once the GBL transitions to the B-U state. The timerfor this statistic will stop once the GBL is no longer in the B-U state.
Analysis
This statistic can be used for trend analysis of the utilization of in-service GBL.
Reference None.
Usage Network accessibility
Fault finding.
Protocol utiliztion.
Basis GBL.
Type Duration.
ISSUE 1 REVISION 2GBL_PAGING_REQS
�MOTOROLA LTD. 2000GPRS01: GPRS Architecture
FOR TRAINING PURPOSES ONLY
4–14
GBL_PAGING_REQS
Description
This statistic counts the number of paging requests received on the GBL.
Refer to Figure 4-4 and Figure 4-8 for an illustration of this statistic.
Pegging
This statistic is pegged each time a page request is received on the GBL to page amobile.
Analysis
This statistic can be used for the trend analysis of the number of circuit switched andpacket switched pages received by the BSS from the SGSN.
Reference None.
Usage Network planning.
Congestion.
Basis BSS.
Type Counter.
ISSUE 1 REVISION 2 GBL_UL_DATA_THRPUT
�MOTOROLA LTD. 2000 GPRS01: GPRS Architecture
FOR TRAINING PURPOSES ONLY
4–15
GBL_UL_DATA_THRPUT
Description
This statistic measures the number of kilobits of data information transmitted on theuplink of the GBL for a given period of time. The PCU will then calculate theinstantaneous throughput by dividing the number of megabits transmitted by the timeinterval.
The time interval gbl_ul_thrput_period will be programmable. The PCU will filter thisstatistic by computing a moving average of the instantaneous throughput. The number ofinstantaneous throughput samples num_gbl_ul_thrput_samples used to compute themoving average will also be programmable.
Refer to Figure 4-5 for an illustration of this statistic.
Pegging
This statistic is pegged by calculating the number of megabits received by the PCUduring the interval, gbl_ul_thrput_period .
The number of bins in the histogram is 10 and the ranges are programmable shown inTable 4-2.
Table 4-2 GBL_UL_DATA_THRPUT_HIST bins 0 – 600
Bin Range
0 0 – 30
1 31 – 71
2 71 – 110
3 111 – 140
4 141 – 170
5 171 – 230
6 231 – 300
7 301 – 400
8 401 – 500
9 501 – 600
Analysis
This statistic can be used for the trend analysis of the average uplink throughput of theGBL.
Reference None.
Usage Network planning.
Congestion.
Basis GBL.
Type Gauge.
ISSUE 1 REVISION 2GBL_UL_DATA_THRPUT_HIST
�MOTOROLA LTD. 2000GPRS01: GPRS Architecture
FOR TRAINING PURPOSES ONLY
4–16
GBL_UL_DATA_THRPUT_HIST
Description
This statistic is a histogram of the total uplink data throughput on the GBL for ameasurement period at the PCU.
The number of bins in the histogram is 10 and the ranges are programmable.
Pegging
This statistic is pegged by calculating the number of megabits transmitted by the PCUduring the interval gbl_ul_thrput_time_period .
Analysis
This statistic can be used for the trend analysis of GBL uplink throughput.
Reference None.
Usage Network planning.
Congestion.
Quality of service monitoring: Networkaccessiblility.
Basis GBL.
Type Normal Distribution.
ISSUE 1 REVISION 2 GBL_UNAVAILABLE
�MOTOROLA LTD. 2000 GPRS01: GPRS Architecture
FOR TRAINING PURPOSES ONLY
4–17
GBL_UNAVAILABLE
Description
This statistic is the duration that the GBL is out of service. This statistic will stop whenthe GBL becomes in service.
The available time will be reported in milliseconds.
Pegging
The timer for this statistic is started when the GBL transitions to a state which is not B-U.It is stopped when the GBL is in the B-U state.
Analysis
This statistic can be used for trend analysis of the duration of GBL outages, includingthose caused by operator interaction.
Reference None.
Usage Network accessibility.
Fault finding.
Basis GBL.
Type Duration.
ISSUE 1 REVISION 2Accessibility Statistic Diagrams
�MOTOROLA LTD. 2000GPRS01: GPRS Architecture
FOR TRAINING PURPOSES ONLY
4–18
Accessibility Statistic DiagramsFigure 4-6 is a ladder diagram detailing the statistic channel_req_rej when it is pegged.It also shows the request and the response messages sent from the BSS/PCU to themobile station.
Immediate Assignment (AGCH)
MSBSS/PCU
Packet Resource Request
CHANNEL_REQ_REJ
PACKET ACESS REJECT
Figure 4-6 Accessibility CHANNEL_REQ_REJ
ISSUE 1 REVISION 2 Accessibility Statistic Diagrams
�MOTOROLA LTD. 2000 GPRS01: GPRS Architecture
FOR TRAINING PURPOSES ONLY
4–19
Figure 4-7 is a ladder diagram detailing the statistics gprs_access_per_rach andgprs_access_per_agch when pegging occurs. It also shows the request and theresponse messages sent from the BSS/PCU to the mobile station.
MSBSS/PCU
Channel Request (RACH)
GPRS_ACCESS_PER_RACH
GPRS_ACCESS_PER_AGCH
Immediate Assignment (AGCH)
Figure 4-7 GPRS_ACCESS_PER_RACH and GPRS_ACCESS_PER_AGCH
ISSUE 1 REVISION 2Accessibility Statistic Diagrams
�MOTOROLA LTD. 2000GPRS01: GPRS Architecture
FOR TRAINING PURPOSES ONLY
4–20
Figure 4-8 is a ladder diagram detailing the statistics gbl_paging_reqs ,gprs_access_per_pch , gprs_access_per_rach , and gprs_access_per_agch whenpegging occurs. It also shows the request and response messages sent from the SGSNto the BSS/PCU and to the mobile station.
MSBSS/PCU
Channel Request (RACH)
GPRS_ACCESS_PER_RACH
GPRS_ACCESS_PER_AGCH
Immediate Assignment (AGCH)
SGSN
BSSGP PS PDU
GBL_PAGING_REQS
GPRS_ACCESS_PER_PCH
PACKET PAGING REQEST (PCH)
Figure 4-8 Accessiblility and GBL statistics
ISSUE 1 REVISION 2 Accessibility Statistic Diagrams
�MOTOROLA LTD. 2000 GPRS01: GPRS Architecture
FOR TRAINING PURPOSES ONLY
4–21
Figure 4-9 is a ladder diagram detailing three MS class type statistics and when peggingoccurs. It also shows the request and response messages sent from the BSS/PCU tothe mobile station.
Immediate Assignment (AGCH)
MSBSS/PCU
Packet Resource Request
MS_CLASS_1_10_REQ
MS_CLASS_11_20_REQ
MS_CLASS_21_29_REQ
CHANNEL_REQ_REC
Figure 4-9 MS CLASS Statistics
ISSUE 1 REVISION 2Accessibility Statistic Diagrams
�MOTOROLA LTD. 2000GPRS01: GPRS Architecture
FOR TRAINING PURPOSES ONLY
4–22
Figure 4-10 details the gprs_channels_switched statistic.
TCHSW
GPRSRESSW
GPRSRESSW
GPRSSW RES
TCHSW RES
TCHRESSW
GPRSSW RES
GPRS_CHANNELS_SWITCHED
GPRS GPRS GPRSGPRS
GPRS GPRS GPRSGPRS GPRS
Figure 4-10 CHANNELS_SWITCHED
ISSUE 1 REVISION 2 CHANNEL_REQS_REC
�MOTOROLA LTD. 2000 GPRS01: GPRS Architecture
FOR TRAINING PURPOSES ONLY
4–23
CHANNEL_REQS_REC
Description
This statistic counts the number of channel or resource request messages received bythe Packet Control Unit (PCU).
Refer to Figure 4-9 for an illustration of this statistic.
Pegging
This statistic pegs for each channel request message received by the PCU.
Analysis
Reference None.
Usage Network planning.
Basis Cell.
Type Counter.
ISSUE 1 REVISION 2CHANNEL_REQS_REJECT
�MOTOROLA LTD. 2000GPRS01: GPRS Architecture
FOR TRAINING PURPOSES ONLY
4–24
CHANNEL_REQS_REJECT
Description
This statistic measures the number of packet channel or resource request received bythe PCU that were rejected.
Refer to Figure 4-6 for an illustration of this statistic.
Pegging
This statistic is pegged when an immediate assignment reject message is sent to the MSin response to a packet channel or resource request. This is due to no channels beingavailable to be allocated.
Analysis
Reference None.
Usage Network planning.
Congestion.
Basis Cell.
Type Counter.
ISSUE 1 REVISION 2 GPRS_ACCESS_PER_AGCH
�MOTOROLA LTD. 2000 GPRS01: GPRS Architecture
FOR TRAINING PURPOSES ONLY
4–25
GPRS_ACCESS_PER_AGCH
Description
This statistic counts the Immediate Assignment messages sent on the Access GrantChannel (AGCH) of a cell for packet data service.
The air interface message on the AGCH for packet immediate assignment andimmediate assignment reject, will contain only on MS.
Access Grants for more than one MS may be contained in one Access Grant message.An Access Grant for more than one MS is only pegged once. This count includesImmediate Assignment, Immediate Extended, and Immediate Assignment Rejectmessages sent on the AGCH of a cell.
Refer to Figure 4-7 and Figure 4-8 for an illustration of this statistic.
Pegging
This statistic is pegged when an access grant message is sent on the AGCH on a cell forpacket data service.
Analysis
This statistic can be used for trend analysis of Immediate Assignment messages sent onthe AGCH of a cell.
Reference None.
Usage Radio resource allocation statistics.
Network planning.
Basis Cell.
Type Counter.
ISSUE 1 REVISION 2GPRS_ACCESS_PER_PCH
�MOTOROLA LTD. 2000GPRS01: GPRS Architecture
FOR TRAINING PURPOSES ONLY
4–26
GPRS_ACCESS_PER_PCH
Description
This statistic counts Paging Request messages sent on the Paging Channel (PCH) of acell for GPRS mobiles.
Pages for circuit switch and packet switch MS can be combined in on PCH message.
Refer to Figure 4-8 for an illustration of this statistic.
Pegging
This statistic is pegged when at least one general packet radio system (GPRS) mobile iscontained in the message sent over the PCH.
Analysis
This statistic can be used for trend analysis of paging request messages sent on thePCH of a cell for packet and GPRS mobile system.
Reference None.
Usage Radio resource allocation statistics.
Network planning.
Basis Cell.
Type Counter.
ISSUE 1 REVISION 2 GPRS_ACCESS_PER_RACH
�MOTOROLA LTD. 2000 GPRS01: GPRS Architecture
FOR TRAINING PURPOSES ONLY
4–27
GPRS_ACCESS_PER_RACH
Description
This statistic counts Channel Request messages sent on the Random Access Channel(RACH) of a cell.
Pegging
Refer to Figure 4-7 and Figure 4-8 for an illustration of this statistic.
Analysis
This statistic can be used for trend analysis of Immediate Assignment messages sent onthe RACH of a cell.
Reference None.
Usage Radio resource allocation statistics.
Network planning.
Basis Cell.
Type Counter.
ISSUE 1 REVISION 2GPRS_CHANNELS_SWITCHED
�MOTOROLA LTD. 2000GPRS01: GPRS Architecture
FOR TRAINING PURPOSES ONLY
4–28
GPRS_CHANNELS_SWITCHED
Description
This statistic counts the number of times that a Packet Data Traffic Channel (PDTCH) isswitched to a Traffic Channel (TCH).
Refer to Figure 4-10 for an illustration for this statistic.
Pegging
This statistic will be incremented each time a PDTCH is switched to a TCH or when aTCH is switched to a PDTCH.
Analysis
Reference None.
Usage
Basis Cell.
Type Counter.
ISSUE 1 REVISION 2 MS_CLASS_1_10_REQ
�MOTOROLA LTD. 2000 GPRS01: GPRS Architecture
FOR TRAINING PURPOSES ONLY
4–29
MS_CLASS_1_10_REQ
Description
This counter array statistic tracks the number of requests received for the mobile stationclasses 1 through 10.
Refer to Figure 4-9 for an illustration of this statistic.
The units of each bin are 10 requests shown in Table 4-3.
Table 4-3 MS_CLASS_1_10_REQ bins 1 through 10
Bin Scenario Description
0 MS_CLASS_1_REQ Number of requests for class 1
1 MS_CLASS_2_REQ Number of requests for class 2
2 MS_CLASS_3_REQ Number of requests for class 3
3 MS_CLASS_4_REQ Number of requests for class 4
4 MS_CLASS_5_REQ Number of requests for class 5
5 MS_CLASS_6_REQ Number of requests for class 6
6 MS_CLASS_7_REQ Number of requests for class 7
7 MS_CLASS_8_REQ Number of requests for class 8
8 MS_CLASS_9_REQ Number of requests for class 9
9 MS_CLASS_10_REQ Number of requests for class 10
Pegging
This is one of three stats that is pegged every time there is an uplink request from anMS. The other two are MS_CLASS_11_19_REQ and MS_CLASS_20_29_REQ .
Analysis
Reference GSM 05.02, 6.2.0, Annex B.
Usage Network planning.
Basis Cell.
Type Counter array.
ISSUE 1 REVISION 2MS_CLASS_11_20_REQ
�MOTOROLA LTD. 2000GPRS01: GPRS Architecture
FOR TRAINING PURPOSES ONLY
4–30
MS_CLASS_11_20_REQ
Description
This counter array statistic tracks the number of requests received for the mobile stationclasses 11 through 20.
Refer to Figure 4-9 for an illustration for this statistic.
The units of each bin are in 10 requests shown in Table 4-4.
Table 4-4 MS_CLASS_11_20_REQ bins 11 through 20
Bin Scenario Description
0 MS_CLASS_11_REQ Number of requests for class 11
1 MS_CLASS_12_REQ Number of requests for class 12
2 MS_CLASS_13_REQ Number of requests for class 13
3 MS_CLASS_14_REQ Number of requests for class 14
4 MS_CLASS_15_REQ Number of requests for class 15
5 MS_CLASS_16_REQ Number of requests for class 16
6 MS_CLASS_17_REQ Number of requests for class 17
7 MS_CLASS_18_REQ Number of requests for class 18
8 MS_CLASS_19_REQ Number of requests for class 19
9 MS_CLASS_20_REQ Number of requests for class 20
Pegging
This is one of three stats that is pegged every time there is an uplink request from anMS. This is one of three stats that is pegged every time there is an uplink request froman MS. The other two are MS_CLASS_1_10_REQ and MS_CLASS_20_29_REQ .
Analysis
Reference GSM 05.02, 6.2.0, Annex B.
Usage Network planning.
Basis Cell.
Type Counter array.
ISSUE 1 REVISION 2 MS_CLASS_21_29_REQ
�MOTOROLA LTD. 2000 GPRS01: GPRS Architecture
FOR TRAINING PURPOSES ONLY
4–31
MS_CLASS_21_29_REQ
Description
This counter array statistic tracks the number of requests received for the mobile stationclasses 21 through 29.
Refer to Figure 4-9 for an illustration for this statistic.
The units of each bin are in 10 requests shown in Table 4-5.
Table 4-5 MS_CLASS_21_29_REQ bins 21 through 29
Bin Scenario Description
0 MS_CLASS_21_REQ Number of requests for class 21
1 MS_CLASS_22_REQ Number of requests for class 22
2 MS_CLASS_23_REQ Number of requests for class 23
3 MS_CLASS_24_REQ Number of requests for class 24
4 MS_CLASS_25_REQ Number of requests for class 25
5 MS_CLASS_26_REQ Number of requests for class 26
6 MS_CLASS_27_REQ Number of requests for class 27
7 MS_CLASS_28_REQ Number of requests for class 28
8 MS_CLASS_29_REQ Number of requests for class 29
Pegging
This is one of three stats that is pegged every time there is an uplink request from anMS. This is one of three stats that is pegged every time there is an uplink request froman MS. The other two are MS_CLASS_1_10_REQ and MS_CLASS_11_19_REQ .
Analysis
Reference GSM 05.02, 6.2.0, Annex B.
Usage Network planning.
Basis Cell.
Type Counter array.
ISSUE 1 REVISION 2MS_CLASS_21_29_REQ
�MOTOROLA LTD. 2000GPRS01: GPRS Architecture
FOR TRAINING PURPOSES ONLY
4–32
ISSUE 1 REVISION 2 Throughput Statistic Diagrams
�MOTOROLA LTD. 2000 GPRS01: GPRS Architecture
FOR TRAINING PURPOSES ONLY
4–33
Throughput Statistic DiagramsFigure 4-11 is a ladder diagram detailing the statistic air_ul_data_blks and whenpegging occurs. It also shows the request and response messages sent from theBSS/PCU to the mobile station.
PACKET UPLINK ASSIGNMENT
MSBSS/PCU
DATA BLOCK
AIR_UL_DATA_BLKS
QOS1 QOS2 QOS3 QOS4CS1 CS1 CS1 CS1
QOS1 QOS2 QOS3 QOS4CS2 CS2 CS2 CS2
Figure 4-11 Uplink Data Transfer
ISSUE 1 REVISION 2Throughput Statistic Diagrams
�MOTOROLA LTD. 2000GPRS01: GPRS Architecture
FOR TRAINING PURPOSES ONLY
4–34
Figure 4-12 is a ladder diagram detailing the statistic air_dl_data_blks and whenpegging occurs. It also shows the request and response messages sent from theBSS/PCU to the mobile station.
PACKET DOWNLINK ASSIGNMENT
MSBSS/PCU
DATA BLOCK
AIR_DL_DATA_BLKS
QOS1 QOS2 QOS3 QOS4CS1 CS1 CS1 CS1
QOS1 QOS2 QOS3 QOS4CS2 CS2 CS2 CS2
Figure 4-12 Downlink Data Transfer
ISSUE 1 REVISION 2 Throughput Statistic Diagrams
�MOTOROLA LTD. 2000 GPRS01: GPRS Architecture
FOR TRAINING PURPOSES ONLY
4–35
Figure 4-13 illustrates the dl_chan_asgn_duration statistic.
1
PDCH PDCH PDCH PDCH PDCH PDCH PDCH PDCH
MS
5
25
1 PDCH
MS
25
2 PDCH35
DL_CHAN_ASGN_DURATION
INC IN DECISECONDS
2 3 4 6 7 85
II I
Figure 4-13 Downlink Channels Assigned Duration
ISSUE 1 REVISION 2Throughput Statistic Diagrams
�MOTOROLA LTD. 2000GPRS01: GPRS Architecture
FOR TRAINING PURPOSES ONLY
4–36
Figure 4-14 illustrates the ul_chan_asgn_duration statistic.
1
PDCH PDCH PDCH PDCH PDCH PDCH PDCH PDCH
MS
5
25
1 PDCH
MS
25
2 PDCH35
UL_CHAN_ASGN_DURATION
INC IN DECISECONDS
2 3 4 6 7 85
II I
Figure 4-14 Uplink Channels Assigned Duration
ISSUE 1 REVISION 2 AIR_DL_DATA_BLKS
�MOTOROLA LTD. 2000 GPRS01: GPRS Architecture
FOR TRAINING PURPOSES ONLY
4–37
AIR_DL_DATA_BLKS
Description
This counter array statistic reports the number of blocks sent by the PCU for each qualityof service level and coding scheme combination. The count is rounded to the nearest100 blocks.
Refer to Figure 4-12 for an illustration of this diagram.
The counters are defined in Table 4-6.
Table 4-6 AIR_DL_DATA_BLKS counters
Bin Scenario Description
0 QOS1_CS1 Quality of service level 1, coding scheme 1
1 QOS2_CS1 Quality of service level 2, coding scheme 1
2 QOS3_CS1 Quality of service level 3, coding scheme 1
3 QOS4_CS1 Quality of service level 4, coding scheme 1
4 QOS1_CS2 Quality of service level 1, coding scheme 2
5 QOS2_CS2 Quality of service level 2, coding scheme 2
6 QOS3_CS2 Quality of service level 3, coding scheme 2
7 QOS4_CS2 Quality of service level 4, coding scheme 2
Pegging
The appropriate bin is incremented by the amount of data blocks sent for the quality ofservice and coding scheme.
Analysis
This statistic shall be pegged at the PCU.
Reference
Usage Network planning.
Basis Cell.
Type Counter array.
ISSUE 1 REVISION 2AIR_UL_DATA_BLKS
�MOTOROLA LTD. 2000GPRS01: GPRS Architecture
FOR TRAINING PURPOSES ONLY
4–38
AIR_UL_DATA_BLKS
Description
This counter array statistic reports the number of data blocks received by the PCU foreach qualilty of service level and coding scheme combination. The count is rounded tothe nearest 100 blocks.
Refer to Figure 4-11 for an illustration of this statistic.
The counters are defined in Table 4-7.
Table 4-7 AIR_UL_DATA_BLKS counters
Bin Scenario Description
0 QOS1_CS1 Quality of service level 1, coding scheme 1
1 QOS2_CS1 Quality of service level 2, coding scheme 1
2 QOS3_CS1 Quality of service level 3, coding scheme 1
3 QOS4_CS1 Quality of service level 4, coding scheme 1
4 QOS1_CS2 Quality of service level 1, coding scheme 2
5 QOS2_CS2 Quality of service level 2, coding scheme 2
6 QOS3_CS2 Quality of service level 3, coding scheme 2
7 QOS4_CS2 Quality of service level 4, coding scheme 2
Pegging
The appropriate bin is incremented by the amount of data blocks received for the qualityof service and coding scheme.
Analysis
This statistic shall be pegged at the PCU.
Reference None.
Usage Network planning.
Basis Cell.
Type Counter array.
ISSUE 1 REVISION 2 DL_CHAN_ASGN_DURATION
�MOTOROLA LTD. 2000 GPRS01: GPRS Architecture
FOR TRAINING PURPOSES ONLY
4–39
DL_CHAN_ASGN_DURATION
Description
This counter array statistic tracks the number of channels that are simultaneously in use(assigned) by an mobile station in the downlink direction.
The bins are durations in that they measure the amount of time in deciseconds that eachnumber of channels were used.
Refer to Figure 4-13 for an illustration of this statistic.
Channels 1 to 8 are shown in Table 4-8.
Table 4-8 DL_CHAN_ASGN_DURATION channels 1 through 8
Bin Scenario Description
0 1_DATA_CHAN_ASGND 1 data channel assigned
1 2_DATA_CHAN_ASGND 2 data channel assigned
2 3_DATA_CHAN_ASGND 3 data channel assigned
3 4_DATA_CHAN_ASGND 4 data channel assigned
4 5_DATA_CHAN_ASGND 5 data channel assigned
5 6_DATA_CHAN_ASGND 6 data channel assigned
6 7_DATA_CHAN_ASGND 7 data channel assigned
7 8_DATA_CHAN_ASGND 8 data channel assigned
Pegging
The appropriate bin (according to the number of timeslots that are in use for the cell) willbe increased by 1 for the cell. Thus, each bin is measured in units of deciseconds.
Analysis
This statistic can be used for trend analysis of channel assignment in the downlinkdirection for the cell.
By observing a daily or weekly trend of the amount of time allocated to each of the bins,the information may be used to determine where or not additional resources may beneeded.
Reference None.
Usage Network planning.
Optimization.
Basis Cell.
Type Counter array.
ISSUE 1 REVISION 2TOTAL_AIR_DL_AVAILABLE_BW
�MOTOROLA LTD. 2000GPRS01: GPRS Architecture
FOR TRAINING PURPOSES ONLY
4–40
TOTAL_AIR_DL_AVAILABLE_BW
Description
This statistic counts the total number of Radio Link Control (RLC) data blocks availablefor downlink transfer at the PCU.
Pegging
The amount of available bandwidth is calculated by summing up the number of availableRLC blocks in a second (50, each takes up 20 milliseconds) and then multiplying by thenumber of timeslots both in use and not in use for GPRS.
Analysis
Reference None.
Usage Network planning.
Network accessiblility.
Basis Cell.
Type Counter.
ISSUE 1 REVISION 2 TOTAL_AIR_UL_AVAILABLE_BW
�MOTOROLA LTD. 2000 GPRS01: GPRS Architecture
FOR TRAINING PURPOSES ONLY
4–41
TOTAL_AIR_UL_AVAILABLE_BW
Description
This statistic counts the total number of RLC data blocks available for uplink transfer atthe PCU.
Pegging
The amount of available bandwidth is calculated by summing up the number of availableRLC blocks in a second (50, each one takes up 20 milliseconds), and then multiplying bythe number of timeslots both in use and not in use for GPRS.
Analysis
Reference None.
Usage Network planning.
Network accessiblity.
Basis Cell.
Type Counter.
ISSUE 1 REVISION 2UL_CHAN_ASGN_DURATION
�MOTOROLA LTD. 2000GPRS01: GPRS Architecture
FOR TRAINING PURPOSES ONLY
4–42
UL_CHAN_ASGN_DURATION
Description
This counter array statistic tracks the number of channels that are simultaneously in use(assigned) by a mobile station in the uplink direction.
The bins are durations in that they measure the amount of time in deciseconds that eachnumber of channels were used.
Refer to Figure 4-14 for an illustration of this statistic.
Channels 1 to 8 are shown in Table 4-9.
Table 4-9 DL_CHAN_ASGN_DURATION channels 1 through 8
Bin Scenario Description
0 1_DATA_CHAN_ASGND 1 data channel assigned
1 2_DATA_CHAN_ASGND 2 data channel assigned
2 3_DATA_CHAN_ASGND 3 data channel assigned
3 4_DATA_CHAN_ASGND 4 data channel assigned
4 5_DATA_CHAN_ASGND 5 data channel assigned
5 6_DATA_CHAN_ASGND 6 data channel assigned
6 7_DATA_CHAN_ASGND 7 data channel assigned
7 8_DATA_CHAN_ASGND 8 data channel assigned
Pegging
The appropriate bin (according to the number of timeslots are in use for the cell) will beincreased by 1 for the cell. Thus, each bin is measured in units of deciseconds.
Analysis
This statistic can be used for trend analysis of channel assignment in the uplink directionfor the cell.
By observing a daily or weekly trend of the amount of time allocated to each of the bins,the information may be used to determine where or not additional resources may beneeded.
Reference None.
Usage Network planning.
Optimization.
Basis Cell.
Type Counter array.
�MOTOROLA LTD. 2000 GPRS01: GPRS Architecture
FOR TRAINING PURPOSES ONLY
i
Chapter 5
GSN Architecture
ISSUE 1 REVISION 2
�MOTOROLA LTD. 2000 GPRS01: GPRS Architecture
FOR TRAINING PURPOSES ONLY
iii
Chapter 5GSN Architecture i. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Objectives 5–1. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
GPRS Overview 5–2. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . GSN in GPRS 5–2. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . GSN Software Architecture 5–4. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . SGSN Architecture 5–6. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Functional Entities and Hardware Mapping 5–8. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . CPX 8216 5–10. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . System Configuration 5–12. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . I/O Configurations 5–14. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Power Supply 5–16. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . MCP 750 – L252 5–18. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . MCP750 5–20. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . PMC 860 Module 5–22. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . ATTACH 5–24. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . ATTACH 5–26. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . ATTACH 5–28. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . ATTACH 5–30. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Detach 5–32. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Explicit Detach 5–34. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Explicit Detach 5–36. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Implicit Detach 5–38. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Routing Area Update 5–40. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Blocking User Data Transfer 5–40. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Modify GMM Context 5–40. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Session Management 5–42. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . PDP Context Activation MS Initiated 5–44. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . PDP Context Activation – Transmission function 5–46. . . . . . . . . . . . . . . . . . . . . . . . . . . Uplink Activation 5–48. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . PDP Context Accept 5–48. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Activate Downlink 5–50. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . PDP Context Deactivation 5–52. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Paging for GPRS Downlink Transfer 5–54. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Paging 5–56. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Transmission Function 5–58. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . SNDCP Peer to Peer 5–60. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . SNDCP XID Parameters 5–60. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . LLC Peer to Peer 5–62. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . GGSN – PDP Context Activation 5–64. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
ISSUE 1 REVISION 2 Objectives
�MOTOROLA LTD. 2000 GPRS01: GPRS Architecture
FOR TRAINING PURPOSES ONLY
5–1
ObjectivesOn completion of this course the students will be able to:
� Identify the major components of the GSN
� Understand the Generic function of GSN entities
� Identify the signalling between GSN entities for Mobility Management and SessionManagement
ISSUE 1 REVISION 2GPRS Overview
�MOTOROLA LTD. 2000GPRS01: GPRS Architecture
FOR TRAINING PURPOSES ONLY
5–2
GPRS OverviewGeneral Packet Radio Service (GPRS) is a Global System for Mobile communications(GSM) service that enables mobile subscribers to send data packets over GSM radiochannels to external data networks.
The main benefit of GPRS is that it reserves specifically for times when there issomething to send. the same radio resource is shared by all mobile stations (MSs) in acell, providing effective use of scarce resources. GPRS facilitates several applications,such as telemetry, train control systems, interactive data access, toll road chargingsystems, and internet browsing using the World Wide Web.
See illustration opposite.
GSN in GPRS
The GPRS Support Node (GSN) is the main element in the GPRS infrastructure. It is ahigh performance, broadband packet-switching node that provides connection andinterworking with various data networks, mobility management with the GPRS registers,and delivery of data packets to mobile stations.
The GSN can be physically integrated with the mobile switching centre (MSC) or it canbe a separate network element based on the architecture of data network routers. theuser data flows directly between the GSN and the base station subsystem (BSS).Physically, the data can flow transparently through the MSC.
All GSNs must implement the Gn interface protocols in order to communicate with otherGSNs in the same Public Land Mobile Network (PLMN). A limited internal home locationregister (HLR) function within the (Serving GPRS Support Node) SGSN is provided forbasic subscriber management purposes.
ISSUE 1 REVISION 2 GPRS Overview
�MOTOROLA LTD. 2000 GPRS01: GPRS Architecture
FOR TRAINING PURPOSES ONLY
5–3
Example of a GPRS system
ISSUE 1 REVISION 2GPRS Overview
�MOTOROLA LTD. 2000GPRS01: GPRS Architecture
FOR TRAINING PURPOSES ONLY
5–4
GSN SoftwareArchitecture
The GSN software architecture is designed on five functional planes. They are:
1. Control function
� Signalling information between different GPRS components, such as MS Attachand PDP activate.
� Macroscopic MS Context information
2. Transmission function
� Data traffic transmission between different GPRS components
� Microscopic MS Context Information
3. OAMP function
� Interface with OMC–G
� Interface with Control and Transmission function for collection of OAMP data (e.g.Statistics)
� Interface for forwarding of alarms to the OMC–G from the Control function andTransmission function
� Configuration Management of Control and Transmission function
4. Accounting Metering function
� Interface with external billing system
� Collection of billing information from Control and Transmission function
5. Network Support function
� Domain name server
� Time server
ISSUE 1 REVISION 2 GPRS Overview
�MOTOROLA LTD. 2000 GPRS01: GPRS Architecture
FOR TRAINING PURPOSES ONLY
5–5
System Framework
Billing/AccountingSystem
Network Support Server
OMC-G
Control Function
Transmission Function
Acc
ount
ing
Met
erin
g F
unct
ion
Acc
ount
ing
Met
erin
g F
unct
ion
OA
MP
Fun
ctio
n
ISSUE 1 REVISION 2GPRS Overview
�MOTOROLA LTD. 2000GPRS01: GPRS Architecture
FOR TRAINING PURPOSES ONLY
5–6
SGSNArchitecture
Functional Entities
The SGSN consists of the following software functional entities:
SGSN – CONTROL
Part of the Control Plane, the SGSN–CONTROL is responsible for handling SGSNsignalling, such as MS attach, PDP activate.
It contains macroscopic information about the MS, i.e. VLR
Transmission Function
The SGSN Transmission function is made up of two functional entities, theSGSN–GNPROC and the SGSN–GBPROC.
SGSN–GNPROC – Part of the transmission plane and responsible for GTP, Relay,SNDCP and LLC protocols. It serves as an anchor and point for an MS within an SGSN.Responsible for paging of MSs and receiving/forwarding data to/from the appropriateSGSN–GBPROC. The GNPROC contains microscopic MS context information; MS MMstate, PDP state and cell location.
SGSN–GBPROC – Also part of the transmission plane responsible for BSSGP protocol.Each GBPROC is connected to one BSS via a number of E1 links. The GBPROC isresponsible for QOS scheduling and flow control. The functional entity contains cell andframe relay PVC mapping.
SS7 Function
The SGSN has a number of interfaces to other network entities that use the SS7 protocolstack for signalling exchange. The SS7 function is the functional component identified tohandle these interfaces. For the trial system the SGSN SS7 function holds a internalHLR database to simulate a GR interface to a HLR.
ISSUE 1 REVISION 2 GPRS Overview
�MOTOROLA LTD. 2000 GPRS01: GPRS Architecture
FOR TRAINING PURPOSES ONLY
5–7
SGSN Architecture
SS7 FUNCTION
HLR
CONTROL FUNCTION
SGSN – CONTROL
SF
SGSN GNPROC
SGSN GbPROC
FR E1 FR E1
BSS
COMMHUB
ISSUE 1 REVISION 2GPRS Overview
�MOTOROLA LTD. 2000GPRS01: GPRS Architecture
FOR TRAINING PURPOSES ONLY
5–8
FunctionalEntities andHardwareMapping
The functional entities for the SGSN can be mapped to the same processor board ordistributed among processor boards. This allows the configuration of GSN to adapt tothe different needs of networks.
SGSN Architecture
The SGSN functional entities will be split into functions. The Control function and theTransmission function.
Control Function
The Control function will comprise an instance of SGSN–control and SGSN–OAMP. TheControl function holds the OAMP function for the CF and the TF.
Transmission Function
The SGSN–GBPROC and SGSN–GNPROC are combined together to form theTransmission function on a processor board. The board will have 2 mezzanine interfaceboards supporting up to 4 E1s to allow connection to the BSS.
SS7 Function
The SS7 function holds a internal HLR simulating a Gr interface to a HLR.
ISSUE 1 REVISION 2 GPRS Overview
�MOTOROLA LTD. 2000 GPRS01: GPRS Architecture
FOR TRAINING PURPOSES ONLY
5–9
Functional entities and hardware mapping
SF SGSN–CF SGSN TF
SF
HLR
OAMP
sgsn – control
tf
sgsn – gbproc
sgsn – gnproc
E1I/F
BSC
ISSUE 1 REVISION 2GPRS Overview
�MOTOROLA LTD. 2000GPRS01: GPRS Architecture
FOR TRAINING PURPOSES ONLY
5–10
CPX 8216
The CPX 8216 is a sixteen slot, high availability Compact PCI system with two separatesix slot Compact PCI 1/0 domains and the capability to contain redundant CPU modulesand redundant Hot–Swap Controller (HSC) modules in the remaining 2 slots of eachdomain.
CPX 8216 is designed as a highly reliable system by providing several levels of systemreliability based on hardware and software. The system allows for integration of standardoff–the–shelf Compact PCI hardware.
ISSUE 1 REVISION 2 GPRS Overview
�MOTOROLA LTD. 2000 GPRS01: GPRS Architecture
FOR TRAINING PURPOSES ONLY
5–11
ISSUE 1 REVISION 2GPRS Overview
�MOTOROLA LTD. 2000GPRS01: GPRS Architecture
FOR TRAINING PURPOSES ONLY
5–12
SystemConfiguration
The CPX 8216 is a flexible system that allows for multiple configuration of processorcontrol, its redundancy and peripheral configurations.
Three possible configurations:
� Simpler system containing a single CPU and Hop Swap Controller controlling bothdomains.
� An active/passive system where one pair of CPU and HSC control both domainswith a stby CPU and HSC.
� Active/Active – each CPU runs a single domain while also serving as a backup tothe other CPU.
For field trial the backplane is not used and there is no system slot processor.
ISSUE 1 REVISION 2 GPRS Overview
�MOTOROLA LTD. 2000 GPRS01: GPRS Architecture
FOR TRAINING PURPOSES ONLY
5–13
I/O
S
T
LO
I/O
S
T
LO
I/O
S
T
LO
I/O
S
T
LO
I/O
S
T
LO
I/O
S
T
LO
I/O
S
T
LO
I/O
S
T
LO
I/O
S
T
LO
I/O
S
T
LO
I/O
S
T
LO
I/O
S
T
LO
I/O
I/O
S
T
LO
I/O
S
T
LO
HSC
A
I/O
CPU
A
CPU
I/O DOMAIN BI/O DOMAIN A
I/O
S
T
LO
I/O
S
T
LO
I/O
S
T
LO
I/O
S
T
LO
I/O
S
T
LO
I/O
S
T
LO
I/O
S
T
LO
I/O
S
T
LO
I/O
S
T
LO
I/O
S
T
LO
I/O
S
T
LO
I/O
S
T
LO
I/O I/O
I/O
S
T
LO
I/O
S
T
LO
CPU
B
HSC
A
CPU
B
I/O I/O
CPU
A
HSC
B
CPU
I/O DOMAIN BI/O DOMAIN A
I/O
S
T
LO
I/O
S
T
LO
I/O
S
T
LO
I/O
S
T
LO
I/O
S
T
LO
I/O
S
T
LO
I/O
S
T
LO
I/O
S
T
LO
I/O
S
T
LO
I/O
S
T
LO
I/O
S
T
LO
I/O
S
T
LO
I/O I/O
I/O
S
T
LO
I/O
S
T
LO
CPU
B
HSC
A
CPU
B
I/O I/O
CPU
A
HSC
B
CPU
PASSIVECU/HSC
I/O DOMAIN BI/O DOMAIN A
ACTIVE CPU ACTIVE HSC
Simplex
Active /Passive
Active/Active
ISSUE 1 REVISION 2GPRS Overview
�MOTOROLA LTD. 2000GPRS01: GPRS Architecture
FOR TRAINING PURPOSES ONLY
5–14
I/OConfigurations
The CPX 8216 contains two independent eight slot Compact PCI buses. One slot ineach bus is dedicated to a system processor and the other is needed for the hop swapcontroller (HSC). This leaves six slots on each bus to support 1/0 devices ornon–system processors.
ISS
UE
1 RE
VIS
ION
2G
PR
S O
verview
�M
OTO
RO
LA LT
D. 2000
GP
RS
01: GP
RS
Architecture
FO
R T
RA
ININ
G P
UR
PO
SE
S O
NLY
5–15
12
34
56
78
910
1112
1314
1516
Rear S
lots
Front S
lots
I/O Slot (Black
I/O Slot (Black
I/O Slot (Black
I/O Slot (Black
I/O Slot (Black
I/O Slot (Black
CPU (Red)
None
CPU (Red)
None
CPU Tms (Red)
Bridge (Tan)
CPU Tms (Red)
Bridge (Tan)
I/O Tms (Black
I/O Slot (Black
I/O Slot (Black
I/O Slot (Black
I/O Slot (Black
I/O Slot (Black
I/O Slot (Black
I/O Tms (Black
I/O Tms (Black
I/O Tms (Black
I/O Tms (Black
I/O Tms (Black
I/O Tms (Black
I/O Tms (Black
I/O Tms (Black
I/O Tms (Black
I/O Tms (Black
I/O Tms (Black
Backplane
ISSUE 1 REVISION 2GPRS Overview
�MOTOROLA LTD. 2000GPRS01: GPRS Architecture
FOR TRAINING PURPOSES ONLY
5–16
Power Supply
The CPX 8216 requires a minimum of two power/fan slot modules and a fan only slotmodule to provide adequate cooling. The system can contain a third power supply/fanslot as part of an N+1 strategy. The modules are hot swapable for AC and DCenvironments.
The fans on the power supplies provide the forced air cooling for the cage. Only two fansare necessary for adequate system cooling with the third fan providing N+1 coolingredundancy.
The power distribution panel is located in the rear of the chassis below the transitionmodule card cage, distributes Ac or DC input power to the system power supplies.These three versions of power distribution power supply; AC, single input DC and dualinput DC.
Power Supply O/P
VOLTAGE REGULATION MINIMUM LOAD MAXIMUM LOAD
+5.06V �3% 0.5A 40.0A
+3.36V �3% 0.5A 40.0A
–12.1V �5% 0.3A 8.0A
+12.1V �5% 0.3A 4.0A
Power Supply I/P
VOLTAGE FREQUENCY INPUT CURRENT
AC 90 – 132
or 190 – 260Vac
47 – 63Hz 6.0A max at 115Vac
3A max at 220Vac
DC 40 – 72Vdc – 113A – 48Vdc at 475V
ISSUE 1 REVISION 2 GPRS Overview
�MOTOROLA LTD. 2000 GPRS01: GPRS Architecture
FOR TRAINING PURPOSES ONLY
5–17
ISSUE 1 REVISION 2GPRS Overview
�MOTOROLA LTD. 2000GPRS01: GPRS Architecture
FOR TRAINING PURPOSES ONLY
5–18
MCP 750 – L252
MCP 750 is a single slot single board computer equipped with an MCP 750 power PCTM 750 series microprocessor. The card has the following characteristics:
� 128 MB DRAM
� One MB flash memory on board (16 bit)
� Additional 64 bit 8 MB flash memory
� Compact flash memory with 48MB compact flash
� One 10/100 Base TX Ethernet port
� One Async Serial port
� One PMC slot
� USB
ISSUE 1 REVISION 2 GPRS Overview
�MOTOROLA LTD. 2000 GPRS01: GPRS Architecture
FOR TRAINING PURPOSES ONLY
5–19
ISSUE 1 REVISION 2GPRS Overview
�MOTOROLA LTD. 2000GPRS01: GPRS Architecture
FOR TRAINING PURPOSES ONLY
5–20
MCP750
MCP 750 offers many features desirable in a Compact PCI computer system, such as:
Compact PCI Bus – MCP750 interfaces to a Compact Peripheral Component Bus (CPCI)using a PCI to PCI bridge. This device allows 64 bit primary and secondary data accessto the CPCI bus on the cage backplane and the on–board local CPCI bus.
The I/0 peripheral interfaces present on the onboard PCI bus include:
� 10/100 Base T Ethernet interface
� UDB host controller
� Fast EIDE interface
� One PMC slot
From the ISA bus are:
� 2 async serial ports
� 2 async/synch serial ports
� keyboard port
� mouse port
� floppy disk controller
� parallel port
� real time clock
� NVRAM
Key to the MCP750 is the industry standard mezzanine interface (DCI Mezzanine Card).PCI modules offer a variety of possibility for 1/0 expansion.
ISSUE 1 REVISION 2 GPRS Overview
�MOTOROLA LTD. 2000 GPRS01: GPRS Architecture
FOR TRAINING PURPOSES ONLY
5–21
MCP 750 Block Diagram
ISSUE 1 REVISION 2GPRS Overview
�MOTOROLA LTD. 2000GPRS01: GPRS Architecture
FOR TRAINING PURPOSES ONLY
5–22
PMC 860 Module
The PMC/860 module has been designed to provide network interface functionality for E1or T1 lines on a single slot PMC format via the front panel or via rear transition module1/0.
PMC/860 provides:
� PCI bus interface via PMC connectors
� 2 E1 or T1 line interfaces via front panel
� Serial 1/0 port
� 40mhz Power DUICC processor
� 4MB DRAM
� 128 KB span
� Up to 2MB boot flash PROM
ISSUE 1 REVISION 2 GPRS Overview
�MOTOROLA LTD. 2000 GPRS01: GPRS Architecture
FOR TRAINING PURPOSES ONLY
5–23
FORCE
SE
RIA
L
Line 1
Line 2
E1–IRD
ISSUE 1 REVISION 2GPRS Overview
�MOTOROLA LTD. 2000GPRS01: GPRS Architecture
FOR TRAINING PURPOSES ONLY
5–24
ATTACH
The MS makes an Attach procedure by the sending of an Attach Request to the SGSN.The Request contains the information elements:–
� Attach Type – GPRS or IMSI or Combined Attach
� MS Network Capability – SMS + Encryption Algorithm capab
� Ciphering Key Sequence
� QOS Parameters
� Force to Stby
� Old P–TMSI or IMSI
� MS Radio Access Capabilities – includes power capability multiple class
� Old RAI
� Requested ready timer value
If the mobile identifies itself using a PTMSI for which the SGSN CF has no GPRSMobility Management (GMM) context, then Subscriber Identification takes place to gainthe MS IMSI. If the IMSI is included in the Attach Request then examination of the IMSIto determine if the MS belongs to the SGSN PLMN is carried out.
Subscriber Identification is performed by the SGSN CF sending an Identity Request tothe MS requesting the MS IMSI. The MS will respond with an IDENTITY RESPONSEcontaining the IMSI.
ISSUE 1 REVISION 2 GPRS Overview
�MOTOROLA LTD. 2000 GPRS01: GPRS Architecture
FOR TRAINING PURPOSES ONLY
5–25
MS CF
ATTACH REQUEST
IDENTITY REQUEST
IDENTITY RESPONSE
ISSUE 1 REVISION 2GPRS Overview
�MOTOROLA LTD. 2000GPRS01: GPRS Architecture
FOR TRAINING PURPOSES ONLY
5–26
ATTACH
HLR Interaction
As the SGSN CF does not have a GMM context for the MS, the HLR must be updatedwith the location of the MS by sending an HPDATE LOCATION LOCATION messageidentifying the SGSN and including the MS IMSI.
Updating the HLR with the new MS location results in the HLR sending the SGSN thesubscriber data.
FIELD DESCRIPTION
IMSI IMSI is the main reference key.
MSISDN The basic MSISDN of the MS.
SGSN Number The SS7 address of the SGSN currently serving thisMS.
SGSN Address The IP address of the SGSN currently serving thisMS.
SMS Parameters SMS–related parameters, e.g. operator–determinedbarring.
MS Purged for GPRS Indicates that the MM and PDP contexts of the MSare deleted from the SGSN.
MNRG Indicates that the MS is not reachable through anSGSN, and that the MS is marked as not reachablefor GPRS at the SGSN and possibly at the GGSN.
GGSN–list The GSN number and optional IP address pairrelated to the GGSN that shall be contacted whenactivity from the MS is detected and MNRG is set.The GSN number shall be either the number of theGGSN or the protocol–converting GSN as describedin the subclauses “MAP–based GGSN – HLRSignalling” and “GTP and MAP–based GGSN – HLRSignalling”.
Each IMSI contains zero or more of the following PDP context subscription records:
PDP Type PDP type, e.g. X.25 or IP.
PDP Address PDP address, e.g. an X.121 address. This field shallbe empty if dynamic addressign is allowed.
QoS Profile Subscribed The quality of service profile subscribed for this PDPcontext. QoS Profile Subscribed is the default level ifa particular QoS profile is not requested.
VPLMN Address Allowed Specifies whether the MS is allowed to use the APNin the domain of the HPLMN only, or additionally theAPN in the domain of the VPLMN.
Access Point Name A label according to DNS naming conventionsdescribing the access point to the external packetdata network.
The SGSN CF creates an MM Context for MS and stores the MS GMM Contextinformation (IMSI, MS NETWORK CAPABILITIES, DRX PARAMETERS, CELL ID andRAI) and the MS PDP CONTEXT information (IMSI, PDP Address, QoS Subscribed,Dynamic Address Allowed, VPLMN address allowed and Access Point Name.
ISSUE 1 REVISION 2 GPRS Overview
�MOTOROLA LTD. 2000 GPRS01: GPRS Architecture
FOR TRAINING PURPOSES ONLY
5–27
MS CF
ATTACH REQUEST
IDENTITY REQUEST
IDENTITY RESPONSE
HLR
UPDATE LOCATION
INSERT SUBSCRIBER DATA
INSERT SUBSCRIBER DATA ACK
UPDATE LOCATION
ISSUE 1 REVISION 2GPRS Overview
�MOTOROLA LTD. 2000GPRS01: GPRS Architecture
FOR TRAINING PURPOSES ONLY
5–28
ATTACH
If the Attach Request message is valid, and the SGSN CF has identified the MS and itbelongs to the SGSN PLM, then the SGSN CF will attempt to configure the TransmissionFunction (TF). The configuration will allocate a new Local TLLI and create a TF GMMcontext.
TLLI Assignment Procedure
Temporary Logical Link Identity (TLLI) consists of 32 bits built either on the basis of aP–TMSI in the case of local or foreign TLLI or a random number in the case of RandomTLLI. MS derives TLLI from the P–TMSI allocated to it from the SGSN.
TLLI BITS
31 30 29 28 27 26–0 TYPE OF TLLI
1 1 T T T T Local
1 0 T T T T Foreign
0 1 1 1 1 R Random
T = Bits derived from P–TMSI
R = Random Bits
A local TLLI is the same as a P–TMSI with the high order bits 31 and 30 set to one andthe rest of the bits set to the P–TMSI. The CF and Tf share the responsibility for theformation of the TLLI, the CL being responsible for the top 16 bits and the TF beingresponsible for the bottom 16 bits.
The CF encodes the portion of the local TLLI and passes it to the TF in the CreateMMCtx_REQ message along with GMM context information for the MS for the TF tostore in its Mobility Management (MM) context.
The TF creates an MM entity for the MS, storing the MM timer values, IMSI, RadioAccess Capabilities and DRX Parameters. The TF concedes its half of the TLLI andreturns the completed local TLLI to the SGSN CF in the CREATEMMCtx_CNF message.The CF now has the complete local TLLI and therefore the P–TMSI as Local TLLI =P–TMSI.
ISSUE 1 REVISION 2 GPRS Overview
�MOTOROLA LTD. 2000 GPRS01: GPRS Architecture
FOR TRAINING PURPOSES ONLY
5–29
MS CF
ATTACH REQUEST
IDENTITY REQUEST
IDENTITY RESPONSE
HLR
UPDATE LOCATION
INSERT SUBSCRIBER DATA
INSERT SUBSCRIBER DATA ACK
UPDATE LOCATION ACK
TF
CREATE MMCTx – REQ
INSERT SUBSCRIBER DATA
CREATE MMCTx – CNF
ATTACH ACCEPT
ATTACH COMPLETE
ISSUE 1 REVISION 2GPRS Overview
�MOTOROLA LTD. 2000GPRS01: GPRS Architecture
FOR TRAINING PURPOSES ONLY
5–30
ATTACH
The SGSN CF, upon return of the complete Local TLLI/P–TMSI from the TF, will send theATTACH ACCEPT message to the MS containing:–
� Attach Result – GPRS only or combined GPRS/IMSI attached Force to Stby
� Periodic RA Timer
� Radio Priority for SMS – Radio Priority Level 1–4
� Routing Area Identification
� Alloc PTMSI – P–TMSI = Local TLLI
� Ready Timer Value – SGSN Configured Value
The GPRS Mobility Management (GMM) context at the SGSN CF will go toGMM–REGISTERED PENDING until the MS replies with the ATTACH CompleteMessage. On receipt of the complete message from the MS using the assigned LocalTLLI the GMM state goes to GMM–REGISTERED.
GPRS Attach Failure Response
Identity Request Timer T3322 STARTED IDENTITY REQ
RANGE 8 SECS STOPPED IDENTITY RESP
RE–SEND MAXIMUM MAX_ACCEPT_ATTEMPT
Attach Accept T3350 STARTED ACCEPT ACCEPT
STOPPED ATTACH COMPLETE
RE–SEND MAXIMUM MAX_IDENTIFICATION_ATTEMPT
If the Attach fails due to either HLR having no need of IMSI or Failure of Transmissionfunction or Communication failure, the CF will send an Attach Reject to the MS andperform an Implicit Detach and log the event.
ISSUE 1 REVISION 2 GPRS Overview
�MOTOROLA LTD. 2000 GPRS01: GPRS Architecture
FOR TRAINING PURPOSES ONLY
5–31
MS CF
ATTACH REQUEST
IDENTITY REQUEST
IDENTITY RESPONSE
HLR
UPDATE LOCATION
INSERT SUBSCRIBER DATA
INSERT SUBSCRIBER DATA ACK
UPDATE LOCATION ACK
TF
CREATE MMCTx – REQ
INSERT SUBSCRIBER DATA
CREATE MMCTx – CNF
ATTACH ACCEPT
ATTACH COMPLETE
START T3350
STOP T3350
START T3322
STOP T3322
ISSUE 1 REVISION 2GPRS Overview
�MOTOROLA LTD. 2000GPRS01: GPRS Architecture
FOR TRAINING PURPOSES ONLY
5–32
Detach
The Detach function enables a mobile to become detached from the network or for thenetwork to detach a mobile from the network. There are two types of detach; Implicitand Explicit detach.
Explicit Detach: MS or Network explicitly requests detach.
Implicit Detach: Occurs in either or both MS and SGSN. No messages exchanged between MS and SGSN.
Reason: Mobile Reachable Timer ExpirationLower Layer Failure occursPaging Fault occursTransmission Configuration occurs
Switch Off
If the Detach is implicit then messaging is passed between the MS and SGSN which willindicate if the detach is due to switch off or not. The result of a detach request with adetach type indicating switch off = TRUE means a Detach Accept message would not bereturned by the network.
ISSUE 1 REVISION 2 GPRS Overview
�MOTOROLA LTD. 2000 GPRS01: GPRS Architecture
FOR TRAINING PURPOSES ONLY
5–33
MS SGSN
DETACH REQUEST
DETACH RESPONSE
DETACH REQUEST
or
DETACH RESPONSE
MS SGSN
DETACH REQUEST
SWITCH OFF = TRUE
ISSUE 1 REVISION 2GPRS Overview
�MOTOROLA LTD. 2000GPRS01: GPRS Architecture
FOR TRAINING PURPOSES ONLY
5–34
Explicit Detach
Explicit Detach is an MS or SGSN detach explicitly requested by one of the elements.Reasons for an Explicit detach could be due to:
1. Insert Subscriber Data from the HLR
2. Unexpected signalling or PTP PDU transfer faults
3. GTP error indication from GGSN
The Control Function (CF) on initiation of an Explicit Detach will attempt to:
1. Message the MS to Detach
2. Delete all active associated PDP contexts in the GGSN if possible
3. Deactivate active associated PDP contexts in the SSGN TF
4. Deactivate associated GMM context in the TF and move to GMM_Deregisteredstate for MS
On initiation of an Explicit Detach from the MS the SGSN CF uses the detach type todetermine the actions required for the detach.
The SGSN CF retrieves the GMM context and PDP context information from its ownGMM context and PDP context and the TF GMM context + PDP context using theGetMMCtx_PE2 message.
ISSUE 1 REVISION 2 GPRS Overview
�MOTOROLA LTD. 2000 GPRS01: GPRS Architecture
FOR TRAINING PURPOSES ONLY
5–35
MS CF
DETACH REQUEST SGSN
GET MMCTx – REQ
SGSN
TFTLLI, IMSI, DETACH TYPE,
FORCE TO STBY
(TLLI, IMSI)
GET MMCTx – CNF
TLLI, IMSI, MM CTX INFO
ISSUE 1 REVISION 2GPRS Overview
�MOTOROLA LTD. 2000GPRS01: GPRS Architecture
FOR TRAINING PURPOSES ONLY
5–36
Explicit Detach
Once the GMM context and active associated PDP contexts have been recovered by theSGSN CF, the PDP contexts are deactivated by sending a Delete PDP Context Requestmessage to GGSN, identifying the PDP contexts by their TID (IMSI and NSAPI). Todelete the PDP contexts at the SGSN TF the message Delete Contx_Req is sentidentifying each PDP context by their IMSI, NSAPI, TLLI. On return of responsemessages from the GGSN and TF that the PDP contexts have been deleted the CF canput its PDP contexts for the MS to INACTIVE.
The SGSN CF can now send the Detach Accept message (identified by TLLI) to the MS.To allow this message the GMM context for MS is maintained at the TF to allow thismessage to be sent. The time T_CF_TXCTL_DELAY01 controls a delay after sending ofDetach Accept before the SGSN CF can send Delete MMCntx_Req to the TF to removethe GMM context for the MS and put the MM context at the SGSN CF to idle.
Network Initiated Explicit Detach
A network initiated detach follows the same procedure as an MS initiated detach. Thedifference is that the Detach Request contains a GMM cause value to indicate why thedetach was initiated. The network will proceed to delete all PDP contexts for the MS andwill wait until the reception of Detach Accept before deleting the GMM Context for the TFand putting the SGSN CF GMM Context to idle for the MS.
ISSUE 1 REVISION 2 GPRS Overview
�MOTOROLA LTD. 2000 GPRS01: GPRS Architecture
FOR TRAINING PURPOSES ONLY
5–37
MS CF
DETACH REQUEST
SGSN
GET MMCtx – REQ
TFSGSN
TLLI, IMSI, detach type, force to stby
(TLLI, IMSI)
GET MMCtx – CNF (TLLI, IMSI, MMCTx info)
GGSN
Delete PDP Context Request(TID)
Delete PDP Context Response(TID)
SGSNTF
Delete PDP Cntx – Req (TLLI, NSAPI, IMSI)
Delete PDP Cntx – Cnf (TLLI, NSAPI, IMSI RESULT CODE)
DETACH ACCEPT
(TLLI)START T_CF_TxCTL_DELAY01
EXPIRY T_CF_TxCTL_DELAY01
DELETE MMCTX – Req (TLLI, IMSI)
DELETE MMCTX – Cnf (TLLI, IMSI, RESULT CODE)
ISSUE 1 REVISION 2GPRS Overview
�MOTOROLA LTD. 2000GPRS01: GPRS Architecture
FOR TRAINING PURPOSES ONLY
5–38
Implicit Detach
Implicit Detach occurs when a Lower Layer Failure occurs or GMM Mobile ReachableTimer expires. This occurs in both the MS and SGSN and each separately follow aprocedure to become GPRS detached. It is called Implicit Detach as there is nomessaging between the MS and the SGSN.
The procedure for an Implicit Detach is on the arrival of a Status_Ind message from theTransmission Function (TF) indicating Mobile Reachable Timer expiry or Lower LayerFailure or a Page Ind where the SGSN cannot find a GMM context associated with theIMSI.
The SGSN CF then follows the detach procedure without sending a Detach Requiredmessage to the MS. Removing GMM and PDP contexts from the TF and GGSN andchanging the PDP context to inactive and the GMM Context is idle for the MS.
ISSUE 1 REVISION 2 GPRS Overview
�MOTOROLA LTD. 2000 GPRS01: GPRS Architecture
FOR TRAINING PURPOSES ONLY
5–39
MS CFSGSN
GET MMCtx – REQ
TFSGSN
TLLI, IMSI
GET MMCtx – CNF
GGSN
Delete PDP Context Request(TID)
Delete PDP Context Response(TID)
SGSNTF
Delete PDP Ctx – Req (TLLI, NSAPI, IMSI)
Delete PDP Ctx – Cnf (TLLI, NSAPI, IMSI RESULT CODE)
DELETE MMCTX – Req (TLLI, IMSI)
DELETE MMCTX – Cnf (TLLI, IMSI, RESULT CODE)
TLLI, IMSI, MMCtx info
ISSUE 1 REVISION 2GPRS Overview
�MOTOROLA LTD. 2000GPRS01: GPRS Architecture
FOR TRAINING PURPOSES ONLY
5–40
Routing AreaUpdate
A Routing area update occurs when a GPRS attached MS enters a new Routing Area(RA) or when the Periodic Routing Area timer has expired. There are two types ofRouting area updates; Intra SGSN – where the MS has moved into a Routing Areacontrolled by the same SGSN, or Inter SGSN – where the MS has entered a newRouting Area controlled by a new SGSN.
Intra SGSN
On receipt of a Routing Area Update, the SGSN CF must determine if there is a GMMcontext for the MS. If the MS used a Local TLLI then there must be a GMM context forthe MS for the Routing Area Update to be an Intra SGSN.
If the MS uses a foreign TLLI, the TF can not determine the IMSI for the MS. The CFcan convert the foreign TLLI to a Local TLLI and query the TF for the IMSI and MMContext information to check the Ready, Mobile Reachable, MS Radio Access Capability.
Blocking UserData Transfer
As the MS has entered into a new cell location, downlink user data transfer is suspendedfor the MS until the TF is updated with the new cell location. SGSN CF commands theTL using BLOCKTX_Req to stop dl data transfer.
Modify GMMContext
The CF now processes the Routing Area Update, the new Routing Area ld is desiredfrom the BSSGP layer which contains the Cell Global ID. If GMM context informationrequires change, such as Ready Timer values, the CF will modify the TF GMM contextand then send the Routing Area Accept.
The SGSN CF, upon completion of the Routing Area Update function, will unblock thedownlink data transfer at the SGSN TF.
ISSUE 1 REVISION 2 GPRS Overview
�MOTOROLA LTD. 2000 GPRS01: GPRS Architecture
FOR TRAINING PURPOSES ONLY
5–41
MS CF
ROUTING AREA UPDATE REQUEST
SGSN
GET MMCTx – REQ
SGSNTF
fTLLI, UPDATE TYPE, OLD RAI, MS RADIO ACCESSCAPABILITIES, REQ READYTIMER VALUES
(TLLI)
GET MMCTx – CNF
TLLI, IMSI, MMCTx INFO
BLOCKTx–REQ
(TLLI)
BLOCKTx–REQ
(TLLI)
MODIFY MMCtx–REQ
TLLI, IMSI, NEW CGI,TIMER VALUES, MSRADIO ACCESS CAPAB,DRX PARAMETERS
MODIFY MMCtx–CNF
TLLI, IMSI, RESULTROUTING AREA ACCEPT
TLLI, IMSI, Force to Stby,update result, RDY timer
Unblock Tx–REQ(TLLI)
Unblock Tx–CNF(TLLI)
ISSUE 1 REVISION 2Session Management
�MOTOROLA LTD. 2000GPRS01: GPRS Architecture
FOR TRAINING PURPOSES ONLY
5–42
Session ManagementSession Management is concerned with the management of virtual connections (PDPcontexts) between an MS and an SGSN and a GGSN. Each active PDP context definesa virtual path between the MS and a Destination PTP address.
Point to Point subscriptions contain subscriptions to one or more PDP addresses. EachPDP address is described by a PDP context in the MS, SGSN and the GGSN.
The Session Activation function activates a PDP context for a subscriber. The PDPcontext established will be for a specified quality of service (QoS) on a specified NSAPI.
The PDP state model for a PDP context has two states;
Active – the context holds the routing information necessary to process PDUs for a PDPaddress between an MS and GGSN. During Active state the PDP context is updatedaccording to changed subscriber location. Active state is permitted only when theMobility Management state is Standby or Ready.
Inactive – The PDP context does not contain the routing information necessary toprocess a PDU for a particular address . PDP contexts are moved to inactive stateduring deactivation procedure. The active PDP contexts for an MS are moved toINACTIVE when the MM state changes to IDLE.
ISSUE 1 REVISION 2 Session Management
�MOTOROLA LTD. 2000 GPRS01: GPRS Architecture
FOR TRAINING PURPOSES ONLY
5–43
PDP State Model
INACTIVE
ACTIVE
ACTIVATE PDPCONTEXT
DEACTIVATEPDP CONTEXT
orMM STATE
changes to idle
ISSUE 1 REVISION 2Session Management
�MOTOROLA LTD. 2000GPRS01: GPRS Architecture
FOR TRAINING PURPOSES ONLY
5–44
PDP ContextActivation MSInitiated
The MS initiates PDP context activation with an Activate PDP context request message.The message contains PDP context parameters required to set up a PDP contextbetween an MS and an SGSN and a GGSN. Information elements include:
– NSAPI
– PDP type
– PDP Address (leaves blank to request dynamic address)
– Access Point Name (reference point to external network, via DNS)
The SGSN CF on receipt of a session activation request retrieves the MobilityManagement context and the PDP context associated with the subscriber. Thisinformation was stored during the GPRS attach procedure.
The Control Function now validates the PDP context request to ensure that therequested QOS can be met. If the message is valid then the function continues. The CFfirst configures the Transmission function before the GGSN for the PDP context, thusallowing the buffering of PDUs from the GGSN to be buffered.
ISSUE 1 REVISION 2 Session Management
�MOTOROLA LTD. 2000 GPRS01: GPRS Architecture
FOR TRAINING PURPOSES ONLY
5–45
MS CFSGSN
ACTIVATE PDP CONTEXTREQUEST
CONTEXT FOR MS
ISSUE 1 REVISION 2Session Management
�MOTOROLA LTD. 2000GPRS01: GPRS Architecture
FOR TRAINING PURPOSES ONLY
5–46
PDP ContextActivation –Transmissionfunction
The Control Function (CF) sends a PDP context activation message detailing the TLLI,IMSI, NSAPI, QOS and GGSN IP address. This information allows the Transmissionfunction to set up and identify the virtual paths to route PDUs to and from the MS andGGSN. The Transmission Function (TF) will inform the SGSN of the result ofconfiguration for the PDP context.
GGSN Configuration
Once the TF has been configured for the PDP context, enabling the buffering of PDUs tothe MS from the GGSN, then the Control function attempts to activate the PDP context inthe GGSN. The GGSN that the SGSN CF selects can be determined from threesources:
� Access Point Name from Subscriber data from HLR
� Access Point Name from MS in PDP Context Request, used if APN is notspecified in Subscriber data.
� Default GGSN address configured in SGSN CF.
The Create PDP Context Request message is sent to the GGSN with the PDP contextinformation elements required to create a PDP context at the GGSN for the MS,including; SGSN address, TID, PDU negotiated, End User address and protocolconfiguration options.
The GGSN creates a new entry in its PDP context table, storing the informationnecessary to route PDUs from the SGSN to an external network entity.
The GGSN returns a PDP Context Response message indicating whether TCP or UDPwill be used to transport PDU between the SGSN and GGSN. Also included are the TID,GGSN address, Cause Value indicating the success of the function.
ISSUE 1 REVISION 2 Session Management
�MOTOROLA LTD. 2000 GPRS01: GPRS Architecture
FOR TRAINING PURPOSES ONLY
5–47
MS CFSGSN
TFSGSN
GGSN
Create PDP Context Request
Create PDP Context Response
Activate PDPContext Request
CONTEXT FOR MS
Create PDPCtx_REQ
Create PDPCtx_CNF
ISSUE 1 REVISION 2Session Management
�MOTOROLA LTD. 2000GPRS01: GPRS Architecture
FOR TRAINING PURPOSES ONLY
5–48
Uplink Activation
Once the SGSN Control Function (CF) has received a successful PDP ContextResponse from the GGSN, the function will activate the Uplink MS to External NetworkEntity. This ensures that the Transmission Function (TF) can process uplink PDUs fromthe MS when the Activate PDP Context Accept is sent to the MS. The Control Functionsends an Activate Uplink Req message to TF referring to the context by TLLI, IMSI andNSAPI and including the path protocol to be used for transport of PDUs, UDP or TCP.The TF will respond with Activate Uplink_CNF with result of function.
PDP ContextAccept
After receipt from the Transmission function of successful activation of the uplink, thecontrol function sends an Activate PDP Context Accept message to the MS. Themessage returns the PDP parameters for a PDP context. Included in the message are:
Transaction Identifier – from MS PDP Context Request Message
Negotiated QOS – Returned QOS profile
Negotiated LLC SAPI – Returned LLC SAPI
Radio Priority – Value for QOS
PDP Address – PDP address for MS
After sending the PDP Context Accept message the SGSN CF sets the CF PDP Contextfields with the PDP context information, NSAPI, Negotiated QOS, State, GGSN addressin use, PDP address, QOS Requested.
ISSUE 1 REVISION 2 Session Management
�MOTOROLA LTD. 2000 GPRS01: GPRS Architecture
FOR TRAINING PURPOSES ONLY
5–49
MS CFSGSN
TFSGSN
GGSN
Create PDP Context Request
Create PDP Context Response
Activate PDPContext Request
CONTEXT FOR MS
Create PDPCtx_REQ
Create PDPCtx_CNF
SGSNTF
Activate Uplink_REQ
Activate Uplink_CNF
Activate PDPContext Accept
ISSUE 1 REVISION 2Session Management
�MOTOROLA LTD. 2000GPRS01: GPRS Architecture
FOR TRAINING PURPOSES ONLY
5–50
ActivateDownlink
After sending an Activate PDP Context Accept message to the MS, the SGSN CF willactivate the Downlink with Activate Downlink_REQ to the TF with the reorder indicator toindicate if the PDUs should be delivered in sequence to the GGSN. Upon return of theActivate Downlink_CNF with an indicated success the CF will set the PDP context toActive.
ISSUE 1 REVISION 2 Session Management
�MOTOROLA LTD. 2000 GPRS01: GPRS Architecture
FOR TRAINING PURPOSES ONLY
5–51
MS CFSGSN
TFSGSN
GGSN
Create PDP Context Request
Create PDP Context Response
Activate PDPContext Request
CONTEXT FOR MS
Create PDPCtx_REQ
Create PDPCtx_CNF
SGSNTF
Activate Uplink_REQ
Activate Uplink_CNF
Activate PDPContext Accept SET PDP CONTEXT
Activate Downlink_REQ
Activate Uplink_CNF
ACTIVE PDP CONTEXT
ISSUE 1 REVISION 2Session Management
�MOTOROLA LTD. 2000GPRS01: GPRS Architecture
FOR TRAINING PURPOSES ONLY
5–52
PDP ContextDeactivation
The deactivation of a PDP Context for an MS can be initiated by the MS or the Network.An SGSN PDP context deactivation can be carried out without messaging the MS. Thismay be because the MS cannot be reached or the SGSN Control function needs to cleanup a session activation that has failed.
An MS initiated Deactivate Context Request comprising TLLI, IMSI, TI and a cause valuefor the deactivation, such as regular PDP context deactivating or insufficient resources.
The SGSN Control function now retrieves the GMM and PDP context for the MS from itsdata stores. The importance is the retrieval of the GGSN IP address to allow themessaging of the GGSN to deactivate the PDP context. The retrieved GGSN address isthen used to send the Delete PDP Context Request containing the TID (IMSI, NSDPI)which uniquely identifies the PDP context at the GGSN.
The SGSN CF will delete the TF PDP context regardless of whether the GGSN PDPdeactivate was successful or not. The SGSN CF sends the TF a Delete PDPCtx_REQmessage, identifying the TLLI, NSDPI of the PDP context to delete.
After return of the Delete PDPCtx_CNF from the TF the Control Function will set thePDP context to Inactive and send a Deactivate PDP Context Accept identified by TLLI,IMSI and TI containing the result code.
ISSUE 1 REVISION 2 Session Management
�MOTOROLA LTD. 2000 GPRS01: GPRS Architecture
FOR TRAINING PURPOSES ONLY
5–53
MS CFSGSN
GGSN
Delete PDP Context Request
Delete PDP Context Response
Deactivate PDPContext Request
CONTEXT FOR MS
SGSNTF
Delete PDPCtx–Request
Deactivate PDPContext Accept
GO INACTIVE
(TLLI, IMSI, TI, CAUSE)
(GGSN IP ADDRESS, TID)
(GGSN IP ADDRESS, TID)
(TLLI, IMSI, NSAPI)
Delete PDPCtx–Response
(TLLI, IMSI, NSAPI, RESULT CODE)
(TLLI, IMSI, TI, CAUSE)
ISSUE 1 REVISION 2Session Management
�MOTOROLA LTD. 2000GPRS01: GPRS Architecture
FOR TRAINING PURPOSES ONLY
5–54
Paging for GPRSDownlinkTransfer
An MS requires paging by the network if a downlink PDU or signalling PDU needs to betransferred to an MS in a Standby State. An MS in Standby cannot receive Point toPoint PDUs or signalling PDUs. The Paging Procedure will move the GPRS MobilityManagement (GMM) state of the MS to ready so any uplink LLC frame from the MS willput the GMM state at the SGSN to READY and is therefore a valid response to page.The SGSN only knows which routing area an MS was last in when the MMS is in standbystate.
The Paging function is initiated by the Transmission Function which, on receipt ofdownlink PDU for an MS in Standby state, notifies the SGSN CF that a PS Page isrequired with PDGE_IND. Prior to paging, the CF GMM Context information must beretrieved to be able to formulate the Page. The MS location is known by Routing Area, arouting area may be served by multiple BSS. Each BSS serving the routing area wherethe MS was last known to be located must be messaged to perform a page.
A BVCI for signalling is maintained for each BSS. The SGSN CF maintains a mapping ofBVCI SIG to RAI (Routing Area Identification). The SGSN CF sends out a paging PSPDU to each BSS serving the routing area of the MSs last known location.
ISSUE 1 REVISION 2 Session Management
�MOTOROLA LTD. 2000 GPRS01: GPRS Architecture
FOR TRAINING PURPOSES ONLY
5–55
MS
TFSGSN GGSN
CONTEXT MS
SGSNCF
DOWNLINK PDU
PAGE – IND
(TLLI, IMSI, CGI, DRX, MSRADIO ACCESS CAP)BSS
BSS
LLC FRAME
PAGE PSPDU START TIMERPAGE RESPONSE
PAGE PSPDU
(BVCI, IMSI, DRX, RAI, QOS PROFILE, PTMSI)
PAGE REPLIED – IND
(TLLI, IMSI)
STOP TIMERPAGE RESPONSE
ISSUE 1 REVISION 2Session Management
�MOTOROLA LTD. 2000GPRS01: GPRS Architecture
FOR TRAINING PURPOSES ONLY
5–56
Paging
Each Paging PSPDU contains the information elements necessary for the BSS to initiatepaging for an MS within a group of cells. The IMSI and DRX parameters allow the BSSto determine the paging population number of the MS. QOS profile indicates the priorityof the paging request relative to other Paging Request messages buffered in the BSS.This ensures that higher priority MS will be paged first. The MS is paged using theP_TMSI.
When an MS receives a paging message it will carry out a packet access procedure andsend an LLC frame. When the SGSN receives the LLC frame the GMM context ismoved to ready in the SGSN TF and a Page Response Indication is sent to the ControlFunction.
Receipt of a Page Response Indication from the TF will stop the paging function at theSGSN CF.
Page Response Timer T3313
The SGSN CF starts Page Response Timer T3133 after sending all Page PSPDU to theBSSs. Receipt of the Page Response Indication from the transmission function will stopthe timer and the paging function. Expiry of the Page Response timer will result in PagePS PDUs being sent to all BSSs within the routing area. The number of transmissions iscontrolled by MAX_PAGE_ATTEMPT.
ISSUE 1 REVISION 2 Session Management
�MOTOROLA LTD. 2000 GPRS01: GPRS Architecture
FOR TRAINING PURPOSES ONLY
5–57
MS
TFSGSN GGSN
CONTEXT MS
SGSNCF
DOWNLINK PDU
PAGE – IND
BSS
BSS
LLC FRAME
PAGE PSPDU START T3313
PAGE PSPDU
PAGE REPLIED – INDSTOP T3313
sgsnDnLinkPagingTimer (T3313)
Range 3 – 15 Secs
Default 8
ISSUE 1 REVISION 2Session Management
�MOTOROLA LTD. 2000GPRS01: GPRS Architecture
FOR TRAINING PURPOSES ONLY
5–58
TransmissionFunction
The SGSN Transmission Function (TF) is the functional component of the SGSN whichprovides. PDP PDU data transfer capabilities between the GGSN and the MS.
The TF interfaces to a BSS via a PMC module socket on the Gb link allows theexchange of signalling and user data. The Gb interface uses BSSGP, NS, FR and E1protocols.
The Gn interface uses GPRS Tunnelling protocol which operates over UDP/IP andTCP/IP and defines both signalling and data transfer between GSNs.
ISSUE 1 REVISION 2 Session Management
�MOTOROLA LTD. 2000 GPRS01: GPRS Architecture
FOR TRAINING PURPOSES ONLY
5–59
GGSN
Gn
Gb
Negotiation
*
CO
NT
RO
L IN
TE
RFA
CE
CO
NT
RO
L F
UN
CT
ION
UPLINK/DOWNLINKUSER DATA
SIGNALLING BETWEENSGSN AND GGSN
BSS
MS
L3M
M
LLC + SNDCPPeer to Peer
BSSGPPeer to Peer
ISSUE 1 REVISION 2Session Management
�MOTOROLA LTD. 2000GPRS01: GPRS Architecture
FOR TRAINING PURPOSES ONLY
5–60
SNDCP Peer toPeer
The Sub Network Dependant Convergence Protocol (SNDCP) layer is responsible fordata compression, protocol control information compression and segmentation of PDUs.To carry out these functions the SNDCP entity at the SGSN must carry out XIDnegotiation with its peer at the MS.
XID negotiations between SNDCP peers are carried by LLC XID commands andresponses. An SNDCP XID command is an LLC XID command or a SABM commandcarrying proposed SNDCP XID parameters and LLC XID parameters. An SNDCP XIDresponse is an LLC XID response or LIA response carrying negotiated SNDCP XIDparameters.
SNDCP XIDParameters
Protocol Control Information Compression
Compression Algorithm Algorithm type (Range 0–31)
RFC1144 IP 0
RFC1144 Uncompressed TCP/IP 1
RFC1144 Compressed TCP/IP 2
– Other values reserved
Data Compression Algorithm Algorithm Type (Range 0–31)
V.42 bis 0
– Other values reserved
ISSUE 1 REVISION 2 Session Management
�MOTOROLA LTD. 2000 GPRS01: GPRS Architecture
FOR TRAINING PURPOSES ONLY
5–61
SNDCP LLC LLC SNDCP
LL_XID_REQ
XID
XID
LL_XID_IND
LL_XID_CNF
LL_XID_REQ
ORIGINATOR RECEIVER
ISSUE 1 REVISION 2Session Management
�MOTOROLA LTD. 2000GPRS01: GPRS Architecture
FOR TRAINING PURPOSES ONLY
5–62
LLC Peer to Peer
During Attach, PDP context activation and modification, LLC may negotiate externaloperating XID parameters for a SAPI with its peer LLC.
Negotiation takes place by exchanging XID frames or PDUs containing the parametersuntil a mutually acceptable set of parameters are arrived at.
LLC negotiates XID parameters when an XID frame is received from an MS or during anAttach procedure to negotiate XID parameters for the signalling SAPI, or during PDPcontext activation when SNDCP may issue an XID request for LLC to negotiate SNDCPparameters. LLC may choose to include LLC XID parameters in the same message asthe SNDCP parameters.
ISSUE 1 REVISION 2 Session Management
�MOTOROLA LTD. 2000 GPRS01: GPRS Architecture
FOR TRAINING PURPOSES ONLY
5–63
ISSUE 1 REVISION 2Session Management
�MOTOROLA LTD. 2000GPRS01: GPRS Architecture
FOR TRAINING PURPOSES ONLY
5–64
GGSN – PDPContextActivation
PDUs from MS to external data networks are transferred via SGSN and GGSN. TheGPRS Tunnelling Protocol (GTP) is used between SGSN and GGSN. Tunnels arecreated between the SGSN and GGSN before PDUs can be transferred. Create PDPContext creates a tunnel between the SGSN and GGSN when the MS wants to sendPDUs to an external network. Creating a tunnel between the SGSN and GGSN involvescreating a PDP context at the SGSN and GGSN.
The SGSN sends a Create PDP Context Request message to the GGSN specified eitherin the MS Create PDP Request message or the GGSN address specified in thesubscriber parameters from the HLR or the default GGSN address specified in the SGSNconfiguration.
The Create PDP Context Request from the SGSN is validated by the GGSN. If theTunnel ID (TID) is a new PDP context then the GGSN creates a new PDP context withthe values specified. The GGSN, once a PDP context has been activated, returns aCreate PDP context response with a cause value to indicate the success of the function.
ISSUE 1 REVISION 2 Session Management
�MOTOROLA LTD. 2000 GPRS01: GPRS Architecture
FOR TRAINING PURPOSES ONLY
5–65
SGSN GGSN
Create PDP Context Request
CREATE NEW PDP CONTEXT FOR MS
(TLLI, QOS, END USER PDPREQ)
Create PDP Context Reponse
(Response Accepted)
ISSUE 1 REVISION 2Session Management
�MOTOROLA LTD. 2000GPRS01: GPRS Architecture
FOR TRAINING PURPOSES ONLY
5–66
�MOTOROLA LTD. 2000 GPRS01: GPRS Architecture
FOR TRAINING PURPOSES ONLY
i
Chapter 6
SGSN configuration parameters
ISSUE 1 REVISION 2 Introduction to SGSN configuration parameters
�MOTOROLA LTD. 2000 GPRS01: GPRS Architecture
FOR TRAINING PURPOSES ONLY
6–1
Introduction to SGSN configuration parameters
Purpose of thischapter
The purpose of this chapter is to provide reference information for SGSN configurationparameters.
How this chapteris structured
This chapter contains SGSN configuration parameters information, using the followingstructure to present that information:
� An introduction to the chapter and the chapter structure.
� Details of the MIB structure identifying the available SGSN objects.
� Parameter tables detailing the parameters available for each SGSN configurationobject.
� Reference diagrams, and explanations, of the purpose of the parameters.
� Data sheets containing information on the individual statistics identified in theattributes tables.
This information may be structured differently for training purposes
NOTE
ISSUE 1 REVISION 2Introduction to SGSN configuration parameters
�MOTOROLA LTD. 2000GPRS01: GPRS Architecture
FOR TRAINING PURPOSES ONLY
6–2
SGSN OIDstructure
Figure 6-1 illustrates the SGSN OID structure, with the emphasis on the configurationmanagement branch of the structure.
Sig
(3)
(1)
mot-gprs-sgsn
(1)
(2) Tx
(3)
(4) Meter
(5) Perf
(6) SW
(7) HA
(8) Op
(9) OAMP
System
SM
(2) SNDCP
(3) LLC
(4) BSSGP
(5) NS
(1)
GTP
GMM
(1) Params
(2) Tables
(1) E1 Link
FrameRelay
(5) NsvcFrPvc
(8) Nse
(12) NseNsvc
RaiNsei
(1)
(8)
(2)
GbLoadShareTransact
Figure 6-1 SGSN OID structure
ISSUE 1 REVISION 2 Introduction to SGSN configuration parameters
�MOTOROLA LTD. 2000 GPRS01: GPRS Architecture
FOR TRAINING PURPOSES ONLY
6–3
Parameter Tables
Details of the parameters available for each configuration management object can befound in the following tables:
Table 6-1 System
Table 6-2 Tx – SM
Table 6-3 Tx – SNDCP
Table 6-4 TX – LLC
Table 6-5 TX – BSSGP
Table 6-6 TX – NS Params
Table 6-7 Tx – NS Tables FrameRelay
Table 6-8 NSVC
Table 6-9 BVC
Table 6-10 Cell-BVC
Table 6-11 Sig – GTP
Table 6-12 Sig – GMM
Table 6-13 Sig – PlaneInformation
ISSUE 1 REVISION 2Introduction to SGSN configuration parameters
�MOTOROLA LTD. 2000GPRS01: GPRS Architecture
FOR TRAINING PURPOSES ONLY
6–4
Referencediagrams
Reference diagrams provide an explanation of the role or function of the configurationparameters. Several parameters may be displayed on a single diagram. The followingreference diagrams are available
System
The following general system parameter diagrams are available:
Figure 6-2 System addresses
Figure 6-3 Configuration file handling
Sig – GTP
The following signalling GTP parameter diagrams are available:
Figure 6-4 GTP Request Attempts
Sig – GMM
The following GPRS Mobility Management parameter diagrams are available:
Figure 6-5 Mobility Management timers
Figure 6-6 Downlink paging timer
Figure 6-7 Maximum paging attempts
Tx – BSSGP
The following BSSGP parameter diagrams are available:
Figure 6-22 BVC block timer
Figure 6-23 BVC reset timer
Figure 6-24 BVC block retries
Figure 6-25 BVC unblock retries
Figure 6-26 BVC set retries
Tx – NS Params
The following NS parameter diagrams are available:
Figure 6-8 TNS block timer
Figure 6-9 NSVC reset timer
Figure 6-10 NSVC Test
Figure 6-11 NSVC block retries
Figure 6-12 NSVC unblock retries
Figure 6-13 NSVC alive retries
Figure 6-14 NSVC resetting
ISSUE 1 REVISION 2 Introduction to SGSN configuration parameters
�MOTOROLA LTD. 2000 GPRS01: GPRS Architecture
FOR TRAINING PURPOSES ONLY
6–5
Tx – NS Tables
The following NS parameter diagrams are available:
Figure 6-15 Gb channel Id
Figure 6-16 SGSN WAN terminations
Figure 6-17 Frame Relay Status Enquiry
Figure 6-18 Gb interface error monitoring
Figure 6-19 NSVCI mapping
Figure 6-20 NSVC Link Id
Figure 6-21 Committed Information Rate
ISSUE 1 REVISION 2Configuration parameter tables
�MOTOROLA LTD. 2000GPRS01: GPRS Architecture
FOR TRAINING PURPOSES ONLY
6–6
Configuration parameter tables
Introduction toconfigurationparameter tables
This section of the manual details the parameters available for each SGSN configurationobject. The parameters available for each object are identified in individual object tables.
Systemparameters
The following table lists the SGSN general system parameters:
Table 6-1 SGSN general system parameters
OIDnumber
parameter
1 sgsnIpAddress
2 sgsnOMC–IpAddress
3 sgsnDefaultAPN
4 sgsnVersion
5 sgsnNetwork OperatorId–MCC
6 sgsnNetworkOperatorId-MNC
7 sgsnDiagConfigFileName
8 sgsnDumpConfigFileName
9 sgsnLoadConfigFileName
10 sgsnLoggingState
11 sgsnTracingState
SessionManagementparameters
The following table lists the SGSN transmit function Session Management parameters:
Table 6-2 SGSN Tx Session Management parameters
OIDnumber
parameter
1 sgsnMaxActivePDP-Context–PerIMSI
ISSUE 1 REVISION 2 Configuration parameter tables
�MOTOROLA LTD. 2000 GPRS01: GPRS Architecture
FOR TRAINING PURPOSES ONLY
6–7
SNDCPparameters
The following table lists the SGSN transmit function SNDCP parameters:
Table 6-3 SGSN Tx SNDCP parameters
OIDnumber
parameter
1 sgsnSNDCP–VersionNum
2 sgsnSNDCP–DataCompressionAlgorithm
3 sgsnNDCP–HeaderCompressionAlgorithm
4 sgsnNDCP–CompressionDirection
5 sgsnNDCP–MaxCompressionCodewords
6 sgsnNDCP–MaxCodewordLength
7 sgsnNDCP–CompressorShared
LLC parameters
The following table lists the SGSN transmit function LLC parameters:
Table 6-4 SGSN Tx LLC parameters
OIDnumber
parameter
1 sgsnLLC-VersionNum
BSSGPparameters
The following table lists the SGSN transmit function BSSGP parameters:
Table 6-5 SGSN Tx BSSGP parameters
OIDnumber
parameter
1 sgsnBSSGP-T1
2 sgsnBSSGP-T2
3 sgsnBSSGP-Bvc-BlockRetries
4 sgsnBSSGP-Bvc-UnblockRetries
5 sgsnBSSGP-Bvc-ResetRetries
ISSUE 1 REVISION 2Configuration parameter tables
�MOTOROLA LTD. 2000GPRS01: GPRS Architecture
FOR TRAINING PURPOSES ONLY
6–8
NS parameters
The following table lists the SGSN transmit function NS parameters:
Table 6-6 SGSN Tx NS parameters
OIDnumber
parameter
1 sgsnNS-TnsBlockTimer
2 sgsnNS-TnsResetTimer
3 sgsnNS-TnsTestInterval
4 sgsnNS-TnsAliveTimer
5 sgsnNS-BlockRetries
6 sgsnNS-UnblockRetries
7 sgsnNS-AliveRetries
8 sgsnNS-ResetPeriod
NS Frame Relaytable parameters
The following table lists the SGSN transmit function NS Frame Relay table parameters:
Table 6-7 SGSN Tx NS Frame Relay table parameters
OIDnumber
parameter
1 sgsnGb–FRRowStatus
2 sgsnGb–FRLinkId
3 sgsnGb–FRBearerChannelId
4 sgsnGb–FRDTE-DCE
5 sgsnGb–FRLMI-DLCI
6 sgsnGb–FRLMI-Std
7 sgsnGb–FRLMI-STDConform
8 sgsnGb–FRT391
9 sgsnGb–FRT392
10 sgsnGb–FRN391
11 sgsnGb–FRN392
12 sgsnGb–FRN393
13 sgsnGb–FRTimeSlot
14 sgsnGb–FR–EndTimeslot
15 sgsnGb-FR-MaxFrame
16 sgsnGb-FR-BitMask
17 sgsnGb-FR-FramingFormat
18 sgsnGb-FR-Encoding
ISSUE 1 REVISION 2 Configuration parameter tables
�MOTOROLA LTD. 2000 GPRS01: GPRS Architecture
FOR TRAINING PURPOSES ONLY
6–9
OIDnumber
parameter
19 sgsnGb–FR–LineBuildOut
20 sganGb-FR-Clocking
NS NsvcFrPvctable parameters
The following table lists the SGSN transmit function NS NsvcFrPvc table parameters:
Table 6-8 SGSN Tx NS NSVCFrPvc table parameters
OIDnumber
parameter
1 sgsnGb–NSVC-RowStatus
2 sgsnGb–NSVC-NSVCI
3 sgsnGb–NSVC-DLCI
4 sgsnGb–NSVC-LinkId
5 sgsnGb–NSVC-BearerChannelId
6 sgsnGb–NSVC-Frpvc-CIR
7 sgsnGb–NSVC-Frpvc-Bc
8 sgsnGb–NSVC-Frpvc-Be
9 sgsnGb–NSVC-Frpvc-StepCount
10 sgsnGb–NSVC-Frpvc-FlowStyle
BVC tableparameters
The following table lists the SGSN transmit function BVC table parameters:
Table 6-9 SGSN Tx NS table parameters
OIDnumber
parameter
1 sgsnGb–BVC–NseNsvcRowStatus
2 sgsnGb–BVC–BVCI
3 sgsnGb–BVC–BCVI–Type
4 sgsnGb–BVC–NSVCI
5 sgsnGb-BVC–SigBVCI
ISSUE 1 REVISION 2Configuration parameter tables
�MOTOROLA LTD. 2000GPRS01: GPRS Architecture
FOR TRAINING PURPOSES ONLY
6–10
Cell-PVCparameters
The following table lists the SGSN transmit function Cell-BVC table parameters:
Table 6-10 SGSN Cell-BVC parameters
OIDnumber
parameter
1 sgsnGb-Cell-BVC-Rowstatus
2 sgsnGb-Cell-BVC-MCC
3 sgsnGb-Cell-BVC-MNC
4 sgsnGb-Cell-BVC-LAC
5 sgsnGb-Cell-BVC-CI
6 sgsnGb-Cell-BVC-PTP-BVCI
Signalling GTPparameters
The following table lists the SGSN signalling GTP parameters:
Table 6-11 SGSN signalling GTP parameters
OIDnumber
parameter
1 sgsnGTP-N3RequestAttempts
Signalling GPRSMobilityManagementparameters
The following table lists the SGSN signalling GPRS Mobility Management parameters:
Table 6-12 SGSN signalling GPRS Mobility Management parameters
OIDnumber
parameter
1 sgsnStandbyTimer
2 sgsnReadyTimer
3 sgsnDnLinkPagingTimer
4 sgsnMaxPagingAttempts
5 sgsnPeriodicRAU-Timer
ISSUE 1 REVISION 2 Configuration parameter tables
�MOTOROLA LTD. 2000 GPRS01: GPRS Architecture
FOR TRAINING PURPOSES ONLY
6–11
Plane Controlparameters
The following table lists the SGSN signalling plane control table parameters:
Table 6-13 Plane Control parameters
OIDnumber
parameter
1 sgsnSigPlaneInfoRowStatus
2 sgsnSigPlaneInfo-MCC
3 sgsnSigPlaneInfo-MNC
4 sgsnSigPlaneInfo-LAC
5 sgsnSigPlaneInfo-CI
6 sgsnSigPlaneInfo-RAC
7 sgsnSigPlaneInfo-BVC
ISSUE 1 REVISION 2System parameter diagrams
�MOTOROLA LTD. 2000GPRS01: GPRS Architecture
FOR TRAINING PURPOSES ONLY
6–12
System parameter diagrams
Systemaddresses
The following diagram identifies the relationship of the system addresses of the SGSNconfiguration parameters. The sgsnIpAddress parameter specifies the logical IPaddress of the OAMP Agent within an SGSN. The sgsnOmcIpAddress parameterspecifies the IP address of the OMC-G for routing SNMP commands.
OMC-G
IP Address = sgsnOmcIpAddress
IP Address = sgsnIpAddress
Commhub
OAMP Agent
SGSN
Figure 6-2 System addresses
ISSUE 1 REVISION 2 System parameter diagrams
�MOTOROLA LTD. 2000 GPRS01: GPRS Architecture
FOR TRAINING PURPOSES ONLY
6–13
Configuration filehandling
The following diagram details how configuration files are handled within the GSN.System parameters (sgsnDiagConfigFileName and sgsnDumpConfigFileName )create a file name, or specify one that already exists, for storage of configurationinformation for diagnostic or archive (dump) purposes.
The sgsnLoadConfigFileName parameter creates a file name, or specifies one thatalready exists, for use when loading a configuration file.
OMC-G
Interface
ConfigurationData Store
GSN OAMP Agent
SNMP
GSN Sub Agent
SGSN Application
SNMPConfiguration
Data Store
Figure 6-3 Configuration file handling
ISSUE 1 REVISION 2sgsnIpAddress
�MOTOROLA LTD. 2000GPRS01: GPRS Architecture
FOR TRAINING PURPOSES ONLY
6–14
sgsnIpAddress
Description
This parameter identifies the IP address of a specific SGSN in a network.
Each SGSN has multiple IP addresses internally. The address defined here is the oneused by the OMC-G, that is, this is where the SGSN agent is running.
This parameter is initialized from /etc/hosts file using alias host name oamphost
Attributes
Value type Integer IP Address x.x.x.x
Valid range x = 0 to 255
Default value 0.0.0.0
Dependencies
Access read only
Status mandatory
Format
dot format, x.x.x.x
where:
0 <= x <= 255
Example
References
ISSUE 1 REVISION 2 sgsnOMC-IpAddress
�MOTOROLA LTD. 2000 GPRS01: GPRS Architecture
FOR TRAINING PURPOSES ONLY
6–15
sgsnOMC-IpAddress
Description
This parameter identifies the IP address of the managing OMC-G.
This parameter is initialized from /etc/hosts file using alias host name omcghost
Attributes
Value type Integer
Valid range 0 to 255
Default value 0.0.0.0
Dependencies
Access read only
Status mandatory
Format
dot format, x.x.x.x
where:
0 <= x <= 255
Example
References
ISSUE 1 REVISION 2sgsnDefaultAPN
�MOTOROLA LTD. 2000GPRS01: GPRS Architecture
FOR TRAINING PURPOSES ONLY
6–16
sgsnDefaultAPN
Description
This parameter identifies the default APN that the SGSN uses, according to the APNselection algorithm specified in GSM 03.60 v6.3.1.
The APN requirement is defined in GSM 03.03.
This parameter contains only the Network Identifier, it does not contain the APN OperatorIdentifier.
Attributes
Value type
Valid range 0 to 63
Default value
Dependencies
Access read - write
Status mandatory
Format
Example
References
GSM 03.60 v6.3.1.
GSM 03.03
ISSUE 1 REVISION 2 sgsnVersion
�MOTOROLA LTD. 2000 GPRS01: GPRS Architecture
FOR TRAINING PURPOSES ONLY
6–17
sgsnVersion
Description
This parameter identifies the software version that runs on the currently identified SGSN.
Attributes
Value type hexidecimal
Valid range 00 to ff (using lower case letters)
Default value GSN00.00.00.00
Dependencies
Access read only
Status mandatory
Format
GSN<system>.<major>.<minor>.<patch>
where:
<system> : GPRS system release number<major> : GSN major release number<minor> : GSN minor release number<patch> : GSN patch level
Example
References
ISSUE 1 REVISION 2sgsnNetworkOperatorId-MCC
�MOTOROLA LTD. 2000GPRS01: GPRS Architecture
FOR TRAINING PURPOSES ONLY
6–18
sgsnNetworkOperatorId-MCC
Description
This parameter is the Network Operator Identification - Mobile Country Code.
Attributes
Value type decimal
Valid range 0 to 9 (in ASCII format)
Default value 000
Dependencies None
Access read - write
Status mandatory
Format
3 decimal digits in ASCII format, with 0 padded at the front.
Example
References
CCITT Rec E.212 Annex A
ISSUE 1 REVISION 2 sgsnNetworkOperatorId-MNC
�MOTOROLA LTD. 2000 GPRS01: GPRS Architecture
FOR TRAINING PURPOSES ONLY
6–19
sgsnNetworkOperatorId-MNC
Description
This parameter is the Network Operator Identification - Mobile Network Code.
Attributes
Value type decimal
Valid range 0 to 9 (in ASCII format)
Default value 00
Dependencies None
Access read - write
Status mandatory
Format
2 decimal digits in ASCII format, with 0 padded at the front.
Example
References
GSM 03.03 v6.1.0
ISSUE 1 REVISION 2sgsnDiagConfigFileName
�MOTOROLA LTD. 2000GPRS01: GPRS Architecture
FOR TRAINING PURPOSES ONLY
6–20
sgsnDiagConfigFileName
Description
This parameter is the full path name of a configuration file to be sanity checked.
When this variable is SET the GSN checks whether the file exists or not. If not, the GSNcreates the file.
Attributes
Value type
Valid range 0 to 256
Default value
Dependencies
Access read - write
Status mandatory
Format
Example
References
ISSUE 1 REVISION 2 sgsnDumpConfigFileName
�MOTOROLA LTD. 2000 GPRS01: GPRS Architecture
FOR TRAINING PURPOSES ONLY
6–21
sgsnDumpConfigFileName
Description
This parameter is the full path name of a configuration file used for a configuration dump.
The SGSN creates the file if it does not already exist.
Attributes
Value type
Valid range 0 to 256
Default value
Dependencies
Access read - write
Status mandatory
Format
Example
References
ISSUE 1 REVISION 2sgsnLoadConfigFileName
�MOTOROLA LTD. 2000GPRS01: GPRS Architecture
FOR TRAINING PURPOSES ONLY
6–22
sgsnLoadConfigFileName
Description
This parameter is the full path name of a configuration file used for SGSN configurationsynchronization, or for configuration through a configuration file.
Attributes
Value type
Valid range 0 to 256
Default value
Dependencies
Access read - write
Status mandatory
Format
Example
References
ISSUE 1 REVISION 2 sgsnLoggingState
�MOTOROLA LTD. 2000 GPRS01: GPRS Architecture
FOR TRAINING PURPOSES ONLY
6–23
sgsnLoggingState
DescriptionThis parameter is used to specify the current level of SGSN logging.
Disable(0) : Default, only the traps are logged.
EnableLevel1(1) : Enable, INFO level.
� Provide supplementary information to an alarm.
� Security alert (for example: unauthorised access).
� Startup/shutdown logging.
� Failure of external components (for example: BSS and GGSN - fromthe perspective of the SGSN).
EnableLevel2(2) : Enable, Medium Verbose level.
� GPRS signalling failure (for example: Attach Reject, Activate Reject,Deactivate Reject).
� MS protocol failure (LLC, SNDCP, MM, SM).
EnableLevel3(3) : Enable, Verbose level.
� All signalling messages (L3MM. GAP, GTP), except the ones logged atthe Medium Verbose level.
� LLC reset.
EnableLevel4(4) : Enable, DEBUG level.
� Detailed logging of internal events, enabling support staff to performdebugging (for example: sequence of function calls, value of variableetc). Logs generated at this level are not expected to be fully understood by the operators.
Enabling the logging at a higher level automatically enables the logging at all lower levels.
Attributes
Value type Integer
Valid range 0 to 4
Default value 0
Dependencies
Access read - write
Status mandatory
Format
Example
References
ISSUE 1 REVISION 2sgsnTracingState
�MOTOROLA LTD. 2000GPRS01: GPRS Architecture
FOR TRAINING PURPOSES ONLY
6–24
sgsnTracingState
Description
This parameter is used to enable/disable SGSN tracing. (For R0 either all protocoltraces are enabled or all disabled).
Disable(0)
Enable(1)
Attributes
Value type Integer
Valid range 0 or 1
Default value 0
Dependencies
Access read - write
Status mandatory
Format
Example
References
ISSUE 1 REVISION 2 Signalling GTP parameter diagrams
�MOTOROLA LTD. 2000 GPRS01: GPRS Architecture
FOR TRAINING PURPOSES ONLY
6–25
Signalling GTP parameter diagrams
GTP RequestAttempts
The following diagram details the PDP Context Request message, which is repeated if noresponse is received during period T3 (mandatory timer). ThesgsnGtpN3RequestAttempts parameter is used to set the number of times (N3counter) that the request is repeated, each request lasting T3.
repeated N3 times
SGSN GGSN
Create PDP Context RequestT3
sgsnGTPN3RequestAttempts
Create PDP Context Request
Create PDP Context Request
Figure 6-4 GTP Request Attempts
ISSUE 1 REVISION 2sgsnGTP-N3RequestAttempts
�MOTOROLA LTD. 2000GPRS01: GPRS Architecture
FOR TRAINING PURPOSES ONLY
6–26
sgsnGTP-N3RequestAttempts
Description
The counter N3-REQUESTS holds the maximum number of attempts made by theSGSN to send a signalling request message.
Attributes
Value type integer
Valid range 1 to 5
Default value 3
Dependencies
Access read - write
Status mandatory
Format
Example
References
GSM 09.60 v5.0.0
ISSUE 1 REVISION 2 GPRS Mobility Management parameter diagrams
�MOTOROLA LTD. 2000 GPRS01: GPRS Architecture
FOR TRAINING PURPOSES ONLY
6–27
GPRS Mobility Management parameter diagrams
MobilityManagementtimers
The following diagram details the Mobility Management states of the mobile subscriber(MS).
The Ready timer determines how long the MS remains in the Ready state. The MS isreturned to the Idle state if a Detach command is received during the timer period. If thetimer expires (reaches the preset value) the MS is placed into the Standby state. Thetimer is over-ridden, and the MS placed into the Standy mode, if a Force to Standbycommand or Abnormal condition occurs.
The Standby timer determines how long the MS remains in the Standby state. The MS isreturned to the Ready state if a PDU is received during the timer period. If the timerexpires the MS is returned to the Idle state.
IDLE
READY
STANDBY
StandbyTimerExpiry
GPRSAttach
GPRSDetach
PDUReception
Ready Timer ExpiryorForce to StandbyorAbnormal Condition
sgsnStanbyTimer–1 = DeactivatedValid Range: 6 – 186 (in multiplesof 6)
sgsnReadyTimer–1 = Deactivated0 = Force to StandbyValid Range: 2 – 1800
Figure 6-5 Mobility Management timers
ISSUE 1 REVISION 2GPRS Mobility Management parameter diagrams
�MOTOROLA LTD. 2000GPRS01: GPRS Architecture
FOR TRAINING PURPOSES ONLY
6–28
Downlink pagingtimer
The following diagram details PDU paging messages used to determine the location ofthe recipient Mobile Subscriber (MS) in the routing area. The sgsnDnLinkPagingTimerparameter determines the value of the downlink paging timer, T3313. The timer governsthe waiting period between a PSPDU paging message being sent to all BSSs and theexpected Page Replied Indication response.
GGSN
Downlink PDU
Page–Ind
BSS#1
BSS#2
Page PSPDU
LLC FRAME
Page Replied –IND
SGSN TF
SGSN CF
StartT3313
StopT3313
MS
sgsnDnLinkPagingTimerRange 3 – 15 Secs
Default 8
Figure 6-6 Downlink paging timer
ISSUE 1 REVISION 2 GPRS Mobility Management parameter diagrams
�MOTOROLA LTD. 2000 GPRS01: GPRS Architecture
FOR TRAINING PURPOSES ONLY
6–29
Maximum pagingattempts
The following diagram details PDU paging messages. The PSPDU paging message issent to all BSS in a routing area and is repeated if a Page Replied Indicator response isnot received from the BSS before the expiry of T3313. The sgsnMaxPagingAttemptsparameter determines the number of times the paging attempt is repeated.
Page–Ind
Page PSPDU
SGSN TF SGSN CF
StartT3313
sgsnMaxPagingAttemptsRange 1 – 5Default 2
Page PSPDU
forMaxPagingAttempts
BSS#1
BSS#2
BSS#1
BSS#2
Figure 6-7 Maximum paging attempts
ISSUE 1 REVISION 2Network Service parameter diagrams
�MOTOROLA LTD. 2000GPRS01: GPRS Architecture
FOR TRAINING PURPOSES ONLY
6–30
Network Service parameter diagrams
NSVC block timer
The following diagram details NS block and unblock PDUs. The sgsnNsTnsBlockTimerparameter determines the period of the TNS block timer, which controls the NSVCblocking and unblocking procedures.
PCU SGSN
NS Block or Unblock PDU TNS Block
sgsnNsTnsBlockTimerRange 1 – 30 Secs
Default 3
NS Block or Unblock Ack PDU
Figure 6-8 NSVC block timer
ISSUE 1 REVISION 2 Network Service parameter diagrams
�MOTOROLA LTD. 2000 GPRS01: GPRS Architecture
FOR TRAINING PURPOSES ONLY
6–31
NSVC reset timer
The following diagram details NS reset PDUs. The sgsnNsTnsResetTimer parameterdetermines the period of the NSVC reset timer. The timer is started when the reset PDUis sent and stopped on receipt of the reset acknowledgement.
The NSVC Reset forces peer entities to a known (blocked) state. Once both entities areat the same state the NSVC unblock procedures can be carried out to bring the NSVCinto service.
PCU SGSN
NS Reset PDU TNS Reset
sgsnNsTnsResetTimerRange 1 – 60 Secs
Default 3
NS Reset Ack PDU
Figure 6-9 NSVC reset timer
ISSUE 1 REVISION 2Network Service parameter diagrams
�MOTOROLA LTD. 2000GPRS01: GPRS Architecture
FOR TRAINING PURPOSES ONLY
6–32
NSVC Test
The following diagram details the Network Service Test procedure. ThesgsnNsTnsAliveTimer parameter controls the NSVC test procedure. The timer isstarted when an NS alive PDU is sent to a peer entity, and is stopped on receipt of an NSAlive Acknowledge PDU.
The sgsnNsTnsTestInterval parameter governs the time between NSVC tests. Thetest interval is started on receipt of the NS alive Acknowledge PDU, and when it expiresthe next NSVC test is started.
PCU SGSN
NS Alive PDU
TNS Alive
sgsnNsTnsTestIntervalRange 1 – 60 Secs
Default 10
NS Alive Ack PDU
TNS TestInterval
TNS TestInterval
sgsnNsTnsAliveTimerRange 1 – 60 Secs
Default 3
Figure 6-10 NSVC Test
ISSUE 1 REVISION 2 Network Service parameter diagrams
�MOTOROLA LTD. 2000 GPRS01: GPRS Architecture
FOR TRAINING PURPOSES ONLY
6–33
NSVC blockretries
The following diagram details the NSVC Block PDU, which is repeated if no response isreceived before the timer expires. The sgsnNsTnsBlockRetries parameter is used toset the number of times that the NSVC Block PDU is sent.
PCU SGSN
NS Block PDU TNS Block
sgsnNsTnsBlockRetriesRange 1 – 30
Default 3
NS Block PDU TNS Block
Figure 6-11 NSVC block retries
ISSUE 1 REVISION 2Network Service parameter diagrams
�MOTOROLA LTD. 2000GPRS01: GPRS Architecture
FOR TRAINING PURPOSES ONLY
6–34
NSVC unblockretries
The following diagram details the NSVC Unblock PDU, which is repeated if no responseis received before the timer expires. The sgsnNsTnsUnblockRetries parameter is usedto set the number of times that the NSVC Unblock PDU is sent.
PCU SGSN
NS Unblock PDU TNS Unblock
sgsnNsTnsUnblockRetriesRange 1 – 30
Default 3
NS Unblock PDU TNS Unblock
Figure 6-12 NSVC unblock retries
ISSUE 1 REVISION 2 Network Service parameter diagrams
�MOTOROLA LTD. 2000 GPRS01: GPRS Architecture
FOR TRAINING PURPOSES ONLY
6–35
NSVC aliveretries
The following diagram details the NSVC Alive PDU which attempts to query the status ofan NSVC. The query is repeated if no response is received before the timer expires.The sgsnNsTnsAliveRetries parameter is used to set the number of times that theNSVC Alive PDU is sent.
PCU SGSN
NS Alive PDU TNS Alive
sgsnNsTnsAliveRetriesRange 1 – 30
Default 3
NS Alive PDU TNS Alive
Figure 6-13 NSVC alive retries
ISSUE 1 REVISION 2Network Service parameter diagrams
�MOTOROLA LTD. 2000GPRS01: GPRS Architecture
FOR TRAINING PURPOSES ONLY
6–36
NSVC resetting
The following diagram details the NSVC resetting procedure. ThesgsnNsTnsResetPeriod parameter sets the period for the NSVC reset procedure.During this period NS Reset PDUs are sent to the peer entity, governed by the ResetTimer. Rest PDUs are sent until a rest acknowledgement is received or the Reset Periodexpires.
For this procedure to function the Rest Period must be set to a greater value than that ofthe Reset Timer.
PCU SGSN
NS Reset PDU TnsResetTimer
sgsnNsTnsResetPeriodRange 1 – 1000 Secs
Default 3
NS Reset PDU TnsResetTimerResetPeriod
ResetPeriod > TnsResetTimer
Figure 6-14 NSVC resetting
ISSUE 1 REVISION 2 sgsnNS-TnsBlockTimer
�MOTOROLA LTD. 2000 GPRS01: GPRS Architecture
FOR TRAINING PURPOSES ONLY
6–37
sgsnNS-TnsBlockTimer
Description
This parameter is the timer, in seconds, that guards the NS blocking and unblockingprocedures.
The blocking or unblocking message is attempted every sgsnNsTnsBlockTimer seconds,until the peer NS acknowledges or the number of retries (sgsnNsBlockRetries orsgsnNsUnblockRetries ) for the procedure is completed.
Attributes
Value type integer
Valid range 1 to 30
Default value 3
Dependencies
Access read - write
Status mandatory
Format
Example
References
ISSUE 1 REVISION 2sgsnNS-TnsResetTimer
�MOTOROLA LTD. 2000GPRS01: GPRS Architecture
FOR TRAINING PURPOSES ONLY
6–38
sgsnNS-TnsResetTimer
Description
This parameter is the timer, in seconds, that guards the NS reset procedure.
The reset is sent every sgsnNS–TnsResetTimer seconds, until the peer NSacknowledges or the sgsnNsResetPeriod expires. It must be less thansgsnNsResetPeriod .
Attributes
Value type integer
Valid range 1 to 60
Default value 3
Dependencies
Access read - write
Status mandatory
Format
Example
References
ISSUE 1 REVISION 2 sgsnNS-TnsTestInterval
�MOTOROLA LTD. 2000 GPRS01: GPRS Architecture
FOR TRAINING PURPOSES ONLY
6–39
sgsnNS-TnsTestInterval
Description
This parameter indicates the periodicity of the NS-VC test procedure, in seconds. It mustbe greater than sgsnNS-TnsAliveTimer .
Attributes
Value type integer
Valid range 1 to 60
Default value 10
Dependencies
Access read - write
Status mandatory
Format
Example
References
ISSUE 1 REVISION 2sgsnNS-TnsAliveTimer
�MOTOROLA LTD. 2000GPRS01: GPRS Architecture
FOR TRAINING PURPOSES ONLY
6–40
sgsnNS-TnsAliveTimer
Description
This parameter is the timer, in seconds, that guards the NS-VC test procedure.
The NsAlive PDU is sent to the peer every sgsnNsTnsAliveTimer seconds, until the peeracknowledges or the number of retries (sgsnNsAliveRetries ) is completed. It must beless than the sgsnNsTnsTestInterval .
Attributes
Value type integer
Valid range 1 to 30
Default value 3
Dependencies
Access read - write
Status mandatory
Format
Example
References
ISSUE 1 REVISION 2 sgsnNS-BlockRetries
�MOTOROLA LTD. 2000 GPRS01: GPRS Architecture
FOR TRAINING PURPOSES ONLY
6–41
sgsnNS-BlockRetries
Description
This parameter is the number of attempts to retry an NS-BLOCK.
Attributes
Value type integer
Valid range 1 to 30
Default value 3
Dependencies
Access read - write
Status mandatory
Format
Example
References
ISSUE 1 REVISION 2sgsnNsUnblockRetries
�MOTOROLA LTD. 2000GPRS01: GPRS Architecture
FOR TRAINING PURPOSES ONLY
6–42
sgsnNsUnblockRetries
Description
This parameter is the number of attempts to retry an NS-UNBLOCK.
Attributes
Value type integer
Valid range 1 to 30
Default value 3
Dependencies
Access read - write
Status mandatory
Format
Example
References
ISSUE 1 REVISION 2 sgsnNS-AliveRetries
�MOTOROLA LTD. 2000 GPRS01: GPRS Architecture
FOR TRAINING PURPOSES ONLY
6–43
sgsnNS-AliveRetries
Description
This parameter is the number of attempts to retry the NS-VC test procedure.
Attributes
Value type integer
Valid range 1 to 30
Default value 3
Dependencies
Access read - write
Status mandatory
Format
Example
References
ISSUE 1 REVISION 2sgsnNS-ResetPeriod
�MOTOROLA LTD. 2000GPRS01: GPRS Architecture
FOR TRAINING PURPOSES ONLY
6–44
sgsnNS-ResetPeriod
Description
This parameter is the period, in seconds, during which reset is attempted. It must begreater than sgsnNsTnsResetTimer .
Attributes
Value type integer
Valid range 1 to 1000
Default value 30
Dependencies
Access read - write
Status mandatory
Format
Example
References
ISSUE 1 REVISION 2 sgsnStandbyTimer
�MOTOROLA LTD. 2000 GPRS01: GPRS Architecture
FOR TRAINING PURPOSES ONLY
6–45
sgsnStandbyTimer
Description
T3315: The value of the Standby Timer in minutes.
As the timer will be encoded in decihours (1/10 of an hour) the unit of increment should be6 minutes. If the value X of the timer is not set to a multiple of 6, it will be truncated. Thetruncated value Y is the nearest multiple of 6, with:
X–6 < Y < X
If truncation occurs, while value Y will be used by the GSN applications, value X is stillreturned in response to a GET request on this variable.
The truncated value of sgsnStandbyTimer should always be greater than thetruncated value of sgsnPeriodicRAU-Timer by a multiple of 6.
Attributes
Value type Integer
Valid range –1 : indicates deactivated6 - 186 : actual timer value
Default value 60
Dependencies
Access read - write
Status mandatory
Format
Example
References
GSM 04.08 v5.6.2, CR A265
ISSUE 1 REVISION 2sgsnReadyTimer
�MOTOROLA LTD. 2000GPRS01: GPRS Architecture
FOR TRAINING PURPOSES ONLY
6–46
sgsnReadyTimer
Description
T3314: The value of the Ready Timer in seconds.
The timer will be encoded in seconds or minutes with certain units of increment,depending on the value to be encoded.
From 2 to 60 seconds, the encoding will be in seconds with the unit of increment 2seconds. If the value X of the timer, in the range 2 - 60 seconds, is not set to a multipleof 2 it will be truncated. The truncated value Y is the nearest multiple of 2, with:
X–2 < Y < X
From 61 to 1800 seconds, the encoding will be in minutes with the unit of increment 60seconds (1 minute). If the value X of the timer, in the range 61 - 1800 seconds, is not setto a multiple of 60 it will be truncated. The truncated value Y is the nearest multiple of60, with:
X–60 < Y < X
If truncation occurs, while value Y will be used by the GSN applications, value X is stillreturned in response to a GET request on this variable.
Attributes
Value type Integer
Valid range –1 : indicates deactivated0 : indicates Force to Standby2 - 1800: actual timer value
Default value 32
Dependencies
Access read - write
Status mandatory
Format
Example
References
GSM 04.08 v5.6.2, CR A265 Rev 5
ISSUE 1 REVISION 2 sgsnDnLinkPagingTimer
�MOTOROLA LTD. 2000 GPRS01: GPRS Architecture
FOR TRAINING PURPOSES ONLY
6–47
sgsnDnLinkPagingTimer
Description
T3313: The value of the Downlink transfer paging Timer in seconds.
Attributes
Value type Integer
Valid range 3 to 15
Default value 8
Dependencies
Access read - write
Status mandatory
Format
Example
References
GSM 04.08 v5.6.2, CR A265 Rev 5
ISSUE 1 REVISION 2sgsnMaxPagingAttempts
�MOTOROLA LTD. 2000GPRS01: GPRS Architecture
FOR TRAINING PURPOSES ONLY
6–48
sgsnMaxPagingAttempts
Description
This parameter identifies the maximum number of attempts to page an MS.
Attributes
Value type Integer
Valid range 1 to 5
Default value 2
Dependencies
Access read - write
Status mandatory
Format
Example
References
GSM introduced.
ISSUE 1 REVISION 2 sgsnPeriodicRAU-Timer
�MOTOROLA LTD. 2000 GPRS01: GPRS Architecture
FOR TRAINING PURPOSES ONLY
6–49
sgsnPeriodicRAU-Timer
Description
T3312: The value of the Periodic RAU (Routing Area Update) Timer in minutes.
As the timer will be encode in decihours (1/10 of an hour) the unit of increment should be6 minutes. If the value X of the timer is not set to a multiple of 6, it will be truncated. Thetruncated value Y is the nearest multiple of 6, with:
X–6 < Y < X
If truncation occurs, while value Y will be used by the GSN applications, value X is stillreturned in response to a GET request on this variable.
The truncated value of sgsnPeriodicRAU-Timer should always be smaller than thetruncated value of sgsnStandbyTimer by a multiple of 6.
Attributes
Value type Integer
Valid range –1 : indicates deactivated6 - 180 : actual timer value
Default value 54
Dependencies
Access read - write
Status mandatory
Format
Example
References
GSM 04.08 v5.6.2, CR A562
ISSUE 1 REVISION 2NS Tables parameter diagrams
�MOTOROLA LTD. 2000GPRS01: GPRS Architecture
FOR TRAINING PURPOSES ONLY
6–50
NS Tables parameter diagrams
Gb channel Id
The following diagram details an E1 bearer channel. The Id of this channel can bespecified by use of the sgsnFrBearerChannelId parameter.
Range: 0 – 30
DLCI = 177 DLCI = 177
DLCI = 45DLCI = 45
Bearer Channel
sgsnFrBearerChannelId
Default 0
Figure 6-15 Gb channel Id
ISSUE 1 REVISION 2 NS Tables parameter diagrams
�MOTOROLA LTD. 2000 GPRS01: GPRS Architecture
FOR TRAINING PURPOSES ONLY
6–51
SGSN WANterminations
The following diagram provides SGSN WAN termination details. The SGSN has tofunction as Data Terminal Equipment (DTE) or Data Communications Equipment (DCE),depending on the type of WAN interface. The SGSN is set to function as DTE or DCE byuse of the sgsnFrDteDce parameter.
sgsnFrDteDce
BSS SGSNGb
DCEDTE
Direct Connection
Gb Gb
DTE DTE
Range: 0 = DCE
1 = DTE
FrameRelay
ConnectionBSS SGSN
Figure 6-16 SGSN WAN terminations
ISSUE 1 REVISION 2NS Tables parameter diagrams
�MOTOROLA LTD. 2000GPRS01: GPRS Architecture
FOR TRAINING PURPOSES ONLY
6–52
Frame RelayStatus Enquiry
The following diagram details the Frame Relay Status Enquiry procedure. ThesgsnFrT391 parameter sets the period between Status Enquiry messages being sentfrom the user to the network.
Timer T392 is started when the Status response is sent from the network to the user, andthe next Status Enquiry should arrive before the timer expires. Parameter sgsnFrT392sets the value of the timer.
The complete status enquiry procedure is governed by counter N391, which determinesthe number of Status Enquiries that have to be sent before a Full Status Enquiry is sent.Parameter sgsnFrN391 sets the value of the counter.
UserNetwork
Status EnquiryT391
Status Enquiry
Full Status Enquiry
N391
Status
Status
Full Status
sgsnFrT391Range: 5 – 29 SecsDefault 10
T392
sgsnFrT392Range: 6 – 30 Secs
Default 15
sgsnFrT392 > sgsnFrT391
sgsnFrN391Range: 1 – 255Default 6
Figure 6-17 Frame Relay Status Enquiry
ISSUE 1 REVISION 2 NS Tables parameter diagrams
�MOTOROLA LTD. 2000 GPRS01: GPRS Architecture
FOR TRAINING PURPOSES ONLY
6–53
Gb Interfaceerror monitoring
The following diagram details the Gb Interface error monitoring, used in conjunction withthe Status response timer T392. Counter N393 monitors the number of error events, andis incremented each time the timer expires or an invalid Status Enquiry is received.Counter N392 monitors the number of contiguous error events. Parameter sgsnFrN393sets the maximum number of error events to be counted, and parameter sgsnFrN392sets the number of contiguous error events to be counted.
N393
N392
T392
sgsnFrN392Range 1 – 10
Default 3
Network
sgsnFrN393Range 1 – 10
Default 4
No Status Enquiry
sgsnFrN392 <= sgsnFrN393
Figure 6-18 Gb interface error monitoring
ISSUE 1 REVISION 2NS Tables parameter diagrams
�MOTOROLA LTD. 2000GPRS01: GPRS Architecture
FOR TRAINING PURPOSES ONLY
6–54
NSVCI mapping
The following diagram details the mapping between protocol layers. In a Point to Pointconnection the NSVCI and DLCI have end to end significance. In an intermediate FrameRelay network only the NSVCI has end to end significance.
BSSGP
NSVCI
DLCI
NSVCI
DLCI DLCI
Chan ID Chan ID
sgsnNsvcFrPvcDLCI
Range: 16 – 991
Default 16
FrameRelay
NS
E1
BSSGP
NS
FrameRelay
E1
sgsnNsvcFrPvcNSVCI
Range: 1 – 65535
BSSGP
FrameRelay
NS
E1
BSSGP
FrameRelay
NS
E1
Figure 6-19 NSVCI mapping
ISSUE 1 REVISION 2 NS Tables parameter diagrams
�MOTOROLA LTD. 2000 GPRS01: GPRS Architecture
FOR TRAINING PURPOSES ONLY
6–55
NSVC Link Id
The following diagram details a NSVC Link. ParametersgsnNsvcFrPvcBearerChannelId specifies the identity of a bearer channel within thelink, and parameter sgsnNsvcFrPvcPhyLinkId specifies the identity of the bearer link.
Range: 0 – 30
Bearer Link
DLCI = 177
DLCI = 45
Bearer Channel 1
sgsnNsvcFrPvcBearerChannelId
Default 0
Bearer Channel 2
DLCI = 55
DLCI = 23
Range: 0 – 3
sgsnNsvcFrPvcPhyLinkId
Default 0
Figure 6-20 NSVC Link Id
ISSUE 1 REVISION 2NS Tables parameter diagrams
�MOTOROLA LTD. 2000GPRS01: GPRS Architecture
FOR TRAINING PURPOSES ONLY
6–56
CommittedInformation Rate
The following diagram provides details of the Committed Information Rate (CIR). TheCIR is effectively the amount of information that can be transferred over a given period,and is set by parameter sgsnNsvcFrPvcCIR . Information transferred at the CIR rate isguaranteed to be delivered.
Due to the burst nature of information transfer, the required transfer may exceed theguaranteed limit. An agreed excess, Bc, may be permitted but the information may beeligible for discard. The size of the excess is set using parameter sgsnNsvcFrPvcBc .
It is possible that the excess may also be insufficient. An additional amount, Be, may beagreed but the information is likely to be discarded on entry. The size of the additionalamount is set using parameter sgsnNsvcFrPvcBe .
Bc
1
2
3
4
CIR
T
Guaranteed
Discard Eligible
Discard OnEntryBc + Be
Bits
sgsnNsvcFrPvcCIR
Range 1 – 2048000
Default 1
sgsnNsvcFrPvcBc
Range: 1 – 2048000
Default 1
sgsnNsvcFrPvcBe
Range: 1 – 2048000
Default 0
Figure 6-21 Committed Information Rate
ISSUE 1 REVISION 2 sgsnGb-FR-Table
�MOTOROLA LTD. 2000 GPRS01: GPRS Architecture
FOR TRAINING PURPOSES ONLY
6–57
sgsnGb-FR-Table
Description
This table lists the Frame Relay Bearer Channels for this SGSN.
Row Creation: For the successful creation of a row in this table, the underlyingphysical E1/T1 links must have already been in service.
Row Deletion: If the Bearer Channel defined by the row is not being referenced byany rows in the sgsnGb-Nsvc-Table , it is allowed to be deleted.Any other attempt at deleting it should be rejected.
Row Update Currently, the software does not have provision to update individualentry values for a row after it has been created. Updates can onlybe achieved by deleting the existing row and then inserting a newrow containing the new values, through separate managementrequests.
Attributes
Value type
Valid range
Default value
Dependencies
Access not accessible
Status mandatory
Format
Example
References
ISSUE 1 REVISION 2sgsnGb-FR-Entry
�MOTOROLA LTD. 2000GPRS01: GPRS Architecture
FOR TRAINING PURPOSES ONLY
6–58
sgsnGb-FR-Entry
Description
This parameter defines an entry for a single Frame Relay Bearer Channel.
Attributes
Value type
Valid range
Default value
Dependencies
Access not accessible
Status mandatory
Format
sgsnFrameRelayEntry ::=
SEQUENCE{
sgsnGb-FRRowStatus GSN-RowStatus,
sgsnGb-FRLinkId INTEGER,
sgsnGb-FRBearerChannelId INTEGER,
sgsnGb-FRDTE-Dce INTEGER,
sgsnGb-FRLMI-DLCI INTEGER,
sgsnGb-FRLMI-STD INTEGER,
sgsnGb-FRLMI-STD-Conform INTEGER,
sgsnGb-FRT391 INTEGER,
sgsnGb-FRT392 INTEGER,
sgsnGb-FRN391 INTEGER,
sgsnGb-FRN392 INTEGER,
sgsnGb-FRN393 INTEGER,
sgsnGb-FRStartTimeSlot
sgsnGb-FR-EndTimeslot
sgsnGb-FR-MaxFrame
sgsnGb-FR-BitMask
sgsnGb-FR-FramingFormat
sgsnGb-FR-Encoding
sgsnGb-FR-LineBuildout
sgsnGb-FR-Clocking
INTEGER,
INTEGER
INTEGER
OCTET STRING
INTEGER
INTEGER
INTEGER
INTEGER
}
ISSUE 1 REVISION 2 sgsnGb-FR-Entry
�MOTOROLA LTD. 2000 GPRS01: GPRS Architecture
FOR TRAINING PURPOSES ONLY
6–59
Example
References
ISSUE 1 REVISION 2sgsnGb-FR-RowStatus
�MOTOROLA LTD. 2000GPRS01: GPRS Architecture
FOR TRAINING PURPOSES ONLY
6–60
sgsnGb-FR-RowStatus
Description
This parameter indicates the status of a table row.
Attributes
Value type
Valid range
Default value undefined
Dependencies
Access read - write
Status mandatory
Format
Example
References
ISSUE 1 REVISION 2 sgsnGb–FR-LinkId
�MOTOROLA LTD. 2000 GPRS01: GPRS Architecture
FOR TRAINING PURPOSES ONLY
6–61
sgsnGb–FR-LinkId
Description
This parameter is the identifier of the Frame Relay bearer E1 link, unique within anSGSN. It is used by the SGSN to identify the physical E1/T1 link for configuring theFrame Relay WAN interfaces.
Attributes
Value type integer
Valid range 0 to 3
Default value
Dependencies
Access read only
Status mandatory
Format
Example
References
ISSUE 1 REVISION 2sgsnGb-FR-BearerChannelId
�MOTOROLA LTD. 2000GPRS01: GPRS Architecture
FOR TRAINING PURPOSES ONLY
6–62
sgsnGb-FR-BearerChannelId
Description
This parameter is the identifier of the Bearer Channel, unique within the SGSN for R0,unique within an E1/T1 link in R1. It is used by the SGSN to configure the Frame RelayWAN interfaces.
Attributes
Value type integer
Valid range 0 to 30
Default value
Dependencies
Access read only
Status mandatory
Format
Example
References
ISSUE 1 REVISION 2 sgsnGb-FR-Dte-Dce
�MOTOROLA LTD. 2000 GPRS01: GPRS Architecture
FOR TRAINING PURPOSES ONLY
6–63
sgsnGb-FR-Dte-Dce
Description
This parameter identifies the type of WAN interface, indicating which side of the networkthe SGSN is operating as. The allowable values are DCE (network side) and DTE (userside).
Attributes
Value type integer
Valid range 0 DCE1 DTE
Default value 1
Dependencies
Access read only
Status mandatory
Format
Example
References
ISSUE 1 REVISION 2sgsnGb–FR-LMI-DLCI
�MOTOROLA LTD. 2000GPRS01: GPRS Architecture
FOR TRAINING PURPOSES ONLY
6–64
sgsnGb–FR-LMI-DLCI
Description
This parameter identifies the DLCI value used by the Local Management Interface (LMI).This should be set to 0, which implies the default for the standard being used.
Attributes
Value type integer
Valid range 0 to 991
Default value 0
Dependencies
Access read only
Status mandatory
Format
Example
References
ISSUE 1 REVISION 2 sgsnGb-FR-LMI-STD
�MOTOROLA LTD. 2000 GPRS01: GPRS Architecture
FOR TRAINING PURPOSES ONLY
6–65
sgsnGb-FR-LMI-STD
Description
This parameter identifies the LMI standard to be used by FRS. The following options areavailable:
ITU: ITU-T Q.933 Annex-A
ANSI: Current version of ANSI T1.617 Annex D
Old ANSI: 1991 version of ANSI T1.617 Annex D
OGOF: Original group of 4
Attributes
Value type integer
Valid range 0 ITU1 ANSI2 Old ANSI3 OGOF
Default value 0
Dependencies
Access read only
Status mandatory
Format
Example
References
ISSUE 1 REVISION 2sgsnGb-FR-LMI-STD-Conform
�MOTOROLA LTD. 2000GPRS01: GPRS Architecture
FOR TRAINING PURPOSES ONLY
6–66
sgsnGb-FR-LMI-STD-Conform
Description
This parameter identifies conformance requirements over and above the localmanagement standard.
Attributes
Value type integer
Valid range 0 none1 Sprint
Default value 0
Dependencies
Access read only
Status mandatory
Format
Example
References
ISSUE 1 REVISION 2 sgsnGb-FR-T391
�MOTOROLA LTD. 2000 GPRS01: GPRS Architecture
FOR TRAINING PURPOSES ONLY
6–67
sgsnGb-FR-T391
Description
This parameter is the link integrity verification polling timer. This is the time, in seconds,between the STATUS ENQUIRY messages sent by FRS. The value should be less thanthat of the T392 timer, and is used when the SGSN is configured as DTE.
Attributes
Value type integer
Valid range 5 to 29
Default value 10
Dependencies
Access read only
Status mandatory
Format
Example
References
ISSUE 1 REVISION 2sgsnGb-FR-T392
�MOTOROLA LTD. 2000GPRS01: GPRS Architecture
FOR TRAINING PURPOSES ONLY
6–68
sgsnGb-FR-T392
Description
This parameter is the polling verification timer. This is the time, in seconds, between theSTATUS ENQUIRY messages, as expected by FRS when configured by FRS to detecterrors at the network side. The value should be greater than that of the T391 timer, andis used when the SGSN is configured as DCE.
Attributes
Value type integer
Valid range 6 to 30
Default value 15
Dependencies
Access read only
Status mandatory
Format
Example
References
ISSUE 1 REVISION 2 sgsnGb-FR-N391
�MOTOROLA LTD. 2000 GPRS01: GPRS Architecture
FOR TRAINING PURPOSES ONLY
6–69
sgsnGb-FR-N391
Description
This parameter is the full status polling counter. Every N391 cycles FRS requests aFULL STATUS ENQUIRY from the network to all PVCs.
Attributes
Value type integer
Valid range 1 to 255
Default value 6
Dependencies
Access read only
Status mandatory
Format
Example
References
ISSUE 1 REVISION 2sgsnGb-FR-N392
�MOTOROLA LTD. 2000GPRS01: GPRS Architecture
FOR TRAINING PURPOSES ONLY
6–70
sgsnGb-FR-N392
Description
This parameter is the error threshold value. If the number of errors detected by FRSreaches the threshold value within the last N393 events, the FRS can assume there is aservice affecting condition at the user-network interface. FRS stops transmitting dataand continues link verification procedures. FRS detects service restoration by detectingN392 consecutive events have occurred without error.
N392 should be less than or equal to N393
Attributes
Value type integer
Valid range 1 to 10
Default value 3
Dependencies
Access read only
Status mandatory
Format
Example
References
ISSUE 1 REVISION 2 sgsnGb-FR-N393
�MOTOROLA LTD. 2000 GPRS01: GPRS Architecture
FOR TRAINING PURPOSES ONLY
6–71
sgsnGb-FR-N393
Description
This parameter is the monitored events count. This value is used to set the count cycleused when counting consecutive error or non-error events. It allows FRS to detectwhether error or non-error events predominate.
N393 should be greater than or equal to N392.
If N393 is set to a value much less than N391, the link could go in and out of the errorcondition without the user equipment or network being notified.
Attributes
Value type integer
Valid range 1 to 10
Default value 4
Dependencies
Access read only
Status mandatory
Format
Example
References
ISSUE 1 REVISION 2sgsnGb-FR-StartTimeslot
�MOTOROLA LTD. 2000GPRS01: GPRS Architecture
FOR TRAINING PURPOSES ONLY
6–72
sgsnGb-FR-StartTimeslot
Description
This parameter specifies the timeslots of the bearer channel over the E1/T1 link. Thisparameter, together with sgsnGb-FR-EndTimeslot specifies a continuous span of theE1/T1 timeslots to be used for fractional support.
For an E1 interface, timeslots 0 and 16 are reserved.
Attributes
Value type Integer
Valid range 1 to 31
Default value 1
Dependencies
Access read only
Status mandatory
Format
Timeslots number range is from 0 to 31 and is mapped to the bits in the mask as follows:
timeslot #: 0 1 2 3 4 ... 31Bit in Mask: 0 1 2 3 4 ... 31
(counting from the least significant bit
Example
MSD LSD
000000fe hex = 00000000 00000000 00000000 11111110
Hence, timeslots 1 to 7 are being used by this bearer channel (timeslot 0 is reserved).
References
ISSUE 1 REVISION 2 sgsnGb-FR-EndTimeslot
�MOTOROLA LTD. 2000 GPRS01: GPRS Architecture
FOR TRAINING PURPOSES ONLY
6–73
sgsnGb-FR-EndTimeslot
Description
This parameter is the last timeslot of the bearer channel over the E1/T1 link. Togetherwith sgsnGb-FR-StartTimeslot this parameter specifies a continuous span of the E1/T1timeslots (DSO) to be used for fractional support.
For an E1 interface, timeslots 0 and 16 are reserved.
Attributes
Value type integer
Valid range 1 to 31
Default value 31
Dependencies
Access read only
Status mandatory
Format
Example
References
ISSUE 1 REVISION 2sgsnGb-FR-MaxFrame
�MOTOROLA LTD. 2000GPRS01: GPRS Architecture
FOR TRAINING PURPOSES ONLY
6–74
sgsnGb-FR-MaxFrame
Description
This parameter specifies the maximum size of the HDLC frame that the channel canreceive, inlusive of the 2 bytes CRC and 2 byte address.
Attributes
Value type integer
Valid range 1 to 1604
Default value 1604
Dependencies
Access read only
Status mandatory
Format
Example
References
ISSUE 1 REVISION 2 sgsnGb-FR-BitMask
�MOTOROLA LTD. 2000 GPRS01: GPRS Architecture
FOR TRAINING PURPOSES ONLY
6–75
sgsnGb-FR-BitMask
Description
This parameter defines the valid bits in each timeslot used for this channel.
For example, a 64bps timeslot would be specified with a BitMask 0xFF and a 56kbpswould be specified with BitMask 0x7F.
Attributes
Value type Octet String
Valid range 1
Default value ff
Dependencies
Access read only
Status mandatory
Format
Example
References
ISSUE 1 REVISION 2sgsnGb-FR-FramingFormat
�MOTOROLA LTD. 2000GPRS01: GPRS Architecture
FOR TRAINING PURPOSES ONLY
6–76
sgsnGb-FR-FramingFormat
Description
This parameter specifies the E1 framing format to be used on the entire E1 interface.
Attributes
Value type Integer
Valid range 0 E1CRC4
1 E1BF
Default value
Dependencies
Access read only
Status mandatory
Format
Example
References
ISSUE 1 REVISION 2 sgsnGb-FR-Encoding
�MOTOROLA LTD. 2000 GPRS01: GPRS Architecture
FOR TRAINING PURPOSES ONLY
6–77
sgsnGb-FR-Encoding
Description
This parameter defines the E1 encoding to be used on the entire E1 interface.
Attributes
Value type integer
Valid range 0 AMI
1 HDB3
Default value
Dependencies
Access read only
Status mandatory
Format
Example
References
ISSUE 1 REVISION 2sgsnGb-FR-LineBuildout
�MOTOROLA LTD. 2000GPRS01: GPRS Architecture
FOR TRAINING PURPOSES ONLY
6–78
sgsnGb-FR-LineBuildout
Description
This parameter defines the line buildout to be used on the entire E1 interface.
Attributes
Value type integer
Valid range 0 OHM_75
1 OHM_120
Default value
Dependencies
Access read only
Status mandatory
Format
Example
References
ISSUE 1 REVISION 2 sgsnGb-FR-Clocking
�MOTOROLA LTD. 2000 GPRS01: GPRS Architecture
FOR TRAINING PURPOSES ONLY
6–79
sgsnGb-FR-Clocking
Description
This parameter defines the transmitter clock reference to be used on the entire E1interface.
Attributes
Value type integer
Valid range 0 CLOCK_LOCAL
1 CLOCK_LOOP
Default value
Dependencies
Access read only
Status mandatory
Format
Example
References
ISSUE 1 REVISION 2sgsnMaxActivePDP-Context–PerIMSI
�MOTOROLA LTD. 2000GPRS01: GPRS Architecture
FOR TRAINING PURPOSES ONLY
6–80
sgsnMaxActivePDP-Context–PerIMSI
Description
This parameter identifies the maximum number of Active PDP Context per IMSI.
When set the parameter affects all IMSI, the number is not maintained for individualIMSI.
Attributes
Value type integer
Valid range 1 to 10
Default value 1
Dependencies
Access read - write
Status mandatory
Format
Example
References
ISSUE 1 REVISION 2 sgsnSNDCP-VersionNum
�MOTOROLA LTD. 2000 GPRS01: GPRS Architecture
FOR TRAINING PURPOSES ONLY
6–81
sgsnSNDCP-VersionNum
Description
This parameter identifies the version of GPRS SNDCP that is running.
Attributes
Value type integer
Valid range 0 to 15
Default value 0
Dependencies
Access read only
Status mandatory
Format
Example
References
ISSUE 1 REVISION 2sgsnSNDCP-DataCompressionAlgorithm
�MOTOROLA LTD. 2000GPRS01: GPRS Architecture
FOR TRAINING PURPOSES ONLY
6–82
sgsnSNDCP-DataCompressionAlgorithm
Description
This parameter identifies the preferred data compression algorithm.
Attributes
Value type integer
Valid range 0 : no compression1 : v.42 bis
Default value 1
Dependencies
Access read - write
Status mandatory
Format
Example
References
ISSUE 1 REVISION 2 sgsnSNDCP-HeaderCompressionAlgorithm
�MOTOROLA LTD. 2000 GPRS01: GPRS Architecture
FOR TRAINING PURPOSES ONLY
6–83
sgsnSNDCP-HeaderCompressionAlgorithm
Description
This parameter identifies the preferred header compression algorithm.
Attributes
Value type integer
Valid range 0 : no compression1 : tcp-ip
Default value 1
Dependencies
Access read - write
Status mandatory
Format
Example
References
ISSUE 1 REVISION 2sgsnSNDCP–CompressionDirection
�MOTOROLA LTD. 2000GPRS01: GPRS Architecture
FOR TRAINING PURPOSES ONLY
6–84
sgsnSNDCP–CompressionDirection
Description
v.42 bis P0. This parameter identifies the direction of the data compression. It defineswhether compression will be done on the uplink only, downlink only, both or none.
Attributes
Value type integer
Valid range 0 : none1 : uplink2 : downlink3 : both
Default value 3
Dependencies
Access read - write
Status mandatory
Format
Example
References
ISSUE 1 REVISION 2 sgsnSNDCP-MaxCompressionCodewords
�MOTOROLA LTD. 2000 GPRS01: GPRS Architecture
FOR TRAINING PURPOSES ONLY
6–85
sgsnSNDCP-MaxCompressionCodewords
Description
v.42 bis P1. This parameter identifies the maximum number of codewords the dictionarymay contain.
Attributes
Value type integer
Valid range 512 to 2048
Default value 2048
Dependencies
Access read - write
Status mandatory
Format
Example
References
ISSUE 1 REVISION 2sgsnSNDCP-MaxCodewordLength
�MOTOROLA LTD. 2000GPRS01: GPRS Architecture
FOR TRAINING PURPOSES ONLY
6–86
sgsnSNDCP-MaxCodewordLength
Description
v.42 bis P2. This parameter identifies the maximum length of text a codeword mayrepresent.
Attributes
Value type integer
Valid range 6 to 250
Default value 20
Dependencies
Access read - write
Status mandatory
Format
Example
References
ISSUE 1 REVISION 2 sgsnSNDCP-CompressorShared
�MOTOROLA LTD. 2000 GPRS01: GPRS Architecture
FOR TRAINING PURPOSES ONLY
6–87
sgsnSNDCP-CompressorShared
Description
This parameter identifies whether the preference is to have one data compressor perSAPI (that is, shared by multiple NSAPIs) or one compressor per NSAPI.
Attributes
Value type integer
Valid range 0 : not shared1 : shared
Default value 1
Dependencies
Access read - write
Status mandatory
Format
Example
References
ISSUE 1 REVISION 2sgsnGb-NSVC-Table
�MOTOROLA LTD. 2000GPRS01: GPRS Architecture
FOR TRAINING PURPOSES ONLY
6–88
sgsnGb-NSVC-Table
Description
This table lists the NS–VCs defined for this SGSN, and their mappings to the FR PVC.
Row Creation: For the successful creation of a row in this table, thereferred FR PVC must exist and have already beenproperly configured within the FR network or via directconnection with the BSS. The FR bearer channelreferred must have been configured.
Row Deletion: A row can only be deleted when no link Set has anyreference to the NS-VC defined by it. Any otherattempt at deleting it will be rejected.
Row Update Currently, the software does not have provision toupdate individual entry values for a row after it hasbeen created. Updates can only be achieved bydeleting the existing row and then inserting a new rowcontaining the new values, through separatemanagement requests.
Attributes
Value type
Valid range
Default value
Dependencies
Access not accessible
Status mandatory
Format
Example
References
ISSUE 1 REVISION 2 sgsnGb-NSVCTableEntry
�MOTOROLA LTD. 2000 GPRS01: GPRS Architecture
FOR TRAINING PURPOSES ONLY
6–89
sgsnGb-NSVCTableEntry
Description
Each entry contains one PVC definition and its mapping to the NS - VC.
Attributes
Value type
Valid range
Default value
Dependencies
Access not accessible
Status mandatory
Format
sgsnGb-NSVCTableEntry ::=
SEQUENCE{
sgsnGb-NSVC-RowStatus GSN-RowStatus,
sgsnGb-NSVC-NSVCI INTEGER,
sgsnGb-NSVC-DLCI INTEGER,
sgsnNGb-NSVC-PhyLinkId INTEGER,
sgsnGb-NSVC-BearerChannelId INTEGER,
sgsnGb-NSVC-CIR INTEGER,
sgsnGb-NSVC-Bc INTEGER,
sgsnGb-NSVC-Be INTEGER,
sgsnGb-NSVC-StepCount INTEGER,
sgsnGb-NSVCF-lowStyle INTEGER,
}
Example
References
ISSUE 1 REVISION 2sgsnGb-NSVC-RowStatus
�MOTOROLA LTD. 2000GPRS01: GPRS Architecture
FOR TRAINING PURPOSES ONLY
6–90
sgsnGb-NSVC-RowStatus
Description
This parameter indicates the status of conceptual rows.
Attributes
Value type
Valid range
Default value undefined
Dependencies
Access read - write
Status mandatory
Format
Example
References
ISSUE 1 REVISION 2 sgsnGb-NSVC-NSVCI
�MOTOROLA LTD. 2000 GPRS01: GPRS Architecture
FOR TRAINING PURPOSES ONLY
6–91
sgsnGb-NSVC-NSVCI
Description
This parameter is the identifier of a NS-VC, unique within the SGSN. It is used by Gb tomaintain the NS-VC List and the mapping to the FR PVC.
Attributes
Value type integer
Valid range 1 to 65535
Default value
Dependencies
Access read only
Status mandatory
Format
Example
References
ISSUE 1 REVISION 2sgsnGb-NSVC-DLCI
�MOTOROLA LTD. 2000GPRS01: GPRS Architecture
FOR TRAINING PURPOSES ONLY
6–92
sgsnGb-NSVC-DLCI
Description
This parameter is the FR PVC Data Link Connection ID, unique per FR BearerChannel. Itis used, together with the BearerChannelId, by Gb to maintain the NS-VCI to PVCmapping.
The valid range is 16 to 991; 0 to 15 are reserved for FR and are therefore not availablefor general use.
Attributes
Value type integer
Valid range 16 to 991
Default value 16
Dependencies
Access read only
Status mandatory
Format
Example
References
ISSUE 1 REVISION 2 sgsnGb-NSVC-LinkId
�MOTOROLA LTD. 2000 GPRS01: GPRS Architecture
FOR TRAINING PURPOSES ONLY
6–93
sgsnGb-NSVC-LinkId
Description
This parameter is the identifier for the physical link (E1/T1) as defined in thesgsnGb-FR-Table .
Attributes
Value type integer
Valid range 0 to 3
Default value 0
Dependencies
Access read only
Status mandatory
Format
Example
References
ISSUE 1 REVISION 2sgsnGb-NSVC-BearerChannelId
�MOTOROLA LTD. 2000GPRS01: GPRS Architecture
FOR TRAINING PURPOSES ONLY
6–94
sgsnGb-NSVC-BearerChannelId
Description
This parameter is the FR Channel Identifier of the PVC associated with the NS-VC, asdefined in the sgsnGb-FR-Table .
Attributes
Value type integer
Valid range 0 to 30
Default value 0
Dependencies
Access read only
Status mandatory
Format
Example
References
ISSUE 1 REVISION 2 sgsnGb-NSVC-FR-PVC-CIR
�MOTOROLA LTD. 2000 GPRS01: GPRS Architecture
FOR TRAINING PURPOSES ONLY
6–95
sgsnGb-NSVC-FR-PVC-CIR
Description
This parameter is the committed information rate (bits/sec) at which the FR networktransfers information to the end system under normal conditions. The rate is averagedover time interval T, where T is calculated to be Bc/CIR.
The maximum value will be the rate of full E1 (32 x 64k)
Attributes
Value type integer
Valid range 1 to 2048000
Default value 1
Dependencies
Access read only
Status mandatory
Format
Example
References
ISSUE 1 REVISION 2sgsnGb-NSVCFRPVCBc
�MOTOROLA LTD. 2000GPRS01: GPRS Architecture
FOR TRAINING PURPOSES ONLY
6–96
sgsnGb-NSVCFRPVCBc
Description
This parameter is the committed burst size. This is the maximum amount of data (in bits)that the FR network agrees to transfer under normal conditions, during time interval T.This data may or may not be interrupted (that is, it may appear in one frame or severalframes).
Attributes
Value type integer
Valid range 1 to 2048000
Default value 1
Dependencies
Access read only
Status mandatory
Format
Example
References
ISSUE 1 REVISION 2 sgsnGb-NSVC-FR-PVC-Be
�MOTOROLA LTD. 2000 GPRS01: GPRS Architecture
FOR TRAINING PURPOSES ONLY
6–97
sgsnGb-NSVC-FR-PVC-Be
Description
This parameter is the maximum amount of uncommitted data (in bits) in excess of Bcthat the FR network will attempt to deliver, during time interval T. This data may or maynot be interrupted (that is, it may appear in one frame or several frames). Excess burstis marked discard eligible (DE) by the FRS driver.
Attributes
Value type integer
Valid range 0 to 2048000
Default value 0
Dependencies
Access read only
Status mandatory
Format
Example
References
ISSUE 1 REVISION 2sgsnGb-NSVC-FR-PVC-StepCount
�MOTOROLA LTD. 2000GPRS01: GPRS Architecture
FOR TRAINING PURPOSES ONLY
6–98
sgsnGb-NSVC-FR-PVC-StepCount
Description
This parameter is the value used by FRS when transmitting frames to increase or reduceCIR. If FRS receives stepcount frames with the BECN bit set, it reduces the CIR to thenext step rate below the current offered rate. If it receives stepcount/2 consecutiveframes with the BECN bit not set it increases the CIR.
Attributes
Value type integer
Valid range 2 to 1000
Default value 8
Dependencies
Access read only
Status mandatory
Format
Example
References
ISSUE 1 REVISION 2 sgsnGb-NSVC-FR-PVC-FlowStyle
�MOTOROLA LTD. 2000 GPRS01: GPRS Architecture
FOR TRAINING PURPOSES ONLY
6–99
sgsnGb-NSVC-FR-PVC-FlowStyle
Description
This parameter determines the type of congestion control used by the FRS.
Attributes
Value type integer
Valid range 1 to 7
Default value 3 (FECN + BECN)
Dependencies
Access read only
Status mandatory
Format
Bit Map: FECN - 0x01, BECN - 0x02, CLLM - 0x04
Example
The default value is 3, which sets the first two bits (011). This initiates FECN and BECNcongestion control.
References
ISSUE 1 REVISION 2sgsnLLC-VersionNum
�MOTOROLA LTD. 2000GPRS01: GPRS Architecture
FOR TRAINING PURPOSES ONLY
6–100
sgsnLLC-VersionNum
Description
This parameter identifies the version of GPRS LLC that is running.
Attributes
Value type integer
Valid range 0 to 15
Default value 0
Dependencies
Access read only
Status mandatory
Format
Example
References
ISSUE 1 REVISION 2 BSSGP parameter diagrams
�MOTOROLA LTD. 2000 GPRS01: GPRS Architecture
FOR TRAINING PURPOSES ONLY
6–101
BSSGP parameter diagrams
BVC block timer
The following diagram details BVC block and unblock messages. The sgsnBssgpT1parameter determines the period of the BVC block timer,T1, which controls the blockingand unblocking procedures. A block or unblock message is sent every T1 seconds untilthe appropriate acknowlegement is received.
PCU SGSN
BVC Block STARTT1
BVC Block ACK STOPT1
sgsnBssgpT1Range 1 – 30 Secs
Default 3
BVC Unblock
OR
BVC Unblock ACK
OR
Figure 6-22 BVC block timer
ISSUE 1 REVISION 2BSSGP parameter diagrams
�MOTOROLA LTD. 2000GPRS01: GPRS Architecture
FOR TRAINING PURPOSES ONLY
6–102
BVC reset timer
The following diagram details BVC reset messages. The sgsnBssgpT2 parameterdetermines the period of the BVC reset timer, T2. The timer is started when the resetmessage is sent and stopped on receipt of the reset acknowledgement.
The BVC Reset forces peer entities to a known (blocked) state. Once both entities are atthe same state the BVC unblock procedures can be carried out to bring the BVC intoservice.
PCU SGSN
BVC Reset STARTT2
BVC Reset ACK STOPT2
sgsnBssgpT2Range 1 – 1000 Secs
Default 60
Figure 6-23 BVC reset timer
ISSUE 1 REVISION 2 BSSGP parameter diagrams
�MOTOROLA LTD. 2000 GPRS01: GPRS Architecture
FOR TRAINING PURPOSES ONLY
6–103
BVC block retries
The following diagram details the BVC Block message, which is repeated if no responseis received during period T1. The sgsnBssgpBvcBlockRetries parameter is used toset the number of times that the BVC Block message is sent.
PCU SGSN
BVC Block T1
BVC Block T1
sgsnBssgpBvcBlockRetriesRange 1 – 30
Default 3
repeated for BVCBlockRetries
Figure 6-24 BVC block retries
ISSUE 1 REVISION 2BSSGP parameter diagrams
�MOTOROLA LTD. 2000GPRS01: GPRS Architecture
FOR TRAINING PURPOSES ONLY
6–104
BVC unblockretries
The following diagram details the BVC Unblock message, which is repeated if noresponse is received during period T1. The sgsnBssgpBvcUnblockRetries parameteris used to set the number of times that the BVC Unblock message is sent.
PCU SGSN
BVC Unblock T1
BVC Unblock T1
sgsnBssgpBvcUnblockRetriesRange 1 – 30
Default 3
repeated for BVCUnblockRetries
Figure 6-25 BVC unblock retries
ISSUE 1 REVISION 2 BSSGP parameter diagrams
�MOTOROLA LTD. 2000 GPRS01: GPRS Architecture
FOR TRAINING PURPOSES ONLY
6–105
BVC reset retries
The following diagram details the BVC Reset message, which is repeated if no responseis received during period T2. The sgsnBssgpBvcResetRetries parameter is used toset the number of times that the BVC Reset message is sent.
PCU SGSN
BVC Reset T2
BVC Reset T2
sgsnBssgpBvcResetRetriesRange 1 – 30
Default 3
repeated for BVCResetRetries
Figure 6-26 BVC set retries
ISSUE 1 REVISION 2sgsnGb-BVC-Table
�MOTOROLA LTD. 2000GPRS01: GPRS Architecture
FOR TRAINING PURPOSES ONLY
6–106
sgsnGb-BVC-Table
Description
This table lists the BVCI to NS-VCI mappings for this SGSN.
Row Creation: For the successful creation of a row in this table, the referredNS-VCI must have already been defined in thesgsnGb-NSVC-Table .
Row Deletion: A row may be deleted if the BVC defined by the row is not beingreferenced by any rows in sgsnGb-CellTable orsgsnSigPlaneInfoTable .
Row Update Currently, the software does not have provision to update individualentry values for a row after it has been created. Updates can onlybe achieved by deleting the existing row and then inserting a newrow containing the new values, through separate managementrequests.
Attributes
Value type
Valid range
Default value
Dependencies
Access not accessible
Status mandatory
Format
Example
References
ISSUE 1 REVISION 2 sgsnGb-BVC-TableEntry
�MOTOROLA LTD. 2000 GPRS01: GPRS Architecture
FOR TRAINING PURPOSES ONLY
6–107
sgsnGb-BVC-TableEntry
Description
This parameter defines one BVCI.
Attributes
Value type ???
Valid range ???
Default value ???
Dependencies
Access not accessible
Status mandatory
Format
sgsnGb-BVC-TableEntry ::=
SEQUENCE{
sgsnGb-BVC-RowStatus GSN-RowStatus,
sgsnGb-BVC-BVCI INTEGER,
sgsnGb-BVC-BVCI-Type INTEGER,
sgsnGb-BVC-NSVCI INTEGER,
sgsnNGb-BVC-SigBVCI INTEGER,
}
Example
References
ISSUE 1 REVISION 2sgsnGb-BVC-RowStatus
�MOTOROLA LTD. 2000GPRS01: GPRS Architecture
FOR TRAINING PURPOSES ONLY
6–108
sgsnGb-BVC-RowStatus
Description
This parameter indicates the status of a table row.
Attributes
Value type
Valid range
Default value undefined
Dependencies
Access read - write
Status mandatory
Format
Example
References
ISSUE 1 REVISION 2 sgsnGb-BVC-BVCI
�MOTOROLA LTD. 2000 GPRS01: GPRS Architecture
FOR TRAINING PURPOSES ONLY
6–109
sgsnGb-BVC-BVCI
Description
This parameter is the identifier of the BVC, unique within the SGSN. It is used by Gb tocommunicate with BSS over the end-to-end BVCs.
Attributes
Value type integer
Valid range 1 to 65535 (ffff hex)
Default value
Dependencies
Access read only
Status mandatory
Format
Example
References
ISSUE 1 REVISION 2sgsnGb-BVC-BVCI-Type
�MOTOROLA LTD. 2000GPRS01: GPRS Architecture
FOR TRAINING PURPOSES ONLY
6–110
sgsnGb-BVC-BVCI-Type
Description
This parameter identifies the type of BVC : PTP, PTM OR Sig (Signalling).
Attributes
Value type integer
Valid range 0 Sig1 PTP2 PTM
Default value 1
Dependencies
Access read only
Status mandatory
Format
Example
References
ISSUE 1 REVISION 2 sgsnGb-BVC-NSVCI
�MOTOROLA LTD. 2000 GPRS01: GPRS Architecture
FOR TRAINING PURPOSES ONLY
6–111
sgsnGb-BVC-NSVCI
Description
This parameter identifies the NS-VC that serves this BVC. It is used by Gb to maintainthe BVCI to NS-VCI mapping. The parameter must be defined in sgsnGb-NSVC-Table .
Attributes
Value type integer
Valid range 1 to 65535 (ffff hex)
Default value 0
Dependencies
Access read only
Status mandatory
Format
Example
References
ISSUE 1 REVISION 2sgsnGb-BVC-SigBVCI
�MOTOROLA LTD. 2000GPRS01: GPRS Architecture
FOR TRAINING PURPOSES ONLY
6–112
sgsnGb-BVC-SigBVCI
Description
This parameter identifies the signalling BVC associated with the BVC/NS-VC pair (whenthe BVC is of the type PTP or PTM) being defined by the table row. It is used by Gb tocommunicate with BSS when the data BVC fails.
When the BVC in the BVC/NS-VC pair is a signalling BVC itself, this field will have avalue of 0. If the value of this field is not 0, it should already have been previouslydefined in the BVC table. It should be noted, that while 0 is not a valid BVCI value, it isallowed for this field.
Attributes
Value type integer
Valid range 0 to 65535 (ffff hex)
Default value
Dependencies sgsnGb-BVC-BVCI
Access read only
Status mandatory
Format
Example
References
ISSUE 1 REVISION 2 sgsnBSSGP-T1
�MOTOROLA LTD. 2000 GPRS01: GPRS Architecture
FOR TRAINING PURPOSES ONLY
6–113
sgsnBSSGP-T1
Description
This parameter is the timer, in seconds, that guards the blocking and unblockingprocedures.
The block or unblock is sent every sgsnBssgpT1 seconds until the peer acknowledges orthe number of retries (sgsnBssgpBvcBlockRetries orsgsnBssgpBvcUnblockRetries ) is completed.
Attributes
Value type integer
Valid range 1 to 30
Default value 3
Dependencies
Access read - write
Status mandatory
Format
Example
References
ISSUE 1 REVISION 2sgsnBSSGP–T2
�MOTOROLA LTD. 2000GPRS01: GPRS Architecture
FOR TRAINING PURPOSES ONLY
6–114
sgsnBSSGP–T2
Description
This parameter is the timer, in seconds, that guards the reset procedure.
The reset is sent every sgsnBssgpT2 seconds until the peer acknowledges or thenumber of retries (sgsnBssgpBvcResetRetries ) is completed.
Attributes
Value type integer
Valid range 1 to 1000
Default value 60
Dependencies
Access read - write
Status mandatory
Format
Example
References
ISSUE 1 REVISION 2 sgsnBSSGP–BVC-BlockRetries
�MOTOROLA LTD. 2000 GPRS01: GPRS Architecture
FOR TRAINING PURPOSES ONLY
6–115
sgsnBSSGP–BVC-BlockRetries
Description
This parameter indicates the number of attempts to retry a BVC-BLOCK.
Attributes
Value type integer
Valid range 1 to 30
Default value 3
Dependencies
Access read - write
Status mandatory
Format
Example
References
ISSUE 1 REVISION 2sgsnBSSGP-BVC-UnblockRetries
�MOTOROLA LTD. 2000GPRS01: GPRS Architecture
FOR TRAINING PURPOSES ONLY
6–116
sgsnBSSGP-BVC-UnblockRetries
Description
This parameter indicates the number of attempts to retry a BVC-UNBLOCK.
Attributes
Value type integer
Valid range 1 to 30
Default value 3
Dependencies
Access read - write
Status mandatory
Format
Example
References
ISSUE 1 REVISION 2 sgsnBSSGP-BVC-ResetRetries
�MOTOROLA LTD. 2000 GPRS01: GPRS Architecture
FOR TRAINING PURPOSES ONLY
6–117
sgsnBSSGP-BVC-ResetRetries
Description
This parameter indicates the number of attempts to retry a BVC-RESET.
Dependencies
Access read - write
Status mandatory
Format
Example
Attributes
Value type integer
Valid range 1 to 30
Default value 3
References
ISSUE 1 REVISION 2sgsnGb-Cell-Table
�MOTOROLA LTD. 2000GPRS01: GPRS Architecture
FOR TRAINING PURPOSES ONLY
6–118
sgsnGb-Cell-Table
Description
This table provides the Cell to BVCI mappings that are defined for this SGSN.
Row Creation: For the successful creation of a row in this table, the referred BVCImust have already been defined in the sgsnGb-BVC-Table .
Row Deletion: There is no restriction on row deletion.
Row Update Currently, the software does not have provision to update individualentry values for a row after it has been created. Updates can onlybe achieved by deleting the existing row and then inserting a newrow containing the new values, through separate managementrequests.
Attributes
Value type
Valid range
Default value
Dependencies
Access not accessible
Status mandatory
Format
Example
References
ISSUE 1 REVISION 2 sgsnGb-Cell-BVC-TableEntry
�MOTOROLA LTD. 2000 GPRS01: GPRS Architecture
FOR TRAINING PURPOSES ONLY
6–119
sgsnGb-Cell-BVC-TableEntry
Description
Each entry defines one <CGI, PTP–BVCI> pair.
Attributes
Value type
Valid range
Default value
Dependencies
Access not accessible
Status mandatory
Format
sgsnRaiNseiEntry ::=
SEQUENCE{
sgsnGb-Cell-BVCRowStatus GSN-RowStatus,
sgsnGb-Cell-BVCMCC Display String,
sgsnGb-Cell-BVCMNC Display String,
sgsnGb-Cell-BVCLAC INTEGER,
sgsnGb-Cell-BVC-CI INTEGER,
sgsnGb-Cell-BVC-PTP-BVCI INTEGER
}
Example
References
ISSUE 1 REVISION 2sgsnGb-Cell-BVCRowStatus
�MOTOROLA LTD. 2000GPRS01: GPRS Architecture
FOR TRAINING PURPOSES ONLY
6–120
sgsnGb-Cell-BVCRowStatus
Description
This parameter indicates the status of a table row.
Attributes
Value type
Valid range
Default value undefined
Dependencies
Access read - write
Status mandatory
Format
Example
References
ISSUE 1 REVISION 2 sgsnGb-Cell-BVC-MCC
�MOTOROLA LTD. 2000 GPRS01: GPRS Architecture
FOR TRAINING PURPOSES ONLY
6–121
sgsnGb-Cell-BVC-MCC
Description
This parameter identifies the Mobile Country Code.
Attributes
Value type display string
Valid range
Default value
Dependencies
Access read only
Status mandatory
Format
3 decimal digits in ASCII format, according to CCITT Rec E.212.
Example
References
CCITT Rec E.212
ISSUE 1 REVISION 2sgsnGb-Cell-BVCMNC
�MOTOROLA LTD. 2000GPRS01: GPRS Architecture
FOR TRAINING PURPOSES ONLY
6–122
sgsnGb-Cell-BVCMNC
Description
This parameter identifies the Mobile Network Code.
Attributes
Value type display string
Valid range
Default value
Dependencies
Access read only
Status mandatory
Format
2 decimal digits in ASCII format, according to CCITT Rec E.212.
Example
References
CCITT Rec E.212
ISSUE 1 REVISION 2 sgsnGb-Cell-BVCLAC
�MOTOROLA LTD. 2000 GPRS01: GPRS Architecture
FOR TRAINING PURPOSES ONLY
6–123
sgsnGb-Cell-BVCLAC
Description
This parameter identifies the Location Area Code.
Attributes
Value type integer
Valid range 0 to 65535
Default value
Dependencies
Access read only
Status mandatory
Format
2 bytes integer, according to TS GSM 04.08
Example
References
TS GSM 04.08
ISSUE 1 REVISION 2sgsnGb-Cell-BVC-CI
�MOTOROLA LTD. 2000GPRS01: GPRS Architecture
FOR TRAINING PURPOSES ONLY
6–124
sgsnGb-Cell-BVC-CI
Description
This parameter identifies the cell identity.
Attributes
Value type integer
Valid range 0 to 65535
Default value
Dependencies
Access read only
Status mandatory
Format
2 bytes integer, according to TS GSM 04.08
Example
References
TS GSM 04.08
ISSUE 1 REVISION 2 sgsnGb-Cell-BVC-PTP-BVCI
�MOTOROLA LTD. 2000 GPRS01: GPRS Architecture
FOR TRAINING PURPOSES ONLY
6–125
sgsnGb-Cell-BVC-PTP-BVCI
Description
This parameter is the identifier of the PTP BVCI serving this cell. It is used by Gb tomaintain the CGI to PTP BVCI mappings. It must be defined in sgsnGb-BVC-Table .
Attributes
Value type integer
Valid range 0 to 65535
Default value
Dependencies sgsnGb-BVC-BVCI
Access read only
Status mandatory
Format
Example
References
TS GSM 04.08
ISSUE 1 REVISION 2sgsnSigPlaneInfoTable
�MOTOROLA LTD. 2000GPRS01: GPRS Architecture
FOR TRAINING PURPOSES ONLY
6–126
sgsnSigPlaneInfoTable
Description
This table provides Signalling Plane Control Information for this SGSN. It is used by theSGSN to obtain the following mappings: CGI > RAI, CGI > SIG BVCI and RAI > SIGBVCI (PCU).
Row Creation: For succesful row creation, the referred BVCI must have alreadybeen defined in the sgsnGb-BVC-Table .
Row Deletion: No restrictions.
Row Update The software does not currently have the provision to updateindividual entry values after a row has been created. Updates canonly be achieved by deleting the existing row and then inserting anew row with the new values.
Attributes
Value type
Valid range
Default value
Dependencies
Access not accessible
Status mandatory
Format
Example
References
ISSUE 1 REVISION 2 sgsnSigPlaneInfoTableEntry
�MOTOROLA LTD. 2000 GPRS01: GPRS Architecture
FOR TRAINING PURPOSES ONLY
6–127
sgsnSigPlaneInfoTableEntry
Description
This parameter defines the entry structure for the sgsnSigPlaneInfoTable .
Attributes
Value type
Valid range
Default value
Dependencies
Access not accessible
Status mandatory
Format
sgsnSigPlaneInfoTableEntry ::=
SEQUENCE{
sgsnSigPlaneInfotRowStatus GSN-RowStatus,
sgsnSigPlaneInfo-MCC DISPLAYSTRING,
sgsnSigPlaneInfo-MNC DISPLAYSTRING,
sgsnSigPlaneInfo-LAC INTEGER,
sgsnSigPlaneInfo-CI INTEGER,
sgsnSigPlaneInfo-RAC
sgsnSigPlaneInfoSIG-BVCI
INTEGER,
INTEGER
}
Example
References
ISSUE 1 REVISION 2sgsnSigPlaneInfoRowStatus
�MOTOROLA LTD. 2000GPRS01: GPRS Architecture
FOR TRAINING PURPOSES ONLY
6–128
sgsnSigPlaneInfoRowStatus
Description
This parameter indicates the status of a table row.
Attributes
Value type
Valid range
Default value undefined
Dependencies
Access read - write
Status mandatory
Format
Example
References
ISSUE 1 REVISION 2 sgsnSigPlaneInfo-MCC
�MOTOROLA LTD. 2000 GPRS01: GPRS Architecture
FOR TRAINING PURPOSES ONLY
6–129
sgsnSigPlaneInfo-MCC
Description
This parameter identifies the Mobile Country Code.
Attributes
Value type integer
Valid range
Default value
Dependencies
Access read only
Status mandatory
Format
2 digits decimal in ASCII format, according to CCITT Rec E.212
Example
References
CCITT Rec E.212
ISSUE 1 REVISION 2sgsnSigPlaneInfo-MNC
�MOTOROLA LTD. 2000GPRS01: GPRS Architecture
FOR TRAINING PURPOSES ONLY
6–130
sgsnSigPlaneInfo-MNC
Description
This parameter identifies the Mobile Network Code.
Attributes
Value type
Valid range
Default value
Dependencies
Access read only
Status mandatory
Format
2 digits decimal in ASCII format, according to CCITT Rec E.212
Example
References
CCITT Rec E.212
ISSUE 1 REVISION 2 sgsnSigPlaneInfo-LAC
�MOTOROLA LTD. 2000 GPRS01: GPRS Architecture
FOR TRAINING PURPOSES ONLY
6–131
sgsnSigPlaneInfo-LAC
Description
This parameter identifies the Location Area Code.
Attributes
Value type integer
Valid range 0 to 65535
Default value
Dependencies
Access read only
Status mandatory
Format
2 digits decimal in ASCII format, according to TS GSM 04.08.
Example
References
TS GSM 04.08
ISSUE 1 REVISION 2sgsnSigPlaneInfo-CI
�MOTOROLA LTD. 2000GPRS01: GPRS Architecture
FOR TRAINING PURPOSES ONLY
6–132
sgsnSigPlaneInfo-CI
Description
This parameter identifies the Cell Identity.
Attributes
Value type integer
Valid range 0 to 65535
Default value
Dependencies
Access read only
Status mandatory
Format
2 bytes integer, according to TS GSM 04.08
Example
References
TS GSM 04.08
ISSUE 1 REVISION 2 sgsnSigPlaneInfo-RAC
�MOTOROLA LTD. 2000 GPRS01: GPRS Architecture
FOR TRAINING PURPOSES ONLY
6–133
sgsnSigPlaneInfo-RAC
Description
This parameter identifies the Routing Area Code, part of a Global identifier of a RoutingArea. RAI is defined as MCC + MNV + LAC + RAC, since the MCC, MNC and LAC arepreviously defined, the only remaining requirement is RAC, to form the RAI.
Attributes
Value type integer
Valid range 0 to 255
Default value
Dependencies
Access read only
Status mandatory
Format
1 bytes integer
Example
References
ISSUE 1 REVISION 2sgsnSigPlaneInfoSIG-BVCI
�MOTOROLA LTD. 2000GPRS01: GPRS Architecture
FOR TRAINING PURPOSES ONLY
6–134
sgsnSigPlaneInfoSIG-BVCI
Description
This parameter identifies the Signalling BVCI of a PCU and must be defined insgsnGb–BVC-Table .
Attributes
Value type integer
Valid range 1 to 65535
Default value
Dependencies
Access read only
Status mandatory
Format
1 bytes integer
Example
References
�MOTOROLA LTD. 2000 GPRS01: GPRS Architecture
FOR TRAINING PURPOSES ONLY
i
Chapter 7
SGSN Statistics Attributes
ISSUE 1 REVISION 2 Introduction to SGSN statistics
�MOTOROLA LTD. 2000 GPRS01: GPRS Architecture
FOR TRAINING PURPOSES ONLY
7–1
Introduction to SGSN statistics
Purpose of thischapter
This chapter describes statistical measurements generated by the SGSN element of theGSN, in response to monitored network and system events.
How this chapteris structured
This chapters contains SGSN statistics information, using the following structure topresent that information:
� An introduction to the chapter and the chapter structure.
� Details of the MIB structure identifying the available SGSN objects.
� Attributes tables detailing the statistics attributes available for each SGSN object.
� Ladder diagrams describing when the statistics are generated (pegged).
� Traffic direction diagrams indicating the statistics applicable to uplink anddownlink traffic.
� Data sheets containing the attribute information of the individual statistics identifiedin the attributes tables.
This information may be structured differently for training purposes
NOTE
SGSN OIDstructure
The following illustration identifies the SGSN OID structure, which forms part of theoverall OID structure.
ISSUE 1 REVISION 2Introduction to SGSN statistics
�MOTOROLA LTD. 2000GPRS01: GPRS Architecture
FOR TRAINING PURPOSES ONLY
7–2
(1) System
(2) OAMP
(3) HA
(4) OP
(5) Gb
(6) Gn
(7) Sig
(8) Meter
(9) Perf
(10) SW
mot-gprs-sgsm
(1) diag
(2) action
(1) bssgp
(2) NS
(1) SM
(2) SNDCP
(3) LLC
(1) GTP
(2) GMM
Figure 7-1 SGSN OID structure
Attributes Tables
Details of the attributes available for each performance management object can be foundin the following tables:
ISSUE 1 REVISION 2 Introduction to SGSN statistics
�MOTOROLA LTD. 2000 GPRS01: GPRS Architecture
FOR TRAINING PURPOSES ONLY
7–3
Sig GTP Table 7-1
GTP_Gn Table 7-2
SNDCP Table 7-3
LLC Table 7-4
BSSGP Table 7-5
NS Table 7-6
FR NO TAG
L3MM Table 7-7
Misc Table 7-8
Ladder diagrams
The following performance management ladder diagrams are available:
Figure 7-2 Signalling GTP Session Activation statistics
Figure 7-3 Signalling GTP Protocol Error statistics
Figure 7-9 L3MM Attach statistics
Figure 7-10 L3MM Detach statistics
Figure 7-11 L3MM Session Activation statistics
Figure 7-12 L3MM Deactivation statistics
Figure 7-13 L3MM RA Update statistics
Traffic directiondiagrams
The following performance management traffic direction diagrams are available:
Figure 2-4 GTP_Gn protocol layer
Figure 2-5 SNDCP protocol layer
Figure 2-6 LLC protocol layer
Figure 2-7 BSSGP protocol layer
Figure 2-8 NS protocol layer
ISSUE 1 REVISION 2Signalling GTP statistics tables and diagrams
�MOTOROLA LTD. 2000GPRS01: GPRS Architecture
FOR TRAINING PURPOSES ONLY
7–4
Signalling GTP statistics tables and diagrams
Introduction tosignalling GTPtables anddiagrams
The information in this section is an aid to understanding the statistics function of aparticular SGSN object.
Table 7-1 identifies the statistics attributes available for the signalling GTP interface.
The following diagrams are used to explain when the statistics are pegged:
Figure 7-2 Signalling GTP Session Activation.
Figure 7-3 Signalling GTP Protocol Error.
Signallinginterface overGTP statistics
The following table details the statistics attributes available for sgsn-perf-gtp-sig :
Table 7-1 SGSN signalling GTP statistics attributes
OIDnumber
attribute
1 sgsnNumSuccessSessionActivationRcvd
2 sgsnNumUnsuccessSessionActivationRcvd
3 sgsnNumSessionActivationSent
4 sgsnNumProtocolErrorTooShort
5 sgsnNumProtocolErrorWrongHeader
6 sgsnNumProtocolErrorUnexpectedMsg
ISSUE 1 REVISION 2 Signalling GTP statistics tables and diagrams
�MOTOROLA LTD. 2000 GPRS01: GPRS Architecture
FOR TRAINING PURPOSES ONLY
7–5
Signalling GTPSessionActivationstatistics
The following is a ladder diagram detailing a Signalling GTP Session Activation Sent froma SGSN to a GGSN, and the expected responses. It also indicates the statistics peggedfor the Request and the responses.
sgsnNumSessionActivationSent
sgsnNumSuccessSessionActivationRcvd
sgsnNumUnsuccessSessionActivationRcvd
SGSN GGSN
PDP CONTEXT REQUEST
PDP CONTEXT ACCEPT
OR
PDP CONTEXT REJECT
Figure 7-2 Signalling GTP Session Activation
ISSUE 1 REVISION 2Signalling GTP statistics tables and diagrams
�MOTOROLA LTD. 2000GPRS01: GPRS Architecture
FOR TRAINING PURPOSES ONLY
7–6
Signalling GTPProtocol Errorstatistics
The following is a ladder diagram detailing a Signalling GTP Protocol Error statisticspegged as a result of incorrect signalling information received from the GGSN.
sgsnNumProtocolErrorTooShort
sgsnNumProtocolErrorWrongHeader
sgsnNumProtocolErrorUnexpectedMsg
SGSN GGSN
BAD SIGNALLING PDU
BAD SIGNALLING PDU
SIGNALLING PDU
Figure 7-3 Signalling GTP Protocol Error
ISSUE 1 REVISION 2 GTP_Gn statistics tables and diagrams
�MOTOROLA LTD. 2000 GPRS01: GPRS Architecture
FOR TRAINING PURPOSES ONLY
7–7
GTP_Gn statistics tables and diagrams
Introduction toGTP_Gn tablesand diagrams
The information in this section is an aid to understanding the statistics function of aparticular SGSN object.
Table 7-2 identifies the statistics attributes available for the GTP_Gn interface.
The following diagram is used to explain when the statistics are pegged:
Figure 7-4 GTP protocol layer.
Gn interfacestatistics
The following table details the statistics attributes available for sgsn-perf-gtp-gn :
Table 7-2 SGSN GTP_Gn interface statistics attributes
OIDnumber
attribute
1 sgsnNumCurrentGgsnConnections
2 sgsnNumGtpDataPacketSentToGGSN
3 sgsnNumGtpDatabytesSentToGGSN
4 sgsnNumGtpDataPacketsRcvdFromGGSN
5 sgsnNumGtpDataBytesRcvdFromGGSN
6 sgsnNumGtpDownLinkDataPacketsSent
7 sgsnNumGtpDownLinkDataBytesSent
8 sgsnNumGtpUpLinkDataPacketsRcvd
9 sgsnNumGtpUpLinkDataBytesRcvd
10 sgsnNumGtpUpLinkDataPacketsDropped
11 sgsnNumGtpDownLinkDataPacketsDropped
ISSUE 1 REVISION 2GTP_Gn statistics tables and diagrams
�MOTOROLA LTD. 2000GPRS01: GPRS Architecture
FOR TRAINING PURPOSES ONLY
7–8
GTP_Gn protocollayer
The following diagram details the traffic direction and statistics associated with the SGSNGTP_Gn protocol layer
SGSN
UplinkDownlinksgsnNumGtpDownLinkDataPacketsSentsgsnNumGtpDownLinkDataBytesSentsgsnNumGtpDataPacketsRcvdFromGGSNsgsnNumGtpDataBytesRcvdFromGGSNsgsnNumGtpDownLinkDataPacketsDropped
MS BSS GGSN
RLC
MAC
GSM RF
SNDCP
LLC
BSSGP
L1
L2
IP
TCP/UDP
GTP
IP
NetworkService
L1
L2
IP
TCP/UDP
GTP
NetworkService
L1 Bis
BSSGP
LLC
SNDCP
GSM RF
MAC
RLC
IP
Uplink Sent
Uplink Rcvd
Downlink Sent
Downlink Rcvd
L1 Bis
sgsnNumGtpUpLinkDataPacketsRcvdsgsnNumGtpUpLinkDataBytesRcvdsgsnNumGtpDataPacketsSentToGGSNsgsnNumGtpDataBytesSentToGGSNsgsnNumGtpUpLinkDataPacketsDropped
Figure 7-4 GTP protocol layer
ISSUE 1 REVISION 2 SNDCP statistics tables and diagrams
�MOTOROLA LTD. 2000 GPRS01: GPRS Architecture
FOR TRAINING PURPOSES ONLY
7–9
SNDCP statistics tables and diagrams
Introduction toSNDCP tablesand diagrams
The information in this section is an aid to understanding the statistics function of aparticular SGSN object.
Table 7-3 identifies the statistics attributes available for the SNDCP protocol layer.
The following diagram is used to explain when the statistics are pegged:
Figure 7-5 SNDCP protocol layer.
SNDCP statistics
The following table details the statistics attributes available for sgsn-perf-sndcp :
Table 7-3 SGSN SNDCP statistics attributes
OIDnumber
attribute
1 sgsnNumSndcpUpLinkDataPacketsSent
2 sgsnNumSndcpUpLinkDataBytesSent
3 sgsnNumSndcpDownLinkDataPacketsRcvd
4 sgsnNumsndcpDownLinkDataBytesRcvd
5 sgsnNumSndcpDownLinkDataPacketsSent
6 sgsnNumSndcpDownLinkDataBytesSent
7 sgsnNumSndcpUpLinkDataPacketsRcvd
8 sgsnNumSndcpUpLinkDataBytesRcvd
9 sgsnNumSndcpUpLinkDataPacketsDropped
10 sgsnNumSndcpDownLinkDataPacketsDropped
ISSUE 1 REVISION 2SNDCP statistics tables and diagrams
�MOTOROLA LTD. 2000GPRS01: GPRS Architecture
FOR TRAINING PURPOSES ONLY
7–10
SNDCP protocollayer
The following diagram details the traffic direction and statistics associated with the SGSNSNDCP protocol layer
SGSN
UplinkDownlinksgsnNumSndcpDownLinkDataPacketsSentsgsnNumSndcpDownLinkDataBytesSentsgsnNumSndcpDownLinkDataPacketsRcvdsgsnNumSndcpDownLinkDataBytesRcvdsgsnNumSndcpDownLinkDataPacketsDropped
MS BSS GGSN
RLC
MAC
GSM RF
SNDCP
LLC
BSSGP
L1
L2
IP
TCP/UDP
GTP
IP
NetworkService
L1
L2
IP
TCP/UDP
GTP
L1 Bis
BSSGP
LLC
SNDCP
GSM RF
MAC
RLC
IP
Uplink Sent
Uplink Rcvd
Downlink Sent
Downlink Rcvd
L1 Bis
sgsnNumSndcpUpLinkDataPacketsRcvdsgsnNumSndcpUpLinkDataBytesRcvdsgsnNumSndcpUpLinkDataPacketsSentsgsnNumSndcpUpLinkDataBytesSentsgsnNumSndcpUpLinkDataPacketsDropped
NetworkService
Figure 7-5 SNDCP protocol layer
ISSUE 1 REVISION 2 LLC statistics tables and diagrams
�MOTOROLA LTD. 2000 GPRS01: GPRS Architecture
FOR TRAINING PURPOSES ONLY
7–11
LLC statistics tables and diagrams
Introduction toLLC tables anddiagrams
The information in this section is an aid to understanding the statistics function of aparticular SGSN object.
Table 7-4 identifies the statistics attributes available for the LLC protocol layer.
The following diagram is used to explain when the statistics are pegged:
Figure 7-6 LLC protocol layer.
LLC statistics
The following table details the statistics attributes available for sgsn-perf-llc :
Table 7-4 SGSN LLC statistics attributes
OIDnumber
attribute
1 sgsnNumLlcDownLinkDataPacketsSent
2 sgsnNumLlcDownLinkDataBytesSent
3 sgsnNumLlcUpLinkDataPacketsRcvd
4 sgsnNumLlcUpLinkDataBytesRcvd
5 sgsnNumLlcDownLinkSignalPacketsSent
6 sgsnNumLlcDownLinkSignalBytesSent
7 sgsnNumLlcUpLinkSignalPacketsRcvd
8 sgsnNumLlcUpLinkSignalBytesRcvd
9 sgsnNumLlcUpLinkDataPacketsSent
10 sgsnNumLlcUpLinkDataBytesSent
11 sgsnNumLlcDownLinkDataPacketsRcvd
12 sgsnNumLlcDownLinkDataBytesRcvd
13 sgsnNumLlcUpLinkSignalPacketsSent
14 sgsnNumLlcUpLinkSignalBytesSent
15 sgsnNumLlcDownLinkSignalPacketsRcvd
16 sgsnNumLlcDownLinkSignalBytesRcvd
17 sgsnNumLlcUpLinkDataPacketsDropped
18 sgsnNumLlcDownLinkDataPacketsDropped
19 sgsnNumLlcUpLinkSignalPacketsDropped
20 sgsnNumLlcDownLinkSignalPacketsDropped
21 sgsnNumLlcPacketsResent
ISSUE 1 REVISION 2LLC statistics tables and diagrams
�MOTOROLA LTD. 2000GPRS01: GPRS Architecture
FOR TRAINING PURPOSES ONLY
7–12
LLC protocollayer
The following diagram details the traffic direction and statistics associated with the SGSNLLC protocol layer
L1 Bis
SGSN
UplinkDownlinksgsnNumLlcDownLinkDataPacketsSentsgsnNumLlcDownLinkDataBytesSent
sgsnNumLlcDownLinkDataPacketsRcvd
sgsnNumLlcDownLinkDataBytesRcvd
sgsnNumLlcDownLinkDataPacketsDropped
MS BSS GGSN
RLC
MAC
GSM RF
SNDCP
LLC
BSSGP
L1
L2
IP
TCP/UDP
GTP
IP
NetworkService
L1
L2
IP
TCP/UDP
GTP
NetworkService
L1 Bis
BSSGP
LLC
SNDCP
GSM RF
MAC
RLC
IP
Uplink Sent
Uplink Rcvd
Downlink Sent
Downlink Rcvd
sgsnNumLlcUpLinkDataPacketsRcvdsgsnNumLlcUpLinkDataBytesRcvd
sgsnNumLlcUpLinkDataPacketsSentsgsnNumLlcUpLinkDataBytesSent
sgsnNumLlcUpLinkDataPacketsDropped
sgsnNumLlcUpLinkSignalPacketsRcvdsgsnNumLlcUpLinkSignalBytesRcvd
sgsnNumLlcUpLinkSignalPacketsSentsgsnNumLlcUpLinkSignalBytesSent
sgsnNumLlcUpLinkSignalPacketsDropped
sgsnNumLlcDownLinkSignalPacketsSent
sgsnNumLlcDownLinkSignalBytesSent
sgsnNumLlcDownLinkSignalPacketsRcvdsgsnNumLlcDownLinkSignalBytesRcvd
sgsnNumLlcDownLinkSignalPacketsDropped
Figure 7-6 LLC protocol layer
ISSUE 1 REVISION 2 BSSGP statistics tables and diagrams
�MOTOROLA LTD. 2000 GPRS01: GPRS Architecture
FOR TRAINING PURPOSES ONLY
7–13
BSSGP statistics tables and diagrams
Introduction toBSSGP tablesand diagrams
The information in this section is an aid to understanding the statistics function of aparticular SGSN object.
Table 7-5 identifies the statistics attributes available for the BSSGP protocol layer.
The following diagram is used to explain when the statistics are pegged:
Figure 7-7 BSSGP protocol layer.
BSSGP statistics
The following table details the statistics attributes available for sgsn-perf-bssgp :
Table 7-5 SGSN BSSGP statistics attributes
OIDnumber
attribute
1 sgsnNumBssgpDownLinkDataPacketsSent
2 sgsnNumBssgDownLinkdataBytesSent
3 sgsnNumBssgpUpLinkDataPacketsRcvd
4 sgsnNumBssgpUpLinkDataBytesRcvd
5 sgsnNumBssgpUpLinkDataPacketsSent
6 sgsnNumBssgpUpLinkDataBytesSent
7 sgsnNumBssgpDownLinkDataPacketsRcvd
8 sgsnNumBssgpDownLinkDataBytesRcvd
9 sgsnNumBssgpUpLinkDataPacketsDropped
10 sgsnNumBssgpDownLinkDataPacketsDropped
ISSUE 1 REVISION 2BSSGP statistics tables and diagrams
�MOTOROLA LTD. 2000GPRS01: GPRS Architecture
FOR TRAINING PURPOSES ONLY
7–14
BSSGP protocollayer
The following diagam details the traffic direction and statistics associated with the SGSNBSSGP protocol layer
SGSN
UplinksgsnNumBssgpUpLinkDataPacketsRcvdsgsnNumBssgpUpLinkDataBytesRcvdsgsnNumBssgpUpLinkDataPacketsSentsgsnNumBssgpUpLinkDataBytesSentsgsnNumBssgpUpLinkDataPacketsDropped
DownlinksgsnNumBssgpDownLinkDataPacketsSentsgsnNumBssgpDownLinkDataBytesSentsgsnNumBssgpDownLinkDataPacketsRcvdsgsnNumBssgpDownLinkDataBytesRcvdsgsnNumBssgpDownLinkDataPacketsDropped
MS BSS GGSN
RLC
MAC
GSM RF
SNDCP
LLC
BSSGP
L1
L2
IP
TCP/UDP
GTP
IP
NetworkService
L1
L2
IP
TCP/UDP
GTP
L1 Bis
NetworkService
L1 Bis
BSSGP
LLC
SNDCP
GSM RF
MAC
RLC
IP
Uplink Sent
Uplink RcvdDownlink Sent
Downlink Rcvd
Figure 7-7 BSSGP protocol layer
ISSUE 1 REVISION 2 NS statistics tables and diagrams
�MOTOROLA LTD. 2000 GPRS01: GPRS Architecture
FOR TRAINING PURPOSES ONLY
7–15
NS statistics tables and diagrams
Introduction toNS tables anddiagrams
The information in this section is an aid to understanding the statistics function of aparticular SGSN object.
Table 7-6 identifies the statistics attributes available for the NS protocol layer.
The following diagram is used to explain when the statistics are pegged:
Figure 7-8 NS protocol layer.
NS statistics
The following table details the statistics attributes available for sgsn-perf-ns :
Table 7-6 SGSN NS statistics attributes
OIDnumber
attribute
1 sgsnNumNsDownLinkDataPacketsRcvd
2 sgsnNumNsDownLinkDataBytesRcvd
3 sgsnNumNsUpLinkDataPacketsSent
4 sgsnNumNsUpLinkDataBytesSent
5 sgsnNumNsUpLinkDataPacketsRcvd
6 sgsnNumNsUpLinkDataBytesRcvd
7 sgsnNumNsDownLinkDataPacketsSent
8 sgsnNumNsDownLinkDataBytesSent
9 sgsnNumNsUpLinkDataPacketsDropped
10 sgsnNumNsDownLinkDataPacketsDropped
ISSUE 1 REVISION 2NS statistics tables and diagrams
�MOTOROLA LTD. 2000GPRS01: GPRS Architecture
FOR TRAINING PURPOSES ONLY
7–16
NS protocol layer
The following diagram details the traffic direction and statistics associated with the SGSNNS protocol layer
SGSN
UplinksgsnNumNsUpLinkDataPacketsRcvdsgsnNumNsUpLinkDataBytesRcvdsgsnNumNsUpLinkDataPacketsSentsgsnNumNsUpLinkDataBytesSentsgsnNumNsUpLinkDataPacketsDropped
DownlinksgsnNumNsDownLinkDataPacketsSentsgsnNumNsDownLinkDataBytesSentsgsnNumNsDownLinkDataPacketsRcvdsgsnNumNsDownLinkDataBytesRcvdsgsnNumNsDownLinkDataPacketsDropped
MS BSS GGSN
RLC
MAC
GSM RF
SNDCP
LLC
BSSGP
L1
L2
IP
TCP/UDP
GTP
IP
NetworkService
L1
L2
IP
TCP/UDP
GTP
NetworkService
L1 Bis
BSSGP
LLC
SNDCP
GSM RF
MAC
RLC
IP
Uplink Sent
Uplink Rcvd
Downlink Sent
Downlink Rcvd
L1 Bis
Figure 7-8 NS protocol layer
ISSUE 1 REVISION 2 L3MM statistics tables and diagrams
�MOTOROLA LTD. 2000 GPRS01: GPRS Architecture
FOR TRAINING PURPOSES ONLY
7–17
L3MM statistics tables and diagrams
Introduction toL3MM tables anddiagrams
The information in this section is an aid to understanding the statistics function of aparticular SGSN object.
Table 7-7 identifies the statistics attributes available for the L3MM interface.
The following diagrams are used to explain when the statistics are pegged:
Figure 7-9 L3MM Attach.
Figure 7-10 L3MM Detach.
Figure 7-11 L3MM Session Activation.
Figure 7-12 L3MM Session Deactivation.
Figure 7-13 L3MM RA Update.
L3MM statistics
The following table details the statistics attributes available for sgsn-perf-l3mm :
Table 7-7 SGSN L3MM statistics attributes
OIDnumber
attribute
1 sgsnNumL3mmAttachReqRcvd
2 sgsnNumL3mmAttachAcceptSent
3 sgsnNumL3mmAttachRejectSent
4 sgsnNumL3mmDetachReqRcvd
5 sgsnNumL3mmDetachAcceptSent
6 sgsnNumL3mmSessionActivateReqRcvd
7 sgsnNumL3mmSessionActivateAcceptSent
8 sgsnNumL3mmSessionActivateRejectSent
9 sgsnNumL3SessionDeactivateReqRcvd
10 sgsnNumL3mmSessionDeactivateAcceptSent
11 sgsnNumL3mmRaUpdateReqRcvd
12 sgsnNumL3mmRaUpdateAcceptSent
13 sgsnNumL3mmRaUpdateRejectSent
14 sgsnNumL3mmMsPagingReqSent
15 sgsnNumL3mmSuccessfulPages
ISSUE 1 REVISION 2L3MM statistics tables and diagrams
�MOTOROLA LTD. 2000GPRS01: GPRS Architecture
FOR TRAINING PURPOSES ONLY
7–18
L3MM Attachstatistics
The following is a ladder diagram detailing an L3MM Attach Request from an MS to theSGSN, and the expected responses. It also indicates the statistics pegged for theRequest and the responses.
MS SGSN
ATTACH REQUEST
ATTACH ACCEPT
OR
ATTACH REJECT
sgsnNumL3mmAttachReqRcvd
sgsnNumL3mmAttachAcceptSent
sgsnNumL3mmAttachRejectSent
Figure 7-9 L3MM Attach
ISSUE 1 REVISION 2 L3MM statistics tables and diagrams
�MOTOROLA LTD. 2000 GPRS01: GPRS Architecture
FOR TRAINING PURPOSES ONLY
7–19
L3MM Detachstatistics
The following is a ladder diagram detailing an L3MM Detach Request from an MS to theSGSN, and the expected response. It also indicates the statistics pegged for theRequest and the response.
MS SGSN
DETACH REQUEST
DETACH ACCEPT
sgsnNumL3mmDetachReqRcvd
sgsnNumL3mmDetachAcceptSent
Figure 7-10 L3MM Detach
ISSUE 1 REVISION 2L3MM statistics tables and diagrams
�MOTOROLA LTD. 2000GPRS01: GPRS Architecture
FOR TRAINING PURPOSES ONLY
7–20
L3MM SessionActivationstatistics
The following is a ladder diagram detailing an L3MM Session Activation Request from anMS to the SGSN, and the expected responses. It also indicates the statistics pegged forthe Request and the responses.
MS SGSN
SESSION ACTIVATION REQUEST
SESSION ACTIVATION ACCEPT
OR
SESSION ACTIVATION REJECT
sgsnNumL3mmSessionActivateReqRcvd
sgsnNumL3mmSessionActivateAcceptSent
sgsnNumL3mmSessionActivateRejectSent
Figure 7-11 L3MM Session Activation
ISSUE 1 REVISION 2 L3MM statistics tables and diagrams
�MOTOROLA LTD. 2000 GPRS01: GPRS Architecture
FOR TRAINING PURPOSES ONLY
7–21
L3MM SessionDeactivationstatistics
The following is a ladder diagram detailing an L3MM Session Deactivation Request froman MS to the SGSN, and the expected response. It also indicates the statistics peggedfor the Request and the response.
MS SGSN
SESSION DEACTIVATION REQUEST
SESSION DEACTIVATION ACCEPT
sgsnNumL3mmSessionDeactivateReqRcvd
sgsnNumL3mmSessionDeactivateAcceptSent
Figure 7-12 L3MM Session Deactivation
ISSUE 1 REVISION 2L3MM statistics tables and diagrams
�MOTOROLA LTD. 2000GPRS01: GPRS Architecture
FOR TRAINING PURPOSES ONLY
7–22
L3MM RA Updatestatistics
The following is a ladder diagram detailing an L3MM RA Update Request from an MS tothe SGSN, and the expected responses. It also indicates the statistics pegged for theRequest and the responses.
MS SGSN
RA UPDATE REQUEST
RA UPDATE ACCEPT
OR
RA UPDATE REJECT
sgsnNumL3mmRAUpdateReqRcvd
sgsnNumL3mmRAUpdateAcceptSent
sgsnNumL3mmRAUpdateRejectSent
Figure 7-13 L3MM RA Update
ISSUE 1 REVISION 2 Miscellaneous statistics tables and diagrams
�MOTOROLA LTD. 2000 GPRS01: GPRS Architecture
FOR TRAINING PURPOSES ONLY
7–23
Miscellaneous statistics tables and diagrams
Introduction tomiscellaneoustables anddiagrams
The information in this section is an aid to understanding the statistics function of aparticular SGSN object.
Table 7-8 identifies the miscellaneous statistics attributes available.
The following diagram is used to explain when the statistics are pegged:
Miscellaneousstatistics
The following table details the statistics attributes available for sgsn-perf-misc :
Table 7-8 SGSN miscellaneous statistics attributes
OIDnumber
attribute
1 sgsnCurrentNumGprsAttachedMS
2 sgsnCurrentNumActivePdpSession
3 sgsnNumCells
ISSUE 1 REVISION 2sgsnNumSuccessSessionActivationRcvd
�MOTOROLA LTD. 2000GPRS01: GPRS Architecture
FOR TRAINING PURPOSES ONLY
7–24
sgsnNumSuccessSessionActivationRcvd
Description
This signalling statistic indicates the total number of Successful Session ActivationRequests received.
Pegging
The statistic is pegged when the SGSN receives a PDP Context Accept from the GGSN.
Analysis
This statistic indicates the number of session management contexts activated within theGSN.
Reference
None
Usage
Network Planning
Congestion Identification
Quality of Service Issues
Basis
GTP
Statistic
Statistic Type
Counter
Statistic Data
Integer ( 0 - 4,294,967,295 )
ISSUE 1 REVISION 2 sgsnNumUnsuccessSessionActivationRcvd
�MOTOROLA LTD. 2000 GPRS01: GPRS Architecture
FOR TRAINING PURPOSES ONLY
7–25
sgsnNumUnsuccessSessionActivationRcvd
Description
This signalling statistic indicates the total number of Unsuccessful Session ActivationRequests received.
Pegging
The statistic is pegged when the SGSN receives a PDP Context Reject from the GGSN.
Analysis
Reference
Usage
Network Planning
Congestion Identification
Quality of Service Issues
Basis
GTP
Statistic
Statistic Type
Counter
Statistic Data
Integer ( 0 - 4,294,967,295 )
ISSUE 1 REVISION 2sgsnNumSessionActivationSent
�MOTOROLA LTD. 2000GPRS01: GPRS Architecture
FOR TRAINING PURPOSES ONLY
7–26
sgsnNumSessionActivationSent
Description
This signalling statistic indicates the total number of Session Activation Requests sent.
Pegging
The statistic is pegged when the SGSN sends a PDP Context Request to the GGSN.
Analysis
Reference
Usage
Network Planning
Congestion Identification
Quality of Service issues
Basis
GTP
Statistic
Statistic Type
Counter
Statistic Data
Integer ( 0 - 4,294,967,295 )
ISSUE 1 REVISION 2 sgsnNumProtocolError-TooShort
�MOTOROLA LTD. 2000 GPRS01: GPRS Architecture
FOR TRAINING PURPOSES ONLY
7–27
sgsnNumProtocolError-TooShort
Description
This signalling statistic indicates the total number of protocol errors - message too short.
Pegging
The statistic is pegged when the SGSN receives a Bad Signalling PDU from the GGSN,such as a PDP Context Accept that is too short.
Analysis
Reference
Usage
Protocol Utilization
Fault Finding
Basis
GTP
Statistic
Statistic Type
Counter
Statistic Data
Integer ( 0 - 4,294,967,295 )
ISSUE 1 REVISION 2sgsnNumProtocolError-WrongHeader
�MOTOROLA LTD. 2000GPRS01: GPRS Architecture
FOR TRAINING PURPOSES ONLY
7–28
sgsnNumProtocolError-WrongHeader
Description
This signalling statistic indicates the total number of protocol errors - unknown orerroneous header.
Pegging
The statistic is pegged when the SGSN receives a Bad Signalling PDU from the GGSN,such PDP Context Accept with the wrong header.
Analysis
Reference
Usage
Protocol Utilization
Fault Finding
Basis
GTP
Statistic
Statistic Type
Counter
Statistic Data
Integer ( 0 - 4,294,967,295 )
ISSUE 1 REVISION 2 sgsnNumProtocolError-UnexpectedMsg
�MOTOROLA LTD. 2000 GPRS01: GPRS Architecture
FOR TRAINING PURPOSES ONLY
7–29
sgsnNumProtocolError-UnexpectedMsg
Description
This signalling statistic indicates the total number of protocol errors - unexpectedmessage.
Pegging
The statistic is pegged when the SGSN receives a signalling PDU from the GGSN thatwas not expected. For example, if the SGSN receives a PDP Context Accept withouthaving first sent a PDP Context Request.
Analysis
Reference
Usage
Protocol Utilization
Fault Finding
Basis
GTP
Statistic
Statistic Type
Counter
Statistic Data
Integer ( 0 - 4,294,967,295 )
ISSUE 1 REVISION 2sgsnNumCurrentGgsn-Connections
�MOTOROLA LTD. 2000GPRS01: GPRS Architecture
FOR TRAINING PURPOSES ONLY
7–30
sgsnNumCurrentGgsn-Connections
Description
This statistic indicates the current number of GGSN connections.
Pegging
The statistic is pegged when a new GGSN connection is made at the SGSN.
Analysis
The statistic can be used to monitor the connection load on an SGSN.
Reference
Usage
Network Planning
Congestion Identification
Basis
GTP Gn
Statistic
Statistic Type
Guage
Statistic Data
Integer ( 0 - 4,294,967,295 )
ISSUE 1 REVISION 2 sgsnNumGtpDataPacketsSentToGGSN
�MOTOROLA LTD. 2000 GPRS01: GPRS Architecture
FOR TRAINING PURPOSES ONLY
7–31
sgsnNumGtpDataPacketsSentToGGSN
Description
This statistic indicates the total number of GTP data packets sent to the GGSN.
Pegging
The statistic is pegged each time the GTP protocol layer sends a data packet to theGGSN.
Analysis
The statistic can be used in conjunction with sgsnNumGtpUpLinkDataPacketsRcvd toshow the SGSN data packet throughput in the uplink direction across the GTP protocollayer.
Reference
Usage
Network Planning
Congestion Identification
Loss Rates
Fault Finding
Basis
GTP Gn
Statistic
Statistic Type
Counter
Statistic Data
Integer ( 0 - 4,294,967,295 )
ISSUE 1 REVISION 2sgsnNumGtpDataBytesSentToGGSN
�MOTOROLA LTD. 2000GPRS01: GPRS Architecture
FOR TRAINING PURPOSES ONLY
7–32
sgsnNumGtpDataBytesSentToGGSN
Description
This statistic indicates the total number of GTP data bytes (including protocol headers)sent to the GGSN.
Pegging
The statistic is pegged each time the GTP protocol layer sends a data byte to the GGSN.
Analysis
The statistic can be used in conjunction with sgsnNumGtpUpLinkDataBytesRcvd toshow the SGSN data byte throughput in the uplink direction across the GTP protocollayer.
Reference
Usage
Network Planning
Congestion Identification
Loss Rates
Fault Finding
Basis
GTP Gn
Statistic
Statistic Type
Counter
Statistic Data
Integer ( 0 - 4,294,967,295 )
ISSUE 1 REVISION 2 sgsnNumGtpDataPacketsRcvdFromGGSN
�MOTOROLA LTD. 2000 GPRS01: GPRS Architecture
FOR TRAINING PURPOSES ONLY
7–33
sgsnNumGtpDataPacketsRcvdFromGGSN
Description
This statistic indicates the total number of GTP data packets received from the GGSN.
Pegging
The statistic is pegged each time the GTP protocol layer receives a data packet from theGGSN.
Analysis
The statistic can be used in conjunction with sgsnNumGtpDownLinkDataPacketsRcvdto show the SGSN data packet throughput in the downlink direction across the GTPprotocol layer.
Reference
Usage
Network Planning
Congestion Identification
Loss Rates
Fault Finding
Basis
GTP Gn
Statistic
Statistic Type
Counter
Statistic Data
Integer ( 0 - 4,294,967,295 )
ISSUE 1 REVISION 2sgsnNumGtpDataBytesRcvdFromGGSN
�MOTOROLA LTD. 2000GPRS01: GPRS Architecture
FOR TRAINING PURPOSES ONLY
7–34
sgsnNumGtpDataBytesRcvdFromGGSN
Description
This statistic indicates the total number of GTP data bytes (including protocol headers)received from the GGSN.
Pegging
The statistic is pegged each time the GTP protocol layer receives a data byte from theGGSN.
Analysis
The statistic can be used in conjunction with sgsnNumGtpDownLinkDataBytesRcvd toshow the SGSN data byte throughput in the downlink direction across the GTP protocollayer.
Reference
Usage
Network Planning
Congestion Identification
Loss Rates
Fault Finding
Basis
GTP Gn
Statistic
Statistic Type
Counter
Statistic Data
Integer ( 0 - 4,294,967,295 )
ISSUE 1 REVISION 2 sgsnNumGtpDownLinkDataPacketsSent
�MOTOROLA LTD. 2000 GPRS01: GPRS Architecture
FOR TRAINING PURPOSES ONLY
7–35
sgsnNumGtpDownLinkDataPacketsSent
Description
This statistic indicates the total number of data packets sent in the downlink direction (toSNDCP protocol layer).
Pegging
The statistic is pegged each time the GTP protocol layer sends a data packet to theSNDCP protocol layer.
Analysis
The statistic can be used in conjunction with sgsnNumGtpDataPacketsRcvdFromGGSN to show the SGSN data packet throughput in the downlink direction across theGTP protocol layer.
Reference
Usage
Network Planning
Congestion Identification
Loss Rates
Fault Finding
Basis
GTP Gn
Statistic
Statistic Type
Counter
Statistic Data
Integer ( 0 - 4,294,967,295 )
ISSUE 1 REVISION 2sgsnNumGtpDownLinkDataBytesSent
�MOTOROLA LTD. 2000GPRS01: GPRS Architecture
FOR TRAINING PURPOSES ONLY
7–36
sgsnNumGtpDownLinkDataBytesSent
Description
This statistic indicates the total number of data bytes (including protocol headers) sent inthe downlink direction (to SNDCP protocol layer).
Pegging
The statistic is pegged each time the GTP protocol layer sends a data byte to theSNDCP protocol layer.
Analysis
The statistic can be used in conjunction with sgsnNumGtpDataBytesRcvdFromGGSNto show the SGSN data byte throughput in the downlink direction across the GTPprotocol layer.
Reference
Usage
Network Planning
Congestion Identification
Loss Rates
Fault Finding
Basis
GTP Gn
Statistic
Statistic Type
Counter
Statistic Data
Integer ( 0 - 4,294,967,295 )
ISSUE 1 REVISION 2 sgsnNumGtpUpLinkDataPacketsRcvd
�MOTOROLA LTD. 2000 GPRS01: GPRS Architecture
FOR TRAINING PURPOSES ONLY
7–37
sgsnNumGtpUpLinkDataPacketsRcvd
Description
This statistic indicates the total number of data packets received in the uplink direction(from SNDCP protocol layer).
Pegging
The statistic is pegged each time the GTP protocol layer receives a data packet from theSNDCP protocol layer.
Analysis
The statistic can be used in conjunction with sgsnNumGtpDataPacketsSentToGGSN toshow the SGSN data packet throughput in the uplink direction across the GTP protocollayer.
Reference
Usage
Network Planning
Congestion Identification
Loss Rates
Fault Finding
Basis
GTP Gn
Statistic
Statistic Type
Counter
Statistic Data
Integer ( 0 - 4,294,967,295 )
ISSUE 1 REVISION 2sgsnNumGtpUpLinkDataBytesRcvd
�MOTOROLA LTD. 2000GPRS01: GPRS Architecture
FOR TRAINING PURPOSES ONLY
7–38
sgsnNumGtpUpLinkDataBytesRcvd
Description
This Gn statistic indicates the total number of data bytes (including protocol headers)received in the uplink direction (from SNDCP protocol layer).
Pegging
The statistic is pegged each time the GTP protocol layer receives a data byte from theSNDCP protocol layer.
Analysis
The statistic can be used in conjunction with sgsnNumGtpDataBytesSentToGGSN toshow the SGSN data byte throughput in the uplink direction across the GTP protocollayer.
Reference
Usage
Network Planning
Congestion Identification
Loss Rates
Fault Finding
Basis
GTP Gn
Statistic
Statistic Type
Counter
Statistic Data
Integer ( 0 - 4,294,967,295 )
ISSUE 1 REVISION 2 sgsnNumGtpUpLinkDataPacketsDropped
�MOTOROLA LTD. 2000 GPRS01: GPRS Architecture
FOR TRAINING PURPOSES ONLY
7–39
sgsnNumGtpUpLinkDataPacketsDropped
Description
This statistic indicates the total number of data packets dropped in the uplink direction.
Pegging
The statistic is pegged each time the GTP protocol layer drops a data packet receivedfrom the SNDCP protocol layer.
Analysis
The statistic can be used in conjunction with GTP uplink throughput statistics to identifyuplink loss rates across the GTP protocol layer.
Reference
Usage
Loss Rates
Fault Finding
Basis
GTP Gn
Statistic
Statistic Type
Counter
Statistic Data
Integer ( 0 - 4,294,967,295 )
ISSUE 1 REVISION 2sgsnNumGtpDownLinkDataPacketsDropped
�MOTOROLA LTD. 2000GPRS01: GPRS Architecture
FOR TRAINING PURPOSES ONLY
7–40
sgsnNumGtpDownLinkDataPacketsDropped
Description
This statistic indicates the total number of data packets dropped in the downlink direction.
Pegging
The statistic is pegged each time the GTP protocol layer drops a data packet receivedfrom the GGSN.
Analysis
The statistic can be used in conjunction with GTP downlink throughput statistics toidentify downlink loss rates across the GTP protocol layer.
Reference
Usage
Loss Rates
Fault Finding
Basis
GTP Gn
Statistic
Statistic Type
Counter
Statistic Data
Integer ( 0 - 4,294,967,295 )
ISSUE 1 REVISION 2 sgsnNumSndcpUpLinkDataPacketsSent
�MOTOROLA LTD. 2000 GPRS01: GPRS Architecture
FOR TRAINING PURPOSES ONLY
7–41
sgsnNumSndcpUpLinkDataPacketsSent
Description
This statistic indicates the total number of SNDCP data packets sent to the GTP protocollayer.
Pegging
The statistic is pegged each time the SNDCP protocol layer sends a data packet to theGTP protocol layer.
Analysis
The statistic can be used in conjunction with sgsnNumSndcpUpLinkDataPacketsRcvdto show the SGSN data packet throughput in the uplink direction across the SNDCPprotocol layer.
Reference
Usage
Network Planning
Congestion Identification
Loss Rates
Fault Finding
Basis
SNDCP
Statistic
Statistic Type
Counter
Statistic Data
Integer ( 0 - 4,294,967,295 )
ISSUE 1 REVISION 2sgsnNumSndcpUpLinkDataBytesSent
�MOTOROLA LTD. 2000GPRS01: GPRS Architecture
FOR TRAINING PURPOSES ONLY
7–42
sgsnNumSndcpUpLinkDataBytesSent
Description
This statistic indicates the total number of SNDCP data bytes (including protocolheaders) sent to the GTP protocol layer.
Pegging
The statistic is pegged each time the SNDCP protocol layer sends a data byte to theGTP protocol layer.
Analysis
The statistic can be used in conjunction with sgsnNumSndcpUpLinkDataBytesRcvd toshow the SGSN data byte throughput in the uplink direction across the SNDCP protocollayer.
Reference
Usage
Network Planning
Congestion Identification
Loss Rates
Fault Finding
Basis
SNDCP
Statistic
Statistic Type
Counter
Statistic Data
Integer ( 0 - 4,294,967,295 )
ISSUE 1 REVISION 2 sgsnNumSndcpDownLinkDataPacketsRcvd
�MOTOROLA LTD. 2000 GPRS01: GPRS Architecture
FOR TRAINING PURPOSES ONLY
7–43
sgsnNumSndcpDownLinkDataPacketsRcvd
Description
This statistic indicates the total number of SNDCP data packets received from the GTPprotocol layer.
Pegging
The statistic is pegged each time the SNDCP protocol layer receives a data packet fromthe GTP protocol layer.
Analysis
The statistic can be used in conjunction with sgsnNumSndcpDownLinkDataPacketsSent to show the SGSN data packet throughput in the downlink direction across theSNDCP protocol layer.
Reference
Usage
Network Planning
Congestion Identification
Loss Rates
Fault Finding
Basis
SNDCP
Statistic
Statistic Type
Counter
Statistic Data
Integer ( 0 - 4,294,967,295 )
ISSUE 1 REVISION 2sgsnNumSndcpDownLinkDataBytesRcvd
�MOTOROLA LTD. 2000GPRS01: GPRS Architecture
FOR TRAINING PURPOSES ONLY
7–44
sgsnNumSndcpDownLinkDataBytesRcvd
Description
This statistic indicates the total number of SNDCP data bytes (including protocolheaders) received from the GTP protocol layer.
Pegging
The statistic is pegged each time the SNDCP protocol layer receives a data byte fromthe GTP protocol layer.
Analysis
The statistic can be used in conjunction with sgsnNumSndcpDownLinkDataBytesSentto show the SGSN data byte throughput in the downlink direction across the SNDCPprotocol layer.
Reference
Usage
Network Planning
Congestion Identification
Loss Rates
Fault Finding
Basis
SNDCP
Statistic
Statistic Type
Counter
Statistic Data
Integer ( 0 - 4,294,967,295 )
ISSUE 1 REVISION 2 sgsnNumSndcpDownLinkDataPacketsSent
�MOTOROLA LTD. 2000 GPRS01: GPRS Architecture
FOR TRAINING PURPOSES ONLY
7–45
sgsnNumSndcpDownLinkDataPacketsSent
Description
This statistic indicates the total number of SNDCP data packets sent to the LLC protocollayer.
Pegging
The statistic is pegged each time the SNDCP protocol layer sends a data packet to theLLC protocol layer.
Analysis
The statistic can be used in conjunction with sgsnNumSndcpDownLinkDataPacketsRcvd to show the SGSN data packet throughput in the downlink direction across theSNDCP protocol layer.
Reference
Usage
Network Planning
Congestion Identification
Loss Rates
Fault Finding
Basis
SNDCP
Statistic
Statistic Type
Counter
Statistic Data
Integer ( 0 - 4,294,967,295 )
ISSUE 1 REVISION 2sgsnNumSndcpDownLinkDataBytesSent
�MOTOROLA LTD. 2000GPRS01: GPRS Architecture
FOR TRAINING PURPOSES ONLY
7–46
sgsnNumSndcpDownLinkDataBytesSent
Description
This statistic indicates the total number of SNDCP data bytes (including protocolheaders) sent to the LLC protocol layer.
Pegging
The statistic is pegged each time the SNDCP protocol layer sends a data byte to the LLCprotocol layer.
Analysis
The statistic can be used in conjunction with sgsnNumSndcpDownLinkDataBytesRcvd to show the SGSN data packet throughput in the downlink direction across theSNDCP protocol layer.
Reference
Usage
Network Planning
Congestion Identification
Loss Rates
Fault Finding
Basis
SNDCP
Statistic
Statistic Type
Counter
Statistic Data
Integer ( 0 - 4,294,967,295 )
ISSUE 1 REVISION 2 sgsnNumSndcpUpLinkDataPacketsRcvd
�MOTOROLA LTD. 2000 GPRS01: GPRS Architecture
FOR TRAINING PURPOSES ONLY
7–47
sgsnNumSndcpUpLinkDataPacketsRcvd
Description
This statistic indicates the total number of SNDCP data packets received from the LLCprotocol layer.
Pegging
The statistic is pegged each time the SNDCP protocol layer receives a data packet fromthe LLC protocol layer.
Analysis
The statistic can be used in conjunction with sgsnNumSndcpUpLinkDataPacketsSentto show the SGSN data packet throughput in the uplink direction across the SNDCPprotocol layer.
Reference
Usage
Network Planning
Congestion Identification
Loss Rates
Fault Finding
Basis
SNDCP
Statistic
Statistic Type
Counter
Statistic Data
Integer ( 0 - 4,294,967,295 )
ISSUE 1 REVISION 2sgsnNumSndcpUpLinkDataBytesRcvd
�MOTOROLA LTD. 2000GPRS01: GPRS Architecture
FOR TRAINING PURPOSES ONLY
7–48
sgsnNumSndcpUpLinkDataBytesRcvd
Description
This statistic indicates the total number of SNDCP data bytes (including protocolheaders) received from the LLC protocol layer.
Pegging
The statistic is pegged each time the SNDCP protocol layer receives a data byte fromthe LLC protocol layer.
Analysis
The statistic can be used in conjunction with sgsnNumSndcpUpLinkDataBytesSent toshow the SGSN data packet throughput in the uplink direction across the SNDCPprotocol layer.
Reference
Usage
Network Planning
Congestion Identification
Loss Rates
Fault Finding
Basis
SNDCP
Statistic
Statistic Type
Counter
Statistic Data
Integer ( 0 - 4,294,967,295 )
ISSUE 1 REVISION 2 sgsnNumSndcpUpLinkDataPacketsDropped
�MOTOROLA LTD. 2000 GPRS01: GPRS Architecture
FOR TRAINING PURPOSES ONLY
7–49
sgsnNumSndcpUpLinkDataPacketsDropped
Description
This statistic indicates the total number of SNDCP data packets dropped in the uplinkdirection.
Pegging
The statistic is pegged each time the SNDCP protocol layer drops a data packet receivedfrom the LLC protocol layer.
Analysis
The statistic can be used in conjunction with SNDCP uplink throughput statistics toidentify uplink loss rates across the SNDCP protocol layer.
Reference
Usage
Loss Rates
Fault Finding
Basis
SNDCP
Statistic
Statistic Type
Counter
Statistic Data
Integer ( 0 - 4,294,967,295 )
ISSUE 1 REVISION 2sgsnNumSndcpDownLinkDataPacketsDropped
�MOTOROLA LTD. 2000GPRS01: GPRS Architecture
FOR TRAINING PURPOSES ONLY
7–50
sgsnNumSndcpDownLinkDataPacketsDropped
Description
This statistic indicates the total number of SNDCP data packets dropped in the downlinkdirection.
Pegging
The statistic is pegged each time the SNDCP protocol layer drops a data packet receivedfrom the GTP protocol layer.
Analysis
The statistic can be used in conjunction with SNDCP downlink throughput statistics toidentify downlink loss rates across the SNDCP protocol layer.
Reference
Usage
Loss Rates
Fault Finding
Basis
SNDCP
Statistic
Statistic Type
Counter
Statistic Data
Integer ( 0 - 4,294,967,295 )
ISSUE 1 REVISION 2 sgsnNumLlcDownLinkDataPacketsSent
�MOTOROLA LTD. 2000 GPRS01: GPRS Architecture
FOR TRAINING PURPOSES ONLY
7–51
sgsnNumLlcDownLinkDataPacketsSent
Description
This statistic indicates the total number of LLC data packets sent to the BSSGP protocollayer.
Pegging
The statistic is pegged each time the LLC protocol layer sends a data packet to theBSSGP protocol layer.
Analysis
The statistic can be used in conjunction with sgsnNumLlcDownLinkDataPacketsRcvdto show the SGSN data packet throughput in the downlink direction across the LLCprotocol layer.
Reference
Usage
Network Planning
Congestion Identification
Loss Rates
Fault Finding
Basis
LLC
Statistic
Statistic Type
Counter
Statistic Data
Integer ( 0 - 4,294,967,295 )
ISSUE 1 REVISION 2sgsnNumLlcDownLinkDataBytesSent
�MOTOROLA LTD. 2000GPRS01: GPRS Architecture
FOR TRAINING PURPOSES ONLY
7–52
sgsnNumLlcDownLinkDataBytesSent
Description
This statistic indicates the total number of LLC data bytes (including protocol headers)sent to the BSSGP protocol layer.
Pegging
The statistic is pegged each time the LLC protocol layer sends a data byte to the BSSGPprotocol layer.
Analysis
The statistic can be used in conjunction with sgsnNumLlcDownLinkDataBytesRcvd toshow the SGSN data byte throughput in the downlink direction across the LLC protocollayer.
Reference
Usage
Network Planning
Congestion Identification
Loss Rates
Fault Finding
Basis
LLC
Statistic
Statistic Type
Counter
Statistic Data
Integer ( 0 - 4,294,967,295 )
ISSUE 1 REVISION 2 sgsnNumLlcUpLinkDataPacketsRcvd
�MOTOROLA LTD. 2000 GPRS01: GPRS Architecture
FOR TRAINING PURPOSES ONLY
7–53
sgsnNumLlcUpLinkDataPacketsRcvd
Description
This statistic indicates the total number of LLC data packets received from the BSSGPprotocol layer.
Pegging
The statistic is pegged each time the LLC protocol layer receives a data packet from theBSSGP protocol layer.
Analysis
The statistic can be used in conjunction with sgsnNumLlcUpLinkDataPacketsSent toshow the SGSN data packet throughput in the uplink direction across the LLC protocollayer.
Reference
Usage
Network Planning
Congestion Identification
Loss Rates
Fault Finding
Basis
LLC
Statistic
Statistic Type
Counter
Statistic Data
Integer ( 0 - 4,294,967,295 )
ISSUE 1 REVISION 2sgsnNumLlcUpLinkDataBytesRcvd
�MOTOROLA LTD. 2000GPRS01: GPRS Architecture
FOR TRAINING PURPOSES ONLY
7–54
sgsnNumLlcUpLinkDataBytesRcvd
Description
This statistic indicates the total number of LLC data bytes (including protocol headers)received from the BSSGP protocol layer.
Pegging
The statistic is pegged each time the LLC protocol layer receives a data byte from theBSSGP protocol layer.
Analysis
The statistic can be used in conjunction with sgsnNumLlcUpLinkDataBytesSent toshow the SGSN data byte throughput in the uplink direction across the LLC protocollayer.
Reference
Usage
Network Planning
Congestion Identification
Loss Rates
Fault Finding
Basis
LLC
Statistic
Statistic Type
Counter
Statistic Data
Integer ( 0 - 4,294,967,295 )
ISSUE 1 REVISION 2 sgsnNumLlcDownLinkSignalPacketsSent
�MOTOROLA LTD. 2000 GPRS01: GPRS Architecture
FOR TRAINING PURPOSES ONLY
7–55
sgsnNumLlcDownLinkSignalPacketsSent
Description
This statistic indicates the total number of LLC signalling packets sent to the BSSGPprotocol layer.
Pegging
The statistic is pegged each time the LLC protocol layer sends a signalling packet to theBSSGP protocol layer.
Analysis
The statistic can be used in conjunction with sgsnNumLlcDownLinkSignalPacketsRcvd to show the SGSN signal packet throughput in the downlink direction across theLLC protocol layer.
Reference
Usage
Network Planning
Congestion Identification
Loss Rates
Fault Finding
Basis
LLC
Statistic
Statistic Type
Counter
Statistic Data
Integer ( 0 - 4,294,967,295 )
ISSUE 1 REVISION 2sgsnNumLlcDownLinkSignalBytesSent
�MOTOROLA LTD. 2000GPRS01: GPRS Architecture
FOR TRAINING PURPOSES ONLY
7–56
sgsnNumLlcDownLinkSignalBytesSent
Description
This statistic indicates the total number of LLC signalling bytes (including protocolheaders) sent to the BSSGP protocol layer.
Pegging
The statistic is pegged each time the LLC protocol layer sends a signalling byte to theBSSGP protocol layer.
Analysis
The statistic can be used in conjunction with sgsnNumLlcDownLinkSignalBytesRcvdto show the SGSN signalling byte throughput in the downlink direction across the LLCprotocol layer.
Reference
Usage
Network Planning
Congestion Identification
Loss Rates
Fault Finding
Basis
LLC
Statistic
Statistic Type
Counter
Statistic Data
Integer ( 0 - 4,294,967,295 )
ISSUE 1 REVISION 2 sgsnNumLlcUpLinkSignalPacketsRcvd
�MOTOROLA LTD. 2000 GPRS01: GPRS Architecture
FOR TRAINING PURPOSES ONLY
7–57
sgsnNumLlcUpLinkSignalPacketsRcvd
Description
This statistic indicates the total number of LLC signalling packets received from theBSSGP protocol layer.
Pegging
The statistic is pegged each time the LLC protocol layer receives a signalling packet fromthe BSSGP protocol layer.
Analysis
The statistic can be used in conjunction with sgsnNumLlcUpLinkSignalPacketsSent toshow the SGSN signalling packet throughput in the uplink direction across the LLCprotocol layer.
Reference
Usage
Network Planning
Congestion Identification
Loss Rates
Fault Finding
Basis
LLC
Statistic
Statistic Type
Counter
Statistic Data
Integer ( 0 - 4,294,967,295 )
ISSUE 1 REVISION 2sgsnNumLlcUpLinkSignalBytesRcvd
�MOTOROLA LTD. 2000GPRS01: GPRS Architecture
FOR TRAINING PURPOSES ONLY
7–58
sgsnNumLlcUpLinkSignalBytesRcvd
Description
This statistic indicates the total number of LLC signalling bytes (including protocolheaders) received from the BSSGP protocol layer.
Pegging
The statistic is pegged each time the LLC protocol layer receives a signalling byte fromthe BSSGP protocol layer.
Analysis
The statistic can be used in conjunction with sgsnNumLlcUpLinkSignalBytesSent toshow the SGSN signalling byte throughput in the uplink direction across the LLC protocollayer.
Reference
Usage
Network Planning
Congestion Identification
Loss Rates
Fault Finding
Basis
LLC
Statistic
Statistic Type
Counter
Statistic Data
Integer ( 0 - 4,294,967,295 )
ISSUE 1 REVISION 2 sgsnNumLlcUpLinkDataPacketsSent
�MOTOROLA LTD. 2000 GPRS01: GPRS Architecture
FOR TRAINING PURPOSES ONLY
7–59
sgsnNumLlcUpLinkDataPacketsSent
Description
This statistic indicates the total number of LLC data packets sent to the SNDCP protocollayer.
Pegging
The statistic is pegged each time the LLC protocol layer sends a data packet to theSNDCP protocol layer.
Analysis
The statistic can be used in conjunction with sgsnNumLlcUpLinkDataPacketsRcvd toshow the SGSN data packet throughput in the Uplink direction across the LLC protocollayer.
Reference
Usage
Network Planning
Congestion Identification
Loss Rates
Fault Finding
Basis
LLC
Statistic
Statistic Type
Counter
Statistic Data
Integer ( 0 - 4,294,967,295 )
ISSUE 1 REVISION 2sgsnNumLlcUpLinkDataBytesSent
�MOTOROLA LTD. 2000GPRS01: GPRS Architecture
FOR TRAINING PURPOSES ONLY
7–60
sgsnNumLlcUpLinkDataBytesSent
Description
This statistic indicates the total number of LLC data bytes (including protocol headers)sent to the SNDCP protocol layer.
Pegging
The statistic is pegged each time the LLC protocol layer sends a data byte to the SNDCPprotocol layer.
Analysis
The statistic can be used in conjunction with sgsnNumLlcUpLinkDataBytesRcvd toshow the SGSN data byte throughput in the Uplink direction across the LLC protocollayer.
Reference
Usage
Network Planning
Congestion Identification
Loss Rates
Fault Finding
Basis
LLC
Statistic
Statistic Type
Counter
Statistic Data
Integer ( 0 - 4,294,967,295 )
ISSUE 1 REVISION 2 sgsnNumLlcDownLinkDataPacketsRcvd
�MOTOROLA LTD. 2000 GPRS01: GPRS Architecture
FOR TRAINING PURPOSES ONLY
7–61
sgsnNumLlcDownLinkDataPacketsRcvd
Description
This statistic indicates the total number of LLC data packets received from the SNDCPprotocol layer.
Pegging
The statistic is pegged each time the LLC protocol layer receives a data packet from theSNDCP protocol layer.
Analysis
The statistic can be used in conjunction with sgsnNumLlcDownLinkDataPacketsSentto show the SGSN data packet throughput in the downlink direction across the LLCprotocol layer.
Reference
Usage
Network Planning
Congestion Identification
Loss Rates
Fault Finding
Basis
LLC
Statistic
Statistic Type
Counter
Statistic Data
Integer ( 0 - 4,294,967,295 )
ISSUE 1 REVISION 2sgsnNumLlcDownLinkDataBytesRcvd
�MOTOROLA LTD. 2000GPRS01: GPRS Architecture
FOR TRAINING PURPOSES ONLY
7–62
sgsnNumLlcDownLinkDataBytesRcvd
Description
This statistic indicates the total number of LLC data bytes (including protocol headers)received from the SNDCP protocol layer.
Pegging
The statistic is pegged each time the LLC protocol layer receives a data byte from theSNDCP protocol layer.
Analysis
The statistic can be used in conjunction with sgsnNumLlcDownLinkDataBytesSent toshow the SGSN data byte throughput in the downlink direction across the LLC protocollayer.
Reference
Usage
Network Planning
Congestion Identification
Loss Rates
Fault Finding
Basis
LLC
Statistic
Statistic Type
Counter
Statistic Data
Integer ( 0 - 4,294,967,295 )
ISSUE 1 REVISION 2 sgsnNumLlcUpLinkSignalPacketsSent
�MOTOROLA LTD. 2000 GPRS01: GPRS Architecture
FOR TRAINING PURPOSES ONLY
7–63
sgsnNumLlcUpLinkSignalPacketsSent
Description
This statistic indicates the total number of LLC signalling packets sent to the SNDCPprotocol layer.
Pegging
The statistic is pegged each time the LLC protocol layer sends a signalling packet to theSNDCP protocol layer.
Analysis
The statistic can be used in conjunction with sgsnNumLlcUpLinkSignalPacketsRcvdto show the SGSN signal packet throughput in the uplink direction across the LLCprotocol layer.
Reference
Usage
Network Planning
Congestion Identification
Loss Rates
Fault Finding
Basis
LLC
Statistic
Statistic Type
Counter
Statistic Data
Integer ( 0 - 4,294,967,295 )
ISSUE 1 REVISION 2sgsnNumLlcUpLinkSignalBytesSent
�MOTOROLA LTD. 2000GPRS01: GPRS Architecture
FOR TRAINING PURPOSES ONLY
7–64
sgsnNumLlcUpLinkSignalBytesSent
Description
This statistic indicates the total number of LLC signalling bytes (including protocolheaders) sent to the SNDCP protocol layer.
Pegging
The statistic is pegged each time the LLC protocol layer sends a signalling byte to theSNDCP protocol layer.
Analysis
The statistic can be used in conjunction with sgsnNumLlcUpLinkSignalBytesRcvd toshow the SGSN signalling byte throughput in the uplink direction across the LLC protocollayer.
Reference
Usage
Network Planning
Congestion Identification
Loss Rates
Fault Finding
Basis
LLC
Statistic
Statistic Type
Counter
Statistic Data
Integer ( 0 - 4,294,967,295 )
ISSUE 1 REVISION 2 sgsnNumLlcDownLinkSignalPacketsRcvd
�MOTOROLA LTD. 2000 GPRS01: GPRS Architecture
FOR TRAINING PURPOSES ONLY
7–65
sgsnNumLlcDownLinkSignalPacketsRcvd
Description
This statistic indicates the total number of LLC signalling packets received from theSNDCP protocol layer.
Pegging
The statistic is pegged each time the LLC protocol layer receives a signalling packet fromthe SNDCP protocol layer.
Analysis
The statistic can be used in conjunction with sgsnNumLlcDownLinkSignalPacketsSent to show the SGSN signalling packet throughput in the downlink direction across theLLC protocol layer.
Reference
Usage
Network Planning
Congestion Identification
Loss Rates
Fault Finding
Basis
LLC
Statistic
Statistic Type
Counter
Statistic Data
Integer ( 0 - 4,294,967,295 )
ISSUE 1 REVISION 2sgsnNumLlcDownLinkSignalBytesRcvd
�MOTOROLA LTD. 2000GPRS01: GPRS Architecture
FOR TRAINING PURPOSES ONLY
7–66
sgsnNumLlcDownLinkSignalBytesRcvd
Description
This statistic indicates the total number of LLC signalling bytes (including protocolheaders) received from the SNDCP protocol layer.
Pegging
The statistic is pegged each time the LLC protocol layer receives a signalling byte fromthe SNDCP protocol layer.
Analysis
The statistic can be used in conjunction with sgsnNumLlcDownLinkSignalBytesSentto show the SGSN signalling byte throughput in the downlink direction across the LLCprotocol layer.
Reference
Usage
Network Planning
Congestion Identification
Loss Rates
Fault Finding
Basis
LLC
Statistic
Statistic Type
Counter
Statistic Data
Integer ( 0 - 4,294,967,295 )
ISSUE 1 REVISION 2 sgsnNumLlcUpLinkDataPacketsDropped
�MOTOROLA LTD. 2000 GPRS01: GPRS Architecture
FOR TRAINING PURPOSES ONLY
7–67
sgsnNumLlcUpLinkDataPacketsDropped
Description
This statistic indicates the total number of LLC data packets dropped in the uplinkdirection.
Pegging
The statistic is pegged each time the LLC protocol layer drops a data packet receivedfrom the BSSGP protocol layer.
Analysis
The statistic can be used in conjunction with LLC uplink data throughput statistics toidentify uplink data loss rates across the LLC protocol layer.
Reference
Usage
Loss Rates
Fault Finding
Basis
LLC
Statistic
Statistic Type
Counter
Statistic Data
Integer ( 0 - 4,294,967,295 )
ISSUE 1 REVISION 2sgsnNumLlcDownLinkDataPacketsDropped
�MOTOROLA LTD. 2000GPRS01: GPRS Architecture
FOR TRAINING PURPOSES ONLY
7–68
sgsnNumLlcDownLinkDataPacketsDropped
Description
This statistic indicates the total number of LLC data packets dropped in the downlinkdirection.
Pegging
The statistic is pegged each time the LLC protocol layer drops a data packet receivedfrom the SNDCP protocol layer.
Analysis
The statistic can be used in conjunction with LLC downlink data throughput statistics toidentify downlink data loss rates across the LLC protocol layer.
Reference
Usage
Loss Rates
Fault Finding
Basis
LLC
Statistic
Statistic Type
Counter
Statistic Data
Integer ( 0 - 4,294,967,295 )
ISSUE 1 REVISION 2 sgsnNumLlcUpLinkSignalPacketsDropped
�MOTOROLA LTD. 2000 GPRS01: GPRS Architecture
FOR TRAINING PURPOSES ONLY
7–69
sgsnNumLlcUpLinkSignalPacketsDropped
Description
This statistic indicates the total number of LLC signalling packets dropped in the uplinkdirection.
Pegging
The statistic is pegged each time the LLC protocol layer drops a signalling packetreceived from the BSSGP protocol layer.
Analysis
The statistic can be used in conjunction with LLC uplink signalling throughput statistics toidentify uplink signalling loss rates across the LLC protocol layer.
Reference
Usage
Loss Rates
Fault Finding
Basis
LLC
Statistic
Statistic Type
Counter
Statistic Data
Integer ( 0 - 4,294,967,295 )
ISSUE 1 REVISION 2sgsnNumLlcDownLinkSignalPacketsDropped
�MOTOROLA LTD. 2000GPRS01: GPRS Architecture
FOR TRAINING PURPOSES ONLY
7–70
sgsnNumLlcDownLinkSignalPacketsDropped
Description
This statistic indicates the total number of LLC signalling packets dropped in the downlinkdirection.
Pegging
The statistic is pegged each time the LLC protocol layer drops a signalling packetreceived from the SNDCP protocol layer.
Analysis
The statistic can be used in conjunction with LLC downlink signalling throughput statisticsto identify downlink signalling loss rates across the LLC protocol layer.
Reference
Usage
Loss Rates
Fault Finding
Basis
LLC
Statistic
Statistic Type
Counter
Statistic Data
Integer ( 0 - 4,294,967,295 )
ISSUE 1 REVISION 2 sgsnNumLlcPacketsResent
�MOTOROLA LTD. 2000 GPRS01: GPRS Architecture
FOR TRAINING PURPOSES ONLY
7–71
sgsnNumLlcPacketsResent
Description
This statistic indicates the total number of LLC packets resent.
Pegging
Analysis
Reference
Usage
Basis
LLC
Statistic
Statistic Type
Counter
Statistic Data
Integer ( 0 - 4,294,967,295 )
ISSUE 1 REVISION 2sgsnNumBssgpDownLinkDataPacketsSent
�MOTOROLA LTD. 2000GPRS01: GPRS Architecture
FOR TRAINING PURPOSES ONLY
7–72
sgsnNumBssgpDownLinkDataPacketsSent
Description
This BSSGP attribute indicates the total number of BSSGP data packets sent to the NSprotocol layer.
Pegging
The statistic is pegged each time the BSSGP protocol layer sends a data packet to theNS protocol layer.
Analysis
The statistic can be used in conjunction with sgsnNumBssgpDownLinkDataPacketsRcvd to show the SGSN data packet throughput in the downlink direction across theBSSGP protocol layer.
Reference
Usage
Network Planning
Congestion Identification
Loss Rates
Fault Finding
Basis
BSSGP
Statistic
Statistic Type
Counter
Statistic Data
Integer ( 0 - 4,294,967,295 )
ISSUE 1 REVISION 2 sgsnNumBssgpDownLinkDataBytesSent
�MOTOROLA LTD. 2000 GPRS01: GPRS Architecture
FOR TRAINING PURPOSES ONLY
7–73
sgsnNumBssgpDownLinkDataBytesSent
Description
This BSSGP attribute indicates the total number of BSSGP data bytes (including protocolheaders) sent to the NS protocol layer.
Pegging
The statistic is pegged each time the BSSGP protocol layer sends a data byte to the NSprotocol layer.
Analysis
The statistic can be used in conjunction with sgsnNumBssgpDownLinkDataBytesRcvd to show the SGSN data byte throughput in the downlink direction across theBSSGP protocol layer.
Reference
Usage
Network Planning
Congestion Identification
Loss Rates
Fault Finding
Basis
BSSGP
Statistic
Statistic Type
Counter
Statistic Data
Integer ( 0 - 4,294,967,295 )
ISSUE 1 REVISION 2sgsnNumBssgpUpLinkDataPacketsRcvd
�MOTOROLA LTD. 2000GPRS01: GPRS Architecture
FOR TRAINING PURPOSES ONLY
7–74
sgsnNumBssgpUpLinkDataPacketsRcvd
Description
This BSSGP attribute indicates the total number of BSSGP data packets received fromNS protocol layer.
Pegging
The statistic is pegged each time the BSSGP protocol layer receives a data packet fromthe NS protocol layer.
Analysis
The statistic can be used in conjunction with sgsnNumBssgpUpLinkDataPacketsSentto show the SGSN data packet throughput in the uplink direction across the BSSGPprotocol layer.
Reference
Usage
Network Planning
Congestion Identification
Loss Rates
Fault Finding
Basis
BSSGP
Statistic
Statistic Type
Counter
Statistic Data
Integer ( 0 - 4,294,967,295 )
ISSUE 1 REVISION 2 sgsnNumBssgpUpLinkDataBytesRcvd
�MOTOROLA LTD. 2000 GPRS01: GPRS Architecture
FOR TRAINING PURPOSES ONLY
7–75
sgsnNumBssgpUpLinkDataBytesRcvd
Description
This BSSGP attribute indicates the total number of BSSGP data bytes (including protocolheaders) received from NS protocol layer.
Pegging
The statistic is pegged each time the BSSGP protocol layer receives a data byte from theNS protocol layer.
Analysis
The statistic can be used in conjunction with sgsnNumBssgpUpLinkDataBytesSent toshow the SGSN data byte throughput in the uplink direction across the BSSGP protocollayer.
Reference
Usage
Network Planning
Congestion Identification
Loss Rates
Fault Finding
Basis
BSSGP
Statistic
Statistic Type
Counter
Statistic Data
Integer ( 0 - 4,294,967,295 )
ISSUE 1 REVISION 2sgsnNumBssgpUpLinkDataPacketsSent
�MOTOROLA LTD. 2000GPRS01: GPRS Architecture
FOR TRAINING PURPOSES ONLY
7–76
sgsnNumBssgpUpLinkDataPacketsSent
Description
This BSSGP attribute indicates the total number of BSSGP data packets sent to the LLCprotocol layer.
Pegging
The statistic is pegged each time the BSSGP protocol layer sends a data packet to theLLC protocol layer.
Analysis
The statistic can be used in conjunction with sgsnNumBssgpUpLinkDataPacketsRcvdto show the SGSN data packet throughput in the uplink direction across the BSSGPprotocol layer.
Reference
Usage
Network Planning
Congestion Identification
Loss Rates
Fault Finding
Basis
BSSGP
Statistic
Statistic Type
Counter
Statistic Data
Integer ( 0 - 4,294,967,295 )
ISSUE 1 REVISION 2 sgsnNumBssgpUpLinkDataBytesSent
�MOTOROLA LTD. 2000 GPRS01: GPRS Architecture
FOR TRAINING PURPOSES ONLY
7–77
sgsnNumBssgpUpLinkDataBytesSent
Description
This BSSGP attribute indicates the total number of BSSGP data bytes (including protocolheaders) sent to the LLC protocol layer.
Pegging
The statistic is pegged each time the BSSGP protocol layer sends a data byte to the LLCprotocol layer.
Analysis
The statistic can be used in conjunction with sgsnNumBssgpUpLinkDataBytesRcvd toshow the SGSN data byte throughput in the uplink direction across the BSSGP protocollayer.
Reference
Usage
Network Planning
Congestion Identification
Loss Rates
Fault Finding
Basis
BSSGP
Statistic
Statistic Type
Counter
Statistic Data
Integer ( 0 - 4,294,967,295 )
ISSUE 1 REVISION 2sgsnNumBssgpDownLinkDataPacketsRcvd
�MOTOROLA LTD. 2000GPRS01: GPRS Architecture
FOR TRAINING PURPOSES ONLY
7–78
sgsnNumBssgpDownLinkDataPacketsRcvd
Description
This BSSGP attribute indicates the total number of BSSGP data packets received fromthe LLC protocol layer.
Pegging
The statistic is pegged each time the BSSGP protocol layer receives a data packet fromthe LLC protocol layer.
Analysis
The statistic can be used in conjunction with sgsnNumBssgpDownLinkDataPacketsSent to show the SGSN data packet throughput in the downlink direction across theBSSGP protocol layer.
Reference
Usage
Network Planning
Congestion Identification
Loss Rates
Fault Finding
Basis
BSSGP
Statistic
Statistic Type
Counter
Statistic Data
Integer ( 0 - 4,294,967,295 )
ISSUE 1 REVISION 2 sgsnNumBssgpDownLinkDataBytesRcvd
�MOTOROLA LTD. 2000 GPRS01: GPRS Architecture
FOR TRAINING PURPOSES ONLY
7–79
sgsnNumBssgpDownLinkDataBytesRcvd
Description
This BSSGP attribute indicates the total number of BSSGP data bytes (including protocolheaders) received from the LLC protocol layer.
Pegging
The statistic is pegged each time the BSSGP protocol layer receives a data byte from theLLC protocol layer.
Analysis
The statistic can be used in conjunction with sgsnNumBssgpDownLinkDataBytesSentto show the SGSN data byte throughput in the downlink direction across the BSSGPprotocol layer.
Reference
Usage
Network Planning
Congestion Identification
Loss Rates
Fault Finding
Basis
BSSGP
Statistic
Statistic Type
Counter
Statistic Data
Integer ( 0 - 4,294,967,295 )
ISSUE 1 REVISION 2sgsnNumBssgpUpLinkDataPacketsDropped
�MOTOROLA LTD. 2000GPRS01: GPRS Architecture
FOR TRAINING PURPOSES ONLY
7–80
sgsnNumBssgpUpLinkDataPacketsDropped
Description
This BSSGP attribute indicates the total number of BSSGP data packets dropped in theuplink direction.
Pegging
The statistic is pegged each time the BSSGP protocol layer drops a data packet receivedfrom the NS protocol layer.
Analysis
The statistic can be used in conjunction with BSSGP uplink throughput statistics toidentify uplink loss rates across the BSSGP protocol layer.
Reference
Usage
Loss Rates
Fault Finding
Basis
BSSGP
Statistic
Statistic Type
Counter
Statistic Data
Integer ( 0 - 4,294,967,295 )
ISSUE 1 REVISION 2 sgsnNumBssgpDownLinkDataPacketsDropped
�MOTOROLA LTD. 2000 GPRS01: GPRS Architecture
FOR TRAINING PURPOSES ONLY
7–81
sgsnNumBssgpDownLinkDataPacketsDropped
Description
This BSSGP attribute indicates the total number of BSSGP data packets dropped in thedownlink direction.
Pegging
The statistic is pegged each time the BSSGP protocol layer drops a data packet receivedfrom the LLC protocol layer.
Analysis
The statistic can be used in conjunction with BSSGP downlink throughput statistics toidentify downlink loss rates across the BSSGP protocol layer.
Reference
Usage
Loss Rates
Fault Finding
Basis
BSSGP
Statistic
Statistic Type
Counter
Statistic Data
Integer ( 0 - 4,294,967,295 )
ISSUE 1 REVISION 2sgsnNumNsDownLinkDataPacketsRcvd
�MOTOROLA LTD. 2000GPRS01: GPRS Architecture
FOR TRAINING PURPOSES ONLY
7–82
sgsnNumNsDownLinkDataPacketsRcvd
Description
This statistic indicates the total number of NS data packets received from the BSSGPprotocol layer.
Pegging
The statistic is pegged each time the NS protocol layer receives a data packet from theBSSGP protocol layer.
Analysis
The statistic can be used in conjunction with sgsnNumNsDownLinkDataPacketsSentto show the SGSN data packet throughput in the downlink direction across the NSprotocol layer.
Reference
Usage
Network Planning
Congestion Identification
Loss Rates
Fault Finding
Basis
NS
Statistic
Statistic Type
Counter
Statistic Data
Integer ( 0 - 4,294,967,295 )
ISSUE 1 REVISION 2 sgsnNumNsDownLinkDataBytesRcvd
�MOTOROLA LTD. 2000 GPRS01: GPRS Architecture
FOR TRAINING PURPOSES ONLY
7–83
sgsnNumNsDownLinkDataBytesRcvd
Description
This statistic indicates the total number of NS data bytes (including protocol headers)received from the BSSGP protocol layer.
Pegging
The statistic is pegged each time the NS protocol layer receives a data byte from theBSSGP protocol layer.
Analysis
The statistic can be used in conjunction with sgsnNumNsDownLinkDataBytesSent toshow the SGSN data byte throughput in the downlink direction across the NS protocollayer.
Reference
Usage
Network Planning
Congestion Identification
Loss Rates
Fault Finding
Basis
NS
Statistic
Statistic Type
Counter
Statistic Data
Integer ( 0 - 4,294,967,295 )
ISSUE 1 REVISION 2sgsnNumNsUpLinkDataPacketsSent
�MOTOROLA LTD. 2000GPRS01: GPRS Architecture
FOR TRAINING PURPOSES ONLY
7–84
sgsnNumNsUpLinkDataPacketsSent
Description
This statistic indicates the total number of NS data packets sent to the BSSGP protocollayer.
Pegging
The statistic is pegged each time the NS protocol layer sends a data packet to theBSSGP protocol layer.
Analysis
The statistic can be used in conjunction with sgsnNumNsUpLinkDataPacketsRcvd toshow the SGSN data packet throughput in the uplink direction across the NS protocollayer.
Reference
Usage
Network Planning
Congestion Identification
Loss Rates
Fault Finding
Basis
NS
Statistic
Statistic Type
Counter
Statistic Data
Integer ( 0 - 4,294,967,295 )
ISSUE 1 REVISION 2 sgsnNumNsUpLinkDataBytesSent
�MOTOROLA LTD. 2000 GPRS01: GPRS Architecture
FOR TRAINING PURPOSES ONLY
7–85
sgsnNumNsUpLinkDataBytesSent
Description
This statistic indicates the total number of NS data bytes (including protocol headers)sent to the BSSGP protocol layer.
Pegging
The statistic is pegged each time the NS protocol layer sends a data byte to the BSSGPprotocol layer.
Analysis
The statistic can be used in conjunction with sgsnNumNsUpLinkDataBytesRcvd toshow the SGSN data byte throughput in the uplink direction across the NS protocol layer.
Reference
Usage
Network Planning
Congestion Identification
Loss Rates
Fault Finding
Basis
NS
Statistic
Statistic Type
Counter
Statistic Data
Integer ( 0 - 4,294,967,295 )
ISSUE 1 REVISION 2sgsnNumNsUpLinkDataPacketsRcvd
�MOTOROLA LTD. 2000GPRS01: GPRS Architecture
FOR TRAINING PURPOSES ONLY
7–86
sgsnNumNsUpLinkDataPacketsRcvd
Description
This statistic indicates the total number of NS data packets received from the FR protocollayer.
Pegging
The statistic is pegged each time the NS protocol layer receives a data packet from theFR protocol layer.
Analysis
The statistic can be used in conjunction with sgsnNumNsUpLinkDataPacketsSent toshow the SGSN data packet throughput in the uplink direction across the NS protocollayer.
Reference
Usage
Network Planning
Congestion Identification
Loss Rates
Fault Finding
Basis
NS
Statistic
Statistic Type
Counter
Statistic Data
Integer ( 0 - 4,294,967,295 )
ISSUE 1 REVISION 2 sgsnNumNsUpLinkDataBytesRcvd
�MOTOROLA LTD. 2000 GPRS01: GPRS Architecture
FOR TRAINING PURPOSES ONLY
7–87
sgsnNumNsUpLinkDataBytesRcvd
Description
This statistic indicates the total number of NS data bytes (including protocol headers)received from the FR protocol layer.
Pegging
The statistic is pegged each time the NS protocol layer receives a data byte from the FRprotocol layer.
Analysis
The statistic can be used in conjunction with sgsnNumNsUpLinkDataBytesSent toshow the SGSN data byte throughput in the uplink direction across the NS protocol layer.
Reference
Usage
Network Planning
Congestion Identification
Loss Rates
Fault Finding
Basis
NS
Statistic
Statistic Type
Counter
Statistic Data
Integer ( 0 - 4,294,967,295 )
ISSUE 1 REVISION 2sgsnNumNsDownLinkDataPacketsSent
�MOTOROLA LTD. 2000GPRS01: GPRS Architecture
FOR TRAINING PURPOSES ONLY
7–88
sgsnNumNsDownLinkDataPacketsSent
Description
This statistic indicates the total number of NS data packets sent to the FR protocol layer.
Pegging
The statistic is pegged each time the NS protocol layer sends a data packet to the FRprotocol layer.
Analysis
The statistic can be used in conjunction with sgsnNumNsDownLinkDataPacketsRcvdto show the SGSN data packet throughput in the downlink direction across the NSprotocol layer.
Reference
Usage
Network Planning
Congestion Identification
Loss Rates
Fault Finding
Basis
NS
Statistic
Statistic Type
Counter
Statistic Data
Integer ( 0 - 4,294,967,295 )
ISSUE 1 REVISION 2 sgsnNumNsDownLinkDataBytesSent
�MOTOROLA LTD. 2000 GPRS01: GPRS Architecture
FOR TRAINING PURPOSES ONLY
7–89
sgsnNumNsDownLinkDataBytesSent
Description
This statistic indicates the total number of NS data bytes (including protocol headers)sent to the FR protocol layer.
Pegging
The statistic is pegged each time the NS protocol layer sends a data byte to the FRprotocol layer.
Analysis
The statistic can be used in conjunction with sgsnNumNsDownLinkDataBytesRcvd toshow the SGSN data byte throughput in the downlink direction across the NS protocollayer.
Reference
Usage
Network Planning
Congestion Identification
Loss Rates
Fault Finding
Basis
NS
Statistic
Statistic Type
Counter
Statistic Data
Integer ( 0 - 4,294,967,295 )
ISSUE 1 REVISION 2sgsnNumNsUpLinkDataPacketsDropped
�MOTOROLA LTD. 2000GPRS01: GPRS Architecture
FOR TRAINING PURPOSES ONLY
7–90
sgsnNumNsUpLinkDataPacketsDropped
Description
This statistic indicates the total number of NS data packets dropped in the uplinkdirection.
Pegging
The statistic is pegged each time the NS protocol layer drops a data packet receivedfrom the FR protocol layer.
Analysis
The statistic can be used in conjunction with NS uplink throughput statistics to identifyuplink loss rates across the NS protocol layer.
Reference
Usage
Loss Rates
Fault Finding
Basis
NS
Statistic
Statistic Type
Counter
Statistic Data
Integer ( 0 - 4,294,967,295 )
ISSUE 1 REVISION 2 sgsnNumNsDownLinkDataPacketsDropped
�MOTOROLA LTD. 2000 GPRS01: GPRS Architecture
FOR TRAINING PURPOSES ONLY
7–91
sgsnNumNsDownLinkDataPacketsDropped
Description
This statistic indicates the total number of NS data packets dropped in the downlinkdirection.
Pegging
The statistic is pegged each time the NS protocol layer drops a data packet receivedfrom the BSSGP protocol layer.
Analysis
The statistic can be used in conjunction with NS downlink throughput statistics to identifydownlink loss rates across the NS protocol layer.
Reference
Usage
Loss Rates
Fault Finding
Basis
GTP Gn
Statistic
Statistic Type
Counter
Statistic Data
Integer ( 0 - 4,294,967,295 )
ISSUE 1 REVISION 2sgsnNumL3mmAttachReqRcvd
�MOTOROLA LTD. 2000GPRS01: GPRS Architecture
FOR TRAINING PURPOSES ONLY
7–92
sgsnNumL3mmAttachReqRcvd
Description
This statistic indicates the total number of L3MM Attach Requests received.
Pegging
The statistic is pegged when the SGSN receives an Attach Request from a MS.
Analysis
Reference
Usage
Network Planning
Congestion Identification
Quality of Service Issues
Basis
L3MM
Statistic
Statistic Type
Counter
Statistic Data
Integer ( 0 - 4,294,967,295 )
ISSUE 1 REVISION 2 sgsnNumL3mmAttachAcceptSent
�MOTOROLA LTD. 2000 GPRS01: GPRS Architecture
FOR TRAINING PURPOSES ONLY
7–93
sgsnNumL3mmAttachAcceptSent
Description
This statistic indicates the total number of L3MM Attach Accepts sent.
Pegging
The statistic is pegged when the SGSN sends an Attach Accept to a MS.
Analysis
Reference
Usage
Network Planning
Congestion Identification
Quality of Service Issues
Basis
L3MM
Statistic
Statistic Type
Counter
Statistic Data
Integer ( 0 - 4,294,967,295 )
ISSUE 1 REVISION 2sgsnNumL3mmAttachRejectSent
�MOTOROLA LTD. 2000GPRS01: GPRS Architecture
FOR TRAINING PURPOSES ONLY
7–94
sgsnNumL3mmAttachRejectSent
Description
This statistic indicates the total number of L3MM Attach Rejects sent.
Pegging
The statistic is pegged when the SGSN sends an Attach Reject to a MS.
Analysis
Reference
Usage
Network Planning
Congestion Identification
Quality of Service Issues
Basis
L3MM
Statistic
Statistic Type
Counter
Statistic Data
Integer ( 0 - 4,294,967,295 )
ISSUE 1 REVISION 2 sgsnNumL3mmDetachReqRcvd
�MOTOROLA LTD. 2000 GPRS01: GPRS Architecture
FOR TRAINING PURPOSES ONLY
7–95
sgsnNumL3mmDetachReqRcvd
Description
This statistic indicates the total number of L3MM Detach Requests received.
Pegging
The statistic is pegged when the SGSN receives a Detach Request from a MS.
Analysis
Reference
Usage
Network Planning
Congestion Identification
Quality of Service Issues
Basis
L3MM
Statistic
Statistic Type
Counter
Statistic Data
Integer ( 0 - 4,294,967,295 )
ISSUE 1 REVISION 2sgsnNumL3mmDetachAcceptSent
�MOTOROLA LTD. 2000GPRS01: GPRS Architecture
FOR TRAINING PURPOSES ONLY
7–96
sgsnNumL3mmDetachAcceptSent
Description
This statistic indicates the total number of L3MM Detach Accepts sent.
Pegging
The statistic is pegged when the SGSN sends a Detach Request to a MS.
Analysis
Reference
Usage
Network Planning
Congestion Identification
Quality of Service Issues
Basis
L3MM
Statistic
Statistic Type
Counter
Statistic Data
Integer ( 0 - 4,294,967,295 )
ISSUE 1 REVISION 2 sgsnNumL3mmSessionActivateReqRcvd
�MOTOROLA LTD. 2000 GPRS01: GPRS Architecture
FOR TRAINING PURPOSES ONLY
7–97
sgsnNumL3mmSessionActivateReqRcvd
Description
This statistic indicates the total number of L3MM Session Activate requests received.
Pegging
The statistic is pegged when the SGSN receives a Session Activation Request from aMS.
Analysis
Reference
Usage
Network Planning
Congestion Identification
Quality of Service Issues
Basis
L3MM
Statistic
Statistic Type
Counter
Statistic Data
Integer ( 0 - 4,294,967,295 )
ISSUE 1 REVISION 2sgsnNumL3mmSessionActivateAcceptSent
�MOTOROLA LTD. 2000GPRS01: GPRS Architecture
FOR TRAINING PURPOSES ONLY
7–98
sgsnNumL3mmSessionActivateAcceptSent
Description
This statistic indicates the total number of L3MM Session Activate accepts sent.
Pegging
The statistic is pegged when the SGSN sends a Session Activation Accept to a MS.
Analysis
Reference
Usage
Network Planning
Congestion Identification
Quality of Service Issues
Basis
L3MM
Statistic
Statistic Type
Counter
Statistic Data
Integer ( 0 - 4,294,967,295 )
ISSUE 1 REVISION 2 sgsnNumL3mmSessionActivateRejectSent
�MOTOROLA LTD. 2000 GPRS01: GPRS Architecture
FOR TRAINING PURPOSES ONLY
7–99
sgsnNumL3mmSessionActivateRejectSent
Description
This statistic indicates the total number of L3MM Session Activate rejects sent.
Pegging
The statistic is pegged when the SGSN sends a Session Activation Reject to a MS.
Analysis
Reference
Usage
Network Planning
Congestion Identification
Quality of Service Issues
Basis
L3MM
Statistic
Statistic Type
Counter
Statistic Data
Integer ( 0 - 4,294,967,295 )
ISSUE 1 REVISION 2sgsnNumL3mmSessionDeactivateReqRcvd
�MOTOROLA LTD. 2000GPRS01: GPRS Architecture
FOR TRAINING PURPOSES ONLY
7–100
sgsnNumL3mmSessionDeactivateReqRcvd
Description
This statistic indicates the total number of L3MM Session Deactivate requests received.
Pegging
The statistic is pegged when the SGSN receives a Session Deactivation Request from aMS.
Analysis
Reference
Usage
Network Planning
Congestion Identification
Quality of Service Issues
Basis
L3MM
Statistic
Statistic Type
Counter
Statistic Data
Integer ( 0 - 4,294,967,295 )
ISSUE 1 REVISION 2 sgsnNumL3mmSessionDeactivateAcceptSent
�MOTOROLA LTD. 2000 GPRS01: GPRS Architecture
FOR TRAINING PURPOSES ONLY
7–101
sgsnNumL3mmSessionDeactivateAcceptSent
Description
This statistic indicates the total number of L3MM Session Deactivate accepts sent.
Pegging
The statistic is pegged when the SGSN sends a Session Deactivation Accept to a MS.
Analysis
Reference
Usage
Network Planning
Congestion Identification
Quality of Service Issues
Basis
L3MM
Statistic
Statistic Type
Counter
Statistic Data
Integer ( 0 - 4,294,967,295 )
ISSUE 1 REVISION 2sgsnNumL3mmRaUpdateReqRcvd
�MOTOROLA LTD. 2000GPRS01: GPRS Architecture
FOR TRAINING PURPOSES ONLY
7–102
sgsnNumL3mmRaUpdateReqRcvd
Description
This statistic indicates the total number of L3MM RA Update requests received.
Pegging
The statistic is pegged when the SGSN receives a RA Update Request from a MS.
Analysis
Reference
Usage
Network Planning
Congestion Identification
Quality of Service Issues
Basis
L3MM
Statistic
Statistic Type
Counter
Statistic Data
Integer ( 0 - 4,294,967,295 )
ISSUE 1 REVISION 2 sgsnNumL3mmRaUpdateAcceptSent
�MOTOROLA LTD. 2000 GPRS01: GPRS Architecture
FOR TRAINING PURPOSES ONLY
7–103
sgsnNumL3mmRaUpdateAcceptSent
Description
This statistic indicates the total number of L3MM RA Update accepts sent.
Pegging
The statistic is pegged when the SGSN sends a RA Update Accept to a MS.
Analysis
Reference
Usage
Network Planning
Congestion Identification
Quality of Service Issues
Basis
L3MM
Statistic
Statistic Type
Counter
Statistic Data
Integer ( 0 - 4,294,967,295 )
ISSUE 1 REVISION 2sgsnNumL3mmRaUpdateRejectSent
�MOTOROLA LTD. 2000GPRS01: GPRS Architecture
FOR TRAINING PURPOSES ONLY
7–104
sgsnNumL3mmRaUpdateRejectSent
Description
This statistic indicates the total number of L3MM RA Update rejects sent.
Pegging
The statistic is pegged when the SGSN sends a RA Update Reject to a MS.
Analysis
Reference
Usage
Network Planning
Congestion Identification
Quality of Service Issues
Basis
L3MM
Statistic
Statistic Type
Counter
Statistic Data
Integer ( 0 - 4,294,967,295 )
ISSUE 1 REVISION 2 sgsnNumL3mmMsPagingReqSent
�MOTOROLA LTD. 2000 GPRS01: GPRS Architecture
FOR TRAINING PURPOSES ONLY
7–105
sgsnNumL3mmMsPagingReqSent
Description
This statistic indicates the total number of L3MM MS paging requests sent (not thenumber of paging PCUs, in case a page request needs to be sent to multiple PCUs).
Pegging
The statistic is pegged when the SGSN sends a MS Paging Request to a MS.
Analysis
Reference
Usage
Network Planning
Congestion Identification
Quality of Service Issues
Basis
L3MM
Statistic
Statistic Type
Counter
Statistic Data
Integer ( 0 - 4,294,967,295 )
ISSUE 1 REVISION 2sgsnNumL3mmSuccessfulPages
�MOTOROLA LTD. 2000GPRS01: GPRS Architecture
FOR TRAINING PURPOSES ONLY
7–106
sgsnNumL3mmSuccessfulPages
Description
This statistic indicates the total number of successful pages (where the paged MS issuccessfully located).
Pegging
Analysis
Reference
Usage
Network Planning
Congestion Identification
Quality of Service Issues
Basis
L3MM
Statistic
Statistic Type
Counter
Statistic Data
Integer ( 0 - 4,294,967,295 )
ISSUE 1 REVISION 2 sgsnCurrentNumGprsAttachedMS
�MOTOROLA LTD. 2000 GPRS01: GPRS Architecture
FOR TRAINING PURPOSES ONLY
7–107
sgsnCurrentNumGprsAttachedMS
Description
This statistic indicates the current number of GPRS attached MS.
Pegging
Analysis
Reference
Usage
Network Planning
Congestion Identification
Basis
Miscellaneous
Statistic
Statistic Type
Gauge
Statistic Data
Integer ( 0 - 4,294,967,295 )
ISSUE 1 REVISION 2sgsnCurrentNumActivePdpSession
�MOTOROLA LTD. 2000GPRS01: GPRS Architecture
FOR TRAINING PURPOSES ONLY
7–108
sgsnCurrentNumActivePdpSession
Description
This statistic indicates the current number of active PDP sessions.
Pegging
Analysis
Reference
Usage
Network Planning
Congestion Identification
Basis
Miscellaneous
Statistic
Statistic Type
Gauge
Statistic Data
Integer ( 0 - 4,294,967,295 )
ISSUE 1 REVISION 2 sgsnNumCells
�MOTOROLA LTD. 2000 GPRS01: GPRS Architecture
FOR TRAINING PURPOSES ONLY
7–109
sgsnNumCells
Description
This statistic indicates the total number of cells.
Pegging
Analysis
Reference
Usage
Network Planning
Congestion Identification
Basis
Miscellaneous
Statistic
Statistic Type
Gauge
Statistic Data
Integer ( 0 - 4,294,967,295 )
ISSUE 1 REVISION 2sgsnNumCells
�MOTOROLA LTD. 2000GPRS01: GPRS Architecture
FOR TRAINING PURPOSES ONLY
7–110
ISSUE 1 REVISION 2 sgsnNumBssgpDownLinkDataPacketsSent
�MOTOROLA LTD. 2000 GPRS01: GPRS Architecture
FOR TRAINING PURPOSES ONLY
7–111
sgsnNumBssgpDownLinkDataPacketsSent
Description
This BSSGP attribute indicates the total number of BSSGP data packets sent to the NSprotocol layer.
Pegging
The statistic is pegged each time the BSSGP protocol layer sends a data packet to theNS protocol layer.
Analysis
The statistic can be used in conjunction with sgsnNumBssgpDownLinkDataPacketsRcvd to show the SGSN data packet throughput in the downlink direction across theBSSGP protocol layer.
Reference
?
Usage
Network Planning
Congestion Identification
Loss Rates
Fault Finding
Basis
BSSGP
Statistic
Statistic Type
Counter
Statistic Data
Integer ( 0 - 4,294,967,295 )
ISSUE 1 REVISION 2sgsnNumBssgpDownLinkDataBytesSent
�MOTOROLA LTD. 2000GPRS01: GPRS Architecture
FOR TRAINING PURPOSES ONLY
7–112
sgsnNumBssgpDownLinkDataBytesSent
Description
This BSSGP attribute indicates the total number of BSSGP data bytes (including protocolheaders) sent to the NS protocol layer.
Pegging
The statistic is pegged each time the BSSGP protocol layer sends a data byte to the NSprotocol layer.
Analysis
The statistic can be used in conjunction with sgsnNumBssgpDownLinkDataBytesRcvd to show the SGSN data byte throughput in the downlink direction across theBSSGP protocol layer.
Reference
?
Usage
Network Planning
Congestion Identification
Loss Rates
Fault Finding
Basis
BSSGP
Statistic
Statistic Type
Counter
Statistic Data
Integer ( 0 - 4,294,967,295 )
ISSUE 1 REVISION 2 sgsnNumBssgpUpLinkDataPacketsRcvd
�MOTOROLA LTD. 2000 GPRS01: GPRS Architecture
FOR TRAINING PURPOSES ONLY
7–113
sgsnNumBssgpUpLinkDataPacketsRcvd
Description
This BSSGP attribute indicates the total number of BSSGP data packets received fromNS protocol layer.
Pegging
The statistic is pegged each time the BSSGP protocol layer receives a data packet fromthe NS protocol layer.
Analysis
The statistic can be used in conjunction with sgsnNumBssgpUpLinkDataPacketsSentto show the SGSN data packet throughput in the uplink direction across the BSSGPprotocol layer.
Reference
?
Usage
Network Planning
Congestion Identification
Loss Rates
Fault Finding
Basis
BSSGP
Statistic
Statistic Type
Counter
Statistic Data
Integer ( 0 - 4,294,967,295 )
ISSUE 1 REVISION 2sgsnNumBssgpUpLinkDataBytesRcvd
�MOTOROLA LTD. 2000GPRS01: GPRS Architecture
FOR TRAINING PURPOSES ONLY
7–114
sgsnNumBssgpUpLinkDataBytesRcvd
Description
This BSSGP attribute indicates the total number of BSSGP data bytes (including protocolheaders) received from NS protocol layer.
Pegging
The statistic is pegged each time the BSSGP protocol layer receives a data byte from theNS protocol layer.
Analysis
The statistic can be used in conjunction with sgsnNumBssgpUpLinkDataBytesSent toshow the SGSN data byte throughput in the uplink direction across the BSSGP protocollayer.
Reference
?
Usage
Network Planning
Congestion Identification
Loss Rates
Fault Finding
Basis
BSSGP
Statistic
Statistic Type
Counter
Statistic Data
Integer ( 0 - 4,294,967,295 )
ISSUE 1 REVISION 2 sgsnNumBssgpUpLinkDataPacketsSent
�MOTOROLA LTD. 2000 GPRS01: GPRS Architecture
FOR TRAINING PURPOSES ONLY
7–115
sgsnNumBssgpUpLinkDataPacketsSent
Description
This BSSGP attribute indicates the total number of BSSGP data packets sent to the LLCprotocol layer.
Pegging
The statistic is pegged each time the BSSGP protocol layer sends a data packet to theLLC protocol layer.
Analysis
The statistic can be used in conjunction with sgsnNumBssgpUpLinkDataPacketsRcvdto show the SGSN data packet throughput in the uplink direction across the BSSGPprotocol layer.
Reference
?
Usage
Network Planning
Congestion Identification
Loss Rates
Fault Finding
Basis
BSSGP
Statistic
Statistic Type
Counter
Statistic Data
Integer ( 0 - 4,294,967,295 )
ISSUE 1 REVISION 2sgsnNumBssgpUpLinkDataBytesSent
�MOTOROLA LTD. 2000GPRS01: GPRS Architecture
FOR TRAINING PURPOSES ONLY
7–116
sgsnNumBssgpUpLinkDataBytesSent
Description
This BSSGP attribute indicates the total number of BSSGP data bytes (including protocolheaders) sent to the LLC protocol layer.
Pegging
The statistic is pegged each time the BSSGP protocol layer sends a data byte to the LLCprotocol layer.
Analysis
The statistic can be used in conjunction with sgsnNumBssgpUpLinkDataBytesRcvd toshow the SGSN data byte throughput in the uplink direction across the BSSGP protocollayer.
Reference
?
Usage
Network Planning
Congestion Identification
Loss Rates
Fault Finding
Basis
BSSGP
Statistic
Statistic Type
Counter
Statistic Data
Integer ( 0 - 4,294,967,295 )
ISSUE 1 REVISION 2 sgsnNumBssgpDownLinkDataPacketsRcvd
�MOTOROLA LTD. 2000 GPRS01: GPRS Architecture
FOR TRAINING PURPOSES ONLY
7–117
sgsnNumBssgpDownLinkDataPacketsRcvd
Description
This BSSGP attribute indicates the total number of BSSGP data packets received fromthe LLC protocol layer.
Pegging
The statistic is pegged each time the BSSGP protocol layer receives a data packet fromthe LLC protocol layer.
Analysis
The statistic can be used in conjunction with sgsnNumBssgpDownLinkDataPacketsSent to show the SGSN data packet throughput in the downlink direction across theBSSGP protocol layer.
Reference
?
Usage
Network Planning
Congestion Identification
Loss Rates
Fault Finding
Basis
BSSGP
Statistic
Statistic Type
Counter
Statistic Data
Integer ( 0 - 4,294,967,295 )
ISSUE 1 REVISION 2sgsnNumBssgpDownLinkDataBytesRcvd
�MOTOROLA LTD. 2000GPRS01: GPRS Architecture
FOR TRAINING PURPOSES ONLY
7–118
sgsnNumBssgpDownLinkDataBytesRcvd
Description
This BSSGP attribute indicates the total number of BSSGP data bytes (including protocolheaders) received from the LLC protocol layer.
Pegging
The statistic is pegged each time the BSSGP protocol layer receives a data byte from theLLC protocol layer.
Analysis
The statistic can be used in conjunction with sgsnNumBssgpDownLinkDataBytesSentto show the SGSN data byte throughput in the downlink direction across the BSSGPprotocol layer.
Reference
?
Usage
Network Planning
Congestion Identification
Loss Rates
Fault Finding
Basis
BSSGP
Statistic
Statistic Type
Counter
Statistic Data
Integer ( 0 - 4,294,967,295 )
ISSUE 1 REVISION 2 sgsnNumBssgpUpLinkDataPacketsDropped
�MOTOROLA LTD. 2000 GPRS01: GPRS Architecture
FOR TRAINING PURPOSES ONLY
7–119
sgsnNumBssgpUpLinkDataPacketsDropped
Description
This BSSGP attribute indicates the total number of BSSGP data packets dropped in theuplink direction.
Pegging
The statistic is pegged each time the BSSGP protocol layer drops a data packet receivedfrom the NS protocol layer.
Analysis
The statistic can be used in conjunction with BSSGP uplink throughput statistics toidentify uplink loss rates across the BSSGP protocol layer.
Reference
?
Usage
Loss Rates
Fault Finding
Basis
BSSGP
Statistic
Statistic Type
Counter
Statistic Data
Integer ( 0 - 4,294,967,295 )
ISSUE 1 REVISION 2sgsnNumBssgpDownLinkDataPacketsDropped
�MOTOROLA LTD. 2000GPRS01: GPRS Architecture
FOR TRAINING PURPOSES ONLY
7–120
sgsnNumBssgpDownLinkDataPacketsDropped
Description
This BSSGP attribute indicates the total number of BSSGP data packets dropped in thedownlink direction.
Pegging
The statistic is pegged each time the BSSGP protocol layer drops a data packet receivedfrom the LLC protocol layer.
Analysis
The statistic can be used in conjunction with BSSGP downlink throughput statistics toidentify downlink loss rates across the BSSGP protocol layer.
Reference
?
Usage
Loss Rates
Fault Finding
Basis
BSSGP
Statistic
Statistic Type
Counter
Statistic Data
Integer ( 0 - 4,294,967,295 )
ISSUE 1 REVISION 2 sgsnNumNsDownLinkDataPacketsRcvd
�MOTOROLA LTD. 2000 GPRS01: GPRS Architecture
FOR TRAINING PURPOSES ONLY
7–121
sgsnNumNsDownLinkDataPacketsRcvd
Description
This statistic indicates the total number of NS data packets received from the BSSGPprotocol layer.
Pegging
The statistic is pegged each time the NS protocol layer receives a data packet from theBSSGP protocol layer.
Analysis
The statistic can be used in conjunction with sgsnNumNsDownLinkDataPacketsSentto show the SGSN data packet throughput in the downlink direction across the NSprotocol layer.
Reference
?
Usage
Network Planning
Congestion Identification
Loss Rates
Fault Finding
Basis
NS
Statistic
Statistic Type
Counter
Statistic Data
Integer ( 0 - 4,294,967,295 )
ISSUE 1 REVISION 2sgsnNumNsDownLinkDataBytesRcvd
�MOTOROLA LTD. 2000GPRS01: GPRS Architecture
FOR TRAINING PURPOSES ONLY
7–122
sgsnNumNsDownLinkDataBytesRcvd
Description
This statistic indicates the total number of NS data bytes (including protocol headers)received from the BSSGP protocol layer.
Pegging
The statistic is pegged each time the NS protocol layer receives a data byte from theBSSGP protocol layer.
Analysis
The statistic can be used in conjunction with sgsnNumNsDownLinkDataBytesSent toshow the SGSN data byte throughput in the downlink direction across the NS protocollayer.
Reference
?
Usage
Network Planning
Congestion Identification
Loss Rates
Fault Finding
Basis
NS
Statistic
Statistic Type
Counter
Statistic Data
Integer ( 0 - 4,294,967,295 )
ISSUE 1 REVISION 2 sgsnNumNsUpLinkDataPacketsSent
�MOTOROLA LTD. 2000 GPRS01: GPRS Architecture
FOR TRAINING PURPOSES ONLY
7–123
sgsnNumNsUpLinkDataPacketsSent
Description
This statistic indicates the total number of NS data packets sent to the BSSGP protocollayer.
Pegging
The statistic is pegged each time the NS protocol layer sends a data packet to theBSSGP protocol layer.
Analysis
The statistic can be used in conjunction with sgsnNumNsUpLinkDataPacketsRcvd toshow the SGSN data packet throughput in the uplink direction across the NS protocollayer.
Reference
?
Usage
Network Planning
Congestion Identification
Loss Rates
Fault Finding
Basis
NS
Statistic
Statistic Type
Counter
Statistic Data
Integer ( 0 - 4,294,967,295 )
ISSUE 1 REVISION 2sgsnNumNsUpLinkDataBytesSent
�MOTOROLA LTD. 2000GPRS01: GPRS Architecture
FOR TRAINING PURPOSES ONLY
7–124
sgsnNumNsUpLinkDataBytesSent
Description
This statistic indicates the total number of NS data bytes (including protocol headers)sent to the BSSGP protocol layer.
Pegging
The statistic is pegged each time the NS protocol layer sends a data byte to the BSSGPprotocol layer.
Analysis
The statistic can be used in conjunction with sgsnNumNsUpLinkDataBytesRcvd toshow the SGSN data byte throughput in the uplink direction across the NS protocol layer.
Reference
?
Usage
Network Planning
Congestion Identification
Loss Rates
Fault Finding
Basis
NS
Statistic
Statistic Type
Counter
Statistic Data
Integer ( 0 - 4,294,967,295 )
ISSUE 1 REVISION 2 sgsnNumNsUpLinkDataPacketsRcvd
�MOTOROLA LTD. 2000 GPRS01: GPRS Architecture
FOR TRAINING PURPOSES ONLY
7–125
sgsnNumNsUpLinkDataPacketsRcvd
Description
This statistic indicates the total number of NS data packets received from the FR protocollayer.
Pegging
The statistic is pegged each time the NS protocol layer receives a data packet from theFR protocol layer.
Analysis
The statistic can be used in conjunction with sgsnNumNsUpLinkDataPacketsSent toshow the SGSN data packet throughput in the uplink direction across the NS protocollayer.
Reference
?
Usage
Network Planning
Congestion Identification
Loss Rates
Fault Finding
Basis
NS
Statistic
Statistic Type
Counter
Statistic Data
Integer ( 0 - 4,294,967,295 )
ISSUE 1 REVISION 2sgsnNumNsUpLinkDataBytesRcvd
�MOTOROLA LTD. 2000GPRS01: GPRS Architecture
FOR TRAINING PURPOSES ONLY
7–126
sgsnNumNsUpLinkDataBytesRcvd
Description
This statistic indicates the total number of NS data bytes (including protocol headers)received from the FR protocol layer.
Pegging
The statistic is pegged each time the NS protocol layer receives a data byte from the FRprotocol layer.
Analysis
The statistic can be used in conjunction with sgsnNumNsUpLinkDataBytesSent toshow the SGSN data byte throughput in the uplink direction across the NS protocol layer.
Reference
?
Usage
Network Planning
Congestion Identification
Loss Rates
Fault Finding
Basis
NS
Statistic
Statistic Type
Counter
Statistic Data
Integer ( 0 - 4,294,967,295 )
ISSUE 1 REVISION 2 sgsnNumNsDownLinkDataPacketsSent
�MOTOROLA LTD. 2000 GPRS01: GPRS Architecture
FOR TRAINING PURPOSES ONLY
7–127
sgsnNumNsDownLinkDataPacketsSent
Description
This statistic indicates the total number of NS data packets sent to the FR protocol layer.
Pegging
The statistic is pegged each time the NS protocol layer sends a data packet to the FRprotocol layer.
Analysis
The statistic can be used in conjunction with sgsnNumNsDownLinkDataPacketsRcvdto show the SGSN data packet throughput in the downlink direction across the NSprotocol layer.
Reference
?
Usage
Network Planning
Congestion Identification
Loss Rates
Fault Finding
Basis
NS
Statistic
Statistic Type
Counter
Statistic Data
Integer ( 0 - 4,294,967,295 )
ISSUE 1 REVISION 2sgsnNumNsDownLinkDataBytesSent
�MOTOROLA LTD. 2000GPRS01: GPRS Architecture
FOR TRAINING PURPOSES ONLY
7–128
sgsnNumNsDownLinkDataBytesSent
Description
This statistic indicates the total number of NS data bytes (including protocol headers)sent to the FR protocol layer.
Pegging
The statistic is pegged each time the NS protocol layer sends a data byte to the FRprotocol layer.
Analysis
The statistic can be used in conjunction with sgsnNumNsDownLinkDataBytesRcvd toshow the SGSN data byte throughput in the downlink direction across the NS protocollayer.
Reference
?
Usage
Network Planning
Congestion Identification
Loss Rates
Fault Finding
Basis
NS
Statistic
Statistic Type
Counter
Statistic Data
Integer ( 0 - 4,294,967,295 )
ISSUE 1 REVISION 2 sgsnNumNsUpLinkDataPacketsDropped
�MOTOROLA LTD. 2000 GPRS01: GPRS Architecture
FOR TRAINING PURPOSES ONLY
7–129
sgsnNumNsUpLinkDataPacketsDropped
Description
This statistic indicates the total number of NS data packets dropped in the uplinkdirection.
Pegging
The statistic is pegged each time the NS protocol layer drops a data packet receivedfrom the FR protocol layer.
Analysis
The statistic can be used in conjunction with NS uplink throughput statistics to identifyuplink loss rates across the NS protocol layer.
Reference
?
Usage
Loss Rates
Fault Finding
Basis
NS
Statistic
Statistic Type
Counter
Statistic Data
Integer ( 0 - 4,294,967,295 )
ISSUE 1 REVISION 2sgsnNumNsDownLinkDataPacketsDropped
�MOTOROLA LTD. 2000GPRS01: GPRS Architecture
FOR TRAINING PURPOSES ONLY
7–130
sgsnNumNsDownLinkDataPacketsDropped
Description
This statistic indicates the total number of NS data packets dropped in the downlinkdirection.
Pegging
The statistic is pegged each time the NS protocol layer drops a data packet receivedfrom the BSSGP protocol layer.
Analysis
The statistic can be used in conjunction with NS downlink throughput statistics to identifydownlink loss rates across the NS protocol layer.
Reference
?
Usage
Loss Rates
Fault Finding
Basis
GTP Gn
Statistic
Statistic Type
Counter
Statistic Data
Integer ( 0 - 4,294,967,295 )
ISSUE 1 REVISION 2 FR stats
�MOTOROLA LTD. 2000 GPRS01: GPRS Architecture
FOR TRAINING PURPOSES ONLY
7–131
FR statsDetails of Fr statistics attributes not available at this time.
ISSUE 1 REVISION 2sgsnNumL3mmAttachReqRcvd
�MOTOROLA LTD. 2000GPRS01: GPRS Architecture
FOR TRAINING PURPOSES ONLY
7–132
sgsnNumL3mmAttachReqRcvd
Description
This statistic indicates the total number of L3MM Attach Requests received.
Pegging
The statistic is pegged when the SGSN receives an Attach Request from a MS.
Analysis
?
Reference
?
Usage
Network Planning
Congestion Identification
Quality of Service Issues
Basis
L3MM
Statistic
Statistic Type
Counter
Statistic Data
Integer ( 0 - 4,294,967,295 )
ISSUE 1 REVISION 2 sgsnNumL3mmAttachAcceptSent
�MOTOROLA LTD. 2000 GPRS01: GPRS Architecture
FOR TRAINING PURPOSES ONLY
7–133
sgsnNumL3mmAttachAcceptSent
Description
This statistic indicates the total number of L3MM Attach Accepts sent.
Pegging
The statistic is pegged when the SGSN sends an Attach Accept to a MS.
Analysis
?
Reference
?
Usage
Network Planning
Congestion Identification
Quality of Service Issues
Basis
L3MM
Statistic
Statistic Type
Counter
Statistic Data
Integer ( 0 - 4,294,967,295 )
ISSUE 1 REVISION 2sgsnNumL3mmAttachRejectSent
�MOTOROLA LTD. 2000GPRS01: GPRS Architecture
FOR TRAINING PURPOSES ONLY
7–134
sgsnNumL3mmAttachRejectSent
Description
This statistic indicates the total number of L3MM Attach Rejects sent.
Pegging
The statistic is pegged when the SGSN sends an Attach Reject to a MS.
Analysis
?
Reference
?
Usage
Network Planning
Congestion Identification
Quality of Service Issues
Basis
L3MM
Statistic
Statistic Type
Counter
Statistic Data
Integer ( 0 - 4,294,967,295 )
ISSUE 1 REVISION 2 sgsnNumL3mmDetachReqRcvd
�MOTOROLA LTD. 2000 GPRS01: GPRS Architecture
FOR TRAINING PURPOSES ONLY
7–135
sgsnNumL3mmDetachReqRcvd
Description
This statistic indicates the total number of L3MM Detach Requests received.
Pegging
The statistic is pegged when the SGSN receives a Detach Request from a MS.
Analysis
?
Reference
?
Usage
Network Planning
Congestion Identification
Quality of Service Issues
Basis
L3MM
Statistic
Statistic Type
Counter
Statistic Data
Integer ( 0 - 4,294,967,295 )
ISSUE 1 REVISION 2sgsnNumL3mmDetachAcceptSent
�MOTOROLA LTD. 2000GPRS01: GPRS Architecture
FOR TRAINING PURPOSES ONLY
7–136
sgsnNumL3mmDetachAcceptSent
Description
This statistic indicates the total number of L3MM Detach Accepts sent.
Pegging
The statistic is pegged when the SGSN sends a Detach Request to a MS.
Analysis
?
Reference
?
Usage
Network Planning
Congestion Identification
Quality of Service Issues
Basis
L3MM
Statistic
Statistic Type
Counter
Statistic Data
Integer ( 0 - 4,294,967,295 )
ISSUE 1 REVISION 2 sgsnNumL3mmSessionActivateReqRcvd
�MOTOROLA LTD. 2000 GPRS01: GPRS Architecture
FOR TRAINING PURPOSES ONLY
7–137
sgsnNumL3mmSessionActivateReqRcvd
Description
This statistic indicates the total number of L3MM Session Activate requests received.
Pegging
The statistic is pegged when the SGSN receives a Session Activation Request from aMS.
Analysis
?
Reference
?
Usage
Network Planning
Congestion Identification
Quality of Service Issues
Basis
L3MM
Statistic
Statistic Type
Counter
Statistic Data
Integer ( 0 - 4,294,967,295 )
ISSUE 1 REVISION 2sgsnNumL3mmSessionActivateAcceptSent
�MOTOROLA LTD. 2000GPRS01: GPRS Architecture
FOR TRAINING PURPOSES ONLY
7–138
sgsnNumL3mmSessionActivateAcceptSent
Description
This statistic indicates the total number of L3MM Session Activate accepts sent.
Pegging
The statistic is pegged when the SGSN sends a Session Activation Accept to a MS.
Analysis
?
Reference
?
Usage
Network Planning
Congestion Identification
Quality of Service Issues
Basis
L3MM
Statistic
Statistic Type
Counter
Statistic Data
Integer ( 0 - 4,294,967,295 )
ISSUE 1 REVISION 2 sgsnNumL3mmSessionActivateRejectSent
�MOTOROLA LTD. 2000 GPRS01: GPRS Architecture
FOR TRAINING PURPOSES ONLY
7–139
sgsnNumL3mmSessionActivateRejectSent
Description
This statistic indicates the total number of L3MM Session Activate rejects sent.
Pegging
The statistic is pegged when the SGSN sends a Session Activation Reject to a MS.
Analysis
?
Reference
?
Usage
Network Planning
Congestion Identification
Quality of Service Issues
Basis
L3MM
Statistic
Statistic Type
Counter
Statistic Data
Integer ( 0 - 4,294,967,295 )
ISSUE 1 REVISION 2sgsnNumL3mmSessionDeactivateReqRcvd
�MOTOROLA LTD. 2000GPRS01: GPRS Architecture
FOR TRAINING PURPOSES ONLY
7–140
sgsnNumL3mmSessionDeactivateReqRcvd
Description
This statistic indicates the total number of L3MM Session Deactivate requests received.
Pegging
The statistic is pegged when the SGSN receives a Session Deactivation Request from aMS.
Analysis
?
Reference
?
Usage
Network Planning
Congestion Identification
Quality of Service Issues
Basis
L3MM
Statistic
Statistic Type
Counter
Statistic Data
Integer ( 0 - 4,294,967,295 )
ISSUE 1 REVISION 2 sgsnNumL3mmSessionDeactivateAcceptSent
�MOTOROLA LTD. 2000 GPRS01: GPRS Architecture
FOR TRAINING PURPOSES ONLY
7–141
sgsnNumL3mmSessionDeactivateAcceptSent
Description
This statistic indicates the total number of L3MM Session Deactivate accepts sent.
Pegging
The statistic is pegged when the SGSN sends a Session Deactivation Accept to a MS.
Analysis
?
Reference
?
Usage
Network Planning
Congestion Identification
Quality of Service Issues
Basis
L3MM
Statistic
Statistic Type
Counter
Statistic Data
Integer ( 0 - 4,294,967,295 )
ISSUE 1 REVISION 2sgsnNumL3mmRaUpdateReqRcvd
�MOTOROLA LTD. 2000GPRS01: GPRS Architecture
FOR TRAINING PURPOSES ONLY
7–142
sgsnNumL3mmRaUpdateReqRcvd
Description
This statistic indicates the total number of L3MM RA Update requests received.
Pegging
The statistic is pegged when the SGSN receives a RA Update Request from a MS.
Analysis
?
Reference
?
Usage
Network Planning
Congestion Identification
Quality of Service Issues
Basis
L3MM
Statistic
Statistic Type
Counter
Statistic Data
Integer ( 0 - 4,294,967,295 )
ISSUE 1 REVISION 2 sgsnNumL3mmRaUpdateAcceptSent
�MOTOROLA LTD. 2000 GPRS01: GPRS Architecture
FOR TRAINING PURPOSES ONLY
7–143
sgsnNumL3mmRaUpdateAcceptSent
Description
This statistic indicates the total number of L3MM RA Update accepts sent.
Pegging
The statistic is pegged when the SGSN sends a RA Update Accept to a MS.
Analysis
?
Reference
?
Usage
Network Planning
Congestion Identification
Quality of Service Issues
Basis
L3MM
Statistic
Statistic Type
Counter
Statistic Data
Integer ( 0 - 4,294,967,295 )
ISSUE 1 REVISION 2sgsnNumL3mmRaUpdateRejectSent
�MOTOROLA LTD. 2000GPRS01: GPRS Architecture
FOR TRAINING PURPOSES ONLY
7–144
sgsnNumL3mmRaUpdateRejectSent
Description
This statistic indicates the total number of L3MM RA Update rejects sent.
Pegging
The statistic is pegged when the SGSN sends a RA Update Reject to a MS.
Analysis
?
Reference
?
Usage
Network Planning
Congestion Identification
Quality of Service Issues
Basis
L3MM
Statistic
Statistic Type
Counter
Statistic Data
Integer ( 0 - 4,294,967,295 )
ISSUE 1 REVISION 2 sgsnNumL3mmMsPagingReqSent
�MOTOROLA LTD. 2000 GPRS01: GPRS Architecture
FOR TRAINING PURPOSES ONLY
7–145
sgsnNumL3mmMsPagingReqSent
Description
This statistic indicates the total number of L3MM MS paging requests sent (not thenumber of paging PCUs, in case a page request needs to be sent to multiple PCUs).
Pegging
The statistic is pegged when the SGSN sends a MS Paging Request to a MS.
Analysis
?
Reference
?
Usage
Network Planning
Congestion Identification
Quality of Service Issues
Basis
L3MM
Statistic
Statistic Type
Counter
Statistic Data
Integer ( 0 - 4,294,967,295 )
ISSUE 1 REVISION 2sgsnNumL3mmSuccessfulPages
�MOTOROLA LTD. 2000GPRS01: GPRS Architecture
FOR TRAINING PURPOSES ONLY
7–146
sgsnNumL3mmSuccessfulPages
Description
This statistic indicates the total number of successful pages (where the paged MS issuccessfully located).
Pegging
?
Analysis
?
Reference
?
Usage
Network Planning
Congestion Identification
Quality of Service Issues
Basis
L3MM
Statistic
Statistic Type
Counter
Statistic Data
Integer ( 0 - 4,294,967,295 )
ISSUE 1 REVISION 2 sgsnCurrentNumGprsAttachedMS
�MOTOROLA LTD. 2000 GPRS01: GPRS Architecture
FOR TRAINING PURPOSES ONLY
7–147
sgsnCurrentNumGprsAttachedMS
Description
This statistic indicates the current number of GPRS attached MS.
Pegging
?
Analysis
?
Reference
?
Usage
Network Planning
Congestion Identification
Basis
Miscellaneous
Statistic
Statistic Type
Counter
Statistic Data
Integer ( 0 - 4,294,967,295 )
ISSUE 1 REVISION 2sgsnCurrentNumActivePdpSession
�MOTOROLA LTD. 2000GPRS01: GPRS Architecture
FOR TRAINING PURPOSES ONLY
7–148
sgsnCurrentNumActivePdpSession
Description
This statistic indicates the current number of active PDP sessions.
Pegging
?
Analysis
?
Reference
?
Usage
Network Planning
Congestion Identification
Basis
Miscellaneous
Statistic
Statistic Type
Counter
Statistic Data
Integer ( 0 - 4,294,967,295 )
ISSUE 1 REVISION 2 sgsnNumCells
�MOTOROLA LTD. 2000 GPRS01: GPRS Architecture
FOR TRAINING PURPOSES ONLY
7–149
sgsnNumCells
Description
This statistic indicates the total number of cells.
Pegging
?
Analysis
?
Reference
?
Usage
Network Planning
Congestion Identification
Basis
Miscellaneous
Statistic
Statistic Type
Counter
Statistic Data
Integer ( 0 - 4,294,967,295 )
ISSUE 1 REVISION 2sgsnNumCells
�MOTOROLA LTD. 2000GPRS01: GPRS Architecture
FOR TRAINING PURPOSES ONLY
7–150
�MOTOROLA LTD. 2000 GPRS01: GPRS Architecture
FOR TRAINING PURPOSES ONLY
i
Chapter 8
GGSN statistics attributes
ISSUE 1 REVISION 2
�MOTOROLA LTD. 2000 GPRS01: GPRS Architecture
FOR TRAINING PURPOSES ONLY
iii
Chapter 3GGSN statistics attributes i. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Introduction to Cisco GGSN statistics 3–1. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Purpose of this chapter 3–1. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . How this chapter is structured 3–1. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . GGSN OID structure 3–2. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Attributes Tables 3–2. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
cgprsGtpCurRxPacketQueueSize 3–5. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
cgprsGtpCurActivatedPDPcontextsCount 3–6. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
cgprsGtpCurUnexpectedRxGpduCount 3–7. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
cgprsGtpCurRejectedPDPContextActivationCount 3–8. . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
cgprsGtpTotalPktsDropped 3–9. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
cgprsGtpDroppedPktsTimeFrame 3–10. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
cgprsGtpDroppedPktsCount 3–11. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
cgprsGtpCurMeanThroughputForPremiumQos 3–12. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
cgprsGtpCurMeanThroughputForNormalQos 3–13. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
cgprsGtpCurMeanThroughputForBestEffortQos 3–14. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
cgprsGtpCurGSNBandwidthResourceUsed 3–15. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
cgprsGtpGSNTable 3–16. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
cgprsGtpGSNEntry 3–18. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
cgprsGtpGSNid 3–19. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
cgprsGtpGSNEchoFailedNotificationCount 3–20. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
cgprsGtpTotalNumAllocIpAddr 3–21. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
cgprsGtpChargingMsgCount 3–22. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
cgprsGtpLastGSNidNoRespToEcho 3–23. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
cgprsGtpGSNidOfLastUnexpectedPDPContext 3–24. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
cgprsGtpTIDOfLastUnexpectedPDPContext 3–25. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
cgprsGtpRejectReasonOfLastUnexpectedPDPContext 3–26. . . . . . . . . . . . . . . . . . . . . . . . . .
cgprsGtpNumAllocIpAddrTable 3–27. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
cgprsGtpNumAllocIpAddrEntry 3–28. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
cgprsGtpNumAllocIpAddr 3–29. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
ISSUE 1 REVISION 2 Introduction to Cisco GGSN statistics
�MOTOROLA LTD. 2000 GPRS01: GPRS Architecture
FOR TRAINING PURPOSES ONLY
8–1
Introduction to Cisco GGSN statistics
Purpose of thischapter
This chapter describes statistical measurements generated by the Cisco GGSN elementof the GSN, in response to monitored network and system events.
How this chapteris structured
This chapters contains SGSN statistics information, using the following structure topresent that information:
� An introduction to the chapter and the chapter structure.
� Details of the MIB structure identifying the available SGSN objects.
� Attributes tables detailing the statistics attributes available for each SGSN object.
� Data sheets containing the attribute information of the individual statistics identifiedin the attributes tables.
This information may be structured differently for training purposes
NOTE
ISSUE 1 REVISION 2Introduction to Cisco GGSN statistics
�MOTOROLA LTD. 2000GPRS01: GPRS Architecture
FOR TRAINING PURPOSES ONLY
8–2
GGSN OIDstructure
The following illustration identifies the Cisco GGSN OID structure, with the emphasis onthe performance management branch of the structure.
Notifications
ciscoGprsGtp
(1) Objects
(2)
(1)
(2)
Config
Stats(1) General
(2) Ggsn
Figure 8-1 Cisco GGSN OID structure
Attributes Tables
Details of the attributes available for each performance management object can be foundin the following tables:
General Table 8-1
General GSN table Table 8-2
Ggsn Table 8-3
Ggsn NumAllocIpAddr table
ISSUE 1 REVISION 2 Introduction to Cisco GGSN statistics
�MOTOROLA LTD. 2000 GPRS01: GPRS Architecture
FOR TRAINING PURPOSES ONLY
8–3
Cisco GGSN General statistics
The following table details the statistics attributes available for cgprsGtpGeneralStats :
Table 8-1 GGSN General statistics attributes
OIDnumber
attribute
1 cgprsGtpCurRxPacketQueueSize
2 cgprsGtpCurActivatedPDPcontextsCount
3 cgprsGtpCurUnexpectedRxGpduCount
4 cgprsGtpCurRejectedPDPContextActivationCount
5 cgprsGtpTotalPktsDropped
6 cgprsGtpDroppedPktsTimeFrame
7 cgprsGtpDroppedPktsCount
8 cgprsGtpCurMeanThroughputForPremiumQos
9 cgprsGtpCurMeanThroughputForNormalQos
10 cgprsGtpCurMeanThroughputForBestEffortQos
11 cgprsGtpCurGSNBandwidthResourceUsed
Cisco GGSN General GSN table statistics
The following table details the statistics attributes available for cgprsGtpGeneralStats :
Table 8-2 GGSN General GSN table statistics attributes
OIDnumber
attribute
1 cgprsGtpGSNid
2 cgprsGtpGSNEchoFailedNotificationCount
ISSUE 1 REVISION 2Introduction to Cisco GGSN statistics
�MOTOROLA LTD. 2000GPRS01: GPRS Architecture
FOR TRAINING PURPOSES ONLY
8–4
Cisco GGSN statistics
The following table details the statistics attributes available for cgprsGtpGgsnStats :
Table 8-3 GGSN statistics attributes
OIDnumber
attribute
1 cgprsGtpTotalNumAllocIpAddr
2 cgprsGtpChargingMsgCount
3 cgprsGtpLastGSNidNoRespToEcho
4 cgprsGtpGSNidOfLastUnexpectedPDPContext
5 cgprsGtpTIDOfLastUnexpectedPDPContext
6 cgprsGtpRejectReasonOfLastUnexpectedPDPContext
Cisco GGSN NumAllocIpAddr table statistics
The following table details the statistics attributes available for cgprsGtpGgsnStats :
Table 8-4 GGSN NumAllocIpAddr table statistics attributes
OIDnumber
attribute
1 cgprsGtpNumAllocIpAddr
ISSUE 1 REVISION 2 cgprsGtpCurRxPacketQueueSize
�MOTOROLA LTD. 2000 GPRS01: GPRS Architecture
FOR TRAINING PURPOSES ONLY
8–5
cgprsGtpCurRxPacketQueueSize
Description
The current size of the Rx Packet Queue on the GSN node (for data received from theAPN, on the Gi interface).
Pegging
?
Analysis
?
Reference
?
Usage
?
Basis
GTP
Statistic
Statistic Type
Gauge 32
Statistic Data
packets
ISSUE 1 REVISION 2cgprsGtpCurActivatedPDPcontextsCount
�MOTOROLA LTD. 2000GPRS01: GPRS Architecture
FOR TRAINING PURPOSES ONLY
8–6
cgprsGtpCurActivatedPDPcontextsCount
Description
The current number of PDP contexts established on the GSN node.
Pegging
?
Analysis
?
Reference
?
Usage
?
Basis
GTP
Statistic
Statistic Type
Gauge 32
Statistic Data
PDP contexts
ISSUE 1 REVISION 2 cgprsGtpCurUnexpectedRxGpduCount
�MOTOROLA LTD. 2000 GPRS01: GPRS Architecture
FOR TRAINING PURPOSES ONLY
8–7
cgprsGtpCurUnexpectedRxGpduCount
Description
The total number of G–PDUs received from a SGSN for a non–existing or an inactivePDP context since system startup.
Pegging
?
Analysis
?
Reference
?
Usage
?
Basis
GTP
Statistic
Statistic Type
Counter
Statistic Data
PDUs
ISSUE 1 REVISION 2cgprsGtpCurRejectedPDPContextActivationCount
�MOTOROLA LTD. 2000GPRS01: GPRS Architecture
FOR TRAINING PURPOSES ONLY
8–8
cgprsGtpCurRejectedPDPContextActivationCount
Description
The total number of Rejected PDP Context activation, due to an overload or otherabnormal conditions since system startup.
Pegging
?
Analysis
?
Reference
?
Usage
?
Basis
GTP
Statistic
Statistic Type
Counter
Statistic Data
PDP contexts
ISSUE 1 REVISION 2 cgprsGtpTotalPktsDropped
�MOTOROLA LTD. 2000 GPRS01: GPRS Architecture
FOR TRAINING PURPOSES ONLY
8–9
cgprsGtpTotalPktsDropped
Description
Total number of packets dropped due to unknown GTP header, since the system wentup.
Pegging
?
Analysis
?
Reference
?
Usage
Basis
GTP
Statistic
Statistic Type
Counter
Statistic Data
packets
ISSUE 1 REVISION 2cgprsGtpDroppedPktsTimeFrame
�MOTOROLA LTD. 2000GPRS01: GPRS Architecture
FOR TRAINING PURPOSES ONLY
8–10
cgprsGtpDroppedPktsTimeFrame
Description
The time frame within which the number of GTP packets, defined bycgprsGtpDroppedPktsCount, are dropped.
Pegging
?
Analysis
?
Reference
?
Usage
?
Basis
GTP
Statistic
Statistic Type
Integer
Statistic Data
( –2147483648..2147483647 )
ISSUE 1 REVISION 2 cgprsGtpDroppedPktsCount
�MOTOROLA LTD. 2000 GPRS01: GPRS Architecture
FOR TRAINING PURPOSES ONLY
8–11
cgprsGtpDroppedPktsCount
Description
The number of packets dropped by GTP within cgprsGtpDroppedPktsTimeFrame.
Pegging
?
Analysis
?
Reference
?
Usage
?
Basis
GTP
Statistic
Statistic Type
Counter
Statistic Data
?
ISSUE 1 REVISION 2cgprsGtpCurMeanThroughputForPremiumQos
�MOTOROLA LTD. 2000GPRS01: GPRS Architecture
FOR TRAINING PURPOSES ONLY
8–12
cgprsGtpCurMeanThroughputForPremiumQos
Description
The mean throughput for premium class QOS users on the GSN.
Pegging
?
Analysis
?
Reference
?
Usage
?
Basis
GTP
Statistic
Statistic Type
Gauge 32
Statistic Data
bits/sec
ISSUE 1 REVISION 2 cgprsGtpCurMeanThroughputForNormalQos
�MOTOROLA LTD. 2000 GPRS01: GPRS Architecture
FOR TRAINING PURPOSES ONLY
8–13
cgprsGtpCurMeanThroughputForNormalQos
Description
The mean throughput for normal class QOS users on the GSN.
Pegging
?
Analysis
?
Reference
?
Usage
?
Basis
GTP
Statistic
Statistic Type
Gauge 32
Statistic Data
bits/sec
ISSUE 1 REVISION 2cgprsGtpCurMeanThroughputForBestEffortQos
�MOTOROLA LTD. 2000GPRS01: GPRS Architecture
FOR TRAINING PURPOSES ONLY
8–14
cgprsGtpCurMeanThroughputForBestEffortQos
Description
The mean throughput for a ’best effort’ class QOS users on the GSN.
Pegging
?
Analysis
?
Reference
?
Usage
?
Basis
GTP
Statistic
Statistic Type
Gauge 32
Statistic Data
bits/sec
ISSUE 1 REVISION 2 cgprsGtpCurGSNBandwidthResourceUsed
�MOTOROLA LTD. 2000 GPRS01: GPRS Architecture
FOR TRAINING PURPOSES ONLY
8–15
cgprsGtpCurGSNBandwidthResourceUsed
Description
The current amount of bandwidth resource used on the GSN. The current amount ofbandwidth resource available on GSN can be obtained by deducting the value of thisobject from the value of the object cgprsGtpGSNTotalBandwidthResource.
Pegging
?
Analysis
?
Reference
?
Usage
?
Basis
GTP
Statistic
Statistic Type
Gauge 32
Statistic Data
bits/sec
ISSUE 1 REVISION 2cgprsGtpGSNTable
�MOTOROLA LTD. 2000GPRS01: GPRS Architecture
FOR TRAINING PURPOSES ONLY
8–16
cgprsGtpGSNTable
Description
GSN peer table. The SGSN–GGSN peer relationship is established as follows:
� A table in DNS listing the APN and corresponding ip address of GGSN.
� When Mobile System (MS) wants service, it sends packets to a SGSN withspecific APN.
� SGSN asks DNS for ip address of a GGSN that service this APN.
� DHCP returns a GGSN.
� SGSN requires a path to the GGSN using GTP protocol.
� The SGSN and GGSN peer maintains path by sending echo request message toeach other. If one side fails in echo reply for certain times, the other side will senda trap to NMS.
Multiple–Multiple peer relationship, i.e. A SGSN have multiple GGSN as peers,while a GGSN have multiple SGSN peers, depending on routing path
NOTE
Path is kept in database.
NOTE
Type ???
Supported by OMC GUI ???
Dependencies ???
Access not accessible
Status mandatory
Syntax
SEQUENCE OF CgprsGtpGSNEntry
Format
Example ???
Values
Value type ???
Valid range ???
Default value ???
ISSUE 1 REVISION 2 cgprsGtpGSNTable
�MOTOROLA LTD. 2000 GPRS01: GPRS Architecture
FOR TRAINING PURPOSES ONLY
8–17
References
ISSUE 1 REVISION 2cgprsGtpGSNEntry
�MOTOROLA LTD. 2000GPRS01: GPRS Architecture
FOR TRAINING PURPOSES ONLY
8–18
cgprsGtpGSNEntry
Description
GSN entry. The entry is created when a path between a GGSN and SGSN is set up andthe end point of the path (either GGSN or SGSN) is not yet listed in the GSN peer table.The entry is deleted when the path is released, or the echo test message on the pathtimes out after the retry number, defined as cgprsGtpN3Request.
Type ???
Supported by OMC GUI ???
Dependencies ???
Access not accessible
Status mandatory
Syntax
cgprsGtpGSNEntry
Format
CgprsGtpGSNEntry ::=
SEQUENCE{
cgprsGtpGSNid
cgprsGtpGSNEchoFailedNotificationCount
}
Example
?
Values
Value type ???
Valid range ???
Default value ???
References
?
ISSUE 1 REVISION 2 cgprsGtpGSNid
�MOTOROLA LTD. 2000 GPRS01: GPRS Architecture
FOR TRAINING PURPOSES ONLY
8–19
cgprsGtpGSNid
Description
IP address that uniquely identifies a GSN node.
Pegging
?
Analysis
?
Reference
?
Usage
?
Basis
GTP
Statistic
Statistic Type
IpAddress
Statistic Data
?
ISSUE 1 REVISION 2cgprsGtpGSNEchoFailedNotificationCount
�MOTOROLA LTD. 2000GPRS01: GPRS Architecture
FOR TRAINING PURPOSES ONLY
8–20
cgprsGtpGSNEchoFailedNotificationCount
Description
The echo test failure count before the entry is deleted.
Pegging
?
Analysis
?
Reference
?
Usage
?
Basis
GTP
Statistic
Statistic Type
Counter
Statistic Data
?
ISSUE 1 REVISION 2 cgprsGtpTotalNumAllocIpAddr
�MOTOROLA LTD. 2000 GPRS01: GPRS Architecture
FOR TRAINING PURPOSES ONLY
8–21
cgprsGtpTotalNumAllocIpAddr
Description
The current number of total allocated ip addresses on the GGSN.
Pegging
?
Analysis
?
Reference
?
Usage
?
Basis
GTP
Statistic
Statistic Type
Counter
Statistic Data
allocated dynamic addresses
ISSUE 1 REVISION 2cgprsGtpChargingMsgCount
�MOTOROLA LTD. 2000GPRS01: GPRS Architecture
FOR TRAINING PURPOSES ONLY
8–22
cgprsGtpChargingMsgCount
Description
The current number of total charging messages in the queue.
Pegging
?
Analysis
?
Reference
?
Usage
?
Basis
GTP
Statistic
Statistic Type
Counter
Statistic Data
?
ISSUE 1 REVISION 2 cgprsGtpLastGSNidNoRespToEcho
�MOTOROLA LTD. 2000 GPRS01: GPRS Architecture
FOR TRAINING PURPOSES ONLY
8–23
cgprsGtpLastGSNidNoRespToEcho
Description
The name of the last peer GSN that does not reply to echo message.
Pegging
?
Analysis
?
Reference
?
Usage
?
Basis
GTP
Statistic
Statistic Type
DisplayString
Statistic Data
?
ISSUE 1 REVISION 2cgprsGtpGSNidOfLastUnexpectedPDPContext
�MOTOROLA LTD. 2000GPRS01: GPRS Architecture
FOR TRAINING PURPOSES ONLY
8–24
cgprsGtpGSNidOfLastUnexpectedPDPContext
Description
The name of the peer GSN whose PDP context is unexpected.
Pegging
?
Analysis
?
Reference
?
Usage
?
Basis
GTP
Statistic
Statistic Type
DisplayString
Statistic Data
?
ISSUE 1 REVISION 2 cgprsGtpTIDOfLastUnexpectedPDPContext
�MOTOROLA LTD. 2000 GPRS01: GPRS Architecture
FOR TRAINING PURPOSES ONLY
8–25
cgprsGtpTIDOfLastUnexpectedPDPContext
Description
The TID of the last unexpected PDP Context activation.
Pegging
?
Analysis
?
Reference
?
Usage
?
Basis
GTP
Statistic
Statistic Type
DisplyString
Statistic Data
?
ISSUE 1 REVISION 2cgprsGtpRejectReasonOfLastUnexpectedPDPContext
�MOTOROLA LTD. 2000GPRS01: GPRS Architecture
FOR TRAINING PURPOSES ONLY
8–26
cgprsGtpRejectReasonOfLastUnexpectedPDPContext
Description
The reason for rejecting the PDP Context activation.
Pegging
?
Analysis
?
Reference
?
Usage
?
Basis
GTP
Statistic
Statistic Type
DisplayString
Statistic Data
?
ISSUE 1 REVISION 2 cgprsGtpNumAllocIpAddrTable
�MOTOROLA LTD. 2000 GPRS01: GPRS Architecture
FOR TRAINING PURPOSES ONLY
8–27
cgprsGtpNumAllocIpAddrTable
Description
The table for currently allocated number of dynamic addresses associated with a givenAPN.
Type ???
Supported by OMC GUI ???
Dependencies ???
Access not accessible
Status mandatory
Syntax
SEQUENCE OF CgprsGtpNumAllocIpAddrEntry
Format
???
Example
Values
Value type ???
Valid range ???
Default value ???
References
?
ISSUE 1 REVISION 2cgprsGtpNumAllocIpAddrEntry
�MOTOROLA LTD. 2000GPRS01: GPRS Architecture
FOR TRAINING PURPOSES ONLY
8–28
cgprsGtpNumAllocIpAddrEntry
Description
The entry is created when a new APN is created. The entry is deleted when theassociated APN is deleted.
Type ???
Supported by OMC GUI ???
Dependencies ???
Access not accessible
Status mandatory
Syntax
cgprsGtpNumAllocIpAddrEntry
Format
CgprsGtpNumAllocIpAddrEntry ::=
SEQUENCE{
cgprsGtpNumAllocIpAddr
}
Example
?
Values
Value type ???
Valid range ???
Default value ???
References
?
ISSUE 1 REVISION 2 cgprsGtpNumAllocIpAddr
�MOTOROLA LTD. 2000 GPRS01: GPRS Architecture
FOR TRAINING PURPOSES ONLY
8–29
cgprsGtpNumAllocIpAddr
Description
Number of ip addresses allocated for the specifified APN (as identified bycgprsGtpAPNId).
Pegging
?
Analysis
?
Reference
?
Usage
?
Basis
GTP
Statistic
Statistic Type
Gauge 32
Statistic Data
?
ISSUE 1 REVISION 2cgprsGtpNumAllocIpAddr
�MOTOROLA LTD. 2000GPRS01: GPRS Architecture
FOR TRAINING PURPOSES ONLY
8–30
ISSUE 1 REVISION 2
�MOTOROLA LTD. 2000 GPRS01: GPRS Architecture
FOR TRAINING PURPOSES ONLY
9–1
Timer GSM Name Use ValueT3313 T3313 Time out duration for page
response from MSDefault 8 SecondsUnits: SecondsRange 3 –15Ref GSM 4.08
MAX–PAGE–ATTEMPT
Maximum number ofattempts to page an MS
Default: 2Range: 1–5 Attempts
T3312 T3312 GMM Periodic RoutingArea Update Timer
Default 54 minutesRange 6 – 180 minutes in 6 minuteincreements–1 deactivates timerRef GSM 3.60
T3314 T3314 GMM Ready Timer Default 32 SecondsUnits: SecondsRange: 2–60 Seconds in 2 secondincrements or 61–180 in 60 secondincerments.–1 Deactivates Timer0 will force to standby
T3315 T3315 GMM Standby Timer Default: 60 MinutesUnits: MiniutesRange: 6–186 minutes in 6 minuteincremetns.–1 deactivates timerMust be greater than T3312
N3 N3 Maximum number ofattempts to send a GTPmessage to a GSN
Default: 3 AttemptsRange: 1–5 Attempts
bssgp_t1_timer T1 T1 specifies the duration ofthe guard timer for cellblocking and unblocking
Default: 3Units: SecondsRange: 30–120
bssgp_t2_timer T2 T1 specifies the duration ofthe guard timer for resetproceedures with the SGSN
Default: 60Units: SecondsRange: 1–120
bssgp_bock_retries BVC–BLOCK–RETRIES
bssgp_bock_retriesspecifeis the number ofretries generated for cellblock messages
Default: 3Range: 1–3
bssgp_unbock_retries BVC–UNBLOCK–RETRIES
bssgp_unbock_retriesspecifeis the number ofretries generated for cellunblock messages
Default: 3Range: 1–3
bssgp_reset_retries BVC–RESET–RETRIES
bssgp_reset_retriesspecifeis the number ofretries generated for resetmessages.
Default: 3Range: 1–3
ns_block_timer Tns–block Timer guards the NS–VCblocking and unblocking
Default: 3Units: SecondsRange: 1–30
ns_reset_timer Tns–reset Timer guards the NS–VCreset proceddure
Defualt: 40Units: SecondsRange: 1–120
ns_test_timer Tns–test Timer sets the period of theNS–VC test proceedure.The NS–VC is tested everyns_test_timer seconds
Default: 30Units: SecondsRange: 1–60
ISSUE 1 REVISION 2
�MOTOROLA LTD. 2000GPRS01: GPRS Architecture
FOR TRAINING PURPOSES ONLY
9–2
ns_alive_timer Tns–alive Timer guards the NS–VCtest proceedure
Default: 3Units: SecondsRange: 1–30
ns_block_retries NS–BLOCK–RETRIES
Timer specifies the numberof retries to block aNS–VC.
Default: 3Range: 1–3
ns_unblock_retries NS_UNBLOCK_RETRIES
Timer specifies the numberof retires generated tounblock the NS–VC
Default: 3Range: 1–3
ns_alive_retries NS_ALIVE_RETRIES
Timer specifes the numberof retries generated toestablish if a NS–VC isalive
Default: 3Range: 1–10
ns_reset_period Timer specifies the periodover which the BSS shallattempt to reset a NS–VC
Default: 125Units: SecondsRange: 1–250
bssgp_fc_period_c Th This timer specifies thefrequency of flow controlform the PCU to the SGSN
Default: 10Units: 10ths of a secondRange 1–1000
gprs_bs_cv_max Maximum count downvalue a mobile can have foruplink RLC data transfer
Default: 6Range: 0–15
bssgp_racap_retries T5 The bssgp_recap_retriesspecifies the number ofretries that the BSSgenerates forRA–Capabilty–Updatemessages
Default: 3Range: 1–3
�MOTOROLA LTD. 2000 GPRS01: GPRS Architecture
FOR TRAINING PURPOSES ONLY
i
Chapter 10
Glossary of technical terms and
abbreviations
ISSUE 1 REVISION 2
�MOTOROLA LTD. 2000 GPRS01: GPRS Architecture
FOR TRAINING PURPOSES ONLY
iii
Chapter 9Glossary of technical terms and abbreviations i. . . . . . . . . . . . . . . . . . . . . . . .
Numbers 9–1. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
A 9–2. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
B 9–5. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
C 9–8. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
D 9–12. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
E 9–15. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
F 9–17. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
G 9–19. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
H 9–21. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
I 9–22. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
K 9–24. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
L 9–25. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
M 9–27. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
N 9–31. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
O 9–33. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
P 9–35. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Q 9–38. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
R 9–39. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
S 9–42. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
T 9–46. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
U 9–49. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
V 9–50. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
W 9–51. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
X 9–52. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Z 9–53. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
ISSUE 1 REVISION 2 Numbers
�MOTOROLA LTD. 2000 GPRS01: GPRS Architecture
FOR TRAINING PURPOSES ONLY
10–1
Numbers# Number.
2 Mbit/s link As used in this manual set, the term applies to the European4-wire 2.048 Mbit/s digital line or link which can carry 30A-law PCM channels or 120 16 kbit/s GSM channels.
4GL 4th Generation Language.
ISSUE 1 REVISION 2A
�MOTOROLA LTD. 2000GPRS01: GPRS Architecture
FOR TRAINING PURPOSES ONLY
10–2
AA interface Interface between MSC and BSS.
A3 Authentication algorithm that produces SRES, using RANDand Ki.
A38 A single algorithm performing the function of A3 and A8.
A5 Stream cipher algorithm, residing on an MS, that producesciphertext out of plaintext, using Kc.
A8 Ciphering key generating algorithm that produces Kc usingRAND and Ki.
AA Anonymous Access.
AB Access Burst.
Abis interface Interface between a remote BSC and BTS. Motorola offers aGSM standard and a unique Motorola Abis interface. TheMotorola interface reduces the amount of message traffic andthus the number of 2 Mbit/s lines required between BSC andBTS.
ABR Answer Bid Ratio.
ac–dc PSM AC–DC Power Supply module.
ac Alternating Current.
AC Access Class (C0 to C15).
AC Application Context.
ACC Automatic Congestion Control.
ACCH Associated Control CHannel.
ACK, Ack ACKnowledgement.
ACM Accumulated Call meter.
ACM Address Complete Message.
ACPIM AC Power Interface Module. Used in M-Cell6 indor ac BTSequipment.
AC PSM AC Power Supply Module. Used in M-Cell6 BTS equipment.
ACSE Associated Control Service Element.
ACU Antenna Combining Unit.
A/D Analogue to Digital (converter).
ADC ADministration Centre.
ADC Analogue to Digital Converter.
ADCCP ADvanced Communications Control Protocol.
ADM ADMinistration processor.
ADMIN ADMINistration.
ADN Abbreviated Dialling Number.
ADPCM Adaptive Differential Pulse Code Modulation.
AE Application Entity.
AEC Accoustic Echo Control.
AEF Additional Elementary Functions.
ISSUE 1 REVISION 2 A
�MOTOROLA LTD. 2000 GPRS01: GPRS Architecture
FOR TRAINING PURPOSES ONLY
10–3
AET Active Events Table. Alarms and events are sent to theEvents Log in the GUI. Different operators will have differentsubscription lists. All alarms and events are sent to the AETbefore they are re-routed to different subscription lists.
AFC Automatic Frequency Control.
AFN Absolute Frame Number.
AGC Automatic Gain Control.
AGCH Access Grant CHannel. A GSM common control channelused to assign MS to a SDCCH or a TCH.
Ai Action indicator.
AI Artificial Intelligence.
AIB Alarm Interface Board.
AIO A class of processor.
Air interface The radio link between the BTS and the MS.
AM Amplitude Modulation.
AMA Automatic Message Accounting (processor).
AM/MP Cell broadcast mobile terminated message. A messagebroadcast to all MSs in a cell.
APN Access Point Name.
AoC Advice of Change.
AoCC Advice of Change Charging supplementary service.
AoCI Advice of Change Information supplementary service.
AOC Automatic Output Control.
AP Application Process.
ARFCN Absolute Radio Frequency Channel Number. An integerwhich defines the absolute RF channel number.
ARQ Automatic ReQuest for retransmission.
ARP Address Resolution Protocol.
ASCE Association Control Service Element. An ASE whichprovides an AP with the means to establish and control anassociation with an AP in a remote NE. Maps directly ontothe Presentation layer (OMC).
ASE Application Service Element (OMC)
ASE Application Specific Entity (TCAP).
ASN.1 Abstract Syntax Notation One.
ASP Alarm and Status Panel.
ASR Answer Seizure Ratio.
ATB All Trunks Busy.
ATI Antenna Transceiver Interface.
ATM Asynchronous Transfer Mode.
ATT (flag) ATTach.
ATTS Automatic Trunk Testing Subsystem.
AU Access Unit.
ISSUE 1 REVISION 2A
�MOTOROLA LTD. 2000GPRS01: GPRS Architecture
FOR TRAINING PURPOSES ONLY
10–4
AuC Authentication Centre. A GSM network entity which providesthe functionality for verifying the identity of an MS whenrequested by the system. Often a part of the HLR.
AUT(H) AUThentication.
AUTO AUTOmatic mode.
ISSUE 1 REVISION 2 B
�MOTOROLA LTD. 2000 GPRS01: GPRS Architecture
FOR TRAINING PURPOSES ONLY
10–5
B
B Interface Interface between MSC and VLR.
BA BCCH Allocation. The radio frequency channels allocated in acell for BCCH transmission.
BAIC Barring of All Incoming Calls supplementary service.
BAOC Barring of All Outgoing Calls supplementary service.
BBBX Battery Backup Board.
BBH Base Band Hopping.
BCC BTS Colour Code.
BCCH Broadcast Control CHannel. A GSM control channel used tobroadcast general information about a BTS site on a per cellor sector basis.
BCD Binary Coded Decimal.
BCF Base station Control Function. The GSM term for the digitalcontrol circuitry which controls the BTS. In Motorola cell sitesthis is a normally a BCU which includes DRI modules and islocated in the BTS cabinet.
BCIE Bearer Capability Information Element.
BCU Base station Control Unit. A functional entity of the BSSwhich provides the base control function at a BTS site. Theterm no longer applies to a type of shelf (see BSC and BSU).
BCUP Base Controller Unit Power.
BER Bit Error Rate. A measure of signal quality in the GSMsystem.
BES Business Exchange Services.
BFI Bad Frame Indication.
BG Border Gateway.
BGP Border Gateway Protocol
BHCA Busy Hour Call Attempt.
BI all Barring of All Incoming call supplementary service.
BIB Balanced-line Interconnect Board. Provides interface to 12balanced (6-pair) 120 ohm (37-pin D-type connector) lines for2 Mbit/s circuits (See also T43).
BIC–Roam Barring of All Incoming Calls when Roaming outside theHome PLMN Country supplementary service.
BIM Balanced-line Interconnect Module.
Bin An area in a data array used to store information.
BL BootLoad. Also known as download. For example, databasesand software can be downloaded to the NEs from the BSS.
BLLNG BiLLiNG.
bit/s Bits per second (bps).
Bm Full rate traffic channel.
BN Bit Number. Number which identifies the position of aparticular bit period within a timeslot.
ISSUE 1 REVISION 2B
�MOTOROLA LTD. 2000GPRS01: GPRS Architecture
FOR TRAINING PURPOSES ONLY
10–6
BPF Bandpass Filter.
BPSM �BCU Power Supply Module.
BS Basic Service (group).
BS Bearer Service. A type of telecommunication service thatprovides the capability for the transmission of signalsbetween user-network interfaces. The PLMN connection typeused to support a bearer service may be identical to that usedto support other types of telecommunication service.
BSC Base Station Controller. A network component in the GSMPLMN which has the digital control function of controlling allBTSs. The BSC can be located within a single BTS cabinet(forming a BSS) but is more often located remotely andcontrols several BTSs (see BCF, BCU, and BSU).
BSG Basic Service Group.
BSIC Base Transceiver Station Identity Code. A block of code,consisting of the GSM PLMN colour code and a base stationcolour code. One Base Station can have several BaseStation Colour Codes.
BSIC-NCELL BSIC of an adjacent cell.
BSP Base Site control Processor (at BSC).
BSN Backward Sequence Number.
BSS Base Station System. The system of base station equipment(Transceivers, controllers and so on) which is viewed by theMSC through a single interface as defined by the GSM 08series of recommendations, as being the entity responsiblefor communicating with MSs in a certain area. The radioequipment of a BSS may cover one or more cells. A BSSmay consist of one or more base stations. If an internalinterface is implemented according to the GSM 08.5x seriesof recommendations, then the BSS consists of one BSC andseveral BTSs.
BSSAP BSS Application Part (of Signalling System No. 7) (DTAP +BSSMAP).
BSSC Base Station System Control cabinet. The cabinet whichhouses one or two BSU shelves at a BSC or one or two RXUshelves at a remote transcoder.
BSSGP Base Station System GPRS Protocol.
BSSMAP Base Station System Management Application Part (6-8).
BSSOMAP BSS Operation and Maintenance Application Part (ofSignalling System No. 7).
BSU Base Station Unit shelf. The shelf which houses the digitalcontrol modules for the BTS (p/o BTS cabinet) or BSC (p/oBSSC cabinet).
BT British Telecom.
BT Bus Terminator.
BTC Bus Terminator Card.
BTF Base Transceiver Function.
BTP Base Transceiver Processor (at BTS). One of the six basictask groups within the GPROC.
ISSUE 1 REVISION 2 B
�MOTOROLA LTD. 2000 GPRS01: GPRS Architecture
FOR TRAINING PURPOSES ONLY
10–7
BTS Base Transceiver Station. A network component in the GSMPLMN which serves one cell, and is controlled by a BSC.The BTS contains one or more Transceivers (TRXs).
Burst A period of modulated carrier less than one timeslot. Thephysical content of a timeslot.
BVCI BSSGP Virtual Circuit Identifiers.
ISSUE 1 REVISION 2C
�MOTOROLA LTD. 2000GPRS01: GPRS Architecture
FOR TRAINING PURPOSES ONLY
10–8
CC Conditional.
C Interface Interface between MSC and HLR/AUC.
C7 ITU-TSS Signalling System 7 (sometimes referred to as S7 orSS#7).
CA Cell Allocation. The radio frequency channels allocated to aparticular cell.
CA Central Authority.
CAB Cabinet.
CADM Country ADMinistration. The Motorola procedure used withinDataGen to create new country and network files in theDataGen database.
CAI Charge Advice Information.
CAT Cell Analysis Tool.
CB Cell Broadcast.
CB Circuit Breaker.
CBC Cell Broadcast Centre.
CBCH Cell Broadcast CHannel.
CBF Combining Bandpass Filter.
CBL Cell Broadcast Link.
CBM Circuit Breaker Module.
CBMI Cell Broadcast Message Identifier.
CBSMS Cell Broadcast Short Message Service.
CBUS Clock Bus.
CC Connection Confirm (Part of SCCP network connectivity).
CC Country Code.
CC Call Control.
CCB Cavity Combining Block, a three way RF combiner. Thereare two types of CCB, CCB (Output) and CCB (Extension).These, with up to two CCB Control cards, may comprise theTATI. The second card may be used for redundancy.
CCBS Completion of Calls to Busy Subscriber supplementaryservice.
CCCH Common Control CHannels. A class of GSM controlchannels used to control paging and grant access. IncludesAGCH, PCH, and RACH.
CCCH_GROUP Group of MSs in idle mode.
CCD Common Channel Distributor.
CCDSP Channel Coding Digital Signal Processor.
CCF Conditional Call Forwarding.
CCH Control CHannel. Control channels are channels which carrysystem management messages.
CCH Council for Communications Harmonization (referred to inGSM Recommendations).
ISSUE 1 REVISION 2 C
�MOTOROLA LTD. 2000 GPRS01: GPRS Architecture
FOR TRAINING PURPOSES ONLY
10–9
CCIT Comité Consultatif International Télégraphique etTéléphonique. This term has been superceded by ITU–TSS(International Telecommunications Union –Telecommunications Sector).
CCM Current Call Meter.
CCP Capability/Configuration Parameter.
CCPE Control Channel Protocol Entity.
CCS Hundred call-seconds. The unit in which amounts oftelephone traffic are measured. A single call lasting onehundred seconds is one CCS. See also erlang.
Cct Circuit.
CDB Control Driver Board.
CDE Common Desktop Environment. Part of the SUN software(crontab – cron job file).
CDR Call Detail Records.
CDUR Chargeable DURation.
CEB Control Equalizer Board (BTS).
CED Called station identifier.
CEIR Central Equipment Identity Register.
Cell By GSM definition, a cell is an RF coverage area. At anomni-site, cell is synonymous with site; at a sectored site, cellis synonymous with sector. This differs from analoguesystems where cell is taken to mean the same thing as site.(See below).
Omni Site1-Cell Site
(1 BTS)
6-Sector Siteor
6-Cell Site(6 BTSs)
1 Cell =1 Sector
CEND End of charge point.
CEPT Conférence des administrations Européennes des Postes etTelecommunications.
CERM Circuit Error Rate Monitor.
CF Conversion Facility.
CF all Call Forwarding services.
CFB Call Forwarding on mobile subscriber Busy supplementaryservice.
CFC Conditional Call Forward.
CFNRc Call Forwarding on mobile subscriber Not Reachablesupplementary service.
CFNRy Call Forwarding on No Reply supplementary service.
ISSUE 1 REVISION 2C
�MOTOROLA LTD. 2000GPRS01: GPRS Architecture
FOR TRAINING PURPOSES ONLY
10–10
CFU Call Forwarding Unconditional supplementary service.
Channel A means of one-way transmission. A defined sequence ofperiods (for example, timeslots) in a TDMA system; a definedfrequency band in an FDMA system; a defined sequence ofperiods and frequency bands in a frequency hopped system.
CIM Coaxial Interconnect Module.
CGF Charging Gateway Function.
CHP CHarging Point.
CHV Card Holder Verification information.
CKSN Ciphering Key Sequence Number.
CI Cell Identity. A block of code which identifies a cell within alocation area.
CI CUG Index.
CIC Circuit Identity Code.
CIR, C/I Carrier to Interference Ratio.
Ciphertext Unintelligible data produced through the use of encipherment.
CKSN Ciphering Key Sequence Number.
CLI Calling Line Identity.
CLIP Calling Line Identification Presentation supplementaryservice.
CLIR Calling Line Identification Restriction supplementary service.
CLK Clock.
CLKX Clock Extender half size board. The fibre optic link thatdistributes GCLK to boards in system (p/o BSS etc).
CLM Connectionless Manager.
CLR CLeaR.
CM Configuration Management. An OMC application.
CM Connection Management.
CMD CoMmanD.
CMM Channel Mode Modify.
CMIP Common Management Information Protocol.
CMISE Common Management Information Service Element. An ASEwhich provides a means to transfer management informationvia CMIP messages with another NE over an associationestablished by ASCE using ROSE (OMC).
CMR Cellular Manual Revision.
CNG CalliNg tone.
COLI COnnected Line Identity.
Collocated Placed together; two or more items together in the sameplace.
Coincident Cell A cell which has a co-located neighbour whose cell boundaryfollows the boundary of the said cell. The coincident cell hasa different frequency type, but the same BSIC, as that of theneighbour cell.
ISSUE 1 REVISION 2 C
�MOTOROLA LTD. 2000 GPRS01: GPRS Architecture
FOR TRAINING PURPOSES ONLY
10–11
COLP COnnected Line Identification Presentation supplementaryservice.
COLR COnnected Line Identification Restriction supplementaryservice.
CODEX Manufacturer’s name for a type of multiplexer and packetswitch commonly installed at the Motorola OMC-R.
COM Code Object Manager.
COM COMplete.
COMB Combiner.
CONNACK CONNect ACKnowledgement.
COMM, Comms COMMunications.
CommsLink Communications Link. (2Mbit/s)
CONF CONFerence circuit.
CONFIG CONFIGuration Control Program.
CP Call Processing.
CPU Central Processing Unit.
C/R Command/Response field bit.
CR Carriage Return (RETURN).
CR Connection Request (Part of SCCP network connectivity).
CRC Cyclic Redundancy Check (3 bit).
CRE Call RE-establishment procedure.
CREF Connection REFused (Part of SCCP network connectivity).
CRM Cell Resource Manager.
CRM-LS/HS Cellular Radio Modem-Low Speed/High Speed. Low speedmodem used to interwork 300 to 2400 bit/s data servicesunder V.22bis, V.23, or V.21 standards. High speed modemused to interwork 1200 to 9600 bit/s data services underV.22bis, V.32, or V.29/V.27ter/V.21 standards.
CRT Cathode Ray Tube (video display terminal).
CSFP Code Storage Facility Processor (at BSC and BTS).
CSP Central Statistics Process. The statistics process in the BSC.
CSPDN Circuit Switched Public Data Network.
CT Call Transfer supplementary service.
CT Channel Tester.
CT Channel Type.
CTP Call Trace Product (Tool).
CTR Common Technical Regulation.
CTS Clear to Send. Method of flow control (RS232 Interface).
CTU Compact Transceiver Unit (M-Cellhorizon radio).
CUG Closed User Group supplementary service.
Cumulative value The total value for an entire statistical interval.
CW Call Waiting supplementary service.
ISSUE 1 REVISION 2D
�MOTOROLA LTD. 2000GPRS01: GPRS Architecture
FOR TRAINING PURPOSES ONLY
10–12
D
D Interface Interface between VLR and HLR.
D/A Digital to Analogue (converter).
DAB Disribution Alarm Board.
DAC Digital to Analogue Converter.
DACS Digital Access Cross-connect System.
DAN Digital ANnouncer (for recorded announcements on MSC).
DAS Data Acquisition System.
DAT Digital Audio Tape.
DataGen Sysgen Builder System. A Motorola offline BSS binary objectconfiguration tool.
dB Decibel. A unit of power ratio measurement.
DB DataBase.
DB Dummy Burst (see Dummy burst).
DBA DataBase Administration/Database Administrator.
DBMS DataBase Management System.
dc Direct Current.
DCB Diversity Control Board (p/o DRCU).
DCCH Dedicated Control CHannel. A class of GSM controlchannels used to set up calls and report measurements.Includes SDCCH, FACCH, and SACCH.
DCD Data Carrier Detect signal.
DCE Data Circuit terminating Equipment.
DCF Data Communications Function.
DCF Duplexed Combining bandpass Filter. (Used inHorizonmacro).
DCN Data Communications Network. A DCN connects NetworkElements with internal mediation functions or mediationdevices to the Operations Systems.
DC PSM DC Power Supply Module.
DCS1800 Digital Cellular System at 1800 MHz. A cellular phonenetwork using digital techniques similar to those used in GSM900, but operating on frequencies of 1710 – 1785 MHz and1805 – 1880 MHz.
DDF Dual-stage Duplexed combining Filter. (Used inHorizonmacro).
DDS DataGen Directory Structure.
DDS Data Drive Storage.
DDS Direct Digital Synthesis.
DEQB Diversity Equalizer Board.
DET DETach.
DFE Decision Feedback Equalizer.
DGT Data Gathering Tool.
ISSUE 1 REVISION 2 D
�MOTOROLA LTD. 2000 GPRS01: GPRS Architecture
FOR TRAINING PURPOSES ONLY
10–13
DHCP Dynamic Host Configuration Protocol.
DHP Digital Host Processor.
DIA Drum Intercept Announcer.
DINO E1/HDSL Line termination module.
DINO T1 Line termination module.
DISC DISConnect.
Discon Discontiuous.
DIQ Diversity In phase and Quadrature phase.
DIR Device Interface Routine.
DL Data Link (layer).
DLCI Data Link Connection Identifier.
DLD Data Link Discriminator.
DLNB Diversity Low Noise Block.
DLSP Data Link Service Process.
DLSP Digital Link Signalling Processor.
Dm Control channel (ISDN terminology applied to mobile service).
DMA Deferred Maintenance Alarm. An alarm report level; animmediate or deferred response is required (see also PMA).
DMA Direct Memory Access.
DMR Digital Mobile Radio.
DMX Distributed Electronic Mobile Exchange (Motorola’snetworked EMX family).
DN Directory Number.
DNIC Data network identifier.
DNS Domain Name Server
Downlink Physical link from the BTS towards the MS (BTS transmits,MS receives).
DP Dial/Dialled Pulse.
DPC Destination Point Code. A part of the label in a signallingmessage that uniquely identifies, in a signalling network, the(signalling) destination point of the message.
DPC Digital Processing and Control board.
DPNSS Digital Private Network Signalling System (BT standard forPABX interface).
DPP Dual Path Preselector.
DPR, DPRAM Dual Port Random Access Memory.
DPSM Digital Power Supply Module.
DRAM Dynamic Random Access Memory.
DRC Data Rate Converter board. Provides data and protocolconversion between PLMN and destination network for 8circuits (p/o IWF).
DRCU Diversity Radio Channel Unit. Contains transceiver, digitalcontrol circuits, and power supply (p/o BSS) (see RCU).
ISSUE 1 REVISION 2D
�MOTOROLA LTD. 2000GPRS01: GPRS Architecture
FOR TRAINING PURPOSES ONLY
10–14
(D)RCU Generic term for radio channel unit. May be standard RCU ordiversity radio channel unit DRCU.
DRI Digital Radio Interface. Provides encoding/decoding andencryption/decryption for radio channel (p/o BSS).
DRIM Digital Radio Interface extended Memory. A DRI with extramemory.
DRIX DRI Extender half size board. Fibre optic link from DRI toBCU (p/o BSS).
DRX, DRx Discontinuous reception (mechanism). A means of savingbattery power (for example in hand-portable units) byperiodically and automatically switching the MS receiver onand off.
DS-2 German term for 2 Mbit/s line (PCM interface).
DSE Data Switching Exchange.
DSI Digital Speech Interpolation.
DSP Digital Signal Processor.
DSS1 Digital Subscriber Signalling No 1.
DSSI Diversity Signal Strength Indication.
DTAP Direct Transfer Application Part (6-8).
DTE Data Terminal Equipment.
DTF Digital Trunk Frame.
DT1 DaTa form 1 (Part of SCCP network connectivity).
DTI Digital Trunk Interface.
DTMF Dual Tone Multi-Frequency (tone signalling type).
DTR Data Terminal Ready signal. Method of flow control (RS232Interface).
DTRX Dual Transceiver Module. (Radio used in M-Cellarena andM-Cellarenamacro).
DTX, DTx Discontinuous Transmission (mechanism). A means ofsaving battery power (for example in hand-portable units) andreducing interference by automatically switching thetransmitter off when no speech or data are to be sent.
Dummy burst A period of carrier less than one timeslot whose modulation isa defined sequence that carries no useful information. Adummy burst fills a timeslot with an RF signal when noinformation is to be delivered to a channel.
DYNET DYnamic NETwork. Used to specify BTSs sharing dynamicresources.
ISSUE 1 REVISION 2 E
�MOTOROLA LTD. 2000 GPRS01: GPRS Architecture
FOR TRAINING PURPOSES ONLY
10–15
E
E See Erlang.
E Interface Interface between MSC and MSC.
EA External Alarms.
EAS External Alarm System.
Eb/No Energy per Bit/Noise floor.
EBCG Elementary Basic Service Group.
EC Echo Canceller. Performs echo suppression for all voicecircuits.
ECB Provides echo cancelling for telephone trunks for 30 channels(EC).
ECID The Motorola European Cellular Infrastructure Division.
ECM Error Correction Mode (facsimile).
Ec/No Ratio of energy per modulating bit to the noise spectraldensity.
ECT Event Counting Tool.
ECT Explicit Call Transfer supplementary service.
EEL Electric Echo Loss.
EEPROM Electrically Erasable Programmable Read Only Memory.
EGSM900 Extended GSM900.
EI Events Interface. Part of the OMC-R GUI.
EIR Equipment Identity Register.
EIRP Effective Isotropic Radiated Power.
EIRP Equipment Identity Register Procedure.
EL Echo Loss.
EM Event Management. An OMC application.
EMC ElectroMagnetic Compatibility.
EMF Electro Motive Force.
EMI Electro Magnetic Interference.
eMLPP enhanced Multi-Level Precedence and Pre-emption service.
EMMI Electrical Man Machine Interface.
EMU Exchange office Management Unit (p/o Horizonoffice)
EMX Electronic Mobile Exchange (Motorola’s MSC family).
en bloc Fr. — all at once (a CCITT #7 Digital Transmission scheme);En bloc sending means that digits are sent from one systemto another ~ (that is, all the digits for a given call are sent atthe same time as a group). ~ sending is the opposite ofoverlap sending. A system using ~ sending will wait until ithas collected all the digits for a given call before it attempts tosend digits to the next system. All the digits are then sent asa group.
EOT End of Tape.
EPROM Erasable Programmable Read Only Memory.
ISSUE 1 REVISION 2E
�MOTOROLA LTD. 2000GPRS01: GPRS Architecture
FOR TRAINING PURPOSES ONLY
10–16
EPSM Enhanced Power Supply Module (+27 V).
EQB Equalizer Board. Control circuit for equalization for 8 timeslots each with equalizing circuitry and a DSP (p/o RCU).
EQCP Equalizer Control Processor.
EQ DSP Equalizer Digitizer Signal Processor.
Erlang International (dimensionless) unit of traffic intensity defined asthe ratio of time a facility is occupied to the time it is availablefor occupancy. One erlang is equal to 36 CCS. In the USthis is also known as a traffic unit (TU).
ERP Ear Reference Point.
ERP Effective Radiated Power.
ERR ERRor.
ESP Electro-static Point.
ESQL Embedded SQL (Structured Query Language). An RDBMSprogramming interface language.
E-TACS Extended TACS (analogue cellular system, extended).
Ethernet Type of Local Area Network.
ETR ETSI Technical Report.
ETS European Telecommunication Standard.
ETSI European Telecommunications Standards Institute.
ETX End of Transmission.
EXEC Executive Process.
ISSUE 1 REVISION 2 F
�MOTOROLA LTD. 2000 GPRS01: GPRS Architecture
FOR TRAINING PURPOSES ONLY
10–17
F
F Interface Interface between MSC and EIR.
FA Fax Adaptor.
FA Full Allocation.
FA Functional Area.
FAC Final Assembly Code.
FACCH Fast Associated Control Channel. A GSM dedicated controlchannel which is associated with a TCH and carries controlinformation after a call is set up (see SDCCH).
FACCH/F Fast Associated Control Channel/Full rate.
FACCH/H Fast Associated Control Channel/Half rate.
FB Frequency correction Burst (see Frequency correction burst).
FC-AL Fibre Channel Arbitration Loop. (Type of hard disc).
FCCH Frequency Correction CHannel. A GSM broadcast controlchannel which carries information for frequency correction ofthe mobile (MS).
FCP Fault Collection Process (in BTS).
FCS Frame Check Sequence.
FDM Frequency Division Multiplex.
FDMA Frequency Division Multiple Access.
FDN Fixed Dialling Number.
FDP Fault Diagnostic Procedure.
FEC Forward Error Correction.
FEP Front End Processor.
FER Frame Erasure Ratio.
FFS, FS For Further Study.
FH Frequency Hopping.
FIB Forward Indicator Bit.
FIR Finite Impulse Response (filter type).
FK Foreign Key. A database column attribute; the foreign keyindicates an index into another table.
FM Fault Management (at OMC).
FM Frequency Modulation.
FMIC Fault Management Initiated Clear.
FMUX Fibre optic MUltipleXer.
FN Frame Number. Identifies the position of a particular TDMAframe within a hyperframe.
FOA First Office Application.
FOX Fibre Optic eXtender.
FR Full Rate. Refers to the current capacity of a data channel onthe GSM air interface, that is, 8 simultaneous calls per carrier(see also HR – Half Rate).
ISSUE 1 REVISION 2F
�MOTOROLA LTD. 2000GPRS01: GPRS Architecture
FOR TRAINING PURPOSES ONLY
10–18
FR Frame Relay.
FRU Field Replaceable Unit.
Frequency correction Period of RF carrier less than one timeslot whose modulationbit stream allows frequency correction to be performed easilywithin an MS burst.
FS Frequency Synchronization.
FSL Free Space Loss. The decrease in the strength of a radiosignal as it travels between a transmitter and receiver. TheFSL is a function of the frequency of the radio signal and thedistance the radio signal has travelled from the point source.
FSN Forward Sequence Number.
FTAM File Transfer, Access, and Management. An ASE whichprovides a means to transfer information from file to file(OMC).
ftn forwarded-to number.
FTP Fault Translation Process (in BTS).
FTP File Transfer Protocol.
ISSUE 1 REVISION 2 G
�MOTOROLA LTD. 2000 GPRS01: GPRS Architecture
FOR TRAINING PURPOSES ONLY
10–19
GG Interface Interface between VLR and VLR.
Gateway MSC An MSC that provides an entry point into the GSM PLMNfrom another network or service. A gateway MSC is also aninterrogating node for incoming PLMN calls.
GB, Gbyte Gigabyte.
GBIC Gigabit Interface Converter.
GCLK Generic Clock board. System clock source, one per site (p/oBSS, BTS, BSC, IWF, RXCDR).
GCR Group Call Register.
GDP Generic DSP Processor board. Interchangeable with the XCDRboard.
GDP E1 GDP board configured for E1 link usage.
GDP T1 GDP board configured for T1 link usage.
GGSN Gateway GPRS Support Node.
GHz Giga-Hertz (109).
GID Group ID. A unique number used by the system to identify auser’s primary group.
GMB GSM Multiplexer Board (p/o BSC).
GMR GSM Manual Revision.
GMSC Gateway Mobile-services Switching Centre (see GatewayMSC).
GMSK Gaussian Minimum Shift Keying. The modulation techniqueused in GSM.
GND GrouND.
GOS Grade of Service.
GPA GSM PLMN Area.
GPC General Protocol Converter.
GPROC Generic Processor board. GSM generic processor board: a68030 with 4 to 16 Mb RAM (p/o BSS, BTS, BSC, IWF,RXCDR).
GPROC2 Generic Processor board. GSM generic processor board: a68040 with 32 Mb RAM (p/o BSS, BTS, BSC, IWF, RXCDR).
GPRS General Packet Radio Service.
GPS Global Positioning by Satellite.
GR GPRS Register.
GSA GSM Service Area. The area in which an MS can be reachedby a fixed subscriber, without the subscriber’s knowledge ofthe location of the MS. A GSA may include the areas servedby several GSM PLMNs.
GSA GSM System Area. The group of GSM PLMN areasaccessible by GSM MSs.
GSM Groupe Spécial Mobile (the committee).
GSM Global System for Mobile communications (the system).
ISSUE 1 REVISION 2G
�MOTOROLA LTD. 2000GPRS01: GPRS Architecture
FOR TRAINING PURPOSES ONLY
10–20
GSM MS GSM Mobile Station.
GSM PLMN GSM Public Land Mobile Network.
GSN GPRS Support Node.
GSR GSM Software Release.
GT Global Title.
GTE Generic Table Editor. The Motorola procedure which allowsusers to display and edit MCDF input files.
GTP GPRS Tunnelling Protocol.
Guard period Period at the beginning and end of timeslot during which MStransmission is attenuated.
GUI Graphical User Interface.
GUI client A computer used to display a GUI from an OMC-R GUIapplication which is beingbrun on a GUI server.
GUI server A computer used to serve the OMC-R GUI applicationprocess running locally (on its processor) to other computers(Gui clients or other MMI processors).
GWY GateWaY (MSC/LR) interface to PSTN.
ISSUE 1 REVISION 2 H
�MOTOROLA LTD. 2000 GPRS01: GPRS Architecture
FOR TRAINING PURPOSES ONLY
10–21
HH Interface Interface between HLR and AUC.
H-M Human-Machine Terminals.
HAD, HAP HLR Authentication Distributor.
HANDO, Handover HANDOver. The action of switching a call in progress fromone radio channel to another radio channel. Handover allowsestablished calls to continue by switching them to anotherradio resource, as when an MS moves from one BTS area toanother. Handovers may take place between the followingGSM entities: timeslot, RF carrier, cell, BTS, BSS and MSC.
HCU Hybrid Combining Unit. (Used in Horizonmacro).
HDLC High level Data Link Control.
HDSL High bit-rate Digital Subscriber Line.
HLC High Layer Compatibility. The HLC can carry informationdefining the higher layer characteristics of a teleservice activeon the terminal.
HLR Home Location Register. The LR where the current locationand all subscriber parameters of an MS are permanentlystored.
HMS Heat Management System. The system that providesenvironmental control of the components inside the ExCell,TopCell and M-Cell cabinets.
HO HandOver. (see HANDO above).
HPU Hand Portable Unit.
HOLD Call hold supplementary service.
HPLMN Home PLMN.
HR Half Rate. Refers to a type of data channel that will doublethe current GSM air interface capacity to 16 simultaneouscalls per carrier (see also FR – Full Rate).
HS HandSet.
HSI/S High Speed Interface card.
HSM HLR Subscriber Management.
HSN Hopping Sequence Number.
HU Home Units.
HW Hardware.
Hyperframe 2048 superframes. The longest recurrent time period of theframe structure.
ISSUE 1 REVISION 2I
�MOTOROLA LTD. 2000GPRS01: GPRS Architecture
FOR TRAINING PURPOSES ONLY
10–22
I
I Information frames (RLP).
IA Incomming Access (closed user group (CUG) SS(supplementary service)).
IA5 International Alphanumeric 5.
IADU Integrated Antenna Distribution Unit. (The IADU is theequivalent of the Receive Matrix used on pre-M-Cell BTSs).
IAM Initial Address Message.
IAS Internal Alarm System.
IC Integrated Circuit.
IC Interlock Code (CUG SS).
IC(pref) Interlock Code op the preferential CUG.
ICB Incoming Calls Barred.
ICC Integrated Circuit(s) Card.
ICM In-Call Modification.
ICMP Internet Control Message Protocol.
ID, Id IDentification/IDentity/IDentifier.
IDN Integrated Digital Network.
IDS INFOMIX Database Server. (OMC-R relational databasemanagement system).
IE Information Element (signalling).
IEC International Electrotechnical Commission.
IEEE Institute of Electrical and Electronic Engineers.
IEI Information Element Identifier.
I-ETS Interim European Telecommunication Standard.
IF Intermediate Frequency.
IFAM Initial and Final Address Message.
IM InterModulation.
IMACS Intelligent Monitor And Control System.
IMEI International Mobile station Equipment Identity. Electronicserial number that uniquely identifies the MS as a piece orassembly of equipment. The IMEI is sent by the MS alongwith request for service.
IMM IMMediate assignment message.
IMSI International Mobile Subscriber Identity. Published mobilenumber (prior to ISDN) (see also MSISDN) that uniquelyidentifies the subscription. It can serve as a key to derivesubscriber information such as directory number(s) from theHLR.
IN Intelligent Network.
IN Interrogating Node. A switching node that interrogates anHLR, to route a call for an MS to the visited MSC.
INS IN Service.
ISSUE 1 REVISION 2 I
�MOTOROLA LTD. 2000 GPRS01: GPRS Architecture
FOR TRAINING PURPOSES ONLY
10–23
INS Intelligent Network Service.
InterAlg Interference Algorithm. A single interference algorithm in acell.
Interworking The general term used to describe the inter-operation ofnetworks, services, supplementary services and so on. Seealso IWF.
Interval A recording period of time in which a statistic is pegged.
Interval expiry The end of an interval.
I/O Input/Output.
IOS Intelligent Optimization Platform.
IP Initialisation Process.
IP Internet Protocol.
IPC Inter-Process Communication.
IP, INP INtermodulation Products.
IPR Intellectual PRoperty.
IPSM Integrated Power Supply Module (–48 V).
IPV4 Internet Protocol Version 4.
IPV6 Internet Protocol Version 6.
IPX (A hardware component).
ISAM Indexed Sequential Access Method.
ISC International Switching Centre.
ISDN Integrated Services Digital Network. An integrated servicesnetwork that provides digital connections betweenuser-network interfaces.
ISG Motorola Information Systems group (formally CODEX).
ISO International Organisation for Standardization.
ISQL Informix Structured Query Language.
ISS IP Support Server.
ISUP ISDN User Part (of signalling system No. 7).
IT Inactivity Test (Part of SCCP network connectivity).
ITC Information Transfer Capability.
ITU International Telecommunication Union.
ITU–TSS International Telecommunication Union – TelecommunicationsSector.
IWF InterWorking Function. A network functional entity whichprovides network interworking, service interworking,supplementary service interworking or signalling interworking.It may be a part of one or more logical or physical entities in aGSM PLMN.
IWMSC InterWorking MSC.
IWU InterWorking Unit.
ISSUE 1 REVISION 2K
�MOTOROLA LTD. 2000GPRS01: GPRS Architecture
FOR TRAINING PURPOSES ONLY
10–24
Kk kilo (103).
k Windows size.
K Constraint length of the convolutional code.
KAIO Kernal Asynchronous Input/Output.
kb, kbit kilo-bit.
kbit/s, kbps kilo-bits per second.
kbyte kilobyte.
Kc Ciphering key. A sequence of symbols that controls theoperation of encipherment and decipherment.
kHz kilo-Hertz (103).
Ki Individual subscriber authentication Key (p/o authenticationprocess of AUC).
KIO A class of processor.
KSW Kiloport SWitch board. TDM timeslot interchanger to connectcalls (p/o BSS).
KSWX KSW Expander half size board. Fibre optic distribution ofTDM bus (p/o BSS).
kW kilo-Watt.
ISSUE 1 REVISION 2 L
�MOTOROLA LTD. 2000 GPRS01: GPRS Architecture
FOR TRAINING PURPOSES ONLY
10–25
L
L1 Layer 1.
L2ML Layer 2 Management Link.
L2R Layer 2 Relay function. A function of an MS and IWF thatadapts a user’s known layer2 protocol LAPB onto RLP fortransmission between the MT and IWF.
L2R BOP L2R Bit Orientated Protocol.
L2R COP L2R Character Orientated Protocol.
L3 Layer 3.
L3MM Layer 3 Mobility Management.
LA Location Area. An area in which an MS may move freelywithout updating the location register. An LA may compriseone or several base station areas.
LAC Location Area Code.
LAI Location Area Identity. The information indicating the locationarea in which a cell is located.
LAN Local Area Network.
LANX LAN Extender half size board. Fibre optic distribution of LANto/from other cabinets (p/o BSS etc).
LAPB Link Access Protocol Balanced (of ITU–TSS Rec. x.25).
LAPD Link Access Protocol Data.
LAPDm Link Access Protocol on the Dm channel.
LC Inductor Capacitor (type of filter).
LCF Link Control Function.
LCN Local Communications Network.
LCP Link Control Processor.
LE Local Exchange.
LED Light Emitting Diode.
LF Line Feed.
LI Length Indicator.
LI Line Identity.
LLC Lower Layer Compatibility. The LLC can carry informationdefining the lower layer characteristics of the terminal.
LLC Logical Link Control.
LLC PDU LLC Protocol Data Unit.
Lm Traffic channel with capacity lower than a Bm.
LMP LAN Monitor Process.
LMS Least Mean Square.
LMSI Local Mobile Station Identity. A unique identity temporarilyallocated to visiting mobile subscribers in order to speed upthe search for subscriber data in the VLR, when the MSRNallocation is done on a per cell basis.
LMT Local Maintenance Terminal.
ISSUE 1 REVISION 2L
�MOTOROLA LTD. 2000GPRS01: GPRS Architecture
FOR TRAINING PURPOSES ONLY
10–26
LNA Low Noise Amplifier.
LND Last Number Dialled.
Location area An area in which a mobile station may move freely withoutupdating the location register. A location area may compriseone or several base station areas.
LPC Linear Predictive Code.
LPLMN Local PLMN.
LR Location Register. The GSM functional unit where MSlocation information is stored. The HLR and VLR are locationregisters.
LSSU Link Stations Signalling Unit (Part of MTP transport system).
LSTR Listener Side Tone Rating.
LTA Long Term Average. The value required in a BTS’s GCLKfrequency register to produce a 16.384 MHz clock.
LTE Local Terminal Emulator.
LTP Long Term Predictive.
LTU Line Terminating Unit.
LU Local Units.
LU Location Update.
LV Length and Value.
ISSUE 1 REVISION 2 M
�MOTOROLA LTD. 2000 GPRS01: GPRS Architecture
FOR TRAINING PURPOSES ONLY
10–27
MM Mandatory.
M Mega (106).
M-Cell Motorola Cell.
M&TS Maintenance and Troubleshooting. Functional area ofNetwork Management software which (1) collects anddisplays alarms, (2) collects and displays Software/Hardwareerrors, and (3) activates test diagnostics at the NEs (OMC).
MA Mobile Allocation. The radio frequency channels allocated toan MS for use in its frequency hopping sequence.
MAC Medium Access Control.
MACN Mobile Allocation Channel Number.
Macrocell A cell in which the base station antenna is generally mountedaway from buildings or above rooftop level.
MAF Mobile Additional Function.
MAH Mobile Access Hunting supplementary service.
MAI Mobile Allocation Index.
MAIDT Mean Accumulated Intrinsic Down Time.
MAINT MAINTenance.
MAIO Mobile Allocation Index Offset.
MAP Mobile Application Part (of signalling system No. 7). Theinter-networking signalling between MSCs and LRs and EIRs.
MAPP Mobile Application Part Processor.
MB, Mbyte Megabyte.
Mbit/s Megabits per second.
MCAP Motorola Cellular Advanced Processor.
MCC Mobile Country Code.
MCDF Motorola Customer Data Format used by DataGen for simpledata entry and retrieval.
MCI Malicious Call Identification supplementary service.
MCSC Motorola Customer Support Centre.
MCU Main Control Unit for M-Cell2/6. Also referred to as the MicroControl Unit in software.
MCUF Main Control Unit, with dual FMUX. (Used in M-Cellhorizon).
MCU-m Main Control Unit for M-Cell Micro sites (M-Cellm). Alsoreferred to as the Micro Control Unit in software.
MCUm The software subtype representation of the Field ReplaceableUnit (FRU) for the MCU-m.
MD Mediation Device.
MDG Mobile Detached Flag for GPRS.
MDL (mobile) Management (entity) - Data Link (layer).
ME Maintenance Entity (GSM Rec. 12.00).
ISSUE 1 REVISION 2M
�MOTOROLA LTD. 2000GPRS01: GPRS Architecture
FOR TRAINING PURPOSES ONLY
10–28
ME Mobile Equipment. Equipment intended to access a set ofGSM PLMN and/or DCS telecommunication services, butwhich does not contain subscriber related information.Services may be accessed while the equipment, capable ofsurface movement within the GSM system area, is in motionor during halts at unspecified points.
MEF Maintenance Entity Function (GSM Rec. 12.00).
MF MultiFrame.
MF Multi-Frequency (tone signalling type).
MF MultiFunction block.
MGMT, mgmt Management.
MGR Manager.
MHS Message Handling System.
MHS Mobile Handling Service.
MHz Mega-Hertz (106).
MI Maintenance Information.
MIB Management Information Base. A Motorola OMC-Rdatabase. There is a CM MIB and an EM MIB.
MIC Mobile Interface Controller.
Microcell A cell in which the base station antenna is generally mountedbelow rooftop level. Radio wave propagation is by diffractionand scattering around buildings, the main propagation iswithin street canyons.
min minute(s).
�s micro-second (10–6).
�BCU Micro Base Control Unit.
MIT Management Information Tree. Name of a file on theMotorola OMC-R.
MM Man Machine.
MM Mobility Management.
MME Mobile Management Entity.
MMF Middle Man Funnel process.
MMI Man Machine Interface. The method in which the userinterfaces with the software to request a function or changeparameters.
MMI client A machine configured to use the OMC-R software from anMMI server.
MMI processor MMI client/MMI server.
MMI server A computer which has its own local copy of the OMC-Rsoftware. It can run the OMC-R software for MMI clients tomount.
MML Man Machine Language. The tool of MMI.
MMS Multiple Serial Interface Link. (see also 2Mbit/s link)
MNC Mobile Network Code.
MNR Mobile Not Reachable Flag.
ISSUE 1 REVISION 2 M
�MOTOROLA LTD. 2000 GPRS01: GPRS Architecture
FOR TRAINING PURPOSES ONLY
10–29
MNT MaiNTenance.
MO Mobile Originated.
MO/PP Mobile Originated Point-to-Point messages.
MOMAP Motorola OMAP.
MoU Memorandum of Understanding.
MPC Multi Personal Computer (was p/o OMC).
MPH (mobile) Management (entity) - PHysical (layer) [primitive].
MPTY MultiParTY (Multi ParTY) supplementary service.
MPX MultiPleXed.
MRC Micro Radio Control Unit.
MRN Mobile Roaming Number.
MRP Mouth Reference Point.
MS Mobile Station. The GSM subscriber unit.
MSC Mobile-services Switching Centre, Mobile Switching Centre.
MSCM Mobile Station Class Mark.
MSCU Mobile Station Control Unit.
msec millisecond (.001 second).
MSI Multiple Serial Interface board. Intelligent interface to two2 Mbit/s digital links (see 2 Mbit/s link and DS-2) (p/o BSS).
MSIN Mobile Station Identification Number.
MSISDN Mobile Station International ISDN Number. Published mobilenumber (see also IMSI). Uniquely defines the mobile stationas an ISDN terminal. It consists of three parts: the CountryCode (CC), the National Destination Code (NDC) and theSubscriber Number (SN).
MSP Multiple Subscriber Profile.
MSRN Mobile Station Roaming Number. A number assigned by theMSC to service and track a visiting subscriber.
MSU Message Signal Unit (Part of MTP transport system). Asignal unit containing a service information octet and asignalling information field which is retransmitted by thesignalling link control, if it is received in error.
MT Mobile Terminated. Describes a call or short messagedestined for an MS.
MT (0, 1, 2) Mobile Termination. The part of the MS which terminates theradio transmission to and from the network and adaptsterminal equipment (TE) capabilities to those of the radiotransmission. MT0 is mobile termination with no support forterminal, MT1 is mobile termination with support for an S-typeinterface and MT2 is mobile termination with support for anR-type interface.
MTBF Mean Time Between Failure.
MTM Mobile-To-Mobile (call).
MTP Message Transfer Part.
MT/PP Mobile Terminated Point-to-Point messages.
ISSUE 1 REVISION 2M
�MOTOROLA LTD. 2000GPRS01: GPRS Architecture
FOR TRAINING PURPOSES ONLY
10–30
MTBF Mean Time Between Failures.
MTK Message Transfer LinK.
MTL MTP Transport Layer Link (A interface).
MTP Message Transfer Part.
MTTR Mean Time To Repair.
Multiframe Two types of multiframe are defined in the system: a26-frame multiframe with a period of 120 ms and a 51-framemultiframe with a period of 3060/13 ms.
MU Mark Up.
MUMS Multi User Mobile Station.
MUX Multiplexer.
ISSUE 1 REVISION 2 N
�MOTOROLA LTD. 2000 GPRS01: GPRS Architecture
FOR TRAINING PURPOSES ONLY
10–31
NNAT Network Address Translation.
N/W Network.
NB Normal Burst (see Normal burst).
NBIN A parameter in the hoping sequence.
NCC Network (PLMN) Colour Code.
NCELL Neighbouring (of current serving) Cell.
NCH Notification CHannel.
ND No Duplicates. A database column attribute meaning thecolumn contains unique values (used only with indexedcolumns).
NDC National Destination Code.
NDUB Network Determined User Busy.
NE Network Element (Network Entity).
NEF Network Element Function block.
NET Norme Européennes de Telecommunications.
NETPlan Frequency planning tool.
NF Network Function.
NFS Network File System.
NHA Network Health Analyst. Optional OMC-R processor feature.
NIC Network Interface Card.
NIC Network Independent Clocking.
NIS Network Information Service. It allows centralised control ofnetwork information for example hostnames, IP addressesand passwords.
NIU Network Interface Unit.
NIU-m Network Interface Unit, micro.
NLK Network LinK processor(s).
Nm Newton metres.
NM Network Management (manager). NM is all activities whichcontrol, monitor and record the use and the performance ofresources of a telecommunications network in order toprovide telecommunication services to customers/users at acertain level of quality.
NMASE Network Management Application Service Element.
NMC Network Management Centre. The NMC node of the GSMTMN provides global and centralised GSM PLMN monitoringand control, by being at the top of the TMN hierarchy andlinked to subordinate OMC nodes.
NMSI National Mobile Station Identification number.
NMT Nordic Mobile Telephone system.
NN No Nulls. A database column attribute meaning the columnmust contain a value in all rows.
Normal burst A period of modulated carrier less than a timeslot.
ISSUE 1 REVISION 2N
�MOTOROLA LTD. 2000GPRS01: GPRS Architecture
FOR TRAINING PURPOSES ONLY
10–32
NPI Number Plan Identifier.
NRZ Non Return to Zero.
NSAP Network Service Access Point.
NSAPI Network Layer Service Access Point Identifier.
NSP Network Service Provider.
NSS Network Status Summary.
NT Network Termination.
NT Non Transparent.
NTAAB New Type Approval Advisory Board.
NTP Network Time Protocol.
NUA Network User Access.
NUI Network User Identification.
NUP National User Part (of signalling system No. 7).
NV NonVolatile.
NVRAM Non-Volatile Random Access Memory.
nW Nano-Watt (10–9).
ISSUE 1 REVISION 2 O
�MOTOROLA LTD. 2000 GPRS01: GPRS Architecture
FOR TRAINING PURPOSES ONLY
10–33
O
O Optional.
OA Outgoing Access (CUG SS).
O&M Operations and Maintenance.
OASCU Off-Air-Call-Set-Up. The procedure in which atelecommunication connection is being established whilst theRF link between the MS and the BTS is not occupied.
OCB Outgoing Calls Barred within the CUG.
OCXO Oversized Voltage Controlled Crystal Oscillator.
OD Optional for operators to implement for their aim.
OFL % OverFlow.
offline IDS shutdown state.
online IDS normal operatng state.
OIC Operator Initiated Clear.
OLM Off_Line MIB. A Motorola DataGen database, used to modifyand carry out Radio Frequency planning on multiple BSSbinary files.
OLR Overall Loudness Rating.
OMAP Operations and Maintenance Application Part (of signallingsystem No. 7) (was OAMP).
OMC Operations and Maintenance Centre. The OMC node of theGSM TMN provides dynamic O&M monitoring and control ofthe PLMN nodes operating in the geographical areacontrolled by the specific OMC.
OMC-G Operations and Maintenance Centre — Gateway Part.(Iridium)
OMC-G Operations and Maintenance Centre — GPRS Part.
OMC-R Operations and Maintenance Centre — Radio Part.
OMC-S Operations and Maintenance Centre — Switch Part.
OMF Operations and Maintenance Function (at BSC).
OML Operations and Maintenance Link.
OMP Operation and Maintenance Processor.
OMS Operation and Maintenance System (BSC–OMC).
OMSS Operation and Maintenance SubSystem.
OOS Out Of Service.
OPC Originating Point Code. A part of the label in a signallingmessage that uniquely identifies, in a signalling network, the(signalling) origination point of the message.
ORAC Olympus Radio Architecture Chipset.
OS Operating System.
OSI Open Systems Interconnection.
OSI RM OSI Reference Model.
OSF Operation Systems Function block.
ISSUE 1 REVISION 2O
�MOTOROLA LTD. 2000GPRS01: GPRS Architecture
FOR TRAINING PURPOSES ONLY
10–34
OSF/MOTIF Open Software Foundation Motif. The basis of the GUI usedfor the Motorola OMC-R MMI.
OSS Operator Services System.
Overlap Overlap sending means that digits are sent from one systemto another as soon as they are received by the sendingsystem. A system using ~ will not wait until it has received alldigits of a call before it starts to send the digits to the nextsystem. This is the opposite of en bloc sending where alldigits for a given call are sent at one time.
ISSUE 1 REVISION 2 P
�MOTOROLA LTD. 2000 GPRS01: GPRS Architecture
FOR TRAINING PURPOSES ONLY
10–35
PPA Power Amplifier.
PAB Power Alarm Board.
PABX Private Automatic Branch eXchange.
PACCH Packet Associated Control Channel
PAD Packet Assembler/Disassembler facility.
Paging The procedure by which a GSM PLMN fixed infrastructureattempts to reach an MS within its location area, before anyother network-initiated procedure can take place.
PATH CEPT 2 Mbit/s route through the BSS network.
PBUS Processor Bus.
PBX Private Branch eXchange.
PC Personal Computer.
PCH Paging CHannel. A GSM common control channel used tosend paging messages to the MSs.
PCHN Paging Channel Network.
PCHN Physical Channel.
PCM Pulse Code Modulation (see also 2 Mbit/s link which is thephysical bearer of PCM).
PCN Personal Communications Network.
PCR Preventative Cyclic Retransmission. A form of errorcorrection suitable for use on links with long transmissiondelays, such as satellite links.
PCU Packet Control Unit (p/o GPRS).
PCU Picocell Control unit (p/o M-Cellaccess).
pd Potential difference.
PD Protocol Discriminator.
PD Public Data.
PDB Power Distribution Board.
PDCH Packet Data Channel.
PDF Power Distribution Frame (MSC/LR).
PDN Public Data Networks.
PDN Packet Data Network.
PDTCH Packet Data traffic Channel.
PDU Power Distribution Unit.
PDU Protected Data Unit.
PDU Protocol Data Unit.
PEDC Pan European Digital Cellular.
Peg A single incremental action modifying the value of a statistic.
Pegging Modifying a statistical value.
PH Packet Handler.
PH PHysical (layer).
ISSUE 1 REVISION 2P
�MOTOROLA LTD. 2000GPRS01: GPRS Architecture
FOR TRAINING PURPOSES ONLY
10–36
PHI Packet Handler Interface.
PI Presentation Indicator.
Picocell A cell site where the base station antenna is mounted within abuilding.
PICS Protocol Implementation Conformance Statement.
PID Process IDentifier/Process ID.
PIM PCM Interface Module (MSC).
PIN Personal Identification Number.
PIN Problem Identification Number.
PIX Parallel Interface Extender half size board. Customer alarminterface (p/o BSS).
PIXT Protocol Implementation eXtra information for Testing.
PK Primary Key. A database column attribute, the primary key isa not-null, non-duplicate index.
Plaintext Unciphered data.
PlaNET Frequency planning tool.
PLL Phase Lock Loop (refers to phase locking the GCLK in theBTS).
PLMN Public Land Mobile Network. The mobile communicationsnetwork.
PM Performance Management. An OMC application.
PM-UI Performance Management User Interface.
PMA Prompt Maintenance Alarm. An alarm report level; immediateaction is necessary (see also DMA).
PMS Pseudo MMS.
PMUX PCM MUltipleXer.
PN Permanent Nucleus (of GSM).
PNE Présentation des Normes Européennes.
POI Point of Interconnection (with PSTN).
POTS Plain Old Telephone Service (basic telephone services).
p/o Part of.
pp, p-p Peak-to-peak.
PP Point-to-Point.
ppb Parts per billion.
PPE Primative Procedure Entity.
ppm Parts per million (x 10–6).
PPP Point to Point Protocol.
Pref CUG Preferential CUG.
Primary Cell A cell which is already optimized in the network and has aco-located neighbour whose cell boundary follows theboundary of the said cell. The primary cell has a preferredband equal to the frequency type of the coincident cell.
PROM Programmable Read Only Memory.
ISSUE 1 REVISION 2 P
�MOTOROLA LTD. 2000 GPRS01: GPRS Architecture
FOR TRAINING PURPOSES ONLY
10–37
Ps Location probability.
PSA Periodic Supervision of Accessability.
PSAP Presentation Services Access Point.
PSM Power Supply Module.
PSPDN Packet Switched Public Data Network. Public datacommunications network. x.25 links required for NE to OMCcommunications will probably be carried by PSPDN.
PSTN Public Switched Telephone Network. The UK land linetelephone network.
PSU Power Supply Unit.
PSW Pure Sine Wave.
PTM Point to Multipoint
PTM-G Point to Multipoint for Group.
PTM-M Point to Multipoint for Multicast.
PTO Public Telecommunications Operator.
PTP Point to Point.
PTP-CLNS Point to Point Connectionless Service.
PVC-CONS Point to Point Connection Oriented Service.
PUCT Price per Unit Currency Table.
PVC Permanent Virtual Circuit.
PW Pass Word.
PWR Power.
PXPDN Private eXchange Public Data Network.
ISSUE 1 REVISION 2Q
�MOTOROLA LTD. 2000GPRS01: GPRS Architecture
FOR TRAINING PURPOSES ONLY
10–38
QQA Q (Interface) – Adapter.
Q3 Interface between NMC and GSM network.
Q-adapter Used to connect MEs and SEs to TMN (GSM Rec. 12.00).
QAF Q-Adapter Function.
QEI Quad European Interface. Interfaces four 2 Mbit/s circuits toTDM switch highway (see MSI).
QIC Quarter Inch Cartridge (Data storage format).
QOS Quality Of Service.
Quiescent mode IDS intermediate state before shutdown.
ISSUE 1 REVISION 2 R
�MOTOROLA LTD. 2000 GPRS01: GPRS Architecture
FOR TRAINING PURPOSES ONLY
10–39
RR Value of reduction of the MS transmitted RF power relative to
the maximum allowed output power of the highest powerclass of MS (A).
RA RAndom mode request information field.
RA Routing Area.
RAB Random Access Burst.
RAC Routing Area Code.
RACCH Random Access Control CHannel. A GSM common controlchannel used to originate a call or respond to a page.
RACH Random Access CHannel.
RAI Routing Area Identity.
RAM Random Access Memory.
RAND RANDom number (used for authentication).
RATI Receive Antenna Transceiver Interface.
RAx Rate Adaptation.
RBDS Remote BSS Diagnostic System (a discontinued Motoroladiagnostic facility).
RBER Residual Bit Error Ratio.
RBTS Remote Base Transceiver Station.
RCB Radio Control Board (p/o DRCU).
RCI Radio Channel Identifier.
RCP Radio Control Processor.
RCU Radio Channel Unit. Contains transceiver, digital controlcircuits, and power supply (p/o BSS) (see DRCU).
RCVR Receiver.
RDBMS Relational DataBase Management System (INFORMIX).
RDI Radio Digital Interface System.
RDIS Restricted Digital Information.
RDM Reference Distribution Module.
RDN Relative Distinguished Name. A series of RDN form a uniqueidentifier, the distinguished name, for a particular networkelement.
REC, Rec RECommendation.
REJ REJect(ion).
REL RELease.
RELP Residual Excited Linear Predictive.
RELP-LTP RELP Long Term Prediction. A name for GSM full rate (seefull rate).
resync Resynchronize/resynchronization.
REQ REQuest.
Revgen A Motorola DataGen utility for producing an MMI script from abinary object database.
ISSUE 1 REVISION 2R
�MOTOROLA LTD. 2000GPRS01: GPRS Architecture
FOR TRAINING PURPOSES ONLY
10–40
RF Radio Frequency.
RFC, RFCH Radio Frequency Channel. A partition of the system RFspectrum allocation with a defined bandwidth and centrefrequency.
RFE Receiver Front End (shelf).
RFEB Receiver Front End Board (p/o DRCU II).
RFI Radio Frequency Interference.
RFM Radio Frequency Module.
RFN Reduced TDMA Frame Number.
RFU Reserved for Future Use.
RJ45 Network cable/Connector type.
RISC Reduced Instruction Set Computer.
RL Remote login.
RLC Release Complete.
PLC Radio Link Control.
RLP Radio Link Protocol. An ARQ protocol used to transfer userdata between an MT and IWF. See GSM 04.22.
RLR Receiver Loudness Rating.
RLSD ReLeaSeD.
RMS Root Mean Square (value).
RMSU Remote Mobile Switching Unit.
RNTABLE Table of 128 integers in the hopping sequence.
ROM Read Only Memory.
ROSE Remote Operations Service Element. An ASE which carriesa message between devices over an association establishedby ASCE (a CCITT specification for O & M) (OMC).
Roundtrip Time period between transmit and receive instant of atimeslot in the BTS, propagation determined by the responsebehaviour of the MS and the MS to BTS delay distance.
RPE Regular Pulse Excited.
RPE-LTP Regular Pulse Excitation - Long Term Prediction. The GSMdigital speech coding scheme.
RPOA Recognised Private Operating Agency.
RPR Read Privilege Required. Access to the column is allowedonly for privileged accounts.
RR Radio Resource management.
RR Receive Ready (frame).
RRSM Radio Resource State Machine.
RS232 Standard serial interface.
RSE Radio System Entity.
RSL Radio Signalling Link.
RSLF Radio System Link Function.
RSLP Radio System Link Processor.
ISSUE 1 REVISION 2 R
�MOTOROLA LTD. 2000 GPRS01: GPRS Architecture
FOR TRAINING PURPOSES ONLY
10–41
RSS Radio SubSystem (replaced by BSS).
RSSI Received Signal Strength Indicator.
RSZI Regional Subscription Zone Identity.
RTC Remotely Tuneable Channel Combiner.
RTE Remote Terminal Emulator.
RTF Radio Transceiver Function.
RTF Receive Transmit Functions.
RTS Request to Send. Method of flow control (RS232 Interface).
RU Rack Unit.
Run level System processor operating mode.
Rx Receive(r).
RXCDR Remote Transcoder.
RXF Receive Function (of the RTF).
RXLEV-D Received signal level downlink.
RXLEV-U Received signal level uplink.
RXQUAL-D Received signal quality downlink.
RXQUAL-U Received signal quality uplink.
RXU Remote Transcoder Unit. The shelf which houses theremote transcoder modules in a BSSC cabinet at a remotetranscoder site.
ISSUE 1 REVISION 2S
�MOTOROLA LTD. 2000GPRS01: GPRS Architecture
FOR TRAINING PURPOSES ONLY
10–42
SS/W SoftWare.
SABM Set Asynchronous Balanced Mode. A message whichestablishes the signalling link over the air interface.
SABME SABM Extended.
SACCH Slow Associated Control CHannel. A GSM control channelused by the MS for reporting RSSI and signal qualitymeasurements.
SACCH/C4 Slow Associated Control CHannel/SDCCH/4.
SACCH/C8 Slow Associated Control CHannel/SDCCH/8.
SACCH/T Slow Associated Control CHannel/Traffic channel.
SACCH/TF Slow Associated Control CHannel/Traffic channel Full rate.
SACCH/TH Slow Associated Control CHannel/Traffic channel Half rate.
SAGE A brand of trunk test equipment.
SAP Service Access Point. In the reference model for OSI, SAPsof a layer are defined as gates through which services areoffered to an adjacent higher layer.
SAP System Audits Process.
SAPI Service Access Point Indicator (identifier).
SAW Surface Acoustic Wave.
SB Synchronization Burst (see Synchronization burst).
SBUS Serial Bus.
SC Service Centre (used for Short Message Service).
SC Service Code.
SCCA System Change Control Administration. Software modulewhich allows full or partial software download to the NE(OMC).
SCCP Signalling Connection Control Part (6-8).
SCEG Speech Coding Experts Group (of GSM).
SCH Synchronization CHannel. A GSM broadcast control channelused to carry information for frame synchronization of MSsand identification of base stations.
SCI Status Control Interface.
SCIP Serial Communication Interface Processor.
SCM Status Control Manager.
SCN Sub-Channel Number. One of the parameters defining aparticular physical channel in a BS.
SCP Service Control Point (an intelligent network entity).
SCSI Small Computer Systems Interface.
SCU Slim Channel Unit.
SCU900 Slim Channel Unit for GSM900.
SDCCH Stand-alone Dedicated Control CHannel. A GSM controlchannel where the majority of call setup occurs. Used forMS to BTS communications before MS assigned to TCH.
ISSUE 1 REVISION 2 S
�MOTOROLA LTD. 2000 GPRS01: GPRS Architecture
FOR TRAINING PURPOSES ONLY
10–43
SDL Specification Description Language.
SDT SDL Developement Tool.
SDU Service Data Unit.
SDR Special Drawing Rights (an international “basket” currency forbilling).
SE Support Entity (GSM Rec. 12.00).
Secondary Cell A cell which is not optimized in the network and has aco-located neighbour whose cell boundary follows theboundary of the said cell. The secondary cell has a preferredband the same as that of its own frequency type.
SEF Support Entity Function (GSM Rec.12.00).
SFH Slow Frequency Hopping.
SI Screening Indicator.
SI Service Interworking.
SI Supplementary Information.
SIA Supplementary Information A.
SID Silence Descriptor.
SIF Signal Information Field. The bits of a message signal unitthat carry information for a certain user transaction; the SIFalways contains a label.
SIM Subscriber Identity Module. Removable module which isinserted into a mobile equipment; it is considered as part ofthe MS. It contains security related information (IMSI, Ki,PIN), other subscriber related information and the algorithmsA3 and A8.
SIMM Single Inline Memory module.
SIMM System Integrated Memory Module.
SIO Service Information Octet. Eight bits contained in a messagesignal unit, comprising the service indicator and sub-servicefield.
SITE BSC, BTS or collocated BSC-BTS site.
SIX Serial Interface eXtender. Converts interface levels to TTLlevels. Used to extend 2 serial ports from GPROC to externaldevices (RS232, RS422, and fibre optics).
SK Secondary Key. A database column attribute, the secondarykey indicates an additional index and/or usage as acomposite key.
SL Signalling Link.
SLNK Serial Link.
SLR Send Loudness Rating.
SLTM Signalling Link Test Message.
SM Switch Manager.
SM Summing Manager.
SMAE System Management Application Entity (CCITT Q795, ISO9596).
SMCB Short Message Cell Broadcast.
ISSUE 1 REVISION 2S
�MOTOROLA LTD. 2000GPRS01: GPRS Architecture
FOR TRAINING PURPOSES ONLY
10–44
SME Short Message Entity.
SMG Special Mobile Group.
SMP Motorola Software Maintenance Program.
SMS Short Message Service.
SMSCB Short Message Service Cell Broadcast.
SMS-SC Short Message Service - Service Centre.
SMS/PP Short Message Service/Point-to-Point.
Smt Short message terminal.
SN Subscriber Number.
SND SeND.
SNDCP Subnetwork Dependant Convergence Protocol
SNDR SeNDeR.
SN—PDU SNDCP PDU.
SNR Serial NumbeR.
SOA Suppress Outgoing Access (CUG SS).
SP Service Provider. The organisation through which thesubscriber obtains GSM telecommunications services. Thismay be a network operator or possibly a separate body.
SP Signalling Point.
SP Special Product.
SP SPare.
SPC Signalling Point Code.
SPC Suppress Preferential CUG.
SPI Signalling Point Inaccessible.
SPP Single Path Preselector.
SQE Signal Quality Error.
SQL Structured Query Language.
SRD Service Request Distributor.
SRES Signed RESponse (authentication).
SS Supplementary Service. A modification of, or a supplementto, a basic telecommunication service.
SS System Simulator.
SSA SCCP messages, Subsystem-allowed (see CCITT Q.712para 1.15).
SSAP Site System Audits Processor.
SSC Supplementary Service Control string.
SSF Subservice Field. The level 3 field containing the networkindicator and two spare bits.
SSM Signalling State Machine.
SSN SubSystem Number.
SSP Service Switching Point (an intelligent network element).
ISSUE 1 REVISION 2 S
�MOTOROLA LTD. 2000 GPRS01: GPRS Architecture
FOR TRAINING PURPOSES ONLY
10–45
SSP SCCP messages, Subsystem-prohibited (see CCITT Q.712para 1.18).
SSP SubSystem Prohibited message.
SSS Switching SubSystem (comprising the MSC and the LRs).
SS7 ANSI Signalling System No. 7 (alias C7).
STAN Statistical ANalysis (processor).
STAT STATistics.
stats Statistics.
STC System Timing Controller.
STMR Side Tone Masking rating.
SUERM Signal Unit Error Rate Monitor.
STP Signalling Transfer Point.
Superframe 51 traffic/associated control multiframes or 26broadcast/common control multiframes (period 6.12s).
Super user User account that can access all files, regardless ofprotection settings, and control all user accounts.
SURF Sectorized Universal Receiver Front-end (Used inHorizonmacro).
SVC Switch Virtual Circuit.
SVM SerVice Manager.
SVN Software Version Number.
SW Software.
SWFM SoftWare Fault Management.
sync synchronize/synchronization.
Synchronization burst Period of RF carrier less than one timeslot whose modulationbit stream carries information for the MS to synchronize itsframe to that of the received signal.
SYS SYStem.
SYSGEN SYStem GENeration. The Motorola procedure for loading aconfiguration database into a BTS.
ISSUE 1 REVISION 2T
�MOTOROLA LTD. 2000GPRS01: GPRS Architecture
FOR TRAINING PURPOSES ONLY
10–46
TT Timer.
T Transparent.
T Type only.
T43 Type 43 Interconnect Board. Provides interface to 12unbalanced (6-pair) 75 ohm (T43 coax connectors) lines for2 Mbit/s circuits (See BIB).
TA Terminal Adaptor. A physical entity in the MS providingterminal adaptation functions (see GSM 04.02).
TA Timing Advance.
TAC Type Approval Code.
TACS Total Access Communications System (European analoguecellular system).
TAF Terminal Adaptation Function.
TATI Transmit Antenna Transceiver Interface. The TATI consistsof RF combining equipments, either Hybrid or CavityCombining. (See CCB).
TAXI Transparent Asynchronous Transmitter/Receiver Interface(physical layer).
TBD To Be Determined.
TBF Temporary Block Flow.
TBR Technical Basis for Regulation.
TBUS TDM Bus.
TC Transaction Capabilities.
TCAP Transaction Capabilities Application Part (of SignallingSystem No. 7).
TCB TATI Control Board.
TCH Traffic CHannel. GSM logical channels which carry eitherencoded speech or user data.
TCH/F A full rate TCH.
TCH/F2.4 A full rate TCH at � 2.4 kbit/s.
TCH/F4.8 A full rate TCH at 4.8 kbit/s.
TCH/F9.6 A full rate TCH at 9.6 kbit/s.
TCH/FS A full rate Speech TCH.
TCH/H A half rate TCH.
TCH/H2.4 A half rate TCH at � 2.4 kbit/s.
TCH/H4.8 A half rate TCH at 4.8 kbit/s.
TCH/HS A half rate Speech TCH).
TCI Transceiver Control Interface.
TCP/IP Transmission Control Protocol/Internet Protocol.
TC-TR Technical Commitee Technical Report.
TCU Transceiver Control Unit.
TDF Twin Duplexed Filter. (Used in M-Cellhorizon).
ISSUE 1 REVISION 2 T
�MOTOROLA LTD. 2000 GPRS01: GPRS Architecture
FOR TRAINING PURPOSES ONLY
10–47
TDM Time Division Multiplexing.
TDMA Time Division Multiple Access.
TDU TopCell Digital Unit.
TE Terminal Equipment. Equipment that provides the functionsnecessary for the operation of the access protocols by theuser.
Tei Terminal endpoint identifier.
TEI Terminal Equipment Identity.
TEMP TEMPorary.
TEST TEST control processor.
TFA TransFer Allowed.
TFI Temporary Flow Identifier.
TFP TransFer Prohibited.
TFTP Trivial File Transfer Protocol.
TI Transaction Identifier.
TI Tunnel Identifier.
Timeslot The multiplex subdivision in which voice and signalling bitsare sent over the air. Each RF carrier is divided into 8timeslots.
Timing advance A signal sent by the BTS to the MS. It enables the MS toadvance the timing of its transmission to the BTS so as tocompensate for propagation delay.
TLLI Temporary Logical Link Identity.
TLV Type, Length and Value.
TM Traffic Manager.
TMI TDM Modem Interface board. Provides analogue interfacefrom IWF to modems for 16 circuits (p/o IWF).
TMM Traffic Metering and Measuring.
TMN Telecommunications Management Network. Theimplementation of the Network Management functionalityrequired for the PLMN is in terms of physical entities whichtogether constitute the TMN.
TMSI Temporary Mobile Subscriber Identity. A unique identitytemporarily allocated by the MSC to a visiting mobilesubscriber to process a call. May be changed between callsand even during a call, to preserve subscriber confidentiality.
TN Timeslot Number.
TON Type Of Number.
Traffic channels Channels which carry user’s speech or data (see also TCH).
Traffic unit Equivalent to an erlang.
Training sequence Sequence of modulating bits employed to facilitate timingrecovery and channel equalization in the receiver.
TRAU Transcoder Rate Adaption Unit.
TRU TopCell Radio unit.
ISSUE 1 REVISION 2T
�MOTOROLA LTD. 2000GPRS01: GPRS Architecture
FOR TRAINING PURPOSES ONLY
10–48
TRX Transceiver(s). A network component which can serve fullduplex communication on 8 full-rate traffic channels accordingto specification GSM 05.02. If Slow Frequency Hopping(SFH) is not used, then the TRX serves the communicationon one RF carrier.
TS Technical Specification.
TS TeleService.
TS TimeSlot (see Timeslot).
TSA TimeSlot Acquisition.
TSA TimeSlot Assignment.
TSDA Transceiver Speech & Data Interface.
TSC Training Sequence Code.
TSI TimeSlot Interchange.
TSDI Transceiver Speech and Data Interface.
TSM Transceiver Station Manager.
TSW Timeslot SWitch.
TTCN Tree and Tabular Combined Notation.
TTL Transistor to Transistor Logic.
TTY TeleTYpe (refers to any terminal).
TU Traffic Unit.
TUP Telephone User Part (SS7).
TV Type and Value.
Tx Transmit(ter).
TXF Transmit Function (of the RTF).
TXPWR Transmit PoWeR. Tx power level in theMS_TXPWR_REQUEST and MS_TXPWR_CONFparameters.
TxBPF Transmit Bandpass Filter.
ISSUE 1 REVISION 2 U
�MOTOROLA LTD. 2000 GPRS01: GPRS Architecture
FOR TRAINING PURPOSES ONLY
10–49
UUA Unnumbered Acknowledgment. A message sent from the
MS to the BSS to acknowledge release of radio resourceswhen a call is being cleared.
UDI Unrestricted Digital Information.
UDP User Datagram Protocol.
UDUB User Determined User Busy.
UHF Ultra High Frequency.
UI Unnumbered Information (Frame).
UIC Union International des Chemins de Fer.
UID User ID. Unique number used by the system to identify theuser.
UL Upload (of software or database from an NE to a BSS).
Um Air interface.
UMTS Universal Mobile Telecommunication System.
UPCMI Uniform PCM Interface (13 bit).
UPD Up to Date.
Uplink Physical link from the MS towards the BTS (MS transmits,BTS receives).
UPS Uninterruptable Power Supply.
UPU User Part Unavailable.
Useful part of burst That part of the burst used by the demodulator; differs fromthe full burst because of the bit shift of the I and Q parts ofthe GMSK signal.
USSD Unstructured Supplementary Service Data.
UUS User-to-User Signalling supplementary service.
ISSUE 1 REVISION 2V
�MOTOROLA LTD. 2000GPRS01: GPRS Architecture
FOR TRAINING PURPOSES ONLY
10–50
VV Value only.
VA Viterbi Algorithm (used in channel equalizers).
VAD Voice Activity Detection. A process used to identify presenceor absence of speech data bits. VAD is used with DTX.
VAP Videotex Access Point.
VBS Voice Broadcast Service.
VC Virtual Circuit.
VCO Voltage Controlled Oscillator.
VCXO Voltage Controlled Crystal Oscillator.
VDU Visual Display Unit.
VGCS Voice Group Call Service.
VLR Visitor Location Register. A GSM network element whichprovides a temporary register for subscriber information for avisiting subscriber. Often a part of the MSC.
VLSI Very Large Scale Integration (in ICs).
VMSC Visited MSC. (Recommendation not to be used).
VOX Voice Operated Transmission.
VPLMN Visited PLMN.
VSC Videotex Service Centre.
V(SD) Send state variable.
VSP Vehicular Speaker Phone.
VSWR Voltage Standing Wave Ratio.
VTX host The components dedecated to Videotex service.
ISSUE 1 REVISION 2 W
�MOTOROLA LTD. 2000 GPRS01: GPRS Architecture
FOR TRAINING PURPOSES ONLY
10–51
WWAN Wide Area Network.
WPA Wrong Password Attempts (counter).
WS Work Station. The remote device via which O&M personnelexecute input and output transactions for networkmanagement purposes.
WSF Work Station Function block.
WWW World Wide Web.
ISSUE 1 REVISION 2X
�MOTOROLA LTD. 2000GPRS01: GPRS Architecture
FOR TRAINING PURPOSES ONLY
10–52
XX.25 CCITT specification and protocols for public packet-switched
networks (see PSPDN).
X.25 link A communications link which conforms to X.25 specificationsand uses X.25 protocol (NE to OMC links).
XBL Transcoder to BSS Link. The carrier communications linkbetween the Transcoder (XCDR) and the BSS.
XCB Transceiver Control Board (p/o Transceiver).
XCDR Full-rate Transcoder. Provides speech transcoding and 4:1submultiplexing (p/o BSS, BSC or XCDR).
XCDR board The circuit board required to perform speech transcoding atthe BSS or (R)XCDR). Also known as the MSI (XCDR)board. Interchangeable with the GDP board.
XFER Transfer.
XID eXchange IDentifier.
X-Term X terminal window.
ISSUE 1 REVISION 2 Z
�MOTOROLA LTD. 2000 GPRS01: GPRS Architecture
FOR TRAINING PURPOSES ONLY
10–53
ZZC Zone Code