Professional Documents
Culture Documents
Annexure 3 SGSN Acceptance Test Procedure: Technical &development Circle SGSN A/T Procedure Jabalpur GSM Phase V.1
Annexure 3 SGSN Acceptance Test Procedure: Technical &development Circle SGSN A/T Procedure Jabalpur GSM Phase V.1
JABALPUR
Annexure 3
SGSN Acceptance Test Procedure
3.0 Back up & restoration As per Backup and restore_SGSN.pdf
4.0 Interface Verification
General:
This test document verifies different interfaces supported by SGSN as required.
Prerequisites:
Node Properties
All node properties will be set to the default values. Some node properties may be changed
during the execution of the test cases.
The SGSN node should be up and running.
Gb Interface Verification
4.1.1 Verification for Gb interface using Frame Relay
Objective
The test case is considered successful if the state of the NS-VC for the Gb interface is deblocked
and alive
Pre-Conditions
The SGSN and BSC are connected and configured to use Gb interface over Frame Relay
Action:Check the status of the Gb interface
Command:gsh get_nsvc <nsvci>
Result:The blocking state of the NSVC is deblocked and operational state is alive.
4.1
Gr interface Verification
4.2.1 Gr interface using narrowband or wideband SS7
Objective
The test case is considered successful if the status of the MTP-L3 links defined in the node for Gr
interface is in service.
Pre-conditions
The Gr interface is configured to use narrowband/wideband SS7.
Action:Check the status of all the configured MTP-L3 links.
Command:gsh action_ss7_sys_statlinks
Result: The links configured for the Gr interface are in service.
4.2
TD/NS/GSM/PHASE V.1/BSS/1280
Page 1 of 31
4.2.2
Objective
The Test case is considered to be successful if the status of the m3ua association for the Gr
interface is active
Pre-conditions
The Gr interface is configured to use SIGTRAN
Action:Check the status of an m3ua associations using SIGTRAN over Gr interface.
Command:gsh action_ss7_m3ua_association_status net <networkname> -nid <nodeid>
-said <said>
Result: The Status of the m3ua association is active.
4.3
Gn interface verification
Objective
The Test case is considered successful if the SGSN receives a response from the GGSN for a
ping or GTP Echo Request sent by it.
Pre-conditions:
The SGSN and GGSN are connected and fully configured
Action: Send a ping request or GTP Echo request to the GGSN GTP IP.
Result: the response of the ping (or GTP Echo) is received from GGSN.
4.4
Objective
The Test case is considered successful if the SGSN is accessible by EMM
Pre-Conditions
EMM is configured to pull the CDRs from SGSN and OSS integration to SGSN is complete
Action:Verify that FTP from EMM to SGSN is successful
Result: The EMM can FTP the CDRs from the SGSN using the Gom Network.
4.5
Ge Interface Verification
Objective
The test case is considered successful if the status of the SSN 146 for the remote DPC using Ge
interface is allowed
Pre-conditions
The remote node (SCP/CCN) is connected to SGSN on the Ge Interface.
Action:check the SSN Status for the CCN connected to the SGSN
Command:gsh action_ss7_sccp_remote_sap_statssnspc net <networkname> -nid
<nodeid> -dpc <dpc> -ssn 146
Result: The status of the SSN 146 is allowed
TD/NS/GSM/PHASE V.1/BSS/1280
Page 2 of 31
Functional Test
5.1
5.1.1
Mobility Management
GPRS ATTACH
Objective
To perform a successful GPRS Attach.
Preconditions
The MS is switched off. SGSN address in HLR unknown.
1 Action: Switch on Mobile Subscriber (MS)
2 Action: Check the subscriber in the SGSN by CLI:
Command: gsh get_subscriber -a -imsi <imsi>>
Result: the MS is in state Standby/Ready
5.1.2
GPRS DETACH
Objective
The Mobile subscriber will perform a detach from the network when powering off.
Preconditions
Mobile Subscriber is GPRS attached.
1 Action: Switch MS off
Result: Detached
2 Action: Check the subscriber in the SGSN by CLI:
Command: gsh get_subscriber -a -imsi <imsi>
Result: the MS is in state idle
5.1.3
Cell Update
Objective
The Mobile subscriber will perform a cell update successfully.
Pre-conditions
The MS is attached to the GPRS network and is in ready state
Action:Check the CGI value of the attached MS.
Command:gsh get_subscriber msisdn <msisdn>
Result: The CGI value of the subscriber is noted
Action: Move the MS to another Cell and check the Value of the CGI
TD/NS/GSM/PHASE V.1/BSS/1280
Page 3 of 31
5.2
Session Management
TD/NS/GSM/PHASE V.1/BSS/1280
Page 4 of 31
Objective
The objective of the test case is to verify PDP context deactivation by the MS.
1 Action: Check the PDP Context status in the SGSN
Command: gsh get_subscriber -a -msisdn <msisdn>
Result: PDP context is active for the concerned user.
2 Action: Delete the PDP context from the MS
Result: PDP context is deactivated by the MS
3 Action : Use CLI to check the PDP Context status in connected SGSN
Command: gsh get_subscriber -a -imsi <imsi>
Result: There is no active PDP context for the subscriber.
5.2.2.2
Objective
The objective of the test case is to verify PDP context deletion by the SGSN
1 Action: Check the PDP Context status in the SGSN
Command: gsh get_subscriber -a -msisdn <msisdn>
Result: PDP context is active for the concerned user.
2 Action: Delete the PDP context from the SGSN
Command: gsh delete_subscriber -msisdn <msisdn>
Result: PDP context is deleted by the SGSN
3 Action : Use CLI to check the PDP Context status in SGSN
Command: gsh get_subscriber -a -msisdn <msisdn>
Result: Subscriber is not registered in the SGSN.
5.2.2.3
Objective
The objective of the test case is to verify PDP context deactivation by the HLR
1 Action: Check the PDP Context status in the SGSN
Command: gsh get_subscriber -a -msisdn <msisdn>
Result: PDP context is active for the concerned user.
2 Action: Delete the PDP context from the HLR
Command: hgpde:msisdn=<msisdn>,pdpid=<pdpid>;
Result: PDP context is deleted by the HLR
3 Action : Use CLI to check the PDP Context status in SGSN
Command: gsh get_subscriber -a -msisdn <msisdn>
TD/NS/GSM/PHASE V.1/BSS/1280
Page 5 of 31
Objective
The objective of the test case is to verify the status of the GPRS subscriber in the SGSN with
active PDP context
1 Action: Check the subscriber status in SGSN when the MS is GPRS attach
Command: gsh get_subscriber -a -msisdn <msisdn>
Result: The subscriber is attached to the GPRS network
2 Action: Activate the PDP context from the MS and start payload session
Result: PDP context is activated
3 Action : Check the status of the subscriber in SGSN
Command: gsh get_subscriber -a -imsi <imsi>
Result: The subscriber has an active PDP context and mobility management state is
ready/standby.
TD/NS/GSM/PHASE V.1/BSS/1280
Page 6 of 31
6.0
6.1
Redundancy test
Gn Redundancy Verification
Objective
The objective of the test case is to verify the redundancy of the SGSN on the Gn interface.
1 Action: Take out the cable from the first Gn board.Verify that the PDP-context activation has
been performed successfully.
Command: user@host> gsh get_subscriber msisdn < msisdn > -a
Result: Subscriber data should be printed for the subscriber.
2. Repeat the same steps after taking out the cable from the second Gn board.
6.2
Gr Redundancy Verification
Objective
The Objective of the test is case is to verify the redundancy of the Gr interface
1 Action: Take out the one of the cables connected for Gr interface.
Result: One of the Gr interface cable is taken out.
2 Action: Delete an attached subscriber from the SGSN
Command:gsh delete_subscriber msisdn <msisdn>
Result : The Subscriber is detached from the GPRS network
3 Action: Check the subscriber status in the HLR
Result: SGSN address in the subscriber profiles unknown
4 Action: check the subscriber state in the SGSN
Command: gsh get_subscriber msisdn <msisdn>
Result: Subscriber is not registered in SGSN
6.3
Objective
The objective of the test case is to verify the redundancy of the SGSN on the Gom interface.
1 Action: Take out the cable from first Gom board and verify that the O&M network
(EMM/OSS/NTP) can access the SGSN.
Result : The O&M network is accessible.
2.Repeat the same steps after taking out the 2nd Gom cable
TD/NS/GSM/PHASE V.1/BSS/1280
Page 7 of 31
7.0
Fault management
Preconditions
The SGSN and GGSN have no active alarms.
Demo Execution
Action 1 Generate an alarm in the SGSN by taking out one interface cable
Result One of the interface cable (Gn/Gom/Gr) is taken out
Action 2 Check that an alarm is generated in the node for the down interface
Command:gsh list_alarms
Result Alarm is generated in the node.
Action 3 Generate an alarm by blocking a PIU and check the status of the PIU
Command: gsh block_eq eq { EqID }
gsh get_eq_info eq { EqID }
Result The Hardware is blocked.
Action 4 Check that an alarm is generated in the node for the blocked hardware
Command:gsh list_alarms
Result Alarm is generated in the node.
Action 5 Retrieve this alarm from the log file
Command:cd /export/logs/fm_alarm/tmp
tail f fm_alarm.X
Result The generated alarm is logged in the path /logs/fm_alarm/ with the time
stamp
Action 6 Check the current recent events list in the node
Command:gsh list_events
Result The recent event lists are displayed.
8.0
Health Check
Introduction
The purpose of this document is to describe a procedure for a quick health check of a Serving
GPRS Support Node (SGSN). The health check can be performed partly or entirely on a daily
basis or when a malfunction is suspected
General Health Check Procedures
TD/NS/GSM/PHASE V.1/BSS/1280
Page 8 of 31
The general health check procedures described in the following sections can be carried out on a
daily basis or whenever deemed necessary.
Checking Alarms and Events
Follow the instructions in this section to check for unknown active alarms or unknown events. Act
on all alarms and events according to the corresponding alarm or event descriptions. It is
important to act on all alarms even those with low severity such as minor, warning, and
indeterminate.
1 Action: Check the alarms in the node
Command: gsh list_alarms
Result: The active alarms in the node are displayed. There should not be any unexpected
alarms.
2 Action Check the alarm history in the fm_alarm logs located in the /tmp/OMS_LOGS/fm_alarm/
directory.
Result The Alarm history are seen
3 Action Check the events in the node.
Command: gsh list_events
Result: The events in the node are displayed. There should not be any unexpected events.
Checking Counters and KPIs
The SGSN is healthy if counters that show numbers of currently attached users vary, and
counters that show successful or unsuccessful actions behave naturally. The counters are
described in Counter Description in the ALEX.
Additional information on the behavior of the SGSN can be collected by using
Key Performance Indicator (KPI).
Follow the instructions below to check counters and calculate KPIs.
1 Action Check the latest Performance Data Collection (PDC) counter values.The following
command displays the counter values for the last hour:
Command:pdc_counters.pl -n 1
Result Values for the PDC counters for the last one hour are displayed.
2 Action Calculate the recommended KPIs.The following command displays the KPI values for
the last hour:
Command:pdc_kpi.pl -n 1
Result KPI values for the last one hour are displayed
Checking for Hardware and Software Failures
Follow the instructions below to check for hardware and software failures.
1 Action Check the In-Service Performance (ISP) as follows:
Command:less /tmp/DPE_COMMONLOG/isp.log
Result The log file displays hardware or software failures and restarts.
TD/NS/GSM/PHASE V.1/BSS/1280
Page 9 of 31
6 Action Run the following command to check if the remote Signaling Point Code (SPC) of a
remote Service Access Point (SAP) is available:
gsh action_ss7_sccp_remote_sap_statspc -dpc DPC ssn SSN
Result The Status is set to Allowed.
SGSN (W) Interface Health Check
Follow the instructions below to perform a health check of the interfaces for WCDMA Systems.
1 Action Run the following command for each Radio Network Controller (RNC):
Command:gsh get_rnc RncName
Result Check that the Status is set to IN SERVICE.
TD/NS/GSM/PHASE V.1/BSS/1280
Page 10 of 31
2 Action Run the following command to check if the remote Signaling Point Code (SPC) of a
remote Service Access Point (SAP) is available:
gsh action_ss7_sccp_remote_sap_statspc -dpc DPC ssn SSN
Result Check that the Status is set to Allowed.
5 Support
If errors detected during the health check cannot be resolved, refer to Troubleshooting or contact
your local Ericsson support.
9.0
Objective
This demo case verifies that the SGSN is synchronized to NTP server which is an external clock.
Preconditions
The NTP server is integrated to SGSN
1 Action Check that the NTP Server is defined in the SGSN.
Command:gsh list_ntp_server
gsh get_ntp_server ip <ntpserverip>
Result: The NTP servers are configured in the node.
2 Action Check the NTP synchronization status in the SGSN
Command: ntpq p
Result The NTP servers defined in the SGSN are listed and star (*) symbol is there before the
NTP server IP address from which SGSN is synchronized.
10.0
General
This is the Test Description for SGSN system Test as required.
Prerequisites:
Node Properties
All node properties will be set to the default values. Some node properties may be changed
during the execution of the test cases.
The Node should be up and running
1 Action Check the status of all the PIU
Command:gsh get_eq_info eq { EqID }
Result Verify that the operational state is up and Adminstate is unblocked for each PIU
2 Action Check the equipment identifier for the Active NCB
Command: gsh get_active_ncb
Result The Equipment ID for the active NCB is listed
TD/NS/GSM/PHASE V.1/BSS/1280
Page 11 of 31
Objective This demo case verifies that the subscribers with active PDP contexts in the node are
listed down in the SGSN.
Pre-conditions
The Node is up and running
1 Action List down the active subscribers in the SGSN
Comamnd: ./ci list -active
Result The currently active subscribers in the node are displayed
2 Action List down the stats of the number of subscribers which are attached ,idle and active
Command: ./ci stats
Result The statistics showing the number of subscribers which are attached,idle and active are
displayed for GSM and WCDMA network.
TD/NS/GSM/PHASE V.1/BSS/1280
Page 12 of 31
12
QoS Negotiations
Objective This demo case verifies the QoS negotiation between MS ,SGSN and HLR.
Preconditions
QoS parameter for a subscriber in the HLR is set to minimum (e.g. Background traffic class and
MBRU and MBRD to 64 kbits/sec)
1 Action Turn ON the MS & request a pdp-context with QoS parameters higher than the
subscribed QoS (e.g. Background traffic class with MBRD/MBRU to 384 Kbits/s).
Result: Pdp-context is successful
2 Action: Check the negotiated QoS parameters in the SGSN
Command:gsh get_subscriber imsi Imsi a
Result: The negotiated QoS is the subscribed QoS as defined in HLR.
3 Action: Send some payload
Result: Payload is successful. SGSN participate in the successful QoS negotiation.
12 (a) Traffic and Statistical Check
12.1 Traffic and Statistical Check in SGSN
Objective
This demo case verifies the number of subscribers with GPRS attach and active PDP context in
SGSN and throughput (uplink and downlink traffic)
Preconditions
The node is up and running.
1 Action: Check the number of attached and active subscribers
Command: ./ci stats
Result: Printout indicates the number of attached subscriber and subscriber with active PDP
context.
2 Action: Check the throughput in the SGSN for the last one hour.
Command: pdc_counters.pl
Result: The Value of the counters downlinkSndcpNpduSent downlinkSndcpOctetSent
uplinkSndcpNpduReceived uplinkSndcpOctetReceivedMode
are noted down for the outgoing
and incoming network packet data units.
12.2
Objective
This demo case verifies the number of subscribers active PDP context in GGSN and throughput
(uplink and downlink traffic)
Preconditions
The node is up and running.
1 Action: Check the number of subscribers with active PDP context
TD/NS/GSM/PHASE V.1/BSS/1280
Page 13 of 31
Charging Functions
Activation and Deactivation of PDP Context
Objective
The demo case demonstrates that an S-CDR is properly created and stored
on the redundant disk system when the MS performs a data transfer session.
Preconditions
The MS must be defined in the HLR with a GPRS subscription
(NAM=0). A corresponding APN must be defined and connected to the
GGSN. In the packet data network (PDN) of this APN a server must be
accessible for user traffic (for example FTP, telnet, or HTTP).
1 Action: Display all IMSI number series defined in the GSN.
Command: gsh list_imsins
Result: Printout showing the IMSI number series.
Comment: Verify that the IMSI number used in the demo belongs to
this IMSI series.
2 Action: Determine the most recently produced CDR (from the root
directory on the Node Controller Board (NCB)).
Command: ls -ltr /export/charging/chsLog/tmp/
Result: The contents of the temporary CDR directory are listed.
Comment: Note the running number of the chsLog.xxx file.
3 Action: Set the open duration of the charging logfiles to 15 minutes
to avoid closure of these during execution of this demo case.
Command: gsh get_chs_config chsLog
Command: gsh set_chs_config chsLog -od 15
Result: The command is executed.
4 Action: Power on the MS and perform an attach.
Result: The MS is attached.
5 Action: Perform a PDP context activation, for example by means of
the Hyper terminal connected to the MS, or other means such as WAP.
Result: A PDP Context is activated for the MS to the called APN.
TD/NS/GSM/PHASE V.1/BSS/1280
Page 14 of 31
Page 15 of 31
Objective
The demo case demonstrates that a pre-paid subscriber is charged in real time for the access of
GPRS network.
Pre-conditions
CCN is connected to the SGSN and Ge interface is up and running.A pre-paid subscriber is
attached to the network
1 Action Check that SSN 146 is allowed
Command:gsh action_ss7_sccp_remote_sap_statssnspc net <networkname> -nid
<nodeid> -dpc <dpc> -ssn 146
Result The SSN 146 is allowed
2 Action Perform a payload session using pre-paid SIM card and check the status in the SGSN
Command:gsh get_subscriber msisdn <msisdn> -a
Result The pre-paid subscriber has an active PDP context.
3 Action Terminate the PDP session and check in the SGSN
Command: gsh get_subscriber msisdn <msisdn> -a
Result Pre-paid subscriber has no active PDP context.
4 Action Verify that the pre-paid subscriber was charged as soon as the PDP was deactivated
Result Pre-paid subscriber is charged successfully in real time soon after deactivation of the PDP
context.
TD/NS/GSM/PHASE V.1/BSS/1280
Page 16 of 31
14
14.1
Objective
This demo case verifies the behavior of the purge function, which allows the
SGSN to inform the HLR that it has deleted the Mobility Management (MM)
and PDP contexts of a detached subscriber.
Preconditions
The test subscriber is attached in the SGSN with an active PDP context.
1 Action: Verify that the subscriber is attached.
Command: gsh get_subscriber -a -imsi <imsi>
Result: Printout indicates that the subscriber is attached in the
SGSN.
2 Action: Delete the subscriber data from the SGSN.
Command: gsh delete_subscriber -imsi <imsi>
Result: This causes the deletion of MM and PDP contexts of the MS. Purge MS message is sent
to HLR. HLR sends Purge MS Res back.
3 Action: Verify that the subscriber has been purged.
Command: gsh get_subscriber -a -imsi <imsi>
Result: The subscriber is no longer registered in the SGSN.
4 Action: Print the subscriber location in the HLR.
Command: HGSDP:imsi=<imsi>,loc;
Result: In the HGSDP printout you will see the SGSN number where the subscriber was
registered, and you will see an extra line saying MS PURGED IN SGSN.
Note : This command is applicable to Ericsson AXE HLR only.
14.2
Objective
This demo case verifies the HLR-initiated detach when the location is reset
from the HLR.
Preconditions
Subscriber is attached in the SGSN and the HLR location data points to the
correct SGSN. Get the subscriber data for that IMSI being used:
HGSDP:IMSI=imsi,all;
HGPDP:IMSIS=imsis;
SGSN: gsh get_subscriber -imsi <imsi>
Note : HLR related commands are applicable to Ericsson AXE HLR only
TD/NS/GSM/PHASE V.1/BSS/1280
Page 17 of 31
15
Objective
To demonstrate that the BSC is connected to the same SGSN to which at least an RNC is
connected and the Gb interface is up and running.
Pass/Fail Criteria
This demo case is considered to be successful when the NSVC state in case of Gb over FR is
de blocked and alive or remote IP end point status is OK in case of Gb over IP.
TD/NS/GSM/PHASE V.1/BSS/1280
Page 18 of 31
15.1
Verification for Gb interface using Frame Relay
Objective
The test case is considered successful if the state of the NS-VC for the Gb interface is deblocked
and alive
Pre-Conditions
The SGSN and BSC are connected and configured to use Gb interface over Frame Relay
1 Action:Check the status of the Gb interface
Command:gsh get_nsvc <nsvci>
Result:The blocking state of the NSVC is deblocked and operational state is alive.
15.2 Verification for Gb interface using Internet Protocol
Objective
The test case is considered successful if the state of the Remote IP end point for the NSE using
Gb over IP is OK.
Pre-conditions:
The SGSN and BSC are defined and connected to use Gb interface over IP
1 Action:Check the status of the remote IP end point for the NSE using Gb over IP
Command:gsh get_nse <nsei>
Result: The remote IP end point status is OK
16.0 Test for access aware test for radio access technology
Introduction
This document describes activation and configuration of the feature Access Aware Core Edge on
SGSN and GGSN nodes.
AACE feature description
General
Access Aware Core Edge allows the SGSN to forward access-related information about a
subscriber to the Gateway GPRS Support Node (GGSN), in order to allow differentiation of
services and charging schemes.
The following information will be sent to the GGSN:
The Mobile Country Code (MCC)/Mobile Network Code (MNC) of the network to which
the subscriber is currently attached
Radio Access Technology (RAT), that is, whether the subscriber is attached to GSM or
WCDMA Systems
Description
The SGSN uses the GTP-C Create PDP Context Request and Update PDP Context Request
messages to forward the following information to GGSN:
TD/NS/GSM/PHASE V.1/BSS/1280
Page 19 of 31
For activation, the Access Aware Core Edge Support SW Feature License
certificate is required
TD/NS/GSM/PHASE V.1/BSS/1280
Page 20 of 31
Page 21 of 31
stp@GGSNJ20re1# commit
Synchronize the two routing-engine using command:
stp@GGSNJ20re1# commit synchronize
Result The GGSN configuration is saved.
Verifying Access Aware Support
Objective:
The test case is considered successful if the information about Radio Access Technology
(whether GERAN or UTRAN) is present in the G-CDR.
Pre-conditions:
The subscriber is attached to the network
Action Perform a payload session using a valid APN
Result PDP is successful
Action Check the subscriber status in the SGSN
Command:gsh get_subscriber msisdn <msisdn> -a
Result The subscriber has an active PDP context
Action Verify in the GGSN that the subscriber has an active PDP context
Result The subscriber has an active PDP context in the GGSN
Action Deactivate the PDP session
Result The PDP is deactivated
Action Check the subscriber status in the SGSN
Command:gsh get_subscriber msisdn <msisdn> -a
Result The subscriber has no active PDP context
Action Check in the GGSN CDR (G-CDR)the information about the Radio Access Technology
(RAT) is available for the subscriber.
Result The field RAT Type is there in the G-CDR and its value is 1 if the MS was using WCDMA
(UTRAN) and the value is 2 for the MS using GSM (GERAN).
17.0
General
This is the Original Test Object List (TOL) for SGSN as required.
Prerequisites:
Node Properties
All node properties will be set to the default values. Some node properties may be changed
during the execution of the test cases.
The neighbouring BSCs are configured for the handover
The Node should be up and running.
TD/NS/GSM/PHASE V.1/BSS/1280
Page 22 of 31
Page 23 of 31
3 Action: Move to the BSC connected to the SGSN2 while PDP context is active
Result: Done
4 Action: Check that the subscriber has now active Context in the SGSN2.
Command: gsh get_subscriber msisdn <msisdn> -a
Result: Printout indicates that the subscriber has an active PDP Context in the SGSN2.
5 Action: Check that the subscriber is no longer attached to the the SGSN1.
Command: gsh get_subscriber msisdn <msisdn>
Result: Printout indicates subscriber is not registered in the SGSN1.
18.0
Password Management
Objective
This demo case verifies that whenever a user tries to access the SGSN he has to type correct
username and password
Preconditions
The node is up and running and username and password to the node is known.
1 Action: Telnet the SGSN and try to login using invalid user name and password.
Result: Login attempt failed.
2 Action: Try to Login using valid user name and wrong password.
Result: Login attempt failed.
3 Action: Try to Login using valid user name and correct password
Result: Login successful.
19
Objective
This demo case verifies that the system is restored when powered ON after powering it off
Preconditions
The node is up and running and there are no serious alarms in the node.
1 Action: Power OFF the SGSN by putting all the toggle switches in the SGSN PDU to OFF
position.
Result: The SGSN is powered OFF and all the LED in the all the magazines are off.
2 Action: Power ON the SGSN by putting all the toggle switches in the SGSN PDU to ON
position.
Result: The node is powered on.
TD/NS/GSM/PHASE V.1/BSS/1280
Page 24 of 31
Test equal priority to voice and GPRS data call & voice and data calls simultaneously
Objective
This demo case verifies that there is equal priority to voice and data call and a subscriber can
make and receive a CS call while the PDP context (data call) is active.
Preconditions
The node is up and running and there are no serious alarms in the node.
The DTM feature is enabled and supported in the SGSN,MSC and BSC.
1 Action: Activate a PDP context and start a GPRS data session.
Result: Done.
2 Action: Check in the SGSN that the subscriber has an active PDP context.
Command: gsh get_subscriber msisdn <msisdn> -a
Result: The subscriber has an active context
3 Action: Set up a mobile terminating CS call
Result: The call is set up.
4 Action: Check in the SGSN that the subscriber still has an active PDP context.
Command: gsh get_subscriber msisdn <msisdn> -a
Result: The subscriber has an active context
5 Action: Terminating the CS call
Result: The call is terminated.
6 Action: Make an MO CS call when the subscriber has an active PDP context.
Result: The CS call is setup.
4 Action: Check in the SGSN that the subscriber still has an active PDP context.
Command: gsh get_subscriber msisdn <msisdn> -a
Result: The subscriber has an active context
22.0
Security Management of SGSN
General
This is the Original Test Object List (TOL) for SGSN as required.
INTRODUCTION
Authentication
TD/NS/GSM/PHASE V.1/BSS/1280
Page 25 of 31
The purpose of the authentication procedure is to protect the operator from unauthorized use. The
authentication procedure performs identification and authentication of the service requester, and
validation of the service request type, to ensure that the user is authorized to use the particular
network service.
Ciphering
Ciphering is done for data confidentiality. The MS and the SGSN must be coordinated before the
authentication procedure can start ciphering. Whether or not ciphering is used is indicated by the
SGSN in the authentication and ciphering request message.
Prerequisites:
Node Properties
All node properties will be set to the default values. Some node properties may be changed
during the execution of the test cases.
The Node should be up and running.
Demo Case for Authentication and Ciphering
Authentication and ciphering feature of the SGSN can be switched on and off by command as per
following table, give following command at active NCB:
Command:gsh set_nodeprop Gb_Ciphering val off
gsh set_nodeprop Gb_Ciphering val on
gsh set_nodeprop Gb_MSAuthentication val off
gsh set_nodeprop Gb_MSAuthentication val on
#
1
2
3
Authenticati
on
Off
On
On
Cipheri
ng
Off
Off
On
TD/NS/GSM/PHASE V.1/BSS/1280
Page 26 of 31
25
3G RELATED TEST
25.1
Iu interface verification
Objective
The Test Case is considered successful if the RNC status is in service
Pass/Fail Criteria
This demo case is considered to be successful when the RNC connected to the SGSN is in service.
Action:Check the RNC status in SGSN
Command:gsh get_rnc <RNCNAME>
Result: The status of the RNC is in service.
Action:Check the RNC status in SGSN
Command:gsh get_rnc <RNCNAME>
Result: The status of the RNC is in service.
25.2
Objective
To demonstrate that the RNC and BSC is connected to the same SGSN and are up and running.
Pass/Fail Criteria
This demo case is considered to be successful when the RNC connected to the SGSN is in service and
BSC (either on Frame Relay or IP) are working.
25.3
TD/NS/GSM/PHASE V.1/BSS/1280
Page 27 of 31
25.4
The negotiated Maximum Bit Rate (MBR) Downlink is 1.6 Mbps in the GGSN. The downlink rate of a file
transfer is 1.6 Mbps.
Parameter Setting
When the maximum bandwidth for downlink traffic is configured to a value greater than 2048 kbps, the
optional service High Speed Downlink Packet Access (HSDPA) is considered to be in operation.
Subscriber QoS settings in the HLR allow Maximum Bit Rate Downlink of 2 Mbps or more.
Preconditions
To support HSDPA for WCDMA Systems, the value range for the Maximum Bit Rate (MBR) and
Guaranteed Bit Rate (GBR) has been increased in the GGSN R4 and onwards. The MBR for the APN
should be atleast 4 Mbps in the downlink direction.
This feature requires support in the SGSN and UTRAN. Terminal support for HSDPA is also required.
Demo Execution
Action 1 Activate a PDP context for the MS.
Result The PDP context is activated.
Action 2 Check the subscriber information in the GGSN by CLI
Command: show services ggsn statistics msisdn <msisdn>
Result: The printout shows the subscriber has an active PDP context for the HSDPA.
Action 3 Check the subscriber information in the SGSN by CLI
Command: gsh get_subscriber a -msisdn <msisdn>
Result: The printout shows the subscriber has an active PDP context for the HSDPA and the routing area
belongs to WCDMA network
Action 4 Perform an FTP session to download a file from the local FTP server.
Result The file is downloaded from the server.
TD/NS/GSM/PHASE V.1/BSS/1280
Page 28 of 31
Action 5 Optionally, measure the downlink speed with a tool (ex netperSec).
Result The downlink speed is higher than 1.6 Mbps.
25.5
Objective
To demonstrate that mobile stations is capable of providing service in 3G and 2G environment.
Pass/Fail Criteria
This demo case is considered to be successful when a subscriber is able to do PDP in UMTS as well as
GSM GPRS environment.
Preconditions
The MS is in 3G environment and is switched off.
1 Action: Switch on the mobile
Result: The MS is attached to the network
2 Action: Check the subscriber in the SGSN by CLI
Command: gsh get_subscriber -msisdn <msisdn>
Result: the MS is in state PMM-connected/PMM-Idle
3 Action: Do a PDP context activation using a valid internet APN and start browsing
Result: PDP is activated and browsing is successful.
4 Action: Check the subscriber in the SGSN by CLI
Command: gsh get_subscriber -msisdn <msisdn> -a
Result: the MS has an active PDP context.
5 Action: Deactivate the PDP
Result: PDP is deactivated
6 Action
Check the subscriber in the SGSN by CLI
Command: gsh get_subscriber -msisdn <msisdn> -a
Result: The MS has no active PDP context
7 Action: Move to GSM GPRS area and do the attach
Result: MS is attached.
8 Action: Check the subscriber in the SGSN by CLI
Command: gsh get_subscriber -msisdn <msisdn>
Result: the MS is in state Standby/Ready
9 Action: Do a PDP context activation using a valid internet APN and start browsing
Result: PDP is activated and browsing is successful.
TD/NS/GSM/PHASE V.1/BSS/1280
Page 29 of 31
25.6
HSDPA Support
Objective
The purpose of this demo case is to demonstrate that GGSN can forward
up to 1.6 Mbps to the subscriber required for HSDPA Support.
Pass/Fail Criteria
The negotiated Maximum Bit Rate (MBR) Downlink is 1.6 Mbps in the GGSN. The downlink rate of a file
transfer is 1.6 Mbps.
Parameter Setting
When the maximum bandwidth for downlink traffic is configured to a value greater than 2048 kbps, the
optional service High Speed Downlink Packet Access (HSDPA) is considered to be in operation.
Subscriber QoS settings in the HLR allow Maximum Bit Rate Downlink of 2 Mbps or more.
Preconditions
To support HSDPA for WCDMA Systems, the value range for the Maximum Bit Rate (MBR) and
Guaranteed Bit Rate (GBR) has been increased in the GGSN R4 and onwards. The MBR for the APN
should be atleast 4 Mbps in the downlink direction.
This feature requires support in the SGSN and UTRAN. Terminal support for HSDPA is also required.
Demo Execution
Action 1 Activate a PDP context for the MS.
Result The PDP context is activated.
Action 2 Check the subscriber information in the GGSN by CLI
Command: show services ggsn statistics msisdn <msisdn>
TD/NS/GSM/PHASE V.1/BSS/1280
Page 30 of 31
Result: The printout shows the subscriber has an active PDP context for the HSDPA.
Action 3 Check the subscriber information in the SGSN by CLI
Command: gsh get_subscriber a -msisdn <msisdn>
Result: The printout shows the subscriber has an active PDP context for the HSDPA and the routing area
belongs to WCDMA network
Action 4 Perform an FTP session to download a file from the local FTP server.
Result The file is downloaded from the server.
Action 5 Optionally, measure the downlink speed with a tool (ex netperSec).
Result The downlink speed is higher than 1.6 Mbps.
TD/NS/GSM/PHASE V.1/BSS/1280
Page 31 of 31