binary sms with nib.js (YateBts, BladeRF)

[gvlachos]

Using YatesBts, BladeRF and nib.js (https://github.com/ctxis/yate-bts/blob/master/nib/nib.js)

I changed mtLocalDelivery (https://github.com/ctxis/yate-bts/blob/master/nib/nib.js#L756), so that all fields the same the same except the following where I set:

• m.text to 'hello', for a text sms, m.dispatch succeeds and the message is delivered
• m.rpdu to '0x41544341542b43474d49' (hex string), m.text is not set (for a binary sms), m.dispatch fails
• m.rpdu to 0x41544341542b43474d49 (hex number), m.text is not set (for a binary sms), m.dispatch fails

also I ran 'yate -vvvvv -l /var/log/yate.log' and in the log (for the 2nd and 3rd tries above) I get the following:

Code: [Select]

2017-05-23_08:00:32.687154 <ybts-signalling:ALL> Connection 3 sapi establish 3 state 0x09 [0x14592d0]
2017-05-23_08:00:32.687177 <ybts-signalling:WARN> Encoding of mandatory parameter RPDU finished with status=MissingMandatoryIE [0x14592d0]
2017-05-23_08:00:32.687182 <ybts-signalling:WARN> Encoding of mandatory parameter Message finished with status=MissingMandatoryIE [0x14592d0]
2017-05-23_08:00:32.687186 <ybts-signalling:WARN> Encoding of mandatory parameter PD finished with status=MissingMandatoryIE [0x14592d0]
2017-05-23_08:00:32.687191 <ybts-signalling:NOTE> Failed to build L3Message (0): Codec error 7 (MissingMandatoryIE) [0x14592d0]
2017-05-23_08:00:32.692124 <ybts:INFO> MT SMS 'ybts/sms/1' to (0x7fbb98007f70) TMSI=007b0001 IMSI=234101713996691 failed reason='' RPDU=
2017-05-23_08:00:32.692273 <nib:INFO> Could not deliver sms from imsi nib_smsc to number 3996691.

what is the correct way ?

--
George

[marian]

You must not add the '0x' prefix to hex strings

[gvlachos]

ok I tried setting m.rpdu to '41544341542b43474d49' however m.dispatch() return false, the log is:

Code: [Select]

2017-05-23_09:10:21.073131 <ybts-mm:ALL> Added UE (0x7fa98c002740) TMSI=007b0001 IMSI=234101713996691 [0x107b360]
2017-05-23_09:10:21.073143 <ybts:INFO> MT SMS 'ybts/sms/1' to (0x7fa98c002740) TMSI=007b0001 IMSI=234101713996691
2017-05-23_09:10:21.073164 <ybts-signalling:INFO> Sending [0x107af80]
-----
Primitive: StartPaging
Info: 1

<StartPaging>
  <identity>TMSI007b0001</identity>
  <imsi>234101713996691</imsi>
</StartPaging>
-----
2017-05-23_09:10:21.073177 <ybts:ALL> Started paging TMSI007b0001
2017-05-23_09:10:21.461247 <gsmtrx:INFO> ARFCN[0]: Slot 0. Receiver clipping 1.90356 dB (FN=36846) count=5 [0x7fa98800fc50]
2017-05-23_09:10:21.461538 <gsmtrx:ALL> Handling command 'CMD 0 NOHANDOVER 0' arfcn=0 [0x7fa988008da0]
2017-05-23_09:10:21.461558 <gsmtrx:ALL> Command 'CMD 0 NOHANDOVER 0' (ARFCN=0) RSP '0'
2017-05-23_09:10:21.461625 <gsmtrx:ALL> Handling command 'CMD 0 NOHANDOVER 0' arfcn=0 [0x7fa988008da0]
2017-05-23_09:10:21.461634 <gsmtrx:ALL> Command 'CMD 0 NOHANDOVER 0' (ARFCN=0) RSP '0'
2017-05-23_09:10:21.770979 <ybts-signalling:INFO> Received [0x107af80]
-----
Primitive: PhysicalInfo
Info: 0
Connection: 3

<PhysicalInfo>TA=0 TE=2.000 UpRSSI=1 TxPwr=33 DnRSSIdBm=-84 time=1495530621.474</PhysicalInfo>
-----
2017-05-23_09:10:21.771048 <ybts-signalling:INFO> Received [0x107af80]
-----
Primitive: L3Message
Info: 0
Connection: 3

<RRM>
  <SkipIndicator>0</SkipIndicator>
  <Message type="PagingResponse">
    <CipheringKeySequenceNumber>no-key/reserved</CipheringKeySequenceNumber>
    <MobileStationClassmark2>
      <RFPowerCapability>class4</RFPowerCapability>
      <RevisionLevel>GSM-phase2</RevisionLevel>
      <SSScreeningIndicator>ellipsis-notation-and-phase2-error-handling</SSScreeningIndicator>
      <Flags>ES-IND,E-GSM-and-R-GSM-support,MT-sms-point-to-point-capability,pseudo-sync-capability,A5/3-support,CMSP-support,LCS-VA-support,CM3-support</Flags>
    </MobileStationClassmark2>
    <MobileIdentity>
      <TMSI>007b0001</TMSI>
    </MobileIdentity>
  </Message>
</RRM>
-----
2017-05-23_09:10:21.771061 <ybts-signalling:ALL> Added connection (0x7fa9940023b0,3) [0x107af80]
2017-05-23_09:10:21.771067 <ybts-mm:ALL> PagingResponse with TMSI=007b0001 conn=3 [0x107b360]
2017-05-23_09:10:21.771079 <ybts-signalling:INFO> Sending [0x107af80]
-----
Primitive: StopPaging
Info: 0

<StopPaging>
  <identity>TMSI007b0001</identity>
</StopPaging>
-----
2017-05-23_09:10:21.771088 <ybts:ALL> Stopped paging TMSI007b0001
2017-05-23_09:10:21.771093 <ybts-signalling:ALL> Connection 3 set UE (0x7fa98c002740) TMSI=007b0001 IMSI=234101713996691 [0x7fa9940023b0]
2017-05-23_09:10:21.771100 <ybts-signalling:INFO> Sending [0x107af80]
-----
Primitive: EstablishSAPI
Info: 3
Connection: 3
-----
2017-05-23_09:10:22.006355 <ybts-signalling:INFO> Received [0x107af80]
-----
Primitive: PhysicalInfo
Info: 0
Connection: 3

<PhysicalInfo>TA=0 TE=2.000 UpRSSI=1 TxPwr=33 DnRSSIdBm=-84 time=1495530621.474</PhysicalInfo>
-----
2017-05-23_09:10:22.467595 <gsmtrx:INFO> ARFCN[0]: Slot 0. Receiver clipping 1.71572 dB (FN=37064) count=18 [0x7fa98800fc50]
2017-05-23_09:10:22.492632 <ybts-signalling:INFO> Received [0x107af80]
-----
Primitive: EstablishSAPI
Info: 3
Connection: 3
-----
2017-05-23_09:10:22.492656 <ybts-signalling:ALL> Connection 3 sapi establish 3 state 0x09 [0x107af80]
2017-05-23_09:10:22.492687 <ybts-signalling:INFO> Sending [0x107af80]
-----
Primitive: L3Message
Info: 3
Connection: 3

<SMS>
  <TID TIFlag="false">0</TID>
  <Message type="CP-Data">
    <RPDU>41544341542b43474d49</RPDU>
  </Message>
</SMS>
-----
2017-05-23_09:10:22.492707 <ybts:ALL> MT SMS 'ybts/sms/1' to (0x7fa98c002740) TMSI=007b0001 IMSI=234101713996691 sent on conn 3
2017-05-23_09:10:22.958063 <ybts-signalling:INFO> Received [0x107af80]
-----
Primitive: PhysicalInfo
Info: 0
Connection: 3

<PhysicalInfo>TA=2 TE=0.000 UpRSSI=1 TxPwr=33 DnRSSIdBm=-84 time=1495530622.463</PhysicalInfo>
-----
2017-05-23_09:10:22.958112 <ybts-signalling:INFO> Received [0x107af80]
-----
Primitive: L3Message
Info: 3
Connection: 3

<SMS>
  <TID TIFlag="true">0</TID>
  <Message type="CP-Ack"/>
</SMS>
-----
2017-05-23_09:10:22.958142 <ybts:ALL> SMS CP-ACK conn=3 callRef=0 tiFlag=true
2017-05-23_09:10:23.200404 <ybts-signalling:INFO> Received [0x107af80]
-----
Primitive: PhysicalInfo
Info: 0
Connection: 3

<PhysicalInfo>TA=2 TE=0.000 UpRSSI=1 TxPwr=27 DnRSSIdBm=-84 time=1495530622.463</PhysicalInfo>
-----
2017-05-23_09:10:23.200457 <ybts-signalling:INFO> Received [0x107af80]
-----
Primitive: L3Message
Info: 3
Connection: 3

<SMS>
  <TID TIFlag="true">0</TID>
  <Message type="CP-Data">
    <RPDU enc="hex">04540160</RPDU>
  </Message>
</SMS>
-----
2017-05-23_09:10:23.200477 <ybts:ALL> MT SMS 'ybts/sms/1' to (0x7fa98c002740) TMSI=007b0001 IMSI=234101713996691 responded
2017-05-23_09:10:23.200495 <ybts-signalling:INFO> Sending [0x107af80]
-----
Primitive: L3Message
Info: 3
Connection: 3

<SMS>
  <TID TIFlag="false">0</TID>
  <Message type="CP-Ack"/>
</SMS>
-----
2017-05-23_09:10:23.205598 <ybts:INFO> MT SMS 'ybts/sms/1' to (0x7fa98c002740) TMSI=007b0001 IMSI=234101713996691 failed reason='' RPDU=04540160


[marian]

SMS did failed to be delivered.
Please analyse returned RPDU
04 means RP-ERROR
RP message descriptions may be found in ETSI TS 100 942

[marian]

Please see also ETSI TS 124 011

[gvlachos]

ok,

one question once m.dispatch() returns false, how can I find the error/rpdu from nib.js ?

[marian]

You can check the 'rpdu' parameter of the message.
If it's not the same as the one you added to it: it's the MS's response

E.g.
myRpdu = "?";
m.rpdu=myRpdu;
m.dispatch();
if (myRpdu !== m.rpdu && m.rpdu) {
  // Handle the response
}

[gvlachos]

So these are the errors I get for different values set to RPDU I get as an error response

• 04540160 (in binary 100 01010100 00000001 01100000) and
• 04ff0161  (in binary 100 11111111 00000001 01100001)

Looking at http://www.etsi.org/deliver/etsi_ts/100900_100999/100942/07.01.00_60/ts_100942v070100p.pdf, sections 7.3.4 and 8.2.5.4,
I get the following sections:

• RP-Message Type (3 bits): so that's the 04 for RP-ERROR
• RP-Message Reference (1 octet): 01010100 or 11111111, different in the two examples above as they are errors for different messages sent
• RP-Cause (2-3 octets): 00000001 01100000 for the first and 00000001 01100001 for the second

The first octet of RP-Cause in both cases is the same 00000001, does that indicate the 'Unassigned (unallocated) number' (cause number 1) of the "Table 8.4/3GPP TS 04.11 (part 1)" of the specification? I think it shouldn't be as the message I try to sent is from YateBts to a mobile phone.

If I search "Table 8.4/3GPP TS 04.11 (part 2)" of the specification I find no values that match what I think is the RP-Cause value of the messages I get.

I am not sure how to proceed.

[marian]

First octet of cause IE is the length. Second octet is the cause reason (code). It may be followed by a diagnostic

[gvlachos]

ok,

still I get 2 cause numbers, i.e. 60 (01100000) and 61 (01100001) that do not appear in the list of valid RP-Cause numbers.

[marian]

0x60=96: Invalid mandatory information
0x61=97: Message type non-existent or not implemented

You may use Wireshark to decode it. It will decode your RPDU and the response
You may enable tapping in ybts.conf and send GSM layer 3 packets to a machine running Wireshark

[gvlachos]

The message that gives me the 'Invalid mandatory information' is for a binary SMS with the command ATCAT+CGMI (changed to hex and set to the RPDU field).

In the Message I set the following parameters:

Code: [Select]

route_type:msg
callednumplan:isdn
callednumtype:international
sms.called.plan:isdn
sms.called.nature:national
caller:123456789
called:3996691
sms.caller:123456789
callto:ybts/TMSI007b0001
oimsi:234101713996691
otmsi:007b0001
maxpdd:5000
rpdu:41544341542b43474d49

not sure if this info helps, my question really is : how to find which is the invalid information ?

or a more general question: I have tried to send a binary SMS message with different RPDU content (e.g. 'TON', 'PRF', 'HLP0', 'HLP1', 'AT+CMGF=?', 'SMSABC') and I always get some error response, so how can I find the appropriate fields and values to pass to YatesBts in a Message (from nib.js) ?

[marian]

You can't simply hexify a text and send it to MS.
Please see ETSI TS 100 942 and ETSI TS 124 011 on RPDU/TPDU format.

[gvlachos]

hello,

I have made some progress, mainly reading the specs (ETSI TS 100 942 and ETSI TS 124 011) and this site as well (http://www.spallared.com/old_nokia/nokia/smspdu/smspdu.htm). Sadly I still have no luck with making a correct pdu to send to the mobile and I get 'rpdu: 04000161' (RP-ERROR Message type non-existent or not implemented).

There is one approach though I thought about: in our current implementation the mobile (MS) sends a binary sms (SMS-SUBMIT) to SMSC. Then using some javacript code (nodejs) I connect to yates and install listeners to catch when an MS is registered and the SMS that are exchanged:

Code: [Select]

var YATEBTS_EXTERNAL_MODULE_PORT = 5040;
var IP = "127.0.0.1";

var net = require('net');

var client = new net.Socket();

client.on('connect', function(){
  // install listeners
  client.write('%%>install:50:user.register\r\n');
  client.write('%%>install:50:idle.execute\r\n');
  client.write('%%>install:50:msg.execute\r\n');
});

cls.client.on('data', function onWatch(rawData) {
  // show and parse the rawData ...
});

// connect to yates
client.connect(YATEBTS_EXTERNAL_MODULE_PORT, IP);

this way I see when an MS is registered and get some info (e.g. IMEI and IMSI) as well as messages sent from the MS to/from the SMSC. So I can see the following binary SMS that the MS sends to SMSC (all fields shown are as expected for the current setup):

Code: [Select]

----------------------------------->
25253e6d6573736167653a30783766316262386662356236302e313233303634373635343a313439363239383934313a6d73672e657865637574653a3a6d6f64756c653d796274733a726f7574655f747970653d6d73673a63616c6c65723d544d534930303762303030313a696d73693d3233343130313731333939363639313a746d73693d30303762303030313a696d65693d3335393236303036323338373030303a63616c6c65643d3638373737303030393a63616c6c65646e756d706c616e3d6973646e3a63616c6c65646e756d747970653d696e7465726e6174696f6e616c3a736d732e63616c6c65643d3132333435363738393a736d732e63616c6c65642e706c616e3d6973646e3a736d732e63616c6c65642e6e61747572653d6e6174696f6e616c3a727064753d303030393030303639313836373730373030663930663031373830396131323134333635383766393030303430333466346233653a7068795f696e666f3d54413d332054453d302e303030205570525353493d2d31342054785077723d3520446e5253534964426d3d2d39372074696d653d313439363239383933392e3335343a68616e646c6572733d6a617661736372697074257a31352c6364726275696c64257a35302c6a617661736372697074257a38303a63616c6c746f3d6e69625f736d7363
info:    [yate-watchsms.js/log_debug] Thu Jun 01 2017 06:35:40 GMT+0000 (UTC) raw: %%>message:0x7f1bb8fb5b60.1230647654:1496298941:msg.execute::module=ybts:route_type=msg:caller=TMSI007b0001:imsi=234101713996691:tmsi=007b0001:imei=359260062387000:called=687770009:callednumplan=isdn:callednumtype=international:sms.called=123456789:sms.called.plan=isdn:sms.called.nature=national:rpdu=000900069186770700f90f017809a121436587f90004034f4b3e:phy_info=TA=3 TE=0.000 UpRSSI=-14 TxPwr=5 DnRSSIdBm=-97 time=1496298939.354:handlers=javascript%z15,cdrbuild%z50,javascript%z80:callto=nib_smsc
info:    [yate-watchsms.js/log_debug] message: %%>message:0x7f1bb8fb5b60.1230647654:1496298941:msg.execute
info:    [yate-watchsms.js/log_debug] fields: module=ybts,route_type=msg,caller=TMSI007b0001,imsi=234101713996691,tmsi=007b0001,imei=359260062387000,called=687770009,callednumplan=isdn,callednumtype=international,sms.called=123456789,sms.called.plan=isdn,sms.called.nature=national,rpdu=000900069186770700f90f017809a121436587f90004034f4b3e,phy_info=TA=3 TE=0.000 UpRSSI=-14 TxPwr=5 DnRSSIdBm=-97 time=1496298939.354,handlers=javascript%z15,cdrbuild%z50,javascript%z80,callto=nib_smsc
{ module: 'ybts',
  route_type: 'msg',
  caller: 'TMSI007b0001',
  imsi: '234101713996691',
  tmsi: '007b0001',
  imei: '359260062387000',
  called: '687770009',
  callednumplan: 'isdn',
  callednumtype: 'international',
  'sms.called': '123456789',
  'sms.called.plan': 'isdn',
  'sms.called.nature': 'national',
  rpdu: '000900069186770700f90f017809a121436587f90004034f4b3e',
  phy_info: 'phy_info=TA=3 TE=0.000 UpRSSI=-14 TxPwr=5 DnRSSIdBm=-97 time=1496298939.354',
  handlers: 'javascript%z15,cdrbuild%z50,javascript%z80',
  callto: 'nib_smsc' }
info:    [yate-watchsms.js/log_debug] Thu Jun 01 2017 06:35:40 GMT+0000 (UTC) imei: 359260062387000
info:    [yate-watchsms.js/log_debug] Thu Jun 01 2017 06:35:40 GMT+0000 (UTC) imsi: 234101713996691
info:    [yate-watchsms.js/log_debug] Thu Jun 01 2017 06:35:40 GMT+0000 (UTC) rpdu: 000900069186770700f90f017809a121436587f90004034f4b3e
info:    [yate-watchsms.js/log_debug] Thu Jun 01 2017 06:35:40 GMT+0000 (UTC) ok message (OK> - 4f4b3e)
<-----------------------------------

So here I get a valid rpdu (000900069186770700f90f017809a121436587f90004034f4b3e) for an SMS-SUBMIT (MS to SMSC) which I would like to parse and understand so I can make an binary SMS for SMS-DELIVER (SMSC to MS).

Here I wonder if you could help me i.e. in understanding how the values are attributed to the correct field from the specs.

So the rpdu is:

Code: [Select]

00 09 00 06 91 86 77 07 00 f9 0f 01 78 09 a1 21 43 65 87 f9 00 04 03 4f 4b 3e

Looking at the spec for SMS-SUBMIT and examining the rpdu I observe the following:

• there is some initial octets I cannot understand:

Code: [Select]

00 09 00


• then I get the SCA (which I can also see from the 'called' field in my log above):

Code: [Select]

06 91 86 77 07 00 f9


• then I get the 'PDU type':

Code: [Select]

0f


• then there are some more octets that I cannot account for:

Code: [Select]

01 78 09 a1


• I recognize the DA (the 'sms.called' field from the log above):

Code: [Select]

21 43 65 87 f9


• then is the PID:

Code: [Select]

00


• then is the DCS:

Code: [Select]

04


• then the UDL:

Code: [Select]

03


• and finally the UDD which is the text "OK>" as expected:

Code: [Select]

4f 4b 3e


Thank you in advance !

[marian]

RPDU contains a RP message (TS 100 942 Section 2.2)
Specific RP messages are described in section 7.3.
For each informational element you must pay attention at Format column in tables: TLV means Type/Length/Value. If a letter is missing it means the corresponding part is not present! (e.g. LV meand length and value fields are present, type is not present)
RP-USER-DATA IE contains a TPDU (see TS 123 040 section 9.2.2)

You may always use Wireshark: this application can show you the binary data and its meaning (it has the ability to decode RP messages)
See tapping at http://wiki.yatebts.com/index.php/Ybts.conf