SGP.32-11

有任何关于GSMA\IOT\eSIM\RSP\业务应用场景相关的问题，欢迎+W:  xiangcunge59  一起讨论, 共同进步 (加的时候请注明:  来自CSDN-iot).

3.6 Error handling within an RSP session
 

在文档的第3.6节中，描述了在RSP（远程SIM卡配置）会话中的错误处理机制。以下是该部分的主要内容概述：

**3.6 RSP会话内的错误处理**

- **RSP会话**：包含在一段时间内SM-DP+（订阅管理数据准备服务器）、IPA（IoT配置文件助理）、eUICC（嵌入式通用集成电路卡）和/或eIM（eSIM IoT远程管理器）之间的一系列操作。

- **错误报告**：除了ES9+、ES9+'、ES10和/或ESipa功能报告的错误外，其他条件也可能影响程序的成功执行。IPA应向外部实体（例如设备管理平台）指示此类故障，但这些错误具体呈现方式不在本文档范围内。

- **RSP会话的启动**：IPA在有活动RSP会话时不应启动新的RSP会话。如果发生这种情况，eUICC应丢弃其会话状态，但未使用的一次性密钥可能存储以供将来重试使用，当使用"ES10b.GetEUICCChallenge"启动新的RSP会话时。

- **会话状态的丢弃**：如果在RSP会话期间成功处理了eUICC内存重置或eUICC测试内存重置，eUICC应丢弃其会话状态。

- **RSP会话失败**：RSP会话可能因为IPA和RSP服务器之间或IPA和eIM之间的通信故障而失败。IPA可以在一段时间内重试失败的RSP会话。当所有重试尝试失败时，IPA应重置自己的会话状态。

- **其他失败原因**：IPA在调用ES10函数时，RSP会话可能因eUICC报告的错误状态以外的原因失败。这些失败的例子包括：
  - 在可移动eUICC卡的情况下，卡意外被移除。
  - IoT设备因电池耗尽或用户操作而关闭电源。
  - 软件故障可能导致IPA、宿主IoT设备和/或基带处理器崩溃。

- **错误指示**：如果可能（例如，当电源恢复时），IPA应向外部实体（例如设备管理平台）提供适当的错误指示，并可能重新启动相关程序。此类错误通知的具体呈现方式不在本文档范围内。

这一节的内容强调了在RSP会话期间可能出现的各种错误情况，以及如何通过IPA进行错误处理和状态重置，以确保eUICC配置过程的稳定性和可靠性。

3.7 Notification Delivery to Notification Receivers
 

在文档的“通知传递给通知接收者”过程中，描述了如何将通知传递给已安装配置文件或执行了配置文件状态管理操作（PSMO）的eUICC（嵌入式通用集成电路卡）生成的一个或多个通知的接收者。以下是该过程的主要内容概述：

**开始条件**：
- 在eIM（eSIM IoT远程管理器）和IPAd（IoT配置文件助理在IoT设备中）之间建立了安全连接。
- 已执行配置文件安装或PSMO，因此eUICC可能已生成一个或多个通知。
- IPAd配置为使用ES9+.HandleNotification或ESipa.HandleNotification发送通知。

**程序**：
1. IPAd应调用ES10b.RetrieveNotificationsList函数检索待处理的通知。
2. 如果待处理的通知列表不为空，IPAd应将待处理的通知传递给通知接收者：
   a. 如果使用直接的ES9+接口向SM-DP+（订阅管理数据准备服务器）传递通知，IPAd应使用ES9+.HandleNotification函数发送通知，如SGP.22 [4]第5.6.4节所述。
   b. 如果通过eIM向SM-DP+传递通知，IPAd应使用本文档第5.14.7节所述的ESipa.HandleNotification函数将通知发送给eIM，然后eIM应使用本文档第5.7.4节所述的ES9+’.HandleNotification函数将通知转发给通知接收者。如果IPAd具有IPA能力minimizeEsipaBytes，则IPAd应以紧凑格式发送通知，如第5.14.7节所述。接收到紧凑格式的待处理通知的eIM应识别相关信息并构建完整的待处理通知，然后再将通知转发给通知接收者。
3. IPAd应调用ES10b.RemoveNotificationFromList（见SGP.22 [4]）来删除已收到确认的待处理通知。

这个过程确保了由eUICC生成的通知能够被正确地传递给适当的接收者，无论是直接通过SM-DP+还是通过eIM。它还涉及到在通知被成功传递和确认后，从eUICC中删除这些通知的步骤。