you won't find it in the modem documentation because IPAd isn't a modem feature. SGP.32 splits the work across three parties, and the modem is only involved in one of them — as a transport.
What SGP.32 actually requires
Component
Where it lives
Who provides it
eUICC with SGP.32 OS
The eSIM/SIM itself
eSIM vendor (Kigen, Thales, IDEMIA, G+D…)
IPAd(IoT Profile Assistant, device variant)
Application processor — your Zephyr app
You / a third-party SDK
eIM
Cloud
Connectivity provider
IPAd is just an application. It needs two things from the nRF9151:
An APDU pipe to the eUICC— to open a logical channel,SELECTthe ISD-R AID (A0000005591010FFFFFFFF8900000100), and drive ES10a/b/c.
An IP data path— plain HTTPS to the SM-DP+ (ES9+) and eIM (ES11/ES10b). SGP.32 deliberately dropped the BIP/CAT-TP requirement that made SGP.02 painful, so this is ordinary TLS over the LTE-M/NB-IoT data connection. The nRF9151 obviously does that fine.
you won't find it in the modem documentation because IPAd isn't a modem feature. SGP.32 splits the work across three parties, and the modem is only involved in one of them — as a transport.
What SGP.32 actually requires
Component
Where it lives
Who provides it
eUICC with SGP.32 OS
The eSIM/SIM itself
eSIM vendor (Kigen, Thales, IDEMIA, G+D…)
IPAd(IoT Profile Assistant, device variant)
Application processor — your Zephyr app
You / a third-party SDK
eIM
Cloud
Connectivity provider
IPAd is just an application. It needs two things from the nRF9151:
An APDU pipe to the eUICC— to open a logical channel,SELECTthe ISD-R AID (A0000005591010FFFFFFFF8900000100), and drive ES10a/b/c.
An IP data path— plain HTTPS to the SM-DP+ (ES9+) and eIM (ES11/ES10b). SGP.32 deliberately dropped the BIP/CAT-TP requirement that made SGP.02 painful, so this is ordinary TLS over the LTE-M/NB-IoT data connection. The nRF9151 obviously does that fine.
