I would be really gratefull for help with this problem.
Our customer has mixed DECT system (RBS and IBS).
All shelfs have RBS base station but one shelf has IBS.
Everything worked OK but problem appeared after upgrading to OXE R9.0 (h1.301.34)
Now user that is registred with RBS is workin fine until it comes to area with IBS. The problem is that when he arives into area that is covered with IBS user gets ''no answer from the system'' error and user must turn of and turn on the device so he can use DECT in IBS area. The procedure is the same when arriving form IBS to RBS.
What could be the reason for this problem. As I mentioned everything worked fine till the upgrade.
DECT user changing between IBS and RBS
Re: DECT user changing between IBS and RBS
Show output with "config all", "dectview ibs" and "infocs" command.
May be you have problem with synchronization.
May be you have problem with synchronization.
-
inovakom
Re: DECT user changing between IBS and RBS
dectview syncibs
Fri Dec 4 11:45:33 CET 2009
Group No 1 of IBS that are well synchronized (list of RPN) :
15- 0- 12- 13- 9- 42- 11- 43- 2- 7- 6- 41- 5- 3- 40- 8- 4- 14-
Group No 2 of IBS that are well synchronized (list of RPN) :
1-
infocs
Fri Dec 4 11:37:11 CET 2009
+----------------------------------------------------------------------+
| N_CR | N_CPL | TYPE | N_ACCES | PRIO | SYNC_CLOCK | TG/LK |
+----------------------------------------------------------------------+
| 0 | 24 | BPRA2 | 0 | 0 | SYNCHRO | TG:0 |
| 0 | 25 | PRA2 | 0 | 1 | POT_SYNCHRO | TG:0 |
| 0 | 26 | BPRA2 | 0 | 2 | POT_SYNCHRO | TG:0 |
| 1 | 27 | PRA2 | 0 | 20 | NOT SYNC | TG:10 |
| 0 | 26 | BPRA2 | 3 | 20 | POT_SYNCHRO | TG:2 |
| 0 | 26 | BPRA2 | 2 | 20 | POT_SYNCHRO | TG:2 |
+----------------------------------------------------------------------+
+---------------------------------------------------------------------+
| Synchronization on global domain |
+---------------------------------------------------------------------+
+========================== Synchro DECT ==================================+
+--------------------------------------------------------------------------+
| N_CR | N_CPL | TYPE | DECT_CLOCK | Depending Crystals |
+--------------------------------------------------------------------------+
| 0 | 6 | CPU7_STEP2 | DTM SYNCHRO | 1 2 3 4 5 6 7 |
| 0 | 16 | DECT4HB | DTM PRESENT | |
| 0 | 20 | CPU7_STEP2 | DTM PRESENT | |
+--------------------------------------------------------------------------+
I will also post output of ''config all'' and ''dectview ibs''.
I do not see why the problem with synchronization should appear after upgrading the system. As I told before the problem was not present befor the upgrade. I also do not see the problem in infocs output.
Fri Dec 4 11:45:33 CET 2009
Group No 1 of IBS that are well synchronized (list of RPN) :
15- 0- 12- 13- 9- 42- 11- 43- 2- 7- 6- 41- 5- 3- 40- 8- 4- 14-
Group No 2 of IBS that are well synchronized (list of RPN) :
1-
infocs
Fri Dec 4 11:37:11 CET 2009
+----------------------------------------------------------------------+
| N_CR | N_CPL | TYPE | N_ACCES | PRIO | SYNC_CLOCK | TG/LK |
+----------------------------------------------------------------------+
| 0 | 24 | BPRA2 | 0 | 0 | SYNCHRO | TG:0 |
| 0 | 25 | PRA2 | 0 | 1 | POT_SYNCHRO | TG:0 |
| 0 | 26 | BPRA2 | 0 | 2 | POT_SYNCHRO | TG:0 |
| 1 | 27 | PRA2 | 0 | 20 | NOT SYNC | TG:10 |
| 0 | 26 | BPRA2 | 3 | 20 | POT_SYNCHRO | TG:2 |
| 0 | 26 | BPRA2 | 2 | 20 | POT_SYNCHRO | TG:2 |
+----------------------------------------------------------------------+
+---------------------------------------------------------------------+
| Synchronization on global domain |
+---------------------------------------------------------------------+
+========================== Synchro DECT ==================================+
+--------------------------------------------------------------------------+
| N_CR | N_CPL | TYPE | DECT_CLOCK | Depending Crystals |
+--------------------------------------------------------------------------+
| 0 | 6 | CPU7_STEP2 | DTM SYNCHRO | 1 2 3 4 5 6 7 |
| 0 | 16 | DECT4HB | DTM PRESENT | |
| 0 | 20 | CPU7_STEP2 | DTM PRESENT | |
+--------------------------------------------------------------------------+
I will also post output of ''config all'' and ''dectview ibs''.
I do not see why the problem with synchronization should appear after upgrading the system. As I told before the problem was not present befor the upgrade. I also do not see the problem in infocs output.
Re: DECT user changing between IBS and RBS
From TC 274 ed.12
With DTM configuration on CPU6 (from Release 4.2) or CPU7 (from Release 6.0), you should use the DTM feature on CPU6 or CPU7 (Main and Stand-By) and do not mix the DTM feature with DECT8 couplers if multi-ACT configuration with INTOF links.
For mixed system:
The handover does not operate between RBS and IBS. The radio coverage of two domains must not overlap otherwise you can have the Campus effect.
About config all - what type of used inter-ACT link - INTOF or INTIP?
With DTM configuration on CPU6 (from Release 4.2) or CPU7 (from Release 6.0), you should use the DTM feature on CPU6 or CPU7 (Main and Stand-By) and do not mix the DTM feature with DECT8 couplers if multi-ACT configuration with INTOF links.
For mixed system:
The handover does not operate between RBS and IBS. The radio coverage of two domains must not overlap otherwise you can have the Campus effect.
About config all - what type of used inter-ACT link - INTOF or INTIP?
-
inovakom
Re: DECT user changing between IBS and RBS
Hi vad,
The inter-ACT link is made with INTOF.
I read TC274 ed.12 and I saw that radio covereg should not overlapp. In documentation I also saw that problem that is appearing could be because of coverage overlaping. But the problem is that problem was not present before an upgrade of OXE and now I'm trying to find out how to solve the problem.
I know that handover does not operate between IBS and RBS but there should be call recovery. But there should be no problem in case that there is no call active. DECT should work even the user come from RBS to IBS.
Do you think that the problem is that DTM synchronization?
The inter-ACT link is made with INTOF.
I read TC274 ed.12 and I saw that radio covereg should not overlapp. In documentation I also saw that problem that is appearing could be because of coverage overlaping. But the problem is that problem was not present before an upgrade of OXE and now I'm trying to find out how to solve the problem.
I know that handover does not operate between IBS and RBS but there should be call recovery. But there should be no problem in case that there is no call active. DECT should work even the user come from RBS to IBS.
Do you think that the problem is that DTM synchronization?
-
inovakom
Re: DECT user changing between IBS and RBS
Hello,
Unfortunatelly no reply to my post.
I simulated the system with R8.0.1 and the same problem appeared. I'm simulating the system with 2 ACT. First ACT has RBS and the second one has IBS. I register DECT on RBS and then I put into service also IBS. When both base stations are in service I disable the RBS and DECT device should now work on IBS. But I get ''no answer from the system error'' and I have to switch off/on the device and then every thing works. Our customer has the same problem.
I know that ''no answer from the system'' could be because of the radio coverage overlaping, but our customer did not have this problem until upgrade to R9.0
Did any one ocure similar problem in case of mixed system (RBS&IBS)? What could be the reason for the problem?
I would be really gratefull for any help.
Unfortunatelly no reply to my post.
I simulated the system with R8.0.1 and the same problem appeared. I'm simulating the system with 2 ACT. First ACT has RBS and the second one has IBS. I register DECT on RBS and then I put into service also IBS. When both base stations are in service I disable the RBS and DECT device should now work on IBS. But I get ''no answer from the system error'' and I have to switch off/on the device and then every thing works. Our customer has the same problem.
I know that ''no answer from the system'' could be because of the radio coverage overlaping, but our customer did not have this problem until upgrade to R9.0
Did any one ocure similar problem in case of mixed system (RBS&IBS)? What could be the reason for the problem?
I would be really gratefull for any help.
-
Jaap
Re: DECT user changing between IBS and RBS
The real problem is that you (the customer) used the system out of spec. You (the customer) was lucky that it worked anyway. Still that's hardy ground for complaints.
The underlying reason is that the "no overlaping radio coverage" clause forces the handset to do a Location Registration when the handset roams into range of one or the other site. This Location Registration procedure arranges for the proper IDs to be assigned, call routing to be arranged, etc.
Now that you do have overlapping radio coverage the handset doesn't execute the Location Registration, hence doesn't get the proper IDs assigned, hence cannot communicate with the system. An Off/On cycle does force a LOC-REG, hence results in a working handset.
The reason why this used to work? Probably different location handling before, I don't know.
The underlying reason is that the "no overlaping radio coverage" clause forces the handset to do a Location Registration when the handset roams into range of one or the other site. This Location Registration procedure arranges for the proper IDs to be assigned, call routing to be arranged, etc.
Now that you do have overlapping radio coverage the handset doesn't execute the Location Registration, hence doesn't get the proper IDs assigned, hence cannot communicate with the system. An Off/On cycle does force a LOC-REG, hence results in a working handset.
The reason why this used to work? Probably different location handling before, I don't know.
-
inovakom
Re: DECT user changing between IBS and RBS
I'm gratefull for any answer.
I know that the most possible reason would be radio coverage overlaping. But here is the hole story that confuses me.
Our customer had only RBS system, then one additional shelf was added that has IBS. Interconnection is made with INTOF links. The problem with ''no answer from the system'' appeared after installing new shelf with IBS. But the problem was solved by another company whic is not present anymore. Everything worked till the software upgrade from R5.0Ux to 9.0.
So you see my problem this problem was present at the first start of the new shelf with IBS, but was solved. No change was made in configuration or positioning of the base stations, and now the problem is here again after upgrade.
I know that the most possible reason would be radio coverage overlaping. But here is the hole story that confuses me.
Our customer had only RBS system, then one additional shelf was added that has IBS. Interconnection is made with INTOF links. The problem with ''no answer from the system'' appeared after installing new shelf with IBS. But the problem was solved by another company whic is not present anymore. Everything worked till the software upgrade from R5.0Ux to 9.0.
So you see my problem this problem was present at the first start of the new shelf with IBS, but was solved. No change was made in configuration or positioning of the base stations, and now the problem is here again after upgrade.
-
shaanvis15
Re: DECT user changing between IBS and RBS
Hello Inovakom,
have you get an explanation or solution for this
have you get an explanation or solution for this
Re: DECT user changing between IBS and RBS
What's your PARI 0 and PARI IBS and what's your PLI value?
