Motorola Solutions 89FT7622 5.7GHz Fixed Wireless (ISM) User Manual Exhibit D Users Manual Part 8 per 2 1033 b3

Motorola Solutions, Inc. 5.7GHz Fixed Wireless (ISM) Exhibit D Users Manual Part 8 per 2 1033 b3

Exhibit D Users Manual Part 8 per 2 1033 b3

Release 8 Operations Guide
Issue 2, December 2006 Draft for Regulatory Review 463
Figure 183: <capture> - Ethereal window, Packet 14 selected
In this second example, Packet 14 (protocol type HTTP) is selected in the top pane.
The two lower panes provide further details about Packet 14.
Release 8 Operations Guide
Issue 2, December 2006 Draft for Regulatory Review 465
32 TROUBLESHOOTING
32.1 GENERAL PLANNING FOR TROUBLESHOOTING
Effective troubleshooting depends in part on measures that you take before you
experience trouble in your network. Canopy recommends the following measures for
each site:
1. Identify troubleshooting tools that are available at your site (such as a protocol
analyzer).
2. Identify commands and other sources that can capture baseline data for the site.
These may include
ping
tracert or traceroute
Link Capacity Test results
throughput data
Configuration tab captures
Status tab captures
session logs
3. Start a log for the site.
4. Include the following information in the log:
operating procedures
site-specific configuration records
network topology
software releases, boot versions, and FPGA firmware versions
types of hardware deployed
site-specific troubleshooting processes
escalation procedures
5. Capture baseline data into the log from the sources listed in Step 2.
32.2 GENERAL FAULT ISOLATION PROCESS
Effective troubleshooting also requires an effective fault isolation methodology that
includes
attempting to isolate the problem to the level of a system, subsystem, or link,
such as
AP to SM
AP to CMM
AP to GPS
CMM to GPS
BHM to BHS
BHM to CMM
power
researching Event Logs of the involved equipment. (See Interpreting Messages
in the Event Log on Page 412.)
Operations Guide Release 8
466 Draft for Regulatory Review Issue 2, December 2006
answering the questions listed in the following section.
reversing the last previous corrective attempt before proceeding to the next.
performing only one corrective attempt at a time.
32.3 QUESTIONS TO HELP ISOLATE THE PROBLEM
When a problem occurs, attempt to answer the following questions:
1. What is the history of the problem?
Have we changed something recently?
Have we seen other symptoms before this?
2. How wide-spread is the symptom?
Is the problem on only a single SM? (If so, focus on that SM.)
Is the problem on multiple SMs? If so
is the problem on one AP in the cluster? (If so, focus on that AP)
is the problem on multiple, but not all, APs in the cluster? (If so, focus on
those APs)
is the problem on all APs in the cluster? (If so, focus on the CMM and the
GPS signal.)
3. Based on data in the Event Log (described in Interpreting Messages in the Event
Log on Page 412)
does the problem correlate to External Hard Resets with no WatchDog timers?
(If so, this indicates a loss of power. Correct your power problem.)
is intermittent connectivity indicated? (If so, verify your configuration, power
level, jitter, cables and connections, and the speed duplex of both ends of the
link).
does the problem correlate to loss-of-sync events?
4. Are connections made via shielded cables?
5. Does the GPS antenna have an unobstructed view of the entire horizon?
32.4 SECONDARY STEPS
After preliminary fault isolation through the above steps
1. check the Canopy knowledge base
(http://motorola.canopywireless.com/support/knowledge) to find whether other
network operators have encountered a similar problem.
2. proceed to any appropriate set of diagnostic steps. These are organized as
follows:
Module Has Lost or Does Not Establish Connectivity
NAT/DHCP-configured SM Has Lost or Does Not Establish Connectivity on
Page 468
SM Does Not Register to an AP on Page 470
BHS Does Not Register to the BHM on Page 471
Module Has Lost or Does Not Gain Sync on Page 472
Module Does Not Establish Ethernet Connectivity on Page 473
Module Does Not Power Up on Page 474
Power Supply Does Not Produce Power on Page 474
Release 8 Operations Guide
Issue 2, December 2006 Draft for Regulatory Review 467
CMM2 Does Not Power Up on Page 475
CMM2 Does Not Pass Proper GPS Sync to Connected Modules on
Page 475
32.5 PROCEDURES FOR TROUBLESHOOTING
32.5.1 Module Has Lost or Does Not Establish Connectivity
To troubleshoot a loss of connectivity, perform the following steps.
Procedure 48: Troubleshooting loss of connectivity
1. Isolate the end user/SM from peripheral equipment and variables such as
routers, switches, and firewalls.
2. Set up the minimal amount of equipment.
3. On each end of the link
a. check the cables and connections.
b. verify that the cable/connection scheme—straight-through or crossover—is
correct.
c. verify that the LED labeled LNK is green.
d. access the General Status tab in the Home page of the module.
e. verify that the SM is registered.
f. verify that RSSI is 700 or higher.
g. verify that jitter is reported as 9 or lower.
h. access the IP tab in the Configuration page of the module.
i. verify that IP addresses match and are in the same subnet.
4. On the SM end of the link
a. verify that the PC that is connected to the SM is correctly configured to obtain
an IP address through DHCP.
b. execute ipconfig.
c. verify that the PC has an assigned IP address.
5. On each end of the link
a. access the General tab in the Configuration page of each module.
b. verify that the setting for Link Speeds (or negotiation) matches that of the
other module.
c. access the Radio tab in the Configuration page of each module.
d. verify that the Radio Frequency Carrier setting is checked in the Custom
Radio Frequency Scan Selection List.
e. verify that the Color Code setting matches that of the other module.
f. access the browser LAN settings (for example, at
ToolsInternet OptionsConnectionsLAN Settings in Internet
Explorer).
g. verify that none of the settings are selected.
h. access the Link Capacity Test tab in the Tools page of the module.
i. perform a link test. (See Procedure 40: Performing a Link Capacity Test on
Page 435.)
Operations Guide Release 8
468 Draft for Regulatory Review Issue 2, December 2006
j. verify that the link test results show efficiency greater than 90% in both the
uplink and downlink (except as described under Comparing Efficiency in 1X
Operation to Efficiency in 2X Operation on Page 134).
k. execute ping.
l. verify that no packet loss was experienced.
m. verify that response times are not significantly greater than
2.5 ms from BH to BH
4 ms from AP to SM
15 ms from SM to AP
n. replace any cables that you suspect may be causing the problem.
6. After connectivity has been re-established, reinstall network elements and
variables that you removed in Step 1.
=========================== end of procedure ===========================
32.5.2 NAT/DHCP-configured SM Has Lost or Does Not Establish Connectivity
Before troubleshooting this problem, identify the NAT/DHCP configuration from the
following list:
NAT with DHCP Client and DHCP Server
NAT with DHCP Client
NAT with DHCP Server
NAT without DHCP
To troubleshoot a loss of connectivity for an SM configured for NAT/DHCP, perform the
following steps.
Procedure 49: Troubleshooting loss of connectivity for NAT/DHCP-configured SM
1. Isolate the end user/SM from peripheral equipment and variables such as
routers, switches, and firewalls.
2. Set up the minimal amount of equipment.
3. On each end of the link
a. check the cables and connections.
b. verify that the cable/connection scheme—straight-through or crossover—is
correct.
c. verify that the LED labeled LNK is green.
4. At the SM
a. access the NAT Table tab in the Logs web page.
NOTE: An example of this tab is shown in Figure 184.
Release 8 Operations Guide
Issue 2, December 2006 Draft for Regulatory Review 469
Figure 184: NAT Table tab of SM, example
b. verify that the correct NAT translations are listed.
RESULT: NAT is eliminated as a possible cause if these translations are
correct.
5. If this SM is configured for NAT with DHCP, then at the SM
a. execute ipconfig.
b. verify that the PC has an assigned IP address.
c. if the PC does not have an assigned IP address, then
enter ipconfig /release “Adapter Name”.
enter ipconfig /renew “Adapter Name”.
reboot the PC.
retreat to Step 5a.
d. if the PC has an assigned IP address, then
access the NAT DHCP Statistics tab in the Statistics web page of
the SM.
NOTE: An example of this tab is shown in Figure 185.
Operations Guide Release 8
470 Draft for Regulatory Review Issue 2, December 2006
Figure 185: NAT DHCP Statistics tab of SM, example
verify that DHCP is operating as configured.
6. After connectivity has been re-established, reinstall network elements and
variables that you removed in Step 1.
=========================== end of procedure ======================
32.5.3 SM Does Not Register to an AP
To troubleshoot an SM failing to register to an AP, perform the following steps.
Procedure 50: Troubleshooting SM failing to register to an AP
1. Access the Radio tab in the Configuration page of the SM.
2. Note the Color Code of the SM.
3. Access the Radio tab in the Configuration page of the AP.
4. Verify that the Color Code of the AP matches that of the SM.
5. Note the Radio Frequency Carrier of the AP.
6. Verify that the value of the RF Frequency Carrier of the AP is selected in the
Custom Radio Frequency Scan Selection List parameter in the SM.
Release 8 Operations Guide
Issue 2, December 2006 Draft for Regulatory Review 471
7. In the AP, verify that the Max Range parameter is set to a distance slightly
greater than the distance between the AP and the furthest SM that must register
to this AP.
8. Verify that a clear line of sight exists between the AP and the SM, and that no
obstruction significantly penetrates the Fresnel zone of the attempted link.
If these conditions are not established, then verify that the AP and SM are
900-MHz modules in close proximity to each other.
9. Access the General Status tab in the Home page of each module.
10. In the Software Version field, verify that both the AP and SM are of the same
encryption scheme (AES or DES).
11. Remove the bottom cover of the SM to expose the LEDs.
12. Power cycle the SM.
RESULT: Approximately 25 seconds after the power cycle, the green LED
labeled LNK should light to indicate that the link has been established. If the
orange LED labeled SYN is lit instead, then the SM is in Alignment mode
because the SM failed to establish the link.
13. In this latter case, and if the SM has encountered no customer-inflicted damage,
then request an RMA for the SM.
=========================== end of procedure ======================
32.5.4 BHS Does Not Register to the BHM
To troubleshoot an BHS failing to register to the BHM, perform the following steps.
Procedure 51: Troubleshooting BHS failing to register to a BHM
1. Access the Radio tab in the Configuration page of the BHS.
2. Note the Color Code of the BHS.
3. Access the Radio tab in the Configuration page of the BHM.
4. Verify that the Color Code of the BHM matches that of the BHS.
5. Note the Radio Frequency Carrier of the BHM.
6. Verify that the value of the RF Frequency Carrier of the BHM is selected in the
Custom Radio Frequency Scan Selection List parameter on the Configuration
page of the BHS.
7. Verify that a clear line of sight exists between the BHM and BHS, and that no
obstruction significantly penetrates the Fresnel zone of the attempted link.
8. Access the General Status tab in the Home page of each module.
9. In the Software Version field, verify that both the BHM and BHS are of the same
encryption scheme (AES or DES).
10. Also in the Software Version field, verify that both the BHM and BHS are of the
same modulation rate from the factory (BH20 or BH10).
11. Remove the bottom cover of the BHS to expose the LEDs.
Operations Guide Release 8
472 Draft for Regulatory Review Issue 2, December 2006
12. Power cycle the BHS.
RESULT: Approximately 25 seconds after the power cycle, the green LED
labeled LNK should light to indicate that the link has been established. If the
orange LED labeled SYN is lit instead, then the BHS is in Alignment mode
because the BHS failed to establish the link. In this latter case, and if the BHS
has encountered no customer-inflicted damage, then request an RMA for
the BHS.
=========================== end of procedure ======================
32.5.5 Module Has Lost or Does Not Gain Sync
To troubleshoot a loss of sync, perform the following steps.
Procedure 52: Troubleshooting loss of sync
1. Access the Event Log tab in the Home page of the SM.
NOTE: An example of this tab is shown in Figure 186.
Figure 186: Event Log tab of SM, example
2. Check for messages with the following format:
RcvFrmNum =
ExpFrmNum =
(See Table 67: Event Log messages for abnormal events on Page 414.)
Release 8 Operations Guide
Issue 2, December 2006 Draft for Regulatory Review 473
3. If these messages are present, check the Event Log tab of another SM that is
registered to the same AP for messages of the same type.
4. If the Event Log of this second SM does not contain these messages, then the
fault is isolated to the first SM.
5. If the Event Log page of this second SM contains these messages, access the
GPS Status page of the AP.
6. If the Satellites Tracked field in the GPS Status page of the AP indicates fewer
than 4 or the Pulse Status field does not indicate Generating Sync, check the
GPS Status page of another AP in the same AP cluster for these indicators.
7. If these indicators are present in the second AP
a. verify that the GPS antenna still has an unobstructed view of the entire
horizon.
b. visually inspect the cable and connections between the GPS antenna and
the CMM.
c. if this cable is not shielded, replace the cable with shielded cable.
8. If these indicators are not present in the second AP
a. visually inspect the cable and connections between the CMM and the AP
antenna.
b. if this cable is not shielded, replace the cable with shielded cable.
=========================== end of procedure ===========================
32.5.6 Module Does Not Establish Ethernet Connectivity
To troubleshoot a loss of Ethernet connectivity, perform the following steps.
Procedure 53: Troubleshooting loss of Ethernet connectivity
1. Verify that the connector crimps on the Ethernet cable are not loose.
2. Verify that the Ethernet cable is not damaged.
3. If the Ethernet cable connects the module to a network interface card (NIC),
verify that the cable is pinned out as a straight-through cable.
4. If the Ethernet cable connects the module to a hub, switch, or router, verify that
the cable is pinned out as a crossover cable.
5. Verify that the Ethernet port to which the cable connects the module is set to
auto-negotiate speed.
6. Power cycle the module.
RESULT: Approximately 25 seconds after the power cycle, the green LED
labeled LNK should light to indicate that the link has been established. If the
orange LED labeled SYN is lit instead, then the module is in Alignment mode
because the module failed to establish the link.
7. In this latter case, and if the module has encountered no customer-inflicted
damage, then request an RMA for the module.
=========================== end of procedure ===========================
Operations Guide Release 8
474 Draft for Regulatory Review Issue 2, December 2006
32.5.7 Module Does Not Power Up
To troubleshoot the failure of a module to power up, perform the following steps.
Procedure 54: Troubleshooting failure to power up
1. Verify that the connector crimps on the Ethernet cable are not loose.
2. Verify that the Ethernet cable is not damaged.
3. Verify that the cable is wired and pinned out according to the specifications
provided under Wiring Connectors on Page 182.
4. Remove the cover of the module to expose the components on the printed wiring
board.
5. Find the Ethernet transformer, which is labeled with either the name Halo or the
name Pulse.
6. Verify that the Ethernet transformer does not show damage that would have
been caused by improper cabling. (You can recognize damage as the top of the
transformer being no longer smooth. The transformer in the following picture is
damaged and is ineligible for an RMA.)
7. Connect the power supply to a known good Canopy module via a known good
Ethernet cable.
8. Attempt to power up the known good module and
if the known good module fails to power up, request an RMA for the power
supply.
if the known good module powers up, return to the module that does not power
up.
9. Reconnect the power supply to the failing module.
10. Connect the power supply to a power source.
11. Verify that the red LED labeled PWR lights.
12. If this LED does not light, and the module has not been powered up since the last
previous FPGA firmware upgrade was performed on the module, then request an
RMA for the module.
=========================== end of procedure ===========================
32.5.8 Power Supply Does Not Produce Power
To troubleshoot the failure of a power supply to produce power, perform the following
steps.
Procedure 55: Troubleshooting failure of power supply to produce power
1. Verify that the connector crimps on the Ethernet cable are not loose.
2. Verify that the Ethernet cable is not damaged.
Release 8 Operations Guide
Issue 2, December 2006 Draft for Regulatory Review 475
3. Verify that the cable is wired and pinned out according to the specifications
provided under Wiring Connectors on Page 182.
4. Connect the power supply to a known good Canopy module via a known good
Ethernet cable.
5. Attempt to power up the known good module.
6. If the known good module fails to power up, request an RMA for the power
supply.
=========================== end of procedure ===========================
32.5.9 CMM2 Does Not Power Up
To troubleshoot a malfunctioning CMM2, perform the following steps.
Procedure 56: Troubleshooting CMM2 that malfunctions
1. Verify that the 115-/230-V switch (in the lower right-hand corner of the CMM2) is
in the correct position for the power source. (See Figure 129 on Page 339.)
Applying power when this switch is in the wrong position can damage the CMM2
and will render it ineligible for an RMA.
2. Verify that the electrical source to the CMM2 meets Canopy specifications. See
Table 20 on Page 75.
3. Verify that the electrical source is connected to the CMM2 at the proper
connection point. (See Figure 131 on Page 341.)
4. Verify that the fuse is operational.
5. Verify that the fuse is properly seated in the receptacle.
6. Attempt to power up the CMM2.
7. If the power indicator on the interconnect board of the CMM2 fails to light when
power is applied to the CMM2, request an RMA for the CMM2.
=========================== end of procedure ======================
32.5.10 CMM2 Does Not Pass Proper GPS Sync to Connected Modules
If the Event Log tabs in all connected modules contain Loss of GPS Sync Pulse
messages, perform the following steps.
Procedure 57: Troubleshooting CMM2 not passing sync
1. Verify that the GPS antenna has an unobstructed view of the entire horizon.
2. Verify that the GPS coaxial cable meets specifications.
3. Verify that the GPS sync cable meets specifications for wiring and length.
4. If the web pages of connected modules indicate any of the following, then find
and eliminate the source of noise that is being coupled into the GPS sync cable:
In the GPS Status page
anomalous number of Satellites Tracked (greater than 12, for example)
incorrect reported Latitude and/or Longitude of the antenna
In the Event Log page
garbled GPS messages
large number of Acquired GPS Sync Pulse messages
Operations Guide Release 8
476 Draft for Regulatory Review Issue 2, December 2006
5. If these efforts fail to resolve the problem, then request an RMA for the CMM2.
=========================== end of procedure ======================
32.5.11 Module Software Cannot be Upgraded
If your attempt to upgrade the software of a module fails, perform the following steps.
Procedure 58: Troubleshooting an unsuccessful software upgrade
1. Download the latest issue of the target release and the associated release notes.
2. Compare the files used in the failed attempt to the newly downloaded software.
3. Compare the procedure used in the failed attempt to the procedure in the newly
downloaded release notes.
4. If these comparisons reveal a difference, retry the upgrade, this time with the
newer file or newer procedure.
5. If, during attempts to upgrade the FPGA firmware, the following message is
repeatable, then request an RMA for the module:
Error code 6, unrecognized device
=========================== end of procedure ===========================
32.5.12 Module Functions Properly, Except Web Interface Became Inaccessible
If a module continues to pass traffic, and the telnet and SNMP interfaces to the module
continue to function, but the web interface to the module does not display, perform the
following steps.
Procedure 59: Restoring the web interface to a module
1. Enter telnet DottedIPAddress.
RESULT: A telnet session to the module is invoked.
2. At the Login prompt, enter root.
3. At the Password prompt, enter PasswordIfConfigured.
4. At the Telnet +> prompt, enter reset.
RESULT: The web interface is accessible again, and this telnet connection is
closed.
=========================== end of procedure ===========================
Release 8 Operations Guide
Issue 2, December 2006 Draft for Regulatory Review 477
33 OBTAINING TECHNICAL SUPPORT
NOTE:
The contact information for Canopy Technical Support staff is included at the
end of this section (on Page 481). However, in most cases, you should follow
the procedure of this section before you contact them.
To get information or assistance as soon as possible for problems that you encounter,
use the following sequence of actions:
1. Search this document, the user guides of products that are supported by
dedicated documents, and the software release notes of supported releases
a. in the Table of Contents for the topic.
b. in the Adobe Reader® search capability for keywords that apply.9
2. Visit http://motorola.canopywireless.com/support/knowledge to view the Canopy
Knowledge Base.
3. Ask your Canopy products supplier to help.
4. View and analyze event logs, error messages, and debug messages to help
isolate the problem.
5. Check release notes and verify that all of your Canopy equipment is on the
correct software release.
6. Verify that the Canopy configuration files match the last known good (baseline)
Canopy configuration files captured in the site log book.
7. Verify connectivity (physical cabling).
8. At the SM level, minimize your network configuration (remove home network
devices to help isolate problem).
9. Perform the site verification checklist.
10. Use Table 69 (two pages) as a job aid to collect basic site information for
technical support to use.
9 Reader is a registered trademark of Adobe Systems, Incorporated.
Operations Guide Release 8
478 Draft for Regulatory Review Issue 2, December 2006
Table 69: Basic site information for technical support
Company:
Location:
Site Contact:
Site Phone:
Open Date:
Close Date:
MAC Addresses:
IP Addresses:
Boot Versions:
FPGA Versions:
Is the customer using
shielded cables?
Yes/No
Remote Access Method:
IP Address:
Release 8 Operations Guide
Issue 2, December 2006 Draft for Regulatory Review 479
Link Distance:
dBm=
Jitter=
Reflectors in use:
Yes/No
Problem Description:
New Install: Yes/No
NAT/DHCP Scenario:
NAT Disabled
Yes/No
NAT with DHCP Client and
DHCP
Server
Yes/No
NAT with DHCP Client
Yes/No
NAT with DHCP Server
Yes/No
NAT with no DHCP
Yes/No
11. Save your basic site information as file Site_Info.
12. From among Figure 34 on Page 103, Figure 35 on Page 104, and Figure 36 on
Page 104, select the basic network topology diagram that most closely matches
your network configuration.
13. If you selected Figure 34.
a. Indicate how many APs are in each cluster.
b. Indicate how many AP clusters are deployed (and what types).
c. Include the IP addresses.
d. Indicate the frequency for each sector.
e. Indicate the type of synchronization.
f. Indicate how much separation exists between clusters.
g. For each AP collect the following additional information:
Sector number:
SW release:
Frequency:
Color code:
Operations Guide Release 8
480 Draft for Regulatory Review Issue 2, December 2006
IP address:
Downlink/uplink ratio:
Max range:
Bridge entry timeout:
Number of subscribers:
Method of synchronization:
14. If you selected Figure 35
a. Indicate how many APs are in each cluster.
b. Indicate how many AP clusters are deployed (and what types).
c. Indicate how many BH links are configured.
d. Include the IP addresses.
e. Indicate the frequency for each sector.
f. Indicate the type of synchronization.
g. Indicate how much separation exists between clusters and BHs.
h. Indicate the types of BH links (10-Mbps or 20-Mbps).
i. Distances of links.
j. Frequency used by each BH.
k. For each AP and BHM, collect the following additional information:
Sector number:
SW release:
Frequency:
Color code:
IP address:
Downlink/uplink ratio:
Max range:
Bridge entry timeout:
Number of subscribers:
Method of synchronization:
15. If you selected Figure 36, collect the following additional information:
Sector number:
SW release:
Frequency:
Color code:
IP address:
Downlink/uplink ratio:
Max range:
Bridge entry timeout:
Number of subscribers:
Method of synchronization:
16. Add any details that are not present in the generic diagram that you selected.
17. Save your diagram as file Net_Diagram.
18. Capture screens from the following web pages of affected modules:
Release 8 Operations Guide
Issue 2, December 2006 Draft for Regulatory Review 481
Home page Status tabs as files SM/AP/BHM/BHS_StatusTabname.gif
Configuration page tabs as files SM/AP/BHM/BHS_ConfigTabname.gif
Home page Event Log as file SM/AP/BHM/BHS_Events.gif
Tools page Link Capacity Test tab (with link test results) as file
SM/AP/BHM/BHS_LinkTST.gif
Statistics page Radio tab as file SM/AP/BHM/BHS_RFstats.gif
19. For any affected SM or BHS, capture the Tools page AP Evaluation tab as file
SM/BHS_APEval.gif.
20. For any affected SM that has NAT/DHCP enabled, capture screens from the
following additional web pages:
Configuration page NAT tab as file SM_Natconfig.gif
Configuration page NAT Port Mapping tab as file SM_NatPortmap.gif
Logs page NAT Table tab as file SM_NatTable.gif
Statistics page NAT Stats tab as file SM_NatStats.gif
Statistics page Translation Table tab as file SM_ArpStats.gif
Statistics page NAT DHCP Statistics tab as file SM_DhcpStats.gif
Also capture the Windows IP Configuration screen as file SM _WindowsIP.gif.
21. Escalate the problem to Canopy systems Technical Support (or another technical
support organization that has been designated for you) as follows:
a. Start e-mail to technical-support@canopywireless.com. In this email
Describe the problem.
Describe the history of the problem.
List your attempts to solve the problem.
Attach the above files.
List the files that you are attaching.
b. Send the email.
c. Call 1 888 605 2552 (or +1 217 824 9742).
=========================== end of procedure ===========================
Release 8 Operations Guide
Issue 2, December 2006 Draft for Regulatory Review 483
34 GETTING WARRANTY ASSISTANCE
For warranty assistance, contact your reseller or distributor for the process.

Navigation menu