This document and its contents shall not be reproduced or transferred in any form without express permission.
Compensation will be claimed for any infringement. All rights reserved in the event of patenting or registration of utility
models.
Latest revisions of all publicly available documentation and firmware downloads are available
from our web-site www.hoeft-wessel.de
Höft & Wessel AG
Rotenburger Strasse 20
D-30659 Hannover
Germany
2.10 • 19.01.20077
PRODUCT OVERVIEW
General Description
2. Product Overview
The DECT transceiver module HW 86012 and the Frequency Hopping Spread Spectrum
(FHSS) transceiver module HW 86022 are highly versatile and powerful engines for popular
and advanced DECT / FHSS applications. They provide both RF and baseband signal
processing as well as a complete protocol stack and allow for data and voice transmission.
2.1 General Description
The protocol stack has been implemented as firmware running on the micro controller of the
HW 86012/22. It comprises the DECT protocol layers MAC (EN 300 175-3), DLC (EN 300
175-4) and NWK (EN 300 175-5). Data service is provided according to the DSP C.1/C.2
profile based on LU3 connection. It offers payload data rates of 26 kbit/s in point-to-point
applications and up to four times 26 kbit/s in point-to-multipoint applications.
Aditionally the CLDPS (Connection-Less DECT Packet System) protocol is implemented. It
offers connection-less, packed based data transmission on DECT with payload data rates of
500 kBit/s per radio cell. A base station allocates up to 12 DECT channels (time / frequency
multiplexing) and uses a dedicated slot format. The capacity can dynamically be shared
between the subscribed portables according to the actual demand. CLDPS allows 64
simultaneously connected portables and therefore is capable to support even large wireless
networks.
Based on CLDPS lower layer protocol, an TCP/IP stack is implemented. This allows PT
mode modules to operate with CLDPS base stations (such as HW 8614 Ethernet Base
Station) using TCP/IP protocol.
Data-Unwired embedded DECT / FHSS modules support both connection-based DECT and
packet-based CLDPS, which can be configured by software.
82.10 • 19.01.2007
Comparison of both protocols:
PRODUCT OVERVIEW
General Description
CharacteristicConnection basedPacket based (CLDPS)
Networking capabilityno
1
yes, 64 active subscribers per
radio cell (= base station)
TCP/IP capabilitynoyes
Data rate2x26 kBit/s for up/downlink,
synchronous
up to 500 kBit/s per radio cell,
asynchronous
Symmetry up/downlinksymmetricalasymmetrical, dynamical
Occupied DECT channels1 duplex12 duplex per radio cell
Real-time capabilitiesdata are transferred in fixed 10 ms
time frame
allocation of timeslots by base
station,
not collision-based,
9 traffic slots per 10ms time
frame,
undetermined behaviour with
increasing number of
subsribers and amount of data
2
Voice transmissionyes, between FT and one PT, input
no
via microphone, output to
loudspeaker at the other side
The FHSS protocol stack of the HW 86022 further additionally includes the MAC layer
procedures related to frequency hopping which is required for operation in the 2.4 GHz ISM
band.
Moreover the firmware includes full interworking with the RS-232 interface.
Note: Earlier firmware versions supported a high-speed point-to-point mode. Due to the
development of CLDPS Höft & Wessel devices will no longer support this mode.
1
present 1:4 protocol mode further supported but not recommend for new projects.
2
packet based voice transmission possible
2.10 • 19.01.20079
PRODUCT OVERVIEW
Summary of Features
2.2 Summary of Features
FeatureShort description
Air interfaceHW 86012:
ProtocolsC-Plane according GAP (EN 300 444)
Data transmissionConnection Orientated: According DSP C.2
Point-to-multipointConnection Orientated: up to 4 simultaneous connections
Small footprintSize: 53 mm x 37 mm
Versatile interfacese.g. RS-232, PCM, I/O, I²C, voice, µC bus
Compliant with DECT (EN 300 175)
HW 86022:
Compliant with FCC part 15 and EN 300 328
(EN 300 651)
Connection-Less: CLDPS
(4x26 kBit/s) (EN 300 651)
Connection-Less: up to 64 simultaneous connections (500
kBit/s per radio cell) (CLDPS)
Firmware upgradeableFirmware can be downloaded
VoiceVoice transmission is possible
Easy configurationConfiguration mode for easy installations
Easy subscriptionThrough EasySubs technique
102.10 • 19.01.2007
2.3 Principles of operation
2.3.1 DECT Network Entities
HW 86012 employs radio transmission according to the international DECT standard on 1.9
GHz. It is compliant with the air interface standard EN 300 175. HW 86022 uses a modified
version of that standard which is compliant with FCC part 15 and EN 300 328 for DECT
operation on 2.4 GHz ISM band. The following description applies to both systems.
The DECT standard defines two communication entities: The fixed termination (FT),
commonly seen as base station, and the portable termination (PT), usually a handset.
Throughout this manual the terms “fixed” and “portable” are used in the DECT sense. This
does not preclude that a FT may change its location or a PT may be stationary mounted.
A HW 86012/22 can be configured either as PT or as FT. For the most simple case, a pointto-point connection between two modules, one side must be configured as PT and the other
side as FT
The general architecture of any DECT system comprises one FT and a variable number of
PTs. This is called a point-to-multipoint network. The number of PTs in a network is not
limited by the DECT standard but only by implementation constraints.
PRODUCT OVERVIEW
Principles of operation
Larger DECT networks often include multiple “base stations”. Strictly speaking, the DECT
network still has a single FT but this is distributed on multiple cells. Many people get
confused about that concept, because they associate “base station” and FT. Within DECT
terminology the term “base station” is not used at all, but this entity is called a “radio fixed
part” (RFP). So in any DECT system there is one FT which comprises one or multiple RFPs.
All entities are identified by DECT-internal “addresses” (for a more detailed discussion on
DECT identifiers see section 3.2.1). When installing a DECT system, every PT must learn
the identity of the FT and the FT must learn the identities of each PT. This procedure is
called subscription. Subscription defines which PTs belong to a FT. All DECT security
features (authentication and encryption) build on that mechanism. The subscription
procedure for HW 86012/22 is described in sections 3.2.3 and 3.2.4.
2.10 • 19.01.200711
PRODUCT OVERVIEW
Principles of operation
2.3.2 Connections
A connection always involves a pair PT - FT. There are no direct connections between two
PTs.
Call control works similar to a telephone system. This means there are the following phases
during a communication:
1. A call is set up either by the calling party (can be PT or FT)
2. The call is accepted by the called party (normal case). However the system may be busy
or the called party is not ready to answer the call (exceptional case).
3. The communication channel is used for payload data
4. The call is released by any party (normal case) or by the system (exceptional case)
HW 86012/22 provides efficient methods of call control. These are described in more details
in sections 3.3.4.4 and 5.1.10.
Different types of connections are defined by the DECT standard. E.g. a data connection
differs very much from a voice connection. Most available DECT devices only support voice
connections. This explains, why it is usually not possible to send data from a HW 86012/22
to a consumer type of DECT “base station”.
Connection types supported by HW 86012/22 include data connections of type LU3 and
voice connections of type LU1. Explanations of LU1, LU3 are given in the DECT DLC layer
standard EN 300175-4.
HW 86012/22 supports advanced connection set-up including symmetric multi-bearer
connections.
122.10 • 19.01.2007
3. Firmware description
The standard firmware contains two radio protocols:
• Connection-based single-bearer mode handles up to 4 connections at a time in point-tomultipoint applications with payload data rates of up to 26 kBit/s per connection
• CLDPS packet based transmission mode handles up to 64 PTs operating in a radio cell
at a time in point-to-multipoint applications with payload data rates of up to 500 kbit/s per
radio cell.
3.1 Overview
All functions of the HW 86012/22 are enabled by suitable firmware. This includes the
processing of the DECT communication protocols, the control of interfaces and other
features.
3.1.1 Operation Modes
The firmware may run in any of the following operation modes:
FIRMWARE DESCRIPTION
Overview
Operation modePurpose
Configuration modeSet-up module parameters
Data modeData transmission using the RS-232 as interface or
voice transmission using the analog frontend or PCM.
Download modeLoad the DECT module with new firmware
The data mode has the following sub-modes
Data sub-modesPurpose
Transparent data modeTransparent data transmission over RS-232 interface,
single connection endpoint
Protocol data modeConnection-based:
Multiplexed data transmission over RS-232 interface,
multiple connection endpoints.
CLDPS packet based:
Ethernet frames over RS-232.
The data sub-mode can be configured by use of the SPPR configuration command (see
section 4).
Each of the operation modes has a specific usage of the RS-232 interface. Please refer to
the descriptions of the operation modes.
2.10 • 19.01.200713
FIRMWARE DESCRIPTION
Overview
3.1.2 Mode Selection
The operation mode can be selected either by an appropriate reset sequence or by software
escape commands. The download mode can be selected by a reset sequence or by a
download command from configuration mode.
3.1.2.1 Selection by Reset Sequence
See HW 86012/022 Integration Manual for details on the reset sequence.
If the download mode is entered, the download protocol is invoked. See section 5.5.
When the configuration mode is entered it will be executed using a baud rate of 9.600 bd.
In case the data mode is selected the RS-232 interfaces now works with the configured data
rate (default 115200 kbps).
3.1.2.2 Selection by Software Escape Sequence
A transition from configuration mode to data mode is performed without hardware reset by
use of the EXIT configuration command (see section 4).
A transition from transparent data mode to configuration mode is performed without
hardware reset by use of the +-+ escape sequence (see section 3.3.4.5.3). In this case the
configuration mode will be executed using the baud rate configured for data mode.
142.10 • 19.01.2007
3.2 System Security
The DECT standard includes useful security functions that efficiently protect DECT systems
from hostile break-in and espionage. For details on the security features please refer to
standard EN 300 175-7.
The firmware implements security features in compliance with the GAP standard EN 300
444.
Before a PT is allowed to set-up connections to any FT it must be subscribed at that FT.
During the subscription procedure PT and FT mutually exchange their identities.
In compliance with GAP the firmware supports on-air subscription of PTs, meaning that the
subscription information is exchanged over the air interface. Through on-air subscription the
HW 86012/22 can be subscribed to DECT equipment of other manufacturers.
Offline subscription is an alternative subscription procedure that does not require any
information exchange over the air interface. This procedure is only supported by equipment
of Höft & Wessel.
FIRMWARE DESCRIPTION
System Security
Both procedures lead to equivalent results and can be used alternatively.
On each connection set-up, the FT requests an authentication from the PT. This assures that
only subscribed PTs connect to a FT.
User data is sent over the air in encrypted format. This provides effective protection from
espionage.
2.10 • 19.01.200715
FIRMWARE DESCRIPTION
System Security
3.2.1 DECT Identities
The DECT standard defines identities for PTs and FTs that are used for mutual identification
and authentication. Standard EN 300 175-6 contains a detailed description of these
identities.
The following sub-sections contain a summary of the DECT identities and their usage.
3.2.1.1 FT related Identities
A FT is identified by an ARI (access rights identity).
According to the DECT standard a FT may own multiple ARIs, which are called PARI
(primary ARI), SARIs (secondary ARIs) and TARIs (tertiary ARIs). In accordance with the
GAP service profile (EN 300 444) HW 86012/22 supports one ARI which is then the PARI.
SARIs and TARIs are not supported.
The DECT standard allows different ARI classes. HW 86012/22 (as FT) uses most ARI class
A, but ARI class B and C are also supported. However HW 86012/22 (as PT) is
interoperable with FTs that use a different ARI class.
The ARI class A is a 36 bits wide, world-wide unique identifier. It is factory-burnt into the
module during production and cannot be modified.
However the factory-burnt ARI can be overloaded by a user-defined ARI. The administration
of multi-cell networks is simplified, if all RFPs carry the same ARI. Please see the
configuration command SIARI.
The structure of the ARI class A is shown below.
000EMCFPN
b35b34b33 b32...b17 b16...b0
The three leftmost bits are always zero. This identifies ARI class A.
The EMC (ETSI manufacturer code) is a 16-bit value that has been assigned by ETSI to a
manufacturer. Höft & Wessel has assigned the EMCs 322 and 2921 (decimal).
The FPN (DECT fixed part number) is a 17-bit value that is unique in the context of an EMC.
It is assigned by the manufacturer.
Höft & Wessel uses an internal code, the DNR (DECT serial number) to uniquely identify
modules. The DNR is a 20-bit value. The FPN is derived from the DNR through integer
division by eight:
FPN = DNR div 8
In a multi-cell environment the FT consists in multiple RFPs. In a single-cell environment
there is only one RFP.
Each RFP is identified by a RFPI (radio fixed part identity). It consists in the PARI of the FT
and the RPN (radio fixed part number). The RPN is used in multi-cell networks in order to
distinguish between RFPs which have the same ARI.
RPN shall be 0 for standalone RFP (single-cell environment) and 1 to 7 for multi-cell
systems.
For more complex installations with more than 7 RFPs please contact Hoeft & Wessel for
ARI class B.
162.10 • 19.01.2007
FIRMWARE DESCRIPTION
System Security
In order to identify allowed FTs any PT stores one PARK (portable access rights key). A
PARK corresponds to a single ARI or to a group of ARIs that only differ in their least
significant bits. The PLI (PARK length indicator) defines, how many bits of the ARI are
relevant. The default is 36, i.e. all bits are relevant.
In multi-cell networks the PARK may be selected such that it covers the ARIs of all RFPs.
When a PARK is manually entered, it is coded according to the GAP standard. The following
format is used.
• The PARK starts with two digits representing the PLI in decimal format.
• Then follow up to 12 digits representing <pli> bits of the ARI in octal format. If necessary
the bit string is padded with zeros at the right side in order to achieve octal alignment.
• Finally a check digit is entered. The check digit is calculated as the sum of each digit
multiplied by its position in the string modulo 11. The check digit lies between 0 and 10
and is represented either as the decimal digit, or as a "*" if equal to 10.
Sometimes it can be necessary to manually calculate a PARK from PLI, EMC and DNR this
is illustrated in the following example:
A PT is identified by an IPEI (international portable equipment identity). This is a 36 bits
wide, world-wide unique identifier. It is factory-burnt into the module during production and
cannot be modified.
The structure of the IPEI is shown below.
EMCDNR
b35...b20 b19...b0
The IPEI is part of the default IPUI (international portable user identity) of type N, that is used
for identification of a PT in a DECT network. The DECT standard allows other IPUI types and
allows multiple IPUIs at a PT. HW 86012/22 (as PT) does not use IPUI types other than N.
However HW 86012/22 (as FT) is interoperable with PTs that use a different IPUI type.
2.10 • 19.01.200717
FIRMWARE DESCRIPTION
System Security
3.2.1.3 Subscription Identities
During the subscription procedure defined in the DECT standard a UAK (user authentication
key) is created. This key represents a pair (FT, PT) and must be known by PT and FT since
it is used for the authentication procedure. When the FT requests an authentication from a
PT it tests the correct UAK.
The UAK is not entered nor transmitted over the air interface but independently computed by
FT and PT from public information which is encrypted using a secret PIN (personal identity
number) code.
This PIN code is stored at the FT and must be entered at the PT as part of the subscription
procedure.
The format of the PIN is 1 to 8 decimal digits.
Note: leading zeros in PIN codes are significant, e.g. PIN 007 is different from PIN 7.
The default PIN (factory setting) is: 0
The PIN code is entered at the FT by use of the SIPIN configuration command. System
integrators are advised to use different PINs in different installations in order to provide a
good level of security. The PIN must be entered at the first installation of a FT and can be
modified by the system operator later.
The firmware supports on-air subscription according to GAP and a proprietary offline
subscription procedure. In on-air subscription the public information is transmitted by the FT
over the air interface, whereas in offline subscription it is read out from the FT as SK
(subscription key).
The SK is an encrypted format of the UAK.
182.10 • 19.01.2007
3.2.2 EasySubs
EasySubs is a powerful technique for handling of subscription information in the FT.
Conventional FT implementations include a table of all subscribed PTs with their UAKs.
Since memory is limited, the FT may only support a very limited number of subscriptions.
The EasySubs technique avoids storage of UAKs in the FT but provides an efficient means
for on-demand computation of UAKs from other information already available. Due to
EasySubs, FTs of Höft & Wessel support an unlimited number of PT subscriptions.
EasySubs if fully compliant with the DECT standard. It is used for both, on-air and offline
subscriptions. EasySubs is interoperable with GAP-compliant PTs of other manufacturers.
The security of the DECT system is fully preserved by EasySubs by introducing an additional
key, the SMK (subscription master key). The SMK is stored in the FT in non-volatile memory.
It is used during on-demand computation of UAKs.
Only a single SMK is needed, independent of the number of PTs to be subscribed.
The default SMK (factory setting) is: 00000000
FIRMWARE DESCRIPTION
System Security
The PT stores subscription information in the conventional way, i.e. EasySubs only affects
the FT.
In multi-cell networks all RFPs must be programmed with the same values of PIN and SMK
respectively.
A big advantage of EasySubs: Any PT must only be subscribed to a single RFP of a multicell network. Then it automatically communicates with all other RFPs of that network.
Note: If the system operator modifies the values of PIN and/or SMK at his FT, all previous
PT subscriptions get invalid and must be renewed.
2.10 • 19.01.200719
FIRMWARE DESCRIPTION
System Security
3.2.3 On-Air Subscription of Portable Terminals
The firmware supports on-air subscription according to GAP. In on-air subscription the public
information is transmitted by the FT over the air interface.
The on-air subscription procedure is described below.
Step 1FTEnable on-air subscription by setting SIAIR ON.
Leave FT powered on.
Step 2PTInitiate on-air subscription by issuing a SISUA command. Result
code <ok> signals successful subscription
Step 3FTDisable on-air subscription by setting SIAIR OFF
or by leaving the configuration mode.
Air subscription also is set OFF on a reset of the FT module.
3.2.4 Offline Subscription of Portable Terminals
The firmware supports a proprietary offline subscription procedure that works without
transmitting information over the air interface. Therefore this technique is also applicable to
situations were PT and FT are physically separated during subscription.
The offline subscription procedure is described below.
Step 1PTPerform offline subscription by issuing a SISUD command.
Result code <ok> signals successful command execution. This
does not imply that the subscription itself was successful (e.g.
PIN could be incorrect)
202.10 • 19.01.2007
3.3 Data Mode
The data mode is used to transfer user data from the module's RS-232 interface to the
DECT network and vice versa. Several modes of operation are available to fit different
applications.
3.3.1 Point to Point Operation
•Transparent (connection-based)
Two modules can be configured to operate point to point with transparent data link. over
DECT radio protocol.
•Transparent, (packet-based)
Two modules can be configured to operate point to point with transparent data link over
CLDPS radio procotol.
See section 2.1 for a overwiew of both radio protocols.
3.3.2 Point to Multipoint Operation
These option are based on connection-based DECT protocol.
FIRMWARE DESCRIPTION
Data Mode
•Multipoint mode
One FT can be connected to up to four PTs simultaneously. All interfaces are operated
transparently. On the FT side, all incoming data are transferred to all connected PT,
while all traffic from the PTs are tranferred to the RS-232 interface. Note that data
arriving simultaneously from the PT may be segmented and mixed.
•Protocol Mode
One FT can be connected to up to four PTs simultaneously. While PT modules are
operated transparently on the FT side a LAP protocol mode is used on the serial
interface in order to transport up to four data links on the RS-232 in parallel.
2.10 • 19.01.200721
FIRMWARE DESCRIPTION
Data Mode
3.3.3 Point to Multipoint Networking Operation
These option are based upon CLDPS radio protocol. Typically, a set of HW 86012/22
modules (configured as PT) is used, operating to a wireles infrastructure consisting of HW
8614 Ethernet base stations connected to an Ethernet based loca area network (LAN).
•TCP/IP
The module‘s interface works transparently. The serial data stream is transferred through
a TCP socket connection over CLDPS lower layer protocol. TCP socket can be
terminated by any destination in the LAN or WAN. A protocol implementation is not
required on the host application. This mode uses the module’s TCP/IP stack.
•SWAP
The module‘s interface works transparently. The serial data stream is transferred through
a SWAP connection to a specific server in the LAN running Höft & Wessel SWAP service.
The module operates as SWAP client. User data are directly transferred, no protocol
implementation is required. The module’s SWAP stack is used.
•PPP
The module’s interface works in PPP mode. The module integrates a PPP server to
which the host system‘s PPP client connects. Once established, the PPP link carries
TCP/IP traffic over CLDPS to the base station connected to the Ethernet LAN. The host
application requires to run its own TCP/IP stack. This is similar to a modem dial-up
network.
•Serial Bus Protocol
The module’s interface uses serial bus protocol, i.e. raw Ethernet frames that are carried
by the CLDPS radio protocol are transferred through the RS-232 interface. The
application must implement any higher layer protocols. Refer to section 5.3 for details.
222.10 • 19.01.2007
3.3.3.1 TCP/IP Data Mode
A
r
A
With the onboard TCP/IP stack, the HW 86012/22 allows for very simple system integration.
A serial data stream can be applied to the module’s RS-232 host application interface
without any protocol implementation. A TCP connection transfers the data through the
CLDPS network to the LAN and WAN to any TCP/IP based server. There, the serial data
stream can be terminated in a TCP socket connection.
The HW 86012/22 module may be configured as a TCP/IP server (listening port) or client
(active port) as required by the application. Protocols implemented in the software stack
include TCP, IP, ARP, ICMP and DHCP. Call control on the serial interface allows to setup
and release a connection easily. The TCP/IP mode can only be applied in CLDPS radio
mode.
Portable Application(s)
µC
FIRMWARE DESCRIPTION
Data Mode
pplication Serve
Client Application
RS-232
Transparent
serial stream
HW 86012
TCP/IP
CLDPS
Figure 1: Wireless network using TCP/IP connection for transportation of serial data stream.
DECT Infrastructure
HW 8614 Ethernet Base
CLDPSETH
pplication
Transparent
serial stream
TCP/IP
ETH
LAN / WAN
2.10 • 19.01.200723
FIRMWARE DESCRIPTION
Data Mode
3.3.3.2 SWAP Data Mode
The SWAP transparent data mode is a sub-mode of the data mode. It allows transparent
data transmission using the RS-232 interface. All data is treated as a stream, no specific
framing is required.
This mode is useful for many applications as no protocol is necessary on the module‘s host
system although a networking structure can be realised. Just plain user data are transferred
on the interface.
As a couple of HW 86012/22 clients may need to be multiplexed on the server side, a
dedicated protocol is used internally in the modules: SWAP (Secure W
Protocol) is based on PPPoE (RFC 2516) and LAP and allows for protected data link with
adequate performance on the DECT / CLDPS link and the wired LAN. The Data-Unwired
embedded module implements the SWAP client - invisible to the user. The SWAP server is
located in the network and terminates the SWAP connection. The host application may, as
shown in figure 1, communicate with the SWAP server in various ways.
As an example, an application that used to be operated directly on a serial line can now
easily be transferred to DECT / CLDPS infrastructure operation. The host system software
needs not to be changed as it can communicate to the device connected with the HW
86012/22 module’s serial port by using a virtual COM port provided by Höft & Wessel SWAP
service on a network server.
ireless Access
Portable Application(s)
µC
Client Application
RS-232
Transparent
serial stream
HW 86012
SWAP-Client
CLDPS
DECT Infrastructure
HW 8614 Ethernet Base
CLDPS
ETH
Host System
WIN2K, NT, XP
Local:
VCOM,
Console,
Telnet,
RawTCP
Transparent
serial stream
SWAP Server
Local Application
Remote:
Telnet, RawTCP
ETH
Remote Application
Figure 2: Wireless network using SWAP connection, client application working transparently
242.10 • 19.01.2007
3.3.3.3 PPP Data Mode
The HW 86012/22 module may be configured to operate a PPP server. The host
application‘s PPP client may initiate a PPP connection to the module, having the opportunity
to use it’s own IP address or to trigger the module to receive an IP address from the network
using DHCP. DNS and WINS server addresses, net mask and standard gateway may as
well be configured automatically.
PPP mode may be used in systems implementing TCP/IP stack and PPP protocol. It allows
to connect to the LAN directly through the WLAN infrastructure similar to a modem dial-up
connection.
Portable Application(s)
µC
Client Application
FIRMWARE DESCRIPTION
Data Mode
RS-232
TCP/IP
PPP
HW 86012
PPP Server
CLDPS
Figure 3: Wireless network in PPP mode
3.3.4 Transparent Data Mode
The transparent data mode is a sub-mode of the data mode. It allows transparent data
transmission using the RS-232 interface. The transparent data mode is selected by issuing
the configuration command SPPR OFF.
DECT Infrastructure
HW 8614 Ethernet Base
CLDPS
ETH
LAN/WAN
Both, PT and FT may operate in transparent data mode. Moreover PT and FT may be
operated in different data modes, e.g. a PT in transparent data mode may connect to a FT in
protocol data mode.
In the transparent data mode, all data is treated as a stream. No specific framing is required.
Call control is provided by the modem lead lines.
This mode is restricted to a single connection (point-to-point). This means that even a FT
only supports a single connection when operated in transparent data mode.
2.10 • 19.01.200725
FIRMWARE DESCRIPTION
Data Mode
3.3.4.1 Usage of RS-232 interface
3.3.4.1.1 Connection of the interface
The RS-232 interface is operated in DCE mode and therefore behaves like the RS-232 port
of a modem, i.e. DCDIO and RIIO are outputs of HW 86012/22.
3.3.4.1.2 Interface parameters
The baud rate of the RS-232 interface is selected using the SPBD configuration command.
The actual baud rate can be retrieved with the GPBD command. A list of available baud
rates is shown in response to the IPBD command.
The baud rate setting is a local matter, i.e. the two peers of a connection may use different
baud rates at their ends.
3.3.4.2 Flow Control
For flow control on the RS-232 interface the HW 86012/22 uses hardware handshake (RTS/CTS).
The hardware handshake signals are active low (usual polarisation in TTL level RS-232
interfaces).
The following description applies to hardware handshake.
Whenever the host deactivates RTSI (RTSI goes high), the HW 86012/22 will stop output of
data after the current data byte. Due to pipelining it may happen that some additional bytes
are output before the module stops. Data output is resumed as soon as the module senses
an active RTSI again.
Whenever HW 86012/22 deactivates CTSO (CTSO goes high), the host shall stop output of
data. HW 86012/22 tolerates up to 16 bytes being output by the host after deactivation of
CTSO has occurred. The module activates CTSO again as soon as it is ready to accept
more data from the host.
RTS/CTS handshake is used for local flow control between the module and the connected
host and not directly inter-worked through the DECT link.
In case the host is not ready to accept data from the module and has deactivated RTSI, the
module continues to accept data from its peer until its internal data buffers are filled. Then it
will apply DECT flow control which stops data transmission from the peer.
Hardware flow control can be switched by using the command <SPCOM>.
The peer module continues to accept data from its host (the peer host), until its internal data
buffers are filled. Finally the peer module deactivates CTSO. This signals the peer host to
stop data transmission.
When the host gets ready to accept data and has activated RTSI, the internal data buffers of
the modules are emptied before the peer module activates CTSO. This signals the peer host
to resume data transmission.
262.10 • 19.01.2007
3.3.4.3 Interworking of Modem lead Signals
In transparent data mode the modem lead signals are available on the DTRI, DSRO, DCDIO
and RIIO pins.
DTRI, DCDIO and RIIO signals are interworked to the peer module. DTRI is always
interworked to DSRO. DCDIO and RIIO are interworked to DCDIO and RIIO respectively.
Interworking RIIO and DCDIO requires that one module is configured in DTE mode and the
peer module in DCE mode. In case both peers are configured in DCE mode, RIIO and
DCDIO outputs remain inactive. In case both peers are configured in DTE mode the RIIO
and DCDIO input signals are ignored.
Note: DTRI, DSRO and RIIO are also used for call control purpose. This function may
overload the normal functions of these signals in certain situations. See section 3.3.4.4 for
details.
The DECT protocol transmits modem lead signals such that only changes of these signals
are signalled. When the module detects a change at any of its modem lead inputs it will
transmit a dedicated message to its peer.
FIRMWARE DESCRIPTION
Data Mode
The maximum transmission rate is one message every 10ms. Hence at the receiving side
the lines are updated in 10ms intervals. This effect causes certain changes to the signal
timing. Moreover, due to internal pipelining the timing between data bytes sent over the RS232 interface and modem lead signal changes is not preserved. This must be taken into
account in certain applications.
3.3.4.4 Call Control
Call control uses the modem lead signals DTRI, DSRO and RIIO. The call control function is
multiplexed with the regular usage of these signals.
An outgoing call is a call that originates from the PT.
An incoming call is a call that originates from the FT.
Please also refer to SPECC command.
2.10 • 19.01.200727
FIRMWARE DESCRIPTION
Data Mode
3.3.4.4.1 Outgoing call, PT interface
In order to request a call, the PT-side host shall activate the DTRI signal (i.e. pull it to low
level).
An established call is indicated to the host through an activation of the DSRO signal. The
DSRO signal remains active for at least 10ms.
There might be several reasons why a call request may not be accepted by the peer:
• Busy condition
• Out of coverage range
• Invalid subscription
• Application-specific reasons
The interface does not provide information about the actual reason.
If DSRO remains deactivate the host may continue the call request by retaining DTRI active.
The host may cancel a call request by deactivating DTRI before DSRO has become active.
3.3.4.4.2 Outgoing call, FT interface
To accept outgoing calls the FT-side host shall leave the DTRI signal permanently active. In
this state the FT accepts any outgoing call immediately.
The host shall reject the call by retaining DTRI deactivated.
282.10 • 19.01.2007
3.3.4.4.3 Incoming call, PT interface
A call request from a FT is signalled to the PT-side host by an activation of the DSRO signal.
If the PT is in DCE mode, the call request is also signalled by an activation of the RIIO output
signal (see SPECC command).
The host shall accept the call by activating the DTRI signal for at least 10ms. As soon as the
call is accepted, the RIIO output signal is deactivated for at least 10ms (DCE mode only, see
SPECC command).
3.3.4.4.4 Incoming call, FT interface
For incoming calls please use config mode commands SPDSI and SPDSD. If there are both
entries with SPDSI and SPDSD, the SPDSI entry is used.
On the activation of DTRI or after reset (dependent of DTRI and SPCC) to data mode the
RFP establishes a connection to the PT. At this time DTRI of the PT must be inactive, in
order to prevent a concurrent connection establishment initiated by the PT.
When the connection has been established DSRO of the PT goes to active state and the
host must respond by activating DTRI.
FIRMWARE DESCRIPTION
Data Mode
Example for calling PTs with SPDSI with FT as active part:
StepAction
1FTenter config mode with ‘+-+’
2FTSPDSI EMC, DNR
3FTEXIT, DTRI is active
4PTDTRI is inactive
5PTwhen DSRO goes active activate DTRI
6FTwhen DSRO goes active connection is established
7FT/PTtransmit data
8FT
PT
9FT
PT
go to step 1 for next connection
when DSRO goes inactive deactivate DTRI
after last PT deactivate DTRI
when DSRO goes inactive deactivate DTRI
2.10 • 19.01.200729
FIRMWARE DESCRIPTION
Data Mode
3.3.4.4.5 Call release, PT interface
The PT-side host shall initiate a call release by pulling DTRI inactive for at least 5 seconds. If
after that time also the DSRO signal from the HW 86012/22 is inactive the call has been
released.
The HW 86012/22 shall indicate a call release from the FT or the network to its host by
deactivating DSRO for at least 5 seconds. After this time has expired the host must
deactivate DTRI during the following second unless a new call shall requested.
3.3.4.4.6 Call release, FT interface
The FT-side host shall initiate a call release by pulling DTRI inactive for at least 5 seconds. If
after that time also the DSRO signal from the HW 86012/22 is inactive the call has been
released.
The HW 86012/22 shall indicate a call release from the PT or the network to its host by
deactivating DSRO for at least 5 seconds. The host may retain DTRI activated, while waiting
for new calls.
302.10 • 19.01.2007
Loading...
+ 111 hidden pages
You need points to download manuals.
1 point = 1 manual.
You can buy points or you can get point for every manual you upload.