HELP: anyone out there know how v.32 GSM data calls work please?

Thread view:

Enable EMail Alerts

Start New Thread

Thread rating:

don madden - 19 Jul 2004 12:49 GMT

Hi,

I'm trying to setup a transparent V.32 GSM data connection between 2
PCs each equipped with a GSM terminal adaptor. Unfortunatley we are
seeing erratic behaviour such as the insertion of garbage data and
early connects. This problem isn't related to the terminal adaptor at
the PC as the same erratic behaviour happens with many different
terminal adaptors. To get a handle on what's happening at a call
control level from the MSC/IWF to Terminal Adaptor at the PC, i've
been wading through lots of GSM documentation.

I understand as far as both sides are connected and an end-end virtual
circuit has been established as per GSM.4.08 (i.e.
set-up/alert/connect/connect-ack at the originating side and
setup/call-conf/connect/connect-ack at the terminating side). This is
simillar to the call control signalling as in a GSM voice call. Once
the call signalistion phase for setting up the physical end-end
circuit is complete and the modems in the IWF can now start training.

Where I'm confused is on completion of V.32 training by the 2 modems,
how does each V.32 modem notify the terminal adaptor that training is
complete and thereby connected? Any information please or some
pointers to the relevalent documentation would be really appreciated.

Thanks a million,
Don

Reply to this Message

Clueless2 - 19 Jul 2004 19:01 GMT

> Where I'm confused is on completion of V.32 training by the 2 modems,
> how does each V.32 modem notify the terminal adaptor that training is
> complete and thereby connected? Any information please or some
> pointers to the relevalent documentation would be really appreciated.

Surely there is not training required as the modem (terminal side) are
digital? The transparent data are rate-adapted into modified V110 frames
before being set over the air and to the IWF. Sure the IWF to IWF will have
to negotiate a rate, but if you are smart you can by pass this by specifying
an "ISDN call" (cannot remember AT+ something) so that the whole
transmission stays in the digital domain!

When using transparent data the start and stop bits are transmitted as well
(hence wasting bandwidth), are you sure you want to do this? If so, have you
set-up your terminal to the correct bit rate and the start and stop bits?

Reply to this Message

don madden - 20 Jul 2004 10:18 GMT

> > Where I'm confused is on completion of V.32 training by the 2 modems,
> > how does each V.32 modem notify the terminal adaptor that training is
[quoted text clipped - 11 lines]
> (hence wasting bandwidth), are you sure you want to do this? If so, have you
> set-up your terminal to the correct bit rate and the start and stop bits?

Yes thanks for the suggestion of using V.110 and non-transparent data
instead of transparent data.
Your are correct that V.110 (AT+CBST=71,0,0) would require no training
except rate negotiation and staying in the digital domain. For these
reasons it is far simpler. Unfortunately in my case, it must also
interoperate with PSTN V.32 modems. As a result, I need a GSM V.32
data connection (AT+CBST=7,0,0) at the GSM data side.
Regarding non-transparent data versus transparent data, you are
correct that it is far simpler to use transparent data which has RLP.
Unfortunatley my application cannot tolerate the delays associated
with non-transparent data and hence the need for a transparent data
service.

Again as i'm really struggling with this one :(, any help from anyone
out there with some knowledge on how transparent GSM v.32 data
connections work would be really appreciated.

Thanks a million
Don

Reply to this Message

Matt - 21 Jul 2004 13:29 GMT

Do you have to use V.32? We started using it because of the quick connection
but then stopped as the error rate can be so high.
It can be made to work but you will need to write your own packet handling
and error correction code, which is all done for you using the stadard GSM
data.

> Hi,
>
[quoted text clipped - 22 lines]
> Thanks a million,
> Don

Reply to this Message