Useful semi-octets

[smsc]

Ciao ragazzi,
stavo programmando in C++ un applicativo che non sto qui a dire cosa deve fare tanto non e' importante ai fini della domanda. Sara' l'eta' ma mi si e' intrecciato il cevello e non riesco ad uscire dal loop... Qualcuno mi da una mano?

Quello che mi serve e', partendo da questa stringa hex:

0x41 0xE1 0x10 0x10 0x14 0x0E 0x01

The application should add the number of useful semi-octets within the values in front of these values. The length should be added in a
byte (octet). In the above case, the number of useful semi-octets in the 7 bit encoded representation is 13 decimal (0x0D hexadecimal). This results in the following hexadecimal values:

0x0D 0x41 0xE1 0x10 0x10 0x14 0x0E 0x01

Come azzo fa ad uscire 13? Secondo voi cosa cavolo vuol dire "the number of useful semi-octets"?

[banryu79]

Originariamente inviato da smsc

Come azzo fa ad uscire 13? Secondo voi cosa cavolo vuol dire "the number of useful semi-octets"?

Ho ricavato il seguente schema per induzione, prova a vedere se ti sembra corretto il procedimento. Se lo è, sei a cavallo e puoi implementare la tua soluzione.

hex = 0x41  0xE1  0x10  0x10  0x14  0x0E  0x01

hex  ->  binary string  ->  7 bit patition  ->  semi-octets
---------------------------------------------------------------
0x41 ->  1000001        ->  1000001         ->  [.100] [0001]
0xE1 ->  11100001       ->  1|1100001       ->  [...1] [.110] [0001]
0x10 ->  10000          ->  10000           ->  [...1] [0000]
0x10 ->  10000          ->  10000           ->  [...1] [0000]
0x14 ->  10100          ->  10100           ->  [...1] [0100]
0x0E ->  1110           ->  1110            ->  [1110]
0x01 ->  1              ->  1               ->  [...1]

total semi-octets: 13

P.S.: Per octet si intende esattamente un gruppo di 8 bit.
Sapendo questo ho dedotto che per "semi-octec" si intendesse "mezzo" octec, cioè esattamente 4 bit.
E' per questo motivo che nello schema sopra ho indicato il padding dei semi-octets con il carattere '.'

[smsc]

banryu, il tuo ragionamento e' davvero interessante, soprattutto per la parte "7 bit patition" che avevo saltato.

Ho provato con un'altra stringa hex, ma il tool (che dovrei riprodurre) mi restituisce 0x0E (14), e se applico il tuo raggionamento mi viene fuori questo:

hex = 0xCD  0xA0  0xF3  0x39  0x95  0x01  0x82

hex  ->  binary string  ->  7 bit patition  ->  semi-octets
---------------------------------------------------------------
CD   ->  11001101       ->   1|1001101      ->  [1] [100] [1101]
A0   ->  10100000       ->   1|0100000      ->  [1] [010] [0000]
F3   ->  11110011       ->   1|1110011      ->  [1] [111] [0011]
39   ->  111001         ->   111001         ->  [11] [1001]
95   ->  10010101       ->   1|0010101      ->  [1] [001] [0101]
01   ->  1              ->   1              ->  [1]
82   ->  10000010       ->   1|0000010      ->  [1] [000] [0010]

Giusto per tua conoscenza stiamo parlando di EMI UCP specification e come codificare l'OadC. Ovviamente la parte che a me interessa e' quella che ho messo in rosso, e cioe':
The application should add the number of useful semi-octets within the alphanumeric address in front of these values, according to ETSI's 3.40. The length should be added in a byte (octet). In case of ALPHA@NUM, the number of useful semi-octets in the 7 bit encoded representation is 16 decimal (0x10 hexadecimal). This results in the following hexadecimal values:
0x10 0x41 0x26 0x14 0x19 0x04 0x38 0xAB 0x4D

Suppose that the alphanumeric address is: ALPHA@NUM
The hexadecimal values of this string are:

0x41 0x4C 0x50 0x48 0x41 0x00 0x4E 0x55 0x4D

This alphanumeric address (IRA) should first be coded into 7 bits, according to ETSI's 3.38, by the application. In GSM 03.38 chapter “Default alphabet” the 7-bit codes can be derived from the table.
These codes are:
A = 100 0001
L = 100 1100
P = 101 0000
H = 100 1000
A = 100 0001
@ = 000 0000
N = 100 1110
U = 101 0101
M = 100 1101
The 7 bits characters are packed in octets as defined in chapter ”SMS Point-to-Point Packing”. The result is:
b7 B6 b5 b4 b3 b2 b1 b0 Result
0 1 0 0 0 0 0 1 41
0 0 1 0 0 1 1 0 26
0 0 0 1 0 1 0 0 14
0 0 0 1 1 0 0 1 19
0 0 0 0 0 1 0 0 04
0 0 1 1 1 0 0 0 38
1 0 1 0 1 0 1 1 AB
0 1 0 0 1 1 0 1 4D

0x41 0x26 0x14 0x19 0x04 0x38 0xAB 0x4D

The application should add the number of useful semi-octets within the alphanumeric address in front of these values, according to ETSI's 3.40. The length should be added in a byte (octet). In case of ALPHA@NUM, the number of useful semi-octets in the 7 bit encoded representation is 16 decimal (0x10 hexadecimal). This results in the following hexadecimal values:
0x10 0x41 0x26 0x14 0x19 0x04 0x38 0xAB 0x4D

Finally this string should be converted to an ASCII string that can be used in the UCP message. Each nibble (4 bits) should be stored as ASCII character. The resulting ASCII string is:
10412614190438AB4D

[banryu79]

Ok, il post mi ha chiarito le idee, in particolare la parte che spiega l'encoding dell'OadC.
Guarda così mi tornano tutti e 3 i casi:

hex = 0x41  0xE1  0x10  0x10  0x14  0x0E  0x01
hex  ->  left padded  ->  bit string  ->  semi-octets
---------------------------------------------------------------
41 ->  .1000001       ->  01000001    ->  [0100] [0001]
E1 ->  11100001       ->  11100001    ->  [1110] [0001]
10 ->  ...10000       ->  00010000    ->  [0001] [0000]
10 ->  ...10000       ->  00010000    ->  [0001] [0000]
14 ->  ...10100       ->  00010100    ->  [0001] [0100]
0E ->  ....1110       ->  00001110    ->  [0000] [1110]
01 ->  .......1       ->  00000001    ->  (0000) [0001]

>13 USEFUL octes


ALPHA@NUM
0x41 0x26 0x14 0x19 0x04 0x38 0xAB 0x4D
hex ->  left padded  ->  bit string -> semi-octet
---------------------------------------------------------------
41  ->  .1000001     ->  01000001   ->  [0100] [0001]
26  ->  ..100110     ->  00100110   ->  [0010] [0110]
14  ->  ...10100     ->  00010100   ->  [0001] [0100]
19  ->  ...11001     ->  00011001   ->  [0001] [1001]
04  ->  .....100     ->  00000100   ->  [0000] [0100]
38  ->  ..111000     ->  00111000   ->  [0011] [1000]
AB  ->  10101011     ->  10101011   ->  [1010] [1011] 
4D  ->  .1001101     ->  01001101   ->  [0100] [1101]

>16 USEFUL octets



hex = 0xCD  0xA0  0xF3  0x39  0x95  0x01  0x82
hex ->  left padded  ->  bit string -> semi-octet
---------------------------------------------------------------
CD  ->  11001101     ->  11001101   ->  [1100] [1101]
A0  ->  10100000     ->  10100000   ->  [1010] [0000]
F3  ->  11110011     ->  11110011   ->  [1111] [0011]
39  ->  ..111001     ->  00111001   ->  [0011] [1001]
95  ->  10010101     ->  10010101   ->  [1001] [0101]
01  ->  .......1     ->  00000001   ->  [0000] [0001]
82  ->  10000010     ->  10000010   ->  [1000] [0010]

>14 USEFUL octets

In pratica, guardando i semi-octets prodotti, l'ordine di lettura è da destra verso sinistra, dall'alto verso il basso. Se l'ultimo semi-octet dell'encoding vale 0 [0000] non lo conti.

[smsc]

Sei un genio!
Quello che non capivo era proprio la dicitura "useful semi-octets". Una volta capito grazie alle tue spiegazioni sara' facile implementare il codice c++.

Intanto tutto sembra funzionare, e per provare ho "buttato giu" al volo due righe di VB per testare piu' casi possibili ("codifica" e' la stringa hex gia' in 7bit):

For t = 1 To Len(codifica)
    octects = String(4 - Len(HexToBin(Mid$(codifica, t, 1))), "0") & HexToBin(Mid$(codifica, t, 1)) & " "
    If octects <> "0000" And t <> Len(codifica) - 1 Then conta = conta + 1
Next
msgbox = String(2 - Len(Hex(conta)), "0") & Hex(conta) & codifica

Grazie ancora, mi hai aiutato non poco!

[banryu79]

Originariamente inviato da smsc

Grazie ancora, mi hai aiutato non poco!

Prego, è stato divertente
Buon lavoro