深度解析 3GPP TS 23.273：7.1 UDM中的LCS信息存储
本文技术原理深度参考了3GPP TS 23.273 V18.9.0 (2025-03) Release 18规范中，关于“7.1 UDM”的核心章节，特别是其中最重要的“Table 7.1-1: LCS privacy profile data stored in the UDM for a UE Subscriber”。本文旨在通过一位普通5G用户“小明”的生活需求，为您详细拆解存储在5G网络“中央档案室”——UDM——中的LCS隐私配置文件，揭示这份“数字法典”是如何精细、全面地定义了我们位置数据的“游戏规则”。
1. 序章：当位置成为一种“货币”
在5G时代，我们的地理位置，已经不仅仅是一个坐标。它是一种高价值的“数字货币”，可以用来兑换便利（地图导航）、优惠（精准营销）、安全（紧急救援），甚至是娱乐（AR游戏）。然而，任何货币都需要一个安全、可靠的“中央银行”来制定发行规则、管理流通，并保障持有者的权利。
在5G定位服务（LCS）的世界里，这个“中央银行”，就是UDM（统一数据管理）。而存储在UDM中的那份关于每个用户的LCS隐私配置文件（LCS privacy profile data），就是管理我们位置“货币”流通的最高“法典”。
For each UE subscriber the UDM stores LCS related data as part of the Subscriber Data Management (SDM) service…
这份档案，在用户办理入网时由运营商生成，并可以在后续通过用户的自主操作（6.12.1）或授权应用的请求（6.12.2）进行动态修改。它的每一个字段，都精确地定义了“谁”、“在什么条件下”、“能以何种方式”使用我们的位置信息。
今天，我们将化身UDM的“档案管理员”，逐一翻阅这份“法典”的核心条款，看看它是如何为普通用户“小明”的数字生活保驾护航的。
2. “法典”的核心：LCS隐私配置文件详解 (Table 7.1-1)
Table 7.1-1是整个第七章的灵魂。它以表格的形式，结构化地定义了UDM中存储的所有LCS相关数据。让我们逐行剖析这份“法典”的核心内容。
2.1 全局总开关：位置隐私指示 (Location Privacy Indication)
| 隐私配置文件数据类型 | 存在性 | UDM数据 (解读) |
|---|---|---|
| Location Privacy Indication | M (强制) | Indication of one of the following mutually exclusive global settings: - Location is disallowed. - Location is allowed (default). Time period when the Location Privacy Indication is valid. |
这是整部“法典”的总纲，也是最简单、最强大的条款。它是一个全局性的开关，由用户自己掌控（通过6.12.1流程设置）。
disallowed：相当于按下了“一键隐身”按钮。一旦设置，除了拥有最高权限的监管类服务（如紧急呼叫），任何商业定位请求（无论来自哪个App）都将被GMLC在第一步就直接拒绝。allowed (default)：这是默认状态，表示“可以谈”。定位请求不会被一刀切地拒绝，但具体是否放行，还需要遵守后续更精细的条款。
此外，这个“总开关”还可以绑定一个有效期，例如，“未来24小时内，我禁止所有定位”。
小明的故事：小明要去参加一个重要的私人面试，不希望被任何社交App打扰。他在手机的系统隐私设置中，开启了“全局位置服务关闭”。这个操作，就通过6.12.1流程，将他UDM档案中的Location Privacy Indication设置为了disallowed。
2.2 “陌生人”条款：非会话相关类别 (Call/session Unrelated Class)
这是“法典”中最复杂、最核心的部分，它定义了如何处理来自普通商业应用的定位请求。这些请求与用户当前的通话或数据会话没有直接关系（例如，一个后台运行的App发起的定位）。
| 隐私配置文件数据类型 | 存在性 | UDM数据 (解读) |
|---|---|---|
| Call/session Unrelated Class | M (强制) | (包含多个子类，分别定义了对“白名单外”、“白名单内”、“特定服务类型”的规则) |
这一大类，又被细分为了三个层次的规则，形成了一个“默认 → 特例 → 再特例”的精细化控制体系。
2.2.1 默认规则：如何对待“不速之客”？
For any LCS client or AF not in the external LCS client list or otherwise identified..., the following data may be present:
- One of the following mutually exclusive options:
- Location not allowed (default case)
- Location allowed with notification
- Location with notification and privacy verification...
这是针对所有未被明确识别的、非“白名单”的LCS客户端的默认策略。
not allowed (default)：默认情况下，任何“陌生”App的定位请求，都会被拒绝。这是最安全的“关门”策略。allowed with notification：允许定位，但必须先在用户手机上弹窗通知。with notification and privacy verification：不仅要通知，还必须得到用户的实时确认（点击“同意”）。
小明的故事：小明下载了一个新的天气App。当这个App首次请求位置时，由于它不在小明的任何“白名单”中，GMLC便会应用这条默认规则。如果小明的设置是not allowed，请求会被拒绝；如果是with notification，他的手机会弹窗：“天气App正在获取您的位置”，然后定位会自动执行。
2.2.2 “白名单”规则：如何对待“熟人”？
External LCS client list: a list of zero or more LCS clients, AFs and LCS Client groups with the following data for each entry:
这是对默认规则的覆盖。用户可以创建一个外部LCS客户端列表（“白名单”），为每一个特定的App或App分组（如“所有社交App”）设定专门的规则。
- 小明的故事：小明是“足迹”社交App的重度用户。他可以在App的隐私设置中，为“足迹”App单独设置一条规则：“允许（好友间的）定位，无需通知”。这条规则会被写入UDM中的这个“白名单”列表。当“足迹”App发起定位时，GMLC会优先匹配到这条特例规则，直接放行，而不会再弹窗打扰他。
2.2.3 “公务”规则：如何对待“特定服务”？
Service types list: a list of one or more service types for which the LCS client is allowed to locate the particular UE.
这是对“白名单”规则的再细化。规则不仅可以绑定到某个App，还可以绑定到某个特定的服务类型。服务类型是在TS 22.071中定义的，例如“道路救援”、“导航”等。
- 小明的故事：小明为他的汽车购买了“道路救援”保险。在签约时，他同意授权保险公司的App，在**服务类型为“道路救援”**时，可以获取他的位置。这条规则也被写入UDM。平时，这个App无法定位小明。但当小明通过App呼叫道路救援时，App发起的定位请求会带上
Service Type = "Roadside Assistance"的标志。GMLC在审查时，会匹配到这条“公务”规则，从而放行定位。
2.2.4 “附加条款”：时间和地理限制
对于上述所有规则，UDM中还可以为其配置时间和地理的“附加条款”。
- Time period when positioning is allowed.- Geographical area where positioning is allowed.
这为用户提供了终极的、情境化的控制能力。
- 小明的故事：小明入职了“TeamLink”公司，他设置的规则是：“仅在工作日9:00-18:00（时间限制），且我在公司科技园区内时（地理限制），允许‘TeamLink’App定位我。”
2.3 “内部人员”条款：PLMN运营商品类别 (PLMN Operator Class)
| 隐私配置文件数据类型 | 存在性 | UDM数据 (解读) |
|---|---|---|
| PLMN Operator Class | O (可选) | LCS client list: a list of one or more generic classes of LCS client that are allowed to locate the particular UE. ... O&M LCS client ..., NWDAF... |
这一条款定义了如何处理来自运营商内部的定位请求。这些请求的发起方不是外部App，而是运营商自己的运维（O&M）系统、网络分析功能（NWDAF）等。通常，这些定位是为了网络优化、故障排查、大数据分析等目的，一般是匿名的。用户可以设置是否允许这类“内部人员”为特定目的使用自己的（通常是匿名的）位置数据。
2.4 “高速公路”条款：用户面连接 (User Plane Connection…)
| 隐私配置文件数据类型 | 存在性 | UDM数据 (解读) |
|---|---|---|
| User Plane Connection… | O (可选) | Indication of one of the following mutually exclusive global settings:- UE is allowed to report ... via user plane...- UE is not allowed to report ... via user plane (default). |
这是我们在6.16章节分析过的用户面定位的“总开关”。它定义了该用户是否被签约允许使用这条“定位高速公路”。默认是不允许。只有当用户（如专业的电竞选手）购买了需要超低时延定位的业务包后，运营商才会在他的UDM档案中，将这个开关打开。
3. 总结：一部精密的、可演进的“隐私法典”
通过对UDM中LCS隐私配置文件的逐条“研读”，我们可以深刻地感受到3GPP在设计5G隐私框架时的深思熟虑。这份“法典”不再是简单的“允许/拒绝”二元论，而是一部多层次、情境化、可动态演进的精密规则体系。
- 分层治理：通过“全局开关 → 默认规则 → 白名单特例 → 服务特例”的层层递进，实现了从宏观到微观的精细化控制。
- 多维控制：将身份（我是谁）、时间（何时）、空间（何地）、目的（为何）四大维度完美地融合进了隐私策略中，赋予了用户前所未有的自主权。
- 面向未来：通过预留
PLMN Operator Class和User Plane Connection等条款，为网络自身的智能化演进（NWDAF）和新兴业务形态（用户面定位）的发展，奠定了坚实的、可管理的隐私基石。
这份存储在UDM深处的数字档案，看似遥远，却与我们每个人的数字生活息息相关。它在无形之中，为我们在享受5G定位服务带来的无限便利的同时，构筑起了一道坚不可摧的个人数据“防火墙”。
FAQ - 常见问题解答
Q1：UDM中存储的这些隐私设置，和我手机操作系统（iOS/Android）里的隐私设置是什么关系？ A1：可以理解为OS的设置是UDM设置的“用户界面（UI）”和“触发器”。当你在OS中为某个App设置定位权限时，OS会通过6.12.1流程，将你的选择（如“始终允许”、“使用期间允许”）转换为UDM能理解的策略，并更新到UDM中。同时，OS自身的隐私控制（例如，App是否在前台运行）也会作为一道本地的、额外的防线。一个定位请求，通常需要同时通过OS和UDM两道“安检”，才能最终执行。
Q2：这个“Call/session Unrelated Class”的名字很拗口，为什么不直接叫“商业应用类别”？ A2：这个命名体现了3GPP标准的严谨性。因为还存在一个“Call/session Related Class”（在本规范中未被支持，但在EPS中有类似概念）。后者的意思是，定位请求与一个正在进行的会话（如一次VoLTE通话）强相关。例如，你用地图App导航时，App为了省电，可能会请求网络：“当用户下一次打电话时，‘顺便’帮我获取一下他的位置。” 这种与已有会话“捆绑”的定位，就是Related Class。而Unrelated Class则泛指所有与当前会话无关的、独立的定位请求，这覆盖了绝大部分商业应用场景。
Q3：我如何查看和修改我自己在运营商UDM中的LCS隐私档案？ A3：直接查看UDM的原始数据对普通用户是不可能的。但运营商有义务为用户提供修改隐私设置的渠道。这些渠道通常包括：1) 手机操作系统的隐私设置菜单（最常用）。2) 运营商的官方营业App或网上营业厅，通常会有专门的隐私授权管理页面。3) 客服热线或线下营业厅。
Q4：这份“隐私法典”是全球统一的吗？
A4：技术框架是全球统一的，由3GPP标准化。Table 7.1-1中定义的这些字段和选项，对于所有遵循3GPP标准的5G网络都是通用的。但是，默认设置以及法律法规的约束，则因国家和地区而异。例如，欧盟的GDPR对用户数据的获取和使用有着极其严格的规定，运营商在配置UDM的默认策略时，必须遵守这些法规，通常会采用更严格的“默认拒绝”或“必须明示同意”的原则。
Q5：如果一个黑客App伪装成一个合法的LCS客户端，能绕过UDM的审查吗？ A5：极难。因为LCS客户端（AF）接入运营商网络，必须经过NEF或GMLC的严格认证。这不仅仅是简单的用户名密码，而是一套基于证书、加密和网络安全协议的复杂认证流程。此外，GMLC还会记录每一次定位请求的来源。一旦发现滥用，可以立即吊销该AF的接入权限，并进行追溯。UDM的隐私审查，是建立在GMLC/NEF这道坚固的“防火墙”之上的。