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

Question

来自 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. 如果一次发送一个命令 TLV，SMSR 是否合规？ （这种方式 SMSR 不会利用 eUICC 的功能，但无论 eUICC 的功能如何，此算法都适用于任何合规的 eUICC。）

Answer 1

SM-SR：

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

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

SM-DP：

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

2. 是的，很可能，但就像上面提到的那样，像 CAT_TP 或 HTTPS 这样的流协议不存在 SMS 的问题。