gsm-net-reveng: tmo/CSD-tests comparison

comparison tmo/CSD-tests @ 71:ed314cc25b8d

tmo/CSD-tests: additional experiments and historical notes

author	Mychaela Falconia <falcon@freecalypso.org>
date	Tue, 26 Nov 2024 20:56:33 +0000
parents	47947e25f922
children	afebef67e8d4

comparison

equal deleted inserted replaced

-:47947e25f922
+:ed314cc25b8d
 A series of experiments seeking to test CSD on the extant network of T-Mobile
 USA, to be performed while this network is still alive.  The main objective is
 to test CSD calls between a single MS and analog (or PCMU-speaking) PSTN, rather
 than mobile to mobile.
+All experiments detailed in the following sections were performed in 2024-11
+at the Mother's home base.
 Test setup
 ==========
 The test MS is an FCDEV3B with a legacy T-Mobile SIM.  The AT command session
 * NT mode was only tested with AT+CBST=7,0,1 default, i.e., 9600 baud and asking
 the IWF for V.32 modem.  As revealed by L1 and CC traces, the network does
 everything it should - but the MS returns NO CARRIER.  However, further
 analysis of CC traces reveals that the DISCONNECT at CC level is initiated by
 the MS and not by the network!  My current working hypothesis is that the MS
-is unhappy about something it sees at RLP level.
+is unhappy about something it sees at RLP level.  [See further updates in
+Experiment 6.]
 Additional observations:
 * The MS issues a single SETUP message with BC indicating ITC of 3.1 kHz and the
 selected CSD mode.  The network responds with CALL PROCEEDING, ALERTING and
 and data calls dialed from the other TMO subscriber line.  It appears that all
 MO CSD calls were treated by the network in "convert to modem emulation" mode
 despite the dialed number being another T-Mobile line; the MT leg always
 received incoming voice calls.
-It thus appears that a change has happened in TMO's network in this regard.
+Experiment 5
-Many years ago, before I learned about T vs NT distinction and other critical
+============
-CSD parameters set with AT+CBST, when I would blindly dial ATDnumber, I was
-sometimes able to make a data call from a proper FreeCalypso test MS to a
+In this experiment I sought to capture TCH DL bits from the DSP in CSD modes in
-Pirelli phone running its official fw: the destination phone would ring and
+the same way how we do it in non-AMR speech modes.  I added what seemed like
-display an incoming call screen, but it said "data call".  For this feat to
+the necessary support in FC Tourmaline fw (Hg commit 304:58c7961bd0b0) and in
-have happened, there must have been a BC IE in the MT SETUP message when the
+fc-shell TCH handling code (freecalypso-tools Hg commit 1014:961efadd530a), and
-MO leg made a data call - hence the change between past and present bahaviour.
+made captures of CSD call sessions with +CBST set to (7,0,0), (6,0,0) and
+(2,0,0).  However, as soon as I looked at the captured recordings, I was
+immediately disappointed: while the beginning of each capture shows what look
+like DL bits constituting idle frames (mostly all 1s, except where disturbed by
+FACCH stealing), as soon as the IDS block kicks in, we read nothing but all 0s.
+Is the IDS part of DSP ROM code overwriting the buffer with zeros after it groks
+those bits?
+Also in this experiment session I tried setting AT+CBST=14,0,0 to see if TMO
+supports TCH/F14.4.  The network responded to SETUP with CALL PROCEEDING, but
+whereas in other modes channel assignment happens almost immediately afterward,
+here it stayed on SDCCH for several seconds, and then the network sent CC
+DISCONNECT message with cause 34.  This cause value means "No circuit/channel
+available" - so it looks like TMO's unloved GSM network does not support
+TCH/F14.4.
+Experiment 6
+============
+As I was writing up notes regarding what seemed like non-working state of NT
+mode while all Transparent modes up to 9600 bps work great, I decided to test
+with an older version of FC firmware, namely Magnetite l1reconst.  In the
+earlier years of FreeCalypso, I would frequently make CSD calls just for fun,
+calling NIST ACTS, and it would always work - and being ignorant of T vs NT
+and other mode settings, I never set AT+CBST and just dialed ATDnumber.  Since
+we now know that TI's firmware default is AT+CBST=7,0,1 and has always been
+this way, we know that I was unknowingly exercising NT mode in those happy
+years - hence I decided to try an older fw version from those years just to see
+if it would have working NT mode.  Tested - it worked!
+But then things got more interesting.  I tested with Magnetite hybrid instead
+of l1reconst - using the new source-enabled version of G23M PS.  Result: it
+seemed a little flaky, but it worked.  Then I went back to current Tourmaline
+fw, the same with which I started in Experiment 1.  Did a call with
+AT+CBST=7,0,0 serving as a control - it worked.  Tried AT+CBST=7,0,1 - got a
+NO CARRIER response; subsequent log analysis shows that the MS initiated CC
+DISCONNECT just like in Experiment 1.  Then I made another attempt, still with
+AT+CBST=7,0,1 - and this time it worked beautifully: I got CONNECT followed by
+the full 40 s of ACTS output.
+Thus we now know that NT mode working or not is not a question of firmware
+version, but some kind of law of chance: time of day, space weather, phase of
+the moon...
+NT mode: need for further debugging
+===================================
+The flaky nature of NT mode calls for further debugging: since we see
+MS-initiated DISCONNECT on those tries when it fails, we really need to know
+exactly what is making the MS unhappy.  But this debugging is made difficult by
+the misfeature of TI's DSP: in Experiment 5 I tried capturing TCH DL bits, but
+all we get is zero fill once the IDS block is active.  As next steps, we will
+need to study the code that interfaces with this IDS block, and see what we can
+observe at that interface level.
+T vs NT mode: utility vs complexity
+===================================
+Consider the IWF provided by the network, speaking CSD frame formats toward GSM
+RAN and emulating analog modem signals toward 64 kbit/s PSTN, and consider the
+work it has to do in T vs NT modes.  It should be evident that NT mode is much
+more complex: all of the work implementing V-series modulations is still needed
+for both T and NT, but whereas T mode provides a direct path between the
+emulated-modem "bit pump" and CSD V.110 frame bits, in NT mode the IWF has to
+implement RLP on the GSM side, V.42 on the analog modem side, and make a high-
+level data connection between these two engines of reliable transmission based
+on acks, retries etc.  Hence the "bug surface", the number of things that can
+go wrong, is much greater for IWF in NT mode.
+OTOH, utility considerations traditionally called for NT mode.  There are
+*some* applications for which non-buffering, fixed-delay Transparent mode is
+the right choice: precision time distribution as in NIST ACTS, train engine
+communication in GSM-R etc - but such applications are more on the boutique
+side.  Instead consider the more typical application of a business user dialing
+into his/her mainframe or UNIX minicomputer etc account while on the go: here
+you have a user with a text terminal, and a server/service somewhere that prints
+text for the user to read and expects text commands.  In this case the user
+would certainly appreciate if his/her session is *not* disturbed by dropouts or
+garbage insertions from radio errors, from handover events or from line noise
+on the PSTN leg - such users would certainly benefit from NT mode.  Outside of
+railways or other special environments, considering ordinary public GSM networks
+intended for consumers and business users, in the days when CSD was a feature
+of real user significance, NT mode was likely the more desired one for reasons
+just explained.  Yet it is the one which is much more onerous to implement...
+Lack of data-call indication from one T-Mobile MS to another
+============================================================
+Looking at the specs for GSM CSD, the intent of the original Creators seems
+clear: they intended CSD to run between an MS and services on the fixed network,
+perhaps going through an IWF.  In contrast, the case of mobile-to-mobile CSD
+calls was NOT the canonical configuration - it was probably considered, but only
+as a rather contrived and unlikely use case.  But if someone does make a CSD
+call addressed to another mobile, how should it work?
+In order for a CSD call to be directly through-connected from Alice to Bob,
+Osmocom-style, without complex conversions and translations in the middle, two
+conditions would have to be met:
+1) The connection element setting would have to be Transparent;
+2) ISDN/UDI mode would need to be selected, rather than 3.1 kHz modem emulation.
+In this case the MO call will be turned into V.110 by the TRAU, no further IWF
+would be applied at the MSC, the ISDN call would connect from Alice to Bob, the
+destination MSC serving Bob would see that it's a data call, and it would
+indicate so to Bob's MS.  So far, so good.  But the moment you add NT mode or
+analog modem emulation, the above pass-through model breaks down:
+1) If the bearer cap IE on the MO call indicates ITC of 3.1 kHz audio instead
+of UDI, Alice's MSC is supposed to pass the call through an IWF that does
+modem emulation.  Once that modem emulation is applied, the call going out
+on ISDN is in 3.1 kHz audio mode, not digital data!
+2) NT mode does not seem to have ever been intended to carry from mobile user
+Alice to mobile user Bob - instead it appears to have been intended to run
+between a single MS and a network IWF only.  The IWF then converts to V.42
+in the case of 3.1 kHz modem emulation, or to V.1xx/X.75/etc protocols in
+the case of ISDN UDI, with or without V.42-like reliability through acks and
+retransmissions.
+However, the above considerations stem from the architectural model _assumed_
+in ETSI GSM specs - whereas the question of what real-world GSM networks have
+actually implemented needs to be asked separately.  In the case of T-Mobile USA,
+the behavior of the network upon own-subscriber Alice making a CSD call to own-
+subscriber Bob appears to have changed over the years:
+* In my earlier years of FreeCalypso work, when I made CSD calls from FC GSM MS
+just for fun while being ignorant of T vs NT modes and other +CBST settings,
+I would call NIST ACTS to get a truly successful session.  But I also
+experimented a little with mobile-to-mobile CSD.  Unfortunately, I never put
+together a proper setup with two FC GSM MS boards powered up and connected to
+my laptop at the same time, fitted with two active T-Mobile SIMs, one calling
+the other - but I did dial CSD a few times from a single "proper" GSM MS
+(probably FCDEV3B, although I don't remember exactly) to my main personal-use
+T-Mobile line whose SIM sat in a Pirelli DP-L10 running its official fw.
+I don't remember if I got this degree of success reliably every time or if it
+was intermittent - but I did get an incoming call indication on the Pirelli
+that said "incoming data" or something to that effect.  I don't remember
+exactly what happened afterward, but my vague recollection (subject to the
+caveats about wetware memory after many years of attention being shifted in
+very different directions) is that the phone would ring with this "incoming
+data" indication on the screen, but once I pressed the Answer button, the
+call attempt would drop - and curiously enough, turn into a "missed call"
+indication.  I don't have good memory of what the call-originating FC GSM MS
+would show: I seem to recall it going directly to NO CARRIER upon me pressing
+Answer on the Pirelli, but I also seem to recall at least once getting a
+CONNECT response, presumably followed by NO CARRIER shortly afterward.
+* In terms of memory reliability, the only part I do remember for certain is
+that the call-receiving Pirelli phone (running its official fw) _did_ display
+a "ringing" screen that said something along the lines of "incoming data" -
+IOW, it very clearly indicated the presence of an incoming call that was data
+rather than voice, even though of course this phone has no official Terminal
+Adaptor Function and no ability to meaningfully accept such calls.  This
+indication implies that the MT SETUP message from the network must have
+included a bearer cap IE that indicated non-speech - although unfortunately
+I have no logs (back then I wasn't looking at CC or any other air interface
+messages), thus we don't know if it was a pass-through of BC from the MO leg
+or altered in some way.  The remaining memories of everything else that
+happened after this logically-deduced MT SETUP should be treated as
+unreliable.
+* When I tried replicating in the present time (2024-11) the just-described
+result from many years ago, I had no success: see description of Experiment 4
+above.  Now when I dial a CSD call from one of my legacy T-Mobile SIMs to
+another, the receiving MS gets an MT SETUP message that contains no BC IE at
+all, same as with calls coming from outside PSTN, the call rings as voice,
+and gets assigned TCH/AHS like other speech calls.  And because the modem-
+emulating CSD IWF in the MO direction initially emits silence while waiting
+for the answering modem, silence is what the receiving phone hears in this
+errant setup.

FreeCalypso > hg > gsm-net-reveng

comparison tmo/CSD-tests @ 71:ed314cc25b8d