CDMA SMS Handling

CDMA SMS Handling

[Rajesh.Nagaiah]

[-- Attachment #1: Type: text/plain, Size: 6305 bytes --]

Hi,

There was a discussion about the CDMA SMS handling and CDMA PDUs in the
IRC channel couple of days before. I would like to highlight the
differences between CDMA and GSM PDU and how we should proceed with this
from my understanding. Let me know your opinion.

Even though oFono supports +CMT and +CMTI, if we feed the incoming CDMA
PDUs to the SMS core it wont get decoded correctly, as there is
substantial differences between the GSM and CDMA SMS PDUs as described
in 3GPP2 specification C.S0015-B Short Message Service (SMS) for
Wideband Spread Spectrum Systems

For eg, the incoming PDU example that was mentioned in the IRC
discussion

+CMT: , 40,
00000210020207028CE95DCC65800601FC08150003168D30010610241830608003061010
04044847
40 - Length of the PDU in bytes
00 - Message Type ( 00 -  SMS Point-to-Point) 
00 - TeleService Identifier Tag (SMS Parameter Indentifier)
02 - TeleService Identifier Length (SMS Parameter Length)
10 - TeleService Identifier Value  - First 8 bits
02 - TeleService Identifier Value  - Second 8 bits
     TeleService Identifier - 0x1002 -  CDMA Messaging Teleservice
(CMT-95)

02 - Originating Address Tag
07 - Originating Address Length
02 - Originating Address 1st 8 Bits
8C - Originating Address 2nd 8 Bits
E9 - Originating Address 3rd 8 Bits
5D - Originating Address 4th 8 Bits
CC - Originating Address 5th 8 Bits
65 - Originating Address 6th 8 Bits
80 - Originating Address 7th 8 Bits

        Digit Mode - 1 Bit
        Number Mode - 1 Bit
        Number Type - 0 or 3 bits
        Number Plan - 0 or 4 bits
        Number Fields - 8 Bits
        Number Field occurrence of CHARi
        CHARi - 4 or 8 bits ( 4 - in case of DTMF encoding, 8 - incase
of ASCII encoding)
        Reserved - 0-7 bits

      Lets take the 1st and 2nd 8 bits
      02  - 0000 0010 ( Digit Mode bit - 0, Number Mode bit - 0)
      8C  - 1000 1100
      As Digit mode bit is set to 0, Number Plan and Number Type is void
(0 bits) in this case.
      So the remaining 6 bits of 1st 8bits and the first 2 bits of 2nd
8bit is Number fields
  
      Number fields - 00 0010 10 - 0000 1010 - 0x0A (10 digits)
      As Digit mode bit is set to 0, each address digit here is
represented as 4bit DTMF digit

      0x8C       0xE9       0x5D       0xCC       0x65       0X80
      1000 1100  1110 1001  0101 1101  1100 1100  0110 0101  1000 0000 
      
      10 0011 0011 1010 0101 0111 0111 0011 0001 1001 0110 0000 00 
      
          3     3   0    5    7    7    3    1    9    6     Last 6 bits
are reserved bits

      Originating Address - 3305773196      

06 - Bearer Reply Option Tag
01 - Bearer Reply Option Length
FC - First 6 bits Reply Sequence number and last 2 bits reserved set to
0
     1111 1100 - 111111 REPLY_SEQ
                     00 Reserved
08 - Bearer Data Tag
15 - Bearer Data Length
00 - Message Indentifier Tag ( Bearer Data Sub parameter )
03 - Message Indentifier Length
16 - Message Type 4 bits Message Id 4 Bits
8D - Message Id 8 Bits
30 - Message Id 4 Bits, UDH Header indicator 1 Bit, Reserved 3 Bits
     How Message Identifier value 16 8D 30 was formed ?
         Message type ( 4 bits )  - 1( 0001 - Deliver)         
         Message Identifier  ( 16 bits ) -  26835( 0x68D3)
         Header Indicator (1 bit) - 0 (UDH not present in User Data
Subparameter)
         Reserved ( 3bits) - 0 (000)

01 - User Data Tag ( Bearer Data Sub parameter )
06 - User Data Length
10 - Message Encoding 5 bits ( 0001 0000 ( 00010 = 2 -> 7-bit ASCII )) &
Number Fields 3 bits ( 000)
24 - Number Fields 5 Bits + User char field 1's 3 bits ( 0010 0100 )
18 - User char field 1's remaining 5 bits + User char field 2's 3 bits
(0001 1000)
30 - User char field 2's remaining 5 bits + User char field 3's 3 bits
(0011 0000)
60 - User char field 3's remaining 5 bits + User char field 4's 3 bits
(0110 0000)
80 - User char field 4's remaining 5 bits + Reserved 3 Bits (1000 0000)

     Number Fields: 000 00100  - 04 (4 Character fields)
     User Char [1] - 100 00011 - 0x83
     User Char [2] - 000 00110 - 0x06
     User Char [3] - 000 01100 - 0x0C
     User Char [4] - 000 10000 - 0x10

     Hex         0x83        0x06        0x0C        0x10
     Octets      1000 0011   0000 0110   0000 1100   0001 0000
     Septets     1000 001   10000 01   100000 1   1000001
     Character   A(0x41)     A(0x41)     A(0x41)  A(0x41)

     Message content: AAAA

     Message Encoding - 2 (00010 - 5 bits) 
     Number Fields - 4 (0000  0100 - 8 bits)
     User characters - 0x83 0x06 0x0C 0x10 ( 8 bits each)

     00010 0000 0100 1000 0011 0000 0110 0000 1100 0001 0000

     0001 0000 - 0x10
     0010 0100 - 0x24
     0001 1000 - 0x18
     0011 0000 - 0x30
     0110 0000 - 0x60
     1000 0000 - 0x80 (Last 3 bits set to 0's(reserved bit) to complete
the octets)
  
03 - Message Center Time Stamp Tag ( Bearer Data Sub parameter )
06 - Message Center Time Stamp Length
     all date and time fields contain two 4-bit BCD numbers giving the
decimal value of the field.
10 - Year (2010)
10 - Month (10 - October)
04 - Day
04 - Hour
48 - Minutes
47 - Seconds
     Time Stamp 04:48:47 04/10/2010

Decoded Information:
Message Type: Deliver (Incoming Message)
Teleservice: CMT-95
Message Identifier: 26835
Originating Address: 3305773196
Message content: AAAA
Message Center Time Stamp: 04:48:47 04/10/2010

As from the above decoding example we can see there is substantial
differences between the GSM and CDMA SMS specifications and so the SMS
atom needs many additions and needs to be heavily modified to support
also CDMA SMS handling. Currently the oFono sms file unit handles the
common and the GSM technology aspects of the SMS stack along with the
smsutils. The SMS atom has the GSM specific members, segmentation and
queuing logic. The smsutils mainly takes care of encoding/decoding of
the PDUs, which is GSM specific. As the segmentation and queuing logic
and the interface is common for both GSM and CDMA, we could reuse this
common code and add the CDMA handling into it and create a new
cdmasmsutils unit to support the CDMA SMS specifics, much like the
smsutils does already for GSM.

BR,
Rajesh



[-- Attachment #2: attachment.html --]
[-- Type: text/html, Size: 13871 bytes --]

Re: CDMA SMS Handling

[Marcel Holtmann]

[-- Attachment #1: Type: text/plain, Size: 833 bytes --]

Hi Rajesh.

> There was a discussion about the CDMA SMS handling and CDMA PDUs in
> the
> IRC channel couple of days before. I would like to highlight the
> differences between CDMA and GSM PDU and how we should proceed with
> this
> from my understanding. Let me know your opinion.

thanks for the details and yes, we knew that the PDU format is
different. I am currently happy to see PDUs on CDMA at all right now.
Previous talks revealed that CDMA hardware might just only expose text
mode for AT commands. And that is a nasty situation that is almost
impossible to support within oFono.

If you guys have example SMS PDUs for CDMA, please collect them and lets
write some unit tests for it. Getting a head start on CDMA can't hurt
even we still have some GSM details to sort out first.

Regards

Marcel

Re: CDMA SMS Handling

[Denis Kenzior]

[-- Attachment #1: Type: text/plain, Size: 1374 bytes --]

Hi Rajesh,

> As from the above decoding example we can see there is substantial
> differences between the GSM and CDMA SMS specifications and so the SMS
> atom needs many additions and needs to be heavily modified to support
> also CDMA SMS handling. Currently the oFono sms file unit handles the
> common and the GSM technology aspects of the SMS stack along with the
> smsutils. The SMS atom has the GSM specific members, segmentation and
> queuing logic. The smsutils mainly takes care of encoding/decoding of
> the PDUs, which is GSM specific. As the segmentation and queuing logic
> and the interface is common for both GSM and CDMA, we could reuse this
> common code and add the CDMA handling into it and create a new
> cdmasmsutils unit to support the CDMA SMS specifics, much like the
> smsutils does already for GSM.

This gets my vote, I like to start bottom up.  E.g. build the
infrastructure first, with unit tests, etc and then hook up the
controlling logic.  So starting cdma smsutils seems like a good idea to me.

Do note however that there's more to smsutils than basic parsing.  We
also have sms fragmentation / de-fragmentation logic, sms assembly
serialization, status reports, character encoding / decoding, etc.  We
will have to figure out which parts can be re-used for both CDMA and GSM
as we go along...

Regards,
-Denis

RE: CDMA SMS Handling

[Rajesh.Nagaiah]

[-- Attachment #1: Type: text/plain, Size: 2742 bytes --]

Hi Denis/Marcel,

>This gets my vote, I like to start bottom up.  E.g. build the
infrastructure first, with unit tests, etc and then hook
>up the controlling logic.  So starting cdma smsutils 
>seems like a good idea to me.

I agree, starting with the cdma smsutils should be the starting point,
along with the unit test developement.

>Do note however that there's more to smsutils than basic parsing.  We
also have sms fragmentation / de-fragmentation
>logic, sms assembly serialization, status reports, 
>character encoding / decoding, etc.  We will have to figure out which
parts can be re-used for both CDMA and GSM as we 
>go along...

I did an analysis of the existing smsutils fuctionalities for the code
reusability. If we can make the struct sms common for both GSM and CDMA
by having them as union members, then we can re-use sms assembly
serialization and fragmentation/de-fragmentation logic with only minor
changes and no interface changes. Also this struct change will later
help in multimode case as well, if we have plans for a multimode stack.

Existing struct sms:

struct sms {
	struct sms_address sc_addr;
	enum sms_type type;
	union {
		struct sms_deliver deliver;
		struct sms_deliver_ack_report deliver_ack_report;
		struct sms_deliver_err_report deliver_err_report;
		struct sms_submit submit;
		struct sms_submit_ack_report submit_ack_report;
		struct sms_submit_err_report submit_err_report;
		struct sms_command command;
		struct sms_status_report status_report;
	};
};

Proposed struct sms:

struct sms {
	enum sms_type type;
	union {
		struct gsm_sms g_sms;
		struct cdma_sms c_sms;
	};
};

struct gsm_sms {
	struct sms_address sc_addr;
	enum gsm_sms_type type;
	union {
		struct sms_deliver deliver;
		struct sms_deliver_ack_report deliver_ack_report;
		struct sms_deliver_err_report deliver_err_report;
		struct sms_submit submit;
		struct sms_submit_ack_report submit_ack_report;
		struct sms_submit_err_report submit_err_report;
		struct sms_command command;
		struct sms_status_report status_report;
	};
};

struct cdma_sms {
	enum cdma_sms_type type;
	union {
		struct cdma_sms_deliver deliver;
		struct cdma_sms_submit submit;
		struct cdma_sms_cancel cancel;
		struct cdma_sms_delivery_ack delivery_ack;
		struct cdma_sms_user_ack user_ack;
		struct cdma_sms_read_ack read_ack;
		struct cdma_sms_deliver_report deliver_report;
		struct cdma_sms_submit_report submit_report;
	};
};

Let me know your feedback on this. If we agree on this, then one of the
first tasks should be to do this struct change on the exising code, so
that GSM developement can happen parallely based on this new structural
change.

BR,
Rajesh

Re: CDMA SMS Handling

[Denis Kenzior]

[-- Attachment #1: Type: text/plain, Size: 2871 bytes --]

Hi Rajesh,

> I did an analysis of the existing smsutils fuctionalities for the code
> reusability. If we can make the struct sms common for both GSM and CDMA
> by having them as union members, then we can re-use sms assembly
> serialization and fragmentation/de-fragmentation logic with only minor
> changes and no interface changes. Also this struct change will later
> help in multimode case as well, if we have plans for a multimode stack.
> 
> Existing struct sms:
> 
> struct sms {
> 	struct sms_address sc_addr;
> 	enum sms_type type;
> 	union {
> 		struct sms_deliver deliver;
> 		struct sms_deliver_ack_report deliver_ack_report;
> 		struct sms_deliver_err_report deliver_err_report;
> 		struct sms_submit submit;
> 		struct sms_submit_ack_report submit_ack_report;
> 		struct sms_submit_err_report submit_err_report;
> 		struct sms_command command;
> 		struct sms_status_report status_report;
> 	};
> };
> 
> Proposed struct sms:
> 
> struct sms {
> 	enum sms_type type;
> 	union {
> 		struct gsm_sms g_sms;
> 		struct cdma_sms c_sms;
> 	};
> };

So personally I'd just extend the current enum sms_type with CDMA
variants, e.g.:
	SMS_TYPE_CDMA_DELIVER, SMS_TYPE_CDMA_SUBMIT, etc and add the cdma
structures directly to the current union, e.g:

struct sms {
	struct sms_address sc_addr;
	enum sms_type type;
	union {
		struct sms_deliver deliver;
		struct sms_deliver_ack_report deliver_ack_report;
		struct sms_deliver_err_report deliver_err_report;
		struct sms_submit submit;
		struct sms_submit_ack_report submit_ack_report;
		struct sms_submit_err_report submit_err_report;
		struct sms_command command;
		struct sms_status_report status_report;

		/* CDMA */
		struct sms_cdma_deliver deliver;
		struct sms_cdma_submit submit;
		...
	};
};

<snip>

> struct cdma_sms {
> 	enum cdma_sms_type type;

Does CDMA have an SMSC address?

> 	union {
> 		struct cdma_sms_deliver deliver;
> 		struct cdma_sms_submit submit;
> 		struct cdma_sms_cancel cancel;
> 		struct cdma_sms_delivery_ack delivery_ack;
> 		struct cdma_sms_user_ack user_ack;
> 		struct cdma_sms_read_ack read_ack;
> 		struct cdma_sms_deliver_report deliver_report;
> 		struct cdma_sms_submit_report submit_report;
> 	};
> };
> 
> Let me know your feedback on this. If we agree on this, then one of the
> first tasks should be to do this struct change on the exising code, so
> that GSM developement can happen parallely based on this new structural
> change.

Doing it the way I suggested would keep the impact on the current code
base absolutely minimal.  This way you can start submitting patches
right away for CDMA support without impacting anyone.  Once the CDMA
aspects are stabilized and we're happy with them we can do the final
struct / API refactoring as needed.

Thoughts?

Regards,
-Denis

RE: CDMA SMS Handling

[Rajesh.Nagaiah]

[-- Attachment #1: Type: text/plain, Size: 1696 bytes --]

Hi Denis,

>So personally I'd just extend the current enum sms_type with CDMA
variants, e.g.:
>	SMS_TYPE_CDMA_DELIVER, SMS_TYPE_CDMA_SUBMIT, etc and add the
cdma structures directly to the current union, e.g:
>
>struct sms {
>	struct sms_address sc_addr;
>	enum sms_type type;
>	union {
>		struct sms_deliver deliver;
>		struct sms_deliver_ack_report deliver_ack_report;
>		struct sms_deliver_err_report deliver_err_report;
>		struct sms_submit submit;
>		struct sms_submit_ack_report submit_ack_report;
>		struct sms_submit_err_report submit_err_report;
>		struct sms_command command;
>		struct sms_status_report status_report;
>
>		/* CDMA */
>		struct sms_cdma_deliver deliver;
>		struct sms_cdma_submit submit;
>		...
>	};
>};

We can do that way as well, but the only reason I proposed the other way
was not to mix the CDMA specific values to exisiting GSM data. For eg,
now we have add CDMA specific SMS types to the enum sms_type.

>Does CDMA have an SMSC address?

CDMA doesnt have Message center address


>Doing it the way I suggested would keep the impact on the current code
base absolutely minimal. This way you can start 
>submitting patches right away for CDMA support
>without impacting anyone.  Once the CDMA aspects are stabilized and
we're happy with them we can do the final struct / 
>API refactoring as needed.
>
>Thoughts?

Yes, i agree doing this way would have minimal impact to the current
code base. But from refactoring prespective the effort will be double if
we do the refactoring at the later stage, as now we need to refactor
only the GSM code and later we have to refactor both GSM and CDMA code.


BR,
Rajesh

Re: CDMA SMS Handling

[Denis Kenzior]

[-- Attachment #1: Type: text/plain, Size: 1213 bytes --]

Hi Rajesh,

>> Doing it the way I suggested would keep the impact on the current code
> base absolutely minimal. This way you can start 
>> submitting patches right away for CDMA support
>> without impacting anyone.  Once the CDMA aspects are stabilized and
> we're happy with them we can do the final struct / 
>> API refactoring as needed.
>>
>> Thoughts?
> 
> Yes, i agree doing this way would have minimal impact to the current
> code base. But from refactoring prespective the effort will be double if
> we do the refactoring at the later stage, as now we need to refactor
> only the GSM code and later we have to refactor both GSM and CDMA code.

I understand your concern, but I think the changes required are simply
too invasive at this point.  There's also the possibility that after
doing all the work for CDMA we might find that it is incompatible with
the rest of smsutil.  I prefer not to take this risk right now.

Besides, I think you will find that transforming the data structures
from my proposal to your original proposal at a later date will not be
that much work.  If we have proper unit tests in place it should take no
more than an afternoon...

Regards,
-Denis

Re: CDMA SMS Handling

[asraf]

[-- Attachment #1: Type: text/plain, Size: 628 bytes --]

Hi Rajesh,

I have a question about CDMA packet that I think it has a bit different from the 
format you have.

I can decode the incoming CDMA packet from MSC if the format of SMS_Bearerdata 
like yours.

But when tehe format of SMS_bearerdata is looks like this,I cannot decode the 
contain of packet:
Data= 00 03 20 03 58 01 4b 12 98 28 00 1a b8 10 13 3f 44 19 33 ee 41 e7 0f 9c 28 
3c 20 e1 97 96 dc 39 77 6b dc 83 16 ff 28 35 ec ee 83 ce 1f 38 50 73 f3 9d 06 2d 
fe 50 61 e1 87 a6 1d 08 36 67 d2 83 16 ff 28 31 6f f2 83 87 5d c8 39 f9 ce 83 ce 
1f 38 40 

I hope you can help me.

Regards,
Ashraf

Re: CDMA SMS Handling

[asraf]

[-- Attachment #1: Type: text/plain, Size: 708 bytes --]

Hi Rajesh,

I need your help in decoding the CDMA packet.

I can decode all incoming packet of SMS_Bearerdata from MSC except small number 
of it.

The construction of packet that I cannot decode looks different from your 
sample of packet.

Below is sample of SMS_Bearerdata I have got from MSC which is I cannot decode:
 Data= 00 03 20 03 58 01 4b 12 98 28 00 1a b8 10 13 3f 44 19 33 ee 41 e7 0f 9c 
28 3c 20 e1 97 96 dc 39 77 6b dc 83 16 ff 28 35 ec ee 83 ce 1f 38 50 73 f3 9d 06 
2d fe 50 61 e1 87 a6 1d 08 36 67 d2 83 16 ff 28 31 6f f2 83 87 5d c8 39 f9 ce 83 
ce 1f 38 40 

I hope you can assist and share with us of your findings base on my sample 
packet.

Regards,
Ashraf