ascom myco 3 - businesscom

TROUBLESHOOTING GUIDE

Ascom Myco 3

TROUBLESHOOTING GUIDEAscom 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


Abbreviations and GlossaryAbbreviations 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 areanetworking (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 radiowaves 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 addressingscheme. This is the principal communications protocol in the Internet Protocolsuite.

MAC Medium Access Control

In IEEE 802 LAN/MAN standards, the MAC sublayer is the layer that controlsthe hardware responsible for interaction with the wired, optical or wirelesstransmission medium.



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 isused for applications of Internet telephony for voice and video calls, in privateIP telephone systems, in instant messaging over IP networks, and in mobilephone 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 locallines, 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 exampleconnect 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 establishcommunication by bringing them within close proximity of each other.



Contents

1 About This Document ..................................................................................................................... 11.1 Target Group ..... .. . .. . . .. . .. . . .. . .. . . .. . . .. . .. . . .. . .. . . .. . .. . . .. . . .. . .. . . .. . .. . . .. . .. . . .. . . .. . .. . . .. . .. . . .. . .. . . .. . . .. . .. . . .. . .. . 11.2 Prerequisites .... . .. . .. . . .. . .. . . .. . .. . . .. . . .. . .. . . .. . .. . . .. . .. . . .. . . .. . .. . . .. . .. . . .. . .. . . .. . . .. . .. . . .. . .. . . .. . .. . . .. . . .. . .. . . .. . .. . 11.3 Information Required by TAC ..... . . .. . .. . . .. . .. . . .. . .. . . .. . . .. . .. . . .. . .. . . .. . .. . . .. . . .. . .. . . .. . .. . . .. . .. . . .. . . .. . .. . . .. . .. .2

2 Troubleshooting Methodology ........................................................................................................3

3 WLAN Overview.............................................................................................................................43.1 The Problem of Legacy WLANs ...... . .. . . .. . .. . . .. . .. . . .. . . .. . .. . . .. . .. . . .. . .. . . .. . . .. . .. . . .. . .. . . .. . .. . . .. . . .. . .. . . .. . .. .43.2 WLAN Planning and Provisioning..... .. . . .. . .. . . .. . .. . . .. . . .. . .. . . .. . .. . . .. . .. . . .. . . .. . .. . . .. . .. . . .. . .. . . .. . . .. . .. . . .. . .. .53.3 The Importance of Pre- and Post-Site Surveys.... . .. . . .. . .. . . .. . .. . . .. . .. . . .. . . .. . .. . . .. . .. . . .. . .. . . .. . . .. . .. . . .. . .. .63.4 WLAN Dynamics ..... . . .. . .. . . .. . .. . . .. . . .. . .. . . .. . .. . . .. . .. . . .. . . .. . .. . . .. . .. . . .. . .. . . .. . . .. . .. . . .. . .. . . .. . .. . . .. . . .. . .. . . .. . .. .63.5 Troubleshooting Implications and WLAN Design ..... .. . .. . . .. . .. . . .. . .. . . .. . . .. . .. . . .. . .. . . .. . .. . . .. . . .. . .. . . .. . .. .6

4 The Handset as a WLAN Wireless Client ..........................................................................................84.1 VoWiFi Handset Protocol Layers..... . .. . . .. . .. . . .. . .. . . .. . . .. . .. . . .. . .. . . .. . .. . . .. . . .. . .. . . .. . .. . . .. . .. . . .. . . .. . .. . . .. . .. .8

4.1.1 Troubleshooting the Layers ..... . .. . . .. . .. . . .. . . .. . .. . . .. . .. . . .. . .. . . .. . . .. . .. . . .. . .. . . .. . .. . . .. . . .. . .. . . .. . .. .94.2 Voice Transmission over a VoWiFi System ..... .. . . .. . . .. . .. . . .. . .. . . .. . .. . . .. . . .. . .. . . .. . .. . . .. . .. . . .. . . .. . .. . . .. . . 104.3 AP Scanning ..... . .. . .. . . .. . .. . . .. . .. . . .. . . .. . .. . . .. . .. . . .. . .. . . .. . . .. . .. . . .. . .. . . .. . .. . . .. . . .. . .. . . .. . .. . . .. . .. . . .. . . .. . .. . . .. . . 10

4.3.1 Active Scanning..... .. . . .. . . .. . .. . . .. . .. . . .. . .. . . .. . . .. . .. . . .. . .. . . .. . .. . . .. . . .. . .. . . .. . .. . . .. . .. . . .. . . .. . .. . . .. . . 104.3.2 Passive Scanning..... . . .. . . .. . .. . . .. . .. . . .. . .. . . .. . . .. . .. . . .. . .. . . .. . .. . . .. . . .. . .. . . .. . .. . . .. . .. . . .. . . .. . .. . . .. . . 104.3.3 Reconnect..... . .. . . .. . .. . . .. . . .. . .. . . .. . .. . . .. . .. . . .. . . .. . .. . . .. . .. . . .. . .. . . .. . . .. . .. . . .. . .. . . .. . .. . . .. . . .. . .. . . .. . .. 114.3.4 Configured Channels and Scanning Intervals.... .. . .. . . .. . .. . . .. . . .. . .. . . .. . .. . . .. . .. . . .. . . .. . .. . . .. . .. 11

4.4 Power Save Mode ..... .. . .. . . .. . .. . . .. . . .. . .. . . .. . .. . . .. . .. . . .. . . .. . .. . . .. . .. . . .. . .. . . .. . . .. . .. . . .. . .. . . .. . .. . . .. . . .. . .. . . .. . .. 114.5 Roaming...... . . .. . . .. . .. . . .. . .. . . .. . .. . . .. . . .. . .. . . .. . .. . . .. . .. . . .. . . .. . .. . . .. . .. . . .. . .. . . .. . . .. . .. . . .. . .. . . .. . .. . . .. . . .. . .. . . .. . .. 11

4.5.1 Call Mode ..... . .. . . .. . .. . . .. . . .. . .. . . .. . .. . . .. . .. . . .. . . .. . .. . . .. . .. . . .. . .. . . .. . . .. . .. . . .. . .. . . .. . .. . . .. . . .. . .. . . .. . . 124.5.2 Scanning Algorithm...... . . .. . .. . . .. . .. . . .. . .. . . .. . . .. . .. . . .. . .. . . .. . .. . . .. . . .. . .. . . .. . .. . . .. . .. . . .. . . .. . .. . . .. . . 12

4.6 DFS Channel Probing ..... . . .. . .. . . .. . . .. . .. . . .. . .. . . .. . .. . . .. . . .. . .. . . .. . .. . . .. . .. . . .. . . .. . .. . . .. . .. . . .. . .. . . .. . . .. . .. . . .. . . 124.7 Wi-Fi Configuration Recommendations.... .. . . .. . .. . . .. . . .. . .. . . .. . .. . . .. . .. . . .. . . .. . .. . . .. . .. . . .. . .. . . .. . . .. . .. . . .. . ..13

5 Troubleshooting Tools ................................................................................................................. 155.1 Site Survey Tools .... . . .. . .. . . .. . .. . . .. . . .. . .. . . .. . .. . . .. . .. . . .. . . .. . .. . . .. . .. . . .. . .. . . .. . . .. . .. . . .. . .. . . .. . .. . . .. . . .. . .. . . .. . . 15

5.1.1 Wi-Fi Site Survey.... .. . . .. . . .. . .. . . .. . .. . . .. . .. . . .. . . .. . .. . . .. . .. . . .. . .. . . .. . . .. . .. . . .. . .. . . .. . .. . . .. . . .. . .. . . .. . . 165.1.2 Cellular Site Survey 1 .... . . .. . .. . . .. . .. . . .. . .. . . .. . . .. . .. . . .. . .. . . .. . .. . . .. . . .. . .. . . .. . .. . . .. . .. . . .. . . .. . .. . . .. . . 18

5.2 Protocol Analyzer Tools .... .. . .. . . .. . . .. . .. . . .. . .. . . .. . .. . . .. . . .. . .. . . .. . .. . . .. . .. . . .. . . .. . .. . . .. . .. . . .. . .. . . .. . . .. . .. . . .. . . 195.3 Air Traces of 802.11 Traffic ..... . . .. . . .. . .. . . .. . .. . . .. . .. . . .. . . .. . .. . . .. . .. . . .. . .. . . .. . . .. . .. . . .. . .. . . .. . .. . . .. . . .. . .. . . .. . .205.4 Logging Scenarios .... .. . .. . . .. . .. . . .. . . .. . .. . . .. . .. . . .. . .. . . .. . . .. . .. . . .. . .. . . .. . .. . . .. . . .. . .. . . .. . .. . . .. . .. . . .. . . .. . .. . . .. . . 215.5 Event Logs (Log Viewer) ... .. . .. . . .. . . .. . .. . . .. . .. . . .. . .. . . .. . . .. . .. . . .. . .. . . .. . .. . . .. . . .. . .. . . .. . .. . . .. . .. . . .. . . .. . .. . . .. . .245.6 Debug with Timed Logging ..... . .. . . .. . .. . . .. . .. . . .. . .. . . .. . . .. . .. . . .. . .. . . .. . .. . . .. . . .. . .. . . .. . .. . . .. . .. . . .. . . .. . .. . . .. . .265.7 Debug Using PCAP ..... .. . . .. . .. . . .. . . .. . .. . . .. . .. . . .. . .. . . .. . . .. . .. . . .. . .. . . .. . .. . . .. . . .. . .. . . .. . .. . . .. . .. . . .. . . .. . .. . . .. . .285.8 Debug Using Remote PCAP ..... .. . . .. . .. . . .. . .. . . .. . .. . . .. . . .. . .. . . .. . .. . . .. . .. . . .. . . .. . .. . . .. . .. . . .. . .. . . .. . . .. . .. . . .. . .285.9 Export Logs with the Handset..... . . .. . .. . . .. . .. . . .. . .. . . .. . . .. . .. . . .. . .. . . .. . .. . . .. . . .. . .. . . .. . .. . . .. . .. . . .. . . .. . .. . . .. . .295.10 Extract Log Files from the Handset .... . . .. . .. . . .. . .. . . .. . . .. . .. . . .. . .. . . .. . .. . . .. . . .. . .. . . .. . .. . . .. . .. . . .. . . .. . .. . . .. . .295.11 Diagnostics.... .. . . .. . .. . . .. . .. . . .. . .. . . .. . . .. . .. . . .. . .. . . .. . .. . . .. . . .. . .. . . .. . .. . . .. . .. . . .. . . .. . .. . . .. . .. . . .. . .. . . .. . . .. . .. . . .. . ..315.12 Perform a Factory Reset.... .. . .. . . .. . . .. . .. . . .. . .. . . .. . .. . . .. . . .. . .. . . .. . .. . . .. . .. . . .. . . .. . .. . . .. . .. . . .. . .. . . .. . . .. . .. . . .. . .32

5.12.1 Factory Reset Using the Handset .... . .. . . .. . . .. . .. . . .. . .. . . .. . .. . . .. . . .. . .. . . .. . .. . . .. . .. . . .. . . .. . .. . . .. . .325.12.2 Factory Reset via MDM..... . .. . . .. . .. . . .. . .. . . .. . . .. . .. . . .. . .. . . .. . .. . . .. . . .. . .. . . .. . .. . . .. . .. . . .. . . .. . .. . . .. . .335.12.3 Hard Reset .... . .. . . .. . .. . . .. . . .. . .. . . .. . .. . . .. . .. . . .. . . .. . .. . . .. . .. . . .. . .. . . .. . . .. . .. . . .. . .. . . .. . .. . . .. . . .. . .. . . .. . .33

6 Troubleshooting Scenarios ...........................................................................................................356.1 Handset Errors..... . .. . . .. . .. . . .. . .. . . .. . . .. . .. . . .. . .. . . .. . .. . . .. . . .. . .. . . .. . .. . . .. . .. . . .. . . .. . .. . . .. . .. . . .. . .. . . .. . . .. . .. . . .. . .35

6.1.1 System Related..... . .. . . .. . . .. . .. . . .. . .. . . .. . .. . . .. . . .. . .. . . .. . .. . . .. . .. . . .. . . .. . .. . . .. . .. . . .. . .. . . .. . . .. . .. . . .. . .356.1.2 Software Related ..... . . .. . . .. . .. . . .. . .. . . .. . .. . . .. . . .. . .. . . .. . .. . . .. . .. . . .. . . .. . .. . . .. . .. . . .. . .. . . .. . . .. . .. . . .. . . 37



6.1.3 Hardware Related..... . .. . . .. . .. . . .. . .. . . .. . .. . . .. . . .. . .. . . .. . .. . . .. . .. . . .. . . .. . .. . . .. . .. . . .. . .. . . .. . . .. . .. . . .. . .386.1.4 Installation and Maintenance..... .. . . .. . .. . . .. . . .. . .. . . .. . .. . . .. . .. . . .. . . .. . .. . . .. . .. . . .. . .. . . .. . . .. . .. . . .. . .43

6.2 WLAN Troubleshooting Scenarios ..... . . .. . .. . . .. . .. . . .. . . .. . .. . . .. . .. . . .. . .. . . .. . . .. . .. . . .. . .. . . .. . .. . . .. . . .. . .. . . .. . .436.2.1 Voice Problems While Roaming..... .. . .. . . .. . . .. . .. . . .. . .. . . .. . .. . . .. . . .. . .. . . .. . .. . . .. . .. . . .. . . .. . .. . . .. . .43

6.3 Warning Messages...... . .. . . .. . .. . . .. . . .. . .. . . .. . .. . . .. . .. . . .. . . .. . .. . . .. . .. . . .. . .. . . .. . . .. . .. . . .. . .. . . .. . .. . . .. . . .. . .. . . .. . .446.3.1 No Network Connection ..... . . .. . .. . . .. . .. . . .. . . .. . .. . . .. . .. . . .. . .. . . .. . . .. . .. . . .. . .. . . .. . .. . . .. . . .. . .. . . .. . .446.3.2 No SIP Connection.... . .. . . .. . .. . . .. . .. . . .. . .. . . .. . . .. . .. . . .. . .. . . .. . .. . . .. . . .. . .. . . .. . .. . . .. . .. . . .. . . .. . .. . . .. . . 476.3.3 Incorrect SIP Authorization Details.... .. . . .. . . .. . .. . . .. . .. . . .. . .. . . .. . . .. . .. . . .. . .. . . .. . .. . . .. . . .. . .. . . .. . .486.3.4 No Phone Calls..... . .. . . .. . . .. . .. . . .. . .. . . .. . .. . . .. . . .. . .. . . .. . .. . . .. . .. . . .. . . .. . .. . . .. . .. . . .. . .. . . .. . . .. . .. . . .. . .49

7 Related Documents..................................................................................................................... 50

8 Document History ........................................................................................................................ 51

Appendix A Handset Parameters .....................................................................................................53A.1 Article Numbers .... .. . . .. . .. . . .. . .. . . .. . . .. . .. . . .. . .. . . .. . .. . . .. . . .. . .. . . .. . .. . . .. . .. . . .. . . .. . .. . . .. . .. . . .. . .. . . .. . . .. . .. . . .. . .53A.2 Device Information .... .. . .. . . .. . .. . . .. . . .. . .. . . .. . .. . . .. . .. . . .. . . .. . .. . . .. . .. . . .. . .. . . .. . . .. . .. . . .. . .. . . .. . .. . . .. . . .. . .. . . .. . .53

Appendix B Ports ............................................................................................................................55B.1 SIP.... . .. . . .. . .. . . .. . . .. . .. . . .. . .. . . .. . .. . . .. . . .. . .. . . .. . .. . . .. . .. . . .. . . .. . .. . . .. . .. . . .. . .. . . .. . . .. . .. . . .. . .. . . .. . .. . . .. . . .. . .. . . .. . .55B.2 Voice Traffic .... . . .. . .. . . .. . .. . . .. . .. . . .. . . .. . .. . . .. . .. . . .. . .. . . .. . . .. . .. . . .. . .. . . .. . .. . . .. . . .. . .. . . .. . .. . . .. . .. . . .. . . .. . .. . . .. . .55B.3 Google Mobile Services .... .. . .. . . .. . . .. . .. . . .. . .. . . .. . .. . . .. . . .. . .. . . .. . .. . . .. . .. . . .. . . .. . .. . . .. . .. . . .. . .. . . .. . . .. . .. . . .. . .55B.4 Other Services ..... . .. . . .. . .. . . .. . .. . . .. . . .. . .. . . .. . .. . . .. . .. . . .. . . .. . .. . . .. . .. . . .. . .. . . .. . . .. . .. . . .. . .. . . .. . .. . . .. . . .. . .. . . .. . .55


TROUBLESHOOTING GUIDEAscom Myco 3 About This Document

1 About This Document

This guide describes procedures to validate and perform troubleshooting for Ascom Myco 3 handsets. Itidentifies some of the more common problem areas, and suggests approaches to troubleshooting andinvestigating these problems. The guide contains detailed information about the behavior of the AscomMyco 3 under faulty or problematic conditions.

This version of the document provides troubleshooting procedures for Ascom Myco 3 devices running thelatest released software. Some information in this version of the document might be not applicable to theearlier software releases, therefore it is recommended to use the latest software version (v2.X.X or later) toget 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 markedwith "Wi-Fi only" or "Cellular only" whenever the functionality differs between the handset versions.

1.1 Target Group

This document provides system administrators responsible for management and maintenance of AscomMyco 3 handsets with guidance about the types of problems that may occur during configuration and usageof the devices. This guide explains the probable causes of these problems and suggests actions along witha 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 troubleshootingand supporting customer Voice over Wireless Fidelity (VoWiFi) systems, and the Wireless Local AreaNetworks (WLANs) that support such systems. The guide may also be of considerable use to systemadministrators and network planners intending to design, implement, deploy and commission a new WLANdesigned 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 thisrespect, system administrators and network planners are recommended to read the document AscomVoWiFi System, System planning, TD 93358EN.

1.2 Prerequisites

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


• Have read other documents related to the installation, for example WLAN, or Cellular specification anddocuments pertaining to the interoperability of the handset with the WLAN, or Cellular infrastructure.

1.3 Information Required 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 ofinvestigation.

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 deviceinformation, 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, ifpossible.

• 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 besent.

• If problems occur with Ascom Apps, for example Unite Axess app, information about the used Unitesoftware should be sent.

• Log files should be attached and appended with descriptions of the tests and equipment used in thetests. For the detailed information on the types of logs that should be send, please refer to the 5.4Logging Scenarios, page 21.

2 TD 93297EN / 19 December 2019 / Ver. B

TROUBLESHOOTING GUIDEAscom Myco 3 Troubleshooting Methodology

2 Troubleshooting Methodology

There are many troubleshooting models that can be used by a support engineer. These methods mightvary but all of them are oriented towards defining and isolating problem areas. There is however usually ageneral approach that applies to most situations.

This guide does not describe troubleshooting theories in details, rather than presents a suggested methodthat 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

Problemsolved?

Stuck?

Familiarproblem?

Document thesolution

• Problem reporting. Define the nature of the problems that users experience and the circumstances inwhich the problems arise. For example, VoWiFi problems usually involve interruptions in the audiostream, disconnections, distortions such as echo and clicking noises, and delays. The user experiencesthat small discrete parts of the conversation are missing.

• Get the picture. Elicit additional information from the user and try to picture the context andcircumstances in which the problem occurs.

• Ascertain what is working. At an early stage of the troubleshooting process it is of high importance torule out the devices that are functional. Why a handset is not functioning properly might depend on theincorrect 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 ofthe solution.

• Prioritize where to start. Eliminate causes that are quick to check first and do the more time-consuminglater. Also eliminate causes that make less impact for the users first. Remember that whatever action youtake may cause an interruption in the services. Make one change at a time and if problem is not solvedunroll your new changes. Document what changes were done.

• Test and check. Make sure the appropriate tools are available for testing a proposed solution. Do notmake unauthorized modifications.

An understanding of the above model can help in the troubleshooting process. A support engineer may usethe model and ask questions and gather facts and thereby identify a single device, location or applicationthat might be causing the problem.


WLAN Overview


3 WLAN Overview

A WLAN enables various devices, or WLAN clients, to communicate across Radio Frequency (RF) channelsthrough 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 isidentified by a hard-coded MAC address.

Initially, WLANs were designed to allow users to send and receive data from devices such as laptopcomputers but increasingly WLANs are being required to support different and more demanding types oftraffic 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 multimediawas never envisaged when these systems were designed, deployed and commissioned. So manytraditional cell-based WLAN topologies proved unsuitable for handling channelization issues, AP-to-APhandoffs, 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 supportVoWiFi but is being upgraded to do therefore requires very careful planning, design, provisioning andhardware deployment to get the level of performance to adequately support voice. These problems aremultiplied 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 asexpected.

It follows that if a legacy WLAN is to support VoWiFi then an assessment of how suitable the WLAN is tosupport VoWiFi must be made. The number and deployment of additional devices involved in the WiFisolution must be carefully assessed. For example, the assessment should consider the adequacy of thecurrent deployment in meeting cell boundary requirements because adequate cell overlap is a fundamentalrequirement for a voice system. The assessment should conclude with a readiness report documenting thesuitability of the WLAN for both the wired and the wireless part of the network. The required parametersettings 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:


TROUBLESHOOTING GUIDEAscom 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 othertypes of traffic.

The assessment must check for the ability to createan Quality of Service (QoS) solution across theentire network.

Voice settings must be set according to vendor'srecommendation and interoperability reports.

Note: These reports provide important informationfor ensuring interoperability between handsets andvendor equipment. For further informationregarding the infrastructure, refer to the AscomInteroperability Reports for respective systempublished on the Ascom Partner Extranet.

Is the right software version installed on thedevices?

Devices may need newer software or hotfixes to beable to support new devices.

This is important when new features are added tocurrent protocols.

Is there sufficient RF coverage? Cell boundaries, cell overlap, and channel planningare extremely important for mobile devices whichneed to roam during usage.

RF coverage must be checked using Site Surveytools.

3.2 WLAN Planning and Provisioning

To summarize, both a legacy WLAN that is to be upgraded to support VoWiFi and an entirely new WLANpurpose 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 toprovide coverage.

• Adequate provisioning of hardware, in other words, the deployment of sufficient APs in suitable locationsto meet the coverage requirements of the WLAN.

• Extensive and accurate documentation of the AP deployment using site maps and floor plans to illustratethe deployment.

• A proper, well documented commissioning sequence including comprehensive testing.

• A rigorous acceptance procedure before the commissioning is signed off as meeting the voice, andother, 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 addingvoice.

• May require a complete reassessment of its existing infrastructure before voice is added.


https://www.ascom-ws.com/AscomPartnerWeb/en/startpage/Sales-tools/Interoperability/Certified-Products/Ascom-Myco-3/WLAN/

WLAN Overview


3.3 The Importance of Pre- and Post-Site Surveys

Modern site survey tools are valuable for pinpointing potential RF propagation problems, especially forlarge sites.

Modern site survey tools can do a lot more than just create the traditional heat maps that show the RFcoverage 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 useto do a simulation of RF coverage by using building drawings for a site. This computer based plan must beverified 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 fullyappreciated.

• 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 surveyafter a network is deployed. This can be done by an installer requesting the site survey report and using thereport to check that the installation is optimized for voice and that AP configurations are consistent andcompliant with the vendors recommendations.

If the support engineer is subsequently required to visit a site to troubleshoot problems, he or she shouldinitially 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 orconcentration of VoWiFi clients may cause problems. The site survey features built into the handsetdescribed later in this guide are very useful in verifying the accuracy of the coverage predicted in the sitesurvey 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 aspeople move around. The physical characteristics of the site may also change over time as furniture ismoved, office partitions are redesigned and walls are build or removed. All of these factors can affect thepropagation of RF signals.

3.5 Troubleshooting Implications and WLAN Design

It is beyond the scope of this guide to provide information about setting up a new WLAN to accommodatevoice traffic or upgrading a legacy WLAN to do the same, except to emphasize the importance of thoseissues described in previous sections. In general, the role of the support engineer should be one oftroubleshooting 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 sitechanges, 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 bea valuable reference in troubleshooting subsequent problems:


TROUBLESHOOTING GUIDEAscom 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 ofthe site, can indicate problems and disturbances to the RF environment that were not previouslyapparent.


The Handset as a WLAN Wireless Client


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 RFchannels. RF channels are provided by APs connected to a wired LAN. Before a handset can access thenetwork, it must have been authenticated by the AP to verify that it is allowed to connect to the network. Ifthe 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, orhandset, 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 MACaddress 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 thelayers defined in the Open Systems Interconnection (OSI) 7 layer protocol model. A thorough understandingof the protocols at each level is essential to understanding how data is moved across a network. A supportengineer with a good understanding of the media and the data structures and devices involved at eachlevel of the protocol will have a systematic view of where problems may be occurring and a methodologicalapproach to solving them. In addition, he or she will have a considerable armory of tools and utilities athand 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 BranchExchange (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 andcorrect delivery of TCP packets through retransmission of lost packets, congestion throttling and errorfree 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 entitiesdefined by the protocols is summarized below:

Layers Sublayers Entity Sending orReceiving Info

Functions

Application layer - Application data packets It depends on the type ofapplication that is installed on thehandset:

If VoIP is used, the VoIP applicationwill most likely use the SIP and RTPprotocols.

Transport layer - TCP/UDP packets The handset uses TCP, or UDP asthe protocol to address packets tobe delivered to other devices like aSIP PBX.


TROUBLESHOOTING GUIDEAscom 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 anddata frames)

The handset uses the IEEE 802.11WLAN standard protocol suit to getaccess to the media and to sendpackets to the AP.

Physical sublayer RF signals, digitized bitstreams

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 pathover which applications communicate. Most application level protocols are associated with one or moreport number.

The SIP protocol is an Application Layer protocol designed to be independent of the underlying TransportLayer.

Transport Layer

TCP packets are routed using the IP addresses of WLAN network devices that may interwork with othernetworks such as the internet or Public Switched Telephone Network (PSTN). In the context of the VoWiFisystem this is likely to be a VoIP gateway or IP-PBX.

The transport layer also provides congestion throttling to maximize data throughput without overwhelmingthe resources of the network.

Internet Level

The Internet level provides the IP address used by network devices, and responds to UDP and TCP servicerequests from the transport layer and provides network to network routing.

Link Layer - MAC and Physical Sublayers

The physical sublayer and MAC sublayer, in the context of the TCP/IP model, replaces the data link andphysical 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 RFchannels. 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 characteristicsof the channels conveying data. The handset uses the standard RF channel on either the 2.4 GHz bandor the 5GHz band.

• Manages the raw bit stream data received by the AP from the handset radio, and packages the bits into802.11 frames. 802.11 defines three kinds of frame for WLANS, one for management, one for control andone 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 aMAC sublayer PDU. The MAC sublayer uses Address Resolution Protocol to maintain logical IP tophysical MAC address mapping of SIP servers in the call path.

4.1.1 Troubleshooting the Layers

Understanding the layers in the TCP/IP protocol stack and how they communicate with each other isimportant because it provides the support engineer with a consistent, structured and methodological




approach to troubleshooting network issues. It enables the support engineer to adopt either a top downapproach 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 badcable or other physical problems. A positive response would confirm that network connectivity had beenestablished, 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 asdefined in layer 4 of the TCP/IP protocol stack. This basic requirement places a substantial overhead on aWLAN. If a WLAN is unable to support the VoWiFi requirement consistently, or only able to provide sporadicand irregular support, then noticeable and unacceptable levels of deterioration to the quality of the voiceservice 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 keeppacket 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 getscongested 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 tothe wired LAN. The scanning process checks the air for the available APs to associate with and, based onthis information, the handset creates a list of candidate APs. The handset will then try to associate with theAP 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 anetwork by transmitting 802.11 probe requests frames to APs on each of the channels the handset isconfigured to use. The probe request frames contain the SSID of the network that the handset wishes toconnect 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 decidewhich AP too associate with. Although these criteria are vendor specific, a handset will usually select the APwith 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 atspecific intervals) for beacon frames transmitted by APs. When passively scanning for beacons, the handsettransmits no frames itself. When associated with an AP, the handset will indicate that for this AP it will gointo the power save mode while continue doing passive scanning on other channels.



4.3.3 Reconnect

When disconnected from the Wi-Fi networking, a frequent scan period is triggered to regain the connectionif the screen is active. During the 160 second period scanning for Wi-Fi is done every ten seconds. Whenthe handset is in sleep mode (the screen is locked), the Wi-Fi scanning is performed approximately with a300-seconds interval.

4.3.4 Configured Channels and Scanning Intervals

When a handset is started from power off mode the procedure to find an AP to associate with depends onthe parameter and protocol settings in the handset.

One of the default protocols that are used by the handset is 802.11d. This protocol transports regulatorydomain information based on country information stored in the AP which is sent out in the beacon. 802.11dis 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 onany 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 slightlylonger than the beacon interval, to be sure not to miss any beacon. The handset then has to switch theradio channel and starts to listen again on the new channel.

For performance reasons when scanning, the amount of channels should be minimized and onlyinclude 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 tosend traffic, an active scanning is made.

The handset can use the DFS channels, but the voice quality may be distorted. For additionalinformation, 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 Myco3 is using legacy power save mode until there are packets to transmit or receive. If no packet transmissionhas 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 APsto create adequate RF coverage throughout a site. In addition, the coverage areas provided by theindividual APs must be deployed in such a way as to allow a user to roam throughout the site without anydeterioration in the quality of an ongoing call. The user must also remain connected to the network at alltimes even when the handset is in idle mode. Failure to adequately support roaming may result in audibleclicks 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 thesignal attenuates. The user then connects to a new AP that offers an increasingly stronger signal as thehandset is carried towards it. As a user moves away from an AP of decreasing received signal strength andtowards one of increasing signal strength, it is predictable enough to be able to apply a roaming algorithmbased on the measurement of received signal strength at fixed time intervals, for example, every 4 seconds.




The algorithm then decides where and when a handset disconnects from one AP and connects to adifferent AP.

An additional factor that must be included in any roaming algorithm is to provision for sudden, large andoften unpredictable reductions in received signal strength due to some dynamic event that is introducedinto the physical environment, such as the closing of a heavily clad steel door or the handset user enters anelevator. These events can occur between the scans performed at the fixed time intervals and causeadditional scans to be performed.

For example, consider a doorway between an associated AP and a handset, with a metal door in the openposition. If the door was momentarily closed and then opened, there might be a sudden 16bB reduction inreceived signal strength and a rapid loss in communication. However, this would be largely restored oncethe 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 probablyworsen 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 ismoving around the site. To improve roaming while in a call, the handset will periodically scan for better APcandidates if it detects traffic in voice or video queue above a threshold level. The threshold level is set to10 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 calland 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 dependingon different regulatory domains. The following table, for example, shows the channels supported in the ETSIregulatory 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


1. Channel 144 is slightly outside the specified band (5.710–5.730 GHz).


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 usedin the scanning process are only those channels that have been setup for use in the WLAN system.

4.7 Wi-Fi Configuration Recommendations

This sections gives key configuration recommendations on how to create an optimized Wi-Fi environmentto enhance audio and voice performances as well as delivery of mission-critical data.




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 handsetand 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 listto newly associated clients. Then the handset only needs to scan the channels present in the latestreceived Neighbour List when trying to roam from an AP. In this setup, a full scan of all channels willonly 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 qualityNeighbour List when 802.11k is used.

Similar functionality is achieved with the part in 802.11v standard called BSS TransitionManagement. With this functionality the handset will ask the AP for the best roamingcandidates 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 usedin the WLAN system. For information on how to limit the amount of channels, please refer toConfiguration Manual, Ascom Myco 3, TD 93309EN.

− Only use a limited number of channels for all AP in the installation, preferably limit the amount uptoeight 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 DFSchannels as well as increase the scan time.

4. Use 802.11r fast roaming to ensure lowest roaming times and best audio performance when movingbetween APs.

The table below gives an overview of the configuration recommendations to achieve optimal performancefor VoWiFi and/ or transmission of critical mission data.

VoWiFi and / or mission-critical data

802.11 krv Number ofchannels1

DFS Channelbonding

Band 802.11ac

Optimal Used Limited to 8 Not used Not used 5GHz Used

Allowed Used Limited Used as fewas possible

Preferablynot used

5GHz and2.4GHz

Used

Not optimal Not used Not limited Used Used 5GHz and2.4GHz

Not used

1. Regardless of number of channels used, the amount of channels enabled on the handset should be minimized to the channelsthat 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.


TROUBLESHOOTING GUIDEAscom Myco 3 Troubleshooting Tools

5 Troubleshooting Tools

This section includes information about some recommended internal and external troubleshooting tools formonitoring and analyzing data along with a list of common issues with suggested troubleshooting steps.

Build-in Troubleshooting Tools

The handset provides the following kind of built-in troubleshooting tools that present information directly onthe handset’s display:

• The site survey tool is used check information about the site that the handset operates in and thepossible RF problems caused by the layout of the site. For more information, please refer to 5.1 SiteSurvey Tools, page 15.

• The Troubleshooting menu (in the Settings > Ascom settings) is used to access debugging and loggingtools. For additional information, start reading from the 5.4 Logging Scenarios, page 21 section.

• The integrated diagnostics tool (Factory mode) is used to check the handset’s hardware status. For moreinformation, please refer to 5.11 Diagnostics, page 31.

• Android battery health (Settings > Battery) is used to monitor the device’s battery life and restrict the useof apps with high background and battery use. For more details on the feature, please refer to theAndroid help center.

External Troubleshooting Tools

A support engineer should be also equipped with a software toolbox containing additional troubleshootingtools commonly used in the trade. The toolbox should preferably contain tools for both the Wired andWireless LAN that are available from many sources like:

• WLAN and LAN infrastructure vendors: If you often work with a specific WLAN vendor it can be beneficialto learn the tools that are produced by that vendor. Some tools may be free while others are costly.

• Niche commercial software publishers: Commercial software products are often highly priced but alicense will give you support, and there are often training programs available to attend.

• Free or low cost tools that can be downloaded from the Internet.

The tools that may be used are, in general, a matter of the support engineer’s personal preference.However, when the support of the Ascom TAC team has been requested in resolving an issue,they may request information, in the form of a trace or dump, from a specific tool.

External troubleshooting tools can be divided in the groups as follows:

• VoIP tools, such as software IP-PBX and software clients, performance measurement tools.

• RF tools such as spectrum analyzers, heat mapper tools, site survey tools.

• Air trace tools. For additional information, refer to 5.3 Air Traces of 802.11 Traffic, page 20.

• Protocol Tools, for example wireless supported Protocol Analyzer (Sniffer). For additional information,refer to 5.2 Protocol Analyzer Tools, page 19.

• Report Tools.

5.1 Site Survey Tools

The handset is the recommended tool for performing a site survey to verify the VoWiFi system deployment.This provides a true measurement of the RF environment based upon the radio of the handset. Wirelessanalyzers can be used to provide additional assistance during a site survey. A laptop computer does notshare the same characteristics as a handset and should not therefore be used to perform site surveys.

The site survey can be done both for the cellular network and the Wi-Fi network using the handset.


https://support.google.com/android/answer/9079241?hl=en&ref_topic=7651006

Troubleshooting ToolsTROUBLESHOOTING GUIDE

Ascom Myco 3

5.1.1 Wi-Fi Site Survey

Ascom Myco 3 has an integrated site survey feature that can be used as a tool to debug Wi-Fi relatedproblems as well as to track information about the received signal strength, current and previouslyassociated APs. Such tool can be used during normal handset operation, as the signal monitor is displayedin Picture-in-Picture (PIP) mode.

Caution

Actual signal strength values come to the site survey tool from Android with a significantdelay (up to three seconds).

Caution must be taken when moving around the site rapidly.

The RSSI information that is shown directly on the handset display, is described in Figure 2.Wi-Fi signalmonitor explained, page 16.

Figure 2. Wi-Fi signal monitor explained

As a part of a troubleshooting procedure, it can be very useful to use third-party WiFi analyzing apps ( seeFigure 3. Site Survey third-party apps, page 17) to help create a graphical representation or heatmaps of RFsignal strengths surrounding an AP. The handset can be used to create a heatmap by sampling RF signalstrengths in the vicinity of an AP and then superimposing these values on to a building plan where theexact location of the AP is shown.



Figure 3. Site Survey third-party apps

Activate the Site Survey

The built-in site survey tool is activated from the Ascom setting menu in the following way:

1. On the handset, go into the Settings > Ascom settings > Wi-Fi.

2. Enter the password 40022 to open the settings.

3. In the opened menu, tapWi-Fi signal monitor.

4. The site survey tool will be shown in the current screen as an overlay in PIP mode.

If Wi-Fi is disabled, the site survey will display the "Wi-Fi disabled" text. With enabled but notconnected Wi-Fi, the site survey will not show any text or will show symbols.

5. To turn off the site survey, repeat the steps above and press the Back or Home button once the sitesurvey display has been expanded. Alternatively (any screen), long press the site survey overlay anddrag it down to the Drag down to dismiss tray.

Evaluate the Radio Environment

To evaluate the VoWiFi system RF environment, follow the procedure below:

1. Configure the handset for the Wi-Fi network environment, refer to the Wi-Fi chapter in ConfigurationManual, Ascom Myco 3, TD 93309EN.

2. Open the build-in or third-party Wi-Fi analyzing tool and perform a site survey.

Be sure to walk slowly. Since the value is filtered sudden drops in field strength caused by theenvironment, for example walking through a door into a room, will be delayed. Thus, it isimportant to walk slowly through the site to cover all weak spots.

Coverage and Roaming Test

The purpose of the test is to verify that the handset is able to roam between different APs without losingconnectivity or experiencing interruptions or distortions to the voice quality. The support engineer makes acall from a handset that can be physically moved around to another handset in a fixed location and thenphysically moves through an Extended Service Set (ESS).

1. Make a call from a handset that can be physically moved around to another handset in a fixed location.



Ascom Myco 3

2. Place a radio or other audio source playing music next to the handset at the fixed location.

To be able to hear roaming delays, interruptions or distortions, a continuous audio sourcefrom a radio or a PC/Smartphone is recommended. A conversation between two people oftenconsists of up to 50% of silent intervals and would not therefore be suitable for the test.

3. Walk around the site to find spots with weak coverage.

Make sure that the walk takes place both directions to ensure that the handset has roamingoptions whenever the field strength drops low.

4. Make detailed notes of any areas where coverage is insufficient.

5. Perform a talk test with two people walking around the site. When done, document the results.

5.1.2 Cellular Site Survey 2

It is recommended to use cellular site survey tools to check a state of GSM, UMTS and LTE networks. Suchtools can provide support engineers with a true strength level measurement of the surrounding basetransceiver stations (BTS), can display locations of BTS, as well as analyze change dynamics. Additionally,these tools can of beneficial use when it comes to the need to check the speed of the incoming andoutgoing connection, make cell ID logs, or create statistics of cell usage.

This section describes how to monitor the received signal strength on the handset as well as to locate othercellular-related diagnostic information, for example service status, roaming information, and mobile networktype.

The information about the device's signal strength can be located through the:

• Settings menu – on the handset, go into the Settings > System > About phone > Status > SIM status.

• Field Test Mode – in the opened dialer, type *#*#4636#*#* and select Phone information.

Figure 4. SIM Status Window (Left) and Field Test Mode (Right)


2. Only applicable for a cellular handset variant.


The Signal strength field shows the current RSSI. The signal is displayed both in decibels (dBM), as well asArbitrary Strength Unit (ASU).

Decibels are expressed as a negative number, like -70 dBm. The closer the number is to 0, the stronger thesignal. For example, -70 dBm is a stronger signal than -90 dBm. A signal beyond -98dBm is not consideredstrong enough to work properly.

RSSI Signal Strength

≥ -70 dBm Excellent

-70 dBm to -85dBm Good

-85 dBm to -98 dBm Fair

-98 dBm to -105 dBm Poor

≤ -105 dBm No Signal

The ASU is an integer value proportional to the received signal strength measured by the handset. ASU isjust a representation of the rate at which the handset is able to update its location by connecting to thetowers near it. It basically measures the same thing as dBm, but on a more linear scale.

You can convert ASU to dBm with this formula:

-In GSM networks, ASU maps to RSSI (received signal strength indicator):

dBm = 2 * ASU - 113, ASU in the range of 0..31 and 99 (for not known or not detectable).

-In UMTS networks, ASU maps to RSCP level (received signal code power):

dBm = ASU - 116, ASU in the range of -5..91 and 255 (for not known or not detectable).

A signal of -60dBm is nearly perfect, and -112dBm is call-dropping bad. If you're above about -87 dBm,Android will report full signal.

5.2 Protocol Analyzer Tools

Capturing the traffic data with a wireless or wired protocol analyzer can be very useful whentroubleshooting a system. Specifically when using WLAN, as capturing traffic in the spot where theproblems arise may provide valuable information about the traffic that is not transferred over to the wirednetwork, for example, retransmissions or rates. Since the wired side is almost always a switched network,capturing traffic is not trivial since access to the switches is needed to create a spanned port to get the datamirrored out to the sniffer. On the other hand, capturing the WLAN which is a broadcast medium is veryconvenient. The only equipment needed is a laptop, for physical mobility, and a wireless network card thatthe sniffer software supports.

General Practices

• Always try to capture as much data as possible. If filtering options exists try to filter the result after thecapture is saved. Applying a filter to the capture itself may exclude interesting packets and ultimatelyrender the capture useless.



Ascom Myco 3

• When capturing wireless bear in mind that the capture device has the same limitations as other wirelessdevices, that is, it will miss packets, be subjected to disturbances and can be out of range. To ensure thebest possible wireless capture try to place the capture device in between the monitored devices, that is,between the handset and the AP. Do not place the capture device too close to another wireless deviceand keep at least 0.5 m between the capture device and monitored devices. If placed too close, trafficmay be overheard on the wrong channels, for example packets on channel 6 will appear on channel 11,or not heard at all due to saturated receivers.

• A result without knowing what happened during the capture is of little use. Try to make note of what thecapture is designed to capture and what devices are involved, what devices are present and what wasexpected to happen but did not.

• Try not to influence the monitored system. For example, if capturing wired traffic with Wireshark orOmniPeek, consider disabling name resolution because each IP/name lookup will generate traffic fromyour PC to the DNS server.

• If data on one channel is to be recorded the WLAN adapter can only be set to listen to one channel. Ifroaming is going to be monitored, two or more channels need to be monitored, in which case oneadapter per channel is required.

5.3 Air Traces of 802.11 Traffic

Ascom recommends Omnipeek from LiveAction as the airtrace tool for capturing data on a designatedchannel. The tool can employ several WLAN adapters simultaneously in promiscuous or monitor mode tocapture the data.

If other air trace tools than Omnipeek are used, the traces must be saved in Packet Capture(PCAP) format. This is a TAC requirement.

Prerequisites

• A support engineer should have already investigated and ruled out relatively easy to identify causessuch as incorrectly configured parameters and incompatible software versions.

• RF problems should also have been investigated and eliminated as a cause of a problem by doing a sitesurvey.

• Problems like co-channel interference, under- or over-coverage, rogue WLAN transmitters and analoginterference sources should also have been addressed.

It is important to note the following before starting a trace:

• Captured traces might not be 100% true. The trace consists of data heard by the adapters, which maymiss data transmitted by handset or AP. It is therefore recommended to take several captures to ensurethat a complete data flow is logged.

• If more than one handset is used for the trace and the handsets are placed too close together, RFdisturbances between the handsets may occur.

To optimize the trace, ensure that:

• The distance between handset and adapter should be no less than 50cm and no more than 100cm.

• A clear line-of-sight exists between the handset and the adapter.

• The adapter is placed between AP and handset.

If the handset is already experiencing WLAN communication problems, it is not recommendedto enable RPCAP tracing in the Admin menu because this will generate additional WLAN traffic.



Requirements

To perform an air trace, the support engineer should be equipped with the following:

• A portable PC.

• Airtrace tool (Omnipeek is recommended). This is used to take wireless sniffer traces of:

− The AP that is transmitting.

− The handset that is transmitting.

− Other air traffic.

• When troubleshooting the roaming problems, either use one adapter per each channel set in the WLANsystem or redesign the system in a way to cover the troubleshooting area with the adapters you have.

If there is only one specific problem that is easy to reproduce, one WLAN adapter is sufficient.

• It is important to have the same time zone, timestamps, and date formats set on all the devices (PCs,handsets, and etc.) that will be used for logging collection. Moreover, it is required to indicate your timezone when sending the logs to be analyzed by the Ascom R&D.If the time zone of logs is not determined, the logs will be stamped with the Ascom’s local time. In thiscase, the time zone might not coincide with the actual time zone thus significantly affecting the results ofthe analysis.

• It is important to send for analysis simultaneous and time-synced logs collected from all the devices (PCs,handsets, and etc.) that have been used for logging collection.

5.4 Logging Scenarios

There are different types of logging that can be used, depending on the area to be investigated. Thesupport engineer, in the first place, should investigate and rule out relatively easy to identify causes, suchas incorrectly configured parameters and incompatible software versions. If this is a case, RF problems,should be investigated and eliminated as a cause of a problem through a site survey. If no relevantinformation can be collected and the problem is persistent, logs should be collected.

Use the following references to get more details on the particular logs:

• 5.5 Event Logs (Log Viewer), page 24.

• 5.6 Debug with Timed Logging, page 26.

• 5.7 Debug Using PCAP , page 28.

• 5.8 Debug Using Remote PCAP, page 28.

• 5.3 Air Traces of 802.11 Traffic, page 20.

Encrypted logs should be collected from the handset and sent to be analyzed by the Ascom R&D.

The below tables explain which logs should be collected in response to the area of the raised problem:



Ascom Myco 3

General (instability, restarts)

Action Logs Encryption

1. Try to repeat the last actions, as there is a certainuncertainty of when exactly the problem appeared.

2. Check the Event log (Log viewer).

3. If the Event log has not showed the required details,perform debugging with timed logging (Additional Wi-Fi trace: disabled) during a certain time, for example,log for 10 min.1 Extract logs and send them to theAscom R&D for analysis.

Event log (Logviewer)

Not encrypted

Timed logging Encrypted

1. To get the most out of your log data, be sure to add some extra logging time (before and after) to log the problem.

Wi-Fi


1. Check the Event log (Log viewer).Make sure that Wi-Fi event logging has been enabled.This is done via Ascom settings > Location services >Wi-Fi location > Wi-Fi location services.

2. If the event logs included no relevant information,perform debugging with timed logging during acertain time, for example, log for 10 min. 1

Make sure to enable Additional Wi-Fi trace via Ascomsettings > Troubleshooting > Additional Wi-Fi trace.Extract logs and send to the Ascom R&D for analysis.CAUTION: The "Additional Wi-Fi trace" must bedisabled directly after logging since it degrades theWi-Fi performance and may cause loss of audio in calls.

3. If none of the tools helped to obtain the requireddetails, use any of the external air traces tools.NOTE: If other air trace tools than Omnipeek are used,the traces must be saved in PCAP format. This is aTAC requirement.

Event log (Logviewer) withadditional Wi-Fievents

Not encrypted

Timed loggingwith additional Wi-Fi tracing

Encrypted

Air traces Encrypted




Ascom VoIP



2. If the event logs showed no relevant information,perform debugging with timed logging during acertain time, for example, log for 10 min. 1

Make sure to enable Additional SIP trace can beenabled via Ascom settings > Troubleshooting >Additional SIP trace. Extract logs and send to theAscom R&D for analysis.NOTE: If there are sound issues, the “Additional SIPtrace” function should be disabled directly afterlogging.

3. If the above-mentioned methods have not given therequired results, perform local PCAP logging orRPCAP.


Not encrypted

Timed loggingwith additional SIPtracing

Encrypted

PCAP

Remote PCAP

Encrypted 2

1. To get the most out of your log data, be sure to add some extra logging time (before and after) to log the problem.2. Except for PCAP logs from the Network packet logging.

Audio (VoIP calls)


1. Check the Event log (Log viewer).Make sure that Wi-Fi event logging has been enabled.This is done via Ascom settings > Location services >Wi-Fi location > Wi-Fi location services.

2. Perform debugging with timed logging (Additional Wi-Fi trace: disabled) during a certain time, for example,log for 10 min. 1 Extract logs and send to the AscomR&D for analysis.

3. If the above-mentioned methods have not given therequired results, perform local PCAP logging orRPCAP. Alternatively, use any of the external airtraces tools.

Event log (Logviewer) withadditional Wi-Fievents

Not encrypted


PCAP

Remote PCAP

Encrypted 2

Air traces Encrypted

1. To get the most out of your log data, be sure to add some extra logging time (before and after) to log the problem.2. Except for PCAP logs from the Network packet logging.

Cellular



2. If the Event log has not showed the required details,perform debugging with timed logging (Additional Wi-Fi trace: disabled) during a certain time, for example,log for 10 min. 1 Extract logs and send to the AscomR&D for analysis.


Not encrypted





Ascom Myco 3

3-rd Party Apps


1. Check the Event log (Log viewer) in case an app isusing Ascom support lib.

2. If special debug logs/ tools should be used for an app,please refer to documentation provided for this app.

3. Perform debugging with timed logging (Additional Wi-Fi and SIP trace are disabled) during a certain time, forexample, log for 10 min. 1 Extract logs and send to theAscom R&D for analysis.


Not encrypted



5.5 Event Logs (Log Viewer)

The built-in Log viewer is a convenient tool for installers and first line support personnel to detect if thesystem is not working correctly. With the Log viewer you can monitor the status of events on a higher level,for example:

• Software upgrade status

• Ascom VoIP (SIP calls and status)

• Wi-Fi

• Location services

• Permissions

• Barcode scanner

It is also possible to trace events coming from third-party applications in case they use Ascomsupport lib.

The data in the Log viewer is limited to a short status update and do not include the descriptive information,so in situations where problems, such as software crashes, occur, the additional tools should be used tocapture the detailed logs. The Log viewer is a part of the standard handset functionality and does notrequire any additional configuration.

Event logs in Log viewer are displayed in runtime, sorted by the newest at the top of the list.

To see all the latest logs, it might be necessary to refresh the page. To do this, tap Refresh in theopened Log viewer.

Each log is designed to support the user with the event information described in Figure 5. Log vieweroverview, page 25:



Figure 5. Log viewer overview

The following colors are used to indicate the severity level of events:

Color Severity Level Description

Fatal A serious error has happened, the device is probablyunusable.

Error The event has caused an error condition.

Warning The event is unexpected and need attention.

Information Information about an expected operation or statechange.

Event A general, expected event.

Open the Log Viewer

The Log viewer can be opened on a handset in two different ways, through:

• Ascom settings menu – go into the Settings > Ascom settings > Troubleshooting> Event log.

• Secret code function – use numeric keypad in the Dialer app and enter *#*#5647#*#*

Filter Event Logs

The event logs can be filtered by severity level and/or package name to meet the certain criteria.

To filter the event logs, do the following:

1. In the opened Log viewer, tap Filter > Filter active.

2. Tap Least shown severity and select the least shown severity level of the events that should beexported.



Ascom Myco 3

The Log viewer shows both the selected and higher severity level events. For example, if“Warning” is chosen then only events with “Warning”, “Error”, and “Fatal” levels will be shown.

3. Tap Package filter and write the package name of the app which logs should be exported.

When filtering event logs by package name, type com.ascom.myco. followed by the nameof the Ascom app.

Export Event Logs

The event logs are not encrypted and stored in the handset’s internal memory, where they may beextracted from.

To export the event logs, follow the steps described below:

1. In the opened Log viewer app, tap Save.

2. Tap Select storage to choose the appropriate method of export. Choose between Email or External.

3. If needed, tap Change filter to apply or change filter parameters (for more information see Filter EventLogs, page 25).

4. Tap Save.

− If Email has been selected at the step 2, fill in the details (email, subject, and description) in theopened window and tap Send.

− If External has been selected at the step 2, tap Send to confirm the export. For the details, seeFigure 6. Event logs exported externally (left) and via email (right), page 26.

Figure 6. Event logs exported externally (left) and via email (right)

5.6 Debug with Timed Logging

Logging information can be used to help the support teams for debugging purposes. With timed logging,the debug logs are created only during the specified time interval, from 10 minutes up to 24 hours. When



enabled, the current buffers are saved in the internal handset memory, in dated folders under differentfolders in /mtklog/, until the specified time interval ends. Timed logging is a part of the standard debugfunctionality in the handset and does not require any additional configuration.

The stored logs are encrypted but can be exported and extracted from the handset (for reference, see 5.10Extract Log Files from the Handset, page 29) to be further sent and analyzed by the Ascom R&D.

Enable Debug with Timed Logging from the Handset

To enable the debugging process with the Timed logging, follow the steps described below:

1. Go into the Settings > Ascom settings > Troubleshooting > Save logs.

2. In the opened list with options, select a time period to log for 3:

− Do not log (default)

− Log for 10 min

− Log for 1 hour

− Log for 12 hours

− Log for 24 hours

Figure 7. Save Logs Window of the Debug Section

3. If needed, enable Additional SIP trace or/and Additional Wi-Fi trace 4 to receive extended logsinformation.

If the logs are exported via USB file transfer, it is required to either turn off logging or let it time outbefore the log files can be seen on the USB drive.


3. To get the most out of your log data, be sure to add some extra logging time (before and after) to log the problem.4. “Additional Wi-Fi trace” should be used with a great caution when performing a normal debug, as enabling this function might

cause additional audio problems.


Ascom Myco 3

5.7 Debug Using PCAP

The Packet Capture (PCAP) logs play a critical role in troubleshooting network-related issues. Toadministrate a network, PCAP consists of an Application Programming Interface (API) for capturing networktraffic. The PCAP feature stores all the Wi-Fi traffic on a log in the handsets internal storage where it can beextracted from.

With PCAP, you can sniff the network traffic on site and uplink the captured packets to a PC, where thecaptured packets can be processed, analyzed and archived. The PCAP logs from the Network packetlogging are without encryption and can be opened, for example in Wireshark. The packet logging can alsobe done while not being on the actual site, using Remote PCAP (RPCAP), see 5.8 Debug Using RemotePCAP, page 28.

Network packets in logs may be encrypted (for example, https or VPN traffic ), but the WLANencryption is removed.

Only run PCAP or RPCAP when needed, and shut it off when not used, if not done automatically bytimed logging. It gives additional load to the handset, as well as the system (with mirroring copies)when using RPCAP.

Start Packet Logging from the Handset

1. Go into the Settings > Ascom settings > Troubleshooting > Network packet logging.

2. In the opened drop-down list, select Local.

Enabling Network packet logging starts tcpdump to log traffic on a network, and disablingstops it. The stored files should be manually removed.

3. To turn off the Network packet logging, repeat the steps above, and select "Off" in the step 3.

Logs should be manually removed, otherwise the entire memory on the handset can be filled.PCAP logs are limited to 10 files of 50 MB each. If the logs are full, the oldest file is deleted toleave room for new data.

5.8 Debug Using Remote PCAP

With RPCAP you can run a packet capture program (the server) on a target computer, which sniffs thenetwork traffic on that system and uplinks the captured packets to another host (the client), where thecaptured packets can be processed, analyzed and archived. To support remote captures, there is also animplementation of the RPCAP protocol allowing captures to be made live from a remote host using, forinstance Wireshark.

Several handsets can be connected to the same Wireshark session to capture, for example,transfer scenarios.

The packet logging can also be done while being on the actual site, using PCAP (for more information, referto 5.7 Debug Using PCAP , page 28).

Start Remote Packet Logging from the Handset

To set up the handset for the RPCAP logging, do the following:

1. Go into the Settings > Ascom settings > Troubleshooting> Network packet logging.

2. In the opened list of options, select Remote.


http://www.wireshark.org


3. Tap Network logging hostname and type an IP address or a hostname of a server that is allowed toconnect to a handset to receive its network traffic.

Only this host or IP address will be allowed to connect to the handset.

5.9 Export Logs with the Handset

With the handset itself it is possible to collect and store logs on the SD card where they can be furtherextracted from, analyzed and handled in different ways depending on the seriousness of the condition.

To export the handset’s logs, do the followings:

1. On the handset, go into the Settings > Ascom settings > Troubleshooting> Export logs.

2. Confirm that the logs should be exported.

3. If the logs are exported for the first time, a permission dialog appears. Tap Allow to confirm.

− If there are no logs to export, you will get the corresponding message.

− If there are logs to export, you will get the message showing the directory where the logs have beenexported to.

Figure 8. Export Logs Windows: No Logs to Export (Left) and Exported Logs (Right)

4. Once the logs have been exported, they can be extracted and used for analysis. For more informationon how to extract logs, refer to 5.10 Extract Log Files from the Handset, page 29.

5.10 Extract Log Files from the Handset

Most logs are encrypted and should be extracted by the Site Administrator to be sent to theAscom R&D for analysis.

On the handset, the logged files are stored in the File Manager > Internal shared storage> logs. The PCAPand RPCAP files are stored in the separate “pcap” folder under the logs.



Ascom Myco 3

Figure 9. Exported logs stored in the File Manager app

To extract log files from the handset, perform the following steps:

1. Connect the handset to a PC running Windows OS using the recommended Micro USB cable (for moreinformation on accessories, please refer to Data Sheet, Ascom Myco 3 Wi-Fi and Cellular, TD 93298ENor Data Sheet, Ascom Myco 3 Wi-Fi, TD 93299EN).

2. Open the Notification Drawer and enable file transfer by doing the following:

a. Tap the USB charging this device notification or tap the Down arrow icon to expand thenotification.

b. Tap the USB charging this device notification again to see the list of options.

If the notification is missing, go to the Settings > Connected devices > USB.

c. In the opened window, select File Transfer.

3. Once connected, the File Explorer automatically opens on your PC.

4. To find the desired log, open Ascom Myco 3 > Internal shared storage > logs (YYYY-MM-DD is thedate the log was exported).



5. Copy the desired folder, and store it on your PC.

5.11 Diagnostics

The integrated diagnostics feature (Factory mode) can be used as an Out of the Box Audit (OBA), usedanytime to check the handset’s hardware status or reset a device to factory settings.

The diagnostics tool can be used to test the following and run a test suite to test them all:

LCD Touchpad GPS

WiFi Bluetooth Buttons

NFC Charger Microphone

Headset Speakers Vibration

Earphone Audio Camera

Backlight Subcamera Memory

IR Scanner IMEI/SN

OTG LED Proximity sensor

Accelerometer Light sensor

Phone (Cellular version only) Lines

The "Phone" test on cellular model in Factory mode initiates the emergency call. The test shouldbe taken place only in controlled environment.

How to Open the Diagnostics Menu

1. In the opened dialer, type *#66#.

2. Choose any physical function to test and follow the instructions on the handset. The automaticmachine testing can be chosen as an alternative.



Ascom Myco 3

Figure 10. Integrated diagnostics feature (Factory mode)

5.12 Perform a Factory Reset

This section presents information about how to factory reset Ascom Myco 3 devices using handset’ssettings, integrated diagnostic tool (Factory mode), and MDM consoles.

Android has a Factory Reset Protection (FRP) to prevent others from using the device without permission.To factory reset a protected device, the screen should be unlocked or Google Account password beentered. Expect to unlock the screen or enter Google Account information if:

• Device's data is erased through Settings.

• Device is reset using its buttons Recovery mode.

• Device is remotely reset with Find My Device.

When a handset factory reset is performed, all handset configuration parameter settings are restored to thedefault values.

Factory reset will erase all the data from a phone, for example Private Branch Exchange (PBX)subscriptions, Google account(s), system and app data, and all downloaded apps. Make sure thereis no important information that is not backed up.

5.12.1 Factory Reset Using the Handset

It’s highly recommended to keep a handset charged until the reset is completed. If the battery level is low,replace the battery, use one of the Ascom chargers or reset with the plugged in handset. For moreinformation on accessible charging methods, please refer to Data Sheet, Ascom Myco 3 Wi-Fi, TD 93299ENor Ascom Myco 3 Wi-Fi and Cellular, Data Sheet, TD 93298EN.

Diagnostic Tool (Factory Mode)

The instructions below show how to use the integrated diagnostics feature (for the additional details, referto 5.11 Diagnostics, page 31) to reset a device to factory settings:

1. In the opened dialer, type *#66#.

2. Tap Factory Reset under the list of hardware features.



3. In the opened window, tap Clear all.

4. Tap OK to confirm.

5. Set up your phone and restore your backed-up data, if needed.

Android Settings

Follow the steps below to factory reset a handset using the standard Android settings:

1. Go into the Settings > System > Reset options> Erase all data (factory reset).

2. If the screen lock is activated, type the password or PIN.

3. Tap Reset phone.

4. Tap Erase everything to confirm.

5. Set up your phone and restore your backed-up data, if needed.

5.12.2 Factory Reset via MDM

If the device is managed via MDM, a factory reset can be triggered, for example, via “Wipe” command. Thisaction triggers the system to remove all the data from the handset and return it to the factory defaultsettings.

If your company is using SOTI MDM solutions, please refer to the technical training presentation “AscomMyco 3 - Deploying Myco 3 Device” published at the Ascom User Documentation Site and demonstratinghow to remove data via the mentioned MDM console. For the detailed information on how to preformfactory reset via other MDM consoles, please refer to your EMM supplier’s documentation.

5.12.3 Hard Reset

If you are experiencing problems accessing your factory reset options through all the above-mentionedoptions, you can still factory reset your Ascom Myco 3 handset performing a series of key combinations.This can be done either when the handset is powered off or in unlocked mode.

Handset is Powered off

1. Press and hold the Power button.

2. While holding the Power button, press and hold the Volume Up button until a test screen showingavailable options appears (see Figure 11. Test screen (left) and System recovery screen (right), page 34).

3. Select Recovery mode.

4. When the screen with "No command" text appears, press and hold the power button.

5. While holding the power button, press the Volume Up button.

6. When the Android system recovery screen appears, use the Volume buttons to scroll to and highlighttheWipe data / factory reset option (see Figure 11. Test screen (left) and System recovery screen (right),page 34). Once it’s highlighted, press the Power button to select.


https://confluence.ascom-ws.com/display/SD/Ascom+Myco+3%2C+Training+Materials


Ascom Myco 3

Figure 11. Test screen (left) and System recovery screen (right)

7. The system will ask for confirmation. Select Yes to erase all user data.

Handset is in Unlocked Mode

1. In unlocked mode, press and hold the Power button to reboot the handset.

2. When rebooting, press and hold Volume up button until a test screen showing available optionsappears.

3. Follow the instructions starting from step 3 described in Handset is Powered off, page 33.


TROUBLESHOOTING GUIDEAscom Myco 3 Troubleshooting Scenarios

6 Troubleshooting Scenarios

This chapter contains information on how to solve common operational problems.

6.1 Handset Errors

The following section covers common system, software, and hardware-related problems that might beencountered when using Ascom Myco 3 handset, together with suggestions on how to troubleshoot them.

6.1.1 System Related

Network (Wi-Fi):

Fault Probable Cause Action

The handset’s connection isoften lost when walking around(roaming).

Bad coverage due to badlyplanned network.

Make a site survey, and move, oradd APs.

The channel complies with theused regulatory domain but it isdisabled on the handset.

Enable the missing channel bydoing the following:

On the handset, go to theSettings > Ascom settings > Wi-Fi > Select channels. Choose therequired channel.

The handset is unable to connectto a Wi-Fi network using a hiddenSSID.

Automatic Wi-Fi selection doesn'twork with networks using hiddenSSIDs.

To connect to a network with ahidden SSID select it as theactive Wi-Fi network throughSettings > Network & Internet >Wi-Fi > Add Network (under thelist of available networks).

Exclamation mark is displayednext to the Wi-Fi indicator.

The exclamation mark indicatesno Internet connection for thecurrent Wi-Fi.

Please contact an administrator ifthe limited connectivity causesissues.

Calls (SIP/WI-Fi):


No ring signal when a call isreceived.

The Ringtones & notificationsvolume is set to Silent or Vibratoronly.

Increase the volume by pressingthe Volume button (+), or byadjusting the sliders in Settings >Sound.

The loudspeaker is defective. Use the Factory mode (in theopened dialer, type *#66#) tocheck if the loudspeaker isworking. If then the loudspeakeris faulty, send in the handset forrepair.

Calls are temporarily (approx. 90seconds) not able to be placed.

The administrator has made aparameter change that affectsthe PBX registration.

Wait until the call can be placed.


Troubleshooting ScenariosTROUBLESHOOTING GUIDE

Ascom Myco 3

Voice quality is bad. Increased traffic load or interfer-ence. Network settings are notprioritizing the voice network.Bad coverage.

– Connect to another phone(wired, analogue or external) todefine if it is the other end thatmay cause bad quality.

– Make a site survey and checkfor areas with under-, or over-coverage and other interfering802.11 systems.

– Do a network performance testto ensure the wired LAN/backbone has adequate capacity.

– Use a spectrum analyzer andlook for non 802.11 interference.

Configuration recommendationsfor an optimized VoWiFienvironment are not followed.

Follow the recommendationsdescribed in 4.7 Wi-Fi Configura-tion Recommendations, page 13.

For additional reference. pleaseread Ascom VoWiFi System,System planning, TD 93358EN.

Connected call but no sound, orone way sound.

Muted or bad speaker/microphone, or IP addressingfault.

– Check if a handset is muted.

– Use the Factory mode (in theopened dialer, type *#66#) toeliminate problems with speaker/ microphone.

– Note the IP address of thehandset. Turn the handset offand ping the IP address. Ifsomething is found, the problemis an IP address conflict.

The ring tone when making SIPcalls from the handset differ fromthe tone normally used in thecountry.

SIP calls from the handset alwaysuse the same ring tone,regardless of region. This tonemight not match the local toneused tone for cellular calls. 1

Configure the ring tone for SIPcalls in Settings > Ascomsettings > Ascom VoIP> dialingTone patterns (for moreinformation, see ConfigurationManual, Ascom Myco 3,TD 93309EN).

The handset calls an emergencynumber when trying to callanother handset, or when callingan international number. 2

The number sequence beginswith the same numbers as anemergency number. Usually thehandset receives a list of locallyused emergency numbers fromthe SIM card, but if no SIM card isinserted a general list of possibleemergency numbers is usedinstead.

If the handset is used without aSIM card, insert a SIM card tolimit the number of possibleemergency numbers.

1. Only for Wi-Fi handsets, or Cellular versions without SIM.2. Cellular version of the handset.



6.1.2 Software Related

Ascom phone (VoIP):


The app does not work asintended (configuration error).

When configuring or using theapp, permissions were notgranted to access specificfeatures, for example to makeand manage phone calls oraccess the microphone.

NOTE: If this is a probable cause,the user should receive a“Configuration error” notificationinforming about the existingproblem. Such notifications arepersistent and stay on lockscreen and in the notificationdrawer as a reminder until theproblems are solved.

In the opened notification drawer,locate “Configuration error”notification for the Ascom PhoneVoIP app and tap Settings.Enable all the requiredpermissions for the app.

Permissions can be granted bygoing directly into the Settings >Apps & notifications > AscomVoIP > Permissions.

Location services (Location manager):



When configuring or using theapp, permissions were notgranted to access specificfeatures, for example to accessthe device’s location.

NOTE: If this is a probable cause,the user should receive a“Configuration error” notificationinforming about the existingproblem. Such notifications arepersistent and stay on lockscreen and in the notificationdrawer as a reminder until theproblems are solved.

In the opened notification drawer,locate “Configuration error”notification for the Locationservices app and tap Settings.Enable all the requiredpermissions for the app.

Permissions can be granted bygoing directly into the Settings >Apps & notifications > Locationservices > Permissions.

Barcode Scanning:


Barcode scanning does not workon the handset.

A policy has been created torestrict the use of camera app onthis device.

To enable the camera, on thehandset go into Settings > Apps& notifications > See all # apps >All apps > Disabled apps >Camera. In the opened window,tap Enable.



Ascom Myco 3

Barcode Scanning:


Barcode scanning does not workon the handset.

The barcode scanning is notproperly configured.

Barcode scanning is onlyactivated when the active appmatches any of the barcodescanner app configurations, andthat app configuration has atleast one output method enabled

Check if barcode scanning hasbeen properly configured bygoing on the handset into theSettings > Ascom settings >Barcode scanning > Appconfigurations.

For the details on barcodescanning configurations, pleaserefer to the Configuration Manual,Ascom Myco 3, TD 93309EN.

The scanned barcode is disabledin the list of supportedsymbologies.

To enable the barcode, go intoSettings > Ascom settings >Barcode scanning > Profiles.Select the profile to beassociated with the barcode.Enable the barcode in the list ofsupported barcodes on thehandset.

NOTE: Be sure that the correctprofile has been chosen inSettings > Ascom settings >Barcode scanning > Appconfiguration to match thecurrent use case.


When configuring or using theapp, permissions were notgranted to access specificfeatures, for example to takepictures and record videos.

NOTE: If this is a probable cause,the user should receive anotification informing about theexisting problem. Such notifica-tions are persistent and stay onlock screen and in the notificationdrawer as a reminder until theproblems are solved.

In the opened notification drawer,locate “Configuration error”notification for the Barcodescanner app and tap Settings.Enable all the requiredpermissions for the app.

Permissions can be granted bygoing directly into the Settings >Apps & notifications > Barcodescanner> Permissions.

6.1.3 Hardware Related


The camera doesn't work. The camera is disabled on thehandset.

The ability to capture photos isrestricted via MDM system.Contact your systemadministrator for assistance.

Camera



The camera doesn't work. The camera is disabled on thehandset.

The ability to capture photos isrestricted via MDM system.Contact your systemadministrator for assistance.

The camera is faulty. Use the integrated diagnostictool to check if the camera isworking. If then the camera isfaulty, send in the handset forrepair. For more information onthe diagnostic tool (Factorymode), see 5.11 Diagnostics, page31.

Display


Nothing is displayed, or pixelsare missing.

The battery is empty. Charge, or replace the battery.

The screen is defective. Use the integrated diagnostictool to check if the display isworking. If then the display isfaulty, send in the handset forrepair. For more information onthe diagnostic tool (Factorymode), see 5.11 Diagnostics, page31.

The display is too dark. Brightness is set too low. Manually adjust the brightness toan appropriate level in thenotification drawer or thoughSettings > Display.

An adaptive brightness or batterysaver mode are enabled.

– Disable the adaptive brightness(Settings > Display)

– Disable battery saver mode inthe notification drawer.

Battery


No charging screen whenconnected to a charger.

The default configuration is toshow the charging screen whencharging the handset in acharging rack, but not whencharging with a USB charger.

Configure the charging screenthrough the parameters found inSettings > Display > Advanced >Screen saver.


Camera



Ascom Myco 3

Battery life is poor. Power Save is not used. – Verify the coverage, since lowsignal strength will make thehandset to constantly search forother APs and therebyconsuming more power.

– Use the shortest convenientsleep time-out in Settings >Display > Sleep .

– Verify with another battery.

– Turn on Adaptive brightness(Settings > Display ) or thebattery saver mode in thenotification drawer to prolong thebattery life.

Battery level drops significantly.Something in a handset isdraining battery, for examplethird-party app, Wi-Fi, mobilenetwork, or Android system itself.

– Refer to the app documenta-tion to check if that app has beencorrectly configured.

– Refer to the battery usage on ahandset by going to: Settings >Battery and tap the percentagecharge value or battery icon atthe top.

The handset is not chargingwhen connected to a USBcharger.

The USB charger used is notsupported by the handset.

Only use supported USBchargers to charge the handset.

A PC is used as a USB charger,and no charge is received fromthe USB port.

Wake the PC from sleep mode,or try connecting to a differentUSB port.

Sound volume


No ringtone/sound when a call/message is received.

The ringtones and notificationsvolume are set to “do notdisturb” mode (total silence,alarms only, priority only) orvibrator only.

Switch the “do not disturb” modeoff in the notification drawer orincrease the volume by pressingthe volume up button.


Battery



Sound volume


No ringtone/sound when a call/message is received.

The loudspeaker is defective. Use the integrated diagnostictool to check if the speaker isworking. If then the speaker isfaulty, send in the handset forrepair.

NOTE: The "Phone" test oncellular model in Factory modeinitiates the emergency call. Thetest should be taken place only incontrolled environment.

For more information on thediagnostic tool (Factory mode),see 5.11 Diagnostics, page 31.

Multifunction buttons


Nothing happens when thebutton is pressed.

"Disengage button" functionalityis chosen for the button.

Configure the button throughSettings > Ascom setting >Button configuration> Defineaction for button. Choose anyrather than "Disengage button".

For more information on how toconfigure multifunction buttons,refer to Configuration Manual,Ascom Myco 3, TD 93309EN.

The button functionality is notconfigured.

Configure the button throughSettings > Ascom setting >Button configuration> Configurecustom intent.

For more information on how toconfigure multifunction buttons,refer to Configuration Manual,Ascom Myco 3, TD 93309EN.

Non-applicable configurationvalues are set either for an actionor component, or for both ofthem.

Refer to the documentation forAndroid developers.

For more information, refer toAscom Myco 3 MultifunctionButton Custom Intent Support,Configuration notes, TD93343EN.



Ascom Myco 3

The buttons on the headset doesnot work as intended.

An Android compatible headsetis not used.

Make sure that an Androidcompatible 3.5 mm headset isused.

An iPhone compatible headset isused.

Switch to an Android compatibleheadset (iPhone headsets differin hardware from Androidcompatible headsets).

Dirt inside the 3.5 mm connectorof the headset adapter.

Disconnect the adapter from thehandset and carefully clean outdirt from inside the 3.5 mmconnector. Use a toothpick oranother object of the same sizeand shape in wood or plastic (notmetal).

NFC


The handset cannot read theNFC tag.

NFC functionality is not enabledon the handset.

Enable NFC on the handsetunder Settings > Connecteddevices > NFC.

The handset is further away fromthe tag than 2-4 cm.

Place the handset closer to theNFC tag.

The back of the handset is notfacing the NFC tag.

Turn the handset around.

The handset cannot read theNFC tag.

The handset is not unlocked withthe screen lit up.

Make sure that the handset isunlocked and that the screen islit up.

The handset is not using anoriginal Ascom Myco 3 battery.

The NFC antenna is built into theoriginal Ascom Myco 3 battery.Make sure to use an originalAscom Myco 3 battery to be ableto use the NFC functionality.

The NFC antenna may stopworking due to dirt on the batterycontacts.

Clean the battery contacts onAscom Myco 3 and/or the battery.


Headset



6.1.4 Installation and Maintenance

Debug


Cannot capture the RPCAP logsusing a PC and Wireshark.

The IP adress / hostname is notspecified in the handset.

Using the handset, add the PChostname/address to theSettings > Ascom settings >Troubleshooting > Networklogging hostname parameter.

Cannot open or read log files. All log files except for Event logsand PCAP logs from the Networkpacket logging are encrypted,and can only be analyzed byAscom R&D.

Send the log files to the Ascomsupport team for analysis.

6.2 WLAN Troubleshooting Scenarios

This section illustrates, through examples, the kinds of performance issues that may arise when operating ahandset in a WLAN. Because the characteristics of sites using VoWiFi and the issues experienced by usersare likely to be very different, it would be difficult to provide a single definitive method for resolving issues.Instead, the information in this section suggests an approach to investigating and solving common WLANissues.

6.2.1 Voice Problems While Roaming

User experiences voice problems, both poor voice quality or audio gaps while moving through the site.

Software

Check that both the WLAN and handset have the latest compatible software and are configured properly:

1. On the handset, go into Settings > Ascom settings > About. Note the value for the Platform versionparameter.

2. Obtain Ascom Interoperability Reports for respective system published on the Ascom Partner Extranet.

3. Check that the WLAN and handset have compatible software versions and are configured according tointeroperability report. Are incorrect configurations or software version incompatibilities found?

− Yes: Perform a system upgrade to reconfigure parameters. For more information on the softwareupgrade, refer to Configuration Manual, Ascom Myco 3, TD 93309EN.

− No: Go to the section Coverage, page 43 located below.

Coverage

Check the RF coverage with the built in Site Survey tool:

1. Use the built-in Site Survey tool , see 5.1.1 Wi-Fi Site Survey, page 16.

2. In unlocked mode, slowly walk around the site, paying attention to the RSSI at frequent intervals.

3. Repeat the procedure in step 2 in a call mode.

− Analyze the results.

4. The signal strength should not be lower than - 70 dBm. Is the signal strength lower?

− Yes: There are coverage gaps that may explain the problem the customer is experiencing


https://www.ascom-ws.com/AscomPartnerWeb/en/startpage/Sales-tools/Interoperability/Certified-Products/Ascom-Myco-3/WLAN/


Ascom Myco 3

− No: Go to the section Roaming, page 44.

Roaming

Check if audio problems are present while moving through the site in a call mode:

1. Make a call to another party and move through the site while holding a conversation with the otherparty.

2. During a call, with the Site survey screen activated, monitor the RSSI value and see if the audioproblem is experienced during the handset roam.

− Analyze the results.

3. Are audio problems experienced?

− Yes: Investigate possible problems caused by incorrect QoS setting, external interference andsecurity issues.

QoS

Control QoS in a network analyzer tool to confirm that both Rx and Tx have UP 6, if not QoS needs to becorrected in the LAN/WLAN. For more information on QoS, refer to the chapter 3.1 Quality of Service (QoS)Recommendations in Ascom VoWiFi System, System planning, TD 93358EN.

External Interference

External interference may occur when VoWiFi devices are forced to share the RF spectrum with otherdevices. Such devices often create interference for wireless LAN users. Perform a site survey with aspectrum analyzer to identify sources of interference.

Security

If Extensible Authentication Protocol (EAP) security is used, check if the full EAP exchange is performedduring the roam with an air trace or log of the Radius server. Normally the keycaching function in the WLANsystem and handset prevent a full EAP exchange during roam.

6.3 Warning Messages

This section illustrates the most common fault messages for the Ascom Phone (VoIP) app that can berectified using corresponding troubleshooting tools. Such warning messages contain detailed informationabout specific errors including guidance on further actions to resolve the existing problems.

6.3.1 No Network Connection

Network connection lost message indicates that there is some fault in a layer below an application. If thereis no access to the Wi-Fi, there is no Access Point (AP) to associate with, which may be caused by thehandset being out of range or by incorrectly configured Wi-Fi network parameters.



Message Details

The Wi-Fi connection has been lost. Shown whennetwork problems occur. Due to poor Wi-Ficonnection the SIP registration is paused. Trymoving to another part of the room/building ormove inside a network connected building if youare outside.

“No Network Connection” failure is indicated by:

• Beep signal and vibration once a minute for up to 30 minutes.

After 30 minutes the handset continues to use only LED signal as a reminder.

• LED flashing orange.

• Popup notification (unlocked mode).

Examples of incorrect Wi-Fi parameter settings may include:

• Incorrect network selected.

• Incompatible with the regions channels.

• Missing or incorrect Service Set Identifier (SSID).

• Incorrect date or time.

Check Network Selected

1. On the handset, go into Settings > Network & Internet > Wi-Fi.

2. Check that the correct network is selected.

Check SSID

If the handset’s network settings have been configured through a Mobile Device Management (MDM)system, check the value of the SSID in the system.

If the SSID value is wrong and the parameter is set for multiple handsets, other users might havesimilar problems.

If the handset’s network settings have been configured directly on the handset, do the following:

1. Go into Settings > Network & Internet > Wi-Fi.

2. Check that the correct value of the SSID for the selected network.

The SSID is case sensitive.



Ascom Myco 3

Check the Regulatory Domain and Selected Channels

The wireless spectrum regulatory domain defines which region's rules the handset should comply to. Basedon the handset version (see A.1 Article Numbers, page 53), different actions should be taken to set theregulatory domain:

• Cellular version – No action needed (cellular network is used even when no SIM is inserted).

• Wi-Fi version in US – Set FCC (for information on how to change domain settings, read below).

• Wi-Fi version in rest of the world – No action needed (802.11d is set as default).

If the World mode is set, the handset listens for a beacon containing 802.11d formatted regioninformation, before transmitting anything (this requires support and configuration from theinfrastructure).

If roaming between an indoor and outdoor area is a requirement, 802.11d (World mode) cannot beused to determine regulatory domain. In these cases it is important to instead specify theregulatory domain the handset is operating in. Such as ETSI (Europe), Japan, etc.

The handset gets its regulatory settings from the AP. If this is not supported by the AP it has to beconfigured for the handset as follows:

1. Go to the Settings > Ascom settings > Wi-Fi > Define option for regulatory domain

2. Select one of the following settings:

− World mode (default)

− FCC

− ETSI

The enabled on the handset channels should comply with the corresponding regulatory domain. If not, dothe following:

1. Go to the Settings > Ascom settings > Wi-Fi > Select channels

2. Choose the channels to be used.

Check Time and Date

If the time or date on the handset differs from the current time or date, the certificate, for example SSL, TSL,or Wi-Fi, might consider the connection invalid. This is the most common in cases when the certificateexpires earlier than the time or date set on the handset.

The date parameter is the most important as minor differences in time do not influence much.

To change time and date on the handset, do the following:

1. On the handset, go into Settings > System > Data & time.

2. If Network- or GPS- provided time is selected in Automatic date & time window, change it for Off andset time or date manually.

3. Restart the handset.



6.3.2 No SIP Connection

Message Details

The SIP registration failed. Shown in case of serverproblems and certification issues. This mostcommonly happens because the PBX is busy orbecause of an invalid IP address, or an invalidcertificate.

“No SIP connection” message indicates that the handset has successfully associated with an AP but itcannot connect to the SIP PBX server. This may be because the application services are not running or theservices are running but the handset is unable to connect to the services due to faulty IP addressconfiguration.

1. Check IP address. On a handset go to Settings > system > About phone > Status > IP address andinspect the value of the Phone IP parameter to see if the handset has an IP address.

− If using static IP addresses: Check that the settings are correct and that there is no IP conflict withanother device. Pay special attention to the value of “Default gateway” if the SIP PBX is on anothersubnet or VLAN.

− If using DHCP-server delivered IP addresses: Check that there is connection to the DHCP server.

2. DHCP problems may also be the case if the there is no access to the DCHP server in a LAN that issegmented using subnets or VLANs.To test DHCP problem perform one or more of the following steps:

− Try to set the IP-address parameters manually. If access is restored it clearly indicates a DHCPproblem.

To exclude TCP/IP stack problems in the handset, ping the handset from a laptop. Find the handset’s IPaddress in Settings > system > About phone > Status > IP address.

• Use a laptop with a wireless card to see if the laptop receives an IP over DHCP.

• Use a wired connection to the same switched network/VLAN as the AP (or controller) is connected to, totest if the laptop receives an IP address over DHCP.

• It is also possible to take help of a network administrator and try to ping to or from an AP or other deviceto the DHCP server. If this is successful the DHCP problem is in the wireless part of the site.

• If a wireless sniffer is available, configure it for the correct encryption key and try to decode packets bothfrom and to the handset.

If the handset initiates the DHCP handshake function, the problem is that the AP isn’t forwarding DHCPoffers or the wrong address is sent out. Check for the possibility that the WLAN internal DHCP server doesnot work.

A common cause is that the VLAN/SSID/USER CLASS mapping is wrong and that the DHCP server cannotbe reached from the wireless side.

If the handset has an IP-address the problem is either in the Services setup or the SIP PBX is not reachable.Major causes can be:

• Wrong IP address parameter settings for VoIP.



Ascom Myco 3

• The handset is not registered in the services.

• Services are on another (sub) network and routing to that LAN is not functioning.

Test for Voice Access

1. Try to ping the SIP PBX from a handset or a laptop.

2. Was the ping successfully echoed?

− No: Check the PBX settings in the LAN as the problem is access to the PBX.

− Yes: If ping is successful from another client to the PBX, check the Voice settings (for example PBXaddress) in the handset.

3. From the handset Settings, check the following:

− The IP address of the handset is on the same subnet as the SIP PBX or there is a route to the SIPPBX in the network. Note that the value of the default gateway must point to a route that canforward the package.

− The IP-address of the SIP PBX is correct set in the handset.

− The handset has an Endpoint number or Endpoint ID that is registered in the SIP PBX and ifpasswords are used for access to the SIP PBX, that it is correct.

4. Check that the APs maps VoIP packets to the Voice VLAN if such are used. To do this, access to theAP setup is needed, otherwise a “wired and wireless sniffing session” must be carried out.

6.3.3 Incorrect SIP Authorization Details

Message Details

Incorrect SIP authorization details have been used.The message is shown when wrong data (usercredentials) in Ascom VoIP settings have beenused.

Incorrect SIP credentials message indicates that the handset is configured to use SIP PBX with invalidauthorizations details, and SIP calls cannot be placed.

Check Endpoint ID

Verify that used on the handset Endpoint ID is registered in SIP PBX.

Check Password

Verify that the same password registered in PBX is used for the current Endpoint ID.

Check Multiple Usage of Same Endpoint ID

The same Endpoint ID can, if supported by the SIP PBX, be simultaneously used on several handsets onlywhen the following conditions are met:

1. The password has been registered in SIP PBX.



2. This password is applied to all the handsets using the same Endpoint ID. On the handset, go intoSettings > Ascom settings > Ascom VoIP > Password.

6.3.4 No Phone Calls

Message Details

In most cases the message is shown when theproblem cannot be identified (unknown reason).

“No Phone Calls” message indicates that the existing problem is different from those described in previoussections. The following measures can be taken to identify and eliminate the problem:

• Wait until the warning message disappears.

• Restart the handset.

• If an issue remains unresolved, contact the Technical Assistance Centre (TAC) team and prove withinformation described in 1.3 Information Required by TAC, page 2.


Related Documents


7 Related Documents

Configuration Manual, Ascom Myco 3, TD 93309EN

Data Sheet, Ascom Myco 3 Wi-Fi and Cellular, TD 93298EN

Data Sheet, Ascom Myco 3 Wi-Fi, TD 93299EN

Ascom Myco 3 Multifunction Button Custom Intent Support, Configuration notes, TD 93343EN

Ascom VoWiFi System, System planning, TD 93358EN


TROUBLESHOOTING GUIDEAscom Myco 3 Document History

8 Document History

For information on changes in the latest version, see the table below.

Version Date Description

B November 2019 General:

General updates in text and images to stand withAndroid™ 9 Pie changes.

New:

1.3 Information Required by TAC, page 2 has beencreated.

3 WLAN Overview, page 4 chapter has been createdwith its corresponding subsections.

4 The Handset as a WLAN Wireless Client, page 8chapter has been created with its correspondingsubsections.

New sections 5.1 Site Survey Tools, page 15, 5.2 ProtocolAnalyzer Tools, page 19, and 5.11 Diagnostics, page 31have been created.

Table for Ascom phone VoIP and Location services havebeen created in 6.1.2 Software Related, page 37.

Table for Calls (SIP/Wi-Fi) has been added in 6.1.1 SystemRelated, page 35.

Section 6.2 WLAN Troubleshooting Scenarios, page 43has been created.

6.3 Warning Messages, page 44 with correspondingsubsections has been created.

5.3 Air Traces of 802.11 Traffic, page 20 has beencreated.

Appendix A Handset Parameters, page 53 and AppendixB Ports, page 55 have been created.


Document HistoryTROUBLESHOOTING GUIDE

Ascom Myco 3

Version Date Description

B November 2019 Updated:

Information about existing internal and externaltroubleshooting tools has been added to 5Troubleshooting Tools, page 15.

“USB File Transfer” has become a part of 5.10 ExtractLog Files from the Handset, page 29.

Section 5.4 Logging Scenarios, page 21 has beenupdated to describe which logs should be collected tosolve certain problems.

Sections “Event Logs” and “LogViewer” have beengrouped into 5.5 Event Logs (Log Viewer), page 24.Editorial changes have been made.

Section “Debug Network Traffic Using PCAP andRPCAP” has been split into two separate parts: 5.7Debug Using PCAP , page 28 and 5.8 Debug UsingRemote PCAP, page 28.

Table for Barcode scanner has been updated in 6.1.2Software Related, page 37.

Table for Network (Wi-Fi) has been updated in6.1.1System Related, page 35.

A 10 June 2019 First release.


TROUBLESHOOTING GUIDEAscom Myco 3 Handset Parameters

Appendix A Handset Parameters

A.1 Article Numbers

Product designator for regulatory purposes of Ascom Myco is SH2.

Hardware designator Product name

SH2–ABAA Ascom Myco Wi-Fi

SH2–ABBA Ascom Myco Wi-Fi EU

SH2–ACAA Ascom Myco Cellular Wi-Fi

SH2–ACBA Ascom Myco Cellular Wi-Fi EU

A.2 Device Information

The following read-only information about the handset is displayed in Settings > Ascom settings > Aboutmenu or seen on the label in the Battery compartment.

Software

The handset is configured with the following software characteristics, that are seen in Settings > Ascomsettings > About.

Parameter Remark

Platform version: The handset’s current firmware version.

Ascom experience version: The handset’s current Ascom experience version.

Model: The handset’s product model. Important forfirmware update, as the device model must becompatible with the firmware version.

Wi-Fi: The MAC address.

Hardware

The handset is configured with the following hardware characteristics, that are seen on the label in thebattery compartment

Parameter Remark

Production date: For information purposes only. Identifies the yearand week the handset was produced.

Model: For information purpose only.


Handset Parameters


MAC: The sub layer 1 MAC address used in frames sentand received. Same address is used independentof the frequency band selected.

The first six octets are useful in creating filters inair-log files to remove other WLAN packets.

S/N: Serial number.


TROUBLESHOOTING GUIDEAscom Myco 3 Ports

Appendix B Ports

This appendix lists the TCP and UDP ports the handset listens on for incoming and outgoing traffic.

B.1 SIP

The following port numbers are configurable:

Protocol Direction Port Number

UDP Outgoing UDP:5060 (set by default)

Incoming UDP:5060 (set by default)

TCP Outgoing TCP: Any free port

Incoming TCP:5060

B.2 Voice Traffic

For a voice connection, one RTP and one RTCP port are used. A call therefore uses two free UDP portsselected from the RTP port range. The RTP port range is, by default, from 16384 to 32767. The port range isthen used for SIP calls.

B.3 Google Mobile Services

For additional details on available ports, please refer to Android documentation.

B.4 Other Services

Protocol Direction Port Number

DNS UDP Outgoing 53

DHCP UDP Outgoing 68

NTP UDP synchronization Outgoing 123

RPCAP TCP Incoming 2002


Ascom (Sweden) AB

Grimbodalen 2

SE–417 49 Göteborg

Sweden

Phone +46 31 55 93 00

www.ascom.com

TD93297EN/19December2019/Ver.B

last page