SpiderCloud Release 3.1.

0
Release Notes
DOC-SCOS-RN3.1.0-01
Date: April 16, 2013

© 2013 SpiderCloud Wireless, Inc.

 Table of contents
1 Introduction ............................................................................................................... 3
2 New Features and Enhancements ........................................................................... 4
3 Alarms, Events, and Conditions .............................................................................. 5
4 Reliability Enhancements and Bug Fixes ............................................................... 6
5 Known Product Limitations ..................................................................................... 8
5.1 Hardware Limitations ........................................................................................................... 8
5.2 Software Limitations ............................................................................................................. 8
5.2.1 UMTS Performance ....................................................................................................... 8
5.2.2 Mobility (SHO, HHO) ...................................................................................................... 8
5.2.3 RF Management and Synchronization ........................................................................... 9
5.2.4 Security/IPsec ................................................................................................................ 9
5.2.5 IP Networking ............................................................................................................... 10
5.2.6 Admission Control and Session Count......................................................................... 11
5.2.7 CLI ................................................................................................................................ 11
5.2.8 Performance Management........................................................................................... 12
5.2.9 SNMP ........................................................................................................................... 13
5.2.10 File Upload Manager .................................................................................................. 13
5.2.11 Miscellaneous ............................................................................................................ 14

6 Known UE Interoperability Issues ......................................................................... 15

7 Certifications and Regulatory Compliance .......................................................... 17
7.1 SCSN-9000 ........................................................................................................................ 17
7.2 SCSN-8000 ........................................................................................................................ 17
7.3 SCRN-200 .......................................................................................................................... 17
8 Software Version and Upgrade Procedure ........................................................... 18
8.1 Software Version ................................................................................................................ 18
8.2 Software Upgrade Path ...................................................................................................... 18
8.3 Hardware Upgrade Path .................................................................................................... 19

9 Documentation ........................................................................................................ 21

© 2012 SpiderCloud Wireless, Inc. Internal 2

‹
 1 Introduction
SpiderCloud Wireless® introduces Release 3.1, which includes new software features, a number
of feature enhancements, and bug fixes.

Release 3.1 supports the SpiderCloud Services Node (SCSN-8000) and SpiderCloud Radio
Node (SCRN-200) hardware and introduces the new SpiderCloud Services Node (SCSN-9000).
Table 1 below summarizes all supported model numbers.

Table 1 Products supported by Release 3.1

Model Number Description

SCSN-9000 SpiderCloud Services Node SCSN-9000
SCSN-8000 SpiderCloud Services Node SCSN-8000
SCRN-200-1 SpiderCloud Radio Node 200 (UMTS Band I, internal antennas, 20dBm)
SCRN-200-1E SpiderCloud Radio Node 200 (UMTS Band I, external antennas, 20dBm)
SCRN 200-2 SpiderCloud Radio Node 200 (UMTS Band II, internal antennas, 20dBm)
SCRN-200-2E SpiderCloud Radio Node 200 (UMTS Band II, external antennas, 20dBm)
SCRN 200-4 SpiderCloud Radio Node 200 (UMTS Band IV, internal antennas, 20dBm)
SCRN-200-4E SpiderCloud Radio Node 200 (UMTS Band IV, external antennas, 20dBm)
SCRN-200-241 SpiderCloud Radio Node 200 (UMTS Band I, internal antennas, 24dBm)
SCRN-200-241E SpiderCloud Radio Node 200 (UMTS Band I, external antennas, 24dBm)
SCRN-200-242 SpiderCloud Radio Node 200 (UMTS Band II, internal antennas, 24dBm)
SCRN-200-242E SpiderCloud Radio Node 200 (UMTS Band II, external antennas, 24dBm)
SCRN-200-244 SpiderCloud Radio Node 200 (UMTS Band IV, internal antennas, 24dBm
SCRN-200-244E SpiderCloud Radio Node 200 (UMTS Band IV, external antennas, 24dBm)

© 2012 SpiderCloud Wireless, Inc. Internal 3

‹
 2 New Features and Enhancements
This section summarizes the new features and enhancements introduced in Release 3.1.

The following provides a list of the different new features introduced in Release 3.1:

Feature Feature ID Optional?

SpiderNet Management System SCW-NMS Yes
High-Capacity Networks SCW-HCN Yes
Enhanced Coverage SCW-EC Yes
Downlink Higher Order Modulation SCW-HOM Yes
High Speed Enhancements SCW-HSE No
Wide-Band AMR SCW-WBAMR No
Cell Broadcast Services SCW-CBS No
Multi-Operator Core Networks SCW-MOCN No
SON Enhancements SCW-ESON No
3GPP Release 8 Fast Dormancy SCW-FD No
TCP MSS Adjustment SCW-TMA No
Dynamic Routing Protocols SCW-DRP No
Virtual Routing and Forwarding SCW-VRF No
File Upload Randomization SCW-UPRND No
Home NodeB Gateway Failover SCW-GWFLVR No
SNMP Proxy SCW-FMPRX No
UMTS Network Monitoring Improvements SCW-NETMON No
VLAN Priority SCW-VLANPCP No

The following provides a list of improvements introduced in Release 3.1:

JIRA Case Description

FL-433 Ability to provision Band II neighbors in Band IV network and vice
versa
FL-430 Ability to scan Band IV neighbors in Band II deployments during
SON operations
FL-295 Randomizing file uploads from the services nodes
FL-168 Group RNs under one or more SACs
FL-305 Support for additional performance counters
FL-283 CORE_IPSEC_TERM should be considered a FAULT
FL-321 Iu-h gateway bring up enhancements
FL-317 Geographic failover on HNB-GW failure (SCW-GWFLVR)
FL-322 Configurable metrics on static routes
FL-345 Allow policy configuration to locally switch a subset of users traffic
to the services blade
FL-190, SNMP proxy agent on SN
FL-303

© 2012 SpiderCloud Wireless, Inc. Internal 4

‹
 FL-158 TCP MSS adjustment (SCW-TMA)
FL-351 Filtering for “show system event” command
FL-355 Additional Fields in MISSING EQUIPMENT Alarm
FL-202 Request to provide event for RN indicating a Power Reset
FL-348 Description field to Event Management targets
FL-381 Need mechanism to provision CA root certificate from the LCI
FL-547 Ability to load SCOS software image through the LCI
FL-447 Ability to populate the /etc/hosts file from the CLI
FL-34 Ability to set local time zone

For more detailed descriptions and configuration of each feature, refer to the SpiderCloud
Feature Description Document and the SpiderCloud OS (SCOS) Administrator Guide.

3 Alarms, Events, and Conditions

Release 3.1 introduces the following new alarms

Alarm Description
CORE_IPSEC_TERM An IPsec tunnel to the core network security gateway has
terminated. (formerly a condition)
DB_INVALID The startup validation of the services node database failed.
MULTIPLE_COOLING_FAN_FAILURES Two or more services node fans have failed.
POWER_SUPPLY_FAILED A power supply module has failed.
POWER_SUPPLY_MISSING A power supply module has not been installed or has been
removed.
TIMEZONE_CHANGED The services node time zone has been changed.
UARFCNDL_CHANGED The UARFCNDL has been changed, provisioned UMTS
externals cells have been recreated.

Release 3.1 introduces no new conditions.

Release 3.1 introduces the following new events:

Event Description
BGP_PEER_DOWN A BGP peer is down.
BGP_PEER_STATE_CHANGE A BGP peer has had a state change.
BGP_PEER_UP A BGP peer is up.
CBS_MSG_BROADCAST_STARTED A broadcast message is now being transmitted
across all radio nodes using the cell broadcast
service.
CBS_MSG_BROADCAST_STOPPED Transmission of a broadcast message across all
radio nodes, using the cell broadcast service, has
now been stopped.
CBS_RESET Transmission of all broadcast messages, using
cell broadcast service, has now been stopped.
The broadcast transport channel is removed.
COOLING_FAN_FAILURES_SUSTAINABLE The system can be properly cooled in spite of
internal fan failures that may exist.

© 2012 SpiderCloud Wireless, Inc. Internal 5

‹
 DB_VALIDATION_FAILED The database validation failed.
DB_VALIDATION_SUCCEEDED The database validation succeeded.
FMGMT_ZONE_ADD_START The radio environment monitoring add cycle has
started for the specified zone.
MULTIPLE_COOLING_FAN_FAILURES Two or more services node fans have failed.
POWER_SUPPLY_FAILED_CLEAR A power supply had recovered from failure.
POWER_SUPPLY_FAILED_RAISE A power supply has failed.
POWER_SUPPLY_MISSING_CLEAR A power supply is no longer missing.
POWER_SUPPLY_MISSING_RAISE A power supply is missing.
RFMGMT_COVERAGE_TARGET_CHANGED The RF management coverage has changed.
RFMGMT_COVERAGE_TARGET_NOT_MET Indicates that a cell's transmit power cannot be
increased to meet the maximum provisioned
level.
RFMGMT_STALE_REM_RESULTS The radio environment monitoring results are
stale for the cell in specified zone.
RFMGMT_UARFCNDL_CHANGE_DETECTED Indicates that the UARFCNDL has changed,
provisioned UMTS external cells must be deleted
and recreated.
RFMGMT_ZONE_ADD_ABORTED The radio environment monitoring add cycle has
been aborted for the specified zone.
RFMGMT_ZONE_ADD_COMPLETE The radio environment monitoring add cycle has
completed for the specified zone.
RFMGMT_ZONE_REM_ABORTED Radio environment monitoring has been aborted
for the specified zone.
RFMGMT_ZONE_REM_COMPLETE The radio environment monitoring has completed
for the specified zone.
RFMGMT_ZONE_REM_START The radio environment monitoring has started for
the specified zone.
TIMEZONE_CHANGED The services node time zone has been changed.
UMTS_CN_CONN_SWITCHOVER_MAX_ATTEMPT The maximum number of attempts to switchover
to a different security gateway and HNB gateway
has been reached.
UMTS_CN_CONN_SWITCHOVER_TRIGGERED A switchover was triggered to the secondary
security gateway and HNB gateway.

4 Reliability Enhancements and Bug Fixes

The following table includes a list of previously reported known issues and limitations, along with
some key enhancements that have been fixed in release 2.0.5:

Tracking Problem description

Performance Management
SW-3663 The statistics maintained for a LANDevice are reset to zero when the LANDevice is
deleted in the configuration.
IPsec
SW-3975 Under certain circumstances, the services node may attempt to reach the IPsec
gateway using an incorrect local address, causing the IPsec tunnel to the core to not
come up. This issue has been fixed in release 3.1.

© 2012 SpiderCloud Wireless, Inc. Internal 6

‹
 System (UMTS)
SW-4235 Admission Control feature was enhanced to handle code tree fragmentation, which
enables the system to admit a higher number of users during normal operation and
makes the system less susceptible to code tree fragmentation. The fix enables the
system to choose a lower OVSF code, if available, at the time of radio bearer setup.
Additionally, the admission control feature was enhanced so that the compressed
mode method is always chosen as SF/2 regardless of whether secondary scrambling
code (SCC) is enabled or not. SSC is still enabled by default.

© 2012 SpiderCloud Wireless, Inc. Internal 7

‹
 5 Known Product Limitations
5.1 Hardware Limitations
No hardware limitations have been reported.

5.2 Software Limitations

5.2.1 UMTS Performance

Tracking Problem description

SW-4360 The issue describes a scenario where a call drop can happen in a multi-RAB (CS +
PS) call. If two security commands are received from the core from both domains, the
RNC correctly waits till the first “SecurityModeComplete” is received, before sending
the second “SecurityModeCommand”. However, it is possible that the RLC ACK for the
first “SecurityModeComplete” was not received by the UE before receiving the second
“SecurityModeCommand”. This can happen for example if the RLC ACK is lost.
Per TS 25.331 the UE will send a “SecurityModeFailure” in this case, as it treats the
first procedure as not complete. This results in a call drop.
SW-3124 If a UE's state switches from "Cell FACH" to "Idle" without the services node being
aware of it (for example, due to poor coverage), the next "RRC_Connection_Request"
by the UE will cause the services node to disconnect the PS session. This scenario
could result in longer call setup times and a session drop (for PS sessions only).
SW-2245 Occasional re-ordering of downlink forwarding plane packets has been observed which
could potentially trigger RLC resets. This is a rare problem but if it happens it could
impact session performance.
SW-2124 Under some rare conditions RoT spikes may be observed. Although RoT spikes won't
be noticeable by the end users, they can cause a temporary drop in the uplink capacity
(the system backs off and reduces the grants allocated to the corresponding UEs).
This issue has been seen only in cases where multiple UEs are located close to each
other and at the boundary of two cells, while they are all attempting to transmit high
uplink traffic (typically more that can be supported by the airlink).
SW-1998 When a radio node is serving a large number of UEs (in this case 14 or more) and is
operating at full rate bi-directional traffic, RLC resets may occur due to ACK/NACK
messages from the UE being delayed behind data PDUs.
SW-1225 Packet drops could occur when sending download traffic to Cat6 UE devices if the
packet size is 100 bytes and the data rate exceeds 770 Kbps.

5.2.2 Mobility (SHO, HHO)

Tracking Problem description

SW-2149 Degradation of the downlink (not in compressed mode) can cause the UE to
experience a session loss before it can trigger a hard handover. This problem can
cause session drops. Currently there is no known workaround.

© 2012 SpiderCloud Wireless, Inc. Internal 8

‹
 SW-1592 During intra frequency HHO, a UE may come up on the new cell with incorrect TTI
alignment, causing CRC errors and eventually loss of signaling and data plane.
Eventually RLC layer will reset tearing down the connection. This is most likely a UE
issue (Qualcomm chipset).
SW-1456 A UE in soft handover, having 2 links in its active set, may occasionally experience a
radio link failure causing a session drop. This is more likely to happen after a sudden
drop (> 5dB) in the downlink DCH power. It is currently estimated to occur less than
0.5% of the time and The effect of a session drop would be a dropped call (for CS) or a
temporary degradation of throughput (for PS).

5.2.3 RF Management and Synchronization

Tracking Problem description

SW-4259 Independently for each SCRN-200 radio node during REM scan operation, the UMTS
sniffer fails to detect an external UMTS cell in good signal strength approximately 5%
of the time. This will rarely affect system performance because each cell includes its
neighbor's external neighbors in its own handoff neighbor list. In the rare cases where
an external cell's signal is very weak within a deployment, such that only 1 or 2 internal
cells could feasibly detect it, this could result in a failure to detect and list that external
UMTS cell as a neighbor for any cell in a deployment.

5.2.4 Security/IPsec

Tracking Problem description

FL-375 The IPsec tunnel to the core may fail to come up after an interface flap if the learned
route from the IPsec gateway conflicts with an already-configured static route.
SW-4707 If the SecGWPreSharedKeyIndex parameter for a CryptoProfile is changed, the IPsec
tunnel to the core can go down and not automatically come up again, requiring that the
tunnel be manually brought down and up.
SW-5548 The IPsec tunnel will not be re-established after changing the configuration from a
StaticConfig to a dynamic config with RequestedIPAddress. Under this scenario, the
Virtual Interface (FAPService 1 Transport Tunnel VirtualInterface) should be disabled
and re-enabled either through the CLI or the LCI.
SW-4143 The IPsec tunnel to the core may be displayed as being established even when one or
more Child SAs have not been negotiated successfully.
SW-3964 If the IPsec tunnel from the services node to the core network security gateway is
unexpectedly terminated, the core network might not detect the termination
immediately and will persist in using a stale security association to send data.
SW-3895 Under certain circumstances, the IPsec tunnel to the core network can go down due to
IKE renegotiation as soon as it comes up, and this can repeat for an indeterminate
period.

© 2012 SpiderCloud Wireless, Inc. Internal 9

‹
 SW-2437 If a denial of service vulnerability in the services node has been detected, where even
with IPsec enabled on the core facing interface, the NTP port (UDP 123) shows as
open. A remote attacker could exploit this by sending a mode 7 error response with a
spoofed IP header, setting the source and destination IP addresses to the IP address
of the target. This would cause the NTP daemon to respond to itself endlessly,
consuming excessive amounts of CPU, resulting in a denial of service.
SW-1986 The services node rekeys IKE SAs without uninstalling the Child IPsec SAs; it lets the
existing Child SAs expire before rekeying a new pair of Child SAs on the newly
rekeyed IKE SA. If a core security gateway is configured to always require that a new
pair of child SAs be renegotiated and used whenever an IKE SA is rekeyed, there may
be traffic interruption or failure following IKE rekeys.

5.2.5 IP Networking

Tracking Problem description

SW-5459 An IPInterface configured with VLANID 1 will transmit packets that are not 802.1Q-
tagged. The packets it sends will be untagged. IPInterfaces with VLANID 1,2 should
be avoided.
SW-5333 When  the  core  network  is  placed  in  a  VRF,  the  Services  Node  will  not  respond  to  an  ICMP  
echo  (ping)  sent  to  the  IPsec-­‐gateway-­‐assigned  IP  address.  All  other  services  are  functional,  
however.
SW-4806 Under some circumstances, changing the IP addresses on interfaces can cause the
IPSec tunnels to the core network and to the radio nodes to go down and then come
up.
SW-4795 If an IPSec tunnel to a security gateway is brought down and static protected subnets
are not configured, the gateway-learned route might not be removed correctly so that
an attempt to replace it with a static route will fail.
SW-4598 When egress traffic shaping is configured on an interface and enough traffic of a
certain class of service is transmitted that the traffic is queued, subsequent traffic of a
different class of service can be transmitted ahead of the queued traffic such that the
anti-replay window of a receiving IPsec gateway is advanced, which will cause the
queued traffic to be dropped at the gateway as being out of window.
SW-3679 A locally-switched multi-homed host that reconnects its data session may not be able
to communicate with the enterprise network.
SW-3678 If “Enrollment-CNAPT” and “CNAPT” policies have different interfaces, a UE may end
up with the incorrect IP address after the RADIUS enrollment. The workaround is to
have the “Enrollment-CNAPT” and “CNAPT” policies to have the exact interfaces.
SW-3551 Due to certain known issues with "CNAPT" local switching mode, it is recommended to
only use "NAPT" in this release when a local switching policy is configured.
SW-3538 Services node to radio node Firewall NAT traversal requires the core network and
radio node private networks to have disjoint IP address spaces.

© 2012 SpiderCloud Wireless, Inc. Internal 10

‹
 5.2.6 Admission Control and Session Count

Tracking Problem description

SW-3339 When a soft handover event occurs right before a RAB setup in a loaded cell, it will
result in an admission control failure. The system by default reserves 3 radio links per
cell for mobility events (soft handover). This particular case however is not treated as a
mobility event and the system will not admit the call even if one cell in the active set is
already loaded with 12 active calls.
SW-1664 Admission Control does not handle code tree fragmentation. This may impact some
admission control demos when a UE that is expected to connect is rejected. In actual
deployments, the customer impact is that a lower proportion of UEs will be admitted
compared with expectations.

5.2.7 CLI
Tracking Problem description
SW-4627 The administrator can use the CLI to configure which statistics should be collected in
performance management reports. The system supports hundreds of statistics.
However, CLI auto complete limits the displayed options to 100. This is a known issue
that occurs when issuing the CLI command "set FAPService 1 PerfMgmt ReportMgmt
Enable true SampleSet statistic reference <TAB>". To navigate the complete set of
supported measurements, refer to the "SCOS NB Data Model Reference Guide",
available as part of the SpiderCloud product documentation.
SW-4470 The data model attribute "FAPService.1.FAPControl.AdminState" is not supported in
this release. It does not lock the UMTS subsystem and prevent radio nodes from
transmitting. In order to quickly stop radio nodes from transmitting, and the system
from serving traffic, issue the following command: "set System OperatingMode
Maintenance".
SW-3906 For radio nodes that do not have their "Name" field provisioned in the CLI, the "show
RadioNode" command displays a "-" in the output column, whereas the "show
RadioNode Radio" command displays "NULL".
SW-3655 The CLI admin user does not have permission to view logfiles/db_* or
logfiles/messages*.

© 2012 SpiderCloud Wireless, Inc. Internal 11

‹
 SW-2247 When the system is configured with RF management enabled
(FAPControl.UMTS.SelfConfig.NLSCE = TRUE), a “load merge” can cause the cell
primary scrambling codes to be set to zero (this will happen for example if the cells
were manually deleted and an attempt to load the previously saved config is made). A
work-around for this release is to execute the following two commands following a
“load merge”:
1) “request umts self-config clear-ue-measurements”
2) “request umts rem start”
This reinitializes the RF management system to start from maximum radio node power
(step 1), and then assign primary scrambling codes and pull power down according to
UE measurements over time (step 2).
The above procedure is not required when RF management is disabled
“FAPControl.UMTS.SelfConfig.NLSCE = FALSE”.

5.2.8 Performance Management

Tracking Problem description
SW-5057 The following Cell related performance counters are not implemented in this release:
Cell.{i}.UMTS.Airlink.RLManagement.UEInCompressedModeHist
Cell.{i}.UMTS.HandOut.InterRAT.CNAttemptsTargetCellIndex
Cell.{i}.UMTS.HandOut.InterRAT.CNSuccessesTargetCellIndex
Cell.{i}.UMTS.HandOut.InterRAT.CNFailuresTargetCellIndex
Cell.{i}.UMTS.HandOut.InterRAT.UESuccessesTargetCellIndex
SW-5472 When a HSPA+ session is moved to Cell-PCH or Cell-FACH state, the PS Session
type is shown as HSPA instead of HSPA+. This is corrected when the session is
restored to the Cell-DCH state.
SW-5551 After a system reboot, it is possible that the historical session statistics are lost even
though the FapService{1}.PerfMgmt.Collection.StoreSessionStatistics value is set to
true. In this case, it is recommended that the session statistics be queried and saved to
a file before reboot if the session statistics need to be stored.
SW-5538 The “show Session UMTS Summary” command does not differentiate between HSPA
and HSPA+ sessions. The HSPA+ sessions are counted as HSUPA sessions.
SW-4080 The statistics maintained for an IPInterface will be reset to zero if the IPInterface is
disabled or if the physical link goes down.
SW-3732 The following RANAP performance counters are not implemented in this release:
FAPService.{i}.UMTS.RANAP.{i}.UESpecificInfomationIndication
FAPService.{i}.UMTS.RANAP.{i}.DataVolumeReportRequest
FAPService.{i}.UMTS.RANAP.{i}.CNInvokeTrace
FAPService.{i}.UMTS.RANAP.{i}.CNDeactivateTrace
FAPService.{i}.UMTS.RANAP.{i}.LocationRelatedDataRequest
FAPService.{i}.UMTS.RANAP.{i}.InformationTransferIndication
FAPService.{i}.UMTS.RANAP.{i}.ErrorIndicationReceived
FAPService.{i}.UMTS.RANAP.{i}.ErrorIndicationSent
FAPService.{i}.UMTS.RANAP.{i}.OverloadReceived
FAPService.{i}.UMTS.RANAP.{i}.DirectInformationTransferReceived

© 2012 SpiderCloud Wireless, Inc. Internal 12

‹
 SW-3731 The following RANAP performance counters are not implemented in this release:
FAPService.{i}.UMTS.RANAP.{i}.RABReleaseRequest.Cause
FAPService.{i}.UMTS.RANAP.{i}.RABReleaseRequest.Sum
SW-3540 The following UMTS performance counters (per UE) in the data model are not
supported:
UE.{i}.UMTS.Traffic. TotalConnectDurationPS
UE.{i}.UMTS.Traffic. TotalConnectDurationCS
UE.{i}.UMTS.Traffic. TotalRLCPDUsSent
UE.{i}.UMTS.Traffic. TotalRLCPDUsReceived
SW-3136 Data model counters for SMS sessions are not supported in this release.
More specifically this applies to the following counters:
FAPService.{i}.UMTS.CurrentStatus.ActiveCSSessions.Type.SMS
FAPService.{i}.UMTS.SessionManagement.MasterSessionCreation.Cause.SMS
FAPService.{i}.UMTS.SessionManagement.NASSessionCreation.CS.Type.SMS
UE.{i}.UMTS.SessionManagement.MasterSessionCreation.Type.SMS
SW-2343 The Voice and Registration counters displayed under
Cell.UMTS.CurrentStatus.SessionManagement.MasterSessionCreation.Cause are not
updated properly and should not be used.
SW-2326 Radio bearer RLC counters for voice sessions are not supported in this release. This
applies to the output of the CLI command: show Session UMTS SessionID 1154
Verbose.

5.2.9 SNMP

Tracking Problem description

SW-5405 Management of third party devices such as routers and switches which do not support
SNMP v2c is not supported in this release.
SW-3710 In order for SNMPv3 "Informs" to be authenticated, the expected NMS manager user
shall be "admin" (as defined in the services node's adminAAA).
SW-3661 The services node SNMP agent returns a bad IpAddress value for "IP-
MIB:ipAdEntAddr" which can cause a "get-next" operation to fail in the NMS manager.
This is due to a known format error. The returned value and type for this object ID is
still correct however and shall be used as a temporary workaround.
SW-2803 SNMP support is limited to "GET" only. The edamin user is only allowed to read,
therefore the MIB browser or NMS user has to provide SNMPReadCommunity
password for the SNMP walk (using a "write" password will not allow "read").

5.2.10 File Upload Manager

Tracking Problem description
SW-3321 On occasion, the upload manager does not detect that the remote device has no
capacity to store additional uploaded files and reports a successful upload when
queried with the “show status OpState System FileManagement” command.
SW-3312 Rarely, the upload manager does not report failure of file uploads after the specified
number of attempts has been reached without a successful upload.

© 2012 SpiderCloud Wireless, Inc. Internal 13

‹
 5.2.11 Miscellaneous
Tracking Problem description
SW-4146 When using the | (pipe) modifier to process the output of a CLI command (for example
to "match", "find" or "except"), the double wildcard ("**") should be avoided.
For example:
"show radionode | match 3**" will cause a problem and should not be used
"show radionode | match 3*" will work fine
SW-4140 It is possible for the database backup CLI command to give a timeout error if the
logging database is included. The backup does succeed in this case, and the CLI
session recovers without intervention. To avoid the CLI error, do not include the
logging database in the database backup.
SW-3089 In a heavily loaded system (50 radio nodes), bi-directional UDP traffic can cause some
radio nodes to reboot. The reason for the reboot is loss of keep-alive messages
between services node and radio node due to congestion. This problem has been
observed on a 50 radio node and 60 UE setup, and has been triggered by bi-
directional UDP traffic simultaneously on all UEs (1400-byte packets and 7 Mbps data
rate per UE).

© 2012 SpiderCloud Wireless, Inc. Internal 14

‹
 6 Known UE Interoperability Issues
Device Tracking Problem description
Samsung GT- FL-427 Under some scenarios, call disconnects are observed on the
S5830i Galaxy Samsung GT- S5830i Galaxy Ace UE, which uses Broadcom
Ace BCM21553 chipset. It is observed that the reason for this failure is
the frequent slot-to-slot phase changes of close to 180 degrees
with this UE. This issue has been identified as UE non-
conformance to 3GPP spec, with regard to phase discontinuity
between slots.
34.121 - section 5.13.3.2 gives the allowable phase discontinuity
between slots as:
• Phase change <30 degrees allowed 100% of time
• Phase change >30 and <60 degrees 20% of time
• Phase change >60 degrees 0% of time
The UE behavior is outside the discontinuity allowed by the
specifications.
T-Mobile/ SW-1310 When a Huawei UMG181 UE is going into a soft handover and
Huawei UMG 181 right after an "active set add" event, it may occasionally report
incorrect CFN-SFN offset in its measurement report. This can
result in a UE disconnect. There is no known workaround for this
issue, however the UE will reconnect on its own few seconds
later.
SW-1194 Huawei UMG181 UEs may occasionally send a PDP Deactivate
request for unknown reasons. This issue has not been seen with
other UEs using the same chipset, so it is believed to be restricted
to UMG181 dongles. There is no known workaround.
SW-1193 This is a rare issue. Intermittent high frequency error on the uplink
transmission has been observed which can cause the AGC to trip
and in some cases cause the UE to disconnect.
Option iCON 452 SW-1955 During soft handover and while DL TCP traffic is running, the
Option iCON452 UE may experience RLC resets that will cause
TCP throughput degradation. The throughput drop could last for 1-
2 seconds but then it returns back to normal.
SW-1912 This problem occurs frequently during hard handover with the
Option iCON 452 UEs. However it has never occurred with other
dongles using the same chipset. During a HHO, the UE fails to
acquire the downlink even though the CPICH is received with
good SNR. There is no workaround, however the services node
will keep retrying the HHO for that UE. Eventually this issue could
affect HHO success rate.

© 2012 SpiderCloud Wireless, Inc. Internal 15

‹
 SW-1023 Occasionally Option iCON452 UEs may detect a large timing error
and send a PRACH preamble with large timing offset. This
preamble may not be detected by the radio node leading to a call
setup failure. There is no workaround but the user impact is low as
the result is a longer call setup time.
HTC Android SW-2989 Same issue as SW-1310 (Huawei UMG181 UE). When an HTC
Android UE is going into a soft handover and right after an "active
set add" it may occasionally report incorrect CFN-SFN offset in its
measurement report. This can result in a UE disconnect. There is
no known workaround for this issue, however the UE will
reconnect on its own few seconds later.
Nokia SW-3707 Some Nokia handsets (C6, C2-01, or X3) may experience hard
handover timeout leading to session drops, if RLC resets due to
signal degradation during the SRNS relocation process.
SW-2816 Nokia C6-01 phones (penta-band) fail to camp on a Band IV OTA
network.
Samsung T919 SW-4215 When a Samsung T919 device is going into a soft handover, it
sometimes reports an incorrect chip offset for the new target cell.
This results in a failure to establish the RL with the new target cell.
In some cases, it could result in a call drop if the remaining cells in
the active set are too weak to maintain their links with the UE.
Nokia N80, N95, SW-3338 Some UEs in multi-RAB sessions fail to terminate the PS session
iPhone 3G, following a radio link failure. As a result, after the RRC re-
Blackberry establishment PS connection attempts fail. This behavior has
been observed with the Nokia N80 (R99), Nokia N95, iPhone 3G,
and some Blackberry phones.

© 2012 SpiderCloud Wireless, Inc. Internal 16

‹
 7 Certifications and Regulatory Compliance
7.1 SCSN-9000
• FCC part 15 Class A
• Industry Canada Class A (ICES 003)
• VCCI V-3/2012.04 Class A
• CISPR 22:2008 Class A
• EN 55022:2010/AC:2011
• EN 55024:2010
• EN 61000-3-2:2006/A2:2009
• EN 61000-3-3:2008
• EN 60950-1:2006/A12:2011
• CAN/CSA-C22.2 NO. 60950-1A-07 (R2012)
• CE Mark, cTUVus
• Directive 2002/95/EC on RoHS
7.2 SCSN-8000
• FCC part 15 Class A
• Industry Canada Class A (ICES 003)
• VCCI V-3 / 2009.04 Class A
• CISPR 22:2008 Class A
• EN55022:2006 Class A
• EN55024:1998/A1:2001/A2:2003
• EN61000-3-2:2006
• EN61000-3-3:1995/A1:2001/A2:2005
• EN 60950-1:2006+A11
• CAN/CSA-C22.2 No.60950-1-07
• CE Mark, cTUVus
• Directive 2002/95/EC on RoHS
7.3 SCRN-200
• FCC Part 15 Class A
• FCC Part 24
• FCC Part 27
• Industry Canada RSS-133, RSS-139, ICES-003 (Class A)
• EN 60950-1: 2006 + A11: 2009
• EN 50385: 2002
• EN 301 489-1 V1.8.1
• EN 301 489-23 V1.4.1
• EN 301 908-1 V4.2.1
• EN 301 908-3 V4.2.1
• CE Mark (CE 2200)
• NRTL Mark
• CB certification as per IEC 60950-1:2011

© 2012 SpiderCloud Wireless, Inc. Internal 17

‹
 8 Software Version and Upgrade Procedure
8.1 Software Version
The software version qualified for this release is 3.1.0.103. The filename of the software
package is scw_Rel_3.1.0.103.

The software build is a single binary file (containing the system images for the services node
and the radio nodes). The radio nodes download the software image from the services node
during initialization. When the services node reboots, all associated radio nodes also reboot,
which guarantees that all radio nodes in the E-RAN are always on the same software version.

Issue the following CLI command to determine the software release running on the system:
admin@> show Version
Product Image Version Timestamp
------- ------- ------- ----------------------
SCOS running 3.1.0 2013-04-10T01:36:11-07:00

Issue the following command to view more details, such as the software build number/date and
the list of all provisioned radio nodes along with their running version:

admin@>  show  Version  Detail    

NodeID    PackageID    Version                          Builder          BuildTime                                        
-­‐-­‐-­‐-­‐-­‐-­‐    -­‐-­‐-­‐-­‐-­‐-­‐-­‐-­‐-­‐    -­‐-­‐-­‐-­‐-­‐-­‐-­‐-­‐-­‐-­‐-­‐-­‐-­‐-­‐-­‐-­‐-­‐-­‐    -­‐-­‐-­‐-­‐-­‐-­‐-­‐-­‐-­‐-­‐    -­‐-­‐-­‐-­‐-­‐-­‐-­‐-­‐-­‐-­‐-­‐-­‐-­‐-­‐-­‐-­‐-­‐-­‐-­‐-­‐-­‐-­‐-­‐-­‐-­‐-­‐-­‐-­‐  
   1025    UMTS              3.1.0.103.4696            builder          Wed  Apr  10  01:12:57  2013  PDT  
   1025    PLAT              3.1.0.103.9676            builder          Wed  Apr  10  00:50:44  2013  PDT  
   1025    BOOTB            3.1.2                              builder          Wed  Apr    3  11:05:50  2013  PDT  
   1025    BOOTA*          3.1.2                              builder          Wed  Apr    3  11:05:50  2013  PDT  
   1102    WLAN              3.1.0.103.258              builder          Wed  Apr  10  01:16:18  2013  PDT  
   1102    PLAT              3.1.0.103.9676            builder          Wed  Apr  10  00:50:44  2013  PDT  
   1102    BOOTB            3.1.2                              builder          Wed  Apr    3  11:05:50  2013  PDT  
   1102    BOOTA*          3.1.2                              builder          Wed  Apr    3  11:05:50  2013  PDT  

8.2 Software Upgrade Path

The following upgrade path has been fully qualified and is supported:

• 2.0.5.30 -> 3.1.0.103

To upgrade to a new version of software, you need to first obtain a new image from SpiderCloud
Wireless and copy that file to the services node. The system uses Secure Copy Protocol (SCP),
so on the remote server SSHd must be running.

© 2012 SpiderCloud Wireless, Inc. Internal 18

‹
 8.3 Hardware Upgrade Path
Release 3.1 introduces the SCSN-9000 services node. To upgrade a deployment that is
currently using SCSN-8000 to SCSN-9000, the following steps are recommended. Note that CLI
or SpiderNet access is needed for performing this hardware upgrade. Only CLI commands are
shown here for simplicity.

Collecting database backup file from SCSN-8000:

• Create a database backup on the SCSN-8000 by using the following command:

o admin@> request system database backup filename <db-filename>
Note: If the database is backed up with the option
“IncludeLoggingDB”, the restore operation may take longer.

• Transfer the backup file from the SCSN-8000 to a network accessible location using the
following command:
o admin@> file put <db-filename> scp://<user>@<host><directory-
path>/<db-filename>

• Power down the SCSN-8000.

Restoring database backup file on SCSN-9000:

• The SNSN-9000 ships with Release 3.1 software version. On the SCSN-9000, reconfigure
the IP interface to access the network. The LCI can also be used to set these parameters.
o admin@% set LANDevice 1 LANEthernetInterfaceConfig 1 Enable true
o admin@% set LANDevice 1 LANHostConfigManagement IPInterface 1
IPInterfaceIPAddress <SN-IP-address> IPInterfaceSubnetMask
255.255.255.0 Enable true
o admin@% set Layer3Forwarding Forwarding 1 DestIPAddress 0.0.0.0
DestSubnetMask 0.0.0.0 GatewayIPAddress <gw-IP-address> Enable true
• Upload the database backup file to the SCSN-9000 using the following command. This
command can be executed via the CLI or SpiderNet.
o admin@> file get scp://<user>@<host><directory-path>/<db-filename>.
• Restore the SCSN-9000 state from the uploaded backup file using the following command:
o admin@> request system Database Restore Filename <db-filename>
• Note: Once the DB restore completes, the newly introduced SCSN-9000 specific data model
container ‘ManagementDevice’ will be empty (this is needed for accessing the LCI). Issue
the following CLI commands to create the ManagementDevice and re-enable access to the
LCI.
o admin@% set ManagementDevice 1 LANHostConfigManagement IPInterface 1
Enable true IPInterfaceIPAddress 192.168.168.1 IPInterfaceSubnetMask
255.255.255.0 DHCPServerEnable true
o admin@% set ManagementDevice 1 LANEthernetInterfaceConfig 1 Enable
true
• Note: Some parameters such as TimeZone may be reverted to system defaults after this set of
operations. These parameters need to be restored to the operational values.

© 2012 SpiderCloud Wireless, Inc. Internal 19

‹
 The SCSN-9000 should be ready for use with the same configuration that was running on the
SCSN-8000. The services node will reboot. The radio nodes will automatically reboot and
connect back to the SCSN-9000 and come operational once frequency synchronization
between the radio nodes is established.

© 2012 SpiderCloud Wireless, Inc. Internal 20

‹
 9 Documentation
The SpiderCloud documentation set includes:

• The SpiderCloud System Description provides an overview of how the SpiderCloud system
fits within an operator’s network and in an enterprise, describes key features of the system,
and provides specifications for the services and radio nodes.
• The SpiderCloud Feature Description document provides an overview of the different key
features of the SpiderCloud Enterprise Radio Access Network (E-RAN) system and
highlights the feature benefits, dependencies, release history and limitations.
• The SpiderCloud OS (SCOS) Administrator Guide provides procedures for configuring the
software environment and internetworking between the services node and radio node devices.
• The SpiderCloud Services Node Hardware Installation Guide provides hardware
specifications and installation instructions.
• The SpiderCloud Radio Node Hardware Installation Guide provides hardware specifications
and installation instructions.
• The E-RAN Deployment Planning Guide provides information about planning and
dimensioning E-RAN systems.
• The SpiderCloud OS (SCOS) CLI User Guide provides an introduction to the key features
and functionalities of the SpiderCloud Command Line Interface (CLI).
• The SCOS NB Data Model Reference Guide provides details about the objects and
parameters that comprise the system configuration and operational state.
• The SpiderCloud System Commissioning Guide provides information about turning up a
SpiderCloud E-RAN with the Local Configuration Interface (LCI) graphical user interface.
• The Performance Measurements for SpiderCloud Small-Cell E-RAN provides a reference
guide to Key Performance Indicators (KPI) that monitor the health and state of the E-RAN
system.
• The E-RAN Troubleshooting Guide provides information about diagnosing and correcting
problems with installing, provisioning, administrating, and maintaining SpiderCloud
equipment and services.
• The SpiderNet Management System Installation and Administration Guide provides
information about installing the SpiderNet network management server and client and using
it to remotely manage E-RAN deployments.
• The SpiderCloud Time Zone Reference Guide provides the information required to configure
the time zone for SpiderCloud services nodes.

SpiderCloud Wireless is based in San Jose, California and is backed by investors Charles River Ventures, Matrix Partners, Opus Capital
and Shasta Ventures. For more information, follow the company on twitter at www.twitter.com/spidercloud_inc or visit www.spidercloud.com

SpiderCloud Wireless is a registered trademark and SmartCloud a trademark of SpiderCloud Wireless, Inc.
©2013 SpiderCloud Wireless, Inc. v040813

© 2012 SpiderCloud Wireless, Inc. Internal 21