Aastra NeXspan S Product manual

DRAFT
IP DECT service
Installation and Maintenance Guide
NeXspan IP PBX
AMT/PTD/PBX/0062/1/2/EN
01/2007

Page 2 01/2007 AMT/PTD/PBX/0062/1/2EN
The user is reminded that the use of PBXs at workplace must be in
accordance with the recommendations of the IT law in force.
The user's attention is also drawn to any clauses applicable in laws
relating to the confidentiality of calls transmitted by means of
telecommunications.

Page 3 01/2007 AMT/PTD/PBX/0062/1/2EN
CONTENTS
1INTRODUCTION...........................................................................................................5
1.1 PURPOSE OF THIS DOCUMENT.........................................................................................5
1.2 SCOPE ..................................................................................................................................5
1.3 AUDIENCE ............................................................................................................................5
1.4 REFERENCE DOCUMENTS.................................................................................................5
2ABBREVIATIONS AND DEFINITIONS ........................................................................7
2.1 ABBREVIATIONS .................................................................................................................7
2.2 DEFINITIONS ........................................................................................................................8
3ABOUT THE IP DECT SERVICE................................................................................10
3.1 GENERAL INFORMATION .................................................................................................10
3.2 RULES AND LIMITATIONS FOR USE ...............................................................................10
3.3 SPECIFICATIONS AND PERFORMANCES.......................................................................11
3.3.1 SPECIFICATIONS ..........................................................................................................................11
3.3.2 PERFORMANCES AND CAPACITIES..........................................................................................11
3.4 OPENMOBILITY MANAGER ..............................................................................................12
3.5 IP SIGNALLING ..................................................................................................................12
3.6 USER LICENCE ..................................................................................................................16
3.7 ARCHITECTURE.................................................................................................................17
3.8 RFP......................................................................................................................................18
3.8.1 PRÉSENTATION ............................................................................................................................18
3.8.2 RFP SYNCHRONIZATION.............................................................................................................19
3.8.3 RFP INSTALLATIONS ...................................................................................................................19
3.9 RFP 32 IP ............................................................................................................................22
3.9.1 SPECIFICATIONS ..........................................................................................................................22
3.9.2 REFERENCES................................................................................................................................22
3.10 RFP 34 IP ............................................................................................................................23
3.10.1 SPECIFICATIONS ..........................................................................................................................23
3.10.2 BASE STATION STATUS INDICATORS ......................................................................................23
3.10.3 REFERENCES................................................................................................................................23
3.11 MOBILE TERMINAL M90X .................................................................................................24
3.11.1 PHYSICAL DESCRIPTION OF MOBILE TERMINAL M90X.........................................................24
3.11.2 CONFIGURING AN M90X MOBILE TERMINAL ...........................................................................25
3.12 M910 MOBILE TERMINALS ...............................................................................................27
3.12.1 PHYSICAL DESCRIPTION OF AN M910 MOBILE TERMINAL ...................................................27
3.12.2 CONFIGURING AN M910 MOBILE TERMINAL ...........................................................................28

Page 4 01/2007 AMT/PTD/PBX/0062/1/2EN
3.13 M92X MOBILE TERMINALS...............................................................................................30
3.13.1 PHYSICAL DESCRIPTION OF AN M92X MOBILE ......................................................................30
3.13.2 CONFIGURING AN M92X MOBILE TERMINAL ...........................................................................32
3.14 OPX MOBILE TERMINALS.................................................................................................34
3.14.1 PHYSICAL DESCRIPTION OF AN OPENPHONE 27...................................................................34
3.14.2 CONFIGURING AN OPENPHONE 27 ...........................................................................................35
3.14.3 PHYSICAL DESCRIPTION OF AN OPENPHONE 28...................................................................37
3.14.4 CONFIGURING AN OPENPHONE 28 ...........................................................................................39
4IMPLEMENTING THE IP DECT SERVICE .................................................................41
4.1 PRINCIPLE..........................................................................................................................41
4.2 CONFIGURING THE DHCP SERVER ................................................................................42
4.3 CONFIGURING THE TFTP SERVER..................................................................................43
4.4 INSTALLING AND CONFIGURING THE OMM ..................................................................44
4.4.1 STARTING THE RFPS ...................................................................................................................44
4.5 CONNECTING TO THE OMM APPLICATION (OPENMOBILITY MANAGER) .................52
4.5.1 LOGGING ON TO THE SERVICE..................................................................................................52
4.5.2 LICENCING.....................................................................................................................................53
4.5.3 SYSTEM..........................................................................................................................................57
4.5.4 RFP CONFIGURATION..................................................................................................................61
4.5.5 CONFIGURATION OF PORTABLES PARTS ...............................................................................64
4.6 DECLARATION ON THE NEXSPAN IPBX.........................................................................69
4.6.1 PRINCIPLE .....................................................................................................................................69
4.6.2 DECALRING SIP DECT SUBSCRIBERS AUTOMATICALLY ON THE IPBX .............................69
4.6.3 DECALRING SIP DECT SUBSCRIBERS MANUALLY ON THE IPBX ........................................73
4.7 OMM DECT MONITOR TOOL.............................................................................................74
4.7.1 DESCRIPTION................................................................................................................................74
5DEPLOYING THE IP DECT SERVICE .......................................................................78
5.1 DEPLOYMENT KIT .............................................................................................................78
6MAINTENANCE..........................................................................................................79
6.1 PP TEST MODE ..................................................................................................................79
6.1.1 CHECKING THE OP27 FIRMWARE VERSION ............................................................................79
6.1.2 DIAGNOSIS ....................................................................................................................................79
6.2 BOOTER..............................................................................................................................82
6.2.1 CHECKING THE RFP BOOTER VERSION...................................................................................82
6.2.2 UPDATING THE RFP BOOTER MANUALLY ...............................................................................82
6.2.3 TELNET USER SHELL ..................................................................................................................83
6.2.4 SNMP ..............................................................................................................................................85
6.2.5 APPLICATION................................................................................................................................86

Page 5 01/2007 AMT/PTD/PBX/0062/1/2EN
1 INTRODUCTION
1.1 PURPOSE OF THIS DOCUMENT
This document describes how to install and put into service the DECT service on an IP network
associated with the following PBXs:
• NeXspan S/L/D (F6)
• NeXspan 50 and NeXspan 500 (F4)
• NCS (F5)
1.2 SCOPE
The IP DECT is applicable as of release 4.2 for the following PBXs:
• NeXspan S/L/D (F6)
• NeXspan 50 and NeXspan 500 (F4)
• NCS (F5)
1.3 AUDIENCE
This document is meant for installers whose tasks are to:
♦
♦
♦
Carry out a study into positioning base stations, and system traffic flow
Connect base stations
Start up the IP DECT system and put it into service.
1.4 REFERENCE DOCUMENTS
/1/ RFC 1350, The TFTP Protocol, Revision 2, July 1992
/2/ OpenMobility Generic Mobility Interface; KI: CTB005933
/3/ OpenMobility Matra Startup; KI: CTB006317
/4/ RFC 1156, Management Information Base for Network Management of TCP/IP-based internet,
May 1990
/5/ RFC 1213, Management Information Base for Network Management of TCP/IP-based internet:
MIB-II, March 1991
/6/ RFC 1450, Management Information Base for version 2 of the Simple Network Management
Protocol (SNMPv2), April 1993
/7/ http://www.simpleweb.org/ietf/mibs/index.html?sel=IETF
/8/ OpenMobility Diagnostic Tools
/9/ RFC 2131, Dynamic Host Configuration Protocol, March 1997
/10/ RFC 3164, The BSD Syslog Protocol, August 2001

Page 6 01/2007 AMT/PTD/PBX/0062/1/2EN
DECT standards (ETSI standards):
ETS 300-175: Digital European Cordless Telephone Common Interface
ETS 300-176: Digital European Cordless Telephone approval test specification
ETS 300-444: Digital European Cordless Telephone General Access Profile
Electromagnetic compatibility:
System components comply with the following safety and electromagnetic compatibility
recommendations:
ETS 300-329: Radio Equipment Systems; Electromagnetic Compatibility for Digital
Enhanced Cordless Telephone.
EN 60950: Security of data processing equipment
EN 50081-1: Electromagnetic compatibility, transmission
EN 50082-1: Electromagnetic compatibility, immunity
M900 M901 M902 User Guide PS8348*
NeXspan C/S/L/D Operating Manual - Volume 1 (PS8147*)
NeXspan C/S/L Operating Manual - Volume 2 (PS8148*)
NeXspan C/S/L Operating Manual - Volume 3 (PS8149*)
Clusters, cards and plugs Installation Manual - F4 range - Release R3.2 (PS10268*)
NeXspan 50 Operating Manual - Volume 1 (PS10225*)
NeXspan 50 Operating Manual - Volume 2 (PS10226*)
NeXspan 50 Operating Manual - Volume 3 (PS10227*)
NeXspan 50 Operating Manual - Volume 4 (PS10228*)
NeXspan 50 Operating Manual - Volume 5 (PS10229*)
NeXspan C/S/L Installation and Maintenance Manual (PS10271*)
M910 User’s Guide (PS10447*)
M920 M921 M922 User’s Guide (PS10419*)
OPENPHONE 27 User’s Guide
OPENPHONE 28 User’s Guide

Page 7 01/2007 AMT/PTD/PBX/0062/1/2EN
2 ABBREVIATIONS AND DEFINITIONS
2.1 ABBREVIATIONS
AC Authentication Code
ADPCM Adaptive Differential Pulse Code Modulation
ARI Access Right Identity
DCK DECT Ciphering Key
DHCP Dynamic Host Configuration Protocol
DSP Digital Signal Processor
CRC Cyclic Redundancy Checking
DECT Digital Enhanced Cordless Telecommunications
EIC Equipment Installation Code
EMC Equipment Manufacturer Code
F4 iPBX range comprising NeXspan 50 and NeXspan 500
F6 iPBX range comprising NeXspan L (XL), NeXspan S (XS) and NeXspan C (XC)
FPS Fixed Part Sub-number
GAP Generic Access Profile
HTTP Hyper Text Transfer Protocol
IPEI International Portable Equipment Identity
IPUI International Portable User Identity
LAL Location Area Level MMC
PLL Permanent Logical Link
NCS NeXspan Communication Server
OMM OpenMobility Manager
PARI Primary ARI
PARK Portable Access Right Key (assigns the rights of a cordless handset)
PARK PARK with PLI y
PP Portable Part (Portable DECT)
PBX Private Branch eXchange
PLI Park Length Indicator
PSN Portable Serial Number
PUN Portable User Number
PUT Portable User Type
RFPI Radio Fixed Park Identity
RPN Radio Port Number
RSSI Radio Signal Strength indicator
RFP Radio Fixed Part
RTCP Real Time Control Protocol
RTP Real Time Protocol
SARI Secondary ARI
SNMP Simple Network Management Protocol
TFTP Trivial File Transfer Protocol
UAK User Authentication Key
UCT1 First-generation Central Processing Unit Card
UCT2 Second-generation Central Processing Unit Card
UCT3 Third-generation Central Processing Unit Card

Page 8 01/2007 AMT/PTD/PBX/0062/1/2EN
2.2 DEFINITIONS
DECT Digital Enhanced Cordless Telecommunications
• The standard (ETS 300 175) basically specifies the air interface.
Voice and data can both be transmitted via this interface.
• Its basic technical characteristics are:
• Frequency range: approx. 1,880 – 1,900 GHz (approximately
20 MHz bandwidth)
• 10 carrier frequencies (1,728 MHz spacing with 12 time slots
each)
• Doubling the time slot (to 24) using the TDMA process.
• Net throughput per channel: 32 kbits/s (for voice transmission
using ADPCM)
• Voice coding using the ADPCM method
• Maximum transmission power: 10 mW
GAP Generic Access Profile
• GAP is the abbreviation for Generic Access Profile.
• The GAP standard (ETS 300 444) is based on the same
technology as DECT, but is limited to the most important basic
features. This standard was created to allow telephones from
different manufacturers to be used on any type of DECT system.
It is thus the lowest common denominator for the variants of the
DECT standard specific to all the manufacturers.
• There is an important limitation in the GAP standard: external
handover is not possible. For this reason, connection handover
is used, which is supported by GAP terminals.
• The operation of GAP-capable telephones is comparable to that
of analogue terminals. For example, features can be called up via
‘*’ and ‘#’ procedures.
Handover Handover
Handover is similar to roaming, but occurs during an on-going call.
Handover normally takes place without disrupting the call (seamless
handover).
IPEI International Portable Equipment Identity
• 13-digit identification code for PPs
• Example: 00019 0592015 3
(the final digit is the checksum).
• The code is represented in decimal form.
• This code is globally unique.
PARK Portable Access Rights Key
Access code for the portable part. This code determines whether or
not a PP can access a specific DECT system. Used for unique
selection of the system at enrolment.
Roaming Roaming

Page 9 01/2007 AMT/PTD/PBX/0062/1/2EN
While in motion, the PP continuously performs measurements to
determine which RFP is best received. The best received RFP is
defined as the active RFP. To prevent the PP from rapidly switching
back and forth between two RFPs that can be almost equally well
received, certain threshold values apply (similar to a Schmitt trigger
circuit).
RFP cluster An RFP cluster consists of a set of synchronised RFPs (all the RFPs
of the same cluster belonging to the same DECT network).
Primary RFP An RFP is defined as primary RFP for each call and each portable
handset. The RFP is in charge of setting up the call (DECT radio
channel taken between the RFP and the portable handset).
Secondary RFP During handover, this is the new RFP with which a new radio channel
is taken with the portable handset. This RFP has a voice path set up
with the primary RFP by the LAN and also a signalling path set up by
the LAN.
The handset no longer has any radio channel set up with the primary
RFP.

Page 10 01/2007 AMT/PTD/PBX/0062/1/2EN
3 ABOUT THE IP DECT SERVICE
3.1 GENERAL INFORMATION
The IP DECT service is meant for NeXspan S/L/D, NCS, NeXspan 50 and NeXspan 500 PBXs.
The IP DECT system contains the following items:
♦
♦
♦
♦
♦
♦
♦
The mobile terminal which gives the user access to PBX telephony features
The base station which provides radio coverage for a given area and supports eight
simultaneous calls
The number of base stations to be installed in order to ensure full coverage on each site
can only be determined after on-site radio study.
OpenMobility Manager (OMM), which manages the service either on one of the radio
fixed parts (main RFP), or on the Linux server PC
A web interface (accessible through a dedicated URL), for managing the OMM
configuration
An iPBX, which manages all the calls, especially those passing through the IP network
A GSI gateway associated with the iPBX which manages the SIP DECT STIMULI
signalling interface with the OMM application.
RFPs
255 max.
WEB interface
NeXspan iPBX
GSI gateway
OMM
(RFP in OMM mode)
3.2 RULES AND LIMITATIONS FOR USE
♦ One OMM interface per IP DECT network

Page 11 01/2007 AMT/PTD/PBX/0062/1/2EN
♦ A single PARI number per IP DECT network
♦
♦
♦
♦
♦
♦
♦
♦
•
•
♦
♦
♦
♦
•
•
•
All the radio fixed parts on a DECT network have the same PARI
A DECT network may contain several DECT RFP clusters.
3.3 SPECIFICATIONS AND PERFORMANCES
3.3.1 SPECIFICATIONS
Frequency range used for the air interface (handset/radio fixed part): 1,880 – 1,900 GHz
(20 MHz bandwidth)
10 carrier frequencies (1,728 Mhz spacing), with 12 TS each
Throughput per channel: 32 kbit/s
Power: 10 mW.
3.3.2 PERFORMANCES AND CAPACITIES
Number of RFPs per DECT network: 256 RFPs maximum
RFP capacities
8 TS for voice
4 TS for signalling
Maximum number of handsets per DECT network, with OMM installed on an RFP: 512
handsets
Maximum number of handsets per DECT network, with OMM installed on a Linux server
PC: 1000 handsets
If the number of SIP DECT handsets is between 1000 and 4000, it is necessary to use
four OMMs, installed on four Linux server PCs.
The maximum number of managed handsets is 4000, limited by:
The Call server NCS capacity (4000 logical subscribers)
The declaration of these subscribers on the SIP gateway
1000 SIP DECT subscribers per OMM installed on a Linux server PC.

Page 12 01/2007 AMT/PTD/PBX/0062/1/2EN
3.4 OPENMOBILITY MANAGER
The OpenMobility Manager (OMM) performs the following tasks:
♦
♦
♦
♦
♦
♦
♦
♦
♦
Sending signals to the GSI gateway (IP Stimuli <-> DECT GAP)
IP flow management
Managing sync-over-air functions between RFPs
System management and configuration interface
OpenMobility Manager (OMM) may run on one of the RFPs or on a dedicated Linux server.
3.5 IP SIGNALLING
Calls between an IP phone and a PP (portable DECT)
To establish a call between an IP Phone and a PP, the following IP streams must be established
for the signalling path:
A signalling channel between the IP phone and the iPBX
A signalling channel between the iPBX (GSI gateway) and the equipment hosting the
OMM
A control interface between the OMM and the RFP that has a connection to the PP
A DECT radio signalling channel between the RFP and the PP.
To establish a call between an IP Phone and a PP, the following IP streams must be established
for the voice path:
A Real Time Protocol (RTP) / Real Time Control Protocol (RTCP) connection between
the IP phone and the primary RFP (RFP associated with the PP).
The following figure illustrates this scenario:
NeXspan iPBX
GSI gateway
Signalling
RFP control interface
OMM
(RFP in OMM mode)
Primary
RFP
IP phone
RTP/RTCP

Page 13 01/2007 AMT/PTD/PBX/0062/1/2EN
Calls between two PPs
To set up a call between two PPs, the same IP streams must be established beforehand.
RTP/RTCP streams are established directly between the RFPs managing the PPs, unless the
PPs are connected to the same RFP. In this case, no RTP packets are transmitted on the LAN by
the RFP.
The following figure illustrates this scenario:
OMM
(RFP in OMM mode)
Signalling
RFP control interface
RTP/RTCP
NeXspan iPBX
GSI gateway
Note: VoIP resources are required if an announcement is transmitted to the PP.

Page 14 01/2007 AMT/PTD/PBX/0062/1/2EN
Handover during a call from a PP
If the PP user is moving and the PP detects a stronger signal from another RFP, it starts the
handover process.
Upon completion of the handover process, the voice path between the IP phone and the PP is
established:
• Between the IP phone and the primary RFP
• Between the primary RFP and the secondary RFP.
The following figure illustrates this scenario:
NeXspan iPBX
GSI gateway
Signalling
RFP control interface
RTP/RTCP
IP phone
OMM
(RFP in OMM mode)
Primary RFPSecondary RFP

Page 15 01/2007 AMT/PTD/PBX/0062/1/2EN
When the PP user moves to a radio coverage area with the next RFP, the PP detects a stronger
signal and the handover process starts again.
Upon completion of the handover process, the voice path between the IP phone and the PP is
established:
• Between the IP phone and the primary RFP
• Between the primary RFP and the new secondary RFP.
The following figure illustrates this scenario:
NeXspan iPBX
GSI gateway
Signalling
Control RFP interface
RTP/RTCP
IP phone
OMM
(RFP in OMM mode)
Primary RFPNew secondary RFP

Page 16 01/2007 AMT/PTD/PBX/0062/1/2EN
3.6 USER LICENCE
The OMM must be enabled with a license key (user licence), which depends on the MAC
address of some RFPs in the DECT system The license key is entered and managed via the
OMM web interface
There are several types of licences:
♦
♦
Licence for 1 or 2 RFPs
Licence for more than 2 RFPs
As mentioned above, the licence depends on the MAC addresses of the DECT system RFPs
(RFP licence).
Each RFP is associated with a licence regardless of its location.
The number of RFP MAC addresses encoded in the license depends on the size of the DECT
installation.
System size
(Number of RFPs)
Number of RFP MAC addresses
encoded in the licence (RFP licence)
1 1
2 2 (1, if a second RFP has been added to a single-RFP
system)
More than 2 3
In addition to the MAC addresses the PARK (Portable Access Rights Key), which identifies the
DECT installation, is also part of the licence.
Since a DECT system can only be operated with a valid PARK, a DECT installation without a
license will be inactive.
Depending on the size of the IP DECT system, it will still work if some RFP licences are out of
service.
System size
(Number of RFPs)
Number of RFP licences Minimum number of
RFP licences available
1 1 1
2 2 1
More than 2 3 2
If the minimum number of RFP licences cannot be reached by the OMM, or if the number of
managed RFPs is above the number of licences, the DECT system will block voice
transmissions.

Page 17 01/2007 AMT/PTD/PBX/0062/1/2EN
3.7 ARCHITECTURE
The different types of IP DECT service architectures are:
♦
♦
A DECT network comprising one or more clusters
Several DECT networks with one or more clusters each
Note: One OMM per DECT network
An RFP cluster consists of a set of synchronised RFPs (all the RFPs of the same cluster
belonging to the same DECT network). Therefore, there can be several clusters on the same
DECT network.
These clusters are outside the radio coverage (for them to be defined as “clusters”).
You can have radio coverage from different DECT networks (radio coverage from different
clusters that have nothing to do with each other since they belong to different DECT networks).
This is, for instance, the case of a Call Manager managing all the IP SIP DECT subscriptions of
several fully inter-dependent companies.
In this case, each OMM has its own subscriptions, and all the SIP subscriptions are managed
by the same Call Manager.

Page 18 01/2007 AMT/PTD/PBX/0062/1/2EN
LIMITATIONS:
All the SIP (DECT/IP) subscriptions must be declared on the Call Manager with which the GSI
gateway (SIP access point) is established.
Therefore:
If the GSI gateway (SIP access point) is located on an NCS (F5), the SIP subscriptions must be
declared on F5.
If the SIP access point is located on an IPS card of a NeXspan iPBX (F6), the SIP subscriptions
must be declared on the F6 fitted with the IPS card.
3.8 RFP
3.8.1 PRÉSENTATION
The DECT RFP transmits and receives radio signals to and from the PP.
This RFP is directly connected to the LAN, declared and managed as an IP element from the
OMM interface.
The RFPs used for this IP DECT service are:
• RFP32 IP: a 12-channel RFP (8 for voice and 4 for signalling) meant for interior
installation only
• RFP34 IP: a 12-channel RFP (8 for voice and 4 for signalling) meant for exterior
installation
Any RFP in an IP DECT installation can be chosen to work not only in RFP mode, but also in
OpenMobility Manager (OMM) mode.
Others are in RFP mode only.

Page 19 01/2007 AMT/PTD/PBX/0062/1/2EN
RFP ONLY MODE
In this mode, the RFP converts the data to be transmitted from IP format to DECT format (or vice-
versa).
Exchanges between the RFP and the PP take place on the air interface via the 12 available
DECT time slots:
♦
♦
♦
♦
8 for voice call in the real sense of it
4 for signalling
In a cluster, RFPs are synchronized to enable a seamless handover when a user moves from
one coverage area to another.
For synchronization, it is not necessary for an RFP to communicate directly with all other RFPs in
the system.
Each RFP only needs to be able to communicate with the next RFP in the chain. But it is
preferable for an RFP to see more than one RFP to guarantee synchronization in the event that
one of the RFPs fails.
The 4 control signalling channels are also used to carry handover start signals. If the radio signal
of another RFP is stronger than that of the current RFP, then the handset starts the handover
process with the RFP that has the stronger signal as the user moves around the site.
OPENMOBILITY MANAGER MODE:
In this mode, the RFP functions as a regular RFP and manages the IP DECT service.
An IP address must be defined for this RFP.
This RFP thus declared on the DHCP server enables you to start the management web interface
of the IP DECT service.
3.8.2 RFP SYNCHRONIZATION
The RFPs are synchronized over the air interface.
For the RFP to synchronize with another RFP, the signal strength should not drop below
–70 dBm.
To avoid communication failure, the radio signal received by the PP must not fall below – 60
dBm.
3.8.3 RFP INSTALLATIONS
The following rules must be observed:
Horizontally, the RFPs must be located 2.50 m away from each other, and 0.25 m
vertically.
The RFPs must be fixed at a height of 1.80 m to 2.30 m, with a ceiling height of 0.50 m.
To guarantee a handover if a caller moves from one RFP coverage area to another, an accurate
synchronization of the RFPs is necessary.

Page 20 01/2007 AMT/PTD/PBX/0062/1/2EN
When all the RFPs are started up, the first RFP to synchronise by receiving the radio signal over
the IP frame will be considered as the reference RFP for the entire system. The synchronisation
is then transmitted to all the RFPs over the air interface.
The first RFP to synchronise in turn transmits a signal on the air and becomes the
synchronisation source for the next RFPs, and so on.
Only RFPs which can receive each other will be synchronized.
R 111 R 110 R 109 R 108 R 106
R 101 R 102 R 103 R 104 R 105
R 107
Unsynchronized RFP,
which does not receive a
signal from another RFP
Unsynchronized RFP,
which receives a signal
from another RFP and
tries to get synchronized
Synchronized RFP,
which receives and
transmits a signal on the
air interface
As long as an RFP is not in sync, no calls can be set up using this RFP.
If an RFP loses the synchronization the RFP does not accept new calls (‘busy bit’). There is a
delay of max. 3 minutes until the active calls on this RFP are finished. Then it tries to get
synchronized again.
An IP DECT installation is more reliable if an RFP can receive the signal from several RFPs,
because the other signals are also used for synchronization