Ats Levels And Failure Reporting Times

[IPAlarms]

I always understood that the biggest issue with gprs is using it infrequently, ie at g2 and g3. But if using it all the time there isn't an issue.

GPRS = IP over GSM. It does not matter how much it used, it is either available or it is not.

Are you saying that if you slow down the polling you are less Lilly to have gprs failures, or do you leave the active poll times alone and just extend the 'poll lost' timer?

I'm more a fan of "heartbeats", which are sent out from the client device, as opposed to "polls" which are handled by the server. Heartbeats "spread the load" if you like and do not put any undue pressure on the server.

So, my suggestion is to have the client devices send heartbeats at the maximum rate possible allowed by the GPRS plan. The key setting is at the server end, where each device should have its own "poll lost timer" as you refer to it. The "poll lost timer" should be adjustable on a client by client basis so that it can be "tuned" to the performance of the client network. I'm not sure if this is how you have things setup already, or if every device must have the same "poll lost timer" according to the grade of the system.

When IP/GPRS first appeared, we all got excited about how quickly we could be alerted if the connection was "attacked". Nobody really expected the networks to be so **** that we would end up with a situation like: "Oh ignore it - it's just another network failure"

[james.wilson]

GPRS = IP over GSM. It does not matter how much it used, it is either available or it is not.

I'm more a fan of "heartbeats", which are sent out from the client device, as opposed to "polls" which are handled by the server. Heartbeats "spread the load" if you like and do not put any undue pressure on the server.

So, my suggestion is to have the client devices send heartbeats at the maximum rate possible allowed by the GPRS plan. The key setting is at the server end, where each device should have its own "poll lost timer" as you refer to it. The "poll lost timer" should be adjustable on a client by client basis so that it can be "tuned" to the performance of the client network. I'm not sure if this is how you have things setup already, or if every device must have the same "poll lost timer" according to the grade of the system.

When IP/GPRS first appeared, we all got excited about how quickly we could be alerted if the connection was "attacked". Nobody really expected the networks to be so **** that we would end up with a situation like: "Oh ignore it - it's just another network failure"

i dont think that available, ie in signal and registered means that data will actually be recieved.

I see this regulally with my own mobile where i have a gprs or hsdpa connection, i have signal and the phone is regestered. But all i see is the data out arrow going on the phone no data recieved. Then a few minutes later it springs into life.

To me the only way you can be 100% the gprs side is 'available' is to actually transmit something, handshake etc and ensure the packet was received.

if your just checking registration and signal then thats like checking there is 50v and dialtone on a pstn line. Should work but many reasons why it may not.

I can see your argument with spreading the load between various servers but i suppose that depends on how your system is setup. Does it all report to a central cluster which then reports to the arc, or does it report direct to the arc. Each have their merits and neither is wrong as such imo.

AFAIK polling is fixed dependant upon if its the primary or an additional backup path and what ATS level its at. It can be more often than the reg states but needs to detect & report failures within the mandatory timelines.

[Guest Oxo]

Am I missing something here?

If I block the GSM with my jammer at the same time my dodgy mate cuts the phone line - are you telling me the ARC is notified instantly ?

Yes, the polling is stopped.

Had this issue with a certian top bod in BT when visiting the server centre.

I showed them how to cut into and bypass the polling.

But, average mong does not know this.

Your instance isnt correct.

[james.wilson]

if using a gsm jammer and a pair of cutter then to 50136 as worse case for dual path devices

g2 - 24 hours

g3 - 5 hours

g4 - 3 minutes

Can be quicker than 3 mins and some are but i think 3 mins in fine. If you want instant then some units can achieve it

but in the above example shows that anything less than g4 signalling is very weak when both paths fail

very weak is a large understatement

but also its not just gsm jammers, attacking the panel, the aerial etc would all provide the same result

[Guest Oxo]

Absoultley agree.

Signalling is not monitered enough.

And we charge people for this.........................

Time things were improved. For us and our clients.

[james.wilson]

ox

a lot 'used' to charge but thought the lower grades were better and cheaper.

Only now some are realising this may have been a mistake.

if you think that G2 dualpath is a huge amount cheaper you can see why some did.

Glad we didnt but due to the large number of my competition that do i need to be more competitive on these installs. I cant (or the customer cant afford/wont pay/doesnt care (delete as applicable) to carry on with G4 signalling so i need a viable alternative. There is a new catagory that some are already meeting that gives close to G4 service levels for a more competitive amount.

Im exploring this currently

[Guest Oxo]

I know you are and look forward to the possible progress.

You and myself agree things are not 100%.

Not a lot more to say really.

[IPAlarms]

This brings us to the point I am trying to make - everything depends on the availability of the network(s). For example, we have grade 2 products where you control how quickly you are notified of path failures, but there is one big drawback - the reliability of the IP & GPRS networks in the UK.

If the installer and ARC were to agree on 90 seconds "poll lost timer", then based on what I've heard about the quality of networks, you'd have nothing but problems. If you agreed on 5 minutes, then you may be OK with a good percentage of your systems and the ones that fail could have the "poll lost timer" increased. If you agreed on 15 minutes, then maybe you would be getting close to having a workable solution for all concerned.

Again, this is of no use to you guys as we are not active in the UK market, but if you could convince your favourite manufacturer to modify their solution to help you compete, then that would be good.

[james.wilson]

i think we have asome stuff like that already lol (aaron you know what i mean)

my issue is if the poll is going missing at 90 or 180 second intervals then what if an intruder signal goes missing?

what sort of availability do you think this thing would have in the uk? ie gprs availability not product