FreeCalypso > hg > gsm-net-reveng

comparison tmo/CSD-tests @ 70:47947e25f922

Find changesets by keywords (author, files, the commit message), revision number or hash, or revset expression.
tmo/CSD-tests: document experimental findings
author Mychaela Falconia <falcon@freecalypso.org>
date Mon, 25 Nov 2024 07:22:43 +0000
parents
children ed314cc25b8d
comparison
equal deleted inserted replaced
69:cf60172895fe 70:47947e25f922
1 A series of experiments seeking to test CSD on the extant network of T-Mobile
2 USA, to be performed while this network is still alive. The main objective is
3 to test CSD calls between a single MS and analog (or PCMU-speaking) PSTN, rather
4 than mobile to mobile.
5
6 Test setup
7 ==========
8
9 The test MS is an FCDEV3B with a legacy T-Mobile SIM. The AT command session
10 will be driven through the dedicated UART, not the usual fc-shell, to enable
11 full use of data functions. Rvinterf will still be used to capture logs; the
12 following command needs to be issued in order to make the firmware emit traces
13 indicating AT command activity:
14
15 sp MMI TRACECLASS 800050
16
17 Issue these two additional commands to trace the MMCM SAP between CC and MM
18 entities of the protocol stack:
19
20 sp MM DUPLICATE CC PCO
21 sp CC DUPLICATE MM PCO
22
23 The objective is to capture all CC protocol messages sent to and received from
24 the network; tracing the exchange between CC and MM seems like the easiest way
25 to accomplish this goal within our existing firmware architecture.
26
27 Experiment 1
28 ============
29
30 In this experiment several MO CSD calls were made from the test MS to
31 +13034944774, the number for USA taxpayer-funded NIST ACTS. Several modes were
32 tested:
33
34 AT+CBST=7,0,1 -- TI GSM MS firmware default
35 AT+CBST=7,0,0
36 AT+CBST=6,0,0
37 AT+CBST=4,0,0
38 AT+CBST=2,0,0
39
40 Results were surprising:
41
42 * Transparent mode works beautifully at 9600 baud, as well as 4800 and 1200
43 baud. Therefore, the previous hypothesis that CSD at 9600 baud no longer
44 works as a result of GSM quality degradation or as a result of IP-fication of
45 internal transports within USA PSTN is now disproven.
46
47 * Transparent mode at 2400 baud produced a different result: successful CONNECT
48 followed by garbage and earlier disconnect, instead of 40 s of good ACTS
49 output in other baud modes. Perhaps a defect in V.22bis implementation in
50 the network IWF?
51
52 * All 3 data TCH modes were observed in L1 traces: TCH/F9.6, TCH/F4.8 and
53 TCH/F2.4, and each of these produced a perfectly good data call in at least
54 one mode.
55
56 * NT mode was only tested with AT+CBST=7,0,1 default, i.e., 9600 baud and asking
57 the IWF for V.32 modem. As revealed by L1 and CC traces, the network does
58 everything it should - but the MS returns NO CARRIER. However, further
59 analysis of CC traces reveals that the DISCONNECT at CC level is initiated by
60 the MS and not by the network! My current working hypothesis is that the MS
61 is unhappy about something it sees at RLP level.
62
63 Additional observations:
64
65 * The MS issues a single SETUP message with BC indicating ITC of 3.1 kHz and the
66 selected CSD mode. The network responds with CALL PROCEEDING, ALERTING and
67 CONNECT in the same cadence as it would for a MO voice call. The timing of
68 ALERTING message is consistent with my expectation of when PSTN plays the
69 ringing tone, and the timing of CC CONNECT message is consistent with my
70 expectation of when Answer Supervision occurs at PSTN level. The CC CONNECT
71 step is reached in all tested modes, including the failing NT mode.
72
73 * The AT-command CONNECT response happens significantly later than CC CONNECT
74 message. My current working hypothesis is that the network generates CC
75 CONNECT when it gets Answer Supervision from PSTN just like it does for voice
76 calls, well before modem connection sequence can happen. Perhaps the status
77 of modem connection is then indicated via V.110 in-band flags, and perhaps
78 the MS is using that in-band status to decide when to declare CONNECT.
79
80 * At the end of each call there was a network-initiated DISCONNECT with cause
81 value 127 (interworking, unspecified) - but in this experiment there is
82 insufficient information to tell if this action is initiated by the IWF upon
83 loss of modem signal, or if it is merely passing along PSTN-level disconnect
84 signaling from the called party. See Experiment 2.
85
86 Experiment 2
87 ============
88
89 In this experiment several MO CSD call attempts were dialed from the test MS to
90 Mother Mychaela's personal voice number on ThemWi; the latter is interconnected
91 with USA PSTN via BulkVS. The objectives were: (1) to confirm the hypothesis
92 about Answer Supervision on PSTN side being the criterion for signaling CC
93 CONNECT to the MS, and (2) to hear what, if anything, the IWF transmits toward
94 PSTN while waiting for modem connection.
95
96 Results:
97
98 * When I answered the call on the destination phone, I heard silence each time.
99 The calling party received CC CONNECT signaling when I made that answer.
100
101 * In both tests where +CBST was set to 7,0,0 and I answered the call, the
102 network (TMO) eventually ended the call, signaling cause 127 to the calling
103 MS like in Experiment 1. (Thus we now know that it is the IWF taking this
104 action, and not the called party hanging up at PSTN level.) In one of these
105 two tests, there was a miraculous CONNECT response from the AT interpreter,
106 some time well after Answer Supervision, but before the IWF-initiated
107 disconnect. In the second test, there was no CONNECT response, only
108 NO CARRIER at the time of IWF-initiated disconnect.
109
110 * In the test case where I didn't answer the destination phone (let the ringing
111 time out), the calling MS received CC DISCONNECT message with cause 17 (user
112 busy), as that is how PSTN middleboxes misinterpret SIP 480 error I return
113 from ThemWi. The AT command interface generated BUSY response.
114
115 * In the final test case in this experiment series, I made the test call with
116 +CBST=7,0,1 and answered the destination phone. The MS initiated DISCONNECT
117 4 s after receiving CC CONNECT, just like it did when calling NIST ACTS.
118
119 Experiment 3
120 ============
121
122 This experiment sought to observe how TMO GSM network handles MT calls from PSTN
123 to a mobile subscriber, including the possiblity of MT CSD calls via AT+CSNS.
124 An MT call was repeatedly dialed from Mother Mychaela's ThemWi phone to the test
125 MS on TMO, with different AT+CSNS and AT+CBST settings established before each
126 call attempt; logs were collected for subsequent analysis.
127
128 Observations:
129
130 * The initial SETUP message from the network to the MS contains _no_ bearer
131 capability IE; the CALL CONFIRM response from the MS does include BC IE,
132 filled with different content depending on AT+CSNS and AT+CBST settings.
133
134 * The network seems to always accept the BC supplied by the MS in that response,
135 and assigns appropriate TCH type and mode.
136
137 * The PSTN caller hears the standard North American ringing tone while the MS
138 emits RING messages on its AT command channel, subsequent to the MS sending
139 CC ALERTING message to the network.
140
141 * When I answer the call with ATA, the MS sends CC CONNECT to the network, the
142 PSTN caller gets Answer Supervision, and I hear modem answer tones from TMO's
143 IWF.
144
145 * Only Transparent modes have been tested so far; the modem answer sequence
146 heard by the PSTN caller depends on the specific modem emulation selected
147 with AT+CBST. With AT+CBST=2,0,0 and AT+CBST=4,0,0 I heard a continuous (no
148 phase reversals) V.25 ANS tone followed by a higher-pitched tone (presumably
149 Unscramled Binary 1s signal of V.22), followed by disconnection; with
150 AT+CBST=6,0,0 and AT+CBST=7,0,0 I heard a V.25 ANS tone *with* phase
151 reversals, directly followed by disconnection (no AC tones).
152
153 Further tests were aborted (I didn't get to testing NT mode) because the network
154 did something that caused the MS firmware (or perhaps the SIM) to go into a
155 funky state; to be investigated as its own separate problem.
156
157 Experiment 4
158 ============
159
160 In this experiment I used two of my legacy T-Mobile SIMs simulateneously: one
161 in the FCDEV3B as in the preceding experiments, the other in a Pirelli DP-L10
162 phone. The Pirelli phone ran RAM-based FC Tourmaline firmware during these
163 tests. Test calls were dialed from the FCDEV3B to the Pirelli; the fw build
164 running on the latter has CSD excluded, but the objective was to see the MT
165 SETUP message as it arrives from the network, before destination MS firmware
166 does anything with it.
167
168 Observation: _no_ BC IE was ever seen in the MT SETUP message, for both voice
169 and data calls dialed from the other TMO subscriber line. It appears that all
170 MO CSD calls were treated by the network in "convert to modem emulation" mode
171 despite the dialed number being another T-Mobile line; the MT leg always
172 received incoming voice calls.
173
174 It thus appears that a change has happened in TMO's network in this regard.
175 Many years ago, before I learned about T vs NT distinction and other critical
176 CSD parameters set with AT+CBST, when I would blindly dial ATDnumber, I was
177 sometimes able to make a data call from a proper FreeCalypso test MS to a
178 Pirelli phone running its official fw: the destination phone would ring and
179 display an incoming call screen, but it said "data call". For this feat to
180 have happened, there must have been a BC IE in the MT SETUP message when the
181 MO leg made a data call - hence the change between past and present bahaviour.