Last updated: October 30, 2013
The protocol stack configuration options provide you with control over the content and execution of events in the protocol stack. These are organized by protocol layer. The parameters listed under the following protocol layers are accessed on the front panel by selecting the layer that contains the parameter in the
Prot Control
menu. For instructions on how to access the protocol layers, see
How to access Protocol Control
.
The parameters associated with the Attach Accept event allow you to configure the test set to simulate a network allowing only GPRS services. This means you can expect an IMSI attach for both GPRS and non-GPRS services to be rejected. You may also choose which cause value is sent to the MS in the GMM cause information element ( GMM Cause Information Element ) with the Attach Reject message. Use this function in parallel with protocol logging ( Protocol Logging ) to verify that the MS behaves in a manner conforming to the standards for this situation and for each associated GMM cause value.
The MS only sends an Attach Request in the "Idle" state. Therefore, the connection status must be "Idle" before the Attach Accept event can be used.
You may configure the test set to simulate a network rejection of any Attach Attempt. You may choose from a variety of cause values to be sent in the GMM cause information element ( GMM Cause Information Element ) with the attach reject message. Use this function in parallel with protocol logging ( Protocol Logging ) to verify that the MS behaves in a manner conforming to the standards for this situation and for each associated GMM cause value.
The MS only sends an Attach Request in the "Idle" state. Therefore, the connection status must be "Idle" before the Attach Accept event can be used.
You may configure the test set to simulate a network ignoring of any Attach Attempt. Use this function in parallel with protocol logging ( Protocol Logging ) to verify that the MS behaves in a manner conforming to the standards for this situation.
The MS only sends an Attach Request in the "Idle" state. Therefore, the connection status must be "Idle" before the Attach Accept event can be used.
The command to set the Attach Ignore State is CALL:PPRocedure:ATTach:IGNore[:STATe]
You can initiate the Detach Request event from the test set anytime the data connection state is "Attached". In addition, a Detach Request can also occur when the data connection state is either "Transferring" or "PDP Active". This allows you to observe how the mobile station responds to a detach request from a network and determines if it complies with mobile performance specifications of 3GPP TS 04.08 Version 7.9.1. The command to send a detach request is CALL:PPRocedure:DETach:REQuest[:IMMediate] .
There are two configurable parameters that you can set before sending a detach request.
You can choose which cause value is sent to the mobile station in the GMM Cause Information Element with the Detach Request.
The command to set the GMM Cause Information Elements is CALL:PPRocedure:DETach:REQuest:GMMCause .
Note: The front panel allows you to select
Custom Value
as the
GMM Cause Information Element
in addition to the GMM Cause Information Element settings defined in 3GPP TS 24.008 Version 6.7.0 Section 10.5.5.14. The
Custom Value
is set with the above command and is not configurable via the front panel.
You can also choose which type of detach message the test set sends the mobile station in the Detach Type Information Element as defined in 3GPP TS 24.008 Version 6.7.0 Section 10.5.5.5.
The command to set the Detach Type Information Element is CALL:PPRocedure:DETach:REQuest:TYPE .
Use these parameters in parallel with Protocol Logging to verify that the mobile station behaves in a manner conforming to the standards 3GPP TS 04.08 Version 7.9.1 Section 4.7.4.2 for this situation and for each associated GMM cause value.
A GPRS MS has four identity values (types). These values are displayed in the Identity Request Summary screen, in the following order:
The Identity Request Summary screen is accessed by pressing the GMM/MM (
F4
) from the
Prot Control
menu (see
How to access Protocol Control
for instructions on how to get to the Prot Control menu), then pressing
Identity Request
(
F4
) in the
Identity Req
menu. The test set displays the DUT Reported Identity that is in the indicated by the
Identity Type
parameter (which can be set to any of the identity types listed above. The default
Identity Type
is
IMSI
.
You can send a request for any one of these four identities from the test set (by selecting the
Identity Type
(
F2
), then pressing
Send Identity Request (
F1
)
) to verify that the MS supplies the appropriate value for the identity requested. Use this function in parallel with protocol logging (
Protocol Logging
) to verify that the MS behaves in a manner conforming to the standards for this situation.
Additionally, you can control whether the Identity Request messages get the IMEI during call setup by configuring the
Get IMEI at Call Setup
parameter. This parameter is located in the
Identity Request Setup
(
F3
) menu, which is accessed from the
Identity Req
menu. The GPIB command for this parameter is
CALL:IMEI:AUTO
.
The data connection state can be either "Attached" or "PDP Active" when an Identity Request message is sent to the MS.
Get IMEI at Call Setup
parameter is located in the Cell Parameters menu for the E6701D lab application and the E1968A test application.The GPIB commands associated with Identity Request are located at CALL:PPRocedure:IDENtity .
You can configure the test set to reject the Location Area Update (LAU) request from the mobile station. This allows you to observe how the mobile station responds to LAU Rejection from a network and determine if it complies with mobile performance specifications of 3GPP TS 24.008 Version 6.13.0.
There are two configurable parameters that you can set before sending a LAU Rejection.
When the Location Area Update Reject State is set to ON, the test set will reject the LAU request from the mobile station.
The command to set the Location Area Update Reject State is CALL:PPRocedure:LAU|LAUPdate:REJect[:STATe] .
You can choose which cause value is sent to the mobile station in the Location Area Update Reject message. the reject cause can be either of the followings:
The front panel also allows you to select
Custom Value
as the
Location Area Update Reject Cause
in addition to the above values. The
Custom Value
is set with the GPIB command only and is not configurable via the front panel. See
GMM Cause Information Element
for more information about the cause values.
The command to set the Location Area Update Reject Cause is CALL:PPRocedure:LAU|LAUPdate:REJect:GMMCause .
You can initiate a LAU Rejection procedure by doing the following:
Attached
Cell Off
Cell Info (
F6
)
Cell Identification
(
F3
)
Location Area Code (LAC)
of the cell
Active Cell
, then when the mobile station comes back in to register to the network. it will send the Location Area Update Request to the test set. Use these parameters in parallel with Protocol Logging to verify that the mobile station behaves in a manner conforming to the standards 3GPP TS 24.008 Version 6.13.0 Section 4.4.4.7 for this situation and for each associated Location Area Update Reject Cause value.
You can configure the test set to ignore the Location Area Update (LAU) request from the mobile station. This allows you to observe how the mobile station responds to LAU ignore from a network and determine if it complies with mobile performance specifications of 3GPP TS 24.008 Version 6.13.0.
You can initiate a LAU Ignore procedure by doing the following:
Attached
Cell Off
Cell Info (
F6
)
Cell Identification
(
F3
)
Location Area Code (LAC)
of the cell
Active Cell
, then when the mobile station comes back in to register to the network. it will send the Location Area Update Request to the test set. Use these parameters in parallel with Protocol Logging to verify that the mobile station behaves in a manner conforming to the standards 3GPP TS 24.008 Version 6.13.0 for this situation.
The command to set the Location Area Update Ignore State is CALL:PPRocedure:LAU|LAUPdate:IGNore[:STATe]
You can configure the test set to reject the request for Routing Area Update (RAU) from the mobile station. This allows you to observe how the mobile station responds to RAU Rejection from a network and determines if it complies with mobile performance specifications of 3GPP TS 24.008 Version 6.13.0.
There are two configurable parameters that you can set before sending a RAU Rejection.
When the Routing Area Update Reject State is set to ON, the test set will reject the RAU request from the mobile station.
The command to set the Routing Area Update Reject State is CALL:PPRocedure:RAU|RAUPdate:REJect[:STATe] .
You can choose which cause value is sent to the mobile station in the Routing Area Update Reject message. You can choose the following reject causes from the front panel:
The front panel also allows you to select
Custom Value
as the
Routing Area Update Reject Cause
in addition to the above values. The
Custom Value
is set with the GPIB command only and is not configurable via the front panel. See
GMM Cause Information Element
for more information about the cause values.
The command to set the Routing Area Update Reject Cause is CALL:PPRocedure:RAU|RAUPdate:REJect:GMMCause .
You can initiate a RAU Rejection procedure by doing the following:
Attached
Cell Off
Cell Info (
F6
)
Cell Identification
(
F3
)
Routing Area Code (RAC)
of the cell
Active Cell
, then when the mobile station comes back in to register to the network. it will send the Routing Area Update Request to the test set. Use these parameters in parallel with Protocol Logging to verify that the mobile station behaves in a manner conforming to the standards 3GPP TS 24.008 Version 6.13.0 Section 4.7.5.1.4 for this situation and for each associated Routing Area Update Reject cause value.
You can configure the test set to ignore the request for Routing Area Update (RAU) from the mobile station. This allows you to observe how the mobile station responds to RAU Ignore from a network and determines if it complies with mobile performance specifications of 3GPP TS 24.008 Version 6.13.0.
You can initiate a RAU Ignore procedure by doing the following:
Attached
Cell Off
Cell Info (
F6
)
Cell Identification
(
F3
)
Routing Area Code (RAC)
of the cell
Active Cell
, then when the mobile station comes back in to register to the network. it will send the Routing Area Update Request to the test set. Use these parameters in parallel with Protocol Logging to verify that the mobile station behaves in a manner conforming to the standards 3GPP TS 24.008 Version 6.13.0 for this situation.
The command to set the Routing Area Update Ignore State is CALL:PPRocedure:RAU|RAUPdate:IGNore[:STATe] .
You can configure the IMS voice over PS session indicator bit in the Network feature support IE of the Attach Accept message and Routing Area Update Accept messages as specified in 3GPP TS 24.008 table 10.5.153c. The Network feature support IE is added to the Attach Accept message and Routing Area Update Accept messages if either of IMS voice over PS session indicator bit or Emergency Bearer Services Indicator bit is set to 1.
The command to set the IMS voice over PS session indicator is CALL:PPRocedure:ATTach:ACCept:NFSupport:IMSi .
You can configure the emergency bearer services indicator bit in the Network feature support IE of the Attach Accept message and Routing Area Update Accept messages as specified in 3GPP TS 24.008 table 10.5.153c. The Network feature support IE is added to the Attach Accept message and Routing Area Update Accept messages if either of IMS Voice Over PS Session Indicator bit or emergency bearer services indicator bit is set to 1.
The command to set the emergency bearer services indicator is CALL:PPRocedure:ATTach:ACCept:NFSupport:EMCi .
You may configure the test set to simulate a network rejection of an Activate PDP Context Request from an MS. You can select from a variety of SM cause values to be sent in the SM cause information element ( SM Cause Information Element ) with the Activate PDP Context Reject message. Use this function in parallel with protocol logging ( Protocol Logging ) to verify that the MS behaves in a manner conforming to the standards for this situation and for each associated SM cause value.
The data connection state must be "Attached" to use the Activate PDP Context Reject event.
You may configure the test set to simulate a network ignoring of an Activate PDP Context Request from an MS. Use this function in parallel with protocol logging ( Protocol Logging ) to verify that the MS behaves in a manner conforming to the standards for this situation.
The data connection state must be "Attached" to use the Activate PDP Context Ignore event.
The command to set the Activate PDP Context Ignore State is CALL:PPRocedure:PDPContext:AIGNore[:STATe]
If data requiring a PDP context is destined for a mobile staion, you can configure whether or not the test set will initiate a PDP context negotiation procedure by setting the Network Initiated PDP Context State.
The GPIB command to set the Network Initiated PDP Context State is CALL:PPRocedure[:QOSProfile]:PDPContext:NINitiated[:STATe] .
The Mobile Originated Alerting Duration is used to delay the connection of a Mobile Originated voice call. When the timer has a non-zero value, the call will remain in the Alerting state until the timer expires, at which point, the 8960 will complete (or release) the call.
This parameter is only applicable in the Active Cell operating mode.
The GPIB command to set the Alerting Duration is CALL:MORiginated:ALERting:DURation .
The Call Release State is used to determine whether an incoming Mobile Originated voice call is connected or released. When this parameter is set to
ON
, the Mobile Originated voice call will be released when the Alerting Duration expires.
This parameter is only applicable in the Active Cell operating mode.
The GPIB command to set the Call Release State is CALL:MORiginated:CALL:RELease[:STATe] .
The Emergency Service Category Value is used to indicate which particular emergency service is acturally required. On the front panel of the test set, under the `DUT Information', there is a `Called Num' field. When the Mobile Originated call is an emergency call, this field will display one of the following strings:
This parameter is only applicable in the Active Cell operating mode.
The GPIB command to query the `Called Num' is CALL:MS:REPorted:ONUMber[:SELected]? .
The setting determines whether to establish an RR connection on TCH in signalling only mode. This setting can only be enabled when
Authentication State
is
On
and
GSM Ciphering Algorithm
is not
Off
.
This parameter is only applicable in the
Active Cell
operating mode.
GPIB command: CALL:PPRocedure:CSETup:SOConnection:STATe .
In order to synchronize the various components of a complex test system, (e.g. the fading system that comprise the test set and a signal source), it is necessary for the test set to provide a Neighbor Cell Synchronization Trigger. This trigger generates a signal on the test set's trigger output which can be used to align the frame start position of the other instruments in the system with the test set. The Uplink Timing Delay parameter allows you to specify the symbol offset prior to the first symbol of the 0'th frame on which to fire the trigger, e.g. if 5 is chosen for this parameter, the trigger will fire 5 symbols before the first symbol of the 0'th frame.
The GPIB command to send the neighbor cell synchronization trigger output is CALL:TRIGger[:OUTPut]:FRAMe:SYNChronize
The GPIB command to set this parameter is CALL:TRIGger[:OUTPut]:FRAMe:SYNChronize:OFFSet .
Detach Type Value (decimal) | Detach Type (bits) | Detach Type | |
---|---|---|---|
1 | 001 | Re-attach Required | |
2 | 010 | Re-attach not Required | |
3 | 011 | IMSI Detach (after VLR failure) |
Cause Value (decimal) | Cause Value (bits) | Cause |
---|---|---|
2 | 00000010 | IMSI Unknown |
3 | 00000011 | Illegal MS |
4 | 00000100 | IMSI UKNOWN IN VLR |
5 | 00000101 | IMEI NOT ACCEPTED |
6 | 00000110 | Illegal ME |
7 | 00000111 | GPRS Services Not Allowed |
8 | 00001000 | GPRS/Non-GPRS Services Not Allowed |
9 | 00001001 | MS Identity Cannot Be Derived |
10 | 00001010 | Implicitly Detached |
11 | 00001011 | PLMN Not Allowed |
12 | 00001100 | Location Area Not Allowed |
13 | 00001101 | Roaming Not Allowed In This LA |
16 | 00010000 | MSC Temporarily Not Reachable |
17 | 00010001 | Network Failure |
22 | 00010110 | Congestion |
32 | 00100000 | Service Option Not Supported |
33 | 00100001 | Requested Service Option Not Subscribed |
34 | 00100010 | Service Option Temporarily Out of Order |
48 | 00110000 | Retry Upon Entry Into A New Cell |
95 | 01011111 | Semantically Incorrect Message |
96 | 01100000 | Invalid Mandatory Information |
97 | 01100001 | Message Type Nonexistent |
98 | 01100010 | Msg Type Incompatible With Prot State |
99 | 01100011 | Information Element Nonexistent |
100 | 01100100 | Conditional IE Error |
101 | 01100101 | Msg Incompatible With Protocol State |
111 | 01101111 | Protocol Error, Unspecified |
Cause Value (decimal) | Cause Value (bits) | Cause |
---|---|---|
25 | 00011001 | LLC or SNDCP Failure |
26 | 00011010 | Insufficient Resources |
27 | 00011011 | Missing or Unknown APN |
28 | 00011100 | Unknown PDP Address or PDP Type |
29 | 00011101 | User Authentication Failed |
30 | 00011110 | Activation Rejected By GGSN |
31 | 00011111 | Activation Rejected, Unspecified |
32 | 00100000 | Service Option Not Supported |
34 | 00100010 | Service Opt Temporarily Out of Order |
35 | 00100011 | NSAPI Already Used |
36 | 00100100 | Regular Deactivation |
37 | 00100101 | QoS Not Accepted |
38 | 00100110 | Network Failure |
39 | 00100111 | Reactivation Required |
81 | 01010001 | Invalid Transaction Identifier Value |
95 | 01011111 | Semantically Incorrect Message |
96 | 01100000 | Invalid Mandatory Information |
97 | 01100001 | Msg Type Nonexistent/Not Implemented |
98 | 01100010 | Msg Type Incompatible With Protocol State |
99 | 01100011 | IE Non-existent or Not Implemented |
100 | 01100100 | Conditional IE Error |
111 | 01101111 | Protocol Error, Unspecified |
The LAPDm Fill Bits parameter allows you to set the Fill Bits for the LAPDm frames. When the parameter is set to Fixed, the LAPDm Fill Bits are set to a fixed value - 0x2B. When the parameter is set to Random, the LAPDm Fill Bits are set to a random value according to 3GPP TS04.06 V8.4.0.
The GPIB command to set this parameter is CALL:LAPDm:FBITs .