TSS-UserManual-0 0 14 0

TSS
Test Scheduling System
User's Manual
Version 0.0.14.0 for Windows-32, 07.Nov.2011
Copyright 2008-2011 by Ingo Zettl, ingo.zettl@aon.at
Chapter
Introduction
This manual tries to give an introduction to the functionality and the features of the TSS software.
You should read this manual carefully if you are not familiar with the Test Scheduling System. If
youre already comfortable with the functionalities and the workflows, you might need the technical
documentation in chapters 4 and 5.
1.1 What is TSS

TSS, the Test Scheduling System, is a software product to run unattended tests on standard
Windows XP computers. TSS provides integrated support for connection and IP configuration
management, file handling, reporting and log file submission, synchronization etc. and uses
external probing tools such as PocketOptimizer or WebSpeedTest to gather measurements.
TSS provides the following features:
Automatic scheduling of flexible tasks with an integrated scheduler (including time shifts to
reduce peak loads).
Task execution engine supporting looping, sub-tasks and conditional execution of tasks.
Timeouts for single tasks, sub-jobs and entire jobs to ensure proper execution.
Minimum execution time and pause to achieve proper timing if required.
Status management for every task including automatic reboot if errors occur consecutively.
Integrated support to establish and drop internet (RAS) connections with connection
monitoring.
Integrated support to manage multiple IP connections (e.g. DSL management connections).
Seamless integration with PocketOptimizer and WebSpeedTest for a variety of active
measurements.
Integrated support to submit XML tickets to a QTS Ticket Receiver or Relay.
Integrated synchronization to synchronize application, job and configuration files with a server.
Integrated generation of XML tickets to display system status and execution results in QTS.
Automatic upload of log and data files to a log file server.
Additional functions to get public IP address and synchronize with time servers.
Integrated compression of log, report and data files with 7-zip to reduce number of files and
HDD consumption, automatic removal of old files with specific settings for different directories.
Integrated support for watchdogs (WD) or modem power switches (MPSW)
1.2 Field of application

Main field of application is stationary testing of mobile or DSL based broadband connections.
Possible use cases are:
Testing of customer experience in wireless or DLS connections.
Active performance testing for wireless, DSL or LAN connections.
Stability measurements for connections with or without load.
Revenue assurance (e.g. payload monitoring on internet connections).
Service testing for different services.
Testing of network components such as accelerators, proxy servers, DNS servers...
TSS 0.0.14.0 07.Nov.2011
Introduction
1.3 Revision History

0.0.14.0 - 07.11.2011 (=0.0.14.0)
support for Huawei E392 LTE data card (bugfix for incorrect AT+CREG response in LTE)
new mobile configuration file for E392 AT commands and AT++RAT=auto command
new parameter [Machine].DisableDelayedStart
bugfix in scheduler continuous mode
bugfix in execution logic for job loops
0.0.13.9 - 03.11.2011
IE8 maximum parallel request detection fixed
0.0.13.8 - 27.10.2011 (=0.0.13.8)
new configuration parameters [Machine].Report-Enable and [Communication].Report-Enable
0.0.13.7 - 29.09.2011 (=0.0.13.7=)
support for WebSpeedTest /logurl command line argument
0.0.13.6 - 06.09.2011 (=0.0.13.6=)
support to run packet sniffer associated with CIC tasks
new tasks Sniffer-Start and Sniffer-Stop to run packet sniffer for CIC or LAN connections
0.0.13.5 - 01.09.2011 (=0.0.13.5=)
bugfix in task numbering (task IDs not generated correctly in 0.0.13.2)
improved log messages when omitting tasks due to timing problems
bugfix when adding GPS coordinates to tickets (15 minute delay could be caused)
support for AT background thread (parameters WatchModemStatus and WatchStatus-xxx)
new metrics and logs for AT background thread (m.1200..m.1204, x.1210..1215)
new parameters in modem configuration files to enumerate COM ports (MobilePorts section)
support for Huawei E372 SysInfoEx command
0.0.13.3 - 18.08.2011
bugfix for Huawei NDIS connections: device select failed
bugfix for RAS connections: connections could be terminated depending on timing
0.0.13.2 - 04.08.2011 (=0.0.13.2=)
support for custom task ID in QTS tickets (parameter TaskID)
support for relative job file names in sub-jobs
support for execution time synchronization (parameters DelayUntil-Before and DelayUntil-After)
support for agent ID and scenario ID increment (Inc-AgentID and Inc-ScenarioId parameters
and attributes in scheduler file)
ticket loader moved to background thread to improve startup time (TSS Status Monitor only)
support for configuration sets in PocketOptimizer
support for random pause in PocketOptimizer
0.0.13.1 - 22.07.2011 (=0.0.13.1=)
new metrics in PocketOptimizer and WebSpeedTest
support for automatic EWF commit (time zone bugfix, parameter EwfTimeZoneFix)
new metrics x.170 (windows version) and x.171 (EWF state)
improvement in fallback tasks: always synchronize time and register if not licensed
support for broadcast of QTS tickets via UDP (new configuration parameters
EnableUdpBroadcast, UdpBroadcastPort, UdpReceiveTickets, UdpBroadcastTickets)
improved support for NDIS interfaces in Windows 7: new Parameter ForceNDISDefaultMetric
allow synchronization for manual or force execution only (changed parameter Sync-Enable)
and new task parameter Sync-Forced
support for reboot in CPU overload conditions (new parameter MaxCpuOverloads)
0.0.13.0 - 17.06.2011 (=0.0.13.0=)
support for TSS Status Monitor added, parameter EnableStatusServer
support for gzip decoding added to WebSpeedTest
changed m.114 to m.116 (sync-enable)
changed name of execution logs for mobile reset (execute.log to resetmobile.log)
scheduler improvement: re-schedule jobs after time adjustment
added new well known variables to execution task (BinPath, VarPath)
bugfix when loading persistent task data from file system
new reboot mode for windows reboot without MPSW cycle (win)
new parameter WaitOnly for modem check task
TSS 0.0.14.0 07.Nov.2011
Introduction
0.0.12.10 - 27.04.2011 (=0.0.12.10=)

new configuration parameter InterceptShutdown
bugfix in PocketOptimizer (HTTP connection keepalive did not work)
new parameters in PocketOptimizer
0.0.12.9 - 04.04.2011 (=0.0.12.9=)
new RAS/CIC task parameter QueryStatus-ComPort
bugfix in metric export (unit was invalid)
new metric x.145: IE information
0.0.12.8 - 25.03.2011 (=0.0.12.8=)
new configuration parameter Sync-AllowDefault
additional log messages in CID/RAS task
new error code ETSS-RAS-NOTREG or ETSS-CIC-NOTREG
dedicated scenario ID for CheckModem task (task parameter Scenario-Id)
fixed execution tickets (prefix TSS was missing in measurement format)
set rating to 0 if Huawei NDIS API select function fails
only check COM port if Huawei NDIS API device is active
added Huawei NDIS API select check to CheckModem task
fixed execution ticket generation: duration was missing
0.0.12.7 - 16.03.2011 (=0.0.12.7=)
new configuration parameter CID-MPSW to generate MPSW tickets
new RAS/CIC task parameter SetNDISInterfaceMetric
new RAS/CIC task parameter RateOnImsiImeiOnly
new configuration parameter Tickets/MobileInfoHistory
0.0.12.6 - 08.03.2011 (=0.0.12.6=)
don't synchronize without agent ID
new metric x.131: network registration status
execute pending MPSW cycle after reboot if failed before reboot (requires new TAS)
save registration info to file (Windows XPe and W7e EWF support)
new configuration parameters TerminateJobTimeout and ShutdownJobTimeout
new special scenario id for shutdown jobs (scenarios/CID-shutdown)
new special entries in scheduler file (startup, shutdown, fallback)
shutdown manager/background thread, new parameter WatchAssistanceSvc
TAS background thread (for shutdown notification and delay)
new CheckModem task to check if modem is available and responding
bugfix when calling ndisapihlp.dll
0.0.12.5 - 15.02.2011 (=0.0.12.5=)
new metric m.114: sync-enable
new IP metrics: x.143=Stack, x.144=AFD
new CIC metrics: x.1010 (type), x.1011 (name), x.1012 (eid), x.1013 (tid)
added modem info to system log
bugfix in cleanup task HDD quota calculated incorrectly
add cleanup initial/limit information
add NDIS API callback details
add NDIS API version information
dump CPU load information
0.0.12.4 - 02.02.2011
Support for Huawei NDIS API 1.1.0.29 (delivered with E372, caused crash in 0.0.12.3)
0.0.12.3 - 26.01.2011 ... changes are highlighted in light yellow and indicated with =0.0.12.3=
PocketOptimizer supports Soft-Stop for parallel tasks
added support for Huawei E372 (5 parameter at+creg response)
added support for Huawei NDIS API for Windows 7 (ndisapihlp.dll)
support for Clean-TempFiles.* parameters in clean task
added ReportPending condition
support for fast shutdown if power switch is pressed or PowerMonitor requires shutdown
support for PowerMonitor parameters in machine.cfg
support for GPS (parameters GPS/Port and Tickets/AddGPSPoints)
additional error handling and log in reboot logic
new parameter MinAssistRebootWait
bugfix in CIC identifier wildcard handling
TSS 0.0.14.0 07.Nov.2011
Introduction
0.0.12.0 - 05.11.2010 ... changes are highlighted in light yellow and indicated with =0.0.12=
Support for Cleware USB Breaker (as modem power switch)
allow scheduler to load tasks even if CIC/HwNd entry not available to enable std error handling
additional error handling for job load errors
force soft reboot if assisted reboot fails after 60 seconds
bugfix in reboot recovery (revert to standard operation if reboot fails)
bugfix in RAS metric function: additional exception handler required for LAN tests
support to check disk free space (new section [DiskFree])
support for Hwnd:* as CIC parameter (if exactly one CIC entry is available)
new config parameter for assistance check (CheckAssistanceSvc)
new config parameter for assistance errors (MaxAssistErrors)
new config parameter for hard reboots (MaxSoftReboots)
add WD+MPSW status to status tickets (new metrics x.250..)
reboot on TSS Assistance Service (WD/MPSW) problems
add unmapped metrics as comment (TSS + PO + WST)
new parameters RebootMode, UseExternalTool and ExternalToolName for reboot task
new parameter DontCheckReboot for execution tasks
added support for immediate reboot requests by tool (===REBOOT)
added ModemPowerCycle task (with different reboot actions on failure)
added config parameter Tool/Mpsw-Tool
change rating for CIC tickets (new parameter RateOnResponseOnly)
added persistence for registration (forced) and reboot (default) task
added persistence for task status, new parameter Period-Persist
added support for SAFE reboot mode
0.0.11.7 - 23.09.2010
support for Cleware USB Watchdog XP with external power supply
problem with certain HDD serial numbers in WebSpeedTest fixed
0.0.11.6 - 16.09.2010
support for Windows Vista and 7
Vista manifest to run with privilege elevation
support for VNC in TSS assistance service
bugfix in FTP client (exceptions in FTP upload under certain timing conditions)
bugfix in CIC detection (inactive connections detected as active since 0.0.11.0)
ReducePrivileges parameter to execute sub-jobs non-elevated in Windows Vista and 7
0.0.11.5 - 21.08.2010
support for USB power switch (type serial), new [ModemSwitch] section in machine.cfg
0.0.11.4 - 20.08.2010
support for %rands()% and %randi()% functions in job files
0.0.11.3 - 13.08.2010
bugfix in RAS connection manager: connections closed under certain timing conditions
0.0.11.2 - 28.07.2010 (internal test version)
support for hard reboot via TSS assistance service (Cleware USB Watchdog XP)
0.0.11.1 - 15.07.2010
change parameter HttpTimeout to Timeout for TimeSync task
0.0.11.0 - 09.07.2010
support for HTTP time synchronization with get-time request
new custom internet connection (CIC) task
tasks RAS-Connect and RAS-Hangup are deprecated, use CIC-Connect and CIC-Hangup instead
support for undefined configuration variables with %@...%
support for Huawei NDIS API
0.0.10.3 - 18.12.2009
update to PocketOptimizer/LE code base
0.0.10.0 - 12.12.2009
GUI shows if a restart/reboot is required after manual job execution
additional log messages for interaction with assistance service
available physical memory is shown in system summary
jobs with system tasks (sync, register...) can be executed if the application is not registered
support for AutoBaseDir parameter
improvements in AT command interface for non-Huawei modems
TSS 0.0.14.0 07.Nov.2011
Introduction
0.0.9.9 - 18.08.2009
Improvement in installer: restart service if it was previously running
bugfix in parameter Ras-DontHangup (was not working)
0.0.9.8 - 29.07.2009
bugfix in FTP submission (didn't delete files)
0.0.9.7 - 28.07.2009
FTP submission: check expected submission time and delay submission if longer than timeout
FTP submission: alternately search by size and date before FTP submission
added parameter v1m to 7z arguments to split large data files in smaller segments
0.0.9.6 - 21.07.2009
fixed FTP submission: old files not dropped
0.0.9.5 - 15.07.2009
changed check for tool executable file
added APN detection
0.0.9.3 - 19.06.2009
improvement: load default RAS entry in fallback job
improvement: execute fallback job if no tasks executed for 6 hours
bugfix in AT reset command
0.0.9.1 - 18.06.2009
bugfix in RAS internal storage
0.0.9.0 - 17.06.2009
support for assistance service interface management
improvements in registration
new parameters in machine.cfg: ModemReset-Enable, ModemReset-Ports
support to reset mobiles with AT+CFUN=1,1
change in user defined commands: use AT++XXX instead of AT+XXX
track COM ports used for RAS connections
0.0.8.5 - 04.05.2009
bugfix in extension reporting
bugfix in RAS task: default value for clear mobile info set to false
bugfix in RAS mobile info: use total timeout, not single timeout
0.0.8.3 - 26.04.2009
initial release
1.4 Important notes for Windows XP, Vista and 7

Administrative rights are required by TSS, otherwise it will not be possible to manage LAN
interfaces, to change the system time etc. Thus the user running TSS needs to be in the
administrators group for all supported operating systems.
For Vista and 7, elevated privileges are required if user account control (UAC) is activated. Thus
TSS includes the requirement for administrative rights in its manifest. To achieve automatic
execution at user logon a task scheduler entry is required, please refer to chapter 2.4.2.2.
1.5 Known limitations

None
1.6 This manual

This manual covers all important aspects of the Test Scheduling System.
Users manual
Chapter 2 describes the installation and configuration
Chapter 3 contains the operation manual
Administrators manual
Chapter 4 contains the administration manual
Chapter 5 contains the technical reference
TSS 0.0.14.0 07.Nov.2011
Introduction
1.7 System architecture

TSS is tightly integrated with PocketOptimizer, WebSpeedTest and the QTS System. This chapter
describes these relations.
1.7.1 Service View

From an architectural point of view, TSS is located between central services (as the Quality Ticket
System QTS) and the probing tools (such as PocketOptimizer and WebSpeedTest).
1.7.2 Functional View

The following figure shows the relation between Test Unit functions, Server functions and
Management functions.
A functional view distinguishes the following functions (bottom to top):

Base functions: these functions include elementary functions as scheduling, job execution,
configuration of LAN/IP interfaces, management of IP routes and timing functions.
TSS 0.0.14.0 07.Nov.2011
Introduction
Test functions: these include functions to establish and analyze internet connections and to
execute test tools such as PocketOptimizer, WebSpeedTest and other tools. These active tools
usually require suitable reference servers.
Reporting: The reporting layer consists of the report generation in the measurement tool and a
report submission unit that submits XML reports to a QTS ticket receiver or relay. Measurement
data can be accessed via SQL, reporting tools or a dashboard.
Synchronization: This layer includes time synchronization via SNTP and synchronization of
application and configuration files via HTTP. Usually public (S)NTP servers can be used for time
synchronization, a dedicated HTTP server is required for file synchronization.
Control functions: Standard methods such as Remote Desktop or OpenSSH are used to control
the Test Unit if required. In addition the TSS Assistance Service provides functions accessible
with the TSS Assistance client.
Log functions: Additional information can be uploaded to an FTP server. The log or data files
can be analyzed manually, automatically or viewed by a Dashboard.
1.7.3 Data view

Measurement functions
The following figure shows the data flow between test units and the reference servers.
Reporting functions
The following figure shows the data flow of XML reports through a QTS Ticket Relay and the QTS
Ticket Receiver. Please note that reporting can be done through the test network (e.g. mobile
internet) or through the management network (e.g. DSL).
TSS 0.0.14.0 07.Nov.2011
Introduction
Synchronization functions
The next figure shows the data flow for synchronization. Application and configuration files are
uploaded to the configuration server from a management console and fetched from the test units
as required. Synchronization can be done through the test network or the management network.
Management functions (without TSS Management Server)

The following figure shows how the test units are controlled via Remote Desktop. Usually the
management network (e.g. DSL) will be used, alternatively the test network can be used if
required.
Please note that it might be complicated to manage test units with varying IP addresses and
multiple network connections (RAS and DSL simultaneously). The TSS Assistance Service contains
functions to deal with some of these problems, but the preferred method is the TSS Management
Server.
TSS 0.0.14.0 07.Nov.2011
Introduction
Management Functions (with TSS Management Server)

The TSS Management Server contains functions to manage all active Test Units. The Test Units
automatically connect to the server allowing the server to provide a list and the status of all active
and inactive Test Units.
In addition, the TSS Management Server provides functions to reboot and remotely control Test
Units even if placed between Firewalls with NAT (and without port forwarding) and to keep
internet connections open for management.
Log functions
The following figure shows the data flow for log file submission. Log files are submitted to a
standard FTP server via the test or the management network. They can be forwarded to or fetched
from an internal server to be available for analysis, reporting functions or the dashboard.
TSS 0.0.14.0 07.Nov.2011
Introduction
Chapter
Installation
This chapter covers the installation of TSS on Windows platforms.
2.1 System requirements

Industry compatible personal computer (minimum requirements depending on your operating
system)
min. 512 MB RAM, 1GB for Windows XP, 2GB for Windows Vista recommended
sufficient hard disk space to store log files (500 MB recommended)
Windows 2000 (SP4), XP (SP1 or SP2), Windows 2003 or Vista
.Net Framework 2.0
fully functional internet (RAS or NDIS) configuration
2.2 Application startup

TSS.exe is a GUI process to allow for simple integration of other test tools and to resemble user
experience as close as possible. A service would theoretically be possible, but could have
drawbacks when running measurement tasks.
It is recommended to execute TSS.exe as a normal GUI process (with elevated privileges) after
user logon, this requires two steps:
automatic user logon
automatic launch of TSS after login (either with autorun in XP or task scheduler in Vista/7).
2.3 Removing previous installations

It is not required to remove existing versions of TSS prior to the installation of a new version.
Nevertheless it is possible to remove the software. The uninstall routine will uninstall the NTService and remove program and helper files Log and configuration files will not be touched or
removed. Thus you will not loose your configuration data when uninstalling TSS.
2.3.1 Removing TSS Win32 Edition

The procedure described in this section will be suitable for most versions of Microsoft Windows
though there may be slight variations.
How to remove TSS Win32 Edition
Open the Windows Control Panel. You will find it in the Windows Start Menu.
Open the Control Panel Application Software.
Select the Item TSS and press the Button Add/Remove.
PocketOptimizer will be removed from your system.
Please consult the documentation for Microsoft Windows if you require more detailed information.
Note: if the TSS Assistance NT-Service has been installed with the automated installer, it will be
stopped and removed by the uninstaller. If you installed the service manually, it is recommended
to remove it before uninstalling TSS.
TSS 0.0.14.0 07.Nov.2011
10
Installation
2.4 Installing TSS

TSS is delivered as a solid setup program (TSS-Win32-Setup-x.x.x.x.exe) for Windows 32-bit. All
you need to do is to run this setup file to start the installation and let the installation process guide
you through setup.
Setup can be customized to install pre-configured files by adding a folder TSS-Custom or TSSCustom-<suffix> to the directory containing the setup program. Please refer to section 4.11 for
details.
2.4.1 Installing TSS Win32 Edition

TSS Win32 Edition is delivered as a solid setup program.
How to install TSS Win32 Edition
Run TSS-Win32-Setup-x.x.x.x.exe to start setup.
Select the desired destination path, start menu folder and data path for TSS.
Specify if the background service shall be installed. For unattended machines the service
should be installed, for workstation machines it might be more comfortable to disable the
background service.
Let setup do the installation.
If you do not change the default target directory, the installation directory will be something like
C:\TSS-System.
2.4.2 Configuring Windows

Some additional steps are required after the TSS setup package has finished.
2.4.2.1 Configuring automatic logon
Windows automatic logon is required to restart TSS after a reboot. You can use a third party tool
such as Tweak UI to enable automatic login, alternatively you can set the registry values
[HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows NT\CurrentVersion\Winlogon]
"AutoAdminLogon"="1"
"DefaultUserName"="user"
"DefaultPassword"="pass"
2.4.2.2 Configuring automatic start

TSS.exe has to be executed with the argument /autorun to start the scheduler automatically.
In Windows 2000 and XP automatic start is automatically configured by the installer, i.e. a shortcut
for TSS.exe /autorun is added to the startup folder.
In Windows Vista or 7 it is required to start TSS.exe with elevated privileges. This is not possible
with the startup folder, thus a task scheduler entry has to be created. Follow these steps to
configure automatic start:
Open Control Panel > Administrative Tools > Task Scheduler
Create Task
General
- Name: TSS-Autorun
- check Run with highest privileges
Triggers
- new trigger: At log on, any user
Actions
- Start a program: D:\TSS\bin\TSS.exe /autorun
Conditions
- uncheck Start the task only if the computer is on AC power
Settings
- check If the task fails, restart every, set values to 1 minute and 3 times
- uncheck Stop the task if it runs longer than
TSS 0.0.14.0 07.Nov.2011
11
Installation
2.4.2.3 Default Ports

The default ports for a TSS configuration are:
UDP 8866 (9012) TSS Assistance Service
TCP 8868 (9018) TSS Assistance Service
TCP 8869 (9016) TSS (reserved)
TCP
22 (9015) OpenSSH
TCP 3389 (9017) Remote Desktop
TCP 5800 (9014) ... TightVNC
(GPS broadcast)
(status broadcast)
(UDP command interface)
(local communication, external use reserved)
2.4.2.4 Remote Desktop

If remote management is required, don't forget to enable remote management and ensure the
RDP Port is not blocked by the Windows Firewall. The recommendation is to change the default
RDP port (3389) to a user defined value, the default value is 9017 (the TSS Assistance Service port
- 1).
2.4.2.5 OpenSSH
OpenSSH can be installed if required and is supported by the TSS Assistance Service for
SSH/terminal connections. Please refer to the product's documentation for details. It is
recommended to change the default port (22), e.g. to 9015 (the TSS Assistance Service port - 3).
2.4.2.6 VNC Server
If your Windows version does not include the Remote Desktop Server (Windows XP Home,
Windows Vista Home, Windows 7 Home), you might want to use a VNC server.
TSS has been tested with the free TightVNC server that can be downloaded from
www.tightvnc.com.
TightVNC can be installed with the default settings with some modifications.
Open the TightVNC Admin panel: Right click VNC Tray Icon > Configuration
Server / Incoming Viewer Connections
- change main server port to 9014
Server / Web Access
- uncheck Serve Java Viewer To Web clients
Access Control / Loopback Connections
- check Allow loopback connections
2.4.2.7 Windows firewall
Depending on your configuration several ports should be available for access from the internet.
For the minimum configuration (TSS and TSS Assistance service) this is UDP port 9018.
For the services mentioned in the previous section these are TCP port 9017 for RDP, TCP port 9016
for OpenSSH and TCP port 9014 for VNC.
It is recommended to open TCP ports 9010..9019 and UDP ports 9010..9019 for compatibility with
future enhancements.
2.5 Registering TSS

It is required to register TSS for your machine prior to using it. Registration is required to ensure
all instances of TSS are assigned unique Agent-IDs and to prevent license misuse.
Different registration schemes are possible depending on the licensed package:
For non-branded licenses, a license request has to be submitted to the software vendor. You
will then be provided the registration data to unlock TSS.
For branded licenses, a special registration utility is available for your license administrator.
This utility can be used to create the unlock key. Please refer to the reference manual for
detailed information.
TSS 0.0.14.0 07.Nov.2011
12
Installation
Registration basics
TSS automatically calculates a Machine ID from your machines unique data.
This Machine ID has to be submitted to the license server or administrator.
The sales representative or license administrator will assign an Agent ID and generate the
Unlocking Code for your combination of Machine ID and Agent ID.
After entering Agent-ID and Unlocking Code your copy of TSS is functional.
Please note that TSS, PocketOptimizer and WebSpeedTest have to be registered independently. If
you use the registration function in TSS to submit a request to the registration server,
WebSpeedTest and PocketOptimizer will automatically started in the background to submit a
registration request, too.
2.5.1 Getting the Machine ID

The Machine ID will automatically be calculated by TSS every time it is executed. It is derived form
your machines internal data and is unique for every machine. The Machine ID can be viewed any
time clicking on the Register button in the main window. It is shown on the tab sheet Licensee.
You have to pass the Machine ID either to a license server or to your license administrator. Please
refer to the next chapters for details.
2.5.2 Automatic registration with license server

Hit the button Register... in the main window to open the registration window.
Entering user information and submitting a license request
To submit or create a registration request, use the function Send a registration request and click
Proceed.
Enter your company name and address, user name and e-mail address. An information e-mail will
be sent to this address when the registration server's database has been updated to provide you
with unlocking data.
Click Proceed to move to the request sheet. This sheet provides some additional input fields that
might or might not be applicable for you:
License: Select Purchased or Evaluation of you have already purchased a license or are
requesting an evaluation license.
Request: This field influences how the registration server will process your request:
o Extend active registration ... This is the default value. If an unlock item is existing in the
license server's database, you will immediately provided with the unlocking data. Otherwise
the data is forwarded to a sales representative or license administrator.
o Manually check my request ... In this case the server does not provide you with unlocking
data automatically, instead your request is always forwarded to sales representative or
license administrator. Use this function if you changed input fields or need a different
license type.
o Unlock code does not work ... This case is similar to the previous one, but the request is
forwarded to our support team.
Vendor: Enter your vendor code if you purchased the software from a reseller. Otherwise leave
the field empty.
Offer No: Enter your software vendor's offer number if you have received different offers with
different software features. Leave the field empty if you only have one offer or are requesting
an evaluation license.
Agent ID: If you want to use a special agent ID (e.g. if you want to re-use an ID), enter it
here.
Agent Pool: If your company uses different pools of agent IDs (e.g. for different departments),
you can enter the required pool name here.
Message: Use this field to provide a message to your sales representative or license
administrator.
Please ensure your machine is connected to the internet and use the button Send request to
submit the request to the license server. If an existing unlock item is found in the database, you
will immediately provided with the unlock data, otherwise you will be informed that the request will
be processed. Usually the unlock information should be available within 15..30 minutes. If required
close TSS while waiting for the unlock data, your input will be saved for further use.
TSS 0.0.14.0 07.Nov.2011
13
Installation
If it is not possible to send the data directly, use the button Save... to save the license request to a
file and send this file to your sales representative or license administrator via e-mail.
Fetching the unlock data
You will be sent an e-mail when your registration has been processed.
To fetch the license data from the server, simply submit the license request again without
changing any information on the Licensee sheet. Please ensure that you use the request Extend
active registration, otherwise the server will not provide the unlock data.
If unlock data is available on the server, the unlocking data is automatically inserted into the input
fields. Check the option I accept the license terms if you agree to the license terms and use the
button Register to save the registration information.
2.5.3 Manual registration with license server

If automatic submission to a license server is not possible, follow the steps as described in the
previous chapter to enter the required information.
Use the button Save... to save the request into a file and submit this file to your sales
representative or license administrator.
You will be provided the unlock data via an e-mail, please save the unlock data into a file and use
the button Load... on the Registration sheet to load the file. After accepting the license terms, you
will be able to register the application.
2.5.4 Manual registration with license utility (branded versions only)

This registration procedure is only available with branded versions that are associated with a
customer and thus do not require the extended unlock information.
Please note that manual registration will only work with special unlock codes and with branded
versions only.
Getting the Machine ID
Copy the Machine ID to the clipboard and pass it to your license administrator.
Entering the Unlock code
Usually you will receive Agent ID and Unlock Code per e-mail. Use the button Register... to open
the registration wizard. Choose Enter registration information to change to the registration sheet.
You only need to enter the last two input fields Agent ID and Unlock. Accept the license terms and
use the button Register to register the application.
2.6 Configuring TSS Tasks

If you a custom configuration directory is used (i.e. the folders TSS-Custom-<suffix>), the main
configuration files including machine.cfg and system.cfg should already be configured properly.
Simply run a synchronization task to synchronize with the server in this case.
2.6.1 Configuring TSS without a server

If no reference configuration on a server is available, edit the sample job and scheduler files to
achieve a working configuration.
Step 1: Edit configuration files
If you did not use the installer customization, be sure to edit the configuration files to enter proper
values.
Step 2: Edit a TSS job file
You should start with one of the sample job files provided in the samples directory and change to
required parameters to meet your requirements. Place the resulting file in the jobs directory.
Step 3: Test the TSS job file
Simply use the button Start Job to select and start the TSS job. Click on the order number in the
task view to switch to the job's log output if required. If the job contains errors edit the file and
run another task until the job is configured properly
TSS 0.0.14.0 07.Nov.2011
14
Installation
Step 4: Configure the scheduler

Use the sample scheduler file in the samples directory and copy it to the scheduler directory. Enter
the proper TSS job file name and period as required.
Click the button Start Scheduler to start and test the scheduler.
2.6.2 Configuring TSS with a server

If a configuration server is available, you can synchronize the settings from the server.
Step 1: Edit configuration files
If you did not use the installer customization, be sure to edit the configuration files.
Step 2: Set up server
Depending on your server configuration, it might be required to add the machine's agent ID to the
file synchronization.cfg on the server. If you use a default configuration (*) in synchronization.cfg
and the machine shall use the default configuration, this step is not required.
Step 3: Run synchronization
Ensue an internet connection is available and use the button Start Job... to start the job ManualFileSync.tss-job in the sub-directory Add. This task will fetch the configuration from the default
configuration server.
TSS 0.0.14.0 07.Nov.2011
15
Installation
Chapter
Operations Manual
This section describes how to use TSS.
3.1 The user front end

TSS is designed as GUI application to allow the integrated scheduler to start the probing
applications in the foreground mode. This is especially important for applications as WebSpeedTest
that test web browsing performance including display rendering and thus require an active
foreground window.
The TSS front end is shown below:
The interface elements are:

Several buttons to control the user interface, the scheduler, execute jobs and register the
application
Views for the scheduler and running/executed tasks
Views for various internal data sources.
Buttons
The buttons control some important functions of TSS:
Use the button Refresh GUI to force a refresh of the entire user interface. This function should
not be required in normal operation.
The button Clean List removes all executed tasks from the task view and releases internal
memory.
TSS 0.0.14.0 07.Nov.2011
16
Operations Manual
The buttons Start Sched. and Stop Sched. start and stop the scheduler.
The button Start Job allows the selection of a job and immediately executes it. Please note
that there are no concurrency checks, i.e. the user is responsible to start jobs only if no other
tasks are affected.
The button Register opens the registration dialog.
Scheduler/Task view
Two different views are available:
The default view uses a text control to give a resource optimized overview of running and
finished tasks.
The table view provides a graphical view but consumes more resources. A context menu is
available in this view that allows cancellation of running tasks.
Special data view
The bottom area contains several dedicated text controls:
The view Selected Item shows the content of the item selected in the scheduler/task view. You
can either select a task in the table to view its log or click on the order number in the simple
text view.
The System Status shows important internal parameters such as run time, memory and
resource requirements.
The Task Status shows the content of the internal task storage. This storage contains the
maximum number of consecutive errors, the current number of errors and the number of
successful and total executions for every task.
The Scheduler Status shows the scheduled items.
The Registration Status shows the registration information for TSS, PocketOptimizer and
WebSpeedTest.
The Message tab shows additional messages on startup or errors and warnings when starting
the application, the scheduler or a task.
3.2 The TSS Assistance Service and Client

The Assistance Service is an NT Service running in the background and started together with
Windows. It provides the following functions:
A UDP response service is available (similar to ping)
A routing service controlled by UDP packets
A reboot service controlled by UDP packets
It provides an additional watchdog for the TSS application and scheduler
An integrated client to the TSS Management Server
Additional information is available in chapter 4.13.2.
3.2.1 Operation modes

The TSS Assistant Client supports two different operation modes.
Standalone Mode
Client for TSS Management Server
In standalone mode, the TSS Assistance Service acts as a UDP server that supports some basic
commands. UDP is used because it does not require 3-way handshaking, thus operation might be
possible even if there are problems with the current routing table.
The supported commands are: connection test, set route and reboot. A dedicated client is available
to send the UDP commands and receive responses.
In client mode, the TSS Assistance Service acts as a client for the TSS Management Server. As
soon as a network interface is allowed to be used for management purposes, the client opens a
TCP connection to the TSS Management Server. As the direction is from the client to the server,
there should not be problems to pass firewalls and routers (without the requirement for port
forwarding). The server can use this connection to send commands to the service. Additional
connections (as for RDP) are established in the same manner (i.e. from the service to the server).
Interfaces are available for management either permanently (e.g. LAN interfaces) or as soon as
allowed by a task. To enable or disable an interface for management use the parameter manageinterfaces in a delay task.
TSS 0.0.14.0 07.Nov.2011
17
Operations Manual
The operations of standalone mode are available in client mode, too.
3.2.2 Standalone operation

The Assistance Service does not provide a user interface directly. The user interface for the UDP
functions is the TSS Assistance Client that is usually executed on a remote management computer.
To use the assistance client, please enter the target machine's IP address and select the required
operation. If you want to reboot the target machine, the reboot password is required.
After clicking the Send button, the client license sends the command via UDP and waits for
returning UDP packets. Usually the server should return 4 packets. Please note that it might be
impossible for the client to send the packet if different default routes are configured.
The possible commands are:
connection test
set route
reboot
The connection test simply sends connection test commands and waits for UDP response
packets. Use this command to check if the connection is available. Please note that it might be
impossible for the target to return UDP packets if the routes are not set correctly.
The set route command sets a route for the machine running the TSS Assistance Client on the
target machine. The command can be used to set a route before the Remote Desktop Protocol
(RDP) can be used. The command works as follows: If the TSS Assistance Service receives a set
route packet from <src> in interface <if>, a route to <src> with mask 255.255.255.255 will be
added to the routing table for interface <if>. The routine will automatically be removed after a
given timeout.
The reboot command can be used to reboot the target computer. You should use a connection
test command to ensure that a connection is available. Please note that it is possible that the
target is rebooted even if no response UDP packets are received.
In addition the button Connect RDP can be used to start the Remote Desktop Client (MSTSC.exe)
for the specified IP Address (and port - 1). The function is the same as opening MSTSC.exe
manually and connecting it to the given port. It is provided for convenience if the TSS Assistance
Client was used to set a route and the IP address is already entered.
If a file default.rdp exists in the same directory as the TSS Assistance Client executable, this file
will be used as template for MSTSC.exe. You can save your user name, password and display
resolution to this file, the client will then automatically log on to the target machine. Please note
that the same restrictions due to routing apply.
TSS 0.0.14.0 07.Nov.2011
18
Operations Manual
3.2.3 Operation with TSS Management Server

The TSS Assistance Service can be used with the TSS Management Server as soon as the
parameter Manage-Server is configured in system.cfg.
The service then uses permanent internet connections (i.e. connections not listed in the filters
defined by RasUsbEnumServices and RasNicNames in assistance.cfg) to connect to the TSS
Management Servers. Other connections can be enabled for management by setting ManageInterfaces in a delay task.
When the TSS Assistance Service has successfully connected to the TSS Management Server, the
server's web front end can be used to establish remote control connections.
Please refer to the documentation of the TSS Management Server for details.
TSS 0.0.14.0 07.Nov.2011
19
Operations Manual
Chapter
Administrators Manual
This section contains information for the system and license administrator and is not intended for end
users.
4.1 TSS Functions

The Test Scheduling System consists of the following main functions:
Scheduler
The scheduler serves two main purposes:
Schedule jobs or job sequences for execution as defined in the scheduler configuration file
scheduler.xml.
Execute system reboots or application restarts if required by updates or due to error conditions.
Execution unit
The execution unit is responsible for the execution of jobs or job sequences and the individual tasks:
Execution of tasks with loop iterations, execution conditions and sub-jobs.
Management of RAS or custom internet connections, interfaces and other system resources
including undo of changes during the measurements in case of successful and erroneous job
completion.
Management of the individual task's status and error counters.
Tasks
Several different tasks are available to execute specific functions. A description of available tasks is
provided in one of the next chapters.
Service
A background service (the TSS Assistance Service) is available to provide additional functionalities and
security. The service's tasks are:
Support to set custom routes for specific IP addresses with mask 255.255.255.255.
Support to reboot the machine on request or if the scheduler or TSS.exe fails.
Manage connection with the TSS Management Server
4.2 Directories
TSS is usually installed in one or two directories.
The manual distinguishes program directories (programs and configuration files) and data directories
(containing data created by TSS and the measurement tools).
4.2.1 Single directory scheme

In this case the data directory is a sub directory of the application directory. The application directory
is typically installed to C:\TSS-System or D:\TSS-System.
Program directories
C:\TSS-System
C:\TSS-System\Apps
C:\TSS-System\Apps\PO
C:\TSS-System\Apps\WST
C:\TSS-System\Scripts
TSS 0.0.14.0 07.Nov.2011
20
C:\TSS-System\Jobs
C:\TSS-System\Jobs\PO
C:\TSS-System\Jobs\WST
C:\TSS-System\Scheduler
Data directories
C:\TSS-System\Data
C:\TSS-System\Data\Work
C:\TSS-System\Data\Work\Logs
C:\TSS-System\Data\Work\Reports
C:\TSS-System\Data\Work\Data
C:\TSS-System\Data\Work\Sniffer
C:\TSS-System\Data\Work\Scheduler
C:\TSS-System\Data\Work\Assistance
C:\TSS-System\Data\Archive
C:\TSS-System\Data\Archive\Logs
C:\TSS-System\Data\Archive\Reports
C:\TSS-System\Data\Archive\Data
C:\TSS-System\Data\Archive\Sniffer
C:\TSS-System\Data\Archive\Scheduler
C:\TSS-System\Data\Archive\Assistance
C:\TSS-System\Data\Outbox
C:\TSS-System\Data\Outbox\Logs
C:\TSS-System\Data\Outbox\Reports
C:\TSS-System\Data\Outbox\Data
C:\TSS-System\Data\Errors
C:\TSS-System\Data\Errors\Logs
C:\TSS-System\Data\Errors\Reports
C:\TSS-System\Data\Errors\Data
C:\TSS-System\Data\Temp
C:\TSS-System\Data\Persistent
4.2.2 Dual directory scheme

In this case the data directory is a mapped to a different directory using the configuration parameter
[Directories].Data in the machine configuration file. The data directory is typically installed to C:\TSSData or D:\TSS-Data.
Program directories
C:\TSS-System
C:\TSS-System\Apps
C:\TSS-System\Apps\PO
C:\TSS-System\Apps\WST
C:\TSS-System\Scripts
C:\TSS-System\Jobs
C:\TSS-System\Jobs\PO
C:\TSS-System\Jobs\WST
C:\TSS-System\Scheduler
Data directories
C:\TSS-Data
C:\TSS-Data\Work
C:\TSS-Data\Work\Logs
C:\TSS-Data\Work\Reports
C:\TSS-Data\Work\Data
C:\TSS-Data\Work\Sniffer
C:\TSS-Data\Work\Scheduler
C:\TSS-Data\Work\Assistance
C:\TSS-Data\Archive
C:\TSS-Data\Archive\Logs
C:\TSS-Data\Archive\Reports
C:\TSS-Data\Archive\Data
C:\TSS-Data\Archive\Sniffer
C:\TSS-Data\Archive\Scheduler
C:\TSS-Data\Archive\Assistance
C:\TSS-Data\Outbox
C:\TSS-Data\Outbox\Logs
C:\TSS-Data\Outbox\Reports
C:\TSS-Data\Outbox\Data
C:\TSS-Data\Errors
C:\TSS-Data\Errors\Logs
C:\TSS-Data\Errors\Reports
C:\TSS-Data\Errors\Data
C:\TSS-Data\Temp
C:\TSS-Data\Persistent
TSS 0.0.14.0 07.Nov.2011
21
4.3 Scheduler
One main component of TSS is the integrated scheduler. This scheduler is configured with the file
scheduler.xml and is responsible for starting TSS jobs.
The scheduler periodically loads scheduler.xml and evaluates the next scheduler item to be executed.
Items can be scheduled periodically (e.g. hourly) at given times of a day (e.g. every day at 14:00) or
continuously. The scheduler manages internal resources and delays scheduled tasks until the required
resources are available. Then the job files are loaded and execution is passed to the execution unit.
Note: In the current version of TSS resources are used exclusively, i.e. only one concurrent task is
executed by the scheduler.
4.4 Execution unit and jobs

The TSS execution unit is able to run multiple job sequences in parallel. Job sequences can consist of
one or several job files that are executed consecutively.
Every job consists of several tasks that can use internal functions, execute sub-jobs or run external
tools.
4.5 Tasks
TSS jobs consist of well known tasks.
The supported task types are:
Pause
Inserts a pause of the specified duration into the job sequence.
Sub-Job
This task executes another TSS-Job as a sub job. Sub jobs can be used for logical grouping, to reuse sequences of tasks or to apply conditions to a group of tasks.
CIC-Connect
Establishes a custom internet connection (CIC), such as a RAS connection or a Huawei NDIS
connection. The connection can be continuously monitored if required.
CIC-Hangup
Terminates a custom internet connection.
RAS-Connect (deprecated, use CIC-Connect instead)
Establishes a RAS connection. The connection can be continuously monitored if required.
RAS-Hangup (deprecated, use CIC-Hangup instead)
Terminates a RAS connection.
AT-Command
Sends AT commands to the device associated with a RAS connection.
CheckModem =0.0.12.6=
Checks if the modem device is available and responding to AT commands.
PocketOptimizer
Executes PocketOptimizer with a specified job file.
WebSpeedTest
Executes WebSpeedTest, the required parameters can be specified as parameters.
Execute
Executes additional tools such as Perl scripts, batch files etc.
TimeSync
Runs the SNTP client to synchronize the local time with an external time server.
Report
Submits the measurement (XML) reports from the outbox directory to the ticket receiver.
SubmitLogs
Submits the measurement logs and data files from the outbox directory to an FTP server. The task
can be deactivated with the configuration parameter Submit-Enable.
FileSync
Synchronizes configuration and application files from the synchronization. This task can be
deactivated with the configuration parameter Sync-Enable.
Registration
Submits a registration request to the registration server to register the application or extend the
expiration date.
TSS 0.0.14.0 07.Nov.2011
22
IPConfig
Manages IP parameters for LAN or RAS interfaces. Usually this task is used to remove default
routes and DNS servers from LAN/DSL interfaces to avoid influences to the measurement results.
Route
This task removes default routes if required.
GetPublicIP
Contacts a special server to get a public IP address. The task will only be executed if an active
interface is available.
Clean
Manages log and data files on the file system: adds files to .7z archives and the archive folders,
deletes excessive data files and copies files to the outbox folder.
Reboot
Initiates a system reboot.
ModemPowerCycle =0.0.12=
Run a modem power cycle (i.e. turn power off for 10 seconds) if an external modem power switch
(MPSW) is available.
Sniffer-Start and Sniffer-Stop =0.0.13.6=
Start or stop an external packet sniffer (NetCap, NMCap or TShark). Sniffer files can be shrinked
(i.e. reduce packet size) and compressed with 7-zip.
4.6 Job and task variables

TSS supports different classes of variables and variable functions:
system defined variables: a list of well known system variables provided by TSS
e.g. %execid%, %taskid%, %logid%...
system defined functions: several functions that can be customized by parameters
e.g. %rands(std,8)%, %randi(0,999,1,3)%
user defined variables: can be defined in configuration or job files and used as required
e.g. define: user_test_param: 1234, use: %user_test_param%
4.6.1 System defined variables

Please refer to chapter 5.3.30 for a detailed reference, the list of available variables is:
%ExecId%
%TaskId%
%LogId%
%Prefix%
%AgentId%
%RasEntry%
%RasIpAddr%
%CicId%
%CicIpAddr%
%BinPath%
%ToolPath%
%ScriptPath%
%JobPath%
%VarPath%
%LogPath%
%ReportPath%
%DataPath%
%TempPath%
%ControlFile%
%ResponseFile%
%IndexFile%
%HistoryFile%
%ReportFile%
yyyymmdd-hhnnss-zzzz-pp-qq
j[(ll)].tii[(ll)][...]
[job/task info]
<ExecId>.<LogId>
<agent-ID>
<RAS entry>
<ip>
<CIC identifier>
<ip>
<dir>
(sys)
=0.0.13.0=
<dir>
(sys\apps)
=0.0.13.0=
<dir>
(sys\scripts) =0.0.13.0=
<dir>
(sys\jobs)
=0.0.13.0=
<dir>
(var)
=0.0.13.0=
<dir>
(var\work\logs)
<dir>
(var\work\reports)
<dir>
(var\work\data)
<dir>
(var\temp)
<execid>-control.dat
<execid>-response.dat
<execid>-index.dat
<execid>-history.dat
<execid>-report.xml
4.6.2 System defined functions

Please refer to chapter 5.3.31 for a detailed reference, the list of available functions is:
%rands(fmt,len)%
%randi(min,max,[step],[len])%
%date([loc],[fmt])%
%time([loc],[fmt])%
%dt([loc],[fmt])%
TSS 0.0.14.0 07.Nov.2011
...
...
...
...
...
random string (fmt=std/base64, len=length in chars)

random integer
current date (loc=loc/utc, fmt=yyyy-mm-dd)
current time (loc=loc/utc, fmt=hh:nn:ss)
date/time (loc=loc/utc, fmt=yyyy-mm-ddThh:nn.ss+zz:zz)
23
4.6.3 User defined variables

User defined variables can be defined in configuration files or job files. Please refer to chapter 5.3.2
for details.
User defined variables in configuration files.
Variables with any name (not conflicting with system defined variables or functions) can be defined in
the [user] sections of the following configuration files:
machine.cfg
application.cfg
platform.cfg
system.cfg
User defined variables in job sections

Variables can be defined in the section [job] of a job file. The variables are valid for the entire job
including all tasks and sub-jobs. The variable names have to start with "User-".
User defined variables in task sections
Variables can be defined in the section [task] of a job file. The variables are valid only for the current
task (and sub-jobs or task in case of a Sub-Job task). The variable names have to start with "User-".
4.6.4 Variable expansion

Variables are expanded when they are used. Nested variables and functions are possible.
If variables are used in form %name%, the variable has to be defined, otherwise an error will be
generated. If an empty string shall be used if a variable is not defined, the form %@name% has to be
used.
4.7 Internet connections: RAS and CIC

TSS supports different types of internet connections
permanent internet connections (e.g. DSL or external 3G routers)
RAS connections (Windows RAS API)
NDIS connections managed by Huawei NDIS API
Connections managed by external tools
4.7.1 Types of connections

4.7.1.1 Permanent internet connections
Permanent internet connections are not managed or evaluated by TSS. Measurement and reporting
tasks automatically use the active interface.
4.7.1.2 RAS connections
The Windows Remote Access Service (RAS) is the main method for non-permanent modem and
internet connections. The RAS API provides functions to establish and terminate internet connections
and to query statistics (such as byte counters).
RAS connections can be used in TSS with the tasks CIC-Connect and CIC-Hangup. The tasks RASConnect and RAS-Hangup are available for compatibility with previous versions.
4.7.1.3 NDIS connections managed by Huawei NDIS API
The Network Driver Interface Specification (NDIS) is the driver model for Windows network adapters.
Several 3G HSPA modems do not only offer modem functions (compatible with RAS) but do also
provide NDIS drivers for a virtual LAN or WLAN card. Unfortunately NDIS does not provide a
standardized interface for management functions, thus additional APIs have to be used to control the
virtual network cards.
TSS supports the Huawei NDIS API that is contained in the file ndisapi.dll. The file has to be copied to
the TSS executable directory before the functions can be used. For property reasons it cannot be
delivered with the TSS setup package.
TSS 0.0.14.0 07.Nov.2011
24
Huawei NDIS Connections can be used with the tasks CIC-Connect and CIC-Hangup. In contrast to
RAS connections the NDIS API does not provide a phonebook that stores user names and passwords.
Thus a number of additional parameters (user name, password, APN) has to be provided for these
connections.
4.7.1.4 Connections managed by external tools
It is possible to manage internet connections with external tools. These connections are treated as
permanent internet connections by TSS.
4.7.2 Connection identifiers

CIC identifiers consist of a CIC type and parameters, separated by a colon (:). Supported CIC types
are RAS and HwNd (Huawei NDIS API).
RAS connections
For RAS connections, the format is RAS:<phonebook entry>. The phonebook entry name is the
entry of the RAS connection as shown in the Windows network connections. The following screenshot
shows two RAS connections: MBB and HUAWEI3G.A1.
The CIC identifiers in this case would be RAS:MBB and RAS:HUAWEI3G.A1.
Huawei NDIS API connections
For Huawei NDIS API connections, the format is HwND:<device name>. Please note that the
device name is not the name listed in the network connections (i.e. not MBB-NDIS-Huawei.5 as shown
in the next screenshot, this is the user defined, friendly name of the network connection). The device
name is shown in the column device name or in the device manager as shown in the second
screenshot (HUAWEI Mobile Connect - 3G Network Card).
Please note that if you connect the USB stick to a different port, the device name will be different
(e.g. HUAWEI Mobile Connect - 3G Network Card #2). The CIC identifier supports wildcards to
simplify the configuration in these cases: =0.0.12=
HwND:* ... uses any Huawei NDIS device if exactly one device is available
HwND:<device name>* ... uses any device starting with the given name (if exactly one device
matches the filter).
The CIC identifier in the previous example case would be "HwNd:Huawei Mobile Connect - 3G
Network Card*".
TSS 0.0.14.0 07.Nov.2011
25
4.7.3 CIC tasks and configuration

Custom internet connections (CIC) are the preferred method to manage temporary internet
connections in TSS.
To ensure that the same measurement jobs can be used on different machines with different internet
connections, it is recommended to separate the connection data from the jobs and to store it in one of
the configuration files. The recommended place is the section [User] in the machine configuration file.
Please note that CIC connection IDs have to be provided in form
RAS:<RAS phonebook entry>
HwNd:<card name>[*]
4.7.3.1 Sample machine configuration file for RAS connection

The following example shows how configuration parameters can be used to store the required
parameters for a CIC task.
Please note that the CIC connection ID is in form RAS:<RAS phonebook entry> to be used by the CIC
tasks. User name, password and APN are not required for RAS connections.
Sample content in machine.cfg:
[User]
Default-CIC-ConnId:
RAS:A1.net
Default-CIC-User:
; not required for RAS
Default-CIC-Password: ; not required for RAS
Default-CIC-APN:
4.7.3.2 Sample machine configuration file for Huawei NDIS connection

parameters for a CIC task.
Please note that Huawei NDIS connection IDs are in form HwNd:<card name>. User name, password
and APN are required by the API.
[User]
Default-CIC-ConnId:
Default-CIC-User:
Default-CIC-Password:
Default-CIC-APN:
TSS 0.0.14.0 07.Nov.2011
HwNd:HUAWEI Mobile Connect - 3G Network Card*

ppp@a1plus.at
ppp
a1.net
26
Please note that the CIC connection ID ends with an asterisk (*) to allow for device names ending
with #2, #3 etc. =0.0.12=
4.7.3.3 Sample measurement task
The following sample job shows how the CIC tasks and the parameters defined in the machine
configuration files can be used in a measurement job.
For convenience local variables can be defined in the [Job] section. This can be of advantage if the
internet connection shall be defined manually for test purposes. In this case only a single occurrence
has to be edited even if the parameter is used multiple times in the job file or in sub-jobs.
Please note the variables using %@...%: If a referenced variable is preceded by the @ character, no
error will occur if it is not defined. This allows for compatibility with old machine configuration files.
[Job]
User-CIC-ConnId:
User-CIC-User:
User-CIC-Password:
User-CIC-APN:
%Default-CIC-ConnId%
%@Default-CIC-User%
%@Default-CIC-Password%
%@Default-CIC-APN%
[Task]
Type:
CIC-ConnId:
CIC-User:
CIC-Password:
CIC-APN:
Scenario-ID:
CIC-Connect
%User-CIC-Entry%
%User-CIC-User%
%User-CIC-Password%
%User-CIC-APN%
1001
[Task]
... measurement tasks here...
[Task]
Type:
CIC-ConnID:
Scenario-ID:
CIC-Hangup
%User-CIC-Entry%
1002
4.7.4 RAS tasks and configuration

RAS tasks are contained for backward compatibility, new configurations should use the CIC tasks. To
simplify migration, RAS tasks support custom internet connections, too.
Thus the RAS entry parameter can be given in form
<RAS phonebook entry>
RAS:<RAS phonebook entry>
HwNd:<card name>[*]
It is recommended to move the definition of the connection to a configuration file.

4.7.4.1 Sample machine configuration file for RAS connection
parameters for a RAS task.
Please note that the RAS entry can consist of the phonebook entry name without a prefix.
[User]
Default-RAS-Entry:
A1.net
Default-RAS-User:
Default-RAS-Password: ; not required for RAS
Default-RAS-APN:
4.7.4.2 Sample machine configuration file for Huawei NDIS connection

parameters for a RAS task.
Please note that Huawei NDIS connection IDs are in form HwNd:<card name>. User name, password
and APN are required by the API.
[User]
Default-RAS-Entry:
Default-RAS-User:
TSS 0.0.14.0 07.Nov.2011

ppp@a1plus.at
27
Default-RAS-Password:
Default-RAS-APN:
ppp
a1.net
Please note that the CIC connection ID ends with an asterisk (*) to allow for device names ending
with #2, #3 etc. =0.0.12=
4.7.4.3 Sample measurement task
The following sample job shows how the RAS tasks and the parameters defined in the machine
configuration files can be used in a measurement job.
For convenience local variables can be defined in the [Job] section. This can be of advantage if the
internet connection shall be defined manually for test purposes. In this case only a single occurrence
has to be edited even if the parameter is used multiple times in the job file or in sub-jobs.
Please note that parameters for user name, password and APN should be defined even if not required
for RAS tasks. Otherwise the job cannot be used for Huawei NDIS connections at a later time.
[Job]
User-RAS-Entry:
User-RAS-User:
User-RAS-Password:
User-RAS-APN:
%Default-RAS-Entry%
%@Default-RAS-User%
%@Default-RAS-Password%
%@Default-RAS-APN%
[Task]
Type:
RAS-Entry:
RAS-User:
RAS-Password:
RAS-APN:
Scenario-ID:
RAS-Connect
%User-RAS-Entry%
%User-RAS-User%
%User-RAS-Password%
%User-RAS-APN%
1001
[Task]
... measurement tasks here...
[Task]
Type:
Ras-Entry:
Scenario-ID:
RAS-Hangup
%User-RAS-Entry%
1002
4.8 Firewall rules

TSS and the TSS Assistance Service use UDP and TCP protocols for communication.
4.8.1 Communication overview

Local communication between TSS and TAS
TCP system connections (local, TSS TAS)
TAS waits for incoming TCP connections from TSS on a user defined TCP port, please refer to
[Network].TcpService for details.
UDP GPS broadcast (local or remote, TAS TSS and TSM)
TAS sends UDP GPS broadcast packets to TSS on the local machine and to other TSS instances or
the TSS status monitor in the LAN (only if GPS is used), please refer to [GPS].Broadcast-Port for
details.
Communication between TAS and TSS Management Server/TSS Assistance Client
UDP control connections (incoming, TAC TAS)
TAS receives UDP packets from the TSS Assistance Client on a user defined UDP port and answers
on the same port, please refer to [Network].ListenPort for details.
TCP control connections (outgoing, TAS TMS)
TAS establishes outgoing TCP control connections to the TSS Management Server as defined in
[Communication].Manage-Server.
TCP chaining connections (outgoing, TAS TMS)
TAS establishes outgoing TCP data connections to the TSS Management Server. The used port is
defined by TMS, it can either be a port within the tunneling port range (protocol v1) or the same
port as the control port (protocol v2) =0.0.25=.
TSS 0.0.14.0 07.Nov.2011
28
Local/LAN communication for TMS chaining service

TCP chaining connections (local or remote, TAS RDP, VNC)
TAS connects outgoing connections to the local RDP and VNC server or to RDP and VNC servers
on other test units in the LAN.
LAN communication (drive testing)
UDP system broadcast (local or remote, TAS TAS and TSM)
TAS sends UDP broadcast packets to other TAS instances or the TSS status monitor in a LAN,
pleas refer to [Network].Broadcast-Port for details.
UDP GPS broadcast (local or remote, TAS TSS and TSM)
TAS sends UDP broadcast packets to TSS on the local machine and to other TSS instances or the
TSS status monitor in the LAN (only if GPS is used), please refer to [GPS].Broadcast-Port for
details.
TSS ticket broadcast (remote, TSS TSS)
TSS sends UDP broadcast packets containing QTS tickets to other TSS instances in the LAN.
Important QTS tickets can then be submitted by other test units.
TSS status monitor communication (remote, TSM TSS)
TSS waits for incoming TCP connections from TSM to provided additional quality and execution
information. Please refer to [NetworkServices].StatusTCPPort.
4.8.2 Protocol summary

The following tables summarize the required UDP and TCP connections.
Network communication by TSS
program protocol
Local communication
TAS
TCP
TAS
UDP bcast
LAN communication
TSS
UDP bcast
TAS
UDP bcast
TSS
UDP bcast
TSS
TCP
direction
zone
default port
info
out
in
localhost
localhost
8868 or 9018
8866 or 9012
communication with local TAS

UDP GPS broadcast (local)
out
in
in
in
LAN
LAN
LAN
LAN
8869
8866
8869
8869
UDP
UDP
UDP
TCP
or
or
or
or
9016
9012
9016
9016
packet broadcast
GPS broadcast (LAN)
packet broadcast
communication with TSM
Network communication by TAS

program protocol
direction zone
Local communication
TSS
TCP
in
localhost
TSS
UDP bcast out
localhost
TAC communication
TAC
UDP
in/out
internet
TMS communication (to server)
TMS
TCP
out
internet
TMS
TCP
out
internet
TMS
TCP
out
internet
TMS communication (to localhost)
RDP
TCP
out
localhost
VNC
TCP
out
localhost
SSH
TCP
out
localhost
TMS communication (to remote units)
RDP
TCP
out
LAN
VNC
TCP
out
LAN
SSH
TCP
out
LAN
LAN communication
TAS
UDP bcast out
LAN
TAS
UDP bcast out
LAN
TAS
UDP bcast in
LAN
default port
info
8868 or 9018
8866 or 9012
communication with local TSS

UDP GPS broadcast
8868 or 9018
UDP packets from/to TAC
8798
8700..8797
8798
TMS control connection

TMS data connections (v1)
TMS data connections (v2)
3389 or 9017
5900 or 9014
22 or 9015
local RDP server

local VNC server
local SSH server
3389 or 9017
5900 or 9014
22 or 9015
remote RDP server

remote VNC server
remote SSH server
8867 or 9013
8866 or 9012
8867 or 9013
system broadcast to TAS+TSM

GPS broadcast to TSS+TSM
system broadcast from TAS
4.8.3 Local/LAN firewall rules

Please ensure that TSS and TAS communication via TCP and UDP is possible for local, LAN and
internet targets. It is recommended to enable the port range from 8860..8869 or 9010..9019
(depending on your configuration) for both incoming and outgoing traffic, both TCP and UDP for all
zones.
In addition firewall rules for RDP, VNC, SSH are required (if used).
TSS 0.0.14.0 07.Nov.2011
29
4.8.4 Internet/WAN firewall rules

For communication with TAC, the required TAS UDP port has to be unblocked for receive and send
operations.
For communication between TAS and TMS, the required port range (default: 8700..8799 for TMS
protocol version 1) or just the control port (default: 8798 for TMS protocol version 2) has to be
unblocked for outgoing TCP connections. =0.0.25=
4.9 TSS internals

This chapter describes important internal facts of TSS.
4.9.1 TSS error processing

The error processing in TSS can be separated into error detection and error handling. =0.0.12=
Error detection
Error detection in TSS is based on several mechanisms. These are executed by the scheduler or the
scheduler's job execution unit.
Error counters for individual tasks
The execution status and time stamps are stored by TSS for every executed task. In addition error
counters are increased if task execution failed or reset to zero after successful execution. If the
number of consecutive errors exceeds the allowed maximum for a given task, a reboot is required.
Error counters for job loading
The loading result for a job is stored by TSS for every executed job. Error counters are increased
if a job cannot be loaded or reset to zero after successful execution. If the number of consecutive
errors exceeds the allowed maximum (5), a reboot is required.
Job execution time stamps
If no jobs can be executed for a given time (6 hours), a fallback job is executed. The fallback job
contains tasks for reporting, log upload, synchronization and license checkout.
Well known job executions
If no tasks for important task types (reporting, upload, synchronization, license checkout) are
executed for a given time, a fallback job is executed.
TSS Assistance Service status
If the TSS Assistance Service reports problems after a given number of task executions (typ. 3), a
reboot is required.
Error handling
TSS error handling is based on the execution of fallback jobs and the reboot mechanism.
Fallback jobs
A fallback job is executed if no jobs or important tasks can be executed for a given time. The
fallback job is defined internally and tries to use default RAS or CIC devices to connect to the
internet and execute reporting, log upload, synchronization and license checkout tasks.
Reboot mechanism
The reboot mechanism tries to reset all used mobiles (with an AT command or an MPSW power
cycle) and to restart the machine (with a hard or soft reboot). This mechanism is described in
more detail in the next chapter.
4.9.2 TSS reboot logic

TSS uses different methods to reset modems and the computer if a reboot is required. Please note
that all of these methods are executed, i.e. if a reboot is required, the modems are reset, an MPSW
cycle is executed and then the machine is rebooted. =0.0.12=
Modem reset
If a reboot is required, TSS tries to reset all used mobiles with an AT+CFUN command. This method
requires that the COM port was learned during job execution and that the mobile still responds to AT
commands.
TSS 0.0.14.0 07.Nov.2011
30
MPSW power cycle

If a modem power switch is attached and working properly, a modem power cycle is done before the
soft or hard reboot is executed. This method guarantees that the modem is reset which is not the
case for the AT command.
Reboot
TSS can execute soft or hard reboots depending on the watchdog configuration. Different reboot
modes are available in TSS, the default reboot mode is auto. Other reboot modes can be used in TSS
tasks or requested by external tools with the ===REBOOT message.
Windows reboot =0.0.13.0=
o TSS always executes a Windows restart, no modem power cycle is executed
Soft reboot
o TSS always executes a soft reboot (i.e. a Windows restart)
If a modem power switch is available, the modem is turned off and back on before rebooting.
Safe reboot
o If a watchdog is available and supports a safe power down, a system power down is initiated.
The watchdog executes a hard power cycle after the watchdog timeout and restarts the
machine.
o Otherwise a soft reboot is executed.
Automatic reboot
machine.
o If a wachdog is available but does not support a safe power down, a series of soft reboots is
executed (defined in MaxSoftReboots). Then a hard reboot is executed by the watchdog while
the OS is running.
o Otherwise a soft reboot is executed
Hard reboot
machine.
o If a wachdog is available but does not support a safe power down, a hard reboot is executed
by the watchdog while the OS is running.
o Otherwise a soft reboot is executed.
4.9.3 Agent ID and scenario ID increment

QTS ticket items (i.e. measurements) are identified by three main identifiers:
agent ID
scenario ID
measurement time
The agent ID uniquely identifies the test unit (i.e. the computer) generating the ticket, the scenario ID
uniquely identifies the scenario that has been measured (i.e. the parameters for the measurement).
The agent ID is derived from the registration data and is bound to the machine ID to ensure it is
unique. Scenario IDs typically are defined in configuration and job files or in scripts or external
probing tools.
Typically all measurements should be assigned individual scenario IDs to ensure they can be
distinguished for analysis. An exception from this rule is that the QTS dashboard can distinguish
measurements with different task IDs.
To simplify configuration of special scenarios, TSS supports agent ID increments and scenario ID
increments. If configured, the agent IDs and scenario IDs of all tickets generated by a job execution
can be incremented by pre-defined values. Please note that the transformation only applies to the
following QTS tickets =0.0.13.2=
TSS execution tickets
RAS/CIC tickets
Measurement tickets (PocketOptimizer, WebSpeedTest and external tools)
MPSW tickets
System tickets (that are generated by the scheduler, not the execution unit) are not affected.
Increments can be defined in three different locations:
TSS 0.0.14.0 07.Nov.2011
31
as attributes in the scheduler xml file (inc-agentid and inc-scenarioid)

as job parameters (Inc-AgentId and Inc-ScenarioId)
as task parameters (Inc-AgentId and Inc-ScenarioId)
Additional loop increments can be specified that are added in every loop iteration. The effective
increment is (please note that loop counters start with 0):
agent_inc =
<scheduler>.<job>.inc_agentid +
[job].Inc-AgentId + [job].Inc-AgentId-Loop * <job-loop> +
[task].Inc-AgentId + [task].Inc-AgentId-Loop * <task-loop>
scenario_inc =
<scheduler>.<job>.inc_scenarioid +
[job].Inc-ScenarioId + [job].Inc-ScenarioId-Loop * <job-loop> +
[task].Inc-ScenarioId + [task].Inc-ScenarioId-Loop * <task-loop>
4.10 Specific operational tasks

This chapter describes some specific operational tasks for TSS.
4.10.1 XML Reports/QTS

TSS is tightly integrated with the Quality Ticket System (QTS). XML reporting is separated in two
different phases in TSS:
XML reports are created by different sources and stored in the outbox directory for later
submission.
XML reports are submitted to the Ticket Receiver when a Report task is executed.
Different sources of XML reports can be distinguished:
TSS CIC/RAS tasks
The tasks CIC-Connect and CIC-Hangup (or RAS-Connect and RAS-Hangup, respectively) and
create an XML report if a scenario ID is specified.
Execution of external tools
External tools (such as PocketOptimizer and WebSpeedTest) automatically produce XML reports
containing the measurement results. Custom tools (e.g. Perl scripts) can create XML reports as
well. The reports provided by the external tools are automatically extended with some TSS and
CIC/RAS specific metrics.
TSS operational functions
Several XML reports can be created by TSS if configured. The report types are:
o Job execution: A report is generated for every executed scheduler item or job sequence.
o Startup: A report is created when the scheduler is started.
o Reboot: A report is created before a reboot is done.
o Status: A periodic status report is generated, e.g. once per day.
4.10.2 File synchronization

Synchronization is executed in a five phase process when FileSync tasks are executed:
As a first step, the file %URL%\synchronization.cfg is fetched from the synchronization server. A
record with the agent ID or the ID '*' is searched. If no record is found, the synchronization is
skipped.
If a record is found, the index files for the synchronization group are loaded. The files have to be
located in %URL%\<group>\files.cfg on the server. Index files contain file information including
length and checksum for all files in the group. The files can be created with the TSS Index Utility.
The group files are merged to create one effective index file for the machine. Please note that files
in successive groups override the same files in previous groups.
All files referenced by the effective index file are loaded into a local repository in
%system\data\sync\files% if not already up to date.
If all files in the repository are equal to the content of the effective index file (including file size
and checksum), the files are installed from %system\data\sync\files% to %system%. If required,
TSS.exe or the entire machine restarted.
Note: synchronization is skipped if the Agent is not registered (i.e. does not have a valid agent ID in
TSS 0.0.12.6 and above. =0.0.12.6=
Note: synchronization to the default ID '*' can be prevented when setting the configuration parameter
Sync-AllowDefault to false in TSS 0.0.12.8 and above. =0.0.12.8=
TSS 0.0.14.0 07.Nov.2011
32
4.10.2.1 Creating synchronization groups

Depending on your requirements, several synchronization can be created, e.g.
apps-default
platform-default
jobs-default
4.10.2.2 Preparing files for synchronization

It is recommended to create a local file structure in a local directory that will match the file structure
on the synchronization server, for example
apps-default\tss.exe
apps-default\apps\PO\PO.exe
platform-default\platform.cfg
jobs-default\jobs\PO\default.PO-job
jobs-default\jobs\default.TSS-job
jobs-default\scheduler\scheduler.xml
4.10.2.3 Creating the index files

Use the TSS Index Tool to create the index files.
Different methods are possible to create the file:

Launch the index tool manually and select the target folder (e.g. apps-default), use the button
Process and Save to save the index file.
Drag the folder onto a shortcut to the TSS Index Tool. It might be advantageous to place a
shortcut to the index tool in the folder containing apps-default etc.
Create a batch file and pass the path together with the argument /run to the index utility.
The index files for the previous example are:
apps-default\files.cfg
platform-default\files.cfg
jobs-default\cfg
4.10.2.4 Creating the synchronization configuration file

Create a synchronization.cfg file in the directory containing the synchronization group folders.
The content of the synchronization.cfg should be similar to
* apps-default platform-default jobs-default
21 apps-default platform-default jobs-default
4.10.2.5 Uploading the files to the server

Load the file from the local directory structure to the server. The content of the server should be
%url%\apps-default\tss.exe
%url%\apps-default\apps\PO\PO.exe
%url%\apps-default\files.cfg
%url%\platform-default\platform.cfg
%url%\platform-default\files.cfg
%url%\jobs-default\jobs\PO\default.PO-job
%url%\jobs-default\jobs\default.TSS-job
TSS 0.0.14.0 07.Nov.2011
33
%url%\jobs-default\scheduler\scheduler.xml
%url%\jobs-default\files.cfg
%url%\synchronization.cfg
4.10.3 Log file upload

Log and data files can automatically be uploaded to an FTP server if required. Submission is done in
two steps:
Files are placed in one of the outbox directories (logs or data).
o The main execution log file is automatically placed in the outbox directory after the job
execution has finished.
o Task's log files are placed in the outbox directory if the file's log level is below or equal to the
task's transmission log level (as defined by Max-Submitlevel). The file's log level is
automatically determined for PocketOptimizer and WebSpeedTest log files and can be
returned by other tools in the index file.
o Third party tools can directly place log or data files in the outbox folder.
o The Clean task can move compressed files or data files to the outbox folder if required.
Files are uploaded to the log file server if a SubmitLogs task is executed.
The preferred configuration is to create a different upload directory for every agent, each directory
then contains the two directories logs and data.
If, for example, the URL ftp://some.host.org/upload/TSS/%agent% is used, the directories on the
server should be (for the agents 101 and 102)
ftp://some.host.org/upload/TSS/101/logs
ftp://some.host.org/upload/TSS/101/data
ftp://some.host.org/upload/TSS/102/logs
ftp://some.host.org/upload/TSS/102/data
4.10.4 Time synchronization

TSS provides the integrated method to synchronize the local clock with a remote server. Time
synchronization is done with the task TimeSync that provides different operation modes:
External synchronization tools
Integrated HTTP get-time synchronization
4.10.4.1 External synchronization tools
External SNTP synchronization tools can be used by TSS. To use this method, the task or
configuration parameter TimeSync-Method has to be undefined or "exec".
Two different synchronization tools are currently supported:
ntpdate (http://www.ece.udel.edu/~mills/ntp/html/ntpdate.html, freeware)
Small SNTP Agent from Alsedi (http://alsedi.com/small_sntp_agent.php, freeware)
The application file name can be given in the task parameter AppFileName or the configuration
parameter SNTP-Tool. TSS will choose the proper operation method depending on the file name.
ntpdate
This command line utility requires the NTP server as a command line argument. It can be specified in
the configuration parameter [Communication]. NTP-Server.
Small SNTP Agent
This GUI utility requires the configuration file servers.txt to contain a list of time servers.
4.10.4.2 HTTP get-time synchronization
This method sends an HTTP GET request to a specified server (e.g. http://www.i-qos.com:8808/gettime). The server responds with an XML file containing the local time. The QTS Ticket Receiver or
Relay supports this method, similar to the public IP address service.
Sample request
GET /get-ipaddr HTTP/1.0
Sample response
<?xml version="1.0" encoding="ISO-8859-1" standalone="yes" ?>
<systime>2010-06-01T01:02:03.456+02:00</systime>
TSS 0.0.14.0 07.Nov.2011
34
The task or configuration parameter TimeSync-Method has to be set to "http-gettime" for this
method. The URL has to be configured in the task or configuration parameter GetTime-Server.
Note: time adjustments are only done if the deviation is larger then 200ms to avoid frequent time
changes.
4.10.5 Public IP address

The task GetPublicIP can be used to determine a public IP address. The task does not modify the
routing table, thus it should be executed when no custom internet connection is active. It is
automatically skipped if no active interface is available.
The server can be configured in the task or configuration parameter PublicIP-Server. The QTS Ticket
Receiver or Relay supports this method.
Sample request
GET /get-ipaddr
Sample response
<?xml version="1.0" encoding="ISO-8859-1" standalone="yes" ?>
<ipaddr>192.168.1.123:1231</ipaddr>
4.10.6 Packet sniffers

TSS 0.0.13.6 and above supports execution of a packet sniffer, either for a CIC connection or
controlled by new tasks Sniffer-Start and Sniffer-Stop. =0.0.13.6=
The available packet sniffers and the capabilities are listed in the following table:
Packet Sniffer
NetCap (Microsoft XP support tools)
NMCap (Microsoft Network Monitor 3.4)
TShark (Wireshark)
Windows XP
RAS + HwNd + LAN
RAS + NwNd + LAN
RAS + HwNd + LAN
Windows 7
LAN only
RAS + NwNd + LAN
LAN only
Shrink
No
Yes
Yes
Please note that Microsoft NMCap provides best compatibility and functionality, but has to be installed
as separate package (available for 32 and 64 bit). NetCap does not support shrinking (i.e. frame size
limitation), but WireShark's EditCap.exe can be used to shrink capture files created by Netcap.
The packet sniffer can be configured either in the machine configuration file or inline in the CIC or
Sniffer task, a sample content for machine.cfg is shown below:
[Sniffer]
Sniffer-Type:
Sniffer-Tool:
Sniffer-Args:
Shrink-Type:
Shrink-Tool:
Shrink-Args:
Sniffer-Enabled:
Sniffer-TruncBytes:
Sniffer-MaxErrors:
NetCap
; sniffer type (NetCap, NMCap or TShark)
D:\Tools\SupportToolsXp\netcap.exe
; additional command line arguments
TShark
; shrinking tool (TShark only)
D:\Tools\Wireshark\editcap.exe
true
; enable use of sniffer (has to be true)
86
; truncate frame length to shrink files
5
; max. errors until reboot (def: 10)
With this configuration, a packet sniffer can be associated with a CIC task as follows:
[Task]
Type:
CIC-ConnId:
CIC-User:
CIC-Password:
CIC-APN:
Monitored:
Scenario-Id:
OnError:
UsePacketSniffer:
Sniffer-Compress:
CIC-Connect
%User-CIC-Entry%
%User-CIC-User%
%User-CIC-Password%
%User-CIC-APN%
true
1001
Continue
true
; use packet sniffer defined in [Sniffer] section
true
; compress .cap or .scap file with 7-zip
[Task]
...
[Task]
Type:
CIC-ConnId:
Scenario-Id:
CIC-Hangup
%User-CIC-Entry%
1002
Please note that the packet sniffer is automatically stopped in the CIC-Hangup task (unless explicitly
disabled) or at the end of the job execution. Temporary sniffer files are placed in directory
data\work\sniffer, the output file (shrinked or zipped) is moved to data\work\data.
TSS 0.0.14.0 07.Nov.2011
35
Different modes are

Sniffer-TruncMode:
None
ShrinkCap
ShrinkReplace
ShrinkAdd
available to shrink capture files during or after capturing, defined with parameter
do not truncate frames, full data is captured

truncate frames during capturing, only produce .scap files
capture full frames but truncate file after capturing and delete old .cap file
capture full frames and truncate file after capturing, keep .cap and .scap files
In addition, the smaller output file (either .cap or .scap) can be compressed with 7-zip. The resulting
output file (.7z, .scap or .cap) is moved to directory data\work\data and can be copied to the output
directory for data upload, too. Possible upload modes (defined with Sniffer-Submit) are:
Never
do not upload sniffer files
OnError
upload sniffer files in case of errors
OnWarning
upload sniffer files in case of errors or warnings
Always
always upload sniffer files
4.11 Installer customization

The installer can be customized if one or several directories named TSS-Custom or TSS-Custom<suffix> is created in the same directory as the setup executable.
Use the following directory structure to install your custom configuration and job files.
h:\TSS\TSS-W32-Setup-x.x.x.x.exe
h:\TSS\TSS-Custom\System.cfg
h:\TSS\TSS-Custom\Machine.cfg
h:\TSS\TSS-Custom\Assistance.cfg
h:\TSS\TSS-Custom\Jobs\Default.TSS-Job
h:\TSS\TSS-Custom\Jobs\Add\Manual-FileSync-NoRAS.TSS-job
h:\TSS\TSS-Custom\Jobs\PO\Default.PO-Job
If more than one directory is available, the setup utility provides a method to select the configuration
directory to be used.
4.12 Integrating external tools into TSS

TSS provides optimized tasks to execute PocketOptimizer, WebSpeedTest and the SNTP client. It is
however possible to integrate third party applications and scripts into TSS.
4.12.1 Types of external applications

External applications can be classified by the input and output they create. A rough categorization is:
Console applications
These applications are executed to apply settings or generate console output. A simple example is the
Windows trace route utility (tracert.exe). The output of the utility will be available in the redirected log
file, but no XML report is generated.
[Task]
ID:
Type:
Exec-Estimation:
NeedCIC:
Timeout:
AppFileName:
Arguments:
UseRedirect:
DontNeedReportFile:
OnError:
TraceRt
Execute
20s
true
; true ... skip task if no internet connection is active
30s
c:\windows\system32\TraceRt.exe
193.99.144.85
true
true
continue
Simple applications
Simple applications are assumed to create an XML ticket with result data. The name of the ticket is
given by TSS and can be accessed with the system defined variables %ReportPath%\%ReportFile%. Log
files should be written to %LogPath%\%Prefix%-<suffix>.log.
[Task]
ID:
Type:
Exec-Estimation:
NeedCIC:
Timeout:
AppFileName:
TSS 0.0.14.0 07.Nov.2011
DoSomething
Execute
10s
true
; true ... skip task if no internet connection is active
30s
%scripts%\perl\dosomething.pl
36
Arguments:
/arg1 /log=%logpath%\%prefix%\some.log
/report=%reportpath%\%ReportFile%
UseShellExec:
true
; note: we can use shellexec to execute a .pl file
OnError:
continue
Complex applications
More complex applications might need to analyze report and log files of previous tasks. These file
names can either be derived from the execution and task ID (available with %execid% and
%taskid%) or by parsing the index file (available with %TempPath%\%IndexFile% if UseHistoryFile is set
to true).
4.12.2 Launching external applications

External applications can be launched using different methods.
Specifying the executable directly
A simple approach is to specify the command line directly, e.g.
[Task]
Type:
AppFileName:
Arguments:
DontCheckAppFile:
UseRedirect:
Execute
~\cmd.exe
/c %scripts%\bat\test1.bat
true ; this is needed as cmd.exe is somewhere in the search path
true
Note: the tilde (~) advices TSS to avoid expanding the file name to the %apps% directory.
Using ArgumentRule
Instead of specifying all arguments directly, an argument rule can be used. This method uses the
parameters AppFileName, ScriptFileName and Arguments. The script file name and the arguments can
be used with the variables $script$ and $args$ in the argument rule as shown below:
[Task]
Type:
AppFileName:
ScriptFileName:
Arguments:
ArgumentRule:
UseRedirect:
Execute
~\perl.exe
%scripts%\perl\test2.pl
/log=%logpath%\%prefix%\some.log
$script$ $args$
true
Registering the application in Application.cfg

Applications registered in application.cfg can be accessed with the parameter Tool. Using this method
allows to define the location of the executable in the configuration file.
A sample definition in application.cfg could be:
[Application]
AppType:
ExeFile:
ArgumentRule:
Cmd
c:\windows\system32\cmd.exe
/c $script$ $args$
A batch file can then be started with:

[Task]
Type:
Tool:
ScriptFileName:
UseRedirect:
Execute
Cmd
%scripts%\batch\test1.bat
true
Using ShellExec
ShellExec allows launching tools with the windows Shell Execute method. This is similar to double
clicking on a file in Windows Explorer. The advantage is that data or script files can be launched
directly if they are associated with a tool, the disadvantage is that console redirection is not possible.
[Task]
Type:
ExeFile:
UseShellExecute:
Execute
%scripts%\perl\test2.pl
true
Note that Perl has to be installed in the system and associated with .pl files to use this method.
4.12.3 Special console messages

Tools can use special console messages to communicate with TSS.
===PROGRESS <progress> <status>
TSS 0.0.14.0 07.Nov.2011
37
===STATUS <status>
===LOG <text>
===ERROR <text>
===WARNING <text>
===REBOOT
The purpose of the messages is:

===PROGRESS: this message can be used to update the progress (0.0 .. 1.0) for the current task. A
status text for the progress display in the GUI can be added as well. This message can be useful
for long tasks that shall be executed semi-unattended.
===STATUS: similar to the progress message, this message can be used to update the GUI status.
===LOG: Adds a log message with higher level to the TSS execution log.
===ERROR: This message indicates an error, similar to a non-zero exit code. An error message
(starting with an error code followed by a colon) can be added if required. The error message will
be added to the error/warning messages in the execution ticket. The task will be considered failed
after an error message and the quality indicator of the execution ticket will be set to a maximum
of 1.
===WARNING: This message indicates a warning. A warning message (starting with a warning code
followed by a colon) can be added if required. The warning message will be added to the
error/warning messages in the execution ticket. The task will not be considered failed, but the
quality indicator of the execution ticket will be set to a maximum of 5.
===REBOOT: This message indicates that the tool requires a reboot. A reboot mode can be given if
required in form ===REBOOT <mode> with mode=WIN/SOFT/HARD/SAFE/AUTO: =0.0.12=
o WIN TSS shall execute a soft reboot (i.e. an OS restart) without an MPSW cycle =0.0.13.0=
o SOFT ... TSS shall execute a soft reboot (i.e. an OS restart), with MPSW cycle if possible
o HARD ... TSS shall execute a hard reboot if an external watchdog is available, even if an
immediate power cycle without safe shutdown is required. If no watchdog is available, a soft
reboot will be executed.
o SAFE ... TSS shall execute a safe reboot. This is a hard reboot if an external watchdog
supporting safe shutdown is available, a soft reboot otherwise.
o AUTO ... TSS shall execute an automatic reboot. This is a hard reboot if an external watchdog
supporting safe shutdown is available, a series of soft reboots with final hard reboot if an
external watchdog without safe shutdown is available or just a soft reboot if no watchdog is
available.
The default mode is SOFT if not specified. Please note that a modem power cycle will be executed
for all modes if an MPSW is available. Please refer to section 4.9.1 for details on error handling
and reboot modes.
4.12.4 Log/detail levels

Different log levels can be used by third party tools if required. The pre-defined log levels are:
0 report files (immediately copy to outbox)
1 master log files
2 additional log files
3 detail log files
4 important data files
5 additional data files
Log levels can be used to control which files are to be copied to the outbox folder. The maximum
outbox log level is defined with the task parameter Max-SubmitLevel.
4.12.5 History files

TSS internally keeps track of the files created during task execution. A tool can receive this
information if the task parameter UseHistoryFile is set to true.
The format of the history file is:
task
file
task
file
file
j.t03
report 0 20090330-135815-00-01.Demo-Std01-WithDSL.03-RASDial-report.xml
j.t04
report 0 20090330-135815-00-01.MKA-Std01-WithDSL.04-PocketOptimizer-report.xml
log
1 20090330-135815-00-01.MKA-Std01-WithDSL.04-PocketOptimizer.0000-job.log
A third party tool can parse the file line by line to search for the required task. The next lines then
contain the task's output including one report entry and log files if available. The file name for the
TSS 0.0.14.0 07.Nov.2011
38
index
file
is
given
by
TSS
and
can
be
accessed
with
the
system
defined
variables
%TempPath%\%HistoryFile%.
4.12.6 Index files

An external tool shall always create log files starting with the prefix given by TSS. The prefix follows
the scheme yyyymmdd-hhnnss-zzzz to ensure the log files are named uniquely and can be associated
with the executed job. You can access the prefix with the system defined variables %LogPrefix% and
the index file name with the system defined variables %TempPath%\%IndexFile%.
Output files following the current naming scheme are automatically recognized by TSS and assigned
the log level 0 for reports (in directory work\reports), 1 for log files (in directory work\logs) and 5 for
data files (in directory work\data). If other log levels are required, an index file has to be created by
the tool.
The format of the index file has to be:
<type> <level> <filename>
Allowed types are Report, Log and Data. Allowed levels are 0..9.
4.13 Common problems

This chapter describes some common tasks.
4.13.1 Interface management

Interface management is an important task for measurement systems with more than one active
interface supporting TCP/IP.
The task of interface management is to effectively disable the existing interfaces (e.g. LAN/DSL)
before activating the measurement interface (e.g. RAS). Please note that the interface usually shall
not be 100% deactivated, as it shall stay available for management via RDP.
The effort of interface management may vary, typical tasks are:
The interface shall not be used for measurements, even if the CIC or RAS connection is dropped
(and thus the connection's default gateway is removed). To achieve this, the existing connection's
default gateway shall be removed during the measurement.
The LAN interface might be assigned a lower metric than the RAS interface (e.g. for GBit LAN),
thus the traffic would be routed to the LAN interface.
If DNS response times are measured, the DNS servers have to be removed as well to avoid DNS
packets to be sent and received on the LAN interface. If the servers are on a remote network.
TSS provides the Task IPConfig to perform the interface management.
The two most important operation modes of this task are disable and enable. Please note that
interface is only effectively disabled by this task.
The operation mode disable performs the following tasks:
o If the interface is DHCP configured, the DNS server addresses are set to 127.0.0.1 and the
default routes are removed (this is required as the DNS servers can't be removed for DHCP
active interfaces).
o If the interface is statically configured, the old settings are saved, then the DNS server
addresses and the default gateway IP address are removed.
The operation mode enable performs the following tasks:
o If the interface is DHCP configured, the DNS server addresses and default gateway are
restored to the DHCP provided values.
o If the interface is statically configured, the backup or fallback values are restored. Please refer
to the next section for detailed information on the fallback values.
Note: If the interface is statically configured, you should always configure fallback values for the
interface in machine.cfg. The reason is that the interface parameter changes are persistent and if the
machine is rebooted while the modified settings are in place, Windows will start with the modified
values and TSS will then use these settings as backup values. Thus you should always provide the
correct interface configuration in the configuration file, e.g.
[NetworkAdapter]
AdapterName:
TSS 0.0.14.0 07.Nov.2011
LAN-Verbindung
39
AdapterDefaultGw:
AdapterDNSServers:
192.168.23.1
192.168.23.10,192.168.23.1
4.13.2 Assistance Service

The TSS Assistance Service provides several additional functions:
A UDP response service is available.
A routing service controlled by UDP packets
A reboot service controlled by UDP packets.
It provides an additional watchdog for the TSS application and scheduler.
4.13.2.1 UDP Response functions
If a UDP response request is sent to the assistance service with the assistance client, the service
immediately answers with 4 UDP packets on all available interfaces. This function can be used to test
the connection.
Please note that it might be impossible for the service to return the UDP packets if the default route is
set to a different interface and no special route is set.
4.13.2.2 Routing functions
If a UDP routing request is sent to the assistance service with the assistance client, the service sets a
route for the originating IP address with mask 255.255.255.255 on the interface the packet was
received. Then it answers the UDP packet as for the response request.
Use this function to set a specific route for a remote machine. This function is important to allow
remote management via LAN/DSL while the default gateway is changed to a RAS connection.
4.13.2.3 Reboot functions
If a UDP reboot request is sent to the assistance service with the assistance client, the service
immediately reboots the machine. Please note that a password is required for this task.
4.13.2.4 Watchdog functions
The TSS Assistance Service and the TSS Scheduler communicate via system wide events as long as
the scheduler is running. If the scheduler stops responding, the TSS Assistance service reboots the
machine within 2 minutes. If the scheduler does not react after startup, the machine is rebooted after
10 minutes. Please don't forget to deactivate the TSS Assistance Service if using a TSS configured
machine interactively or for different tasks.
4.14 Hardware watchdogs and power switches

TSS supports hardware watchdogs and USB power switches. The interfacing with the external devices
is done by the TSS Assistance Service.
4.14.1 Hardware watchdogs (WD)

A hardware watchdog is an external device that is used to reset or power-cycle a computer in case of
problems. In TSS such a device can be used to power-cycle the PC and the attached data card if it is
not accessible or software reboots don't work.
If the watchdog is configured, it is automatically calmed by the TSS Assistance service. If the
watchdog is operational, every or every Nth reboot is executed as hard reboot instead of a soft reboot,
depending on the watchdog capabilities (with N = MaxSoftReboots + 1).
The exact behavior depends on the watchdog's capabilities: =0.0.12=
Watchdog with safe power down
If the watchdog supports safe power down, it is armed to a longer interval (typ. 3 minutes), then
a system shutdown is initiated, i.e. Windows is shut down safely. When the watchdog interval
expires, the watchdog power cycles the machine that shall auto power on when AC returns.
Watchdog without safe power down
In this case the system cannot be shut down safely because the watchdog would not work
without USB power. If a hard reboot is required, the watchdog is no longer calmed or a power
cycle is immediately forced. This will reboot the machine while the OS is running.
No watchdog
TSS 0.0.14.0 07.Nov.2011
40
Without a watchdog only soft reboots are executed.

If a watchdog supports safe power down, TSS will always execute hard reboots. If not, TSS will
schedule up to MaxSoftReboots soft reboots until a hard reboot is executed. This shall avoid excessive
hard reboots that have a risk of file system corruption.
Currently only one watchdog model is supported:
Cleware USB Watchdog XP (www.cleware.de)
To use the watchdog functions, the configuration section [Watchdog] in machine.cfg has to be
configured properly, please refer to 5.1.4 for details. Additional API files might be required, too.
4.14.1.1 Cleware USB Watchdog XP
Two different operating modes are available for the Cleware USB Watchdog XP with TSS:
standard mode (does not
ext power mode (supports safe power down)
Cleware USB Watchdog XP in standard mode
The USB Watchdog XP is inserted between the power outlet and the computer's AC input and
connected to one of the Computer's USB ports. This is the default configuration recommended by
Cleware. Unfortunately it is not possible to shut down the machine before doing the power cycle due
to the fact that the Cleware USB Watchdog XP is exclusively powered from the USB port.
If a hard reboot is required, the TSS Assistance Service stops calming the watchdog and initiates a
WD power cycle while windows is running. The watchdog then does a power cycle and reboots the
machine.
The watchdog section in machine.cfg for this case is:
[Watchdog]
Model:
Cleware
TSS 0.0.14.0 07.Nov.2011
41
Cleware USB Watchdog XP in ext power mode

The USB Watchdog XP and a 230V power splitter are inserted between the power outlet and the
computer's AC input. The watchdog is not directly connected to the PC but to an USB Hub. The USB
Hub is externally powered by an AC adapter connected to the watchdog's output. Please note that the
USB hub is only used to feed the external +5V power supply to the watchdog.
Please consider two important configuration details:

Watchdog power supply
The USB Watchdog XP requires a power supply even if the PC has been turned off. A simple diode
from a +5VDC power supply to the USB input's power pin would be sufficient but is difficult to
purchase. Thus an USB Hub with an external power supply is used to achieve the same effect.
Insert an USB hub between PC and watchdog. The HUB has to be powered by an external power
supply.
Watchdog power supply shutdown
The watchdog requires that the USB power is shut down when the output is powered down, otherwise
the output will not be turned on any more.
It is important that the USB Hub's power supply is connected to the output of the watchdog, i.e.
it has to be switched by the watchdog.
This configuration is supported by TSS 0.0.11.7 and above. Please specify the feature
SupportPowerDown = true in the machine configuration file.
[Watchdog]
Model:
Functions:
Cleware
SupportPowerDown=true
Watchdog configuration
To use the Cleware watchdog functions, two steps are required:
The API (Usbaccess.dll) has to be installed.
The [Watchdog] section in machine.cfg has to be configured.
To allow TSS to interface with the Cleware USB Watchdog XP, the interface dll Usbaccess.dll has to be
copied to the TSS binary directory. The file can be found on the Cleware driver CD.
To configure TSS to interface with the watchdog, the [Watchdog] section has to be configured. Set
the parameter Model to Cleware and the parameter Functions to SupportPowerDown=true if external
power was applied as described.
4.14.2 Modem power switches (MPSW)

Modem power switches are hardware devices that can switch the USB power for bus-powered devices
such as USB data cards.
TSS 0.0.14.0 07.Nov.2011
42
Currently two modem power switch models are supported:

Serial USB power switch
Cleware USB cutter
To use the USB power switch, the configuration section [ModemSwitch] in machine.cfg has to be
configured properly, please refer to 5.1.4 for details. Additional API files might be required, too.
If the power switch is configured, it is automatically used by the TSS Assistance service. A LED on the
power switch is toggled by the service and indicates operation. If a reboot is executed, the power
switch is automatically switched off for 10 seconds, the system reboot is executed after this power
cycle.
4.14.2.1 Serial USB power switch
A serial USB power switch uses a serial port's DTR and RTS pins to turn the +5V for external USB
devices on and off. The default configuration uses DTR for the switch and RTS for an activity
indicator. The machine configuration file is =0.0.12=
[ModemSwitch]
Model:
Port:
Functions:
Serial
\\.\COM31:9600,n,8,1
Reset=DTR,Status=RTS
; serial/cleware
; COM port and parameters
; Reset=[!]DTR/RTS,Status=[!]DTR/RTS
4.14.2.2 Cleware USB cutter

The Cleware USB cutter uses two relays to switch both supply voltage and data lines with a small
delay as required by the USB standard. The device uses the same API as the Cleware USB Watchdog
XP. =0.0.12=
The watchdog section in machine.cfg for this case is:
[ModemSwitch]
Model:
Cleware
; serial/cleware
In addition, the API file Usbaccess.dll has to be copied to the TSS binary directory. The file can be
found on the Cleware driver CD, please note that at least version 4.0.3 is required for the USB cutter.
4.14.3 GPS receivers

Serial and USB GPS receivers providing data in NMEA format are supported by TSS. Please note that
USB GPS receivers have to provide a virtual COM port. No special startup command is supported, the
receiver has to start sending data without user intervention.
Only the serial NMEA data stream is used by TSS, thus a single 3-pin connection with GND, RXD and
VCC is sufficient. =0.0.12.5=
The GPS receiver's data stream can either be handled by TAS or by TSS.
4.14.3.1 GPS receiver handled by the TSS Assistance Service
In this case the COM port is handled by TAS, the NMEA data is broadcasted within the local machine
or via LAN to other machines. The GPS section in machine config is:
[GPS]
Model:
Port:
Owner:
Broadcast-Port:
Serial
\\.\COM32:4800,n,8,1
TAS
8866
;
;
;
;
serial
COM port and parameters
Owner: TAS or TSS, default: TAS
8866/9012: UDP broadcast port
4.14.3.2 GPS receiver handled by TSS

In this case the COM port is handled by TSS, data can be used within TSS only. The GPS section in
machine config is:
TSS 0.0.14.0 07.Nov.2011
43
[GPS]
Model:
Port:
Owner:
Serial
\\.\COM32:4800,n,8,1
TSS
; serial
; Owner: TAS or TSS, default: TAS
4.14.4 Power monitor devices

A power monitor device is an external hardware device that signals a shutdown request to the TSS
Assistance Service. A power monitor is not required in stationary test cases but can be required in
drive testing when the computer has no dedicated power switch input (e.g. the ARK-1380 platform).
=0.0.12.5=
The following schematic shows a reference implementation of a combined GPS distribution and power
monitor device. Please note that several conditions are required that may not always be met. The
implementation has the advantage that it can be built small enough to be contained in an RS232
connector's case but has drawbacks regarding standard conformity and voltage levels.
The device has a serial GPS input that is distributed to several PC serial inputs. Please note that this is
not contained in the RS232 specification, it has to be checked if the GPS receiver's output is able to
drive more than one serial input.
In addition the device provides a shutdown signal to the PC DCD inputs, the power supply is drawn
from the PC DTR outputs that are set to high by the software. Please note that this is not contained in
the specification but works in most cases. The LEDs have to be high efficiency devices to operate with
low currents down to 0.5mA.
Please note that the threshold voltage for the given implementation will be approximately VCC - 1.75V
with VCC of 5..12V depending on the used serial ports. The used IGN signal has to be at least VCC 1.0V for proper operation.
The PowerMonitor section for the previous device in machine.cfg is
[PowerMonitor]
Model:
Port:
Functions:
ShutDownDelay:
Serial
; serial
GPS
; COM port and parameters (GPS to share)
PowerDown=DCD,Status=RTS,Const=DTR
10s
TSS 0.0.14.0 07.Nov.2011
44
Chapter
Technical Reference
5.1 Configuration file reference
The configuration of TSS is contained in several configuration files residing in the TSS system
directory.
5.1.1 Overview of configuration files

The following configuration files are required or recognized by TSS:
machine.cfg
contains configuration parameters for a single machine
application.cfg
contains configuration parameters for installed tools
platform.cfg
contains configuration parameters for work and archive directories
system.cfg
contains system and communication parameters
mobiles.cfg
contains AT commands for different mobile devices
mapping.cfg
contains mapping information for metrics (referenced by system.cfg)
assistance.cfg
contains configuration for the background service
The reason to split the configuration files into several files is to allow flexible synchronization for
different parts of the configuration. For example machine.cfg and application.cfg will not be
synchronized at all in most cases while platform.cfg, system.cfg, mobiles.cfg and mapping.cfg will
probably be the same file for all test units.
5.1.2 Allowed sections in configuration files

The following sections are allowed in the configuration files:
machine.cfg
[Machine]
[Scheduler]
[NetworkServices]
[Sniffer]
[NetworkAdapter]
[Directories]
[Watchdog]
[Modemswitch]
[GPS]
[PowerMonitor]
[User]
application.cfg
[Application]
[Methods]
[Tools]
[User]
platform.cfg
[Quota]
[Diskfree]
[Tempfiles]
[Tempfiles/*]
[User]
system.cfg
[Scheduler]
[Communication]
[Tickets]
TSS 0.0.14.0 07.Nov.2011
only once
only once (merged)
only once
=0.0.13.0=
only once
=0.0.13.6=
multiple
only once
only once
only once
only once
=0.0.12.3=
only once
=0.0.12.3=
only once (merged)
multiple
only once
only once
only once (merged)
only
only
only
only
only
once
once
=0.0.12=
once
once per directory
once (merged)
only once (merged)

only once
only once
=0.0.12.3=
45
Technical Reference
[Scenarios]
[User]
mobiles.cfg
[MobileDevice]
[MobilePorts]
mapping.cfg
[default]
[TSS.*]
assistance.cfg
[Network]
[Management]
[Routing]
[Directories]
[Log]
[Installer]
only once
only once (merged)
multiple
multiple
=0.0.13.5=
only once
only once per measurement format
5.1.3 Processing order for configuration files

Most sections are only valid in one configuration file. For the sections [User] and [Scheduler] the files
are processed in the same order as shown in the previous section, i.e. if the same parameter is
defined in the machine configuration file, it overrides values in the application configuration file (and
the other files).
5.1.4 Machine configuration file

The machine configuration file contains parameters that are likely to be different for every machine.
5.1.4.1 Sample machine configuration file
;
;
;
;
TSS Machine configuration file

-----------------------------v0.0.13.10, 17.06.2011
Copyright (c) 2009-2011 by Ingo Zettl, ingo.zettl@aon.at
[Machine]
;Machine-Name:
;Sync-Enable:
;Sync-AllowDefault:
;Sync-Groups:
;Submit-Enable:
;Report-Enable:
;Fallback-Enable:
;ManageServer-Enable:
;ModemReset-Enable:
;ModemReset-Ports:
;HwNd-Enable:
;InterceptShutdown:
;EwfTimeZoneFix:
Bot01
yes
yes
global group1
yes
yes
yes
yes
yes
;
;
;
;
;
;
;
;
;
;
;
;
;
yes
no
yes
override Windows machine name if req.

yes/no/manual/forced (def: yes)
allow synchronization to def. item (*)
override synchronization groups
enable log/data file submission
enable QTS ticket upload
enable execution of fallback jobs
enable management over RAS connections
enable reset of mobiles before reboot
custom list of COM ports (comma sep.)
enable use of Huawei NDIS API
execute shutdown job before shutdown
do auto-commit after time zone changes
[Scheduler]
; Note: every agent can be assigned a random or fixed agent shift to spread server loads
;Agent-Shift-Fixed:
9s
; use fixed agent shift as specified
;Agent-Shift-Max:
10m
; use random shift derived from agent ID
;Agent-Shift-Inc:
30s
; increment (or rounding value) for shifts
;MaxAssistErrors:
3
; max. TAS errors until a reboot (def: 3)
;MaxSoftReboots:
1
; max. soft reboots before a hard reboot
;MinAssistRebootWait:
1d
; min. time between reboots due to TAS
;CheckAssistanceSvc:
true
; set to false if TAS shall not be checked
;WatchAssistanceSvc:
true
; communicate with TAS in bkground thread
;InitialMPSWDelay:
40s
; delay job after initial MPSW cycle
;TerminateJobTimeout:
15s
; timeout before starting shutdown job
;ShutdownJobTimeout:
60s
; timeout for shutdown job
;MaxCpuOverloads:
2
; reboot after N tasks > 100% sng CPU load
;DisableDelayedStart:
false
; disable automatic start after 30 min
[NetworkServices]
;EnableStatusServer:
;StatusTCPPort:
;StoreTime:
;EnableUdpBroadcast:
;UdpBroadcastPort:
;UdpReceiveTickets:
;UdpBroadcastTickets:
[Sniffer]
Sniffer-Type:
TSS 0.0.14.0 07.Nov.2011
true
8869
3d
true
8869
true
true
;
;
;
;
;
;
;
NetCap
enable status server for TSM

TCP port for status server (8869/9016)
ticket storage time for server (3d)
enable UDP bcast/reception (def:off)
UDP port for ticket bcasts (8869/9016)
receive broadcasted tickets (def:on)
bcast tickets if subm. fails (def:on)
; sniffer type (NetCap, NMCap or TShark)
46
Technical Reference
Sniffer-Tool:
Sniffer-Args:
Shrink-Type:
Shrink-Tool:
Shrink-Args:
Sniffer-Enabled:
;Sniffer-TruncBytes:
;Sniffer-TruncMode:
;Sniffer-BufferSize:
;Sniffer-Compress:
;Sniffer-Submit:
;Sniffer-MaxErrors:
;Sniffer-AddLog:
D:\Tools\SupportToolsXp\netcap.exe
TShark
; shrinking tool (TShark only)
D:\Tools\Wireshark\editcap.exe
true
; enable use of sniffer (has to be true)
86
; truncate frame length to shrink files
ShrinkCap
; None/ShrinkCap/ShrinkReplace/ShrinkAdd
100
; buffer size for packet sniffer in MB
true
; compress capture files with 7-zip
Never
; Never/OnError/OnWarning/Always
5
; max. errors until reboot (def: 10)
true
; add sniffer's output to exec log
[Watchdog]
; use these parameters to define an external watchdog to be used by TSS/TAS
; supported watchdog models:
; - cleware ... Cleware USB-Watchdog XP (requires USBAccess.dll)
;Model:
Cleware
; cleware
;Functions:
SupportPowerDown=true
; SupportPowerDown=true
[ModemSwitch]
; use these parameters to define an external power switch to be used by TSS/TAS
; supported USB Switch models:
; - serial ... COM/FTDI based power switch
; - cleware ... Cleware USB cutter (requires USBAccess.dll)
; Serial MPSW switch
;Model:
;Port:
;Functions:
Serial
\\.\COM31:9600,n,8,1
Reset=DTR,Status=RTS
; Cleware USB cutter (requires USBAccess.dll)

;Model:
Cleware
; MPSW Model (serial)

; Reset=[!]DTR/RTS,Status=[!]DTR/RTS
; MPSW Model (cleware)
[GPS]
; use these parameters to define a serial/USB GPS receiver
; supported GPS models:
; - serial ... COM based GPS receiver (includes USB with virtual COM port)
;Model:
Serial
; GPS Model (serial only)
;Port:
\\.\COM99:4800,n,8,1
;Owner:
TAS
; Owner: TAS or TSS, default: TAS
;Broadcast-Port:
8866
; 8866/9012: UDP broadcast port
;Broadcast-Port-TXL:
; override for TX local port (from)
;Broadcast-Port-TXT:
; override for TX remote port (to)
;Broadcast-Port-RXL:
; override for RX local port (to)
;Broadcast-Port-RXF:
; override for RX remote port (from)
;Log-TAS:
basic
; GPS log level (off/basic/full)
[PowerMonitor]
; use these parameters to define a power monitor device
; supported power monitor models:
; - serial ... COM based power monitor (includes USB with virtual COM port)
;Model:
Serial
; PM Model (serial only)
;Port:
\\.\COM30:4800,n,8,1
; COM port and parameters (or GPS)
;Functions:
; PowerDown=[!]DCD/DSR/CTS/RI,Status=[!]DTR/RTS,Const=[!]DTR/RTS
;ShutdownDelay:
10s
; delay until shutdown is requested
[NetworkAdapter]
; Note: if adapters have static IP configuration, these parameters are required to restore
; the adapter settings in case of an error
;AdapterName:
LAN-Connection
; name of NIC connection
;AdapterDefaultGw:
192.168.1.1
; default GW in case of static IP config
;AdapterDNSServers:
195.127.23.17
; default DNS servers for static IP config
[Directories]
System:
Data:
C:\TSS-System
C:\TSS-Data
; application and configuration files

; data files
[User]
; Note: this section contains user defined parameters that can be used in jobs and tasks.
; connection variables for RAS tasks in sample jobs
Default-RAS-Entry:
MBB
;Default-RAS-Entry:
Default-RAS-User:
Default-RAS-Password:
Default-RAS-APN:
TSS 0.0.14.0 07.Nov.2011
47
Technical Reference
; connection variables for CIC tasks in sample jobs

Default-CIC-ConnID:
RAS:MBB
;Default-CIC-ConnID:
Default-CIC-User:
%rands(std,8)%@a1plus.at
ppp
Default-CIC-APN:
a1.net
; additional variables for tests
;Default-LAN-Name:
LAN-Connection
5.1.4.2 Allowed sections in the machine configuration file

The system configuration file may contain the following sections:
machine.cfg
[Machine]
[Scheduler]
[NetworkServices]
[Sniffer]
[NetworkAdapter]
[Directories]
[Watchdog]
[Modemswitch]
[GPS]
[PowerMonitor]
[User]
only once
only once (merged)
only once
=0.0.13.0=
only once
=0.0.13.6=
multiple
only once
only once
only once
only once
=0.0.12.3=
only once
=0.0.12.3=
only once (merged)
5.1.4.3 Detailed parameter description for the machine configuration file

Section [Machine]
The machine configuration file may include one section Machine.
Known parameters in machine.cfg configuration section [Machine]
Machine-Name:
<name>
(string, optional)
This parameter can be used to specify a different agent name than the Windows machine name. The
agent name will be reported in the XML reports and in some log files.
Sync-Enable:
(yes/no/manual/forced)
(bool, default: yes)
This parameter can be used to disable synchronization for an individual machine or to restrict
synchronization to manual execution or special tasks. Possible values are:
o yes Synchronization is always enabled.
o manual Synchronization is only enabled if a job is executed manually. If a job is executed
by the scheduler, FileSync tasks will be skipped.
o forced Synchronization is only enabled if a job is executed manually and the task parameter
Sync-Forced is set to true. Otherwise FileSync tasks will be skipped.
o no Synchronization is disabled, FileSync tasks are skipped.
The parameter should be used with care and only be set for test machines or machines with special
configurations. =0.0.13.1=
Sync-AllowDefault:
(True/False/Yes/No)
(bool, default: true)
This parameter can be used to disable synchronization to the default item (*) for an individual
machine. This can be useful for devices that shall not be synchronized to the default configuration.
=0.0.12.8=
Sync-Groups:
(group,group,..)
(string, optional)
This parameter can be used to specify other synchronization groups than defined in the
synchronization server's synchronization.cfg. The parameter should only be used for test machines
as the group assignment cannot be changed on the server if the parameter is set.
Submit-Enable:
(True/False/Yes/No)
This parameter can be used to disable log and data file submission for an individual machine. In this
case SubmitLogs tasks will be skipped and log or data files are not moved to the outbox folder.
Please note that this parameter overrides the parameter Log-Enable in the system configuration file.
Report-Enable:
(True/False/Yes/No)
This parameter can be used to disable QTS ticket upload for an individual machine. If set to false,
Report tasks will be skipped. =0.0.13.8=
Fallback-Enable:
(True/False/Yes/No)
This parameter can be used to disable fallback handling for special cases. Fallback handling
automatically executes special tasks (reporting, synchronization, file submission) if these are not
executed for a longer time period. While this behavior will be suitable for most situations as it avoids
TSS 0.0.14.0 07.Nov.2011
48
Technical Reference
configuration errors, it may be undesirable for special tasks and can thus be disabled. The parameter
should only be used for test machines as it might happen that machines do not recover after
configuration problems.
ManageServer-Enable:
(True/False/Yes/No)
This parameter can be set to false to prevent TSS from querying an interface's management status
from the TSS Assistance Server.
ModemReset-Enable:
(True/False/Yes/No)
Use this parameter to disable the automatic reset of modems or data cards. If this parameter is set
to true, the COM ports defined in the parameter ModemReset-Ports will be reset with the user
defined command AT++RESET or, if not defined, AT+CFUN=1,1.
ModemReset-Ports:
(port,port,...)
(string, default: *)
This parameter can be used to manually define the COM ports of the modems to be reset. If the
parameter is not defined or has the value '*', the COM ports of all CIC or RAS connections used in
the executed jobs will be used.
HwNd-Enable:
(True/False/Yes/No)
This parameter can be set to prevent the Huawei NDIS API functions to be loaded. Please note that
the interface dll ndisapi.dll has to be present in the TSS executable directory.
InterceptShutdown:
(True/False/Yes/No)
(bool, default: false)
This parameter has to be set to true to allow the execution of a shutdown job when the power
button is pressed. This feature is not required if a power monitor device is managed by TAS but is
required if a power button press is simulated (e.g. by the DCDC-USB power supply). Please note that
as a side effect the system will execute a shutdown job and then be turned off in the following
cases:
o when the power button is pressed
o when the user shuts down the system (e.g. with the start menu)
o when the user reboots the system (e.g. with the start menu)
This behavior is caused by the implementation of windows that does not allow the application to
distinguish between those events. To avoid this behavior the user has to terminate TSS before
initiating a windows reboot. =0.0.12.10=
EwfTimeZoneFix:
(True/False/Yes/No)
If this parameter is set to true, TSS automatically checks if the OS is XP embedded or Windows 7
embedded and EWF is enabled. In this case, an automatic EWF commit is initiated if the time zone
has changed (e.g. from standard time to summer time), to fix an issue of Windows and EWF.
Otherwise windows would adjust the system time by one hour after every reboot. Set the parameter
to false to disable EWF checks. =0.0.13.1=
Section [Scheduler]
The machine configuration file may include one section Scheduler. Please note that the parameters in
the machine configuration file supersede the settings in the system configuration file.
Known parameters in machine.cfg configuration section [Scheduler]
Agent-Shift-Fixed:
<1d1h1m1s1ms>
(duration, optional)
If this parameter is defined, it overrides the automatic agent shift defined by Agent-Shift-Max and
Agent-Shift-Inc and delays all task executions by the specified time. Please note that the execution
IDs will be assigned the non-delayed time while the Measurement time (mtime) will be assigned the
actual execution time, e.g.
Agent-Shift-Fixed:
Scheduled time:
Execution ID:
Measurement time:
Agent-Shift-Max:
3m
01.Jan.2009 13:00:00
20090101-130000+0100
20090101-130301+0100
<1d1h1m1s1ms>
This parameter is only used if Agent-Shift-Fixed is empty. In this case the agents are assigned time
shifts from 0 to Agent-Shift-Fixed in steps of Agent-Shift-Inc. The actual shift is derived from a
permutation of the agent ID to reduce the probability that neighboring agent IDs get similar time
shifts.
Agent-Shift-Inc:
<1d1h1m1s1ms>
This parameter is only used if Agent-Shift-Fixed is empty. It provides the finest granularity between
the different agent shifts.
TSS 0.0.14.0 07.Nov.2011
49
Technical Reference
MaxAssistErrors:
<int>
(integer, default: 3)
Maximum number of consecutive problems reported by the TSS Assistance Service until a soft/hard
reboot is executed. = 0.0.12=
MaxSoftReboots:
<int>
Maximum number of soft reboots before a hard reboot is executed. This parameter is only used if a
watchdog is available and it does NOT support safe power down. In this case up to MaxSoftReboots
soft reboots are executed before a hard reboot to reduce the risk of file system problems due to the
hard power-off while the OS is running. =0.0.12=
MinAssistRebootWait:
<1d1h1m1s1ms>
(duration, default: 1d)
Minimum delay between reboots due to TAS problems. Typical problems leading to TAS reboots are
communication problems with watchdogs or power switches. The parameter MinAssistRebootWait
can be used to prevent excessive reboots due to (non-critical) TAS problems. =0.0.12.3=
CheckAssistanceSvc:
(True/False/Yes/No)
If this parameter is set to false, the TSS Assistance Service is not checked by the scheduler. If it is
true (default), the scheduler regularly queries the TSS Assistance service for problems (e.g. nonfunctioning watchdog or MPSW devices). In case of problems, additional reboots (not shorter than
every 12 hours) are executed. =0.0.12=
WatchAssistanceSvc:
(True/False/Yes/No)
Communicate with TSS Assistance Service in background thread. This function is required when
using a power monitor device. =0.0.12.6=
InitialMPSWDelay:
<1d1h1m1s1ms>
(duration, default: 40s)
Delay execution of first job by given time if a pending MPSW cycle is executed at startup. The delay
is required to allow the mobile to register to the network. =0.0.12.6=
TerminateJobTimeout:
<1d1h1m1s1ms>
Timeout to terminate a running job before starting the shutdown job. The shutdown job is executed
when the power button is pressed (except if RDP owns the console session) or the power monitor
device requests a system shutdown. =0.0.12.6=
ShutdownJobTimeout:
<1d1h1m1s1ms>
Timeout to execute the shutdown job. Shutdown is delayed while the shutdown job is executed, this
parameter is used to prevent the shutdown job from locking or excessive duration. =0.0.12.6=
MaxCpuOverloads:
<int>
(optional, default: 2)
Maximum # of job executions with CPU overload issues before a reboot is initiated. TSS
automatically detects the CPU load during task executions. If the CPU load of one single core is at
100%, this indicates a software issue. If the number of consecutive CPU overload situations exceeds
MaxCpuOverloads, a reboot is initiated. =0.0.13.1=
DisableDelayedStart:
(True/False/Yes/No)
(optional, default: false)
Disable automatic scheduler start after 30min even if not called with /autorun argument. =0.0.14.0
Section [NetworkServices]
The machine configuration file may include one section NetworkServices.
Known parameters in machine.cfg configuration section [NetworkServices]
EnableStatusServer:
(True/False/Yes/No)
Set this parameter to true to enable the internal status server and the memory based ticket storage.
These functions are required by the TSS Status Monitor to access ticket data. =0.0.13.0=
StatusTCPPort:
<int>
(integer, default:8869)
Defines the TCP port used for the integrated status server. Typical values are 8869 or 9016.
=0.0.13.0=
StoreTime:
<1d1h1m1s1ms>
Defines the storage time for tickets in in-memory ticket storage. This parameter is only required if
the integrated status server is used for communication with the TSS Status Monitor (i.e. if
EnableStatusServer is true). =0.0.13.1=
EnableUdpBroadcast:
(True/False/Yes/No)
Enables UDP broadcasting from TSS to TSS. This function has to be enabled to submit or receive
QTS tickets from other test units via UDP. =0.0.13.1=
UdpBroadcastPort:
<int>
(integer, default:8869)
Defines the UDP port used for sending and receiving broadcast messages (e.g. QTS execution tickets
that could not be sent to the QTS Ticket Receiver). Typical values are 8869 or 9016. =0.0.13.1=
TSS 0.0.14.0 07.Nov.2011
50
Technical Reference
UdpReceiveTickets:
(True/False/Yes/No)
Enables reception of QTS tickets via UDP. Received tickets are stored in the outbox directory and
submitted to the QTS Ticket Receiver in the next reporting task. =0.0.13.1=
UdpBroadcastTickets:
(True/False/Yes/No)
Enables submission of QTS tickets via UDP. Only execution tickets are submitted via UDP and only if
the submission in the reporting task failed. This feature can be used in drive testing to allow
reporting even if a single test unit cannot submit QTS tickets. =0.0.13.1=
Section [Sniffer]
The machine configuration file may include one section Sniffer to define a packet sniffer utility and
operational parameters. Please note that the parameters can be overridden in the CIC or Sniffer tasks
=0.0.13.6=.
Known parameters in machine.cfg configuration section [NetworkAdapter]
Sniffer-Type:
(NetCap/NMCap/TShark)
(string, optional)
Defines the packet sniffer tool to be used. Possible values are: =0.0.13.6=
o NetCap
Microsoft NetCap from XP support tools (Windows XP only)
o NMCap
Microsoft NMCap from Network Monitor 3.4 (Windows XP and Windows 7)
o TShark
Wireshark's TShark (Windows XP, LAN only in Windows 7)
Sniffer-Tool:
<exe-file>
(string, optional)
Defines the executable file name for the packet sniffer.

Sniffer-Args:
<args>
(string, optional)
Additional command line arguments for the packet sniffer tool. Arguments automatically applied are:
NetCap:
NMCap:
TShark:
netcap.exe /B:<buf> /N:<id> /C:<file>

nmcap.exe /disableconversations /network <id> /naxframelength <trunc>
/capture /file <file>[:<buf>M]
tshark.exe -n -p -q -F libpcap -B <buf> -s <trunc> -I <id> -w <file>
Shrink-Type:
(TShark)
(string, optional)
Defines the capture file shrinking tool (only required if a .cap file shall be reduced in size by
truncating frames after N bytes). The only supported type is TShark using Wireshark's editcap.exe.
=0.0.13.6=
Shrink-Tool:
<exe-file>
(string, optional)
Defines the executable file name for the capture file shrinking tool (editcap.exe). =0.0.13.6=
Shrink-Args:
<args>
(string, optional)
Additional command line arguments for the capture file shrinking tool. =0.0.13.6=
Sniffer-Enabled:
(True/False/Yes/No)
This parameter has to be set to true to enable the packet sniffer. Can be used to disable the packet
sniffer while preserving all configuration parameters.
Sniffer-Connection:
<type>:<id>
(string, optional)
Defines the internet connection or interface to be used. Possible values are:

o <empty>
use latest CIC or default LAN connection
o CIC
o RAS:<entry> use given RAS connection
o HwNd:<dev> use given Huawei NDIS device
o NIC:<dev>
use given network card (with network card name)
o LAN:<name> use given LAN name
o CAP:<id>
use packet sniffer's internal name (depending on packet sniffer)
Sniffer-TruncBytes:
<bytes>
(integer, optional)
Define this parameter to reduce the number of bytes per captured frame and thus reduce the size of
the capture file while preserving the header information. Please note that TSS uses a different file
extension .scap for shrinked capture files. =0.0.13.6
The following header sizes have to be considered when shrinking capture files:
o MAC header 14 bytes
o IP header
20 bytes
o TCP header 20..32 bytes
A typical frame length of 86 thus results in 20..32 bytes of TCP payload data per frame.
Sniffer-TruncMode:
(None/ShrinkCap/ShrinkReplace/ShrinkAdd) (string, optional)
Defines the truncation mode to be used =0.0.13.6=

o None
do not truncate frames at all (no .scap file created)
o ShrinkCap
shrink while capturing if possible (only .scap file created)
TSS 0.0.14.0 07.Nov.2011
51
Technical Reference
o ShrinkReplace shrink after capturing, but delete .cap file (only .scap file created)
o ShrinkAdd
shrink after capturing, preserve .cap file (.cap and .scap files created)
Sniffer-BufferSize:
<MB>
(integer, optional)
Defines the buffer size for the packet sniffer. Some packet sniffers (NetCap and NMCap) use circular
buffers, i.e. the existing buffer bytes are overwritten once the buffer size is reached. In this case the
buffer size has to be chosen large enough to contain the entire data session. =0.0.13.6=
Sniffer-Compress:
(True/False/Yes/No)
Compress capture file with 7-zip. The smaller output file (either the .scap or .cap) can be
compressed with 7-zip before storage or submission. The input file is deleted after compression to
reduce file system usage. =0.0.13.6=
Sniffer-Submit:
(Never/OnError/OnWarning/Always) (string, optional)
Sniffer files can automatically be submitted via FTP data upload if required. Please note that in this
case the smallest sniffer file (.7z, .scap or .cap) will be copied to the outbox directory, upload has to
be done with a properly configured SubmitLogs task. Possible upload modes are =0.0.13.6=
o Never
o OnError
o OnWarning
o Always
Sniffer-MaxErrors:
<int>
Maximum number of errors (starting or stopping the packet sniffer) until a reboot is done.
Sniffer-AddLog:
(True/False/Yes/No)
Add sniffer tool's console output to execution log for debugging purposes.
Section [NetworkAdapter]
The machine configuration file may include one or several section NetworkAdapter. One section is
required for every LAN Adapter (connected to a LAN or DSL connection) with static IP configuration.
The purpose of this parameters is to provide the parameters for IPConfig tasks with mode Restore.
Note: These parameters are only required for static IP configuration, not if the interface is on DHCP.
The parameters are needed because in case of a power loss or an external reboot while the interface
is configured for measurement, the system will reboot without proper IP configuration and TSS can
only revert to the proper settings if these are defined.
In case of multiple adapters multiple sections have to be defined, the primary key for the sections is
the parameter AdapterName.
Known parameters in machine.cfg configuration section [NetworkAdapter]
AdapterName:
<NIC name>
(string)
This parameter uniquely identifies the NetworkAdapter section. Please use the same adapter name
as in the Windows Networks connections.
AdapterDefaultGW:
<IP addr>
(string)
Specify the default gateway's IP address for the adapter.

AdapterDNSServers:
<IP addr>[,<IP addr>[,...]]
(string)
Specify one or several DNS server IP addresses for the adapter, separated by commas
Section [Directories]
The machine configuration file may include one section Directories. Usually this section will contain
the system and the data directory, but other directories can be defined as well.
Known parameters in machine.cfg configuration section [Directories]
System:
<dir>
(string, mandatory)
The system directory has to be defined, usually it will be the directory the file TSS.exe is located in.
In most cases the parameter will automatically be set by the installer. The system directory is the
base directory for all other directories
Data:
<dir>
(string, optional)
Usually the data directory will be a special directory, if not defined it will default to %system%\data. In
most cases the parameter will automatically be set be the installer.
<Dir>:
<dir>
(string, optional)
Any required directory can be defined according to the following scheme: The parameter name is the
requested directory with an underscore (_) instead of the backslash (\) as directory separator.
Directory
TSS 0.0.14.0 07.Nov.2011
Parameter Name
52
Technical Reference
Apps
Apps\PO
Apps\WST
Scripts
Jobs
Jobs\PO
Jobs\WST
Scheduler
Apps
Apps_PO
Apps_WST
Scripts
Jobs
Jobs_PO
Jobs_WST
Scheduler
Data
Data\Work
Data\Work\Logs
Data\Work\Reports
Data\Work\Data
Data\Work\Sniffer
Data\Work\Scheduler
Data\Work\Assistance
Data\Archive
Data\Archive\Logs
Data\Archive\Reports
Data\Archive\Data
Data\Archive\Sniffer
Data\Archive\Scheduler
Data\Archive\Assistance
Data\Outbox
Data\Outbox\Logs
Data\Outbox\Reports
Data\Outbox\Data
Data\Errors
Data\Errors\Logs
Data\Errors\Reports
Data\Errors\Data
Data\Temp
Data\Persistent
Data
Data_Work
Data_Work_Logs
Data_Work_Reports
Data_Work_Data
Data_Work_Sniffer
Data_Work_Scheduler
Data_Work_Assistance
Data_Archive
Data_Archive_Logs
Data_Archive_Reports
Data_Archive_Data
Data_Archive_Sniffer
Data_Archive_Scheduler
Data_Archive_Assistance
Data_Outbox
Data_Outbox_Logs
Data_Outbox_Reports
Data_Outbox_Data
Data_Errors
Data_Errors_Logs
Data_Errors_Reports
Data_Errors_Data
Data_Temp
Data_Persistent
Section [Watchdog]
A single watchdog model is supported by the TSS Management Service
Cleware USB Watchdog XP (www.cleware.de)
The Cleware access API (usbaccess.dll) has to be copied to the windows directory or the application
directory to use the watchdog.
If the watchdog is configured, it is automatically calmed by the TSS Assistance Service. Every second
reboot is executed as a hard reboot in this case.
Parameters in section [Watchdog]
Model
<model>
Currently only the model Cleware is supported (Cleware USB Watchdog XP). The Cleware access API
(usbaccess.dll) has to be copied to the application directory to use the watchdog.
Functions
<function>,<function>
Currently only one function is supported: Set SupportPowerDown to true if the Cleware USB
Watchdog is connected to an external power supply (e.g. via an USB hub) to ensure USB power is
maintained even if the PS is shut down. If the parameter is set to true, the TSS Assistance service
will safely shut down windows instead of initiating a WD hard reboot.
SupportPowerDown=true/false
Section [ModemSwitch]
Two Modem power switches (MPSW) are supported by the TSS Management Service
Serial USB power switch
Cleware USB cutter
If the power switch is used, a 10 second power cycle is automatically executed before a reboot.
Parameters in section [ModemSwitch]
Model
<model>
Currently the models Serial and Cleware are supported. For serial switches the control lines (DTR or
RTS) are used to control the power switch and an optional activity indicator (LED). The Cleware USB
cutter uses an API (contained in Usbaccess.dll) that does not require parameters. =0.0.12=
Port
<com>:<params>
Contains the serial port and the parameters, e.g. \\.\COM30:9600,n,8.1. This parameter is only
required for serial power switches.
TSS 0.0.14.0 07.Nov.2011
53
Technical Reference
Functions
<function>,<function>
Defines the functions provided by the USB power switch. Two functions can be defined for serial
power switches: Reset and Status. Both functions can be assigned to an output signal (DTR or RTS),
the signal can be inverted if required (if preceded by an exclamation mark).
Reset=DTR/!DTR/RTS/!RTS
Status=DTR/!DTR/RTS/!RTS
The default implementation uses non-inverted DTR for the switch and non-inverted RTS for the LED,
i.e. Functions: Reset=DTR,Status=RTS
Section [GPS]
Serial GPS receivers are supported by TSS and TAS. Please note that most USB GPS receivers provide
a virtual serial port, these are supported by TSS, too. =0.0.12.3=
Parameters in section [GPS]
Model
<model>
Currently the model Serial is supported. =0.0.12.3=

Port
<com>:<params>
Contains the serial port and the parameters, e.g. \\.\COM30:4800,n,8.1. =0.0.12.3=
Owner
TAS/TSS
(string, default: TAS)
Defines the GPS port's owner (TAS or TSS). If owned by TAS, the TSS Assistance Service receives
data from the serial port and broadcasts them via UDP for use on the local machine and in the LAN.
If owned by TSS, UDP functions are not available and GPS data can only be used by the local TSS
instance. =0.0.12.3=
Broadcast-Port
<port>
(integer, default: 8866 or 9012)
The UDP port to broadcast the data to. The port is used for local and remote port in TSS and TAS if
not overridden by one of the detail parameters described below. This parameter is only used if
Owner is TAS. Please note that GPS data is broadcasted to LAN interface only, not to the
measurement interface. =0.0.12.3=
Broadcast-Port-TXL
<port>
(integer, optional)
Override for the local transmit port for special requirements. =0.0.12.3=
Broadcast-Port-TXT
<port>
(integer, optional)
Override for the remote transmit port (transmit-to) for special requirements. =0.0.12.3=
Broadcast-Port-RXL
<port>
(integer, optional)
Override for the local receive port for special requirements. =0.0.12.3=
Broadcast-Port-RXF
<port>
(integer, optional)
Override for the remote receive port (receive-from) for special requirements. =0.0.12.3=
Log-TAS
<off/basic/full>
(string, default:off)
Log mode for GPS data, only used if Owner is TAS. Possible log modes are
o off
... no GPS data is logged
o basic
... only GPRMC and GPGGA records are logged
o full
... the entire GPS NMEA data is logged
Please note that the log file is defined in assistance.cfg, parameter Logfile-GPS. =0.0.12.3=
Section [PowerMonitor]
A power monitor is an external device that signals a required power shutdown to TSS. In addition a
status signal can be controlled by TSS (e.g. a blinking LED). Currently power monitor functions are
available for test purposes only, more advanced functions can be implemented in the future.
=0.0.12.3=
Parameters in section [PowerMonitor]
Model
<model>
Currently the model Serial is supported. Both physical and virtual serial ports can be used.
=0.0.12.3=
Port
<com>:<params>
Contains the serial port and the parameters, e.g. \\.\COM30:4800,n,8.1. =0.0.12.3=
The special value "GPS" is supported to share the serial port with the GPS receiver. Use this method
to use a combined GPS/PowerMonitor cable as shown in section Fehler! Verweisquelle konnte
nicht gefunden werden.. =0.0.12.7=
TSS 0.0.14.0 07.Nov.2011
54
Technical Reference
Functions
<port>
(integer, optional)
Defines the functions provided by the power monitor device. Three functions can be defined for
serial power switches: PowerDown, Status and Const. The first function can be assigned to an input
signal (DCD, DSR, CTS or RI), the remaining functions can be assigned to an output signal (DTR or
RTS), the signals can be inverted if required (if preceded by an exclamation mark). =0.0.12.3=
=0.0.12.6=
PowerDown=DCD/!DCD/DSR/!DSR/CTS/!CTS/RI/!RI
Status=DTR/!DTR/RTS/!RTS
Const=DTR/!DTR/RTS/!RTS
If the PowerDown signal is raised for a time longer than the given shutdown-delay, a shutdown is
internally scheduled. The Status signal can drive a LED that will be toggled to indicate operation. The
Const signal can be used to set an output to constant high or low (e.g. for power supply purposes).
=0.0.21=
The reference implementation uses non-inverted DCD as power input (raised to positive voltage if
shutdown is required), RTS for a LED and DTR as power supply, i.e. Functions:
ShutdownDelay
<1d1h1m1s1ms>
Defines the mimimum time the PowerDown signal has to be set until a shutdown is scheduled.
Please
note
that
an
additional
time
from
Management/ShutdownDelay
to
Management/ShutdownTimeout will occur until the system shutdown is initiated. =0.0.12.3=
=0.0.12.6=
Section [User]
The machine configuration file may include one section User.
Known parameters in machine.cfg configuration section [User]
The user section can contain any user defined parameter. The parameters can be accessed in any
job or task section, e.g.
[User]
Default-CIC-ConnId:
RAS:A1.net
;Default-CIC-User:
;Default-CIC-Password: ; not required for RAS
;Default-CIC-APN:
Sample content in a TSS task:

[Task]
Type:
CIC-ConnId:
CIC-User:
CIC-Password:
CIC-APN:
CIC-Connect
%Default-CIC-Entry%
%Default-CIC-User%
%Default-CIC-Password%
%Default-CIC-APN%
5.1.5 Application configuration file

The application configuration file contains parameters for the installed applications.
5.1.5.1 Sample application configuration file
;
;
;
;
----- application configuration ----this section contains applications that can be accessed by the name defined in
parameter AppType
note: these files are located in %apps% (or %system%\apps) if a relative path is specified
[Application]
AppType:
ExeFile:
PocketOptimizer
PO\PocketOptimizer.exe
[Application]
AppType:
ExeFile:
WebSpeedtest
WST\WebSpeedTest.exe
; ----- method configuration ----; operation methods for special tasks

[Methods]
TimeSync-Method:
TSS 0.0.14.0 07.Nov.2011
http-gettime
55
Technical Reference
; ----- tool configuration ----; file names for special known tools
; note: these files are located in %apps% (or %system%\apps) if a relative path is specified
[Tools]
;Reboot-Tool:
;MPSW-Tool:
Zip-Tool:
;SNTP-Tool:
SNTP-Tool:
cmd.exe /c scripts\extreset.bat
mpsw.exe
7Zip\7z.exe
SmallSNTP\SmallSNTPAgent.exe
NTPDate\ntpdate.exe
5.1.5.2 Allowed sections in the application configuration file

The application configuration file may contain the following sections:
application.cfg
[Application]
[Methods]
[Tools]
[User]
multiple
only once
only once
only once (merged)
5.1.5.3 Detailed parameter description for the application configuration file

Section [Application]
The application configuration file may include several Application sections. The sections are identified
by the parameter AppType.
Known parameters in application.cfg configuration section [Application]
AppType:
<name>
(string)
The name of the application. Known names are PocketOptimizer and WebSpeedTest. Other names
can be used as required.
ExeFile:
<path\file.exe>
(string)
Path to the executable file name. If the file name is not absolute, it has to be relative to the
configuration path %system\apps%, except if it starts with the prefix ~\. In this case, the file name is
not expanded and will be searched in the Windows search path.
ArgumentRule:
<rule>
(string, optional)
The optional argument rule can be used to create the application arguments for script processing
tools. The parameter can contain the placeholders $script$ and $args$ that are expanded to the
corresponding parameters.
The application rule for the Windows command processor cmd.exe is
/c $script$ $args$
Section [Methods]
The application configuration file may include one Method section. This section contains configuration
parameters for special tasks.
Known parameters in application.cfg configuration section [Methods]
TimeSync-Method:
[exec/http-gettime]
(string, optional)
Two different time synchronization methods are available: An external tool or HTTP get-time.
exec: the external tool defined in [Tools].SNTP-Tool is used
http-gettime: An internal HTTP request to the server defined in GetTime-Server is used (typically a
QTS Ticket Receiver or Relay).
Section [Tools]
The application configuration file may include one Tool section. This section contains file names for a
list of well known tools.
Known parameters in application.cfg configuration section [Tools]
Reboot-Tool:
[path\]<file.ext> [args]
(string, optional)
If this parameter is not empty, the specified reset tool is executed instead of rebooting the system
with Windows API calls.
MPSW-Tool:
[path\]<file.ext> [args]
(string, optional)
If this parameter is not empty, the specified modem power switch tool is executed instead of an
internal power switch. The tool shall apply a short (e.g. 10 seconds) power cycle to the modem.
Zip-Tool:
[path\]7z.exe
(string, optional)
The zip tool is used to compress log and data files to backup files. Currently only 7-zip is supported.
TSS 0.0.14.0 07.Nov.2011
56
Technical Reference
SNTP-Tool:
[path\]<file.exe>
(string, optional)
The SNTP tool has to start an SNTP synchronization and terminate if the synchronization is
successful. Otherwise TSS will terminate the application after a timeout and raise an error. Currently
two tools are supported: GNU ntpdate and Alsedi Small SNTP Agent.
Section [User]
The application configuration file may include one section User.
Known parameters in application.cfg configuration section [User]
job or task section.
5.1.6 Platform configuration file

The platform configuration file contains parameters that are specific for a certain hardware/software
platform, e.g. disk quotas and file handling rules.
5.1.6.1 Sample platform configuration file
[Quota]
data_work:
data_archive:
data_backup:
data_errors:
data_outbox:
data_temp:
[Diskfree]
;sys_os:
;sys_temp:
;tss:
;data:
[Tempfiles]
;compress-enabled:
;compress-period:
;compress-delay:
;compress-history:
;compress-complete:
;compress-submit:
;archive-enabled:
;archive-period:
;archive-delay:
;archive-history:
;clean-work-maxage:
;clean-work-maxnum:
;clean-arch-maxage:
;clean-arch-maxnum:
;clean-zip-maxage:
;clean-zip-maxnum:
;clean-err-maxage:
;clean-err-maxnum:
;clean-tmp-maxage:
;clean-tmp-maxnum:
1000M
1000M
1000M
100M
100M
100M
100M
100M
100M
100M
true
P1d
0h
31d
true
false
true
P1d
0h
31d
3d
10000
30d
100000
60d
100
90d
10000
7d
5000
[Tempfiles/Logs]
compress-submit:
clean-maxsize:
true
15%
[Tempfiles/Reports]
compress-submit:
clean-maxsize:
true
15%
[Tempfiles/Data]
clean-maxsize:
30%
[Tempfiles/Sniffer]
clean-maxsize:
30%
[Tempfiles/Assistance]
compress-enabled:
archive-enabled:
clean-maxsize:
false
false
5%
[Tempfiles/Scheduler]
compress-enabled:
false
TSS 0.0.14.0 07.Nov.2011
57
Technical Reference
archive-enabled:
clean-maxsize:
false
5%
[Tempfiles/Temp]
compress-enabled:
archive-enabled:
clean-tmp-maxage:
clean-maxsize:
false
false
7d
100%
5.1.6.2 Allowed sections in the platform configuration file

The platform configuration file may contain the following sections:
platform.cfg
[Quota]
[Diskfree]
[Tempfiles]
[Tempfiles/*]
[User]
only
only
only
only
only
once
once
once
once per directory
once (merged)
5.1.6.3 Detailed parameter description for the platform configuration file

Section [Quota]
The platform configuration file may include one Quota section. These settings are used in clean tasks
only.
Known parameters in platform.cfg configuration section [Quota]
Data_Work:
<int> or <int>M
(string, default: 1000M)
Specifies the maximum size for the directory %system/data/work%, either in bytes or MB.
Data_Archive:
<int> or <int>M
Specifies the maximum size for the directory %system/data/archive%, either in bytes or MB.
Data_Backup:
<int> or <int>M
Specifies the maximum size for the directory %system/data/backup%, either in bytes or MB.
Data_Errors:
<int> or <int>M
Specifies the maximum size for the directory %system/data/errors%, either in bytes or MB.
Data_Outbox:
<int> or <int>M
Specifies the maximum size for the directory %system/data/outbox%, either in bytes or MB.
Data_Temp:
<int> or <int>M
Specifies the maximum size for the directory %system/data/temp%, either in bytes or MB.
Section [Diskfree]
The platform configuration file may include one Diskfree section. The settings are used to check
different drives for minimum free disk space. Warnings are generated in the execution tickets if the
free space drops below the allowed limit. Free disk space is checked in the Cleanup task. =0.0.12=
Known parameters in platform.cfg configuration section [Diskfree]
sys_os:
<int> or <int>M
(string, default: 0)
Specifies the minimum free size for the drive containing the operating system (typically C:\).
sys_temp:
<int> or <int>M
Specifies the minimum free size for the drive containing the system temp directory (typically C:\).
tss:
<int> or <int>M
Specifies the minimum free size for the drive containing the TSS base directory.
data:
<int> or <int>M
Specifies the minimum free size for the drive containing the TSS data directory.
<other>:
<int> or <int>M
Specifies the minimum free size for the drive containing a special TSS directory. The same directory
parameters as in the [Directory] section in machine.cfg can be used (e.g. data_work or data_temp).
Section [Tempfiles]
The platform configuration file may include one Tempfiles section. This section contains the default
values for the specific Tempfiles/<dir> sections.
Please refer to the next section for details.
TSS 0.0.14.0 07.Nov.2011
58
Technical Reference
Section [Tempfiles/<dir>]
The platform configuration file may include one Tempfiles section for the directories Logs, Reports,
Data, Assistance, Scheduler. The first 3 directories are considered as high frequency directory with a
larger amount of files per day, the last 2 directory are low frequency directory.
The different settings apply to the following folders:
Config section
Tempfiles/Logs
Tempfiles/Reports
Tempfiles/Data
Tempfiles/Sniffer
Tempfiles/Scheduler
Tempfiles/Assistance
work directory
data\work\logs
data\work\reports
data\work\data
data\work\sniffer
data\work\scheduler
data\work\assistance
archive directory
data\archive\logs
data\archive\reports
data\archive\data
data\archive\sniffer
data\archive\scheduler
data\archive\assistance
backup directory
data\backup\logs
data\backup\reports
data\backup\data
data\backup\sniffer
data\backup\scheduler
data\backup\assistance
freq
high
high
high
high
low
low
The default values in this chapter are given as <high freq>/<low freq> and are used in clean tasks
only.
Known parameters in platform configuration section [Tempfiles]
compress-enabled:
(True/False/Yes/No)
(bool, default: true/false)
If this parameter is set to true, the content of the work folder will be compressed to 7z backup files.
compress-period:
(P1DT1H1M1S+O1DT1H1M1S)
(period, default: P1D/P1M)
This parameter specifies the compression interval. A value of P1D leads to one backup file per day.
compress-delay:
(1d1h1m1s1ms)
(duration, default: 5m/1h)
This parameter defines an additional delay before the backup file is created. This parameter is used
to avoid the creation of backup archives before the data files are entirely written.
compress-history:
(1d1h1m1s1ms)
(duration, default: 62d/183d)
This parameter defines the maximum age for files in the work directory to be compressed in backup
files. Usually this parameter should not be needed as the files are usually deleted from the work
directory at a maximum age of clean-work-maxage.
compress-complete:
(True/False/Yes/No)
If this parameter is set, the creation of the archive file is delayed until the archive period (compressperiod) and the delay (compress-delay) have expired. Otherwise the archive is created immediately
and will grow in every clean task as new files are added.
compress-complete:
(True/False/Yes/No)
If this parameter is set to true, the content of the work folder will only be compressed if the
compression period is complete, i.e. the compression is delayed until no more files are likely to be
added.
compress-submit:
(True/False/Yes/No)
(bool, def: true for logs/reports)
If this parameter is set to true, the backup file is moved to the output directory for submission.
archive-enabled:
(True/False/Yes/No)
If this parameter is set to true, the content of the work folder will be moved to the archive folder.
archive-period:
(period, default: P1D/P1M)
This parameter defines the backup interval. One sub-directory in the archive directory per backup
interval is created to improve the file system access performance for large amounts of files.
archive-delay:
(1d1h1m1s1ms)
(duration, default: 5m/1h)
This parameter defines an additional delay before files are moved to the archive directory.
archive-history:
(1d1h1m1s1ms)
This parameter defines the maximum age for files in the work directory to be moved to the archive
directory. Usually this parameter should not be needed as the files are usually deleted from the work
directory at a maximum age of clean-work-maxage.
clean-maxsize:
<int>%/<int>/<int>M
(string, default: 30%/5%)
Defines the quota for a particular sub-directory in the work, archive and backup directory. Values
given in percent are relative to the corresponding parameter in section [Quota]. The default values
of 30%+30%+30%+5%+5% will lead to a total utilization of 100%.
Usually this parameter is used if the work, archive and backup directory are assigned the same
percentage. Otherwise different quotas can be defined with clean-work-maxsize, clean-arch-maxsize
and clean-zip-maxsize.
clean-work-maxage:
(1d1h1m1s1ms)
The maximum file age in the work directory. Files are deleted from the work directory after reaching
the specified age.
TSS 0.0.14.0 07.Nov.2011
59
Technical Reference
clean-work-maxnum:
<int>
(integer, default 20000/1000)
The maximum number of files in the work folder.

clean-work-maxsize:
<int>%/<int>/<int>M
Defines the quota for a particular sub-directory of the work directory (Logs/Reports/Data/Scheduler/
Assistance). Values given in percent are relative to the corresponding parameter in section [Quota].
clean-arch-maxage:
(1d1h1m1s1ms)
The maximum file age in the work directory. Files are deleted from the archive directory after
reaching the specified age.
clean-arch-maxnum:
<int>
The maximum number of files in the archive folder.

clean-arch-maxsize:
<int>%/<int>/<int>M
Defines
the
quota
for
a
particular
sub-directory
of
the
archive
directory
(Logs/Reports/Data/Scheduler/ Assistance). Values given in percent are relative to the corresponding
parameter in section [Quota].
clean-bak-maxage:
(1d1h1m1s1ms)
The maximum file age in the backup directory. Files are deleted from the backup directory after
reaching the specified age.
clean-bak-maxnum:
<int>
The maximum number of files in the archive folder.

clean-bak-maxsize:
<int>%/<int>/<int>M
Defines
the
quota
for
a
particular
sub-directory
of
the
backup
directory
(Logs/Reports/Data/Scheduler/ Assistance). Values given in percent are relative to the corresponding
parameter in section [Quota].
clean-err-maxage:
(1d1h1m1s1ms)
The maximum file age in the error directory. Files are deleted from the error directory after reaching
the specified age.
clean-err-maxnum:
<int>
The maximum number of files in the error folder.

clean-err-maxsize:
<int>%/<int>/<int>M
Defines the quota for a particular sub-directory of the error directory (Logs/Reports/Data/Scheduler/
Section [Tempfiles/Temp]
The platform configuration file may include one section Tempfiles/Temp.
The parameters control deletion of files in the directory %system\data\temp%.
Known parameters in platform.cfg configuration section [Tempfiles/Temp]
clean-err-maxage:
(1d1h1m1s1ms)
The maximum file age in the error directory. Files are deleted from the temp directory after reaching
the specified age.
clean-err-maxnum:
<int>
The maximum number of files in the temp folder.

clean-err-maxsize:
<int>%/<int>/<int>M
(string, default: 30%)
Defines the quota for a particular sub-directory of the temp directory (Logs/Reports/Data/Scheduler/
5.1.7 System configuration file

The system configuration file contains parameters concerning the communication and servers.
5.1.7.1 Sample system configuration file
;
;
;
;
TSS System configuration file

----------------------------v0.0.12.3, 26.01.2011
[Scheduler]
;Agent-Shift-Fixed:
Agent-Shift-Max:
Agent-Shift-Inc:
TSS 0.0.14.0 07.Nov.2011
9s
10m
30s
; use fixed agent shift as specified

; use random shift derived from agent ID
; increment (or rounding value) for shifts
60
Technical Reference
;MaxAssistErrors:
;MaxSoftReboots:
;MinAssistRebootWait:
;CheckAssistanceSvc:
;WatchAssistanceSvc:
;InitialMPSWDelay:
;TerminateJobTimeout:
;ShutdownJobTimeout:
3
1
1d
true
true
40s
15s
60s
;
;
;
;
;
;
;
;
max. TAS errors until a reboot (def: 3)

max. soft reboots before a hard reboot
min. time between reboots due to TAS
set to false if TAS shall not be checked
communicate with TAS in bkground thread
delay job after initial MPSW cycle
timeout before starting shutdown job
timeout for shutdown job
[Communication]
Report-Instance:
Report-TIC:
Report-Server:
Report-Enable:
PublicIP-Server:
GetTime-Server:
Sync-Server:
Log-Server:
Log-User:
Log-Pass:
;Log-Passive:
;Log-Enable:
NTP-Server:
Manage-Server:
Manage-Instance:
QTS-Demo
; instance name for QTS
0
; Ticket identification code for QTS
http://www.i-qos.com:8808/
false
; enable QTS ticket upload
http://www.i-qos.com:8808/get-ipaddr
http://www.i-qos.com:8808/get-time
http://www.i-qos.com/config/demo/TSS/default
ftp://www.i-qos.com/upload/demo/TSS/%agentid%
iFtpXxx
; FTP user name for log file upload
iFtpXxx
; FTP password for log file upload
true
; use FTP passive mode for log upload
true
; enable FTP log file upload
0.pool.ntp.org
; NTP server for time synchronization
test2.i-qos.com:8798
; TSS management server
Manage-Demo
; override instance name for TMS
[Tickets]
AddGPSPoints:
;MobileInfoHistory:
auto
10
; add GPS to tickets (auto/none/always)

; # of executions to store MI (0=none)
[Scenarios]
CID-Execution:
CID-Status:
CID-Startup:
CID-Restart:
CID-Shutdown:
CID-ModemReset:
CID-MPSW:
Status-Period:
;Mapping:
1000.exec
1001.status
1002.startup
1003.restart
1004.shutdown
1005.reset
1006.mpsw
P1D+OT15M
mapping.cfg
; CID/TID for execution tickets

; CID/TID for status tickets
; CID/TID for startup ticket
; CID/TID for restart ticket
; CID/TID for shutdown ticket
; CID/TID for modem reset tickets
; CID/TID for MPSW tickets
; period to generate status tickets
; mapping definition of metrics
[User]
; user defined variables for use in job files
;Default-ICMP-Host:
128.131.88.39
5.1.7.2 Allowed sections in the system configuration file

system.cfg
[Scheduler]
[Communication]
[Tickets]
[Scenarios]
[User]
only
only
only
only
only
once (merged)
once
once
=0.0.12.3=
once
once (merged)
5.1.7.3 Detailed parameter description for the system configuration file

Section [Scheduler]
The system configuration file may include one section Scheduler. Please note that these parameters
are superseded by parameters in the machine configuration file.
Known parameters in system.cfg configuration section [Scheduler]
Agent-Shift-Fixed:
<1d1h1m1s1ms>
If this parameter is defined, it overrides the automatic agent shift defined by Agent-Shift-Max and
Agent-Shift-Inc and delays all task executions by the specified time. Please note that the execution
ids will be assigned the non-delayed time while the Measurement time (mtime) will be assigned the
actual execution time, e.g.
Agent-Shift-Fixed:
Scheduled time:
Execution ID:
Measurement time:
TSS 0.0.14.0 07.Nov.2011
3m
01.Jan.2009 13:00:00
20090101-130000+0100
20090101-130301+0100
61
Technical Reference
Agent-Shift-Max:
<1d1h1m1s1ms>
This parameter is only used if Agent-Shift-Fixed is empty. In this case the agents are assigned time
shifts from 0 to Agent-Shift-Fixed in steps of Agent-Shift-Inc. The actual shift is derived from a
permutation of the agent ID to reduce the probability that neighboring agent IDs get similar time
shifts.
Agent-Shift-Inc:
<1d1h1m1s1ms>
This parameter is only used if Agent-Shift-Fixed is empty. It provides the finest granularity between
the different agent shifts.
MaxAssistErrors:
<int>
Maximum number of consecutive problems reported by the TSS Assistance Service until a soft/hard
reboot is executed. =0.0.12=
MaxSoftReboots:
<int>
Maximum number of soft reboots before a hard reboot is executed. This parameter is only used if a
watchdog is available and it does NOT support safe power down. In this case up to MaxSoftReboots
soft reboots are executed before a hard reboot to reduce the risk of file system problems due to the
hard power-off while the OS is running. =0.0.12=
MinAssistRebootWait:
<1d1h1m1s1ms>
Minimum delay between reboots due to TAS problems. Typical problems leading to TAS reboots are
communication problems with watchdogs or power switches. The parameter MinAssistRebootWait
can be used to prevent excessive reboots due to (non-critical) TAS problems. =0.0.12.3=
CheckAssistanceSvc:
(True/False/Yes/No)
If this parameter is set to false, the TSS Assistance Service is not checked by the scheduler. If it is
true (default), the scheduler regularly queries the TSS Assistance service for problems (e.g. nonfunctioning watchdog or MPSW devices). In case of problems, additional reboots (not shorter than
every 12 hours) are executed. =0.0.12=
WatchAssistanceSvc:
(True/False/Yes/No)
Communicate with TSS Assistance Service in background thread. This function is required when
using a power monitor device. =0.0.12.6=
InitialMPSWDelay:
<1d1h1m1s1ms>
Delay execution of first job by given time if a pending MPSW cycle is executed at startup. The delay
is required to allow the mobile to register to the network. =0.0.12.6=
TerminateJobTimeout:
<1d1h1m1s1ms>
Timeout to terminate a running job before starting the shutdown job. The shutdown job is executed
when the power button is pressed (except if RDP owns the console session) or the power monitor
device requests a system shutdown. =0.0.12.6=
ShutdownJobTimeout:
<1d1h1m1s1ms>
Timeout to execute the shutdown job. Shutdown is delayed while the shutdown job is executed, this
parameter is used to prevent the shutdown job from locking or excessive duration. =0.0.12.6=
Section [Communication]
The system configuration file may include one section Communication.
Known parameters in System.cfg configuration section [Communication]
Report-Instance:
<instance>
(string, optional)
The QTS instance (database) name. The instance name will automatically be inserted into all
submitted tickets.
Report-TIC:
<http-int>
(integer, optional)
The QTS TIC (ticket identification code). The TIC will automatically be inserted into all submitted
tickets.
Report-Server:
<http-url>
(string, optional)
URL for a report server (QTS ticket receiver or relay). QTS tickets are delivered using the HTTP
protocol.
Report-Enable:
(True/False/Yes/No)
If this parameter is false, QTS ticket files are not submitted to the QTS ticket receiver. In this case,
Report tasks are skipped. =0.0.13.8=
PublicIP-Server:
<http-url>
(string, optional)
URL for a server providing the public IP address. Usually the QTS ticket receiver or relay provides
this information under the path get-ipaddr. The parameter can be overwritten in the PublicIP task
parameter PublicIP-Server.
TSS 0.0.14.0 07.Nov.2011
62
Technical Reference
GetTime-Server:
<http-url>
(string, optional)
URL for a server providing the current time in XML format. Usually the QTS ticket receiver or relay
provides this information under the path get-time. The parameter can be overwritten in the
TimeSync task parameter GetTime-Server.
Sync-Server:
<http-url>
(string, optional)
URL to the server containing the synchronization data. The synchronization main configuration file
synchronization.cfg has to reside in this directory.
Log-Server:
<ftp-url>
(string, optional)
Path to a server to receive or store the log files. The placeholder %agentid% is replaced by the actual
agent ID. The two sub-directories logs and data have to be available in the directory to receive the
corresponding files from the output directories.
Log-User:
<user>
(string, optional)
FTP user name for log/data file submission.

Log-Pass:
<pass>
(string, optional)
FTP password for log/data file submission

Log-Passive:
(True/False/Yes/No)
If this parameter is true, passive mode is used for log/data file submission.
Log-Enable:
(True/False/Yes/No)
If this parameter is false, no log or data files are moved to the outbox folder and loaded to the FTP
server. Note that the parameter can be overridden by the parameter Submit-Enable in the machine
configuration file.
Section [Tickets]
The system configuration file may include one section Tickets. =0.0.12.3=
Known parameters in System.cfg configuration section [Tickets]
AddGPSPoints:
<none/auto/always>
(string, optional)
Specifies how GPS coordinates are added to the ticket, parameter <coordinates><points>. Please
note that coordinates are always added to <coordinates><longitude> and <coordinates><latitude> if
available =0.0.12.3=.
o none
... <points> is not filled
o auto
... <points> is only filled if coordinates with more than 50m distance exist
o always
... <points> is always filled, even if only a single point is added
MobileInfoHistory:
<int>
(integer, optional, default: 10)
Number of task executions to store mobile information in internal storage. Set this parameter to 0 to
use life data only and disable storage of mobile information. =0.0.12.7=
Section [Scenarios]
The system configuration file may include one section Scenarios.
Known parameters in System.cfg configuration section [Scenarios]
CID-Execution:
<int>[:<eid>]
(string, optional)
Scenario ID and execution ID for execution tickets. An execution ticket is generated for every job
sequence started by the scheduler.
CID-Status:
<int>[:<eid>]
(string, optional)
Scenario ID and execution ID for status tickets. Status tickets are created periodically if required.
CID-Startup:
<int>[:<eid>]
(string, optional)
Scenario ID and execution ID for startup tickets. Startup tickets are created when the scheduler is
started.
CID-Restart:
<int>[:<eid>]
(string, optional)
Scenario ID and execution ID for restart tickets. Restart tickets are required before a reboot or
restart is required.
CID-Shutdown:
<int>[:<eid>]
(string, optional)
Scenario ID and execution ID for shutdown tickets. Shutdown tickets are created when system
shutdown is requested (either by pressing the power button or by the power monitor device).
=0.0.12.6=
CID-ModemReset:
<int>[:<eid>]
(string, optional)
Scenario ID and execution ID for modem reset tickets. Modem reset tickets are created before a
reboot if a modem is reset with e.g. an AT+CFUN command.
TSS 0.0.14.0 07.Nov.2011
63
Technical Reference
CID-MPSW:
<int>[:<eid>]
(string, optional)
Scenario ID and execution ID for modem power switch tickets. MPSW tickets are created when an
MPSW cycle is executed by the TSS Asisstance Service. This can be the case in CheckModem tasks,
before a reboot or after startup. =0.0.12.6=
Status-Period:
(period, default: P1D+OT30M)
<file.ext>
(string, optional)
Period for status tickets.

Mapping:
File name of an optional metric mapping file. The file contains custom mappings from internal metric
ids (such as x.100 or m.5230) to user defined text or metric IDs or extension field names.
Section [User]
The system configuration file may include one section User.
Known parameters in application.cfg configuration section [User]
job or task section.
5.1.8 Mobile configuration file

The mobile configuration file contains parameters for model specific AT commands (custom
commands). The configuration file is used by AT-Command tasks.
Please note: user defined commands (or custom commands) have to start with AT++ to be detected
by TSS. Commands starting differently will directly be sent to the mobile without looking up the real
command in the mobile configuration file.
5.1.8.1 Sample mobile configuration file
;
;
;
;
TSS Mobile configuration file

----------------------------v0.0.14.0, 07.11.2011
;
;
;
;
;
;
This file defines user commands for different mobiles.

It may contain several [MobileDevice] sections. Mobiles are
defined either by Id (manufacturer|model) or IMEI. User
defined commands can be specified as required with the prefix
'Cmd-', e.g. Cmd-AT++ZZZ for the command AT++ZZZ.
Note: user defined commands have to start with AT++
[MobileDevice]
Name:
Id-01:
Id-02:
Id-03:
Id-04:
Id-05:
Id-06:
Id-07:
Id-08:
Id-09:
Id-10:
;IMEI-01:
Cmd-AT++RAT-auto:
Cmd-AT++RAT-2G:
Cmd-AT++RAT-3G:
Cmd-AT++RAT-2G+3G:
Cmd-AT++RAT-3G+2G:
Huawei Data Cards

huawei|E17X
huawei|E27*
huawei|E22*
huawei|E87*
huawei|E3735*
huawei|E182E*
huawei|EM770*
huawei|K3715*
huawei|E169*
huawei|E630*
359298*
AT^SYSCFG=2,2,780380,1,2
AT^SYSCFG=13,0,780380,1,2
AT^SYSCFG=14,0,780380,1,2
AT^SYSCFG=2,1,780380,1,2
AT^SYSCFG=2,2,780380,1,2
[MobileDevice]
Name:
Id-01:
Method-RAT:
Cmd-AT++RAT-auto:
Cmd-AT++RAT-2G:
Cmd-AT++RAT-3G:
Cmd-AT++RAT-2G+3G:
Cmd-AT++RAT-3G+2G:
Huawei DC-HSPA+ Data Cards (SysInfoEx)

huawei|E372
SysInfoEx
AT^SYSCFG=2,2,780380,1,2
; AT++RAT=auto
AT^SYSCFG=13,0,780380,1,2
; AT++RAT=2G
AT^SYSCFG=14,0,780380,1,2
; AT++RAT=3G
AT^SYSCFG=2,1,780380,1,2
; AT++RAT=2G+3G
AT^SYSCFG=2,2,780380,1,2
; AT++RAT=3G+2G
;
;
;
;
;
AT++RAT=auto
AT++RAT=2G
AT++RAT=3G
AT++RAT=2G+3G
AT++RAT=3G+2G
[MobileDevice]
Name:
Huawei LTE Data Cards (SysInfoEx+SysCfgEx)
Id-01:
huawei*|E392
; note: requires TSS 0.0.13.10 or above to support vendor wildcards
TSS 0.0.14.0 07.Nov.2011
64
Technical Reference
Method-RAT:
SysInfoEx
; note: E392 does not support AT^SYSCFG, just AT^SYSCFGEX
; note: 00=auto, 01=GSM, 02=UMTS, 03=LTE
Cmd-AT++RAT-auto:
AT^SYSCFGEX="00",3FFFFFFF,1,2,7FFFFFFFFFFFFFFF,0,0
Cmd-AT++RAT-2G:
Cmd-AT++RAT-3G:
Cmd-AT++RAT-4G:
Cmd-AT++RAT-2G+3G:
Cmd-AT++RAT-3G+2G:
[MobileDevice]
Name:
Id-01:
Id-02:
Method-RAT:
Cmd-AT++RAT-2G:
Cmd-AT++RAT-3G:
Cmd-AT++RAT-2G+3G:
Cmd-AT++RAT-3G+2G:
Option Globetrotter 3G+ (Nozomi), HSDPA

Option N.V.|GlobeTrotter 3G+
Option N.V.|GlobeTrotter HSDPA Modem
COPS
AT_OPSYS=0,2
AT_OPSYS=1,2
AT_OPSYS=2,2
AT_OPSYS=3,2
[MobileDevice]
Name:
Id-01:
Id-02:
Method-RAT:
Method-SignalLevel:
Method-Power:
Cmd-AT++RAT-2G:
Cmd-AT++RAT-3G:
Cmd-AT++RAT-2G+3G:
Cmd-AT++RAT-3G+2G:
Ericsson F3507G/Dell 5530

Dell|D5530
Ericsson|F3507G
E2EMM9
E2EMM9
CFUNE04
AT+CFUN=5
AT+CFUN=6
AT+CFUN=1
AT+CFUN=1
;
;
;
;
;
;
AT++RAT=auto
AT++RAT=2G
AT++RAT=3G
AT++RAT=4G
AT++RAT=2G+3G
AT++RAT=3G+2G
[;MobilePorts]
; sample rule to derive diagnostic COM port
; use this section as sample for other sections, it is internally contained in TSS
Name:
Huawei Data Cards (test)
ID-01:
USB\Vid_12d1*
DeviceDesc-01:
Huawei Test
Rule-Modem-01:
Class=Modem
Rule-Port0-01:
Class=Modem
Rule-Port1-01:
Class=Ports,DeviceDesc="*PC UI Interface*"
Method-Modem:
Device:FriendlyName
Method-Port0:
Modem:AttachedTo
Method-Port1:
Device:Device Parameters\PortName
5.1.8.2 Allowed sections in the mobile configuration file

mobiles.cfg
[MobileDevice]
[MobilePorts]
multiple
multiple
=0.0.13.5=
5.1.8.3 Detailed parameter description for the mobile configuration file

Section [MobileDevice]
The mobile configuration file may include multiple MobileDevice sections.
Known parameters in mobiles.cfg configuration section [MobileDevice]
Name:
<name>
(string, optional)
Use this parameter to provide a descriptive name for the device configuration. The parameter is used
for log file output only.
ID-00..ID-99:
<vendor>|<model>[*]
(string, optional)
Use the parameters ID-00 to ID-99 to specify combinations of vendor and model separated by a pipe
character (|). A trailing asterisk (*) can be used to indicate that any characters may follow the given
string. The configuration will be used if any of the ID-xx or IMEI-xx filters match.
IMEI-00..IMEI-99:
<imei>[*]
(string, optional)
Use the parameters IMEI-00 to IMEI-99 to specifiy an IMEI or the start characters of the IMEI if
using a trailing asterisk (*). The configuration will be used if any of the ID-xx or IEMI-xx filters
match.
TSS 0.0.14.0 07.Nov.2011
65
Technical Reference
Cmd-<cmd>:
<at-command>
(string, optional)
Use these parameters to specify user defined AT commands. The parameter name has to be the
command preceded by the prefix 'Cmd-'. Please note that in addition the character '=' has to be
replaced by '-'. To distinguish user defined commands from regular commands, they should be
named AT++XXX.
Examples:
; AT++ZZZ
; AT++RAT=2G
-> parameter Cmd-AT++ZZZ

-> parameter Cmd-AT++RAT-2G
Method-RAT:
This parameter defines

are:
o <empty>
o COPS
o SYSINFO
o SYSINFOEX
o E2EMM9
Method-SignalLevel:
(COPS/SYSINFO)
(string, optional)
the AT command used to get the radio access technology. Possible methods
same as COPS
use AT+COPS (default)
use AT^SYSINFO (Huawei)
use AT^SYSINFOEX (Huawei E372 and above) =0.0.13.5=
use AT*E2EMM=9 (Ericsson)
(E2EMM9)
(string, optional)
This parameter defines the AT command used to get the signal level. Possible methods are:
o <empty>
use AT+CSQ (default)
o E2EMM9
use AT*E2EMM=9 (Ericsson)
Method-Power:
(CFUNE4)
(string, optional)
This parameter defines the AT command used to detect the power state. Possible methods are:
o <empty>
don't detect power state
o CFUNE04
use AT+CFUN and treat result 0 and 4 as turned off (Ericsson)
Section [MobilePorts]
The mobile configuration file may include multiple MobilePorts sections. =0.0.13.5=
Known parameters in mobiles.cfg configuration section [MobilePorts]
Name:
<name>
(string, optional)
Use this parameter to provide a descriptive name for the device configuration. The parameter is used
for log file output only.
ID-00..ID-99:
<device id>
(string, optional)
Use the parameters ID-00 to ID-99 to specify hardware device IDs (typically USB device IDs)
identifying the device. A trailing asterisk (*) can be used to indicate that any characters may follow
the given string. The configuration will be used if any of the ID-xx or DeviceDesc-xx filters match.
A typical USB device ID is in form USB\Vid_xxxx&Pid_xxxx*, a filter for Huawei devices is
USB\Vid_12d1*.
DeviceDesc-00..99:
<device description>
(string, optional)
Use the parameters DeviceDesc-00 to DeviceDesc-99 to specify hardware device descriptions

identifying the device. The device description for a given device has to be derived from the registry,
however it is recommended to use the ID parameters instead.
The device description for a Huawei E170 modem device is "Huawei Mobile Connect - 3G Modem".
Rule-Modem-00..99:
<rule>
(string, optional)
Rule to derive the modem device from a given hardware device ID. The rule is used to select the
modem device from a multi-function device. Please note that this rule is reserved for future use and
is not required by TSS.
For example a Huawei E170 data card contains the following devices:
Vid_12d1&Pid_1003&MI_00 HUAWEI Mobile Connect - 3G Modem
Vid_12d1&Pid_1003&MI_01 HUAWEI Mobile Connect - 3G PC UI Interface
Vid_12d1&Pid_1003&MI_02 USB-Mass Storage device
For most devices, the modem can be identified by the simple filter Class=Modem. Once the device is
identified, the modem name is derived with the method defined in Method-Modem.
Rule-Port0-00..99:
<rule>
(string, optional)
Rule to derive the modem COM port name from a given hardware device ID. The rule is used to
select the modem device from a multi-function device. Please note that this rule is reserved for
future use and is not required by TSS.
For most devices, the modem can be identified by the simple filter Class=Modem. Once the device is
identified, the modem COM port is derived with the method defined in Method-Port0.
TSS 0.0.14.0 07.Nov.2011
66
Technical Reference
Rule-Port1-00..99:
<rule>
(string, optional)
Rule to derive the monitoring COM port from a given hardware device ID. The rule is used to select
the secondary COM port (typically used by the dashboard application) from a multi-function device.
This rule is required if an AT background thread shall be used with a data card.
Typical Rules for secondary COM ports are:
Class=Ports,DeviceDesc="*3G PC UI Interface*"
Class=Ports,Service=hwdatacard,Serial:PortIdentify=HWPCUI
Class=Ports,USB:Prot=Prot_02
Class=Ports,USB:MI=MI_01
(Huawei
(Huawei
(Huawei
(Huawei
generic)
E372)
E372/Win7)
E170/XP)
Please contact support if a rule for a new device has to be found.

Method-Modem:
<method>
(string, optional)
Method to derive the modem name from the modem device.

The method suitable for most modems is:
Device:FriendlyName
This method uses the parameter FriendlyName in the device's enumeration registry key.
Method-Port0:
<method>
(string, optional)
Method to derive the primary COM port from the modem device.
Modem:AttachedTo
This method uses the parameter AttachedTo in the associated modem's registry key.
Method-Port1:
<method>
(string, optional)
Method to derive the secondary COM port from the communication device.
Device:Device Parameters\PortName
This method uses the parameter PortName in the associated port's registry key, sub-key Device
Parameters.
5.1.9 Mapping configuration file

The mapping configuration file contains parameters to map from internal metric IDs to user defined
QTS metric IDs or QTS extension fields.
Please note that the TSS mapping file only controls those metrics that are created or added by TSS,
these are:
all metrics in the system tickets (execution, startup, restart, status)
all metrics in the RAS tickets (CIC-Dial, CIC-Hangup, RAS-Dial, RAS-Hangup)
additional metrics added to tickets created by external tools (TSS info, RAS info).
The TSS mapping file does not control metrics created by other tools, please refer to the mapping files
for PocketOptimizer and WebSpeedTest to control metrics generated by this tools.
The mapping file allows to map a metric ID to one or several other IDs or to remove metrics from the
ticket (in these case the metrics are added as comments).
5.1.9.1 Sample mapping configuration file
;
;
;
;
;
;
;
This file contains several mapping sections to map known Metrics

to user defined metrics. Section names can either be 'default' or
one of the known measurement formats.
Known metrics can be m.123 (numeric metrics) or x.123 (text metrics).
User defined metrics can be m.<id>, x.<id> or e.<id>.<field> for extensions.
Metrics without destination mappings are not added to the XML report.
Unmentioned metrics are mapped
[default]
; this section
mfid:
x.100:
x.101:
x.105:
x.140:
contains default mapping for all TSS generated metrics

*.user
; target mf ID: e.g. TSS.CIC-Dial.User
x.100,e.test1.version
; map to text metric and extension
x.101
; map to default value
; do not add to ticket
x.140,e.test1.ip
[TSS.Exec]
; this section contains special mappings for TSS metrics with format TSS.Exec
mfid:
*.user
; target mf ID: TSS.Exec.User
x.140:
x.140,e.test1.ip
TSS 0.0.14.0 07.Nov.2011
67
Technical Reference
5.1.9.2 Allowed sections in the mapping configuration file

The mapping configuration file may contain the following sections:
mapping.cfg
[default]
[TSS.Exec]
[TSS.Startup]
[TSS.Restart]
[TSS.Status]
[TSS.CIC-Dial]
[TSS.CIC-Hangup]
[TSS.CIC-Add]
[TSS.RAS-Dial]
[TSS.RAS-Hangup]
[TSS.RAS-Add]
Please note that the sections [TSS.RAS-*] is used if [TSS.CIC-*] is not existing for compatibility with
previous versions.
5.1.9.3 Detailed parameter description for the mapping configuration file
Section [default]
The mapping configuration file may include one section default.
Known parameters in mapping.cfg configuration section [default]
mfid:
<text>
(string, optional)
Contains the target measurement format identifier. If not specified, the suffix '.user' will be
appended to the source measurement format ID.
m.<id>:
m.<id>,x.<id>,e.<ext>.<col>
(string, optional)
Mapping for numeric metrics. A metric can be mapped to an empty value (i.e. it will not be added to
the XML report) or to any combination of numeric metrics, text metrics or extensions.
Please note that if using extensions the extension table must exist in the QTS database, must be
mapped in the extension table and must contain the defined column.
x.<id>:
x.<id>,e.<ext>.<col>
(string, optional)
Mapping for text metrics. A text metric can be mapped to an empty value or to any combination of
text metrics or extensions. Mapping to numeric metrics is theoretically possibly, but will probably fail
as the metric's content cannot be converted to a numeric value.
Please note that if using extensions the extension table must exist in the QTS database, must be
mapped in the extension table and must contain the defined column.
Section [TSS.<mf>]
The mapping configuration file may include one section per known measurement format. The specific
sections contain the same parameters as the default section and override the default mapping if
present.
The sections TSS.CIC-Add and TSS.RAS-Add has a special function: it controls the metrics that are
added to tickets produced by other tools (e.g. PocketOptimizer, WebSpeedTest etc.).
5.1.10 Assistance configuration file

The assistance configuration file contains parameters for the TSS assistance background service.
5.1.10.1 Sample assistance configuration file
[Network]
ListenPort:
8868
[Management]
Password:
DontReboot:
RabbitHole
true
[Routing]
AutoDelete:
;DontSetRoutes:
12h
true
[Directories]
LogFiles:
logs
[Log]
LogLevel:
P-Info
TSS 0.0.14.0 07.Nov.2011
68
Technical Reference
LogFile:
LogFile-GPS:
LogRotate:
assistance.log
gps.log
1d
5.1.10.2 Allowed sections in the assistance configuration file

The assistance configuration file may contain the following sections:
assistance.cfg
[Network]
[Management]
[Routing]
[Directories]
[Log]
[Installer]
5.1.10.3 Detailed parameter description for the assistance configuration file

Section [Network]
The assistance configuration file may include one section Network.
Known parameters in assistance.cfg configuration section [Network]
ListenPort:
<int>
Defines the UDP port the service uses to listen for incoming control packets or 0 to disable the UDP
function. The TSS Assistance Client can be used to create UDP packets to set routes or reboot the
machine but the UDP method has been superseded by the TSS Management Server.
TcpService
<ip>:<port>
127.0.0.1:8868 (9018)
This is the port the service uses to communicate with the TSS assistance service. The function is not
required for a standalone installation. Set the value to off to disable the TCP server.
Broadcast-Port
<port>
8867 (9013)
This port is used as local and target port for UDP broadcast packets containing status information.
The broadcast packets can be used by a remote computer in the LAN to detect the available TSS
machines and determine their status. =0.0.12.6=
Broadcast-Port-TXL
<port>
This parameter overrides the local UDP port for the status broadcasts, i.e. the source port in the UDP
packets. It is only required for special purposes. =0.0.12.6=
Broadcast-Port-TXR
<port>
This parameter overrides the remote UDP port for status broadcasts, i.e. the destination port in the
UDP packets. It is only required for special purposes. =0.0.12.6=
Section [Management]
The assistance configuration file may include one section Management.
Known parameters in assistance.cfg configuration section [Management]
Password:
<pass>
(string, optional)
The password that has to be entered in the assistance client to reboot the machine.
DontReboot:
(True/False/Yes/No)
(bool, default: False)
If this parameter is set to true, the background service will not initiate a system reboot if the TSS
scheduler is not running any more. Otherwise the service will reboot the machine if the scheduler is
not running for 10 minutes (if it was not running at all) of after 2 minutes (if it stopped running).
DontScanScheduler
bool
false
This parameter has to be set to true to disable monitoring of the TSS scheduler. If the parameter is
not set to true, the machine will be rebooted after 2 hours.
ShutdownDelay
<1d1h1m1s>
15s
Delay from the detection of a valid power down signal until a shutdown is initiated. Within this time
TSS is informed of a pending shutdown and has the chance to block shutdown to cancel the pending
job and execute the shutdown job. If TSS does not block, a system shutdown is initiated after the
given delay. Please note that the delay is triggered after PowerMonitor/ShutdownDelay expires.
=0.0.12.6=
ShutdownTimeout
<1d1h1m1s>
60s
Delay from the detection of a valid power down signal until a shutdown is forced. TSS cannot block
shutdown any more if this timeout expires. Please note that the delay is triggered after
PowerMonitor/ShutdownDelay expires. =0.0.12.6=
TSS 0.0.14.0 07.Nov.2011
69
Technical Reference
AutoUseRAS
<1d1h1m1s>
Set this parameter to a duration in form 1d1h1m1s to enable management over RAS devices. If not
configured, RAS connections will not be used for management to avoid influencing measurements. If
RAS connections shall be used, a delay can be specified with the parameter AutoUseRAS. If the
delay is greater than zero, a RAS connection will be used for management after the specified time
(starting with connection establishment).
RasUsbEnumServices
string
"ewusbnet"
A list of service names for NIC cards that shall be treated as RAS devices. Several values can be
separated by commas. USB network cards with the given service name will be treated as RAS
devices and not used for management automatically. The default value "ewusbnet" is suitable for
Huawei devices (e.g. E182E).
RasNicNames
string
"MBB*"
A list of network card names for NIC cards that shall be treated as RAS devices. Several values can
be separated by commas. Network cards following this naming convention will be treated as RAS
devices and not used for management automatically. Assign names like "MBB-Huawei" to your virtual
network cards to have them excluded from management with the default value of "MBB*".
Section [Routing]
The assistance configuration file may include one section Routing.
Known parameters in assistance.cfg configuration section [Routing]
AutoDelete:
(1d1h1m1s1ms)
(duration, default:12h)
This parameter specifies the maximum age of a custom route set by the assistance service. If a
special route is requested by the assistance client, the route is temporarily set by the service. It is
automatically removed if Windows is restarted or after the specified timeout expires.
DontSetRoutes
bool
false
If this parameter is set to true, the service does not set specific routes to the TSS Management
Server on the interfaces in use. This behavior can be required if running without administrative rights
or with UAC in Windows Vista or 7.
Section [Directories]
The assistance configuration file may include one section Directories
Known parameters in assistance.cfg configuration section [Directories]
LogFiles:
<dir>
(string, optional)
Specifies the directories to contain the log files.

Section [Log]
The assistance configuration file may include one section Log.
Known parameters in assistance.cfg configuration section [Log]
LogLevel:
<level>
(string, default:P-Warn)
<file.log>
(string, optional)
Log level for log file output.

LogFile:
Log file name. If log rotation is used, the date/time is appended to the file name.
LogFile-GPS:
<gps.log>
(string, optional)
GPS Log file name. If log rotation is used, the date/time is appended to the file name. =0.0.12.3=
LogRotate:
<1d1h1m1s1ms>
(duration, default:31d)
Log rotation period. A new log file is automatically created if the date/time enters a new log file
period.
Section [Installer]
The assistance configuration file may include one section Installer.
Known parameters in assistance.cfg configuration section [Installer]
service_name:
<name>
(string, optional)
This parameter is used by the installer to store the service name for future updates and the uninstall
routine.
TSS 0.0.14.0 07.Nov.2011
70
Technical Reference
5.2 Scheduler Reference

The main component of TSS is the scheduler to execute TSS jobs. The scheduler is controlled by the
scheduler configuration file.
5.2.1 Scheduler file format

The scheduler file is an XML file containing rules how to execute jobs. It has to be located in the
directory %system\scheduler% (usually %system%\scheduler).
5.2.1.1 Sample scheduler file
<?xml version="1.0"?>
<schedule-plan>
<schedule mode="planned" name="Default">
<jobs>
<job>Demo-Std01-WithDSL.tss-job</job>
<job inc-agentid="0" inc-scenarioid="0">SpecialTest.tss-job</job>
</jobs>
<plan>
<start mode="interval">PT15M</start>
</plan>
</schedule>
<startup>
<jobs>
<job>Demo-Startup01.tss-job</job>
</jobs>
</startup>
<shutdown>
<jobs>
<job>Demo-Shutdown01.tss-job</job>
</jobs>
</shutdown>
</schedule-plan>
Scheduler file specification

element
schedule-plan
container
The root element of the scheduler file has to be a schedule-plan element.

element
schedule-plan/schedule
container
The schedule-plan element contains one or several schedule elements. Every schedule item is
assigned one or several jobs to be executed consecutively and an execution plan.
attribute schedule-plan/schedule.mode
string
Two different scheduling modes are available:

o planned
one or several intervals or start times can be specified.
o continuous
the jobs will immediately started after the previous job has finished.
Please note that planned and continuous modes cannot be mixed and that only one continuous item
can be scheduled.
attribute schedule-plan/schedule.name
string
If required a name can be assigned to the scheduled item. The name will be used in log files and the
progress display.
element
schedule-plan/schedule/jobs
container
The schedule element has to contain a single jobs element acting as a container for one or several
job elements.
attribute schedule-plan/schedule/jobs.inc-agentid
integer >= 0, optional
If the parameter is defined (> 0), the agent ID in the QTS tickets generated by the job is
incremented by the given value. Please note that the increment is applied to execution, RAS/CIC,
MPSW and measurement tickets, not to system tickets. Please refer to 4.9.3 for details. =0.0.13.2=
attribute schedule-plan/schedule/jobs.inc-scenarioid
integer >= 0, optional
If the parameter is defined (> 0), the scenario IDs in the QTS tickets generated by the job are
element
schedule-plan/schedule/jobs/job
string
One or several TSS-jobs can be associated to the scheduled item. The jobs will be executed
consecutively. If a relative path is given, the files have to be located in %system\jobs% (usually
%system%\jobs).
TSS 0.0.14.0 07.Nov.2011
71
Technical Reference
element
schedule-plan/schedule/plan
container, planned mode only
The schedule element has to contain a single plan element in planned mode. The element is not
required in continuous mode.
element
schedule-plan/schedule/start
period-def
The plan element has to contain at least one start element. The content of the element can be:
o daily mode
the content can be a list of execution times in format hh:nn or hh:nn:ss,
separated by commas
o interval mode: the content has to be a period definition.
Period definitions are given in form P<days>T<sub-days>[+O<days>T<sub-days>]. Possible values
for days are nM (months), nW (weeks), nD (days), possible values for sub-days are nH (hours), nM
(minutes) and nS (seconds), not required values can be omitted. For example the period definition
PT1H+O15M leads to execution every 15 minutes after a full hour, e.g. 00:15, 01:15, 02:15 The
period definition P1D leads to execution every day at 00:00.
attribute schedule-plan/schedule/start.mode
Two different scheduling modes are available:

o daily
a list of daily execution times can be specified
o interval
a single period definition can be spedified
element
schedule-plan/startup
container
The startup element contains one jobs element. =0.0.12.6=

element
schedule-plan/startup/jobs
container
Container for one or several job elements. These define the jobs to be executed at scheduler start.
=0.0.12.6=
element
schedule-plan/startup/jobs/job
container
A TSS-job to be executed, refer to schedule-plan/schedule/jobs/job for details. =0.0.12.6=

element
schedule-plan/shutdown
container
The startup element contains one jobs element. =0.0.12.6=

element
schedule-plan/shutdown/jobs
container
Container for one or several job elements. These define the jobs to be executed at system
shutdown. =0.0.12.6=
Please note that a shutdown job will be executed if a system shutdown is signaled to the TSS
Assistance Service by a power monitor device or if a power button press is intercepted by TSS. This
requires the configuration parameter InterceptShutdown to be set to true. =0.0.12.10=
element
schedule-plan/shutdown/jobs/job
container
A TSS-job to be executed, refer to schedule-plan/schedule/jobs/job for details. =0.0.12.6=
5.3 Job File Reference

TSS job files are the input for the TSS execution unit. TSS jobs are either executed automatically by
the scheduler or manually with the button Execute job in the GUI.
Jobs can contain several well known tasks as shown below to run internal tasks or execute external
tools.
5.3.1 Job file format

Job files are sectioned text files similar to windows .ini files.
Sections are specified with square brackets.
Allowed sections are [Job] and [Task].
Section and parameter names are case insensitive.
The semicolon (;) denotes comments if it occurs on the beginning of a line or after a white space.
Parameter names must end with a colon (:)
White spaces in parameter values are removed.
If parameter values contain special characters, they have to be quoted with double quotes (").
5.3.2 Job and task variables

TSS supports different classes of variables and variable functions:
system defined variables: a list of well known system variables provided by TSS
e.g. %execid%, %taskid%, %logid%...
system defined functions: several functions that can be customized by parameters
TSS 0.0.14.0 07.Nov.2011
72
Technical Reference
e.g. %rands(std,8)%, %randi(0,999,1,3)%

user defined variables: can be defined in configuration or job files and used as required
e.g. define: user_test_param: 1234, use: %user_test_param%
5.3.2.1 System defined variables
Please refer to chapter 5.3.30 for a detailed reference of system defined variables.
5.3.2.2 System defined functions
Please refer to chapter 5.3.31 for a detailed reference of user defined variables.
5.3.2.3 User defined variables
User defined variables can be defined in configuration files or job files.
User defined variables in configuration files.
Variables with any name (not conflicting with system defined variables or functions) can be defined in
the following configuration files and sections:
machine.cfg
[User]
application.cfg
[User]
platform.cfg
[User]
system.cfg
[User]
The files are processed in the given order, i.e. if the same parameter is defined in the machine
configuration file, it overrides values in the application configuration file (and the other files).
A sample [user] section in machine.cfg could be:
[User]
Default-CIC-ConnId:
Default-CIC-User:
Default-CIC-APN:

ppp@a1plus.at
ppp
a1.net
User defined variables in job sections

Variables can be defined in the section [job] of a job file. The variables are valid for the entire job
including all tasks and sub-jobs. The variable names have to start with "User-", e.g.
[Job]
User-CIC-ConnId:
User-CIC-User:
User-CIC-Password:
User-CIC-APN:
%@Default-CIC-User%
%@Default-CIC-APN%
The previous sample defines local variables using the values from the configuration files. This
mechanism allows to change parameters for job execution in a single place at the top of the job file.
User defined variables in task sections
Variables can be defined in the section [task] of a job file. The variables are valid only for the current
task (and sub-jobs or task in case of a Sub-Job task). The variable names have to start with "User-".
5.3.2.4 Variable expansion
Variables are expanded when they are used. This chapter defines some additional rules when using
variables.
Nested variables and functions
Nested variables and functions are possible. An example is the use of a random user name for RAS
connections:
content in machine.cfg:
[User]
Default-CIC-ConnId:
Default-CIC-User:
TSS 0.0.14.0 07.Nov.2011

%rands(std,8)%@a1plus.at
ppp
73
Technical Reference
Default-CIC-APN:
a1.net
Content in the job:

[Job]
User-CIC-ConnId:
User-CIC-User:
User-CIC-Password:
User-CIC-APN:
%@Default-CIC-User%
%@Default-CIC-APN%
The previous sample generates random user names with 8 random characters followed by
@a1plus.at.
Using undefined variables
If variables are used in form %name%, the variable has to be defined, otherwise an error will be
generated. If an empty string shall be used if a variable is not defined, the form %@name% has to be
used.
5.3.3 Task types

TSS supports the following task types:
Pause
Inserts a pause of the specified duration into the job sequence.
Sub-Job
This task executes another MSS-Job as a sub job. Sub jobs can be used for logical grouping, to reuse sequences of tasks or to apply conditions to a group of tasks.
CIC-Connect
Establishes a custom internet connection (CIC), such as a RAS connection or a Huawei NDIS
connection. The connection can be continuously monitored if required.
CIC-Hangup
Terminates a custom internet connection.
RAS-Connect (deprecated, use CIC-Connect instead)
Establishes a RAS connection. The connection can be continuously monitored if required.
RAS-Hangup (deprecated, use CIC-Hangup instead)
Terminates a RAS connection.
AT-Command
Sends AT commands to the device associated with a CIC or RAS connection.
CheckModem =0.0.12.6=
Checks if the modem device is available and responding to AT commands.
PocketOptimizer
Executes PocketOptimizer with a specified job file.
WebSpeedTest
Executes WebSpeedTest, the required parameters can be specified as parameters.
Execute
Executes additional tools such as Perl scripts, batch files etc.
TimeSync
Runs the SNTP client to synchronize the local time with an external time server.
Report
Submits the measurement (XML) reports from the outbox directory to the ticket receiver.
SubmitLogs
Submits the measurement logs and data files from the outbox directory to an FTP server.
FileSync
Synchronizes configuration and application files from the synchronization. This task can be
deactivated by the configuration parameter Sync-Enable.
Registration
Submits a registration request to the registration server to register the application or extend the
expiration date.
IPConfig
Manages IP parameters for LAN, CIC or RAS interfaces. Usually this task is used to remove default
routes and DNS servers from LAN/DSL interfaces to avoid influences to the measurement results.
Route
This task removes default routes if required.
GetPublicIP
TSS 0.0.14.0 07.Nov.2011
74
Technical Reference
Contacts a special server to get a public IP address. The task will only be executed if an active
interface is available.
Clean
Manages log and data files on the file system: adds files to .7z archives and the archive folders,
deletes excessive data files and copies files to the outbox folder.
Reboot
Initiates a system reboot.
ModemPowerCycle =0.0.12=
Run a modem power cycle (i.e. turn power off for 10 seconds) if an external modem power switch
(MPSW) is available.
Sniffer-Start and Sniffer-Stop =0.0.13.6=
Start or stop an external packet sniffer (NetCap, NMCap or TShark). Sniffer files can be shrinked
(i.e. reduce packet size) and compressed with 7-zip.
5.3.4 Job parameters

This section describes parameters that are valid for jobs and sub-jobs. The parameters are contained
in the job's [Job] section.
Known parameters for jobs
Name:
<job name>
(string, optional)
A job name can be specified that will be used in the user interface and the log files. If the parameter
is empty, the job's file name is used.
Loops:
<job loops>
If required, more than one loop iteration can be specified. In this case the sequence of tasks will be
executed more than one time. Please note that in this case scenario IDs will be used more than
once. Use the task ID in the XML report to distinguish the different job and task iterations.
Master-Timeout:
<1d1h1m1s1ms>
Master timeout for the entire job execution (including delays and all loop iterations). If the specified
timeout is reached, the current task is terminated and all remaining tasks are skipped.
Loop-Timeout:
<1d1h1m1s1ms>
Timeout for a single loop iteration (including delays and all tasks). If the specified timeout is
reached, the current task is terminated and the remaining tasks for the job loop iteration are
skipped. Execution is continued with the first task if more loop iterations are required.
Delay-Before:
<1d1h1m1s1ms>
An additional delay before the sequence of tasks is executed. The delay is inserted in every job
iteration.
Delay-After:
<1d1h1m1s1ms>
An additional delay after the sequence of tasks is executed. The delay is inserted in every job
iteration.
Duration:
<1d1h1m1s1ms>
Minimum duration for the execution of the entire task sequence.. If the tasks can be executed faster
than the specified duration, an additional pause is inserted to ensure constant execution time.
Inc-AgentID:
<int>
(integer >= 0, optional)
If the parameter is defined (> 0), the agent IDs in the QTS tickets generated by the job are
Inc-ScenarioID:
<int>
If the parameter is defined (> 0), the scenario IDs in the QTS tickets generated by the job are
Inc-AgentID-Loop:
<int>
Additional agent ID increment applied for every job iteration. =0.0.13.2=

Inc-ScenarioID-Loop:
<int>
Additional scenario ID increment applied for every job iteration. =0.0.13.2=

NeedCIC:
<True/False/Yes/No>
This parameter can be used to skip the job execution. If the NeedCIC condition is true, the job or
sub-job is only executed if the internet connection specified by NeedCICID is active. If NeedCICID is
empty, the last dialed internet connection has to be active.
TSS 0.0.14.0 07.Nov.2011
75
Technical Reference
Please note that the parameter NeedCIC can only be used in sub-jobs, not in the main job.
NeedRAS:
<True/False/Yes/No>
This parameter can be used to skip the job execution. It is available for backward compatibility and
is a synonym for NeedCIC.
NeedCICID:
<CIC identifier>
(string, default: "")
This parameter is only used if NeedRAS or NeedCIC is true. If empty, the last dialed internet
connection is used, otherwise a special connection can be specified. The parameter has to be in form
<type>:<params>, e.g. RAS:<phonebook entry> or HwNd:<connection name>.
NeedRASEntry:
connection is used, otherwise a special RAS or CIC connection can be specified. The parameter can
contain a RAS phonebook entry or can be a full CIC identifier in form <type>:<params>.
User-*:
<any>
(string)
User defined parameters have to start with "user-", otherwise warnings will be generated. User
defined parameters can be used in any other parameter in any task or sub-job, e.g.
user-param1:
user-param2:
test
%user-param1%
5.3.5 Common task parameters

This section describes parameters that are valid for all TSS tasks.
Known parameters for all tasks
ID:
<id>
(string, optional)
An optional text identifier for the task. The identifier will be used in the user interface, log files and
the internal task storage. You can use this parameter to distinguish several tasks of the same type
within a job file.
Type:
<type>
(string)
This parameter defines the task type, allowed task types are:
Pause, Sub-Job, CIC-Connect, CIC-Hangup, RAS-Connect, RAS-Hangup, AT-Command,
PocketOptimizer, WebSpeedTest, Execute, TimeSync, Report, SubmitLogs, FileSync, Registration,
IPConfig, Route, GetPublicIP, Clean, Reboot.
Custom-TaskId:
<type>
(string)
Use this parameter to define a custom task ID for the QTS ticket. Default ask IDs are automatically
generated as j(loop).t<idx>(loop) where loop numbers are omitted if not required. Typical task IDs
are thus j(00).t02(00) or j.t02.j.t03 (for task in a sub job).
As the QTS dashboard automatically groups by task ID, user defined task IDs can be used to obtain
human readable descriptions for special tasks occurring more than once in a job. Please note that
task IDs have to be unique within a job, the following variables are available if required: =0.0.13.2=
o %TaskIndex% current task index (starting with 1)
o %JobLoop% current job iteration (starting with 1)
o %TaskLoop% current task iteration (starting with 1)
o %Parent-TaskId% parent task ID (for sub-jobs)
OnError:
<error>
(string, default:continue)
Defines the error behavior if the task fails:

o continue:
Job execution is continued.
o exit-task:
Execution of the current task's iterations is stopped and continued at the next
task.
o exit-jobloop: Execution of the current job iteration is stopped and continued with the next
job iteration.
o exit-job:
The entire job execution is stopped and continued with the next job.
o kill:
The execution of the entire job sequence is stopped.
Delay-Before:
<1d1h1m1s1ms>
An additional delay before the task is executed. The delay is inserted in every task iteration.
Delay-After:
<1d1h1m1s1ms>
An additional delay after the task is executed. The delay is inserted in every task iteration.
DelayUntil-Before:
<1d1h1m1s1ms>
(offset to scheduled time, optional)
Use this parameter to synchronize execution to a given time. If defined, an additional pause is
inserted after the pre-execution pause (i.e. after Delay-Before) until the given time (relative to the
TSS 0.0.14.0 07.Nov.2011
76
Technical Reference
scheduled time) is reached. A similar effect can be achieved by setting the parameter Duration for all
tasks before the current task, but synchronization to a given time can be configured in a single task.
=0.0.13.2=
Example:
scheduled time:
09:00:00 + 00:02:00
task start:
09:02:05
delay-before:
5s
-> delays until
09:02:10
delayuntil-before: 30s
-> target time
09:00:00 + 00:02:00 + 00:00:30 = 09:02:30
-> additional pause: 20s
DelayUntil-After:
<1d1h1m1s1ms>
(offset to scheduled time, optional)
Use this parameter to synchronize execution to a given time. If defined, an additional pause is
inserted after post-execution pause (i.e. after Delay-After) until the given time (relative to the
scheduled time) is reached. =0.0.13.2=
Duration:
<1d1h1m1s1ms>
Minimum duration for task execution. If the task can be executed faster than the specified duration,
an additional pause is inserted to ensure constant execution time. The duration is not executed if a
task is skipped due to conditions.
Exec-Estimation:
<1d1h1m1s1ms>
This parameter is used for the internal progress estimations. It should give the task execution time in
average situations to allow linear progress displays for average situations.
Timeout:
<1d1h1m1s1ms>
Hard timeout for the task execution. If the task execution for a single iteration (not including DelayBefore and Delay-After) exceeds the timeout, the task (and all sub-tasks or processes) are killed and
the task status is erroneous.
Inc-AgentID:
<int>
If the parameter is defined (> 0), the agent IDs in the QTS tickets generated by the task or sub jobs
are incremented by the given value. Please note that the increment is applied to RAS/CIC, MPSW
and measurement tickets, not to system tickets. Please refer to 4.9.3 for details. =0.0.13.2=
Inc-ScenarioID:
<int>
If the parameter is defined (> 0), the scenario IDs in the QTS tickets generated by the task or sub
jobs are incremented by the given value. Please note that the increment is applied to RAS/CIC,
Inc-AgentID-Loop:
<int>
Additional agent ID increment applied for every task iteration. =0.0.13.2=

Inc-ScenarioID-Loop:
<int>
Additional scenario ID increment applied for every task iteration. =0.0.13.2=

Loops:
<number of iterations>
More than one task iteration (i.e. repetition) can be specified if required. Please note that in case of
multiple iterations, the same scenario ID and execution ID, but different task IDs will be reported.
Max-Failures:
<number>
This parameter specifies the maximum number of consecutive failures until a reboot is required. A
value of 0 can be specified to indicate that no reboot shall be initiated. A value of 3 will result in a
machine reboot after the 4th consecutive error of the task. Please note that the reboot will be
initiated after the entire job is finished.
The status of all tasks (including the current and maximum failure count) can be viewed in the Tasks
tab and is dumped at the end of the execution log file.
Period:
<P1DT1H1M1S+O1DT1H1M1S>
(period, optional)
An additional period (e.g. PT1H) can be specified if the task shall be executed with lower frequency
than the job. Using this method, you can execute some tasks for example every 2 hours while the
other tasks (and the job) is executed every 15 minutes.
Please note that the task execution is only delayed if the last execution was successful. In case of a
task error, the task execution is not skipped.
Period-Persist:
<True/False/Yes/No>
If a period is used, this parameter defines if the last successful execution shall be persistent (i.e. be
preserved after a TSS restart). If a task is not persistent, TSS assumes it has not been executed
after a TSS restart and executes it in the first job execution after TSS startup. Persistent periods are
TSS 0.0.14.0 07.Nov.2011
77
Technical Reference
required e.g. for periodic reboots, where a job execution shall only be executed every 12 hours and
not every 12 hours and after every TSS startup. =0.0.12=
Condition:
<condition>
(string, optional)
It is possible to skip the task execution in dependency of a known condition. Currently the following
conditions are possible:
o HasPublicIp The task is only executed if a public IP address is available.
o NoPublicIp
The task is not executed if a public IP address is available.
o Failed(Prev)
The task is only executed if the previous task failed.
o FailedOrSkipped(Prev)
The task is executed if the previous task was skipped or failed.
o Succeeded(Prev)
The task is executed if the previous task succeeded.
o SucceededOrSkipped(Prev) The task is executed if the previous task was skipped or succd.
o ReportPending
The task is executed if reports have to be submitted.
Note: a task is only executed if the Condition and the NeedCIC (or NeedRAS) condition are true.
NeedCIC:
<True/False/Yes/No>
This parameter is another condition to skip task execution. If the NeedCIC condition is true, the task
is only executed if the internet connection specified by NeedCICID is active. If NeedCICID is empty,
the last dialed internet connection has to be active.
NeedRAS:
<True/False/Yes/No>
This parameter is another condition to skip task execution. It is available for backward compatibility
and is a synonym for NeedCIC.
NeedCICID:
<CIC identifier>
connection is used, otherwise a special connection can be specified. The parameter has to be in form
<type>:<params>, e.g. RAS:<phonebook entry> or HwNd:<connection name>.
NeedRASEntry:
connection is used, otherwise a special RAS or CIC connection can be specified. The parameter can
contain a RAS phonebook entry or can be a full CIC identifier in form <type>:<params>.
User-*:
<any>
(string)
User defined parameters have to start with "user-", otherwise warnings will be generated. User
defined parameters can be used in any other parameter, e.g.
user-param1:
user-param2:
test
%user-param1%
5.3.6 Task parameters for task Delay

The task Delay does not have additional parameters.
The desired delay is specified with the common task parameter Duration.
Known parameters for task Delay
Duration:
<1d1h1m1s1ms>
This is the same parameter as the default task parameter Duration. Usually this parameter will
specify the exact task duration. If, however, the task parameter Manage-Interfaces is set, the task
might require more time as the management server has to be commanded to establish a
management connection for the interface.
Manage-Interfaces:
<item>[,<item>...]
(string list, optional)
This parameter defines a list of interfaces that are allowed to be used by the TSS Assistance Service
to connect to the TSS Management Server.
Note: Per default the TSS Assistance Service is configured to use LAN interfaces for management
purposes but to avoid RAS/CIC interfaces. If such an interface shall be used for management, it has
to be enabled with a delay task.
Possible values are:
*
<entry>
<name>
RAS:*
HwNd:*
RAS:<entry>
HwNd:<entry>
...
...
...
...
...
...
...
TSS 0.0.14.0 07.Nov.2011
any custom internet connection dialed by TSS

phonebook entry for RAS connections
connection name for Huawei NDIS connections
any RAS connection dialed by TSS
any Huawei NDIS connection dialed by TSS
a specific RAS connection dialed by TSS
a specific Huawei NDIS connection dialed by TSS
78
Technical Reference
Manage-Estimation:
<1d1h1m1s1ms>
The estimated time required by the TSS Assistance Service and the communication timeout. The
default value is 1000ms.
Manage-Shutdown:
<True/False/Yes/No>
If this parameter is set to true, management by the TSS Assistance Service is revoked after the
specified delay. If set to false, management will not be terminated after task execution and the TSS
Assistance Service will use the interface until it is shut down or re-connected (e.g. in the next job
execution).
5.3.7 Task parameters for task Sub-Job

This section describes dedicated parameters for the task Sub-Job. Please note that common
parameters are available, too.
Known parameters for task Sub-Job
Job:
<file name>
(string)
Specifies the job file name to be executed including the extension (.tss-job). If the file name is
relative, it is located in the configuration path system/jobs.
Combined-Success:
(All/Any)
(list, default: All)
Determines the success or failure state of the Sub-Job task:

o All
The Sub-Job task is only considered successful if all sub-jobs are successful.
o Any
The Sub-Job task is considered successful, if at least one sub-job didn't fail.
5.3.8 Task parameters for task CIC-Connect

Note: The task CIC-Connect is the successor of RAS-Connect. The changed name shall indicate that
the task is able to manage different kinds of Custom Internet Connections. The task RAS-Connect is
however available for compatibility reasons and has been enhanced to support RAS and CIC
connections though not all functions and parameters of CIC-Connect are available.
The connection ID is specified with the parameter CIC-ConnID. It has to contain a fully qualified CIC
identifier in form <type>:<params>.
Use case 1: RAS entry in fully qualified form
CIC-ConnID:
RAS:RasConn01
Use case 2: Huawei NDIS connection in fully qualified form

CIC-ConnID:
CIC-User:
CIC-Password:
CIC-APN:

ppp@a1plus.at
ppp
a1.net
Please note that RAS connections usually do not require user name and password as it can be
contained in the RAS phonebook entry. Huawei NDIS connections require user name, password and
APN. Please refer to chapter 4.7 for details.
This section describes dedicated parameters for the task CIC-Connect. Please note that common
Known parameters for task 'CIC-Connect'
CIC-ConnID:
<type>:<params>
(string, mandatory)
The identifier of the custom internet connection in fully qualified form, i.e. <type>:<params>.
For RAS connections, the identifier is in form RAS:<entry>. The phonebook entry name can be found
in the Windows network connection list, please refer to chapter 4.7.2 for details.
For Huawei NDIS connections, the identifier is in form HwNd:<name>. The device name can be found in
the column device name in the Windows network connection list or in the Windows device manager,
please refer to chapter 4.7.2 for details. An asterisk (*) can be used as wildcard to define any HwNd
device (HwNd:*) or any HwNd device starting with the given text (HwNd:<name>*). =0.0.12=
CIC-Timeout:
<1d1h1m1s1ms>
Timeout to establish the internet connection. A connection attempt is cancelled after the timeout is
reached and a new retry is started. The maximum duration of the task is CIC-Timeout (1 + CICRetries).
CIC-Retries:
<int>
Maximum number of retries to establish an internet connection. The default value of 3 leads to a
maximum of 4 connection attempts (1 regular + 3 retries).
TSS 0.0.14.0 07.Nov.2011
79
Technical Reference
CIC-User:
<user name>
(string, optional)
Optional user name for the internet connection. If no user name and password is specified, the RAS
entries parameters are used. Non-RAS connections might require a user name in any case.
CIC-Password:
<password>
(string, optional)
Optional password for the internet connection. If no user name and password is specified, the RAS
entries parameters are used. Non-RAS connections might require a password in any case.
CIC-APN:
<apn>
(string, optional)
Optional APN for the internet connection. The parameter is required for NDIS connections. RAS
connections do not require this parameter as the APN is usually defined in the modem. If given for a
RAS connection, the custom init string at+cgdcont=1,"IP","<apn>" is applied to the modem before
the RAS connection is established.
CIC-APN-Method:
<method>:<params>
(string, optional)
Specifies the method to apply the APN. Possible methods are API and InitStr.
For NDIS connections the format is API:<param>, the default value is API:apn. If the method is given
in this form, the APN parameter value is applied to the API parameter param. There should not be a
requirement to set this parameter for NDIS connections.
For
RAS
connections
the
format
is
InitStr:<initstr>,
the
default
value
is
If given in this form, the APN is applied to the init string. If
additional commands shall be applied in the init string, they can be defined with this parameter. If
no init string shall be applied, the parameter can be set to "~".
InitStr:at+cgdcont=1,"IP","%apn%".
CIC-Ext-<param>
<value>
(string, optional)
Optional parameters for the NDIS driver. NDIS drivers might require additional parameters that can
be specified with these parameters. Currently no additional parameters are suppored.
HangupIfActive:
<True/False/Yes/No>
If this parameter is true, the internet connection will be terminated if active. Otherwise the existing
internet connection will be used, but the rating in the report ticket will be set to 0 as no
measurements are available.
HangupIfManaged:
<True/False/Yes/No>
If this parameter is true, the internet connection will not be terminated if the TSS Assistance Service
operates tunnel connections (such as for RDP, VNC etc). This means that the connection will be shut
down before connecting if it is not managed or just the management connection the TSS
Management Server is open. But if tunnel connections are active, the connection will not be closed
to keep the tunnel connections open.
DontHangup:
<True/False/Yes/No>
If this parameter is true, the internet connection will be kept open if no CIC-Hangup task is
executed. If the parameter is not specified, the connection will be terminated if the task terminates
(either on success or error). Please note that NDIS connections might always be terminated when
TSS is closed, depending on the API implementation.
FailIfMissing:
<True/False/Yes/No>
This parameter is only available for fallback jobs to ensure that the fallback job is executed even if
the internet connection is not available.
Scenario-ID:
<int>
The QTS scenario for the internet connection report ticket. If the parameter is 0, no ticket is
generated.
RateOnResponseOnly:
<True/False/Yes/No>
If this parameter is set to true, the ticket's rating will only be set to 1 if a connection attempt was
made AND the modem was responding to AT commands. Otherwise the rating will always be set to 1
if a connection attempt as made. The rating will always be set to 0 if an existing connection was
used. =0.0.12=
RateOnImsiImeiOnly:
<True/False/Yes/No>
If this parameter is set to true, the ticket's rating will only be set to 1 if both IMSI and IMEI are
valid. =0.0.12.7=
ClearMobileStatus:
<True/False/Yes/No>
If this parameter is true, the old content in the modem information storage will be cleared before
querying the modem information. Otherwise the old content will be maintained, but the validity
counter will be decremented by one.
TSS 0.0.14.0 07.Nov.2011
80
Technical Reference
QueryModemStatus:
<True/False/Yes/No>
If this parameter is true, the modem status is queried before the internet connection is established.
On success, the new information is stored in the modem information storage, otherwise the validity
QueryStatus-Timeout:
<1d1h1m1s1ms>
Timeout to query the modem status. If the status cannot be queried within the specified time, the
data is assumed to be invalid and the old data is kept as described above.
QueryStatus-ComPort:
<com>:<params>
(string, optional)
TSS automatically detects the COM port associated with a RAS entry or NDIS connection. This COM
port is used to query the modem status. If the automatic detection does not work or a different COM
port shall be used, use the parameter QueryStatus-ComPort to override it. =0.0.12.9=
Monitored:
<True/False/Yes/No>
Set this parameter to true to enable internet connection monitoring for this connection. Three
different monitoring modes are available:
o Connection monitoring: Passively monitors the NDIS or RAS connection using Windows API
calls. This method is always enabled if the parameter Monitored is true.
o ICMP monitoring: Actively monitors the connection by sending ICMP requests. This method is
only active if a host is specified with the parameter Test-ICMP-Host.
o AT command monitoring: the modem's status is queried periodically in a background thread.
This method requires an additional COM port to access the device during an active internet
connection. =0.0.13.5=
If connection monitoring is active, metrics m.1101..1129 are generated.
Test-ICMP-Host:
<IP or DNS name>
(string, optional)
Only required if Monitored is true. Specifies the IP address or host name to send ICMP ECHO
requests to. If the parameter is empty, ICMP monitoring is not used.
If ICMP monitoring is active, metrics m.1151..1179 are generated.
Test-ICMP-Period:
<1d1h1m1s1ms>
Period of ICMP bursts sent to the host (time from start of one burst to start of next burst).
Test-ICMP-Advance:
<1d1h1m1s1ms>
Time increment from on ICMP ECHO request transmission to the next within a burst..
Test-ICMP-Timeout:
<1d1h2m1s1ms>
Receive timeout for single request.

Test-ICMP-TxCount:
<int>
Number of ICMP ECHO requests to be sent per burst.

Test-ICMP-FailCount:
<int>
Number of consecutive packets to be lost to treat the RAS connection as dropped.

Test-ICMP-Size:
<int>
<True/False/Yes/No>
ICMP payload size in bytes.

WatchModemStatus:
Set this parameter to true to enable AT command monitoring (only if Monitored is true). If enabled,
a background thread will be started that periodically queries the modem and network status. If AT
command monitoring is active, metrics m.1200..1219 are generated. =0.0.13.5=
WatchStatus-ComPort:
<com>:<params>
(string, optional)
TSS automatically detects the secondary COM port for known devices (please refer to the description
of the MobilePorts sections in the modem configuration file). If automatic detection does not work or
a different COM port shall be used, the parameter WatchStatus-ComPort can be used to override it.
=0.0.13.5=
WatchStatus-CommandTimeout: <1d1h2m1s1ms>
Defines the timeout for a single AT command in the background thread. =0.0.13.5=
WatchStatus-Interval:
<1d1h2m1s1ms>
Defines the query interval for the background thread. Modem and network status is queried once per
query interval. =0.0.13.5=
UsePacketSniffer:
(True/False/Yes/No)
Start a packet sniffer for the current internet connection. Please note that UsePacketSniffer and
Sniffer-Enabled both have to be true to enable the packet sniffer. =0.0.13.6=
Sniffer-Type:
(string, optional)
TSS 0.0.14.0 07.Nov.2011
81
Technical Reference
o NetCap
o NMCap
o TShark
Sniffer-Tool:

<exe-file>
(string, optional)

Sniffer-Args:
<args>
(string, optional)
NetCap:
NMCap:
TShark:

Shrink-Type:
(TShark)
(string, optional)
=0.0.13.6=
Shrink-Tool:
<exe-file>
(string, optional)
Shrink-Args:
<args>
(string, optional)
Sniffer-Connection:
<type>:<id>
(string, optional)

o <empty>
o CIC
o NIC:<dev>
o CAP:<id>
Sniffer-Enabled:
(True/False/Yes/No)
Sniffer-TruncBytes:
<bytes>
(integer, optional)
o IP header
20 bytes
Sniffer-TruncMode:

o None
o ShrinkCap
o ShrinkAdd
Sniffer-BufferSize:
<MB>
(integer, optional)
Sniffer-Compress:
(True/False/Yes/No)
Sniffer-Submit:
TSS 0.0.14.0 07.Nov.2011
82
Technical Reference
o
o
o
o
Never
OnError
OnWarning
Always

Sniffer-MaxErrors:
<int>
Sniffer-AddLog:
(True/False/Yes/No)
SetNDISInterfaceMetric:
<int>
(integer, optional)
Use this parameter to set an NDIS interface's (routing) metric to a given value. This function can be
used to prefer the interface over other interfaces in the system. If, for example, all LAN interfaces
are set to a metric of 50, NDIS interfaces can be preferred if setting their metric to a lower metric
(e.g. 20). Note: the metric value is stored as user defined value in the system registry. =0.0.12.7=
ForceNDISDefaultMetric:
<int>
(integer, optional)
In some situations Windows 7 ignores the interface metric defined for NDIS dial-up interfaces. Use
this parameters to reduce the interface's default metric to the given value after the connection has
been initiated. If defined and less than the actual value, TSS removes the default gateway item for
the current interface from the routing table and creates a new one with the given metric. Please
note that this will fail if the metric is too low as Windows 7 does not allow route metrics less than the
interface metric (typically 20 for 3G data modems). =0.0.13.1=
5.3.9 Task parameters for task CIC-Hangup

Note: The task CIC-Hangup is the successor of RAS-Hangup. The changed name shall indicate that
the task is able to manage different kinds of Custom Internet Connections. The task RAS-Hangup is
however available for compatibility reasons and has been enhanced to support RAS and CIC
connections though not all functions and parameters of CIC-Hangup are available.
This section describes dedicated parameters for the task CIC-Hangup. Please note that common
Known parameters for task CIC-Hangup
CIC-ConnID:
<type>:<params>
(string, mandatory)
The identifier of the custom internet connection in fully qualified form, i.e. <type>:<params>.
For RAS connections, the identifier is in form RAS:<entry>. The phonebook entry name can be found
in the Windows network connection list, please refer to chapter 4.7.2 for details.
For Huawei NDIS connections, the identifier is in form HwNd:<name>. The device name can be found in
the column device name in the Windows network connection list or in the Windows device manager,
please refer to chapter 4.7.2 for details. An asterisk (*) can be used as wildcard to define any HwNd
device (HwNd:*) or any HwNd device starting with the given text (HwNd:<name>*). =0.0.12=
HangupIfManaged:
<True/False/Yes/No>
down if it is not managed or just the management connection the TSS Management Server is open.
But if tunnel connections are active, the connection will not be closed to keep the tunnel connections
open.
DontHangup:
<True/False/Yes/No>
If this parameter is true, the internet connection will be kept open, i.e. the Hangup-Task is ignored.
UsePacketSniffer:
(True/False/Yes/No)
Stop the packet sniffer associated with the internet connection. Please note that a running packet
sniffer is automatically stopped if this parameter is not explicitly set to false. =0.0.13.6=
5.3.10 Task parameters for task RAS-Connect

Note: The task RAS-Connect is deprecated and available for compatibility with old jobs. New
installations should use the task CIC-Connect. To allow for easy migration to NDIS connections, the
RAS tasks support non-RAS connection identifiers, too.
Use case 1: just RAS entry, no prefix (compatibility to TSS 0.0.10.x and before)
Ras-Entry:
RasConn01
TSS 0.0.14.0 07.Nov.2011
83
Technical Reference
Use case 2: RAS entry in fully qualified form

Ras-Entry:
RAS:RasConn01
Use case 3: Huawei NDIS connection in fully qualified form

Ras-Entry:
Ras-User:
Ras-Password:
Ras-APN:

ppp@a1plus.at
ppp
a1.net
Please note that RAS connections usually do not require user name and password as it can be
contained in the RAS phonebook entry. Huawei NDIS connections require user name, password and
APN. Please refer to chapter 4.7 for details.
This section describes dedicated parameters for the task RAS-Connect. Please note that common
Known parameters for task 'RAS-Connect'
RAS-Entry:
(string, mandatory)
The name of the RAS connection in the Windows RAS phonebook or a fully qualified CIC ID.
The phonebook name can be found in the Windows network connections list. The specified
connection must exist.
A CIC ID has to be in form <type>:<params>, e.g. RAS:<entry> or HwNd:<name>. Please refer to
chapter 4.7.2 for details. An asterisk (*) can be used as wildcard to define any HwNd device
(HwNd:*) or any HwNd device starting with the given text (HwNd:<name>*). =0.0.12=
RAS-Timeout:
<1d1h1m1s1ms>
Timeout to establish the RAS connection. A connection attempt is cancelled after the timeout is
reached and a new retry is started. The maximum duration of the task is RAS-Timeout (1 + RASRetries).
RAS-Retries:
<int>
Maximum number of retries to establish a RAS connection. The default value of 3 leads to a
maximum of 4 connection attempts (1 regular + 3 retries).
RAS-User:
<user name>
(string, optional)
Optional user name for the RAS connection. If no user name and password is specified, the RAS
entries parameters are used. Non-RAS connections might require a user name in any case.
RAS-Password:
<password>
(string, optional)
Optional password for the RAS connection. If no user name and password is specified, the RAS
entries parameters are used. Non-RAS connections might require a password in any case.
RAS-APN:
<apn>
(string, optional)
Optional APN for the RAS connection. The parameter has been added as it is required for NDIS
connections. RAS connections do not require this parameter as the APN is usually defined in the
modem. If given for a RAS connection, the custom init string at+cgdcont=1,"IP","<apn>" is applied
to the modem before the RAS connection is established.
RAS-InitString:
<AT-command>
(string, optional)
Optional RAS initialization string to be written to the modem associated with the RAS connection. If
the value is empty, the parameter is not changed, otherwise any value can be specified or use the
tilde (~) to clear an existing command. This parameter overrides RAS-APN if both parameters are
specified.
HangupIfActive:
<True/False/Yes/No>
If this parameter is true, the RAS connection will be terminated if active. Otherwise the existing RAS
connection will be used, but the rating in the report ticket will be set to 0 as no measurements are
available.
HangupIfManaged:
<True/False/Yes/No>
down before connecting if it is not managed or just the management connection the TSS
Management Server is open. But if tunnel connections are active, the connection will not be closed
to keep the tunnel connections open.
DontHangup:
<True/False/Yes/No>
If this parameter is true, the RAS connection will be kept open if no RAS-Hangup task is executed. If
the parameter is not specified, the connection will be terminated if the task terminates (either on
success or error).
TSS 0.0.14.0 07.Nov.2011
84
Technical Reference
FailIfMissing:
<True/False/Yes/No>
This parameter is only available for fallback jobs to ensure that the fallback job is executed even if
the RAS connection is not available.
Scenario-ID:
<int>
The QTS scenario for the RAS connection report ticket. If the parameter is 0, no ticket is generated.
RateOnResponseOnly:
<True/False/Yes/No>
If this parameter is set to true, the ticket's rating will only be set to 1 if a connection attempt was
made AND the modem was responding to AT commands. Otherwise the rating will always be set to 1
if a connection attempt as made. The rating will always be set to 0 if an existing connection was
used. =0.0.12=
RateOnImsiImeiOnly:
<True/False/Yes/No>
If this parameter is set to true, the ticket's rating will only be set to 1 if both IMSI and IMEI are
valid. =0.0.12.7=
ClearMobileStatus:
<True/False/Yes/No>
If this parameter is true, the old content in the modem information storage will be cleared before
querying the modem information. Otherwise the old content will be maintained, but the validity
QueryModemStatus:
<True/False/Yes/No>
If this parameter is true, the modem status is queried before the RAS connection is established. On
success, the new information is stored in the modem information storage, otherwise the validity
QueryStatus-Timeout:
<1d1h1m1s1ms>
Timeout to query the modem status. If the status cannot be queried within the specified time, the
data is assumed to be invalid and the old data is kept as described above.
QueryStatus-ComPort:
<com>:<params>
(string, optional)
TSS automatically detects the COM port associated with a RAS entry or NDIS connection. This COM
port is used to query the modem status. If the automatic detection does not work or a different COM
port shall be used, use the parameter QueryStatus-ComPort to override it. =0.0.12.9=
Monitored:
<True/False/Yes/No>
Set this parameter to true to enable RAS connection monitoring for this connection. Three different
monitoring modes are available:
o RAS monitoring: Passively monitors the RAS connection using Windows API calls. This method
is always enabled if the parameter Monitored is true.
o ICMP monitoring: Actively monitors the RAS connection by sending ICMP requests. This
method is only active if a host is specified with the parameter Test-ICMP-Host.
o AT command monitoring: the modem's status is queried periodically in a background thread.
This method requires an additional COM port to access the device during an active internet
connection. =0.0.13.5=
Test-ICMP-Host:
<IP or DNS name>
(string, optional)
Only required if Monitored is true. Specifies the IP address or host name to send ICMP ECHO
requests to. If the parameter is empty, ICMP monitoring is not used.
Test-ICMP-Period:
<1d1h1m1s1ms>
Period of ICMP bursts sent to the host (time from start of one burst to start of next burst).
Test-ICMP-Advance:
<1d1h1m1s1ms>
Time increment from on ICMP ECHO request transmission to the next within a burst..
Test-ICMP-Timeout:
<1d1h2m1s1ms>
Receive timeout for single request.

Test-ICMP-TxCount:
<int>
Number of ICMP ECHO requests to be sent per burst.

Test-ICMP-FailCount:
<int>
Number of consecutive packets to be lost to treat the RAS connection as dropped.

Test-ICMP-Size:
<int>
<True/False/Yes/No>
ICMP payload size in bytes.

WatchModemStatus:
Set this parameter to true to enable AT command monitoring (only if Monitored is true). If enabled,
a background thread will be started that periodically queries the modem and network status
=0.0.13.5=
TSS 0.0.14.0 07.Nov.2011
85
Technical Reference
WatchStatus-ComPort:
<com>:<params>
(string, optional)
TSS automatically detects the secondary COM port for known devices (please refer to the description
of the MobilePorts sections in the modem configuration file). If automatic detection does not work or
a different COM port shall be used, the parameter WatchStatus-ComPort can be used to override it.
=0.0.13.5=
WatchStatus-CommandTimeout: <1d1h2m1s1ms>
Defines the timeout for a single AT command in the background thread. =0.0.13.5=
WatchStatus-Interval:
<1d1h2m1s1ms>
Defines the query interval for the background thread. Modem and network status is queried once per
query interval. =0.0.13.5=
UsePacketSniffer:
(True/False/Yes/No)
Start a packet sniffer for the current RAS connection. Please note that UsePacketSniffer and SnifferEnabled both have to be true to enable the packet sniffer. =0.0.13.6=
Sniffer-Type:
(string, optional)
o NetCap
o NMCap
o TShark
Sniffer-Tool:
<exe-file>
(string, optional)

Sniffer-Args:
<args>
(string, optional)
NetCap:
NMCap:
TShark:

Shrink-Type:
(TShark)
(string, optional)
=0.0.13.6=
Shrink-Tool:
<exe-file>
(string, optional)
Shrink-Args:
<args>
(string, optional)
Sniffer-Connection:
<type>:<id>
(string, optional)

o <empty>
o CIC
o NIC:<dev>
o CAP:<id>
Sniffer-Enabled:
(True/False/Yes/No)
Sniffer-TruncBytes:
<bytes>
(integer, optional)
o IP header
20 bytes
Sniffer-TruncMode:

o None
TSS 0.0.14.0 07.Nov.2011
86
Technical Reference
o ShrinkCap
o ShrinkAdd
Sniffer-BufferSize:
<MB>
(integer, optional)
Sniffer-Compress:
(True/False/Yes/No)
Sniffer-Submit:
o Never
o OnError
o OnWarning
o Always
Sniffer-MaxErrors:
<int>
Sniffer-AddLog:
(True/False/Yes/No)
SetNDISInterfaceMetric:
<int>
(integer, optional)
Use this parameter to set an NDIS interface's (routing) metric to a given value. This function can be
used to prefer the interface over other interfaces in the system. E.g. if all LAN interfaces are set to a
metric of 50, NDIS interfaces can be preferred if setting their metric to a lower metric (e.g. 10).
=0.0.12.7=
ForceNDISDefaultMetric:
<int>
(integer, optional)
In some situations Windows 7 ignores the interface metric defined for NDIS dial-up interfaces. Use
this parameters to reduce the interface's default metric to the given value after the connection has
been initiated. If defined and less than the actual value, TSS removes the default gateway item for
the current interface from the routing table and creates a new one with the given metric. Please
note that this will fail if the metric is too low as Windows 7 does not allow route metrics less than the
interface metric (typically 20 for 3G data modems). =0.0.13.1=
5.3.11 Task parameters for task RAS-Hangup

Note: The task RAS-Hangup is deprecated and available for compatibility with old jobs. New
installations should use the task CIC-Hangup. To allow for easy migration to NDIS connections, the
RAS tasks support non-RAS connection identifiers, too.
This section describes dedicated parameters for the task RAS-Hangup. Please note that common
Known parameters for task RAS-Hangup
RAS-Entry:
(string, mandatory)
The name of the RAS connection in the Windows RAS phonebook or a fully qualified CIC ID.
The phonebook name can be found in the Windows network connections list. The specified
connection must exist.
A CIC ID has to be in form <type>:<params>, e.g. RAS:<entry> or HwNd:<name>. Please refer to
chapter 4.7.2 for details.
HangupIfManaged:
<True/False/Yes/No>
down if it is not managed or just the management connection the TSS Management Server is open.
But if tunnel connections are active, the connection will not be closed to keep the tunnel connections
open.
DontHangup:
<True/False/Yes/No>
If this parameter is true, the internet connection will be kept open, i.e. the Hangup-Task is ignored.
TSS 0.0.14.0 07.Nov.2011
87
Technical Reference
UsePacketSniffer:
(True/False/Yes/No)
Stop the packet sniffer associated with the internet connection. Please note that a running packet
sniffer is automatically stopped if this parameter is not explicitly set to false. =0.0.13.6=
5.3.12 Task parameters for task AT-Command

This section describes dedicated parameters for the task AT-Command. Please note that common
Known parameters for task AT-Command
CIC-ConnID:
<type>:<connection ID>
(string, optional)
The identifier of a custom internet connection. If possible, TSS uses the COM port assigned to the
RAS modem or NDIS connection. The COM port must not be used by RAS or any other process when
the AT-Command task is executed.
RAS-Entry:
(string, optional)
The name of the RAS connection in the windows RAS phonebook or the network connections. The
specified connection must exist. TSS uses the COM port assigned to the modem associated with the
RAS connection. The COM port must not be connected by RAS or any other process when the ATCommand task is executed.
COM-Port:
<COM port>
(string, optional)
The COM port to be used, e.g. COM12. The COM port must not be connected by RAS or any other
process when the AT-Command task is executed.
AT-Command-00:
<AT command>
(string)
First AT command to be executed. The command can either be a native command or a virtual
command defined in the file mobiles.cfg. Please refer to section xxxxx for details.
AT-Command-01..99:
<AT command>
(string)
Other AT commands to be executed.

AT-Single-Timeout:
<1d1h1m1s1ms>
Timeout for a single AT command.

AT-Retries:
<num retries>
Number of retries for the entire sequence of commands (of one command fails due to result code or
timeout).
AT-Continue:
(True/False/Yes/No)
If this parameter is true, all AT commands are executed, even if a command fails. If the parameter is
false, execution is stopped after an erroneous command and a retry is started for the entire
sequence.
LogCommunication:
(True/False/Yes/No)
If this parameter is true, the communication with the modem is added to the execution log.
Requirements
Exactly one of the parameters CIC-ConnID, RAS-Entry or COM-Port has to be specified.
5.3.13 Task parameters for task CheckModem

This section describes dedicated parameters for the task CheckModem. Please note that common
parameters are available, too. =0.0.12.6=
Known parameters for task CheckModem
CIC-ConnID:
<type>:<connection ID>
(string, optional)
The identifier of a custom internet connection. If possible, TSS uses the COM port assigned to the
RAS modem or NDIS connection. The COM port must not be used by RAS or any other process when
the CheckModem task is executed. =0.0.12.6=
RAS-Entry:
(string, optional)
The name of the RAS connection in the windows RAS phonebook or the network connections. The
specified connection must exist. TSS uses the COM port assigned to the modem associated with the
RAS connection. The COM port must not be connected by RAS or any other process when the
CheckModem task is executed. =0.0.12.6=
COM-Port:
<COM port>
(string, optional)
The COM port to be used, e.g. COM12. The COM port must not be connected by RAS or any other
process when the CheckModem task is executed. =0.0.12.6=
TSS 0.0.14.0 07.Nov.2011
88
Technical Reference
AT-Single-Timeout:
<1d1h1m1s1ms>
Timeout for a single AT command. =0.0.12.6=

AT-Retries:
<num retries>
Number of retries for the entire sequence of commands. =0.0.12.6=

WaitOnly:
(True/False/Yes/No)
Assume the modem has recently been turned off and on. Thus only wait for modem to be available
and registered, don't issue another power cycle if failing. =0.0.13.0=
ForceCheck:
(True/False/Yes/No)
Always check the mobile status, even if AlwaysReset is set to true. =0.0.12.6=
ResetIfNoNetwork:
(True/False/Yes/No)
Reset mobile with MPSW if no network registration is available. =0.0.12.6=

ForceReset:
(True/False/Yes/No)
Always reset mobile with MPSW, don't care for current status. =0.0.12.6=
ForceReboot:
(True/False/Yes/No)
Always reboot instead of MPSW cycle. =0.0.12.6=

DeviceTimeout:
<1d1h1m1s1ms>
Timeout for device and COM port to be established after MPSW cycle. =0.0.12.6=
RebootOnFailure:
(True/False/Yes/No)
Reboot if device or COM port does not re-appear after MPSW cycle. =0.0.12.6=
RegistrationTimeout:
<1d1h1m1s1ms>
Timeout for network registration after COM port is available. =0.0.12.6=

Scenario-ID:
<cid>[:<tid>]
(string, optional)
Scenario ID for dedicated ticket. If specified, a ticket is always generated per task execution
(regardless if an MPSW cycle was required or not). This does not affect the generation of MPSW
tickets after an MPSW cycle with the scenario ID defined in CID-MPSW. =0.0.12.8=
AltRebootMode:
<None/Win/Soft/Auto/Safe/Hard> (string, optional)
Use this parameter to define an alternate reboot mode if the modem power cycle fails. =0.0.12.8=
UseExternalTool:
(True/False/Yes/No)
Set this parameter to true to force or disable the use of an external MPSW tool. =0.0.12.8=
ExternalToolName:
<file>
(string, optional)
Use this parameter to define an alternate external MPSW tool. The default tool is define in the
[Tools] section in the application config file. =0.0.12.8=
ImmediateShutdown:
(True/False/Yes/No)
If this parameter is set to true, an alternate reboot is executed immediately. =0.0.12.8=

RebootTimeout:
<1d1h1m1s1ms>
Timeout for communication with TSS Assistance Service. =0.0.12.8=
5.3.14 Task parameters for task PocketOptimizer

This section describes dedicated parameters for the task PocketOptimizer. Please note that common
Known parameters for task PocketOptimizer
Job:
<file.PO-job>
(string, mandatory)
The job file for PocketOptimizer including the extension (.PO-job). If the file name is relative, it is
located in the configuration path system/jobs/PO.
AppFileName:
<file.exe>
(string, optional)
This parameter overrides the tool configuration in Application.cfg. If the file name is relative, it is
located in the configuration directory system/apps. If the parameter is not specified, the executable
file name in for the tool named PocketOptimizer in Application.cfg is used.
Arguments:
<args>
(string, optional)
Additional command line arguments for PockerOptimizer can be specified if required.

AddCICMetrics:
(True/False/Yes/No)
Set this parameter to true to add CIC metrics (mobile and cell information, connection IP address) to
the XML reports created by PocketOptimizer.
AddRASMetrics:
(True/False/Yes/No)
Set this parameter to true to add RAS metrics (Mobile information, connection IP address) to the
XML reports created by PocketOptimizer. The parameter is equal to AddCICMetrics.
TSS 0.0.14.0 07.Nov.2011
89
Technical Reference
AddCICMetricConnID:
<type>:<Conn ID>
(string, optional)
This parameter is only used if AddCICMetrics is true. If empty, the last dialed internet connection is
used, otherwise a special internet connection can be specified.
AddRASMetricEntry:
(string, optional)
used, otherwise a special RAS connection can be specified.
AutoBaseDir:
(True/False/Yes/No)
If this parameter is set, the default directory for execution is set to the application directory instead
of the working directory of TSS.
ReducePrivileges:
(True/False/Yes/No)
If this parameter is set to true, the privileges of the executed task are set to non-privileged,
otherwise it is executed with full admin rights. This behavior is only available in Windows Vista or 7
with active UAC. The default value for PocketOptimizer and WebSpeedTest is true as these
application don't require admin rights and to improve system security.
5.3.15 Task parameters for task WebSpeedTest

This section describes dedicated parameters for the task WebSpeedTest. Please note that common
Known parameters for task WebSpeedTest
URL:
<url>
(string, mandatory)
The URL to be downloaded with WebSpeedTest.

Scenario-ID:
<int>
(integer, default 0)
The scenario ID for the XML report created by WebSpeedTest. If 0, only log files but no XML report
will be created.
NoLogParams:
(True/False/Yes/No)
If this parameter is true, the default log file command line arguments will not be added to
WebSpeedTest's command line. In this case specific log file arguments can be provided in the
parameter Arguments.
AppFileName:
<file.exe>
(string, optional)
This parameter overrides the tool configuration in Application.cfg. If the file name is relative, it is
located in the configuration directory system/apps. If the parameter is not specified, the executable
file name in for the tool named WebSpeedTest in Application.cfg is used.
Arguments:
<args>
(string)
Additional command line arguments for WebSpeedTest can be specified if required.

AddCICMetrics:
(True/False/Yes/No)
AddRASMetrics:
(True/False/Yes/No)
AddCICMetricConnID:
<type>:<Conn ID>
(string, optional)
AddRASMetricEntry:
(string, optional)
AutoBaseDir:
(True/False/Yes/No)
of the working directory of TSS.
ReducePrivileges:
(True/False/Yes/No)
with active UAC. The default value for PocketOptimizer and WebSpeedTest is true as these
application don't require admin rights and to improve system security.
DontCheckReboot:
(True/False/Yes/No)
If this parameter is set to true, ===REBOOT messages from the tool are ignored. =0.0.12=
TSS 0.0.14.0 07.Nov.2011
90
Technical Reference
5.3.16 Task parameters for task Execute

This section describes dedicated parameters for the task Execute. Please note that common
Known parameters for task Execute
Tool:
<name>
(string)
The tool name as specified in the configuration file Applications.cfg. If the parameter is specified, the
corresponding entry in the application configuration file is used to determine the executable file
name.
AppFileName:
<file.exe>
(string)
If the parameter Tool is not used or the tool is not registered in Applications.cfg, this parameter can
be used to specify the executable file name directly. If the file name is not absolute, it has to be
relative to the configuration path %system\apps%, except if it starts with the prefix ~\. In this case,
the file name is not expanded and will be searched in the Windows search path.
ArgumentRule:
<rule>
(string, optional)
The argument rule can be used to automatically create the command line arguments from the
parameters ScriptFileName and Arguments. The argument rule can contain the placeholders $script$
and $args$ and any other text arguments. The output of the argument rule will be appended to the
application file name to generate the entire command line. If the parameter Tool is specified, the
argument rule can be fetched from the application configuration file.
Examples for argument rules for cmd.exe and perl are:
/c $script$ $args$
$script$ $args$
ScriptFileName:
<file.ext>
(string, optional)
This parameter can be used in conjunction with parameter ArgumentRule to allow tool execution just
with one of the following parameter combinations:
o Tool, ScriptFileName (ArgumentRule fetched from Application.cfg)
o AppFileName, ArgumentRule, ScriptFileName
Arguments:
<args>
(string, optional)
This parameter can either contain the entire command line (if Tool and AppFileName are not
specified), additional arguments for the argument rule (if specified or derived from the application
configuration file) or just the arguments for the executable file name.
SetEnvironment:
(True/False/Yes/No)
If this parameter is set to true, the environment of TSS and the system and user defined variables
will be set in the environment of the executed process.
UseShellExec:
(True/False/Yes/No)
If this parameter is set to true, the ShellExecute method will be used to create the process instead
of the CreateProcess method. ShellExecute can be used for data files, too, Windows will
automatically search the registered application for the file in this case. ShellExecute however does
not provide support for console redirection.
UseRedirect:
(True/False/Yes/No)
If this parameter is set to true, the console output (stdout and stderr) from the called process will be
directed to TSS. TSS will monitor special messages (===STATUS, ===ERROR, ===WARNING, ===PROGRESS)
and display the messages in the execution log.
UseResponseFile:
(True/False/Yes/No)
If this parameter is set to true, the executed process is assumed to write the messages to the
response file instead of the console output. The console file name is given by TSS and can be
accessed with the system defined variables %TempPath%\%ResponseFile%. The file name has to be
passed to the called process either with user defined command line arguments or by environment
variables (SetEnvironment switch).
UseControlFile:
(True/False/Yes/No)
If this parameter is set to true, the executed process is assumed to terminate if the control file is
created by TSS. The control file name is given by TSS and can be accessed with the system defined
variables %TempPath%\%ControlFile%. The file name has to be passed to the called process either with
user defined command line arguments or by environment variables (SetEnvironment switch).
UseHistoryFile:
(True/False/Yes/No)
If this parameter is set to true, a history file containing the log and report file names of all previously
executed tasks is created for the executed process. The tool can use the history file to locate these
TSS 0.0.14.0 07.Nov.2011
91
Technical Reference
files and extract information. The file name is given by TSS and can be accessed with the system
defined variables %TempPath%\%HistoryFile%. The file name has to be passed to the called process
either with user defined command line arguments or by environment variables (SetEnvironment
switch).
DontCheckAppFile:
(True/False/Yes/No)
If this parameter is set to true, TSS does not check if the tool file exists. This can be useful if the tool
is located in the Windows search path or the ShellExecute method is used for a script file.
DontCheckExitCode:
(True/False/Yes/No)
If this parameter is set to true, TSS does not check the tool's exit code (error level). Otherwise a tool
failure will be assumed if the exit code is different to 0.
DontNeedReportFile:
(True/False/Yes/No)
If this parameter is set to true, TSS does not expect the tool to create a report file. Otherwise an
XML report has to be created by the tool, a tool failure is assumed if it does not exist. The file name
for the report is given by TSS, it can be accessed with the system defined variables
%ReportPath%\%ReportFile%.
DontAddToHistoryFile:
(True/False/Yes/No)
If this parameter is set to true, the files created by the tool are not added to the history file.
AddCICMetrics:
(True/False/Yes/No)
AddRASMetrics:
(True/False/Yes/No)
AddCICMetricConnID:
<type>:<Conn ID>
(string, optional)
AddRASMetricEntry:
(string, optional)
DeleteResponseFile:
(True/False/Yes/No)
If this parameter is set to false, the response file created by the tool is not deleted automatically.
AutoBaseDir:
(True/False/Yes/No)
of the working directory of TSS. This parameter is not available if shell execution is used.
ReducePrivileges:
(True/False/Yes/No)
with active UAC. The default value is false to maintain compatibility to Windows XP.
DontCheckReboot:
(True/False/Yes/No)
If this parameter is set to true, ===REBOOT messages from the tool are ignored. =0.0.12=
5.3.17 Task parameters for task TimeSync

This section describes dedicated parameters for the task TimeSync. Please note that common
Please refer to the configuration parameters Sync-Enable, Sync-AllowDefault and Sync-Groups for
details.
Known parameters for task TimeSync
TimeSync-Method:
exec or http-gettime
(string, default exec)
Defines the time synchronization method to be used. The parameter can be used to override the
default setting in the configuration parameter [Methods].TimeSync-Method.
o exec ... use external SNTP client
o http-gettime ... use internal HTTP client and get-time request
GetTime-Server:
<url>
(string)
This parameter is only used if method is http-gettime. It can be used to override the default setting
in the configuration parameter [Communication].GetTime-Server. The QTS Ticket Receiver and Relay
support the get-time request, the URL should be in form http://server/get-time.
TSS 0.0.14.0 07.Nov.2011
92
Technical Reference
AppFileName:
<file.exe>
(string)
This parameter is only used if method is exec. It overrides the tool configuration [Tools].SNTP-Tool
in Application.cfg. If the file name is relative, it is located in the configuration directory system/apps.
NumRetries:
<int>
Only used if method is http-gettime. Number or retries for a single HTTP request to the public IP
server.
Timeout:
<1d1h1m1s1ms>
Timeout for a single HTTP request to the time server (if method is http-gettime) or for execution of
external sync tool (if method is exec).
Sync-Forced:
(True/False/Yes/No)
This parameter is only required if the configuration parameter Sync-Enabled is set to forced. In this
case synchronization is only allowed if a job is executed manually and the synchronization task's
Sync-Forced parameter is true. =0.0.13.1=
5.3.18 Task parameters for task Report

This section describes additional parameters for the task Report.
Known parameters for task Report
MaxFiles:
<int>
Maximum number of report files to be submitted per task execution. The youngest report files are
submitted first, this parameter can be used to limit the execution time of the reporting task.
MaxDuration:
<1d1h1m1s1ms>
(duration, default: 5m)
Maximum time duration to start another submission of an XML report. The youngest report files are
submitted first, no further files are submitted after the maximum duration is reached. To avoid
additional error messages, the task's timeout should be larger than MaxDuration + HttpTimeout.
Report-Server:
<QTS url>
(string, optional)
The URL of the report server (QTS ticket receiver or relay). Usually this parameter is not required
and the URL is fetched from the system configuration file.
Report-Instance:
<QTS instance>
(string, optional)
The database instance name for the report server (QTS ticket receiver ore relay). Usually this
parameter is not required and the URL is fetched from the system configuration file.
Report-TIC:
<QTS TIC>
(integer, optional)
The ticket identification code for the report server (QTS ticket receiver or relay). Usually this
parameter is not required and the TIC is fetched from the system configuration file.
NumRetries:
<int>
Maximum number of submission attempts for a single report file. If the submission of a file is not
possible after the specified number of attempts, the file is moved to the error output directory and
no further submission attempts for this file will be started. Please note that submission attempts
without server reaction are not counted as failure, i.e. no report files are dropped if the report server
does not respond.
HttpTimeout:
<1d1h1m1s1ms>
Timeout for a single HTTP transfer. Please note that this is the entire timeout from the connection of
the TCP socket to the reception of the HTTP status code. The timeout has to be large enough to
allow transmission of the larges XML report files over the slowest possible connection.
5.3.19 Task parameters for task SubmitLogs

This section describes dedicated parameters for the task SubmitLogs. Please note that common
Known parameters for task SubmitLogs
MaxFiles:
<int>
Maximum number of report files to be submitted per task execution. The youngest files are
submitted first, this parameter can be used to limit the execution time of the reporting task.
MaxDuration:
<1d1h1m1s1ms>
Maximum time duration to start another submission of a files. The youngest files are submitted first,
no further files are submitted after the maximum duration is reached. To avoid additional error
messages, the task's timeout should be larger than MaxDuration + FtpTimeout.
TSS 0.0.14.0 07.Nov.2011
93
Technical Reference
Log-Server:
<FTP url>
(string, optional)
URL of the FTP server to load the files onto. Usually this parameter is not required and the URL is
fetched from the system configuration file. The parameter %agentid% in the URL is replaced by the
agent ID provided in the registration data.
Log-User:
<FTP user name>
(string, optional)
FTP user name for the log server. Usually this parameter is not required and the user name is
fetched from the system configuration file.
Log-Pass:
<FTP password>
(string, optional)
FTP password for the log server. Usually this parameter is not required and the user name is fetched
from the system configuration file.
Log-Passive:
(True/False/Yes/No)
Set this parameter to true to use passive mode. If not defined, the corresponding parameter from
the system configuration file is used.
NumRetries:
<int>
Maximum number of submission attempts for a single file. If the submission of a file is not possible
after the specified number of attempts, the file is moved to the error output directory and no further
submission attempts for this file will be started. Please note that submission attempts without server
reaction are not counted as failure, i.e. no report files are dropped if the server does not respond.
FtpTimeout:
<1d1h1m1s1ms>
Timeout for a single FTP transfer. Please note that this is the entire timeout from the connection of
the TCP socket to the reception of the FTP status code. The timeout has to be large enough to allow
transmission of the larges report and data files over the slowest possible connection.
5.3.20 Task parameters for task FileSync

This section describes dedicated parameters for the task FileSync. Please note that common
Known parameters for task FileSync
Sync-Server:
<HTTP url>
(string, optional)
This parameter can be used to override the default synchronization server in the system
configuration file.
Sync-Groups:
<group list>
(string, optional)
This parameter can be used to assign special synchronization groups to the machine. Usually this
parameter will not be required, in this case the parameter in the machine configuration file will be
used, or more likely the groups defined in the file synchronization.cfg on the synchronization server
(either for the current agent ID or for the default group '*').
DoDownload:
(True/False/Yes/No)
If this parameter is false, the files will not be downloaded. In this case TSS will install the files from
the repository to the application directory if the content of the repository is valid and complete. This
parameter can be used to split download and installation into different tasks.
DoInstall:
(True/False/Yes/No)
If this parameter is false, the files will not be installed. In this case TSS will check for new files to
download and will store them in the repository directory, but will not install them.
MaxDuration:
<1d1h1m1s1ms>
Maximum duration for downloads. This parameter can be used to limit the task duration. Download
of new files will be started until MaxDuration is reached. Please note that the files will only be
installed after the last required file has been loaded and the entire repository is valid and complete.
NumRetries:
<int>
Number of retries for a single file per task execution. The file will be loaded again in the next task
execution.
HttpTimeout:
<1d1h1m1s1ms>
Timeout for a single HTTP request. The value should be large enough to allow loading the largest
required file (approx. 2MB) over the slowest possible connection.
5.3.21 Task parameters for task Registration

The task Registration does not provide special parameters.
TSS 0.0.14.0 07.Nov.2011
94
Technical Reference
5.3.22 Task parameters for task IPConfig

This section describes dedicated parameters for the task IPConfig. Please note that common
Known parameters for task IPConfig
Mode:
(Backup/Restore/Set/Remove/Disable/Enable)
(string)
This parameter defines the operation mode of the IPConfig task.

o Backup
backup interface parameters and store in internal storage
o Restore
restore interface parameters from internal storage
o Set
set interface parameters and stores backup in internal storage if required
o Remove
set empty values to interface parameters and store backup in internal
storage if req.
o Disable
set empty value or 127.0.0.1 to interface parameters, backup if required
o Enable
restore backup of pre-defined values to interface parameters
Interfaces:
<list of interfaces>
(string)
Specifies filter criteria to restrict the interfaces to apply the modifications to. The filter consists of a
list of interface identifiers. If an identifier is preceded by an exclamation sign (!), it is excluded from
the filter, otherwise it is included.
Possible identifiers are:
o *
all active interfaces
o *NIC
all active network interfaces (not RAS or NDIS connections)
o *RAS
all active RAS connections (not network cards)
o *HwNd
... all Huawei NDIS interfaces
o NIC:<name>
... given network card
o RAS:<entry>
specified RAS connection
o HwNd:<name>
specified Huawei NDIS connection
o FN:<name>
... network connections with given friendly name
Parameters:
(GW,DNS)
(string, default: GW,DNS)
A list of interface parameters can be specified with this parameter:

o GW
modifies the interfaces default gateway parameter (value in GwAddrs)
o DNS
modifies the interfaces DNS server address (value in DnsAddrs)
DnsAddrs:
<ip-addr,ip-addr>
(string)
A list of DNS server addresses separated by commas. This parameter is only used if mode is Set.
GwAddrs:
<ip-addr>
(string)
The default gateway's IP address. This parameter is only use if mode is Set.
DoBackup:
(True/False/Yes/No)
If this parameter is set to true, the existing value is stored in internal storage if mode is Set, Remove
or Disable.
DoOverwrite:
(True/False/Yes/No)
If this parameter is set to true, an existing backup value in the internal storage will be overwritten. If
the parameter is false, the existing backup value is kept.
UseGlobalStorage:
(True/False/Yes/No)
If this parameter is set to true, a global backup storage for the entire TSS process is used, otherwise
a local storage for the current job execution is used.
OnlyIfDhcp:
(True/False/Yes/No)
If this parameter is set to true, interface modifications are only executed if the interface is configured
by DHCP.
5.3.23 Task parameters for task Route

This section describes dedicated parameters for the task Route. Please note that common parameters
are available, too.
Known parameters for task Route
Interfaces:
<list of interfaces>
(string list, separated by comma)
Specifies filter criteria to restrict the interfaces to apply the modifications to. The filter consists of a
list of interface identifiers. If an identifier is preceded by an exclamation sign (!), it is excluded from
the filter, otherwise it is included.
Possible identifiers are:
TSS 0.0.14.0 07.Nov.2011
95
Technical Reference
o
o
o
o
o
o
o
o
*
*NIC
*RAS
*HwNd
NIC:<name>
RAS:<entry>
HwNd:<name>
FN:<name>
OnlyIfDhcp:
all active interfaces

all active network interfaces (not RAS or NDIS connections)
all active RAS connections (not network cards)
... all Huawei NDIS interfaces
... given network card
specified RAS connection
specified Huawei NDIS connection
... network connections with given friendly name
(True/False/Yes/No)
If this parameter is set to true, interface modifications are only executed if the interface is configured
by DHCP.
5.3.24 Task parameters for task GetPublicIP

This section describes dedicated parameters for the task GetPublicIP. Please note that common
Known parameters for task GetPublicIP
PublicIP-Server:
<HTTP url>
(string, optional)
This parameter can be used to override the configuration parameter in the system configuration file.
PublicIP-Name:
<string>
(string, optional)
If multiple public IP addresses are available, a name for the interface can be assigned to the task.
Please note that proper routing configuration has to be ensured with Route or IPConfig tasks before
running the GetPublicIP task in this case.
NumRetries:
<int>
Number or retries for a single HTTP request to the public IP server.

HttpTimeout:
<1d1h1m1s1ms>
Timeout for a single HTTP request to the public IP server

ValidCount:
<int>
On success the valid counter in the internal storage is set to this value. On failure, the valid counter
is reduced by one. A public IP address is assumed to be valid as long as the counter is > 0.
MustExist:
< True/False/Yes/No)
If this parameter is set to true, an error is generated if no public IP address is available. =0.0.12.3=
5.3.25 Task parameters for task Clean

The task Clean provides one parameter to define how the temporary directory is cleaned. =0.0.12.3=
Known parameters for task Clean
Clean-Tempfiles.Xxx
(varying)
(string, optional)
This parameter can be used to override settings in the platform configuration file. The parameter
name is formed by the prefix 'Clean-TempFiles.' and the path and parameter in the configuration file,
e.g. =0.0.12.3=
[TempFiles].Compress-Enabled
[TempFiles/Logs].Compress-Enabled
-> Clean-TempFiles.Compress-Enabled
-> Clean-TempFiles-Logs.Compress-Enabled
5.3.26 Task parameters for task Reboot

This section describes dedicated parameters for the task Reboot. Please note that common
Known parameters for task Reboot
ImmediateShutdown:
(True/False/Yes/No)
If this parameter is set to true, the reboot is executed immediately, otherwise after the job execution
has finished.
RebootMode:
(Soft/Win/Auto/Safe/Hard)
(list, default: auto)
Defines the required reboot mode. Possible values are: =0.0.12=

o Win always execute a soft reboot without an MPSW cycle =0.0.13.0=
o Soft ... always executed a soft reboot (with an MPSW cycle if possible)
o Auto ... hard reboot only is safe power down is supported, N soft reboots followed by 1 hard
reboot otherwise
o Safe ... hard reboot if safe power down is supported, soft reboot otherwise
TSS 0.0.14.0 07.Nov.2011
96
Technical Reference
o Hard ... hard reboot if supported, soft reboot otherwise

Please note that hard reboots are executed only if an external watchdog is available. MPSW cycles
are always executed before a reboot if an external MPSW is available. Please refer to section 4.9.1
for details.
UseExternalTool:
(True/False/Yes/No)
Set this parameter to true to force or disable the use of an external reboot tool. =0.0.12=
ExternalToolName:
<file>
(string, optional)
Use this parameter to define an alternate external reboot tool. The default tool is defined in the
[Tools] section in the application config file. =0.0.12=
5.3.27 Task parameters for task ModemPowerCycle

This section describes dedicated parameters for the task ModemPowerCycle. Please note that
common parameters are available, too. =0.0.12=
Known parameters for task ModemPowerCycle
AltRebootMode:
<None/Soft/Auto/Safe/Hard>
(string, optional)
Use this parameter to define an alternate reboot mode if the modem power cycle fails.
UseExternalTool:
Set this parameter to true to force or disable the use of an external MPSW tool.
ExternalToolName:
Use this parameter to define an alternate external MPSW tool. The default tool is define in the
[Tools] section in the application config file.
ImmediateShutdown:
If this parameter is set to true, an alternate reboot is executed immediately.
5.3.28 Task parameters for task Sniffer-Start

The task Sniffer-Start starts a packet sniffer for a CIC (RAS/HwNd) or LAN connection. The available
parameters are the same as in the machine configuration file (section 5.1.4.3) or for CIC tasks
(section 5.3.8). =0.0.13.6=
Please note that Sniffer-Enable has to be enabled and it might be required to specify Sniffer-
Connection.
5.3.29 Task parameters for task Sniffer-Stop

The task Sniffer-Stop terminates a packet sniffer for a CIC (RAS/HwNd) or LAN connection.
=0.0.13.6=
Please note that Sniffer-Enable has to be enabled and it might be required to specify SnifferConnection.
5.3.30 System defined variables

These variables are internally defined by TSS and can be used in tasks (e.g. as command line
arguments). Use the form %param% to access the values.
Available system variables
ExecId:
yyyymmdd-hhnnss-zzzz-pp-qq
(string)
The execution ID for the current job sequence. It contains the scheduled job start stamp (local time
including time zone) followed by a parallel ID (if multiple jobs are executed in parallel) and a
sequence ID (if the job sequence contains more than one job).
TaskId:
j[(ll)].tii[(ll)][...]
(string)
The current task ID in containing job loop (if more than one job), task index and task loop (if more
than one loop). For sub-jobs additional job and task IDs are added.
LogId:
[job/task info]
(string)
This is the long form of TaskId as used in the log file names.
Prefix:
<ExecId>.<LogId>
(string)
The log file prefix consisting of execution ID and log ID. Log files should be placed in the directory
%LogPath% using this prefix, data files in the directory %DataPath%.
TSS 0.0.14.0 07.Nov.2011
97
Technical Reference
AgentId:
<agent-ID>
(integer)
The agent ID as defined in the registration process.

RasEntry:
<RAS entry>
(string)
The name of the last dialed RAS connection if used, empty otherwise. The parameter is deprecated.
RasIpAddr:
<ip>
(string)
The last dialed RAS connection's IP address if used, empty otherwise. The parameter is deprecated.
CicId:
<CIC identifier>
(string)
The identifier of the last dialed internet connection if used, empty otherwise.
CicIpAddr:
<ip>
(string)
The last dialed internet connection's IP address if used, empty otherwise.

The following parameters are available for Execution tasks only:
BinPath:
<dir>
(string)
The path for TSS binary and configuration files (%system%). =0.0.13.0=
ToolPath:
<dir>
(string)
The path for TSS tools (%system\apps%, usually this is %system%\apps). =0.0.13.0=
ScriptPath:
<dir>
(string)
The path for script files (%system\scripts%, usually this is %system%\scripts). =0.0.13.0=
JobPath:
<dir>
(string)
The path for TSS job files (%system\jobs%, usually this is %system%\jobs). =0.0.13.0=
VarPath:
<dir>
(string)
The path for data files (%data%). =0.0.13.0=

LogPath:
<dir>
(string)
The path for log files (%data\work\logs%, usually this is %data%\work\logs).

ReportPath:
<dir>
(string)
The path for XML report files (%data\work\reports%, usually this is %data%\work\reports).
DataPath:
<dir>
(string)
The path for additional (binary) data files (%data\work\data%, usually this is %data%\work\data).
TempPath:
<dir>
(string)
The path for temporary files (%data\temp%, usually this is %data%\temp).

ScriptPath:
<dir>
(string)
The path for script files (%system\scripts%, usually this is %system%\scripts).

ControlFile:
<execid>-control.dat
(string)
The control file for executed processes if used. If this file is created in the directory %TempPath%,
the process shall terminate.
ResponseFile:
<execid>-response.dat
(string)
The response file for console output if used (in the temp directory). The process can write console
output for TSS into this file.
IndexFile:
<execid>-index.dat
(string)
The index file. The process can write the output files and log levels into this file in the temp
directory.
HistoryFile:
<execid>-history.dat
(string)
The history file. The process can receive the list of the current job's executed tasks and the log and
data files. The file is placed in the temp directory by TSS.
ReportFile:
<execid>-report.xml
(string)
The process shall use this file name to store the XML report file in the %ReportPath% directory.
5.3.31 System defined functions

System defined functions are similar to variables, but can be configured with a series of parameters.
Parameters have to be provided in parenthesis (), separated by commas (,). If required, parameters
have to be quoted by double quotes ("). Optional parameters can be omitted starting from right to
left.
Available system functions
%rands(<fmt>,<len>)%
(string)
Returns a random string with given character set and length

<fmt>
- std
... character set, possible values are:

... standard character set: 62 characters A..Z, a..z, 0..9
TSS 0.0.14.0 07.Nov.2011
98
Technical Reference
- base64
<len>
... base64/UUE caracter set: 64 characters A..Z, a..z, 0..9, /, +

... length of result in characters
%randi(<min>,<max>,[<step>],[<len>])%
(integer/string)
Returns a random integer number with given range

<min>
<max>
<step>
<len>
... the minimum possible value

... the maximum possible value
... the step size, default is 1
only values <min>, <min>+<step>, <min>+2*<step>... are returned
... minimum length in characters, default is 0
the returned value is filled with trailing zeros up to the given length
%date([<loc>],[<fmt>])%
(integer)
Returns the current date, either in local time zone or UTC

<loc>
- loc
- utc
<fmt>
- yy, yyyy
- m, mm
- d, dd
- h, hh
- n, nn
- s, ss
- ss.sss
- zzz:zz
...
...
...
...
...
...
...
...
...
...
...
...
the location or time zone, default loc, possible values are

use local time zone
use UTC time
the format, default yyyy-mm-dd, possible formats are
current year (2 or 4 digit form)
current month (1..2 or 2 digit form)
current day (1..2 or 2 digit form)
hour (1..2 or 2 digit form)
minute (1..2 or 2 digit form)
second (1..2 or 2 digit form)
second with fractional part
time zone
%time([<loc>],[<fmt>])%
(integer)
Returns the current time, either in local time zone or UTC

<loc>
- loc
- utc
<fmt>
- yy, yyyy
- m, mm
- d, dd
- h, hh
- n, nn
- s, ss
- ss.sss
- zzz:zz
...
...
...
...
...
...
...
...
...
...
...
...

use local time zone
use UTC time
the format, default hh:nn:ss, possible formats are
time zone
%dt([<loc>],[<fmt>])%
(integer)
Returns the current date, either in local time zone or UTC

<loc>
- loc
- utc
<fmt>
- yy, yyyy
- m, mm
- d, dd
- h, hh
- n, nn
- s, ss
- ss.sss
- zzz:zz
...
...
...
...
...
...
...
...
...
...
...
...

use local time zone
use UTC time
the format, default yyyy-mm-ddThh:nn:sszzz:zz, possible formats are
time zone
5.4 Measurement format IDs

This chapter describes the used measurement format identifiers. These directly map to the section
names in the parameter mapping files, please refer to chapter 5.1.9 for details.
Measurement formats used by TSS:
TSS.Exec
TSS.Startup
TSS.Restart
TSS.Status
TSS.CIC-Dial
TSS.CIC-Hangup
TSS.CIC-Add
TSS.RAS-Dial
TSS.RAS-Hangup
TSS.RAS-Add
...
...
...
...
...
...
...
...
...
...
generated by execution jobs

generated when the application starts
generated before a restart or reboot is required
generated in regular intervals defined by Status-Period
generated by CIC-Dial tasks
generated by CIC-Hangup tasks
added to external reports (e.g. PocketOptimizer and WebSpeedTest)
generated by RAS-Dial tasks (or CIC-Dial tasks)
generated by RAS-Hangup tasks (or CIC-Hangup tasks)
added to external reports if TSS.CIC-Add mapping is not defined.
Please note that the sections [TSS.RAS-*] is used if [TSS.CIC-*] is not existing for compatibility with
previous versions.
TSS 0.0.14.0 07.Nov.2011
99
Technical Reference
5.5 Reports and metrics

This chapter describes QTS reports and metrics generated by TSS.
5.5.1 Execution tickets (TSS.Exec)

Execution tickets are generated when a scheduled item is executed (i.e. after the execution has
finished) or if a scheduled item has to be skipped due to timing problems.
Tickets can be generated for two different types of task execution:
For scheduled jobs if the configuration parameter CIC-Execution is defined.
For modem reset jobs executed before a reset if the parameter CIC-ModemReset is defined.
Ticket parameters
rating:
Ticket rating
(string)
Ticket quality indicator
(string)
Always 1, i.e. ticket is valid

qi:
0 if not executed, 1 is errors occurred, 5 is warnings occurred, 10 if no errors/warnings occurred

comment:
Ticket status/error
(string)
Contains the first error or warning that has occurred

duration:
Duration in seconds
(float)
Contains the entire task execution time in seconds

Metric groups
TSS information (100..109) with execution log file (<exec-id>-execute.log), refer to 5.5.10.1
Tool information (110..119) with TSS version information and error information, refer to 5.5.10.2
Public IP information (160..169), refer to 5.5.10.5
TSS assistance service information (250..259), refer to 5.5.10.7
TSS health information (280..289), refer to 5.5.10.7
Synchronization information (290..299), refer to 5.5.10.9
Registration information (300..399), refer to 5.5.10.10
Metrics
m.112:
Number or errors
(integer)
Contains the number of errors occurred during task execution (only for TSS execution tickets)
m.113:
Number or warnings
(integer)
Contains the number of warnings occurred during task execution (only for TSS execution tickets)
m.116:
Synchronization enabled
(integer)
Note: Changed from m.114 to m.116 in =0.0.13.0=

Shows the current synchronization configuration (1 ... enabled, -1 ... disabled) =0.0.12.5=
5.5.2 Startup tickets (TSS.Startup)

Startup tickets are generated when the TSS scheduler is started, either automatically or manually.
Tickets are generated if the configuration parameter CID-Startup is defined.
Ticket parameters
rating:
Ticket rating
(string)
(string)
Ticket status/error
(string)
Duration in seconds
(float)

qi:
Always 10.0
comment:
Always "Scheduler started"

duration:
Always 0
Metric groups
TSS information (100..109) without execution log file, refer to 5.5.10.1
Tool information (110..119) with TSS version information, refer to 5.5.10.2
Connection IP information (140..149), refer to 5.5.10.4
TSS 0.0.14.0 07.Nov.2011
100
Technical Reference

Metrics
No additional metrics are generated.
5.5.3 Restart tickets (TSS.Restart)

Restart tickets are generated when a restart is required due to execution problems or software
updates. Tickets are generated if the configuration parameter CID-Restart is defined.
Ticket parameters
rating:
Ticket rating
(string)
(string)

qi:
0.0 if reboot is required due to problem, 8.0 for normal reboots

comment:
Ticket status/error
(string)
"Reboot required", "Application restart required" with additional information

duration:
Duration in seconds
(float)
Always 0
Metric groups
Metrics
x.114:
Reboot mode
(string)
Contains the reboot mode: "soft", "ext", "assist-hard", "assist-hard+mpsw", "assist-soft", "assistsoft+mpsw"
5.5.4 Shutdown tickets (TSS.Shutdown)

Shutdown tickets are generated when a system shutdown request is recognized by TSS. Possible
reasons are: =0.0.12.6=
The power button is pressed (note: Windows blocks power messages if Remote Desktop has
taken over the console session as long as no local user is logged on)
The TSS Assistance Services detects a shutdown request from the power monitor device.
Ticket parameters
rating:
Ticket rating
(string)
(string)
Ticket status/error
(string)
Duration in seconds
(float)

qi:
Always 10.0
comment:
none
duration:
Always 0
Metric groups
Metrics
TSS 0.0.14.0 07.Nov.2011
101
Technical Reference
5.5.5 Status tickets (TSS.Status)

Status tickets are generated in regular intervals defined by the configuration parameter Status-Period.
Tickets are generated if the configuration parameter CID-Status is defined.
Ticket parameters
rating:
Ticket rating
(string)
(string)
Ticket status/error
(string)
Duration in seconds
(float)

qi:
Always 10.0
comment:
Always "Status report"

duration:
Always 0
Metric groups
TSS assistance service information (250..259), refer to
Metrics
5.5.6 MPSW/Modem check tickets (TSS.MPSW)

MPSW tickets are generated in two different situations =0.0.12.6=
If an MPSW cycle is done (in CheckModem task, before reboot or after startup)
In this case tickets are generated with CID/TID defined in configuration parameter CID-MPSW.
When a CheckModem task is executed with parameter Scenario-ID defined.
In this case tickets are generated with CID as defined as TID as given by task execution.
Ticket parameters
rating:
Ticket rating
(string)
(string)

qi:
o 10.0 ... Modem OK

o 5.0 ... MPSW success
o 4.0 ... MSPW success without check
o 3.0 ... MPSW success but not re-registered
o 2.0 ... MPSW not available
o 1.0 ... MPSW failed
comment:
Ticket status/error
(string)
Duration in seconds
(float)
contains error information

duration:
Always 0
Metric groups
Metrics
TSS 0.0.14.0 07.Nov.2011
102
Technical Reference
5.5.7 CIC/RAS dial tickets (TSS.CIC-Dial, TSS.RAS-Dial)

CIC/RAS dial tickets are generated by TSS/CIC dial tasks if the task parameter Scenario-ID is
specified.
The measurement format is TSS.CIC-Dial or TSS.RAS-Dial. If a mapping for TSS.CIC-Dial does not
exist, the mapping for TSS.RAS-Dial is used for compatibility reasons.
Ticket parameters
rating:
Ticket rating
(string)
Default values
o 0 if CIC/RAS connection is already active (i.e. was not dialed)
o 1 otherwise (i.e. if a dial attempt was started)
If RateOnResponseOnly is true =0.0.12=
o 0 if the modem cannot be found or does not respond to AT commands (and connection fails)
If RateOnImsiImeiOnly is true =0.0.12.8=
o 0 if the modem does not provide valid IMSI and IMEI (and connection fails)
qi:
(string)
10.0/number of connection attempts on success, 0.0 on failure

comment:
Ticket status/error
(string)
Status or error code (STSS..., WTSS..., ETSS...) followed by detail information

duration:
Duration in seconds
(float)
Total duration if available

Metric groups
Mobile network information (120..139), refer to 5.5.10.3
Metrics
m.1000:
CIC failure ratio
(float)
Internet connection failure ratio = 1.0 - 1.0 / num_attempts on success, 1.0 on failure
m.1001:
CIC total count
(integer)
Number of connection attempts (0 if already open, 1..1+max_retries otherwise)

m.1002:
CIC retry count
(integer)
Number of retries (total count - 1)

m.1003:
CIC activation time (sec)
(float)
Connection activation time of last attempt in seconds, not including time to query modem status
m.1004:
CIC total time (sec)
(float)
Total activation time of all attempts in seconds, not including time to query modem status
x.1010:
CIC type
(string)
CIC type (RAS or HwNd:<version>) =0.0.12.5=

x.1011:
CIC name
(string)
CIC name (RAS entry or NDIS device name) =0.0.12.5=
5.5.8 CIC/RAS hangup tickets (TSS.CIC-Hangup, TSS.RAS-Hangup)

CIC/RAS hangup tickets are generated by TSS/CIC hangup tasks if the task parameter Scenario-ID is
specified.
The measurement format is TSS.CIC-Hangup or TSS.RAS-Hangup. If a mapping for TSS.CIC-Hangup
does not exist, the mapping for TSS.RAS-Hangup is used for compatibility reasons.
Ticket parameters
rating:
Ticket rating
(string)
(string)
Always 1
qi:
10.0 if connection is still active, 5.0 if a connection drop occurred

TSS 0.0.14.0 07.Nov.2011
103
Technical Reference
comment:
Ticket status/error
(string)
Duration in seconds
(float)
Not used
duration:
Always 0
Metric groups
Mobile network information (120..139), refer to 5.5.10.3
Metrics (generic)
x.1010:
CIC type
(string)
CIC type (RAS or HwNd:<version>) =0.0.12.5=

x.1011:
CIC name
(string)
CIC name (RAS entry or NDIS device name) =0.0.12.5=

x.1012:
CIC open EID
(string)
execution ID of CIC ticket that initiated the connection =0.0.12.5=

x.1013:
CIC open TID
(string)
task ID of CIC ticket that initiated the connection =0.0.12.5=

Metrics (if API monitoring is active)
These metrics are generated if the CIC parameter Monitored is set to true.
m.1101:
CIC drop detected
(integer)
0 if connection is still active , 1 if the connection dropped

x.1111:
CIC start stamp
(string)
Connection start stamp in XML date/time format

x.1112:
CIC last active stamp
(string)
Last time stamp when connection was detected as active with API functions in XML date/time format
m.1113:
CIC total active time
(float)
Total active time in seconds if available (i.e. if connection was established by TSS or the API provides
the start time or total duration)
m.1114:
CIC total bytes RX
(integer)
Total number of received bytes as provided by API (for entire connection)

m.1115:
CIC total bytes TX
(integer)
Total number of transmitted bytes as provided by API (for entire connection)

x.1121:
CIC first monitored stamp
(string)
The first time stamp when the internet connection was monitored. The value contains the activation
time stamp (if the connection was dialed) or the first monitored time stamp (if the connection was
already active) in XML date/time format.
m.1123:
CIC monitored active time
(float)
Monitored active time for connection. This is the time from first monitored stamp until the
connection drop or CIC/RAS hang up task.
m.1124:
CIC monitored bytes RX
(integer)
The number of received bytes as provided by API (from connect until hang up task)
m.1125:
CIC monitored bytes TX
(integer)
The number of transmitted bytes as provided by API (from connect until hang up task)
Metrics (if ICMP monitoring is active)
These metrics are generated if the CIC parameters Monitored and Test-ICMP-Host are defined.
m.1151:
ICMP drop detected
(integer)
0 if no drop was detected by ICMP monitoring, 1 if drop was detected by ICMP monitoring
x.1162:
ICMP last active stamp
(string)
Time stamp when last ICMP response was received in XML date/time format
m.1163:
ICMP total active time
(float)
Total active connection time in seconds as detected by ICMP monitoring. Only available if the
connection establishment time could be derived (if connection was dialed or provided by the API)
TSS 0.0.14.0 07.Nov.2011
104
Technical Reference
x.1171:
ICMP first monitored stamp
(string)
Time stamp when first ICMP request was sent.

m.1173:
ICMP monitored active time
(float)
Time from first monitored to last active stamp in seconds.

Metrics (if AT command monitoring is active)
These metrics are generated if the CIC parameters Monitored and WatchModemStatus are defined.
=0.0.13.5=
m.1200:
RAT handovers
(integer)
# of RAT handovers (i.e. changes from one technology to another technology)

m.1201:
RAT selects
(integer)
# of RAT selects (i.e. changes from not-attached to an active technology)

m.1202:
RAT drops
(integer)
# of RAT drops (i.e. changes from an active technology to not-attached)

m.1203:
Cell handovers
(integer)
# of inter cell handovers (i.e. changes from one cell ID to another cell ID)
m.1204:
Cell selects
(integer)
# of cell selections (i.e. changes from not-attached to an active cell ID)

x.1210:
RAT types
(id list)
list of used RAT types, separated by commas, e.g. GSM,UMTS

The list may include N/A (could not be determined) and <none> (drop)
x.1211:
RAT usage
(id+duration list)
list of used RAT types and spent time in seconds, separated by commas, e.g. GSM(10),UMTS(50)
x.1212:
Ext RAT types
(id list)
list of used RAT sub-types, separated by commas, e.g. UMTS-HSPA,UMTS-UMTS

x.1213:
Ext RAT usage
(id+duration list)
list of used RAT sub-types and spent time in seconds, separated by commas e.g. UMTSHSPA+(50),UMTS-UMTS(10)
x.1214:
Cell list
(id list)
list of visited cell IDs, separated by commas, e.g. 232-001-17002-18800,232-001-17002-18823

x.1215:
Cell usage
(id+duration list)
list of visited cell IDs and durations, e.g. 232-001-17002-18800(20),232-001-17002-18823(10)
5.5.9 CIC/RAS additional information (TSS.CIC-Add, TSS.RAS-Add)

TSS adds additional information to tickets generated by external tools (e.g. PocketOptimizer,
WebSpeedTest or scripts). Connection related information can be controlled with the task parameter
AddCicMetrics, tool information is always added but can be controlled with mapping for the
measurement formats TSS.CIC-Add or TSS.RAS-Add.
If a mapping for TSS.CIC-Add does not exist, the mapping for TSS.RAS-Add is used for compatibility
reasons.
Ticket parameters
Ticket parameters do not exist as the information is added to other tickets.
Metric groups
Mobile network information (120..139, only if AddCicMetrics is set), refer to 5.5.10.3
Connection IP information (140..159, only if AddCicMetrics is set), refer to 5.5.10.4
Metrics
5.5.10 Metric groups

This chapter describes metric groups that are used by different tickets.
TSS 0.0.14.0 07.Nov.2011
105
Technical Reference
5.5.10.1 TSS information (100..109)

The TSS information group contains TSS and scheduler information.
Metrics
x.100:
TSS version
(string)
Contains the current TSS version

x.101:
TSS execution ID
(string)
Contains the current TSS execution ID

x.102:
TSS task ID
(string)
Contains the current TSS task ID

x.103:
TSS log file ID
(string)
Contains the log file ID if a log file is available

x.104:
TSS execution time
(string)
Contains the TSS execution time if available in XML format

x.105:
TSS scheduled time
(string)
Contains the TSS scheduled time if available in XML format

x.106:
TSS time shift
(string)
Contains the TSS time shift in seconds.

5.5.10.2 Tool information (TSS, 110..119)
The tool information depends on the executed tool. Typically x.110 and x.111 shall contain the tool
version and tool/task type, other metrics depend on the tool.
Metrics
x.110:
Tool version
(string)
Contains the tool version (the TSS version if the ticket was generated by TSS)
x.111:
Tool/Task type
(string)
Contains the task type if the ticket was generated by TSS

x.114:
The reboot mode used for

o soft
o assist-hard
o assist-hard+mpsw
o assist-soft
o assist-soft+mpsw
o ext
Reboot mode
(string)
the restart. Possible values are: =0.0.12=

... a soft reboot was executed by TSS
... a hard reboot was initiated by the TSS Assistance Service
... a hard reboot with an MPSW cycle was initiated by TAS
... a soft reboot was initiated by the TSS Assistance Service
... a soft reboot with an MPSW cycle was initiated by TAS
... a reboot with an external tool was initiated
5.5.10.3 Mobile network information (120..139)

The mobile network information contains the modem, SIM, network and configuration information.
The parameters are returned if a serial port is available and the values could be queried by AT
commands or API calls.
Metrics
x.120:
IMSI
(string)
IMEI
(string)
Signal level (dBm)
(float)
The mobile's IMSI

x.121:
The mobile's IMEI

m.123:
The current signal level in dBm

x.124:
MCC/MNC
(string)
The current country code/network code in decimal form (e.g. 232-01)

x.125:
LAC
(string)
The location area code as provided by the mobile in hex format (e.g. 426B)
x.126:
Cell ID
(string)
The cell ID as provided by the mobile in hex format (e.g. 278B4)

x.127:
SysInfo
(string)
The system information as provided by the mobile in internal format (e.g. 2,3,0,5,1,,4)
TSS 0.0.14.0 07.Nov.2011
106
Technical Reference
x.128:
SysType
(string)
The current system type as provided by the mobile (UMTS or GSM)

x.129:
Cell Global Identifier
(string)
Cell global identifier in decimal form ccc-nnn-lllll-iiiii (e.g. 232-001-17003-30900)

x.130:
APN
(string)
Detected APN if specified for API calls or derived from mobile and configuration data. For RAS
connections the APN can only be defined if the MSISDN is in Form *99***1#. For *99# this is not
possible.
x.131:
Registration status
(string)
Modem's network registration status =0.0.12.6=

o reg-home
... registered in home network
o reg-roaming ... registered in foreign network
o searching
... searching for network
o denied
... denied/rejected
o unknown
... undetermined/none of the above
5.5.10.4 Connection IP information (140..159)
Connection IP information contains IP information for a CIC/RAS connection.
x.140:
Local IP address
(string)
The IP address assigned to the CIC/RAS connection

x.141:
Local IP network mask
(string)
The IP network mask assigned to the CIC/RAS connection

x.142:
DNS server addrs
(string)
The DNS server addresses assigned to the CIC/RAS connection

x.143:
TCP/IP stack parameters
(string)
TCP settings (for Windows XP) in form =0.0.12.5=

Wnd=<wnd>,1323=<opt>,MTU=<mtu>
Wnd ... window size, 1323 ... RFC1323 options, MTU ... MTU size
x.144:
AFD parameters
(string)
AFD settings (for Windows XP) in form =0.0.12.5=

DRW=<drw>,DSW=<dsw>,BS=<bss>/<bsm>/<bsl>
drw ... default receive window, dss ... default send window, BSS ... small buffer size, bsm ... medium
buffer size, bsl ... large buffer size
x.145:
IE information
(string)
Internet Explorer information in form =0.0.12.9=

IE=<vers>,MC=<mc>,MC_10=<mc_10>
vers ... Internet Explorer version, mc ... max. parallel connections (HTTP 1.1) , mc_10 ... max.
parallel connections (HTTP 1.0)
5.5.10.5 Public IP information (160..169)
Public IP information contains IP information for a permanent IP connection.
x.160:
Public IP address
(string)
The public IP address of a permanent IP connection.

x.161:
Public IP time stamp
(string)
The time stamp when the public IP address was determined.

5.5.10.6 OS information (170..179)
The OS information contains information describing Windows.
x.160
Windows version
(string)
Contains the current windows version (e.g. XP = 5.1, Vista = 6.0, Win7 = 6.1) =0.0.13.1=
x.161
EWF status
(string)
Contains the current EWF status or error information, typical values are: =0.0.13.1=
o EWF is disabled
o EWF manager not found
o Error detecting EWF state
o EWF is enabled, time zone unchanged
o Error committing EWF
o EWF commit initiated, new time zone -120
TSS 0.0.14.0 07.Nov.2011
107
Technical Reference
5.5.10.7 TSS Assistance Service information (250..259)

Health information for the TSS Assistance Service. =0.0.12=
x.250:
TAS Status
(string)
The current TAS status. Possible values are:

o not configured
... TAS is not used
o active
... TAS is active
o unknown
... TAS status could not be determined
o unknown/expired
... TAS status could not be determined or has expired
x.251:
TAS Warning
(string)
A TAS warning if TAS is not working properly in form WD:<warn>, MPSW:<warn>

x.252:
WD Status
(string)
The TAS watchdog status, possible values are:

o none
... no watchdog configured
o act
... watchdog is active and responsive
o act,ps
... watchdog is active and responsive and supports safe power down
o fail
... watchdog failure (device not found or not responding)
x.253:
MPSW Status
(string)
The TAS modem power switch status, possible values are:

o none
... no MPSW configured
o act
... MPSW is active and responsive
o fail
... MPSW failure (device not found or not responding)
5.5.10.8 TSS health information (280..289)
TSS health information contains information regarding the TSS process.
x.280:
TSS application start time
(string)
The time stamp when the TSS application was started in XML date/time format.
m.281:
Working set size (MB)
(string)
The process working set size (RAM) in MB

m.282:
GC memory size (MB)
(string)
The .Net garbage collection heap size in MB

m.283:
TSS thread count
(string)
The thread count of the TSS process

m.284:
TSS handle count
(string)
The handle count of the TSS process

5.5.10.9 TSS synchronization information (290..299)
This group contains synchronization information (configuration and application files).
x.290:
Sync status
(string)
The current synchronization status, possible values are:

o clean
... local files are up to date
o dirty
... local files do not match repository
o checking
... local files are checked
o installing
... repository files are being installed
x.291:
Sync check time stamp
(string)
Time stamp when repository was checked the last time in XML date/time format.
x.292:
Sync install time stamp
(string)
Time stamp when repository files were installed the last time in XML date/time format.
x.293:
Sync content time stamp
(string)
Latest time stamp from repository index files. The time stamp is generated from the latest date
header field in one of the index files. It is provided in XML date/time format.
5.5.10.10 Registration information (300..399)
This group contains tool registration information. Currently the registration information for 3 tools is
reported:
TSS (301..304)
PocketOptimizer (311..314)
TSS 0.0.14.0 07.Nov.2011
108
Technical Reference
WebSpeedTest (321..324)
x.300+n*10:
Tool version
(string)
Tool version
(string)
Tool registration status
(string)
The tool name

x.301+n*10:
The current tool version

x.302+n*10:
The tool registration status, possible values are:

o valid
o not valid
o unknown
x.303+n*10:
Tool expiration
(string)
The tool expiration date/time. Either a date/time in XML format or one of the following status codes
o unknown
o perpetual
x.304*n+10:
Tool checkout
(string)
The tool checkout date/time. Either the time when the registration was checked out from the server
or one of the following status codes:
o unknown
o perpetual
TSS 0.0.14.0 07.Nov.2011
109
Technical Reference
Contents
Introduction................................................................................................................................................1
1.1 What is TSS ........................................................................................................................................1
1.2 Field of application ..............................................................................................................................1
1.3 Revision History ..................................................................................................................................2
1.4 Important notes for Windows XP, Vista and 7 .......................................................................................5
1.5 Known limitations................................................................................................................................5
1.6 This manual........................................................................................................................................5
1.7 System architecture ............................................................................................................................6
1.7.1 Service View .................................................................................................................................6
1.7.2 Functional View ............................................................................................................................6
1.7.3 Data view .....................................................................................................................................7
Installation ............................................................................................................................................... 10
2.1 System requirements......................................................................................................................... 10
2.2 Application startup ............................................................................................................................ 10
2.3 Removing previous installations ......................................................................................................... 10
2.3.1 Removing TSS Win32 Edition....................................................................................................... 10
2.4 Installing TSS ................................................................................................................................... 11
2.4.1 Installing TSS Win32 Edition ........................................................................................................ 11
2.4.2 Configuring Windows .................................................................................................................. 11
2.5 Registering TSS ................................................................................................................................ 12
2.5.1 Getting the Machine ID ............................................................................................................... 13
2.5.2 Automatic registration with license server..................................................................................... 13
2.5.3 Manual registration with license server ......................................................................................... 14
2.5.4 Manual registration with license utility (branded versions only) ...................................................... 14
2.6 Configuring TSS Tasks....................................................................................................................... 14
2.6.1 Configuring TSS without a server ................................................................................................. 14
2.6.2 Configuring TSS with a server...................................................................................................... 15
Operations Manual .................................................................................................................................... 16
3.1 The user front end ............................................................................................................................ 16
3.2 The TSS Assistance Service and Client................................................................................................ 17
3.2.1 Operation modes ........................................................................................................................ 17
3.2.2 Standalone operation .................................................................................................................. 18
3.2.3 Operation with TSS Management Server ...................................................................................... 19
Administrators Manual .............................................................................................................................. 20
4.1 TSS Functions ................................................................................................................................... 20
4.2 Directories ........................................................................................................................................ 20
4.2.1 Single directory scheme .............................................................................................................. 20
4.2.2 Dual directory scheme................................................................................................................. 21
4.3 Scheduler ......................................................................................................................................... 22
4.4 Execution unit and jobs ..................................................................................................................... 22
4.5 Tasks ............................................................................................................................................... 22
4.6 Job and task variables ....................................................................................................................... 23
4.6.1 System defined variables............................................................................................................. 23
4.6.2 System defined functions ............................................................................................................ 23
4.6.3 User defined variables ................................................................................................................. 24
4.6.4 Variable expansion...................................................................................................................... 24
4.7 Internet connections: RAS and CIC .................................................................................................... 24
4.7.1 Types of connections .................................................................................................................. 24
4.7.2 Connection identifiers.................................................................................................................. 25
4.7.3 CIC tasks and configuration ......................................................................................................... 26
4.7.4 RAS tasks and configuration ........................................................................................................ 27
4.8 Firewall rules .................................................................................................................................... 28
4.8.1 Communication overview............................................................................................................. 28
4.8.2 Protocol summary ....................................................................................................................... 29
4.8.3 Local/LAN firewall rules ............................................................................................................... 29
4.8.4 Internet/WAN firewall rules ......................................................................................................... 30
TSS 0.0.14.0 07.Nov.2011
110
Contents
4.9 TSS internals .................................................................................................................................... 30

4.9.1 TSS error processing ................................................................................................................... 30
4.9.2 TSS reboot logic ......................................................................................................................... 30
4.9.3 Agent ID and scenario ID increment ............................................................................................ 31
4.10 Specific operational tasks................................................................................................................. 32
4.10.1 XML Reports/QTS...................................................................................................................... 32
4.10.2 File synchronization................................................................................................................... 32
4.10.3 Log file upload .......................................................................................................................... 34
4.10.4 Time synchronization................................................................................................................. 34
4.10.5 Public IP address ...................................................................................................................... 35
4.10.6 Packet sniffers .......................................................................................................................... 35
4.11 Installer customization..................................................................................................................... 36
4.12 Integrating external tools into TSS ................................................................................................... 36
4.12.1 Types of external applications.................................................................................................... 36
4.12.2 Launching external applications ................................................................................................. 37
4.12.3 Special console messages .......................................................................................................... 37
4.12.4 Log/detail levels ........................................................................................................................ 38
4.12.5 History files .............................................................................................................................. 38
4.12.6 Index files ................................................................................................................................ 39
4.13 Common problems .......................................................................................................................... 39
4.13.1 Interface management .............................................................................................................. 39
4.13.2 Assistance Service ..................................................................................................................... 40
4.14 Hardware watchdogs and power switches......................................................................................... 40
4.14.1 Hardware watchdogs (WD)........................................................................................................ 40
4.14.2 Modem power switches (MPSW) ................................................................................................ 42
4.14.3 GPS receivers............................................................................................................................ 43
4.14.4 Power monitor devices .............................................................................................................. 44
Technical Reference .................................................................................................................................. 45
5.1 Configuration file reference................................................................................................................ 45
5.1.1 Overview of configuration files..................................................................................................... 45
5.1.2 Allowed sections in configuration files .......................................................................................... 45
5.1.3 Processing order for configuration files......................................................................................... 46
5.1.4 Machine configuration file............................................................................................................ 46
5.1.5 Application configuration file........................................................................................................ 55
5.1.6 Platform configuration file ........................................................................................................... 57
5.1.7 System configuration file ............................................................................................................. 60
5.1.8 Mobile configuration file .............................................................................................................. 64
5.1.9 Mapping configuration file ........................................................................................................... 67
5.1.10 Assistance configuration file....................................................................................................... 68
5.2 Scheduler Reference ......................................................................................................................... 71
5.2.1 Scheduler file format ................................................................................................................... 71
5.3 Job File Reference............................................................................................................................. 72
5.3.1 Job file format ............................................................................................................................ 72
5.3.2 Job and task variables................................................................................................................. 72
5.3.3 Task types.................................................................................................................................. 74
5.3.4 Job parameters........................................................................................................................... 75
5.3.5 Common task parameters............................................................................................................ 76
5.3.6 Task parameters for task Delay.................................................................................................... 78
5.3.7 Task parameters for task Sub-Job ................................................................................................ 79
5.3.8 Task parameters for task CIC-Connect ......................................................................................... 79
5.3.9 Task parameters for task CIC-Hangup .......................................................................................... 83
5.3.10 Task parameters for task RAS-Connect....................................................................................... 83
5.3.11 Task parameters for task RAS-Hangup ....................................................................................... 87
5.3.12 Task parameters for task AT-Command ...................................................................................... 88
5.3.13 Task parameters for task CheckModem ...................................................................................... 88
5.3.14 Task parameters for task PocketOptimizer .................................................................................. 89
5.3.15 Task parameters for task WebSpeedTest .................................................................................... 90
5.3.16 Task parameters for task Execute .............................................................................................. 91
5.3.17 Task parameters for task TimeSync............................................................................................ 92
5.3.18 Task parameters for task Report ................................................................................................ 93
TSS 0.0.14.0 07.Nov.2011
111
Contents
5.3.19 Task parameters for task SubmitLogs ......................................................................................... 93

5.3.20 Task parameters for task FileSync .............................................................................................. 94
5.3.21 Task parameters for task Registration ........................................................................................ 94
5.3.22 Task parameters for task IPConfig ............................................................................................. 95
5.3.23 Task parameters for task Route ................................................................................................. 95
5.3.24 Task parameters for task GetPublicIP ......................................................................................... 96
5.3.25 Task parameters for task Clean.................................................................................................. 96
5.3.26 Task parameters for task Reboot ............................................................................................... 96
5.3.27 Task parameters for task ModemPowerCycle .............................................................................. 97
5.3.28 Task parameters for task Sniffer-Start ........................................................................................ 97
5.3.29 Task parameters for task Sniffer-Stop ........................................................................................ 97
5.3.30 System defined variables ........................................................................................................... 97
5.3.31 System defined functions........................................................................................................... 98
5.4 Measurement format IDs ................................................................................................................... 99
5.5 Reports and metrics ........................................................................................................................ 100
5.5.1 Execution tickets (TSS.Exec)...................................................................................................... 100
5.5.2 Startup tickets (TSS.Startup) ..................................................................................................... 100
5.5.3 Restart tickets (TSS.Restart)...................................................................................................... 101
5.5.4 Shutdown tickets (TSS.Shutdown) ............................................................................................. 101
5.5.5 Status tickets (TSS.Status) ........................................................................................................ 102
5.5.6 MPSW/Modem check tickets (TSS.MPSW)................................................................................... 102
5.5.7 CIC/RAS dial tickets (TSS.CIC-Dial, TSS.RAS-Dial)....................................................................... 103
5.5.8 CIC/RAS hangup tickets (TSS.CIC-Hangup, TSS.RAS-Hangup) ..................................................... 103
5.5.9 CIC/RAS additional information (TSS.CIC-Add, TSS.RAS-Add) ...................................................... 105
5.5.10 Metric groups.......................................................................................................................... 105
Contents................................................................................................................................................. 110
TSS 0.0.14.0 07.Nov.2011
112
Contents

TSS-UserManual-0 0 14 0

Uploaded by

Document Information

Original Title

Copyright

Available Formats

Share this document

Share or Embed Document

Sharing Options

Did you find this document useful?

Is this content inappropriate?

Copyright:

Available Formats

TSS-UserManual-0 0 14 0

Uploaded by

Copyright:

Available Formats

TSS

Test Scheduling System

Copyright 2008-2011 by Ingo Zettl, ingo.zettl@aon.at

1.1 What is TSS

1.2 Field of application

TSS 0.0.14.0 07.Nov.2011

1.3 Revision History

0.0.12.10 - 27.04.2011 (=0.0.12.10=)

TSS 0.0.14.0 07.Nov.2011

TSS 0.0.14.0 07.Nov.2011

1.4 Important notes for Windows XP, Vista and 7

1.5 Known limitations

1.6 This manual

TSS 0.0.14.0 07.Nov.2011

1.7 System architecture

1.7.1 Service View

1.7.2 Functional View

A functional view distinguishes the following functions (bottom to top):

TSS 0.0.14.0 07.Nov.2011

1.7.3 Data view

TSS 0.0.14.0 07.Nov.2011

Management functions (without TSS Management Server)

TSS 0.0.14.0 07.Nov.2011

Management Functions (with TSS Management Server)

TSS 0.0.14.0 07.Nov.2011

2.1 System requirements

2.2 Application startup

2.3 Removing previous installations

2.3.1 Removing TSS Win32 Edition

TSS 0.0.14.0 07.Nov.2011

2.4 Installing TSS

2.4.1 Installing TSS Win32 Edition

2.4.2 Configuring Windows

2.4.2.2 Configuring automatic start

TSS 0.0.14.0 07.Nov.2011

2.4.2.3 Default Ports

2.4.2.4 Remote Desktop

2.5 Registering TSS

TSS 0.0.14.0 07.Nov.2011

2.5.1 Getting the Machine ID

2.5.2 Automatic registration with license server

2.5.3 Manual registration with license server

2.5.4 Manual registration with license utility (branded versions only)

2.6 Configuring TSS Tasks

2.6.1 Configuring TSS without a server

TSS 0.0.14.0 07.Nov.2011

Step 4: Configure the scheduler

2.6.2 Configuring TSS with a server

TSS 0.0.14.0 07.Nov.2011

3.1 The user front end

The interface elements are:

3.2 The TSS Assistance Service and Client

3.2.1 Operation modes

The operations of standalone mode are available in client mode, too.

3.2.2 Standalone operation

TSS 0.0.14.0 07.Nov.2011

3.2.3 Operation with TSS Management Server

TSS 0.0.14.0 07.Nov.2011

4.1 TSS Functions

4.2.1 Single directory scheme

4.2.2 Dual directory scheme

TSS 0.0.14.0 07.Nov.2011

4.4 Execution unit and jobs