innovaphone wiki - User contributions [en]

Howto:Understanding DECT handover with IP1200

2010-06-29T08:00:16Z

R.hubers: /* Problem Details */

When a DECT handset is moved, then it may move out of the coverage area of its current radio (base or repeater).

In order to not drop the call in this case, the handset switches the radio used.

This is called “handover”.

Here is how it works.

==Applies To==
This information applies to

* IP 1200

==More Information==

===Problem Details===
When a handset is using a specific radio to handle a call and the handset is moved to the edge of this radios coverage area, then the handset needs to find another radio that can handle the call.

It then needs to switch the call to the new radio and free the resources previously used on the old radio.

This process is referred to as “handover”.

Handover performance is key to an overall good system performance.

If handover is bad, then users will suffer bad voice quality during handover or finally dropped calls.

One major goal during deployment thus is to make sure good handover performance is achieved

===Handover strategy===
Handover is generally initiated by the handset itself.

This is why different handsets may show different handover performance and thus one of the reasons why using non-innovaphone handsets is always risky.

When a handset has a call, it will always monitor the transmission quality on the air.

This is done by looking at the number of bit errors during transmission.

This number of bit errors is measured as “Q-value”.

The higher the Q-value, the better the transmission quality.

The Q-value has a maximum of 64.

During a call, when the Q value drops below 52 or when it becomes unstable or when it drops below 58 while there is a base nearby that has at least 12dB better signal strength, the handset will initiate a handover.

The first step in this process is to look for another radio which may take over the call and provides better quality.

The handset will scan all available (that is, synchronized) radios in the DECT-System and choose the one with the highest signal strength at this point.

It will then try to initiate a handover to this radio (which may fail, e.g. when this radio has no free channels available).

If handover fails, then the handset will try again.

Please note that on the handset in deployment mode, the values are updated every half second only.

In areas with strange signal distortions, the Q value may change quickly which might not be visible on the display thus.

===Possible problems with handover===
While this approach works quite fine, it has some problems with it in some specific scenarios.

The handset will check for a handover every 4 seconds.

The full handover process may last up to 10 seconds.

So when designing a DECT system you need to make sure that the handset will have in fact enough time to perform a successful handover before it looses the current radio.

There are some typical scenarios which make this difficult.

===Fast moving handsets===
When a handset moves out of the coverage area of a radio, then the remaining time where it still will be within the coverage obviously depends on the speed of the handset.

There are many different usage patterns in DECT-Systems.

For example in many office environments, moving handsets are not really an issue as user rarely move during a call and if so, they are not fast.

However, in industrial environments, users often move all the time and they also may move fast.

If we assume a walking speed of 3.5 km/h and a handover time of 10s, then the theoretical coverage overlap required is (3500/3600)*10 = 10 meter.

If we assume a vehicle being used (such as a fork-lift truck) with a speed of 10 km/h, then we end up with 30m required.

Enough coverage overlap is key.

===Partial overlaps===
So far, we have just said that there must be “enough” coverage overlap.

However, the layout of the coverage overlap is also important.

Assume this standard scenario: a rectangular building where there shall be coverage in the surrounding area.

The radios are mounted in the middle of the walls.

There is a huge overlap area.

However, when a user walks from A to B, then the overlap area actually traversed is rather short.

Although at any point along the users path there is enough field strength, the call will likely drop due to the small overlap along the path.

[[image:Howto-Understanding_DECT_handover_with_IP1200_Handover01.PNG]]

It is better to mount the radios on the edges thus as shown below.

[[image:Howto-Understanding_DECT_handover_with_IP1200_Handover02.PNG]]

===Handover speed===
There are 2 kinds of handover implemented in the DECT system, bearer handover and connection handover.

Bearer handover is entirely done in the MAC layer, connection handover is done above in the signaling layer.

Bearer handover is usually faster and less noisy, so normally bearer handover is the better choice.

Moreover, bearer handover can be done as long as the call being handover does not change the base station it is on.

So using bearer handover, the call may switch from one repeater to another or it may even stay on the same repeater or base, just changing the channel used.

Use of bearer handover is controlled by configuration (see below).

That is why repeater chains (repeaters not synced to base stations but to repeaters again) are special and need to be properly configured to work well.

The only drawback of bearer handover is that it reduces the maximum number of base stations in your system, as we will see now.

===How to configure bearer handover===
Use of bearer handover is controlled by the Sys-Mask configured in the radios (Configuration / DECT / System / Sys-Mask).

Normally, this is configured only in the IP-master IP1200 and replicated to the radios.

If you leave this field empty, then always connection hand over is done.

If you configure a value, then this value is used together with a radios radio-ID to determine how handover is to be performed.

Assume a handset wants to perform handover from radio A to radio B.

Then it calculates (A bitwise AND sysmask) and (B bitwise AND sysmask) and checks if both are equal.

If so, bearer handover is performed.

Practically, if sysmask is 0x3F (077 octal or 111111 binary) and the handover shall be done from radio-id 1 to radio id 2, then (1 bitwise AND 0x3f) is 1 and (2 bitwise AND 0x3f) is 2.

Since 1 is unequal 2, connection handover will take place.

Whereas if handover shall be done from radio-id 1 to radio-id 65, then (65 bitwise AND 0x3f) is 1 and since 1 is equal 1, bearer handover will take place.

So to force a bearer handover, you need to configure a sysmask.

You would then set the base stations radio-ids to a value between 0 and your bitmask value (0 to 63 if your bitmask is 0x3f) and the repeaters radio ids to the sync-sources radio + sysmask + 1.

Example: if your sysmask is 0x3f and the radio-id of one of your bases is 2, then you would set the repeaters radio-id to 66.

If you create a repeater chain, then you would set the radio-id of the second repeater to 130 and so on.

With this setting, you can have at most 64 bases stations and repeater chains can be up to 3 repeaters (e.g. 2, 66, 130, 194).

To have more base stations, set sysmask to 0x7f.

You then can have 128 base stations but only one repeater synced to a base (no chain).

To have longer repeater chains, set sysmask to 0x1f.

You then can have 32 base stations and up to 7 repeaters per chain (e.g. 2, 34, 66, 98, 130, 162, 194, 226).

Long repeater chains are not recommended though.

If you have no sysmask configured, no repeater chains are possible, as repeaters cannot perform connection handover. You can then configure up to 255 base stations but no repeaters.

Please note that there cannot be bearer handover from one base to another, only between base and repeater or 2 repeaters.

As a consequence, when you use repeater chains you will need to change the repeaters radio-ids if you need to change the sysmask after installation.

As repeaters can only be programmed using a serial cable, this may be a problem when physical access is difficult after final installation.

We recommend to use a sysmask of 0x3f if you are sure you will not need more than 64 bases, otherwise use 0x7f.

Here is an example of a simple repeater chain with a sysmask of 0x3f:

[[image:Understanding_DECT_handover_with_IP1200_Handover03.PNG]]

The repeaters however need not form a single chain though.

Consider the following example

[[image:Howto-Understanding_DECT_handover_with_IP1200_Handover04.PNG]]

This employs 2 chains to a single base.

In fact, repeaters may as well form a tree, as in the next example (using a sysmask of 0x1f):

[[image:Howto-Understanding_DECT_handover_with_IP1200_Handover05.PNG]]

===Using bearer handover for difficult spots===

As bearer handover is faster than connection handover, it may help in difficult deployment situations.

[[image:Howto-Understanding_DECT_handover_with_IP1200_Handover06.PNG]]

With only the 2 bases A and B, handover will be difficult as the overlap when walking from A to B is short.

Adding a repeater R which is synced to base B can help here.

When the user walks from A to B, the handset will likely at some point in time handover to R.

When proceeding, she will walk out of R’s coverage area rather quickly which then forces a handover to B.

If R can do bearer handover to B, then this may work out OK while a handover from A to B might fail, as it is slower and the time may not suffice.

This will not work when R is synced to A, as in the critical situation again a connection handover would be done.

===Using external antennas to enforce bearer handover===
Sometimes it is difficult to place a repeater so that bearer handover can take place and the repeater gets a reliable sync to the right base.

Consider the above example where 2 radios only have a short overlap.

If it is not feasible to mount the radios as suggested above, you may improve the situation by making sure bearer handover takes place when the user walks from area b to area a.

To do so, you would need to make sure that A actually is a repeater and B is a base A is synced to.

Setting the sysmask properly will ensure that a fast bearer handover takes place. However, getting A synced to B is difficult, as A is not in B’s coverage area.

To overcome, you may install an external antenna within B’s coverage area and attach it to A.

[[image:Howto-Understanding_DECT_handover_with_IP1200_Handover07.PNG]]

This will ensure that A is properly synched to B.

Please note that external antennas are used to grab a signal from or provide a signal to another radio.

They should not be used to provide coverage for portable parts!

==Related Articels==

[[Howto:How to configure IP1200]]

[[Howto:Rules for successful IP1200 deployment]]

[[Howto:How to program repeaters for DECT systems]]

[[Howto:Debugging tools for DECT deployment]]

[[Category:Howto|{{PAGENAME}}]]

Reference8:Administration/PBX/General

2010-03-18T16:50:07Z

R.hubers: /* Common */

The fundamental operating modes of the PBX are configured on this page. These parameters are stored in the config file. All other PBX config is stored in the LDAP.

== Configuration ==

=== Common ===

{|
|valign=top nowrap=true|'''PBX Mode'''
|The PBX operating mode
* '''Off''' - The PBX is disabled. After enabling the PBX a browser refresh is needed to activate additional PBX webpages.
* '''Master''' - The PBX on this device acts as Master. Within a multisite installation exactly one PBX must be configured as Master.
* '''Standby''' - The PBX on this device acts as Standby for the Master. As long as the master is available, this PBX is not active, but just monitors the Master. If the Master is not availabe this PBX is active.
* '''Standby-Slave''' - The PBX on this device acts as Standby for a Slave. As long as the slave is available, this PBX is not active, but just monitors the slave. If the slave is not availabe this PBX is active.
|-
|valign=top nowrap=true|'''System Name'''
| The system Name. On all PBX within a multisite installation the same System Name must be configured. For H.323 endpoints this name is the gatekeeper identifier, for SIP endpoints it is the server name.
|-
|valign=top nowrap=true|'''PBX Name'''
|The name of the PBX on this device. With this name a PBX is associated to a node. The field 'Name' (not Long Name) of a PBX Node object relates to this name.
|-
|valign=top nowrap=true|'''Unknown Registrations'''
|If this checkmark is set, the PBX accepts 'unknown' registrations. This means registrations with no matching object configured. If from an endpoint registered in this way a number of an object is dialed, which has no registration active and no 'HW-ID' configured the name used for the registration is configured as 'HW-ID' of this object. This is an easy way to deploy large numbers of phones.
|-
|valign=top nowrap=true|'''Music On Hold URL'''
|A URL for the Music On Hold. This file is read by the PBX using HTTP and sent to a held endpoint via RTP. The format of this URL is
''<nowiki>http://<addr>/<file>.$coder?coder=g729,g711a,g711u,g723&repeat=true</nowiki>''. <addr> is the IP address of the http server, no dns name is allowed here. <file> is the filename. $coder will be replaced by the actual coder used.
Parameters: ''coder=g729,g711a,g711u,g723'' is the list of available coders. Only these coders must be specified for which a corresponding file exists. ''repeat=true'' should be specified in order to loop the file endlessly. ''random=true'' can be used to start the music on hold on a random point (this will work only if the URL is not local though).

By default the built-in Music-On-Hold is played (Pseudo URL: "MOH?coder=g729,g711a,g723&repeat=true"). You can also play a dial tone (Pseudo URL "TONE") or a ring-back tone (Pseudo URL "TONE?tone=ringback").
If you configure a wrong (or invalid) URL then you will have silence as MOH.
|-
|valign=top nowrap=true|'''External Music On Hold'''
|To offload the device from playing the Music on hold, the Music On Hold can be played by a seperate device. This device can register with a name configured here. To retrieve the Music On Hold a call is sent to this device. For each held endpoint a call is sent.
|-
|valign=top nowrap=true|'''Response Timeout'''
|Global timeout (in seconds) after which any action for no response is taken (e.g. Call Forward on No Response). A timeout configured at any object overrides this value.
|-
|valign=top nowrap=true|'''Dial Complete Timeout'''
|Global timeout (in seconds) after which any action for incomplete dialed number is taken (e.g. incomplete destination at trunk object).
|-
|valign=top nowrap=true|'''No. of Regs w/o Pwd'''
|Number of registration without password authentication which are allowed per user. If 0 is configured no registration without password is possible.
|-
|valign=top nowrap=true|'''Recall Timer'''
|A value configured here enables recall after transfer. If a call is transfered and not answered within this time, the call is sent back to the transfering endpoint.
|-
|valign=top nowrap=true|'''Pickup Prefix V7'''
|In V7, the pickup prefix is obsolete. Please use the pbx object [[:Reference7:Administration/PBX/Objects/DTMF Features|DTMF Featurecodes]].
|-
|valign=top nowrap=true|'''Enable External Transfer'''
|Unless this checkbox is set any attempt to transfer an external call back to an external destination will result in disconnection of the call.
|-
|valign=top nowrap=true|'''RTP Proxy'''
|If this checkbox is set, all media traffic is routed thru the PBX. Check this only if you need to have this, since it creates CPU load on the PBX.
|-
|valign=top nowrap=true|'''Generate CDRs'''
|If this checkbox is set, the PBX generates CDRs for all calls. See [[Reference:Call_Detail_Record_CDR_PBX]] for a description of the CDRs.
|-
|valign=top nowrap=true|'''Route Root-Node External Calls to'''
|Destination object (Long Name) of Root-Node external calls. This configuration option is available on the Master or Standby PBX only. Any call call which cannot be terminated inside the PBX is sent to this destination as long as neither the source nor the destination of the call can be associated with a node with a PBX configured. This object must be assigned to this PBX.
|-
|valign=top nowrap=true|'''Route PBX-Node External Calls to'''
|Destination object (Long Name) of PBX-Node external calls. Any call which cannot be terminated inside the PBX is sent to this destination as long as the source nor the destination of the call can be associated with the node of this PBX. If a call is sent from or to an object defined inside the node of this PBX or in a node hierachically below the node of this PBX the call is associated to the node of this PBX. This object must be assigned to this PBX, that is, it has to register to this PBX.
|-
|valign=top nowrap=true|'''Route Internal Calls to'''
|Destination object (Long Name) to which any call is sent for which a PBX internal destination was found, except for those calls that originated from that object. This can be used to apply special routing on PBX internal calls.
|-
|valign=top nowrap=true|'''Escape Dialtone from'''
|The PBX object (Long Name) to which a call is made to get a dialtone if a dialtone is configured for the escape of a node. As above, this object must be assigned to this PBX.
|-
|valign=top nowrap=true|'''Prefix for Intl/Ntl/Subscriber'''
|Prefixes to be used to map International, National or Subscriber called type of numbers.
* '''International Prefix''' (''00'' in Germany).
* '''National Prefix''' (''0'' in Germany).
* '''Subscriber Numbers''' (E.g ''73009'').
|}

=== Slave PBX ===

If the PBX is operated in Slave mode, then the Slave PBX section is displayed
{|
|valign=top nowrap=true|'''Master'''
|The IP address of the PBX master
|-
|valign=top nowrap=true|'''Alternate Master'''
|The IP address of an alternative PBX master (standby, if available
|-
|valign=top nowrap=true|'''Password'''
|The password to be used for registration at the Master as configured in the Node Object
|-
|valign=top nowrap=true|'''Route Master calls if no Master to'''
|If the master is not available, master calls are sent to this destination
|-
|valign=top nowrap=true|'''Max Calls to Master'''
|This parameter can be used to limit the calls to the master. If a call is sent to the master and there are already calls to/from the master equal to or exceeding this value, the call is handled as if the master was not available.
|-
|valign=top nowrap=true|'''Replication'''
|This parameter allows you to select the replication style for the slave PBX: either ''All'' or ''Local'' (only users that need to be known in this PBX)
|}

=== Standby PBX ===

If the PBX is operated in Standby mode, then the Standby PBX section is displayed
{|
|valign=top nowrap=true|'''Master'''
|The IP address of the PBX master
|-
|valign=top nowrap=true|'''Replicate from Master'''
|Turns on full replication from the master PBX
|}

== License Status ==

=== Licenses ===

A list of all installed PBX license with their current usage is displayed here.

{|
|valign=top nowrap=true|'''Count'''
|The total number of installed licenses of this type.
|-
|valign=top nowrap=true|'''Usage'''
|The total usage of this license type
|-
|valign=top nowrap=true|'''Local'''
|The usage of this license on this PBX
|-
|valign=top nowrap=true|'''Slaves'''
|The usage of this license on PBX's registered to this PBX.
|}

see [[Reference8:Licenses]] for a description of the licenses.

=== Registrations ===

The current number of registrations and the limit as defined by the base license is displayed here. Because this limit is defined by the base license it includes any registrations because of standby as well, which require no registration license.