Use these parameters to define the session loading cycle and mobility events for your test. They are accessible by clicking the Settings... button in the Test Activity pane when Session Loading With Mobility is selected from the Test Activity drop-down list. An additional tab may be added to the test case that allows you to define the control protocol parameters used with the handoff node or SUT.
Each MN session is timed independently. If you define a cycle wherein the pending and hold times are shorter than the time required to establish all of the MN sessions, the SUT is constantly connecting, handing off, and disconnecting sessions.
NOTE: Mobility test handoff rates may not be able to reach or sustain the maximum activation rate allowed for Capacity tests. |
The number of seconds a session is left idle before it is re-connected. This timer begins when the session is disconnected after the Session Hold Time expires.
IMPORTANT: When Data Traffic is used in the test, the Session Pending Time must allow for enough time to release the data resources before re-connecting the session. If the pending time is not long enough, the session will not be able to establish data traffic when it is re-connected. The Session Pending Time should be at least twice the slowest Transaction Rate plus .5 seconds. For example, if the Transaction Rate is .1 (one transaction every 10 seconds), the Session Pending Time should be at least 21 seconds. |
Range: 15 — 100,000 (as of release 16.6, the minimum value supported is 15 (used to be 1))
Default: 1000
The number of seconds a session is maintained in an established state before being disconnected. This timer begins when the final handoff is complete. The test may generate additional control or data traffic, depending on the capability of the test case, during the hold time.
Range: 15 — 100,000 (as of release 16.6, the minimum value supported is 15 (used to be 1))
Default: 1000
When this box is checked, the test system will validate that the values you entered for Session Pending Time and Session Hold Time will result in a constant load on the SUT. Example:Example:
Assuming that the test connects 200,000 MN sessions (including all PDP contexts or service instances) at a rate of 1,000 sessions/second, 200 seconds are required to connect all of the sessions. To achieve a balanced load, sessions must be active for 100 seconds and idle (Session Pending Time) for 100 seconds.
During the 100 seconds that a session is active, handoffs are performed and then the session is maintained for the hold time. If 2 handoffs are performed with a Handoff Time of 30 seconds, 60 seconds are required to process the handoffs, leaving 40 seconds for the Hold Time.
The hold timers in the first sessions start to expire while the remaining 100,000 sessions are being connected and handed off. By the time all of the 200,000 sessions have been connected for the first time, the pending timers in the first sessions start to expire, and they begin to be reconnected at the same rate that the later sessions are being disconnected.
The result is a balanced session loading cycle with 100,000 active sessions and 100,000 idle sessions at any given time. Every second 1,000 sessions are connected, 1,000 sessions are handed off, and 1,000 sessions are disconnected.
If hold time + pending time + (Number of Handoffs * Handoff Time) = total activation time, the settings are accepted when you click OK. Otherwise, a pop-up window informs you that the calculation was invalid. When the box is cleared, you can enter any valid value in the timers.
The number of milliseconds to wait before initiating a session's first handoff and the delay between handoffs if the test performs multiple handoffs. This timer begins when the session is connected (first handoff) or when the previous handoff is complete (multiple handoffs).
Range: 1 — 10,000,000
Default: 60,000
The number of handoffs that will be performed with each MN session. If more than one handoff is defined, Handoff Time defines the delay between handoffs.
Range: 1 — 10,000
Default: 2
The type of handoffs that will be performed. The selections in this list vary depending on the test case. If only one option is valid, that option is displayed and is not selectable.
Options:
Uncontrolled Handoff — Perform "Uncontrolled (Unpredictive) HO with Context Retrieval" as described in section 4.7.3 of the NWG R1.0.0 Stage 3 specification....
Fully Controlled MN Initiated Handoff — Perform "Handover Preparation Scenario 1: AK Context Retrieval and Path Pre-Registration Initiated by Target ASN" as described in section 4.7.2.1.2 of the NWG R1.0.0 Stage 3 specification.
Fully Controlled Ntwk Initiated Handoff — You can select this only if Test Activity is Mobile Node Mobility or Session Loading with Mobility, and Profile Type is Profile A).
This option supports the Network triggered handoff procedure in Rel. 1 Version 1.3. If selected, the BS will not initiate any handoffs, but will respond to a Handoff Directive message from the ASN GW to start the handoff procedure.
Default: Uncontrolled Handoff
The Inter-ASN Gateway available in the ASN Nodal Test Case supports ASN Gateway's ability to process handoffs between two SUTS.
Inter-ASN Gateway tests a SUT's ability to process MS movements between the ASN Gateway and the FA Node. The FA Target Node is enabled for Inter-ASN mobility.
Inter-Technology — When this option is selected, the test simulates an MN handoff between a WiMAX and a CDMA network. You can define both FA and Target FA nodes.
Options:
Inter-PDSN — Perform handoffs between PDSN-FAs. This option is only available in the End-to-End Mobile IP and HA Nodal test cases. With this option, you must identify the FA used for the handoffs.
In the End-to-End Mobile IP test case, you can select the FA that will receive handoffs from the SUT #2 FA drop-down list. Define the Mobility PCF Nodes associated with the handoff FA and the RP interface on the Handoff RP tab.
In the HA Nodal test case, you can define multiple Mobility FA Nodes to receive the handoff sessions.
Intra-PDSN — Perform handoffs between PCFs. This option is available in the End-to-End Mobile IP, FA Nodal, Simple IP, and Simple IP VPN test cases. With this option, you must define the Mobility PCF Nodes and define their RP interfaces with the PDSN SUT on the Handoff RP tab.
Default: Inter-PDSN (where available)
Inter-SGSN is the only option available in the GPRS test case. You can define a Mobility SGSN Node Group that will receive the handoff sessions, and provision the GTP parameters for the handoff SGSNs on the Handoff GTP tab.
The type of handoffs that will be performed in a PDG Micro-Mobility test case.
Mobile Node — When this option is selected, the test simulates MN movement between local WLAN IP addresses.
Inter-Technology (Reserved for future use.)
If Mobile Node is selected, you can define the Starting Client IP Address #2 and network mask that form the pool of addresses to be used for the handoffs. See Handoff Test Settings for important notes regarding address format.
The type of handoffs that will be performed in an IPv4 HA Nodal or CDMA/WiFi Convergence test case.
Options:
Inter-FA (IPv4 HA Nodal only) — When this option is selected, the test simulates an MN handoff between FAs. You can define multiple FA nodes to receive the handoff sessions.
Mobile Node Mobility — When this option is selected, the test simulates an MN handoff between co-located care-of addresses without FA services. You can define the Co-Located Care of Address #2 that will be used for the first MN's handoff. This address will be incremented for each MN. See Handoff Test Settings for important notes regarding address format.
IMPORTANT: In the IPv4 HA Nodal test case, the Mobile Node sub-tab must be configured to support the selected Mobility Type. If you select Mobile Node Mobility, for example, you must define a Co-Located Care-of Address and the Foreign Agent must not be enabled. |
Inter-Technology Mobility (CDMA/WiFi Convergence only) — When this option is selected, the test simulates an MN handoff between a WiFi and a CDMA2000 network. You can define the PCF Node, and the RP and PPP settings associated with the PCF.
Default: Inter-FA
The type of handoffs that will be performed in a MME-Nodal test case.
Intra-MME and Inter-MME — When this option is selected, you can define both Control and User for Target ENodeB Nodes.
When you select Intra-MME and X2 Interface, you may select only either Single Handoff or Continuous Handoff, When Session Started.
Inter technology — When this option is selected, the test simulates an MN handoff between a MME and a UMTS network. You can define both Control and User Target RNC Nodes, and IuPS interface tabs settings associated with the UTMS/UMTS (IuPS over IP) protocol.
Intra-SGW, Inter-SGW, and Inter-MME — When this option is selected, you can define both Control and User for Target ENodeB Nodes and Target MME Nodes.
Intra-MME — During SGW Nodal testing, when Handoff Type = Dual Connectivity and Test Activity = "Intra-MME Mobility" or "Session Loading with Mobility" and Mobility Type= "Intra-MME", indicates 4G to 5G dual connectivity - phase I. The SGW Nodal will handover between 4G eNodeB and 5G gNodeB. The gNodeB User Node becomes available in Network devices tab. The eNodeB User Node is not available for input.
Inter-Technology Mobility — When this option is selected, the test simulates an UE handoff between a LTE and a GPRS network. You can define the MME Control Node, SGSN Control Node, GTPv2, IPv4/IPv6, and GTP settings associated with the S11 and Gn interface associated with eNodeB.
The following types of handoffs will be performed in a HSGW-Nodal test case.
Inter-Technology Mobility — When this option is selected, the test simulates an UE handoff between a LTE and a CDMA network. You can define the ePCF Node, RP and PPP settings associated with the ePCF and S1-MME settings interface associated with eNodeB.
Intra-HSGW, Inter-HSGW — When this option is selected, you can define both Control and User for Target ePCF Nodes.
During HNB testing, Intra HNB GW type of handoffs will be performed.
Use the drop-down list to select the emulated mode for disconnecting sessions in a CDMA2000 or GPRS test.
Options:
Mobile Node — The MN sends a registration request with the lifetime set to zero, which causes the MIP layer to de-register. Then the PPP layer sends a terminate request to the PDSN. After the terminate acknowledgement is received, the test tears down the RP layer. This is initiated by a registration request with the lifetime of zero. When the request is received, the PDSN tears down the RP layer and the disconnect is complete.
Mobile Node PPP — Same as above, except the disconnect begins with the PPP layer first sending a terminate request. In this case the MIP layer is left hanging until its timer expires.
PCF — Same as in the above scenarios, but this time the disconnect begins with the RP layer sending a lifetime of zero to initiate the disconnect request. In this case both MIP and PPP are left hanging until their timers expire.
Default: Mobile Node
Options:
Mobile Node — Emulates a disconnect by the mobile node, with the PPP or IPv4 layer initiating the disconnect.
SGSN — Emulates a disconnect initiated by the SGSN at the GTP layer.
Default: Mobile Node
Use the checkbox to enable fast handoff support. In a fast handoff, the MN's PPP session is maintained throughout the handoff.
Use the checkbox to include an Active Start Airlink record in all handoff registration requests. When the box is cleared, dormant sessions will remain dormant.
In a UMTS test case, you can use this checkbox to trigger the Serving Radio Network System (SRNS) relocation procedure and simulate RAN-initiated handoffs between RNCs.
When performing UMTS Mobility testing using MXP test Server (STC Chassis), Perform serving RNS Relocation Procedure is selected by default.
In a UMTS Gb interface test, you can use this checkbox to trigger an inter-BSS or Gb-Iu handoff initiated by the SGSN.