好的，我们继续接续上一篇文章，对 3GPP TS 31.102 规范进行深度拆解。
深度解析 3GPP TS 31.102：4.2.10 EFGID1 & 4.2.11 EFGID2 (群组标识符)
本文技术原理深度参考了3GPP TS 31.102 V18.8.0 (2025-03) Release 18规范中，关于“4.2.10 EFGID1 (Group Identifier Level 1)”和“4.2.11 EFGID2 (Group Identifier Level 2)”的核心章节，旨在为读者阐明这两个看似神秘的文件在特定应用场景下，是如何实现USIM卡群组化管理的。
在之前的章节中，我们已经探索了USIM中关于身份、安全、服务能力和网络选择的核心文件。这些文件共同为单个用户（如我们的主角“李想”）构建了一个完整的数字身份模型。然而，在许多行业应用和企业管理场景中，仅仅对用户进行个体管理是不够的，还需要引入“群组”的概念。
例如，一个大型企业可能希望将其员工分为不同的群组：“管理层”、“销售部”、“研发部”，并为不同群组的用户配置不同的通信策略（如不同的通话权限、数据套餐或专网访问权限）。或者，在一个公共安全网络中，需要将应急人员分为“消防队”、“医疗队”、“警察”等不同的小组。
为了满足这种群组化管理的需求，USIM规范中预留了EFGID1和EFGID2这两个文件。它们的名字非常直白：Group IDentifier（群组标识符）。这两个文件的作用就像是为李想的USIM卡贴上一个或多个“团队标签”，使得网络或应用能够快速识别他所属的群体，并据此应用相应的策略。
今天，我们将一起揭开这两个文件的面纱，理解它们为何存在，以及它们是如何通过简单的标识符来实现复杂的群组管理的。
1. “贴标签”的艺术：GID文件的核心价值
EFGID1和EFGID2的核心使命非常纯粹：存储一个或多个代表用户所属群组的标识符。
If service n° 17 is “available”, this file [EFGID1] shall be present.
This EF contains identifiers for particular USIM-ME associations. It can be used to identify a group of USIMs for a particular application.
If service n° 18 is “available”, this file [EFGID2] shall be present.
… (描述与EFGID1类似)
从规范的原文中，我们可以提炼出以下关键点：
-
服务关联:
EFGID1与USIM服务表（EF_UST）中的服务n°17关联，而EFGID2与服务n°18关联。这意味着群组标识符功能是可选的，只有在运营商需要时才会开通。 -
群组识别: 这两个文件的根本目的是 识别一个USIM群体 (identify a group of USIMs)。网络侧或终端上的特定应用可以通过读取这两个文件中的ID，来判断当前用户是否属于某个特定的群组。
-
应用驱动: 其用途是 为特定应用 (for a particular application) 服务。这表明GID通常不是给通用通信（如普通公众通话）使用的，而是为需要群组区分的垂直行业应用、企业解决方案或特定的增值业务设计的。
-
双层级别 (Level 1 & Level 2): 规范定义了两个独立的GID文件，
GID1和GID2。这提供了一种双层的、可嵌套的群组管理能力。
NOTE: The structure of EFGID1 and EFGID2 is identical. They are provided to allow the network operator to enforce different levels of security dependant on an application.
规范的这个NOTE画龙点睛地指出了设置两个级别的原因：允许运营商根据应用的不同，实施不同级别的安全策略。
场景化举例：
假设李想毕业后加入了一家大型跨国公司“智联科技”。公司为所有员工办理了企业集团号，并使用了USIM的群组管理功能。
-
EFGID1可能被用来存储李想的部门归属。例如，公司为“研发部”分配了群组ID'R&D-001'。李想的EFGID1文件中就存储了这个值。 -
EFGID2可能被用来存储李想的项目归属或安全级别。例如，李想参与了一个名为“猎户座”的高度机密项目，该项目的群组ID为'ORION-SECRET'。那么，这个值就会被存入他的EFGID2文件。
当李想使用公司内网APP时：
-
APP首先读取
EFGID1，发现群组ID为'R&D-001'。APP据此判断李想是研发部员工，于是为他展示了研发部门内部的公告和文档库。 -
当李想尝试访问“猎户座项目”的专属资料时，APP会进一步检查
EFGID2。发现群组ID为'ORION-SECRET'后，验证通过，允许访问。而另一位同在研发部但未参与该项目的同事，其EFGID2文件为空或值不同，则会被拒绝访问。
这种双层标签机制，为企业实现精细化的移动化权限管理提供了极大的便利。
2. 简洁而强大：GID文件的结构与编码
EFGID1和EFGID2在结构上完全相同，都采用了最简洁的设计，以实现最大的灵活性。
2.1 文件结构
表 4.2.10-1 & 4.2.11-1: EFGID1/EFGID2 文件结构
| 属性 | 值 |
| :--- | :--- |
| Identifier | ‘6F3E’ (GID1) / ‘6F3F’ (GID2) |
| Structure | Transparent |
| File size | n bytes |
| Update activity | Low |
| Access Conditions | READ: PIN, UPDATE/DEACTIVATE/ACTIVATE: ADM |
字节内容
| 字节 | 描述 | M/O | 长度 |
| :--- | :--- | :--- | :--- |
| 1 to n | USIM group identifier(s) (USIM群组标识符) | O | n bytes |
逐项解读：
-
Structure: Transparent（透明文件）。这是一个非常关键的选择。规范没有预定义GID的格式、长度或数量。设计成透明文件，意味着运营商可以根据自己的应用需求，自由地定义这
n个字节的内容。可以是一个简单的ASCII字符串，可以是一个二进制编码的数字，也可以是多个标识符的拼接，甚至是一个TLV（Tag-Length-Value）结构。这种设计的灵活性极高。 -
File size:
n bytes（可变长度）。运营商可以根据需要存储的群组ID的复杂程度，来决定这个文件的大小。 -
Access Conditions:
-
READ权限为PIN，意味着终端应用需要用户解锁USIM后，才能获取其群组信息，保护了用户的群组归属隐私。 -
UPDATE权限为ADM，用户的群组身份是由企业或运营商权威分配的，用户和手机不能自行修改。当李想从研发部调到销售部时，公司IT部门会通过OTA后台命令，更新他USIM卡中的EFGID1文件。
-
2.2 编码的开放性
规范对EFGID1/EFGID2的内容编码没有做任何硬性规定。这种开放性是它强大之处，但也对使用者提出了要求：定义GID格式和解析规则的责任，落在了使用这个功能的应用生态（运营商、企业、应用开发者）身上。
他们必须共同商定一套私有的编码规范。例如，“智联科技”可能会定义如下规则：
-
GID为ASCII字符串。
-
EFGID1中存储格式为[部门代码]-[员工等级]，如'RD-L7'。 -
EFGID2中可以存储多个项目组ID，以分号;隔开，如'ORION;PEGASUS'。
李想手机上的“智联科技”企业应用，就必须内置对这套私有规则的解析逻辑，才能正确地从文件中提取出群组信息。
这种设计哲学是：3GPP提供一个标准化的、安全的“容器”（EF文件），而容器里装什么“货物”（数据格式），则由应用方根据场景自行决定。
3. GID的应用场景与价值延伸
虽然EFGID1和EFGID2不是公众用户常用的功能，但它们在垂直行业和企业应用中具有不可估量的价值。
-
企业移动管理 (EMM): 如前所述，用于实现基于部门、级别、项目的移动应用访问控制、策略下发（如VPN配置、数据漫游限制）。
-
公共安全与关键任务通信 (MCPTT/MCData): 在MCPTT（Mission Critical Push-to-Talk）等场景下，GID可以用来标识用户的归属群组（如某消防支队），终端据此自动加入相应的通话组，实现高效的指挥调度。
-
物联网 (IoT) 设备分组: 大量的物联网终端可以被分组管理。例如，属于“智能电表”群组的设备，网络可以对其应用特定的低功耗策略和数据上报计划；属于“车载监控”群组的设备，则可能被赋予更高的网络优先级。
-
虚拟专网 (VPN/VPDN): 企业可以根据GID，为不同群组的用户自动分配不同的APN，将其接入到不同的企业内网或VLAN中，实现网络层面的安全隔离。
EFGID1和EFGID2就像是为海量的USIM卡提供了一个GROUP BY的能力，使得从“管理个体”到“治理群体”的跨越成为可能。
总结：从个体身份到群体画像的钥匙
EFGID1和EFGID2虽然在规范中着墨不多，结构也极为简单，但它们的设计理念却非常深远。它们是USIM从一个单纯的个人身份模块，向一个能够承载丰富社会属性和组织属性的“身份档案”演进的重要一步。
-
简洁性与灵活性: 通过采用最简单的透明文件结构，规范将数据格式的定义权交给了应用，最大限度地适应了未来各种不可预知的群组管理需求。
-
分级管理: 提供Level 1和Level 2两个独立的文件，为构建多维度的、可嵌套的群组管理体系提供了基础，满足了复杂组织架构的需求。
-
安全可控: 严格的ADM更新权限和PIN读取权限，确保了群组身份的权威性和用户隐私的安全性。
对于李想而言，当他还是一个普通公众用户时，他USIM里的EFGID1和EFGID2可能一直是空的。但当他步入职场，成为“智联科技”的一员，这两个文件就被赋予了内容。他的USIM卡不再仅仅代表“李想”这个自然人，更承载了他作为“研发部工程师”、“猎户座项目成员”的职业角色。这张小小的卡片，通过EFGID1和EFGID2，完成了从个体身份到群体画像的延伸。
FAQ环节
Q1：EFGID1和EFGID2有什么本质区别？为什么不直接用一个文件存储所有群组ID？
A1：本质上，这两个文件在结构和编码上没有区别，它们都是存储群组标识的“容器”。规范之所以提供两个独立的文件，是为了逻辑上的分层。这允许运营商或企业将不同性质、不同安全等级的群组信息分离开。例如，EFGID1可以用于定义一个相对稳定、公开的组织归属（如部门），而EFGID2可以用于定义一个动态的、更私密的项目归属或权限级别。这种分层为应用实现更复杂的、多维度的权限控制逻辑提供了便利。如果只用一个文件，所有ID混在一起，应用就需要更复杂的内部逻辑来区分它们的类型和含义。
Q2：我的个人手机SIM卡里有EFGID1和EFGID2这两个文件吗？
A2：大概率是空的，甚至可能这两个文件对应的服务（n°17和n°18）都未在EF_UST中激活。GID功能主要面向企业、政府和行业用户，对于普通的公众移动用户，运营商很少有必要为其配置群组信息。所以，除非你使用的是企业定制的集团卡或特定行业的专用卡，否则这两个文件通常处于未使用状态。
Q3：既然GID的编码格式是自定义的，那不同公司的应用能互相识别对方的GID吗？
A3：不能。这正是GID设计的特点。它的互操作性是生态系统内部的，而不是全球通用的。例如，“智联科技”定义了一套GID格式，那么只有“智联科技”自己开发或授权的应用，才需要知道如何去解析这套格式。另一家公司“未来通信”可以定义一套完全不同的GID格式用于自己的员工管理。这种“各自定义”的方式保证了企业内部信息的私密性，同时也赋予了最大的灵活性。
Q4：GID信息在网络认证（AKA）过程中起作用吗？
A4：在核心的AKA认证流程中不起作用。AKA认证只关心用户的根本身份（基于IMSI/SUPI和根密钥K），以确认用户的合法性。GID是在认证成功、安全上下文建立之后，由上层应用（手机APP或网络侧的业务平台）读取并用于业务逻辑判断的。可以理解为，AKA是“验明正身”，确认“你是李想”；而读取GID是“核对角色”，确认“你是研发部的李想”，这是两个不同层面、不同阶段的操作。
Q.5：EFGID1和EFGID2与5G网络切片中的EFURSP有什么关系？
A5：这是一个很好的问题，体现了不同功能之间的潜在关联。EFGID1/EFGID2和EFURSP可以协同工作，实现更智能的策略控制。例如，运营商可以为“智联科技”的EFGID1为'R&D-001'的用户，下发一套特定的URSP规则，规定他们在使用公司内部应用时，自动通过企业专属的网络切片。而对于EFGID1为空的普通用户，则使用另一套默认的URSP规则。这样，通过结合GID的“用户画像”和URSP的“路由策略”，网络可以实现高度定制化和差异化的服务。