ASCOM Myco 3 User manual

TROUBLESHOOTING GUIDE
Ascom Myco 3

TROUBLESHOOTING GUIDE
Ascom Myco 3
Trademarks
Ascom Myco™ is a trademark of Ascom (Sweden) AB.
Android ™, Google ™, Google play ™ and other marks are trademarks of Google LLC.
TD 93297EN / 19 December 2019 / Ver. B

TROUBLESHOOTING GUIDE
Ascom Myco 3
Abbreviations and Glossary
Abbreviations and Glossary
API Application Programming Interface
PCAP Packet CAPture
VoIP Voice over IP
RPCAP Remote Packet CAPture
WiFi Family of radio technologies that is commonly used for the wireless local area
networking (WLAN).
Used generically when referring to any type of 802.11 network.
WLAN Wireless Local Area Network
A type of LAN in which data is sent and received via high-frequency radio
waves rather than cables or wires.
VoWiFi Voice over WiFi
Refers to a system running VoIP over WLAN.
AP Access Point
BSS Basic Service Set
BSSID Basic Service Set Identifier
MDM Mobile Device Management.
DHCP Dynamic Host Configuration Protocol
A protocol for automating the configuration of computers that use TCP/IP.
DNS Domain Name Server
UDP User Datagram Protocol
TCP Transmission Control Protocol
IP Internet Protocol
Global standard that specifies the format of datagrams and the addressing
scheme. This is the principal communications protocol in the Internet Protocol
suite.
MAC Medium Access Control
In IEEE 802 LAN/MAN standards, the MAC sublayer is the layer that controls
the hardware responsible for interaction with the wired, optical or wireless
transmission medium.
TD 93297EN / 19 December 2019 / Ver. B

TROUBLESHOOTING GUIDE
Ascom Myco 3
SIP Session Initiation Protocol
SIP is a signaling protocol used for initiating, maintaining, and terminating real-
time sessions that include voice, video and messaging applications. SIP is
used for applications of Internet telephony for voice and video calls, in private
IP telephone systems, in instant messaging over IP networks, and in mobile
phone calling over LTE, Voice over LTE (VoLTE).
SSID Service Set Identifier
PBX Private Branch Exchange
A telephone system within an enterprise that switches calls between local
lines, and allows all users to share a certain number of external lines.
Also referred to as Call Manager.
PSTN Public Switched Telephone Network.
OSI Open Systems Interconnection
USB Universal Serial Bus: a serial bus standard to interface devices, for example
connect computer peripherals such as mice, keyboards, scanners etc.
RF Radio Frequency
DTIM Delivery Traffic Indication Message
NFC Near Field Communication
A set of communication protocols that enable two devices to establish
communication by bringing them within close proximity of each other.
TD 93297EN / 19 December 2019 / Ver. B

TROUBLESHOOTING GUIDE
Ascom Myco 3
Contents
1 Abo t This Doc ment ..................................................................................................................... 1
1.1 Target Group...................................................................................................................... 1
1.2 Prerequisites ...................................................................................................................... 1
1.3 Information Required by TAC ...............................................................................................2
2 Tro bleshooting Methodology........................................................................................................3
3 WLAN Overview.............................................................................................................................4
3.1 The Problem of Legacy WLANs ............................................................................................4
3.2 WLAN Planning and Provisioning..........................................................................................5
3.3 The Importance of Pre- and Post-Site Surveys........................................................................6
3.4 WLAN Dynamics .................................................................................................................6
3.5 Troubleshooting Implications and WLAN Design ....................................................................6
4 The Handset as a WLAN Wireless Client..........................................................................................8
4.1 VoWiFi Handset Protocol Layers...........................................................................................8
4.1.1 Troubleshooting the Layers ....................................................................................9
4.2 Voice Transmission over a VoWiFi System .......................................................................... 10
4.3 AP Scanning..................................................................................................................... 10
4.3.1 Active Scanning................................................................................................... 10
4.3.2 Passive Scanning................................................................................................. 10
4.3.3 Reconnect............................................................................................................ 11
4.3.4 Configured Channels and Scanning Intervals........................................................... 11
4.4 Power Save Mode.............................................................................................................. 11
4.5 Roaming............................................................................................................................ 11
4.5.1 Call Mode ........................................................................................................... 12
4.5.2 Scanning Algorithm.............................................................................................. 12
4.6 DFS Channel Probing ........................................................................................................ 12
4.7 Wi-Fi Configuration Recommendations.................................................................................13
5 Tro bleshooting Tools ................................................................................................................. 15
5.1 Site Survey Tools .............................................................................................................. 15
5.1.1 Wi-Fi Site Survey.................................................................................................. 16
5.1.2 Cellular Site Survey 1............................................................................................ 18
5.2 Protocol Analyzer Tools..................................................................................................... 19
5.3 Air Traces of 802.11 Traffic .................................................................................................20
5.4 Logging Scenarios ............................................................................................................ 21
5.5 Event Logs (Log Viewer) ....................................................................................................24
5.6 Debug with Timed Logging ................................................................................................26
5.7 Debug Using PCAP ..........................................................................................................28
5.8 Debug Using Remote PCAP...............................................................................................28
5.9 Export Logs with the Handset.............................................................................................29
5.10 Extract Log Files from the Handset .....................................................................................29
5.11 Diagnostics........................................................................................................................31
5.12 Perform a Factory Reset.....................................................................................................32
5.12.1 Factory Reset Using the Handset ..........................................................................32
5.12.2 Factory Reset via MDM.........................................................................................33
5.12.3 Hard Reset..........................................................................................................33
6 Tro bleshooting Scenarios...........................................................................................................35
6.1 Handset Errors..................................................................................................................35
6.1.1 System Related....................................................................................................35
6.1.2 Software Related .................................................................................................37
TD 93297EN / 19 December 2019 / Ver. B

TROUBLESHOOTING GUIDE
Ascom Myco 3
6.1.3 Hardware Related................................................................................................38
6.1.4 Installation and Maintenance.................................................................................43
6.2 WLAN Troubleshooting Scenarios ......................................................................................43
6.2.1 Voice Problems While Roaming.............................................................................43
6.3 Warning Messages............................................................................................................44
6.3.1 No Network Connection ......................................................................................44
6.3.2 No SIP Connection...............................................................................................47
6.3.3 Incorrect SIP Authorization Details.........................................................................48
6.3.4 No Phone Calls....................................................................................................49
7 Related Doc ments..................................................................................................................... 50
8 Doc ment History........................................................................................................................ 51
Appendix A Handset Parameters .....................................................................................................53
A.1 Article Numbers................................................................................................................53
A.2 Device Information ............................................................................................................53
Appendix B Ports............................................................................................................................55
B.1 SIP...................................................................................................................................55
B.2 Voice Traffic .....................................................................................................................55
B.3 Google Mobile Services.....................................................................................................55
B.4 Other Services..................................................................................................................55
TD 93297EN / 19 December 2019 / Ver. B

TROUBLESHOOTING GUIDE
Ascom Myco 3 About This Document
1 Abo t This Doc ment
This guide describes procedures to validate and perform troubleshooting for Ascom Myco 3 handsets. It
identifies some of the more common problem areas, and suggests approaches to troubleshooting and
investigating these problems. The guide contains detailed information about the behavior of the Ascom
Myco 3 under faulty or problematic conditions.
This version of the document provides troubleshooting procedures for Ascom Myco 3 devices running the
latest released software. Some information in this version of the document might be not applicable to the
earlier software releases, therefore it is recommended to use the latest software version (v2.X.X or later) to
get up-to-date information from this document.
This document describes features and settings for the following handset versions of Ascom Myco 3:
• Ascom Myco 3 Wi-Fi and Cellular
• Ascom Myco 3 Wi-Fi
• Ascom Myco 3 Wi-Fi and Cellular EU
• Ascom Myco 3 Wi-Fi EU
Ascom Myco 3 is referred to as the "handset" or the "device" in the manual, and can be specifically marked
with "Wi-Fi only" or "Cellular only" whenever the functionality differs between the handset versions.
1.1 Target Gro p
This document provides system administrators responsible for management and maintenance of Ascom
Myco 3 handsets with guidance about the types of problems that may occur during configuration and usage
of the devices. This guide explains the probable causes of these problems and suggests actions along with
a list of diagnostic and troubleshooting tools necessary to retrieve the existing issues.
This guide is also written with a focus on support network administrators responsible for troubleshooting
and supporting customer Voice over Wireless Fidelity (VoWiFi) systems, and the Wireless Local Area
Networks (WLANs) that support such systems. The guide may also be of considerable use to system
administrators and network planners intending to design, implement, deploy and commission a new WLAN
designed for VoWiFi access, or upgrade an existing WLAN to support a new VoWiFi system.
Many of the problems described in this guide arise because of poor provisioning and planning. In this
respect, system administrators and network planners are recommended to read the document Ascom
VoWiFi System, System planning, TD 93358EN.
1.2 Prereq isites
To gain the maximum benefit from this guide, readers should have the following:
Software
• The latest software version installed on the handset(s).
Knowledge and Experience
• How WLAN and Cellular networks function.
• Sufficient knowledge in networking concepts.
• A basic understanding of Voice over Internet Protocol (VoIP) and the VoIP Session Initiation Protocol (SIP).
• Have read Configuration Manual, Ascom Myco 3, TD 93309EN.
TD 93297EN / 19 December 2019 / Ver. B 1

About This Document
TROUBLESHOOTING GUIDE
Ascom Myco 3
• Have read other documents related to the installation, for example WLAN, or Cellular specification and
documents pertaining to the interoperability of the handset with the WLAN, or Cellular infrastructure.
1.3 Information Req ired by TAC
If an issue remains unresolved and a request needs to be opened with the Technical Assistance Centre
(TAC) team, different types of information and logs should be forwarded with regards to the area of
investigation.
Presented in the current section information includes but is not limited to the data required by TAC.
Additional information might be requested.
• The handset model.
• The handset software version (Firmware and Ascom Experience versions). For the details on the device
information, please refer to Appendix A Handset Parameters, page 53.
• The frequency of the occurrence of the error and information about how to reproduce the error, if
possible.
• A detailed description of the problem and what tests have been performed.
• The values of parameters that have been configured.
• The WLAN hardware and software versions of both controller and APs.
• If cellular version of the handset has been used, information about the cell phone provider should be
sent.
• If problems occur with Ascom Apps, for example Unite Axess app, information about the used Unite
software should be sent.
• Log files should be attached and appended with descriptions of the tests and equipment used in the
tests. For the detailed information on the types of logs that should be send, please refer to the 5.4
Logging Scenarios, page 21.
2TD 93297EN / 19 December 2019 / Ver. B

TROUBLESHOOTING GUIDE
Ascom Myco 3 Troubleshooting Methodology
2 Tro bleshooting Methodology
There are many troubleshooting models that can be used by a support engineer. These methods might
vary but all of them are oriented towards defining and isolating problem areas. There is however usually a
general approach that applies to most situations.
This guide does not describe troubleshooting theories in details, rather than presents a suggested method
that has successfully been used.
A very common method is a cycle model as illustrated below:
Yes
Yes
Yes
No
No
No
Problem reported
3. Make hypothesis
Get support
2. What´s wrong?
What’s correct?
4. Prioritize where to start
5. Test and check
Apply known fix1. Get the picture
Problem
solved?
Stuck?
Familiar
problem?
Document the
solution
•Problem reporting. Define the nature of the problems that users experience and the circumstances in
which the problems arise. For example, VoWiFi problems usually involve interruptions in the audio
stream, disconnections, distortions such as echo and clicking noises, and delays. The user experiences
that small discrete parts of the conversation are missing.
•Get the picture. Elicit additional information from the user and try to picture the context and
circumstances in which the problem occurs.
•Ascertain what is working. At an early stage of the troubleshooting process it is of high importance to
rule out the devices that are functional. Why a handset is not functioning properly might depend on the
incorrect function of several other devices.
•Form a hypothesis. Make a list of possible causes. The fault is maybe on a device not primary a part of
the solution.
•Prioritize where to start. Eliminate causes that are quick to check first and do the more time-consuming
later. Also eliminate causes that make less impact for the users first. Remember that whatever action you
take may cause an interruption in the services. Make one change at a time and if problem is not solved
unroll your new changes. Document what changes were done.
•Test and check. Make sure the appropriate tools are available for testing a proposed solution. Do not
make unauthorized modifications.
An understanding of the above model can help in the troubleshooting process. A support engineer may use
the model and ask questions and gather facts and thereby identify a single device, location or application
that might be causing the problem.
TD 93297EN / 19 December 2019 / Ver. B 3

WLAN Overview
TROUBLESHOOTING GUIDE
Ascom Myco 3
3 WLAN Overview
A WLAN enables various devices, or WLAN clients, to communicate across Radio Frequency (RF) channels
through APs. APs provide RF coverage throughout the site covered by the WLAN and this enables users,
and their devices, to move around the site without being disconnected from the network. Each AP is
identified by a hard-coded MAC address.
Initially, WLANs were designed to allow users to send and receive data from devices such as laptop
computers but increasingly WLANs are being required to support different and more demanding types of
traffic such as voice and multimedia. A VoWiFi system is illustrated in Figure 1. VoWiFi Overview, page 4.
Figure 1. VoWiFi Overview
LAN
Handsets
Location Server
Controller
optional equipment
required equipment
AP
AP
IP-PBX
3.1 The Problem of Legacy WLANs
Legacy WLAN systems were designed for transmitting data packets; support for voice and other multimedia
was never envisaged when these systems were designed, deployed and commissioned. So many
traditional cell-based WLAN topologies proved unsuitable for handling channelization issues, AP-to-AP
handoffs, and the unpredictably of system bandwidth that are introduced when VoWiFi is implemented.
Voice is very susceptible to such issues being addressed satisfactorily. A WLAN that does not support
VoWiFi but is being upgraded to do therefore requires very careful planning, design, provisioning and
hardware deployment to get the level of performance to adequately support voice. These problems are
multiplied when different traffic types such as voice, video and data all contend for the same airspace.
Adding voice to a WLAN may require radical changes of the APs placement and the amount of APs needed.
If this is not considered feasible to undertake in a current installation VoWiFi may never perform as
expected.
It follows that if a legacy WLAN is to support VoWiFi then an assessment of how suitable the WLAN is to
support VoWiFi must be made. The number and deployment of additional devices involved in the WiFi
solution must be carefully assessed. For example, the assessment should consider the adequacy of the
current deployment in meeting cell boundary requirements because adequate cell overlap is a fundamental
requirement for a voice system. The assessment should conclude with a readiness report documenting the
suitability of the WLAN for both the wired and the wireless part of the network. The required parameter
settings of the devices supporting the WiFi system should also be documented.
The following table lists some of the topics that should be included in an assessment document:
4TD 93297EN / 19 December 2019 / Ver. B

TROUBLESHOOTING GUIDE
Ascom Myco 3 WLAN Overview
Topic Comments
Are voice settings correctly set in the infrastructure,
both LAN and WLAN devices?
Voice packet must have precedence over other
types of traffic.
The assessment must check for the ability to create
an Quality of Service (QoS) solution across the
entire network.
Voice settings must be set according to vendor's
recommendation and interoperability reports.
Note: These reports provide important information
for ensuring interoperability between handsets and
vendor equipment. For further information
regarding the infrastructure, refer to the Ascom
Interoperability Reports for respective system
published on the Ascom Partner Extranet.
Is the right software version installed on the
devices?
Devices may need newer software or hotfixes to be
able to support new devices.
This is important when new features are added to
current protocols.
Is there sufficient RF coverage? Cell boundaries, cell overlap, and channel planning
are extremely important for mobile devices which
need to roam during usage.
RF coverage must be checked using Site Survey
tools.
3.2 WLAN Planning and Provisioning
To summarize, both a legacy WLAN that is to be upgraded to support VoWiFi and an entirely new WLAN
purpose build to support VoWiFi and probably other kinds of media require:
• Comprehensive site surveys and detailed maps and floor plans of the areas where the WLAN is to
provide coverage.
• Adequate provisioning of hardware, in other words, the deployment of sufficient APs in suitable locations
to meet the coverage requirements of the WLAN.
• Extensive and accurate documentation of the AP deployment using site maps and floor plans to illustrate
the deployment.
• A proper, well documented commissioning sequence including comprehensive testing.
• A rigorous acceptance procedure before the commissioning is signed off as meeting the voice, and
other, requirements, of the new or upgraded WLAN.
In addition, a legacy WLAN:
• Should have been documented properly to provide the basis and understanding implications of adding
voice.
• May require a complete reassessment of its existing infrastructure before voice is added.
TD 93297EN / 19 December 2019 / Ver. B 5

WLAN Overview
TROUBLESHOOTING GUIDE
Ascom Myco 3
3.3 The Importance of Pre- and Post-Site S rveys
Modern site survey tools are valuable for pinpointing potential RF propagation problems, especially for
large sites.
Modern site survey tools can do a lot more than just create the traditional heat maps that show the RF
coverage areas from all access points. They can display co-channel interference areas, Signal-to-noise ratio
(SNR levels), rogue access points and more.
Furthermore, most tools also include a pre-site survey WLAN CAD planning tool which a designer can use
to do a simulation of RF coverage by using building drawings for a site. This computer based plan must be
verified on place, once the APs have been installed and configured, by doing a live site survey at the site.
This pre-site survey is an aid to help the designer to plan for the placements of the APs in a new installation.
The designer should make sure that:
• The information gathered about the site is accurate and complete regarding the layout of the site.
• The materials use in the construction of the building and their effects on RF propagation are fully
appreciated.
• The types of antennas to be used and deployed are provisioned for.
• The power levels to use are fully understood.
Otherwise, the result of the survey will not accurately represent the anticipated RF propagation at the site.
Performance problems will immediately manifest themselves once the WLAN is commissioned.
If a pre-site survey was performed in the traditional way, it should be followed up with a post-site survey
after a network is deployed. This can be done by an installer requesting the site survey report and using the
report to check that the installation is optimized for voice and that AP configurations are consistent and
compliant with the vendors recommendations.
If the support engineer is subsequently required to visit a site to troubleshoot problems, he or she should
initially verify that the content of the site survey still is accurate when it comes to AP placements, traffic load,
and channel plans, etcetera. Special attention should be paid to areas where the layout of the building or
concentration of VoWiFi clients may cause problems. The site survey features built into the handset
described later in this guide are very useful in verifying the accuracy of the coverage predicted in the site
survey and can, in some situations, quickly identify holes in the RF coverage.
3.4 WLAN Dynamics
Consideration must also be made that a WLAN is not a one-time installation. It changes constantly as
people move around. The physical characteristics of the site may also change over time as furniture is
moved, office partitions are redesigned and walls are build or removed. All of these factors can affect the
propagation of RF signals.
3.5 Tro bleshooting Implications and WLAN Design
It is beyond the scope of this guide to provide information about setting up a new WLAN to accommodate
voice traffic or upgrading a legacy WLAN to do the same, except to emphasize the importance of those
issues described in previous sections. In general, the role of the support engineer should be one of
troubleshooting a system that once appeared to adequately meet the requirements of the enterprise
(otherwise it wouldn’t have been signed off) but is now experiencing problems because of physical site
changes, increasing personnel numbers, new applications and other factors that were never envisaged.
Documentation that was completed during the setting up and deployments of the new site can therefore be
a valuable reference in troubleshooting subsequent problems:
6 TD 93297EN / 19 December 2019 / Ver. B

TROUBLESHOOTING GUIDE
Ascom Myco 3 WLAN Overview
• Site maps and floor plans can indicate insufficient deployment and hence insufficient RF coverage.
• Floor plans, as long as they are regularly updated to accurately represent the actual physical layout of
the site, can indicate problems and disturbances to the RF environment that were not previously
apparent.
TD 93297EN / 19 December 2019 / Ver. B 7

The Handset as a WLAN Wireless Client
TROUBLESHOOTING GUIDE
Ascom Myco 3
4 The Handset as a WLAN Wireless Client
A handset is designed to be a part of a VoWiFi system that enables voice communication across RF
channels. RF channels are provided by APs connected to a wired LAN. Before a handset can access the
network, it must have been authenticated by the AP to verify that it is allowed to connect to the network. If
the verification is successful, the handset forms an association with the AP and communications may begin.
A Basic Service Set (BSS) is an AP and the clients that are in communications range of that AP. A client, or
handset, in the context of a WLAN becomes a member of the BSS when it becomes associated with the AP.
In the usual implementation of a permanent, or infrastructure, WLAN, a BSS can only have one AP. The MAC
address of the AP is used to uniquely identity the BSS and thereby provide the BSS identity (BSSID).
4.1 VoWiFi Handset Protocol Layers
The handset uses protocols defined in a 4 layer TCP/IP protocol stack, which has similarities to some of the
layers defined in the Open Systems Interconnection (OSI) 7 layer protocol model. A thorough understanding
of the protocols at each level is essential to understanding how data is moved across a network. A support
engineer with a good understanding of the media and the data structures and devices involved at each
level of the protocol will have a systematic view of where problems may be occurring and a methodological
approach to solving them. In addition, he or she will have a considerable armory of tools and utilities at
hand for investigating sources of trouble.
The TCP/IP protocol stack is all about data communication across a WLAN and the use of protocols such as:
•Application layer. For applications that interface with the transport layer, including Private Branch
Exchange (PBX9, Unite, Dynamic Host Name Configuration Protocol (DHCP) and Domain Name Server
(DNS).
•Transport layer. Transports User Datagram Protocol (UDP) and TCP packets. TCP ensures secure and
correct delivery of TCP packets through retransmission of lost packets, congestion throttling and error
free transmission.
•Internet layer. Assigns each networked device its logical IP address.
•Link layer (consisting of MAC and physical sublayers specified in 802.11). Defines the physical character-
istics of the carrier medium and access protocols.
The role of the handset in moving data across the network between different physical and logical entities
defined by the protocols is summarized below:
Layers Sublayers Entity Sending or
Receiving Info
Functions
Application layer - Application data packets It depends on the type of
application that is installed on the
handset:
If VoIP is used, the VoIP application
will most likely use the SIP and RTP
protocols.
Transport layer - TCP/UDP packets The handset uses TCP, or UDP as
the protocol to address packets to
be delivered to other devices like a
SIP PBX.
8 TD 93297EN / 19 December 2019 / Ver. B

TROUBLESHOOTING GUIDE
Ascom Myco 3 The Handset as a WLAN Wireless Client
Internet layer - IP packets IP addressing - APs, controllers.
Link layer MAC sublayer 802.11 frames
(Management, control and
data frames)
The handset uses the IEEE 802.11
WLAN standard protocol suit to get
access to the media and to send
packets to the AP.
Physical sublayer RF signals, digitized bit
streams
Application Level
The application layer includes the functions of OSI Application, Presentation Layer and Session Layer,
which are often referred to as a user services. TCP/UDP sockets and ports are used to describe the path
over which applications communicate. Most application level protocols are associated with one or more
port number.
The SIP protocol is an Application Layer protocol designed to be independent of the underlying Transport
Layer.
Transport Layer
TCP packets are routed using the IP addresses of WLAN network devices that may interwork with other
networks such as the internet or Public Switched Telephone Network (PSTN). In the context of the VoWiFi
system this is likely to be a VoIP gateway or IP-PBX.
The transport layer also provides congestion throttling to maximize data throughput without overwhelming
the resources of the network.
Internet Level
The Internet level provides the IP address used by network devices, and responds to UDP and TCP service
requests from the transport layer and provides network to network routing.
Link Layer - MAC and Physical S blayers
The physical sublayer and MAC sublayer, in the context of the TCP/IP model, replaces the data link and
physical layers of the OSI model with a single link layer. This means that the link layer:
• Controls how data, in the form of bit streams, is transmitted through the network on standard RF
channels. The layer is the interfaces between the RF channel and the network devices such as the APs,
and handsets. The notion of the physical layer also defines the protocols that define the characteristics
of the channels conveying data. The handset uses the standard RF channel on either the 2.4 GHz band
or the 5GHz band.
• Manages the raw bit stream data received by the AP from the handset radio, and packages the bits into
802.11 frames. 802.11 defines three kinds of frame for WLANS, one for management, one for control and
one for data. The handset uses management and control frames for AP association and authentication.
• The MAC sublayer manages the physical MAC addressing scheme by encapsulating layer 2 PDUs in a
MAC sublayer PDU. The MAC sublayer uses Address Resolution Protocol to maintain logical IP to
physical MAC address mapping of SIP servers in the call path.
4.1.1 Tro bleshooting the Layers
Understanding the layers in the TCP/IP protocol stack and how they communicate with each other is
important because it provides the support engineer with a consistent, structured and methodological
TD 93297EN / 19 December 2019 / Ver. B 9

The Handset as a WLAN Wireless Client
TROUBLESHOOTING GUIDE
Ascom Myco 3
approach to troubleshooting network issues. It enables the support engineer to adopt either a top down
approach or a bottom up approach to troubleshooting and reconciling network issues.
With top-down troubleshooting, the support engineer starts with the application layer or user services level.
Bottom-up troubleshooting involves checking the device for physical problems such as no power, a bad
cable or other physical problems. A positive response would confirm that network connectivity had been
established, in which case it is safe to conclude that connectivity up to the Network layer was successful.
The focus can now be turned to troubleshooting the upper four layers of the OSI.
4.2 Voice Transmission over a VoWiFi System
VoWiFi requires that digitized voice signals are sent over a Wi-Fi network in the form of data packets as
defined in layer 4 of the TCP/IP protocol stack. This basic requirement places a substantial overhead on a
WLAN. If a WLAN is unable to support the VoWiFi requirement consistently, or only able to provide sporadic
and irregular support, then noticeable and unacceptable levels of deterioration to the quality of the voice
service occur.
For example, if voice data packets are unable to arrive at their destinations at regular time intervals,
typically every 20 ms, distortions in the conversation are likely to occur. The VoWiFi system must also keep
packet loss, delay, and jitter within required limits to avoid a loss or reduction in the voice service.
As a voice signal travels through the VoWiFi infrastructure of APs, Ethernet switches, routers, and gateways,
packet loss, delay, and jitter can add up to reduce the signal quality, especially when the network gets
congested with traffic.
4.3 AP Scanning
When a handset is powered on or on the move, it needs to associate with an AP to be able to connect to
the wired LAN. The scanning process checks the air for the available APs to associate with and, based on
this information, the handset creates a list of candidate APs. The handset will then try to associate with the
AP with the strongest RF signal.
4.3.1 Active Scanning
Active scanning occurs when a handset actively seeks to associate with an AP and ultimately connect to a
network by transmitting 802.11 probe requests frames to APs on each of the channels the handset is
configured to use. The probe request frames contain the SSID of the network that the handset wishes to
connect to, and all APs that are configured with the same SSID return a probe response to the handset.
If the handset receives probe responses from more than one AP, it can use a number of criteria to decide
which AP too associate with. Although these criteria are vendor specific, a handset will usually select the AP
with the strongest RF signal.
4.3.2 Passive Scanning
When the handset performs passive scanning it listens (on each channel it is configured to use and at
specific intervals) for beacon frames transmitted by APs. When passively scanning for beacons, the handset
transmits no frames itself. When associated with an AP, the handset will indicate that for this AP it will go
into the power save mode while continue doing passive scanning on other channels.
10 TD 93297EN / 19 December 2019 / Ver. B

TROUBLESHOOTING GUIDE
Ascom Myco 3 The Handset as a WLAN Wireless Client
4.3.3 Reconnect
When disconnected from the Wi-Fi networking, a frequent scan period is triggered to regain the connection
if the screen is active. During the 160 second period scanning for Wi-Fi is done every ten seconds. When
the handset is in sleep mode (the screen is locked), the Wi-Fi scanning is performed approximately with a
300-seconds interval.
4.3.4 Config red Channels and Scanning Intervals
When a handset is started from power off mode the procedure to find an AP to associate with depends on
the parameter and protocol settings in the handset.
One of the default protocols that are used by the handset is 802.11d. This protocol transports regulatory
domain information based on country information stored in the AP which is sent out in the beacon. 802.11d
is not allowed in the USA.
The correct channel set up in a WLAN is quite important. The channels set up to be used by the handset on
any of the 2.4 GHz or 5GHz has impact on the performance of the handset.
To be able to detect APs when in passive scanning mode the handset must listen to each channel slightly
longer than the beacon interval, to be sure not to miss any beacon. The handset then has to switch the
radio channel and starts to listen again on the new channel.
For performance reasons when scanning, the amount of channels should be minimized and only
include the channels that are used in the WLAN.
Active scanning of the 5 GHz UNII-2 and UNII-2e, the DFS-channels are not permitted in the 802.11 standard,
so those channels will only be scanned in passive mode. If in passive scanning was determined to permit to
send traffic, an active scanning is made.
The handset can use the DFS channels, but the voice quality may be distorted. For additional
information, see the section 4.6 DFS Channel Probing, page 12.
4.4 Power Save Mode
Maintaining connection to the Access Point at all times can run the battery down significantly. Ascom Myco
3 is using legacy power save mode until there are packets to transmit or receive. If no packet transmission
has happened during the next 500 ms, the handset goes back to the power save mode.
4.5 Roaming
One of the most important design criteria for good functionality in a voice system is to deploy sufficient APs
to create adequate RF coverage throughout a site. In addition, the coverage areas provided by the
individual APs must be deployed in such a way as to allow a user to roam throughout the site without any
deterioration in the quality of an ongoing call. The user must also remain connected to the network at all
times even when the handset is in idle mode. Failure to adequately support roaming may result in audible
clicks and other disturbances in a voice call.
Roaming can be described as disconnecting from the current AP as the user moves away from it and the
signal attenuates. The user then connects to a new AP that offers an increasingly stronger signal as the
handset is carried towards it. As a user moves away from an AP of decreasing received signal strength and
towards one of increasing signal strength, it is predictable enough to be able to apply a roaming algorithm
based on the measurement of received signal strength at fixed time intervals, for example, every 4 seconds.
TD 93297EN / 19 December 2019 / Ver. B 11

The Handset as a WLAN Wireless Client
TROUBLESHOOTING GUIDE
Ascom Myco 3
The algorithm then decides where and when a handset disconnects from one AP and connects to a
different AP.
An additional factor that must be included in any roaming algorithm is to provision for sudden, large and
often unpredictable reductions in received signal strength due to some dynamic event that is introduced
into the physical environment, such as the closing of a heavily clad steel door or the handset user enters an
elevator. These events can occur between the scans performed at the fixed time intervals and cause
additional scans to be performed.
For example, consider a doorway between an associated AP and a handset, with a metal door in the open
position. If the door was momentarily closed and then opened, there might be a sudden 16bB reduction in
received signal strength and a rapid loss in communication. However, this would be largely restored once
the door was opened again and make an extra scan unnecessary and a waste of network resources.
However, if the door was left closed, the loss in received signal strength would be sustained and probably
worsen as the user moved away from the AP. An extra scan would therefore be justified.
4.5.1 Call Mode
In call mode, received signal strength is very important for ensuring voice quality, particularly if the user is
moving around the site. To improve roaming while in a call, the handset will periodically scan for better AP
candidates if it detects traffic in voice or video queue above a threshold level. The threshold level is set to
10 packets with a 5- second interval, which is then defined as a scan interval.
4.5.2 Scanning Algorithm
Ascom Myco 3 scans for new APs according to a RSSI-based roaming-scan trigger:
Case Scans
During the call Periodic scan with aprox. 5sec. interval.
Not in call RSSI low periodic scan with aprox. 10sec. interval.
Additional Scans
The handset may perform additional scans and roam decisions when a drop is detected in RSSI both in call
and non-call modes.
4.6 DFS Channel Probing
The 5 GHz band supports a minimum of 21 non-overlapping channels and potentially a few more depending
on different regulatory domains. The following table, for example, shows the channels supported in the ETSI
regulatory domain:
Band Channel
UNII-1 36, 40, 44, 48
UNII-2 52, 56, 60, 64
UNII-2e 100, 104, 108, 112, 116, 120,124, 128, 132, 136, 140,
144 1
UNII-3 149, 153, 157, 161, 165
12 TD 93297EN / 19 December 2019 / Ver. B
1. Channel 144 is slightly outside the specified band (5.710–5.730 GHz).

TROUBLESHOOTING GUIDE
Ascom Myco 3 The Handset as a WLAN Wireless Client
The radio channels in the UNII-2 and UNII-2e bands are DFS-channels, which may be used by civilian and
military radar such as aviation and weather radar. Because radar always has a higher priority than a WLAN,
additional procedures must be employed to prevent LAN devices from interfering with radar when the radar
is using the DFS channels. This can increase latency and degrade the performance in a WLAN.
A client that does not support radar detection is not allowed to actively scan for APs in the DFS channels.
The client is only allowed to perform passive scanning, which means that it can only listen for beacons. For a
voice client, this will affect an ongoing call to some degree by introducing a slight increase in jitter in the
voice stream.
The handset can use the Dynamic Frequency Selection (DFS) channels in a voice enabled WLAN, but the
voice quality can be distorted as the DFS channels must be treated differently in the scanning process.
The probing process above is repeated each time the handset needs to find roaming candidates, that
means, when the signal quality on its current associated AP decreases.
Another reason that the use of DFS channels is not recommended in areas where radar may be operating, is
the requirement of automatic switching of channels and the non-service time gap that occurs. Note that
radar can be airborne, for example, used by aircraft for navigational purposes.
The regulations for using 5 GHz channels, generally known as DFS channels, in which radar operates, is that
the handset uses a different approach while scanning.
The DFS regulations require that Wi-Fi devices should check for radar that is currently operating before they
initiate a session. This requires special software features and is normally only included in APs, which are the
devices that are set to use a specific channel. If a radar signal is detected, the AP should invoke a special
procedure to automatically move to another channel. During this transfer to another channel, which takes a
while, the transmission of packets in that cell is stopped and as a result the call can be lost.
Portable devices, like a handset, are not able to detect radar and thus are not allowed to initiate a conversa-
tion. Active probing on the DFS channels is therefore prohibited until it has been determined that no radar is
present.
To detect an AP to roam to, the handset has to use passive scanning which means it has to listen to beacons
on every configured channel.
The default beacon period in most APs is set 102.4ms. Using a short scanning interval of let's say 20ms on a
channel the handset’s chances of hearing a beacon is about one in five. To improve the chances of the
handset picking up a beacon the listening time on a channel can be extended or the beacon period made
shorter.
For the DFS channels the passive listening time for the handset is set up to 110ms, during which the handset
may or may not hear a beacon. If the handset hears a beacon during this period or if the time period expires,
it will immediately return to its currently working channel and exchange packets with the current AP that was
buffered during the scanning process.
Since scanning for many channels takes a considerable time, it is important that the channels used
in the scanning process are only those channels that have been setup for use in the WLAN system.
4.7 Wi-Fi Config ration Recommendations
This sections gives key configuration recommendations on how to create an optimized Wi-Fi environment
to enhance audio and voice performances as well as delivery of mission-critical data.
TD 93297EN / 19 December 2019 / Ver. B 13

The Handset as a WLAN Wireless Client
TROUBLESHOOTING GUIDE
Ascom Myco 3
The list of recommendations includes the following:
1. Limit the number of channels to scan in order to shorten the scan time and improve both the handset
and the system performance:
− Enable 802.11k in infrastructure.
When 802.11k is used, each AP holds a list of the channels used by its neighbours, and sends this list
to newly associated clients. Then the handset only needs to scan the channels present in the latest
received Neighbour List when trying to roam from an AP. In this setup, a full scan of all channels will
only be performed if the Ascom Myco 3 has failed to find a roaming candidate in the Neighbour List.
It is of vital importance to the roaming performance that the APs deliver a good quality
Neighbour List when 802.11k is used.
Similar functionality is achieved with the part in 802.11v standard called BSS Transition
Management. With this functionality the handset will ask the AP for the best roaming
candidates and then scan in a way similar to when receiving a neighbour list.
− The amount of channels enabled on the handset should be minimized to the channels that are used
in the WLAN system. For information on how to limit the amount of channels, please refer to
Configuration Manual, Ascom Myco 3, TD 93309EN.
− Only use a limited number of channels for all AP in the installation, preferably limit the amount upto
eight channels. This is especially important when 802.11k is not used.
2. If possible, avoid using DFS channels where only time-consuming passive scanning can be performed.
3. If possible, avoid using channel bonding i.e. 40 or 80 MHz channels, as it will increase the use of DFS
channels as well as increase the scan time.
4. Use 802.11r fast roaming to ensure lowest roaming times and best audio performance when moving
between APs.
The table below gives an overview of the configuration recommendations to achieve optimal performance
for VoWiFi and/ or transmission of critical mission data.
VoWiFi and / or mission-critical data
802.11 krv Number of
channels1
DFS Channel
bonding
Band 802.11ac
Optimal Used Limited to 8 Not used Not used 5GHz Used
Allowed Used Limited Used as few
as possible
Preferably
not used
5GHz and
2.4GHz
Used
Not optimal Not used Not limited Used Used 5GHz and
2.4GHz
Not used
1. Regardless of number of channels used, the amount of channels enabled on the handset should be minimized to the channels
that are used in the WLAN system. For information on how to limit the amount of channels, please refer to Configuration Manual,
Ascom Myco 3, TD 93309EN.
14 TD 93297EN / 19 December 2019 / Ver. B