EF PNN speicifcation in sim/usim

Question

I am writing a sim profile and I need to code EF PNN. As per TS31.102 and TS24.008 it shows that EF-PNN has

    first byte = Full name for network IEI: '43'
    second byte = Length of Full name for network Name contents
    Y bytes = Full name for network

So for example, if I want to code to display network name as "Mynetwork", I am coding as

EF PNN = '43094D796E6574776F726B'H

But the output is some junk characters. Can someone throw a light on how to code network name string for EF PNN? Is it not straight ASCII conversion?

Answer 1

Is it not straight ASCII conversion?

Maybe.

You need to pay really close attention to exactly what the specification says for these kinds of AT commands that is doing more special case/advanced/low level stuff (for accessing SIM EF entries I assume you are using AT+CSIM or AT+CRSM?).

For more "mainsteam", "normal" AT commands, like for instance AT+CPBW for writing phonebook entries, the string arguments are very likely to be plain strings (NB, subject to AT+CSCS conversion). For the more "special" case/low level commands it might not be. Specifically for AT+CRSM, in chapter 8.18 Restricted SIM access +CRSM in 27.007 the syntax is given as

+CRSM=<command>[,<fileid>
[,<P1>,<P2>,<P3>
[,<data>[,<pathid>]]]]

and below it lists

<data>:   information which shall be written to the SIM (hexadecimal character
          format; refer +CSCS)
<pathid>: string type; contains the path of an elementary file on the SIM/UICC in
          hexadecimal format as defined in ETSI TS 102 221 [60] (e.g. "7F205F70"
          in SIM and UICC case). The <pathid> shall only be used in the mode
          "select by path from MF" as defined in ETSI TS 102 221 [60].

So this command has one (<data>) that you clearly can treat as a normal string and another one (<pathid>) that you absolutely cannot tell without checking the specified reference (I briefly checked this one and it appears to also be a plain string but with some constraints on what values the string can contain).

But the point is you absolutely cannot assume. You must check because many of the AT commands are literally just transparently exposing whatever low level values that is used internally by some part of the mobile stack¹.

---

Now for the network name this appears to be defined in chapter "10.5.3.5a Network Name" in 24.008, and in "Figure 10.5.80/3GPP TS 24.008 Network Name information element" it lists

• octet 1 as information element
• octet 2 as length
• octet 3 is a coding scheme byte describing how to interpret the following payload
• octet 4..n payload

so you are missing this third byte.

Notice that for coding scheme you actually only have two values to chose from, either GSM default alphabet or UCS2 and to me this then sort of implies that the input value ought not to go through a AT+CSCS translation. So if you want to use gsm alphabet the safest bet would be to set AT+CSCS="GSM" first to make sure no translation is done. If you would want to use UCS2 and have run AT+CSCS="UCS2" beforehand I think maybe you would need to double encode the network name for it to be correctly saved, and I think using AT+CSCS="HEX" instead would be a safer option in that case.

---

¹ Speaking of which, while the string in AT+CPBW is straight forward notice that the <type> parameter literally is the raw, low level 8 bits in the EXT + TON + NPI byte (Type of number, Numbering plan identification) from the address format specified for SMS messages.

E.g. the typical 145 value (0x91, 1001_0001b) is EXT always 1, TON 001 (International number) and NPI 0001 (ISDN/telephone numbering plan (E.164/E.163)).

Answer 2

I have created a project doing the EF PNN encoding.

Basically the encoding is:

43 <xy length> 8<x sparebits> <gsm03.38 septet encoding>