哪些 eUICC 功能以及 SMSR 应如何用于分割 SCP03t 脚本？

如何解决哪些 eUICC 功能以及 SMSR 应如何用于分割 SCP03t 脚本？

来自 SGP.02-v4.2 的第 5.4.4 节：

SM-SR 负责构建最终的命令脚本，具体取决于 eUICC 功能和所选协议

很明显，在某些情况下，SM-SR 应该拆分它在 ES3.SendData 的数据字段中收到的命令脚本。 SGP.11-v4.0 中的示例支持这一点：比较第 408 页上的步骤 14，其中在 #PROFILE_PACKAGE 中传递了完整的配置文件包 ES3.SendData。第 211-212 页的步骤 3、5 和 7，其中 #PROFILE_PARTi 形式的段通过 ES5 发送。

首先不清楚是什么因素限制了将整个命令脚本发送到 eUICC 的能力。这个问题很重要，因为它的答案很可能会回答最重要的问题：SMSR 究竟如何决定（如它考虑哪些参数）如何拆分命令脚本。

我知道 EUICC-CAPABILITIES，但他们只指定了支持哪些传输/算法/功能。它们没有给出由 SMSR 构建的命令脚本的单个段（即 #PROFILE_PARTi）可以有多大的任何提示。此外，规范似乎将 eUICC capabilities 与 selected protocol 区分开来，这是另一个让我认为 5.4.4 中提到的功能与 EUICC-CAPABILITIES 不同的因素。

SGP.11-v4.0 表明即使对于 CAT_TP 或 HTTPS 也应该使用分段，并且 SMSR 需要以某种方式决定如何拆分它收到的命令脚本。

所以问题：

1. SMSR 应考虑哪些 eUICC 功能？
2. SMSR 究竟应该如何使用这些功能来决定它可以使用的脚本段（如 #PROFILE_PARTi）的大小？
3. SMSR 如何为给定的 eUICC 检索这些功能？
4. 是否可以通过某些 GP 规范中定义的方式或特定于该制造商的方式检索它们？

根据 SGP.02-v4.2 的 4.1.3.3 节，eUICC 应支持至少 1024 字节（包括标签和长度字段）的配置文件命令数据段。这是否意味着：

1. SMDP 永远不会创建代码“86”超过 1024 字节的配置文件命令数据 TLV？
2. 如果 SMSR 一次发送一个命令 TLV，它是否合规？ （这样，SMSR 就不会利用 eUICC 的功能，但无论 eUICC 的功能如何，该算法都适用于任何兼容的 eUICC。）

解决方法

SM-SR：

1. 查看“EUICC-CAPABILITIES”部分。 5.1.1.2.10 支持的传输功能。对于您的实施，例如支持的缓冲区大小也可能有助于发送尽可能少的串联 SMS 或具有更好的 TCP 有效负载大小。这必须通过读取 EID 来隐含地知道，并通过解释模型和制造商来知道 eUICC 的特性。不确定 yome eUICC 在这里提供的是否超过最低要求。

2.+3.+4。在注册 eUICC 时存储 EIS。 （SM-SR 可以将它放在数据库中）。这包含 EUICC 功能。

SM-DP：

1. 是的。包括标签和长度、MAC 和填充。配置文件包被切成 1020 字节的块，然后加上 86 标签和 3 字节长度作为前缀。

2. 是的，很有可能，但如上所述，像 CAT_TP 或 HTTPS 这样的流媒体协议没有 SMS 的问题。