SMS: 16bit reference numbers for concatenation / Sending "SMS-PP DO...

SMS: 16bit reference numbers for concatenation / Sending "SMS-PP DO... SearchSearch

SMS & MMS Technical Forum » NowSMS Support - SMS Issues (Product Support Only) » Archive through August 22, 2012 » SMS: 16bit reference numbers for concatenation / Sending "SMS-PP DOWNLOAD" messages « Previous || Next »
Author Message
Andy28
New member
Username: De_afeider

Post Number: 3
Registered: 11-2011
Posted on Tuesday, February 14, 2012 - 10:11 am:   

Hello NowSMS team,

I got two questions regarding the SMS functionality of NowSMS:

We are using a licensed version of NowSMS, but we are not sure, whether the following tests can be executed using NowSMS.

1) Is there a way to configure NowSMS to use 16bit reference numbers when sending concatenated SMS (according to 3GPP TS 23.040 - 9.2.3.24.8)?

2) Is it possible to use NowSMS to send the kind of message stated below?

ENVELOPE (SMS-PP DOWNLOAD)

Command: ENVELOPE
Status: Normal ending of command, with extra information from the proactive UICC. Length 15.

Current DF: USIM Application Directory (3F00.7FFF)
Current EF: Location Information (6F7E)
Time: 726.877 s
Logical Channel: 00

Secure Messaging Indication: No SM used between terminal and card

SMS-PP DOWNLOAD

Device Identity
Source: Network
Destination: UICC

Address
Type of number: International Number
Numbering plan identification: ISDN/ telephony numbering plan (Rec. E.164/ E.163)
Dialling number string: 491720354333

SMS TPDU
TP-Message-Type-Indicator: SMS-DELIVER (in the direction SC to MS)
TP-More-Messages-to-Send: No more messages are waiting for the MS in this SC
TP-Reply-Path: TP-Reply-Path parameter is not set in this SMS-SUBMIT/DELIVER
TP-User-Data-Header-Indicator: The beginning of the TP-UD field contains a Header in addition to the short message
TP-Status-Report-Indication A status report will be returned to the SME
TP-Originating-Address
Error in Length: A length of more than 127 bytes shall be coded in two bytes (81 xx).
Type of number: Unknown
Numbering plan identification: ISDN/ telephony numbering plan (Rec. E.164/ E.163)
Dialling number string: 0000
TP-Protocol-Identifier: USIM Data download
TP-Data Coding Scheme: 8-bit data, Class 2 SIM-specific message,
TP-Service-Centre-Time-Stamp 12/02/08, 14:42:25 GMT +1:0

TP-User Data Length: 45
Information-Element-Identifier: RFU
Data: @(êã@))$°g 'B9' '83' '84' - 'C9' 'E5' 'D6' '92' k '83' m 'B9' 'F8' '8F' 'C8' 'AC' 'E9' rTÖ '9A' 'FE' A 'EC' SFDU 'CF' V
TP-User Data (hexadecimal): 02 70 00 00 28 15 16 00 29 29 02 0A 10 67 B9 83
84 2D C9 E5 D6 92 6B 83 6D B9 F8 8F C8 AC E9 72
54 5C 9A FE 41 10 EC 53 46 44 55 CF 56

I am pretty sure, that some information is missing to answer the second issue. Please help me to gather all the information needed to get the issue solved.

Kind regards,
Andy
Des - NowSMS Support
Board Administrator
Username: Desosms

Post Number: 3779
Registered: 08-2008
Posted on Tuesday, February 14, 2012 - 06:06 pm:   

Hi Andy,

1.) To enable 16-bit reference numbers, edit SMSGW.INI, and under the [SMSGW] section header, add ConcatRef16Bit=Yes.

(This setting is present in all 2010 and later releases.)

Note that using this setting changes the number of characters per SMS when sending long SMS, as one more byte is required for UDH. (The web interface character/message count will not be accurate.)

2.) I gather you're trying to do SIM update of some sort.

These are the bits that I can help you with:

PID = 7F (TP-Protocol-Identifier: USIM Data download)
DCS = F6 (TP-Data Coding Scheme: 8-bit data, Class 2 SIM-specific message)
UDH = 027000 (Command Packet Identifier)

You'll notice in your example, 02 70 00 is the start of the user data in your example. In NowSMS, specify this part as the "UDH" (user data header), and the rest as "Data".

The encoding of the data is the tough part.

You need to construct an ETSI GSM 11.11/11.14 binary message with valid security codes for encryption, matching the codes set on the SIM. ETSI GSM 03.48 defines the security mechanisms for the encryption of the data.

Section 5.1 of GSM 03.48 gives you the Command Packet Structure. Leave off the CPI, and start with the CPL (Command Packet Length). In your example above, the CPL is 00 28 (40 decimal).

Section 6.2 explains how to format that packet for SMS, and explains the UDH that I've already mentioned.

If you search this forum with a keyword of 027000, you will find some other threads, and might find some useful information. Note that in a lot of those threads, people are trying to put the SIM update commands into the data (GSM 11.11/11.14) without following the encryption and command packet format defined in GSM 03.48. So many of the examples you will find in that search are somewhat misguided because they are not considering this.

--
Des
NowSMS Support
Des - NowSMS Support
Board Administrator
Username: Desosms

Post Number: 3780
Registered: 08-2008
Posted on Tuesday, February 14, 2012 - 06:08 pm:   

This discussion thread might also be helpful: http://support.nowsms.com/discus/messages/1/59837.html
Andy28
New member
Username: De_afeider

Post Number: 4
Registered: 11-2011
Posted on Wednesday, February 15, 2012 - 09:52 am:   

Thanks for your help!

Regarding issue 1):

Is it also possible to change this on a per message basis so that I am able to use both concatenation values via web interface?


Regarding issue 2):

Here is a complete PDU trace which I try to recreate and send via NowSMS:

D14B020283810607919471025334330B3C64048100007FF6212080512233402D0270000028151600 2929020A1028E10E623E0B69DF018CA1CF509DBC7ACD5CFE46686A746AE944B6FEF3BD16A2

What I figured out until now (also with your help):
07 - SMSC address length
91 - Type of SMSC address (international, ISDN)
9471025334330B3C - SMSC address (0B3C seems to be too much)
64 - Type of message (SMS-Deliver, User Data Header included, Report requested, no more messages waiting)
04 - Address length
81 - Type of address (unknown)
0000 - Phone number
7F - PID (USIM Data download)
F6 - DCS (8-bit data, Class 2)
21208051223340 - Timestamp
2D - User Data Length
027000 - User Data Header (Command Packet Identifier)
00281516002929020A1028E10E623E0B69DF018CA1CF509DBC7ACD5CFE46686A746AE944B6FEF3BD 16A2 - User Data (excluding Header)

I am wondering about the values in front of the SMSC address length (D14B0202838106).
Also I do not know about the values (0B3C) between SMSC address and type of originating adress.

Do you see any explanation for these values?

Kind regards,
Andy
Des - NowSMS Support
Board Administrator
Username: Desosms

Post Number: 3785
Registered: 08-2008
Posted on Wednesday, February 15, 2012 - 01:45 pm:   

Hi Andy,

1.) No. If you need to do this only for certain messages, you would need to presegment them and include UDH when submitting.

2.) You don't have control over all of the headers.

The SMSC address and timestamp are inserted by the SMSC that processes and delivers the message.

Using a GSM modem is about as close as you can get, but other SMSC interfaces abstract values and use different parameter names.

Flags like User Data Header included are set automatically by NowSMS depending on whether or not you include UDH. Report requested corresponds to ReceiptRequested=Yes (there is a setting to force this for all HTTP submissions if you want). More messages waiting is a flag set by the SMSC.

Type of address goes by different names/values in different interfaces. The general rule for NowSMS is to default to unknown as long as the address is numeric. If it starts with +, it is set as international. If it contains alpha characters, it is set as alphanumeric.

Of course, in this packet, the address referenced is the sender. The sender value cannot be set if sending via a modem.

As for the extra bytes, 0B3C, I believe you are looking at a corrupt message. I can't see any explanation.

As for the values in front of the SMSC address, I just assume that you are looking at this packet wrapped inside of another protocol. I'm not really sure how you captured this packet ... that is, at what protocol layer it was captured. Of course, it is also possible that those extra bytes mean something at the other protocol layer as well ... it would be odd, but possible.

--
Des
NowSMS Support

Login Login / Register Logout Logout Search Last 30 Days Topics Topics