CN108886520A - 建立会话发起协议会话 - Google Patents

Abstract

本公开描述了用于建立会话发起协议会话的方法和系统。一种方法包括发送请求认证配置信息的第一消息；响应于第一消息，接收包括认证配置信息的第二消息；基于所接收的认证配置信息发送包括认证信息的第三消息；接收根据第二协议格式化的认证挑战请求；以及响应于接收认证挑战请求，向第二网络节点发送认证响应。

Description

建立会话发起协议会话

相关申请的交叉引用

本申请要求于2016年1月25日提交的美国申请No.62/286,739和作为于2015年6月30日提交的美国申请No.14/788,099的继续申请的于2016年8月25日提交的美国申请No.15/247,065的优先权，这两个申请都通过引用整体明确地并入本文中。

技术领域

本公开涉及一种互联网协议(IP)多媒体子系统(IMS)，并且特别涉及IMS网络中标识的验证。

背景技术

IP多媒体子系统是一种以标准化方式向移动设备提供分组数据的架构框架。这种IMS网络允许通过分组系统而不是电路交换系统进行语音呼叫。它允许其它功能，比如一键通(PTT)，特别是用于现场急救人员的关键任务一键通(MCPTT)。

IMS认证对在IMS网络上使用的专用标识符和公共标识符进行认证。然而，IMS认证不允许不同的单个IMS公共用户标识分别与相同或不同的IMS专用用户标识一起被认证。这可能导致在各种情况下的问题。例如，如果现场急救人员使用MCPTT应用，则该MCPTT应用可能需要通过与设备的专用标识所绑定的公共标识不同的公共标识来对该设备进行认证。

附图说明

参考附图将更好地理解本公开，在附图中：

图1是示例IMS网络的框图；

图2是示出了IMS订户的认证的数据流程图；

图3是示出了IMS系统中的专用用户标识和公共用户标识之间的关联的框图；

图4是示出了包括各种网元的公共安全运营商和公共安全UE之间的信令的框图；

图5A是用于EAP认证的协议栈的框图；

图5B是当EAP是用户认证协议时的协议栈的框图；

图6是示出了提供用于双重认证的指示的第一带内实施例的数据流程图；

图7是在认证中使用第二公共用户标识的备选带内实施例的数据流程图；

图8是示出了基于公共用户标识符的密钥操作(keying)的带内实施例的数据流程图；

图9是示出了针对HSS和UE中的密钥产生的处理的框图；

图10是在向运营商隐藏公共用户PIN的网元处的密钥产生处理的框图；

图11是在向运营商隐藏公共用户PIN的用户设备处的密钥产生处理的框图；

图12是示出了用于IMS认证的带外实施例的数据流程图；

图13是示出了带外认证处理的框图；

图14是示出了使用不同的公共用户标识进行认证的带外实施例的数据流程图；

图15是示出了UE可以漫游到第二MCPTT网络中的带外实施例的数据流程图；

图16是示出了MCPTT数据的示例数据结构的框图；

图17是示出了使用证书的认证的数据流程图；

图18是示出了证书的产生的框图；

图19是示例网元的简化框图；以及

图20是与本公开的实施例一起使用的示例用户设备的框图。

图21是示出了根据实现的示例MCPTT系统的应用层架构的示意图。

图22是示出了根据实现的用于MCPTT用户认证的示例呼叫流程的流程图。

图23示出了根据实现的用于加密和解密的示例框架。

图24A至图24B是示出了根据实现的用于MCPTT呼叫的示例呼叫流程的流程图。

图25示出了根据实现的用于获得令牌的示例处理。

图26示出了根据实现的用于获得令牌的示例代码。

图27至图32示出了使用3GPP Sh接口的示例实现。

图33至图34示出了根据实现的示例消息。

图35示出了根据实现的示例联系人列表(contact list)。

具体实施方式

本公开提供了一种用户设备处的用于使用互联网协议(IP)多媒体子系统(IMS)向第三网络节点进行注册的方法，所述方法包括：创建用户设备和第一网络节点之间的隧道；向第一网络节点认证与用户设备相关联的第一公共标识；从第一网络节点接收具有第二专用用户标识符和第二公共用户标识符的配置信息，第二专用用户标识符和第二公共用户标识符与第二网络节点相关联；以及使用第二专用用户标识符和第二公共用户标识符向第三网络节点进行注册。

本公开还提供了一种用户设备，被配置用于使用互联网协议(IP)多媒体子系统(IMS)向第三网络节点进行注册，用户设备包括：处理器；以及通信子系统，其中，用户设备被配置为：创建用户设备和第一网络节点之间的隧道；向第一网络节点认证与用户设备相关联的第一公共标识；从第一网络节点接收具有第二专用用户标识符和第二公共用户标识符的配置信息，第二专用用户标识符和第二公共用户标识符与第二网络节点相关联；以及使用第二专用用户标识符和第二公共用户标识符向第三网络节点进行注册。

本公开还提供了一种在第一网络节点处的被配置用于使用互联网协议(IP)多媒体子系统(IMS)在用户设备和第三网络节点之间进行认证的方法，所述方法包括：与用户设备建立隧道；在第一网络节点处认证用户设备的第一公共标识；从用户设备接收配置信息消息，配置信息消息包括其上注册了所述用户设备的网络的网络标识符；从第二网络节点获得第二专用用户标识符和第二公共用户标识符；以及向用户设备提供第二专用用户标识符和第二公共用户标识符。

本公开还提供了一种被配置用于使用互联网协议(IP)多媒体子系统(IMS)在用户设备和第三网络节点之间进行认证的第一网络节点，第一网络节点包括：处理器；以及通信子系统，其中，第一网络节点被配置为：与用户设备建立隧道；在第一网络节点处认证用户设备的第一公共标识；从用户设备接收配置信息消息，配置信息消息包括其上注册了所述用户设备的网络的网络标识符；从第二网络节点获得第二专用用户标识符和第二公共用户标识符；以及向用户设备提供第二专用用户标识符和第二公共用户标识符。

本公开总体上涉及IMS系统中的认证。在这种认证的一个方面，以下讨论IMS系统关于MCPTT的使用。然而，这不是IMS网络的唯一用途，IMS认证可以同等地用于分离的或不同的应用。因此下面MCPTT的使用只是为了说明。

关于MCPTT说明了IMS认证的缺陷的一个示例。例如，MCPTT由现场急救人员来使用，并且具有各种要求。这些要求可包括但不限于任何用户都应该能够拿起任何设备并使用它。因此，如果消防站有许多未被个别指派而是根据需要提供给用户的设备，那么任何消防员都应该能够拿起任何可用的设备并使用这些设备。

为了满足公共安全服务提供商和公共安全用户的安全要求，MCPTT还可以要求设备上的MCPTT应用的认证需要独立于蜂窝/IMS网络。

在第三方面，MCPTT可能需要能够隐藏或隐蔽正在使用设备的用户的标识或角色。例如，在现场急救人员是警察的情况下，在一些情况下，当使用MCPTT应用时，可能希望保护该警察的标识的保密性。隐蔽可能需要包括向运营商或网络运营商隐蔽真实公共标识。

鉴于上述三个方面以及如下所述的IMS认证工作的方式，IMS认证没有提供与MCPTT的兼容功能。具体地，当前的IMS认证方法基于IMS专用用户标识，不允许不同的个体IMS公有用户标识分别与相同或不同的IMS专用用户标识一起被认证。因此，例如，如果第一用户和第二用户以非并发方式使用相同的移动设备，则系统不能区分用户是谁，且因此不能以不同的方式认证这两个用户，并且不能在拒绝一个接入的同时授权其它接入。因此，本公开提供了一种用于对设备和用户两者进行认证然后提供是否应该允许用户使用设备的确定的方法和系统。

如本文所使用的，术语“专用标识符”和“专用用户标识符”可以互换使用。

根据以下公开，提供了对上述问题的各种解决方案。特别地，本公开描述了各种带内解决方案，其使用当前IMS认证消息传递来捎带(piggy back)单独的公共标识验证。下面描述的其他解决方案包括带外解决方案，其利用常规IMS认证之外的消息传递来验证公共标识。此外，提供了基于公共用户标识的各种密钥操作，其可以在下面描述的带内或带外信令解决方案中使用。本领域的技术人员将会理解，基于公共用户标识的带内/带外和密钥方案可以以多种方式进行组合以产生另外的实施例。

在下面描述的实施例的一个方面中，特定用户的用户标识可以在系统中被隐蔽，并且提供了用于隐蔽公共标识的各种解决方案。

现在参考图1，图1示出了附接到第四代(4G)网络的示例IMS网络的概况。图1的示例仅仅意在说明网络架构内的各种组件。图1的实施例不是限制性的，并且在大多数情况下，真实的网络将具有该组件中的部分或全部以及附加的组件。

此外，如下所述，每个要素可以被认为是逻辑块。也就是说，要素的功能可以组合到一个服务器中。此外，单个要素的功能可以被分割到多个物理服务器上，并且本公开不限于使用任何特定的物理架构。

在图1的示例中，第四代(4G)网络110可以利用IMS网络130来提供标准化分组数据通信。特别地，4G网络110可以是其中设备112或设备114可以进行通信的第三代(3G)长期演进(LTE)或系统架构演进(SAE)网络。设备112和114可以是能够通过蜂窝网络进行通信的任何设备，并且可以包括例如用户设备(UE)、移动设备、智能电话、膝上型电脑、平板电脑或者任何其它能够进行数据传送的设备。

设备112使用正交频分复用(OFDM)，通过LTE-Uu接口与演进节点B(eNB)116通信。

类似地，设备114通过LTE-Uu接口与eNB 118通信。

eNB 116和118中的每一个与两个实体(即，服务网关120和移动性管理实体(MME)122)通信。MME 122负责空闲模式的UE寻呼，并且还负责在UE进入连接模式时选择服务网关120。

服务网关120路由并转发来自设备112和114的分组。

服务网关120与SAE锚点124通信。SAE锚点124是锚定用户平面以用于第三代合作伙伴计划(3GPP)接入层与非3GPP接入层之间的移动性的功能实体，非3GPP接入层用于诸如电气和电子工程师协会(IEEE)802.11(Wi-Fi)的系统以及其它非3GPP接入系统。

MME 122与3GPP锚点126通信。3GPP锚点126是锚定用户平面以用于第二代和第三代接入层与LTE接入系统之间的移动性的功能实体。

IMS网络130可以通过各种逻辑实体与4G网络110进行通信。在第一方面，MME 122可以与归属订户服务器(HSS)132进行通信。HSS 132是数据库，其包含订户的简档，并且提供位置功能以及认证数据库，其中简档包括标识和他们已经订阅的服务。

MME 122还可以与策略和计费规则功能(PCRF)服务器134进行通信。PCRF 134是IMS网络内的要素，其控制订户的策略以及向这些订户收取的金额两者。

PCRF 134和HSS 132以及3GPP锚点126可以与IMS网络130的呼叫服务器控制功能(CSCF)136通信。CSCF 136提供用于处理IMS网络130中的SIP信令分组的若干个会话发起协议(SIP)服务器或代理。

特别地，CSCF 136可以包括各种逻辑实体，该各种逻辑实体包括作为进入IMS网络的第一入口点的代理呼叫会话控制功能(P-CSCF)。此外，服务呼叫会话控制功能(S-CSCF)处理网络中的会话，并将SIP消息路由到适当的P-CSCF以及IMS应用服务器(IMS AS)。此外，CSCF 136可以包括用作查找网络中的订户的入口点的询问呼叫会话控制功能(I-CSCF)，并且当订户在网络中注册时辅助指派S-CSCF。

IMS应用服务器(AS)138是具有针对IMS订户来执行服务的逻辑和软件的应用服务器。IMS网络130中具有的这样IMS AS 138的数量可以介于0和许多之间。CSCF 136可以向IP语音服务(VOIP)提供输出，如图1的示例中所示的那样。

CSCF 136还可以与提供媒体相关功能(例如媒体操纵)的媒体资源功能(MRF)140进行通信。MRF 140还可以连接到媒体服务器142。

CSCF 136可以与中断网关控制功能(BGCF)144连接，BGCF 144允许在域名服务器(DNS)路由不能使用时处理来自S-CSCF的SIP请求。

CSCF 136和BGCF 144都可以与媒体网关控制功能(MGCF)146通信，MGCF 146与IMS媒体网关(IMS MG)148通信以允许接入电路交换域。

此外，MGCF 146可以与信令网关(SG)150通信，SG 150也可以允许与电路交换域通信。

在某些情况下，除了4G网络110之外，可以使用3G网络或3.5G网络160。在这种情况下，设备162或164可以通过Uu接口使用高速分组接入(HSPA)分别与节点B166和节点B 168进行通信。

节点B 166和168两者都与无线电网络控制(RNC)170通信，RNC 170控制连接到RNC170的节点B。

RNC 170与服务通用分组无线电服务(GPRS)支持节点(SGSN)172通信，SGSN 172负责传送去往和来自在SGSN 172的地理位置中的移动台的分组。RNC 170还与移动交换中心(MSC)174通信，MSC 174控制网络交换要素。

SGSN 172可以连接到网关GPRS支持节点(GGSN)176。SGSN 172还与4G网络中的MME122和服务网关120通信，以用于在4G网络和3G网络之间传送计划(device)。

GGSN 176还可以通过CSCF 136来使用IMS网络130。

在图1的实施例中，还提供了毫微微小区(femtocell)180。在该示例中，设备182通过高速分组接入链路与毫微微小区接入点184通信。

毫微微小区180可以包括安全网关186和毫微微网关188。然后，毫微微网关188可以与3G网络160中的SGSN 172和MSC 174通信。

如上所述，图1仅意在示出使用IMS网络130的通信的要素，因此其它示例和网络架构是可能的。

IMS认证

如上所示，诸如以上图1中的设备112、114、162、164或180之类的设备可能希望向IMS网络130进行认证。目前，认证包括首次向网络进行注册。IMS注册独立于底层接入网，允许对接入不可知服务进行标准化。

当用户向网络注册时，在网络和IMS设备之间建立安全关联。这允许用户使用他们已经订阅的IMS服务，并且允许用户通过在设备和P-CSCF之间建立互联网协议安全(IPSec)隧道来保护数据。

如下所述，IMS设备将被称为SIP用户代理(UA)。然而，这不是限制性的，可以使用任何设备。

SIP UA是实现客户端SIP功能的逻辑实体。SIP UA的一些实现可以是无线的或固定的，例如但不限于机顶盒、膝上型电脑、台式电脑等。SIP UA向网络提供两种标识。首先是专用IMS标识(称为IMS专用标识(IMPI))，另一个被称为公共用户标识(称为IMS公共标识(IMPU))。

公共标识是可以用于联系用户的标识。IMPI是用于认证SIP UA并授予对IMS系统访问的标识。IMPI存储在归属运营商网络的HSS132中，并且可以根据存储在通用订户标识模块(USIM)上的国际订户标识(IMSI)导出，或者可以存储在IMS订户标识模块(ISIM)中。

以上内容在例如以下文献中得到描述：第三代合作伙伴计划(3GPP)技术规范(TS)33.203，“3G security；Access security forIP-based services”，V12.8.0，2012年12月，其内容通过引用并入本文中。

该技术标准的第6.1节涉及认证和密钥协商(AKA)。特别地，如6.1.0节所述，IMSAKA实现了ISIM(如果存在，否则是USIM)和家庭网络(HN)之间的相互认证。用于认证订户的标识是专用标识IMPI，其具有如例如在3GPP TS 23.228中描述的网络接入标识符(NAI)(其采用如在RFC 4282中描述的格式)的形式。HSS和ISIM/USIM共享与IMPI相关联的长期密钥。

此外，如3GPP TS 33.203规范的6.1.1节所述，在用户可以访问IM服务之前，需要注册至少一个IMPU，并且在IMS中在应用层级处对IMPI进行认证。因此，IMPI也用于标识存储订阅简档的HSS。

均可以使用空中下载(OTA)功能在USIM/ISIM上对IMPI和IMPU进行改变。该OTA功能允许运营商改变ISIM/USIM上的数据项。

如果使用与SIP UA功能相关联的硬件来接入3GPP系统，则还将存在通用集成电路卡(UICC)。UICC包含诸如USIM应用和可能的ISIM应用的应用。USIM应用和ISIM应用包含用于接入3GPP网络的标识和认证算法。

USIM包含IMSI和认证机制(称为3GPPAKA)。ISIM包含用户名@域的形式的专用标识，并且公共用户标识也是相同的形式。ISIM还包含被称为IMS AKA的认证机制，但算法的输出不同。

因此，SIP UA的认证是使用IMPI来执行的。用于认证的IMPI可以比作IMSI的IMPI，并且可以从ISIM专用标识获得；或者在ISIM不存在或者其上没有存储IMPI的情况下根据USIM IMSI导出。

以SIP REGISTRATION(SIP注册)消息向网络发送IMPI和IMPU。基于IMPI与AKA机制结合使用，网络将发回多个认证向量。这些例如在3GPP TS 33.203的6.1.1节中描述。

现在参考图2。特别地，如图2所述，UE 210向P-CSCF 212发送SIP注册消息230。然后，SIP注册消息作为消息232被转发到I-CSCF 214。然后，I-CSCF 214针对注册消息选择HSS 216和S-CSCF 218，如块234和消息236所示。

然后，将挑战发回给UE，并且基于挑战发生注册。特别地，S-CSCF向HSS 216执行PUT(如块240所示)，然后向HSS 216发送AV请求(如消息242所示)。在S-CSCF 218处从HSS216接收AV请求响应244。

然后，S-CSCF 218以消息250向I-CSCF 214发送认证挑战。以消息252将认证挑战转发到P-CSCF 212，然后以消息254将认证挑战转发到UE 210。

针对该挑战的响应具有关于IMSI的向量的形式，然后向HSS和S-CSCF发回该响应，然后HSS和S-CSCF可以确认认证是否可以。具体地，响应是从UE 210向P-CSCF 212发送的注册消息260。然后，以消息262将该响应转发到I-CSCF 214。I-CSCF 214向HSS 216执行Cx-Query(如块264所示)，然后向S-CSCF 218转发该响应(如消息266所示)。

然后，S-SCSF 218向HSS 216验证该响应，如Cx-Put块270和Cx-Pull块272所示。如果认证成功，则从S-CSCF 218向I-CSCF 214发送成功消息280。然后，成功消息作为消息282被转发到P-CSCF 212，并作为消息284被转发到UE 210。

IMS还允许多于一个的公共用户标识与专用用户标识相关联。事实上，公共用户标识可以与多个专用用户标识相关联，如例如关于图3所示。

图3是以下文献中的图4.6的再现：3GPP TS 23.228，“IPMultimedia Subsystem(IMS)；Stage2”，v.13.2.0，2015年3月，其内容通过引用并入本文中。特别地，如图3所示，IMS订阅310包括两个专用用户标识320和330。专用用户标识320包括两个公共用户标识，即公共用户标识322和324。

专用用户标识330还包括公共用户标识324以及公共用户标识332。

公共用户标识322与服务简档340相关联，并且公共用户标识324和公共用户标识332共享服务简档342。

因此，如图3所示，IMS订阅可以具有各种专用用户标识和与专用用户标识中的一个或多个专用用户标识相关联的公共用户标识。

没有与公共用户标识322、324或332相关联的认证。通过由HSS经由S-CSCF向P-CSCF下载设备可以使用的公共用户标识，来执行UE可以使用什么用户标识的策略。当设备发起会话时，P-CSCF将确保只使用有效的公共用户标识。

当向IMS网络注册IMPU时，HSS将向S-CSCF下载服务简档。服务简档(例如图3中的服务简档340或342)描述了IMS应用服务器应该在什么情况下参与呼叫/会话。例如，服务器可以参与执行与公共用户标识相关联的服务，并且将由S-CSCF来控制。

如上所述，IMS认证机制被称为IMS AKA。IMS还允许支持其它认证方案，包括但不限于：SIP摘要、传输层安全性(TLS)、GPRS-IMS捆绑认证(GIBA)。网络接入子系统(NASS)-IMS捆绑认证也被允许用于来自固定特定位置或针对IMS AKA不可用的早期IMS部署的认证。GPRS IMS捆绑认证是NASS-IMS捆绑认证的另一变体，用于早期IMS部署。例如，在3GPPTS 33.203的第N.1节、O.1.1节、R.1节和T.1节中描述了这样的认证方案。

然而，无法验证公共用户标识。这在某些应用中带来了问题。例如，这种会带来问题的一个应用是关键任务一键通(MCPTT)，下面将对此进行描述。

关键任务一键通

关键任务一键通是一种用于关键任务类型操作(例如应急服务)的一键通服务。然而，它也可以扩展到商业用户，包括公用事业、出租车等。在一些情况下，MCPTT可以用于如今存在专用移动无线电(PMR)系统的任何地方。

MCPTT 3GPP服务在以下文献中得以描述：3GPP TS 22.179，“Mission CriticalPush to Talk (MCPTT) over LTE；Stage 1”，v.13.1.0，2015年3月，其内容通过引用并入本文中。

如该规范第4.5节中所述：

MCPTT服务支持MCPTT用户简档。MCPTT用户简档包含与接收MCPTT服务的MCPTT用户相关的重要信息，其中包括MCPTT用户标识，该MCPTT用户标识是全球唯一且独立于由3GPP网络运营商所指派的移动订户标识(IMSI)。MCPTT用户简档的一部分内容(例如，包含一些显示偏好、一些UE音频设置、一些地址簿)可以由MCPTT用户来设置/修改/更新，但重要部分可能只能由经认证的人员来设置/修改/更新。MCPTT用户简档永久存储在与提供MCPTT服务的基础设施相关联的数据库中。简档的相关部分可以被下载，并且暂时或永久地缓存在某些MCPTT UE上。当与MCPTT用户相关联的MCPTT用户简档存储在MCPTT UE上时，该与MCPTT用户相关联的MCPTT用户简档可能是机密的且受到完整性保护，并且该信息仅可用于与该MCPTT用户相关联的经认证的可信应用客户端。MCPTT用户简档信息可以在MCPTT UE上的缓存与MCPTT服务基础设施的数据库中保存的主副本之间自动或按需地进行同步。MCPTT用户简档是MCPTT应用服务域的一部分，并且形成MCPTT应用层安全性的基础，并向MCPTT服务标识MCPTT用户。

每个MCPTT用户具有至少一个MCPTT用户简档，也可能有若干个。通常，将MCPTT用户简档之一指定为默认MCPTT用户简档，除非明确选择了MCPTT用户简档，否则将使用该默认MCPTT用户简档。通常，用户简档与特定设备、特定操作模式(即，联网或离网的)和/或特定情况(例如，用户在下班时在某个城市，或者扮演某个角色)相关联。当在基础设施和MCPTT设备之间同步MCPTT用户简档时，可以根据需要将信息下载到设备并更新。随后，如果允许，MCPTT用户可以选择不同的关联MCPTT用户简档进行下载并存储在设备上。一次只有一个MCPTT用户简档是活跃的。允许经认证的用户创建、删除和更改针对MCPTT用户的MCPTT用户简档和/或预存储的MCPTT用户简档。

此外，3GPP TS 22.179规范的第4.5.1节指出：

与EPS范例一致，当MCPTT UE开机时，它接入LTE系统，并连接到EPC。在此阶段，使用来自与MCPTT UE相关联的UICC上的USIM应用(如果使用IMS，也可能是ISIM应用)的凭证向HSS进行认证。随后，由驻留在MCPTT UE上的MCPTT应用建立到IMCPTT服务的连接，在该连接中采用应用层安全性。

此外，3GPP TS 22.179规范的第4.5.2节指出：

用户可以输入他的标识/认证凭证(例如，用户名/密码、PIN、生物特征、来自远程可信设备的断言标识)。此步骤通常使MCPTT用户能够访问存储在MCPTT UE上的本地信息和应用，特别是MCPTT客户端应用。

MCPTT服务允许相同的MCPTT用户从不同的MCPTT UE登录(并同时保持登录状态)。例如，事件管理器或命令器可以使用便携式电话、命令平板电脑或单独的消息发送单元。

最后，该技术规范第4.5.4节规定：

可共享MCPTT UE的概念模型是UE池的概念模型，其中，每个UE可与其它任何UE互换，并且用户从池中随机选择一个或多个UE，由每个用户暂时专用。能够访问存储在可共享MCPTT UE上的MCPTT客户端应用的用户可以使用可共享MCPTT UE，并且该用户可以成为经认证的MCPTT用户。可共享MCPTT UE一次只能服务一个MCPTT用户。登录到已在使用中的可共享MCPTT UE的MCPTT用户将导致前一个MCPTT用户的退出。

MCPTT用户可以同时拥有若干个活跃的MCPTT UE，从MCPTT服务的角度来看，这些MCPTT UE可以被单独寻址，和/或在与它们与MCPTT用户关联的上下文中被共同寻址。

根据上述技术规格，可以导出各种事项。例如，一个要求是来自第一组的用户可以使用属于第二组的设备。例如，法国警察可能能够使用属于荷兰警察的设备。

MCPTT架构的一个示例在3GPP TS 23.779，“Study on applicationarchitecture to support Mission Critical Talk over LTE(MCPTT)services”，v.0.5.0，2015年2月中提供了，并且例如在该规范的图5.2.1.1.1-1中示出，该规范的内容通过引用并入本文中。特别地，公共安全用户可以在服务器或服务器组中拥有自己的应用。这样的应用可以包括与IMS网络的S-CSCF进行通信的应用，并且包括PS-UDF(公共安全用户数据功能)，PS-UDF由公共安全管理局操作，并且用作一种“移动虚拟网络运营商”，以及提供IMS和公共安全应用所需的HSS的功能。因此，PS-UDF替代了HSS。

由于替代了HSS，因此可能需要与传统的虚拟公共陆地移动网络(VPLMN)漫游。然而，在一些实施例中，EPC级安全性使用传统的HSS，而公共安全管理局使用PS-UDF。

可以是公共安全机构服务器的一部分的其它应用可以包括MCPTT服务器。在这种情况下，PS-UDF提供针对移动终止呼叫/会话建立和服务调用提供认证，并且利用过滤准则来更新S-CSCF以触发公共安全应用服务器向用户提供服务。PS-UDF与MCPTT服务器和组管理功能通信以支持IMS中的MCPTT服务。在一个实施例中，MCPTT服务器等同于针对公共安全(PCPS)架构的开放移动联盟(OMA)一键通信中的蜂窝一键通(PoC)服务器。

综上所述，公共安全服务的架构包括通过S-CSCF与IMS系统进行通信的一个或多个服务器，该一个或多个服务器包括PS-UDF和MCPTT服务器。

在操作中，可以如图4所示的那样来部署MCPTT。特别地，如图4所示，公共安全运营商可以具有应用基础设施410以及支持公共安全运营商的SIP IMS核412。

然后，常规PLMN可以用于某种信令，包括支持公共安全运营商的IP(EPC)核420以及诸如LTE的接入网424。

公共安全UE 430可以包括组管理客户端432以及MCPTT客户端434。

如图4所示，公共安全机构的应用基础设施之间的控制信令向组管理客户端432以及MCPTT客户端434提供控制信令。

此外，从应用基础设施410向MCPTT客户端434提供用户数据和嵌入式控制。

在图4的部署模型的一个使用中，可以在蜂窝运营商不知道设备正在用于什么用途、或由谁来使用的情况下对IMS层提供完全控制。在这种情况下，设备将具有将在蜂窝网络中使用的通用公共用户标识。然而，在IMS网络中，该标识会改变，并且蜂窝运营商看不到该改变。

可扩展认证协议

可扩展认证协议是一种可扩展认证框架。它提供了将其它认证方案合并到基本消息发送结构中的必要工具。已经创建了许多EAP机制。一个EAP机制是EAP隧道传输层安全(TTLS)。在该认证方案中，通过在客户端和TTLS服务器之间建立安全隧道，然后在安全隧道内允许使用另一个认证协议对客户端进行认证，可以向认证、授权和计费(AAA)基础设施安全地认证客户端。

EAP-TTLS在例如以下文献中得以描述：Internet Engineering Task Force(IETF)request for comments(RFC)5281“Extensible Authentication ProtocolTunneling Transport Layer Security Authenticated Protocol version 0”，2008年8月，其内容通过引用并入本文中。现在参考图5A和图5B，图5A和图5B示出了RFC 5281的第6节中的协议栈。

特别地，如图5A所示，当用户认证协议本身不是EAP时，EAP-TTLS分组被封装在EAP中，而EAP相应地需要运营商协议(carrier protocol)来传输它。EAP-TTLS分组本身封装有TLS，而TLS然后用于封装属性-值对(AVP)，AVP可以携带用户认证或其它信息。因此，如图5A所示，协议栈包括运营商协议层510、EAP层512、EAP-TTLS层514、TLS层516和EAP层518。

当用户认证协议本身是EAP时，关于图5B示出了协议栈。特别地，如图5B所示，协议栈包括EAP层530、EAP-TTLS层532、TLS层534和针对包括EAP的AVP的层536。然而，协议栈还包括EAP方法层538，其中已经定义了用于在运营商协议内封装EAP的方法。例如，点对点协议(PPP)或LAN上的可扩展认证协议(EAPOL)可以用于在客户端和接入点之间传输EAP。RADIUS或Diameter用于在接入点和TTLS服务器之间传输EAP。

针对MCPTT的IMS认证

因此，MCPTT要求任何用户应该能够拿起任何设备并使用它。例如，消防站可以有任何消防员都能够拿起和使用的一箱设备。此外，MCPTT应用的认证需要独立于蜂窝/IMS网络以满足公共安全服务提供商和公共安全用户的安全性要求，并且在一些情况下可能期望隐藏或隐蔽正在使用设备的用户的标识或角色。因此，MCPTT不适合当前的IMS认证协议。

根据本公开的实施例，描述了用于提供单独的公共用户标识和专用用户标识的各种认证方案。此外，还描述了用于隐蔽用户的标识的方法和系统。尽管以下公开内容是关于MCPTT描述的，但是对下面所描述的认证系统和方法的使用同样可以用于其它应用。因此，本公开不限于MCPTT。

在下面描述的实施例中，提供了用于带内信令和带外信令的解决方案。如本文所使用的，带内信令意味着使用现有的IMS消息发送来认证IMS UE的信号，所述信号被增强以携带附加信息以指示需要执行的新形式的认证。此外，如本文所使用的，带外信令意味着使用新信令路径来认证IMS UE，而不是使用当前信令路径来认证IMS UE。换句话说，带外信令意味着当前用于认证IMS UE的信令没有被增强，并且使用另一机制来认证单独的订户。

以下提供了各种带内实施例和带外实施例。

以下描述的实施例被提供为完整的实施例。然而，本领域技术人员将认识到，每个解决方案的一部分都可以与其它解决方案一起使用以形成其它可能的解决方案。此外，随特定实现示出了一些编码机制。然而，特定实现可以在各种解决方案中混合并匹配。此外，在附录和表中描述了对标准的各种改变。这些改变示出了其它特定实现，并且可以等同地混合和匹配。本领域技术人员将认识到，这些示例改变也用于说明目的，并且可以以许多其它方式同样地完成编码。

带内-用于双重认证的指示

在一个实施例中，IMS注册消息被增强以包含新的指示。新的指示向网络发信号通知，不仅仅认证IMS专用用户标识(第一认证机制)，还需要执行IMS公共用户标识认证(第二认证机制)。该指示可以被发送给诸如HSS或PS-UDF的认证数据库，以指示在UE处需要两个认证向量集。

现在参考图6。在图6的实施例中，希望向IMS系统认证UE 610。通信可以通过P-CSCF 612、S-CSCF 614、AAA 616、HSS 618和PS-UDF 620来进行。然而，可以对图6的逻辑要素进行重新布置，并且可以在其它要素中放置某些逻辑，因此图6仅是示例。例如，AAA服务器可以与PS-UDF组合。在另一示例中，PS-UDF可以与HSS组合。其它示例也是可能的。

在图6以及说明书的其余部分中，标识了各种网络节点，例如MCPTT服务器、PS-UDF、HSS等。然而，通常，这些实体中的每一个可以被认为是彼此交互以执行本文描述的方法的若干个网络节点中的一个网络节点。

在图6的实施例中，UE 610向P-CSCF 612发送消息630。消息630包含各种信息，包括但不限于第一公共用户标识、第一专用用户标识、以及指示支持或需要“双重认证”(专用和公共用户ID的认证)的指示符。在一个实施例中，消息630的标识符可以被编码为标识新安全方法的新机制/名称。例如，该方法可以被称为IPSEC-MCPTT。备选地或附加地，标识符可以被编码为安全客户端字段中的mech参数，例如，如IETF RFC 3329中所述。

在备选实施例中，消息630中的标识符可以是认证头字段中的新参数。例如，可以使用新的AKA版本号。

在另一个实施例中，标识符可以被编码为所支持或所需的头字段中的选项标签。

在另一个实施例中，该标识符可以被编码为特征标签。

此外，标识符可以被编码为通用资源标识符(URI)参数，例如“doubleauthentication＝yes”。

在另一个实施例中，标识符可以被编码为可扩展标记语言(XML)主体。标识符也可以被编码为新的头，或者可以被附加到第一公共用户标识或第一专用用户标识。

例如，在下面的表1中，粗体的项目表示上述各种方法的中一些编码。下面的表1示出了均置于相同注册消息中的各种选项。然而，本领域技术人员将会知道，在一些情况下，只需要一个标识符，并且可以是下面以粗体显示的那些中的任一个。在其它情况下，可以有多个指示符。

表1：对IMS注册消息的可能改变

类似地，可以根据所附的附录A对3GPP TS 24.229进行改变。如附录A中粗体所示，提供了对TS 24.229文本的补充。然而，如上面的表1所示，各种改变都被分组到附录A中，本领域技术人员将认识到，在实践中可能仅需要粗体改变中的一个改变或子组合。

再次参考图6，一旦P-CSCF 612接收到消息630，它就向S-CSCF 614发送包含消息630的内容的消息632。

S-CSCF接收消息632，并向HSS 618发送认证请求消息634。在附录B中以粗体提供了可以对3GPP TS 29.228规范中的消息634做出的改变的一个示例。如附录B所示，认证的描述可以包括例如生物特征指纹数据和IMS-AKA认证。然而，附录B中的改变仅作为示例。

关于附录C示出了备选实施例，其中S-CSCF识别第二认证摘要头，并且包括具有对要使用的认证方案的指示的新的MCPTT SIP认证方案属性值对(AVP)。

具体地，如附录C所示，定义了一个全新的认证方案。

第一数据库功能(例如，HSS 618)接收消息634，然后可以从第二数据库功能(例如，PS-UDF 620)获得认证向量，如消息636所示。具体地，如关于图6中的消息636所示，HSS可以从PS-UDF获得针对公共用户标识号的向量集。HSS向PS-UDF发送认证请求消息，该消息包含上述标识任何或全部数据。

关于实现，在一些实施例中，HSS 618可以与PS-UDF 620组合。

PS-UDF 620接收公共用户标识并且用向量集进行响应。向量可以包括以下挑战中的一个或多个，但挑战响应不限于以下示例。具体地，基于AKA的示例向量集是：

-AV＝RAND_n||AUTN_n||XRES_n||CK_n||IK_n，其中：

-RAND：用于产生XRES、CK、IK以及AUTN的一部分的随机数。其还用于在UE处产生RES。

-AUTN：认证令牌(包括MAC和SQN)。

-XRES：来自UE的期望(正确)结果。

-CK：密码密钥(可选)。

-IK：完整性密钥。

然而，基于所使用的算法，向量可以不同。例如，向量可以基于在SIP寄存器中传送的数据，然后将其转换成附录B中的条目。可以使用例如如下消息：Security-Client：ipsec-MCPTT；alg＝biometric finger prnt；spi-c＝23456789；spi-s＝12345678；port-c＝2468；port-s＝1357。

在实现方面，PS-UDF可以与MCPTT服务器619或AAA服务器616组合。

HSS 618然后可以以消息640向S-CSCF 614反向提供挑战向量。消息640中的挑战向量可以针对第一专用用户标识和第一公共用户标识。针对第一公共用户标识的挑战向量可以被编码为特征标签、XML主体、AVP或新的头以及其它可能中的任一个。例如，附录D以粗体示出了针对AVP挑战对3GPP 29.228的一个可能改变。

在图6的实施例中，由于双重认证方案的标识，HSS因此包括了第二认证向量集。然后，在此信元后的数据与第一公共用户标识相关联。在附录D中的改变中，最后四行是与第二IMS AKA功能关联的数据项，但是认证机制可以是任何认证机制。因此，附录D中所示的SIP认证包含所呈现的针对第一公共用户标识的挑战。此外，还存在可以被第一公共用户标识用来确保它被经认证的实体挑战的数据项。

附录D中的SIP认证元素是针对挑战的期望结果。S-CSCF 614接收消息640并向P-CSCF 612提供消息642。消息642提供针对专用用户标识和公共用户标识的挑战向量。例如，如下面的表2所示，粗体部分提供了对认证消息的补充。粗体部分表示第二认证向量集。

表2：对认证请求的可能改变

在上面的表2中，第二个不重数(nonce)是与第一个不重数相似的各种数据集的结构。这种第二个不重数的使用仅是为了说明目的，并且本领域技术人员将认识到重点在于第二个不重数包含用于验证挑战是否来自合法来源的挑战和附加数据。

P-CSCF 612接收消息642并将针对公共用户ID和专用用户ID的挑战向量转发给UE610，如消息644所示。消息644通常包含不重数、要使用的算法、第二个不重数和与第二个不重数相关联的第二算法。

例如，参考表3，其以粗体示出了可以对消息644做出的补充。

表3：对认证请求的可能改变

当UE 610接收到包含两个认证挑战向量的消息644时，可以将第二挑战向量集编码为特征标签、XML主体、AVP、新的头或www认证头等。

UE 610包含移动要素(ME)和UICC。ME执行第一认证。如果ME中包含UICC，则可以通过ME-UICC接口发送认证向量。

在第一认证之后或在第一认证期间，ME将运行第二认证挑战，将在下面详细描述第二认证挑战。

关于下面的附录E，示出了对3GPP TS24.229规范的一个改变示例，以在UE处支持这种双重认证。特别地，已经在附录E的示例中修改了3GPP TS 24.229的5.1.1.5节，以示出UE可以提取挑战和认证参数并检查认证参数的有效性。如果认证参数有效，则UE可以执行MCPTT应用认证。

当UE 610已经完成了第一认证时，然后UE可以发送包含两个响应的认证响应650。第二挑战响应可以被编码为特征标签、XML主体、AVP、第二认证头、新的头中的任何一个，或使用分隔符或其它选项附加到现有响应值(例如，XXXXX yyyyyy，其中XXXXX是第一响应值，YYYYY是第二响应值)。这些响应值可以是长度上为任意数的字符。

参考下面的表4，其以粗体示出了包括在第二响应中的第二认证头。用户名(username)是第一公共用户标识的用户名。

表4：第二认证头

在下面的附录F中以粗体提供了针对响应对3GPP TS 24.229做出的改变的示例。

如附录F所示，响应被提供了附加到第一响应的第二计算响应，如附录F中粗体所示。

在P-CSCF 612处接收消息650并将消息650转发给S-CSCF 614，如消息652所示。然后，如块654所示，S-CSCF 614可以执行对期望响应的检查。如果在图6中的块641处，第一个不重数和第二个不重数两者都成功地与存储在S-CSCF 614中的那些不重数匹配，则将针对MCPTT服务对UE 610进行注册。如果第二个不重数与存储在S-CSCF中的值不匹配，则仅针对IMS服务对UE进行注册。如果第一个不重数与存储在S-CSCF 614中的不重数不匹配，则针对任何服务都不对UE 610进行注册。

在可选的实施例中，如果S-CSCF 614尚未具有针对公共用户标识的存储向量，则可以向HSS 618发送消息660。关于附录G示出了消息660的示例，附录G以粗体示出了对3GPPTS 29.228的建议改变。

HSS 618或其它认证功能(例如，PS-UDF)接收消息660，并确定对认证向量的请求是针对包含在公共用户标识字段中的公共用户标识的。该确定基于以上标识的指示。特别地，附录H以粗体示出了所提供的对3GPP TS 29.228中的认证请求数据的可能改变。

诸如HSS 618的认证功能将产生认证向量，或者通过转发消息或使用备选协议来请求另一功能产生认证向量。然后，诸如HSS 618的认证功能发送针对公共用户标识的认证向量。附录I以粗体示出了对3GPP TS 29.228的可能改变。

如附录I所示，响应中提供了公共用户认证向量。因此，消息660经由标识公共用户认证使得HSS包括针对公共用户标识的认证向量集。然后，在此信元后的数据与第一公共用户标识相关联。本领域技术人员将会理解，附录I中的最后四行是与第二IMS AKA功能相关联的数据项，但是认证机制可以是任何机制。再次，一个方面是SIP认证包含所呈现的针对公共用户标识的挑战。例如，如果正在认证第一公共用户标识，则该挑战指向该第一公共认证用户标识。此外，在消息中的第一公共用户标识数据项中，存在可以被第一公共用户标识用来确保它被经认证的实体挑战的数据项。此外，附录I中的SIP认证字段是挑战的期望结果。

再次参考图6，如果针对MCPTT服务已经对UE 610进行了注册，则S-CSCF 614可以向认证功能(例如，HSS、PS-UDF等)发送包含第二认证已经成功的指示的消息662。该指示可以被编码为但不限于：特征标签、XML主体、AVP或新的头等。

关于附录J示出了可被更新的AVP的示例。如附录J中粗体所示，提供了对3GPP29.229规范(特别是6.3.15节)的改变。

关于附录K示出了新的AVP的另一示例。在附录K中，在3GPPTS 29.229的6.1.3节中标识了正被注册的应用，如粗体所示。

如果针对公共安全/MCPTT服务尚未注册UE，并且仅针对任何IMS服务对UE进行了注册，也可以使用消息662。在这种情况下，S-CSCF 614可以发送包含依照3GPP TS 29.228的信息的消息662。

在图6中，一旦S-CSCF 614确认了成功，就可以向UE 610提供成功消息670。

在上文中，当UE接收到针对第二认证挑战的数据时，UE需要向网络提供响应。这可以在ME或UICC上的应用上执行。结果可以由自动或手动处理来产生。自动响应可以使用外部认证令牌。外部认证令牌可以被刷入ME中的读卡器，ME可以经由无线机制(例如，使用蓝牙^TM、近场通信(NFC)、射频标识符(RFID)等)与认证令牌通信。基本上，ME向外部节点发送消息，并且外部节点用认证凭证来反向对ME进行响应。

在手动认证中，ME提供指示，该指示可以是但不限于音频、视觉或其它消息中的任一个。ME经由键盘、屏幕、ME的移动、指纹读取器、视网膜扫描器、NFC、刷卡读取器等选项来接收数据。然后，接收的数据被用作挑战响应，并被编码在例如MIME类型的消息中。

因此，根据上述内容，IMS注册消息被增强以包含新的指示。新的指示向网络发送信号通知不仅对IMS专用标识进行认证，还要执行IMS公共用户标识认证。也向认证数据库发送该新的指示，以指示需要两个认证向量集。

网络在接收到新的指示时将利用两个认证向量集而不是一个认证向量集进行响应，或者如果针对IMPI已经存在安全关联，将单个认证向量集与IMS公共用户标识相关联。

设备应该能够接收两个认证向量集，并且在成功验证IMS专用用户标识集后，设备然后可以验证并运行第二认证向量集。第二认证向量集可以是密码或用户的一些其它唯一标识，例如指纹、来自ID卡的QR码、生物特征数据(比如，视网膜扫描)等等。

来自设备的对第一认证向量集的成功响应可以允许设备在IMS网络中执行有限的功能，例如接收配置信息。

对第二认证向量的成功响应允许特定用户使用该设备。确切的功能由过滤准则和与已被成功认证的公共用户标识相关联的服务描述特性来支配。

带内-第二公共用户ID和认证响应

根据本公开的另一实施例，正常执行IMS注册，包括第一公共用户标识和第一专用用户标识。然而，当设备对认证挑战做出响应时，设备还可以在挑战响应中包括新的附加信息，包括第二公共用户标识，而不是在初始IMS注册中发送的第一公共用户标识。

在一些实施例中，如果UE知道针对公共用户标识的挑战向量，则UE还可以提供针对第二公共用户标识的挑战响应。特别地，如果针对第二公共标识使用与针对第一标识提供的挑战向量相同的挑战向量，则挑战响应将是不同的，但是是可以在网络中导出的。

在一个实施例中，针对第二公共用户标识的挑战响应可以是密码或用户的一些其它唯一标识，例如指纹、来自ID卡的QR码、或其它生物特征数据(比如，视网膜扫描)等等。在一些情况下，可以以明文形式发送第二公共用户标识，或者可以通过设备对第二公共用户标识进行加密或隐蔽，因此第二公共用户标识必须由诸如HSS的网络实体来进行解密或解隐蔽。如果第二公共用户标识已被加密，则在IMS注册期间可能需要提供标识符以指示这种加密。加密可以基于设备和HSS、PS-UDF或公共安全AAA服务器已知的公钥。

当网络接收到与第一公共用户标识不匹配的第二公共用户标识时，S-CSCF可能需要获得针对第二公共用户标识的认证向量。如果针对第二公共用户标识的挑战响应对于第二公共用户标识是正确的，则网络以第二用户标识进行响应作为将用于设备的标识。然而，如果挑战响应对于第二公共用户标识是不正确的，则网络将以第一公共标识进行响应来作为设备将使用的标识。

现在参考图7。在图7中，UE 710与P-CSCF 712通信。网络的其它要素包括S-CSCF714、AAA 716、HSS 718和PS-UDF 720。本领域技术人员将会理解，这些是逻辑功能并且可以组合在一起。

在图7的实施例中，UE 710希望向IMS网络(例如，公共安全IMS网络)注册。在这种情况下，UE 710向P-CSCF 712提供消息730，消息730提供第一公共用户标识和第一专用标识。P-CSCF 712接收消息730并将消息转发给S-CSCF 714(如消息732所示)，消息732再次提供第一用户标识和第一专用标识。

然后，S-CSCF 714向HSS 718提供认证请求734，并且HSS 718可以获得针对专用标识符的挑战向量，并且以消息740将这些挑战向量提供给S-CSCF 714。在一些情况下，可以从P-UDF 720获得挑战向量，如箭头741所示。

然后，以消息742从S-CSCF 714向P-CSCF 712传送挑战向量，然后以消息744向UE710传送该挑战向量。

当接收到消息744的认证挑战时，UE 710反向向P-CSCF 712提供消息750。如果UE支持MCPTT服务，则该消息可以包含由(但不限于)第一专用用户标识、第二公共用户标识和与第二公共用户标识相关联的凭证组成的信息。如果是这样的情况，还可以提供第二公共用户标识和/或凭证已被加密的可选指示。

消息750中的信息可被编码为包括标识新安全方法的新机制名。例如，该新机制名可以是安全客户端头字段中的IPSEC-MCPTT和/或MEC-PARAMETERS。例如，IETF RFC 3329描述了这样的编码。此外，编码可以是认证头字段中的新参数，例如，如在IETF RFC 3310中描述的新的AKA版本。此外，信息可以被编码为所支持或所需要的头字段中选项标签、特征标签、URI参数、XML主体、新的头，或者可以附加到第一公共标识或第一专用用户标识。

例如，参考附录L，其示出了对3GPP TS 24.229(特别是对该规范的5.1.1.5节)的可能改变。附录L的粗体部分是新增部分。

此外，表5示出了对用于提供消息750的消息发送的两个实现的可能改变。

表5：认证响应

P-CSCF 712接收消息750并将消息752转发给S-CSCF 714。消息752包括与消息750中所包括的信息相同的信息。

在图7的示例中，并且如表5所示，S-CSCF发现接收的信息与以消息732提供的信息不匹配，随后存储对该接收的信息进行存储。该信息可以包括在用户名头中接收的公共用户标识、不重数或算法。如果S-CSCF尚未存储针对公共标识的向量，则S-CSCF将向认证功能(例如，HSS 718或P-UDF 720或AAA 716)请求认证向量，如块754所示。

向量的获得由消息756示出，并且与上面图6的消息660的获得相同，除了该信息包含第二用户标识。

如图7所示，消息752提供参数和认证响应以允许第二公共用户标识的成功认证。因此，一旦根据消息756检查了认证，如果认证是成功的，则在S-CSCF 714和HSS 718之间提供消息760。

此外，可以向UE 710提供成功消息762，并且该消息可以如图6的消息670那样被提供。

相反，如果认证对于第二公共用户标识符是不成功的，则消息770包括仅对于第一公共用户标识符、但不对于第二公共用户标识符的成功。因此，消息772提供了成功，但利用第一公共用户标识。

因此，以上允许使用ISM的带内认证机制来隐蔽公共用户标识以及对这种第二公共用户标识认证。

基于公共用户ID的带内密钥操作

在另一实施例中，正常地执行来自UE的IMS注册，其中包括针对MCPTT或公共用户标识也需要认证的指示。该指示被发送给S-CSCF和HSS/PS-UDF以及从S-CSCF和HSS/PS-UDF被发送。

密钥导出处理和挑战响应处理被增强，以包括与用于访问系统的公共用户标识相关联的个人标识号(PIN)。PIN被组合到IMS AKA算法中以创建认证向量。

这里使用的术语PIN以通用方式使用，并且可以包括但不限于：一组字母数字字符、图片、虹膜扫描、生物特征数据、指纹、声纹、密钥卡、条形码、Q码、以上的一些或全部的组合以及其它选项。

现在参考图8，其示出了针对这种密钥操作的信息流。特别地，UE 810与P-CSCF812通信，P-CSCF 812与S-CSCF 814、AAA 816和HSS 818通信。在一些实施例中，HSS 818还可以与PS-UDF通信。

如图8所示，UE 810发送包括公共用户标识符和专用用户标识符的消息830。然后从P-CSCF 812向S-CSCF 814转发该消息，如消息832所示。S-CSCF 814可以在接收到消息832时向AAA 816提供认证请求，如消息834所示。AAA 816以消息836向HSS 818提供认证请求。

挑战向量被创建，并且HSS 818以消息840向AAA 816提供针对专用ID的挑战向量。然后以消息842从AAA 816向S-CSCF 814提供挑战向量。

然后，以消息844从S-CSCF 814向P-CSCF 812转发挑战向量，并最终以消息846向UE 810提供挑战向量。如下所述，UE执行认证并反向向P-CSCF 812提供认证响应850。然后，认证响应被转发给S-CSCF 814，如消息852所示。

如果S-CSCF 814包括或已经存储了挑战向量响应，则可以进行检查，如块854所示。否则，可以在S-CSCF 814和HSS 818之间产生响应请求，如消息860所示。

如果认证成功，则将消息862用于确定，并反向向UE 810提供消息864。

在上文中，UE因此向网络发送注册消息，其包括针对MCPTT应用执行认证的指示。该指示可以被编码为以下中的任一个：标识新安全方法的新机制名(例如，安全客户端头字段中的ipsec-MCPTT、和/或mech参数)；认证头字段中的新参数；所支持或所要求的头字段中的选项标签；特征标签；URI参数；XML主体；新的头；或者，该指示可以附加到第一公共用户标识或第一专用用户标识。下面表6中编码的示例以粗体示出了改变，其中，新的安全客户端被称为“ipsec-3GPP-MCPTT”。

表6：MCPTT认证编码

此外，在UE处，当接收到消息846时，UE可以获得与公共用户标识相关联的挑战响应，所述公共用户标识是以IMS注册消息在“from”头中被发送的。然后，可以将被称为公共用户ID PIN的挑战响应发送给在ME或UICC处用于对其进行修改的功能，然后通过ME-UICC的方式，将响应从ME发送给UICC。UICC可以接收公共用户ID PIN并使用它来产生密钥和挑战响应。

下文的附录M中以粗体示出了对3GPP TS 31.103规范的可能改变的示例。

对于密钥操作，可以通过向认证功能发送消息以获得认证向量来增强S-CSCF814。消息可以包括其用于MCPTT服务的指示，并且该指示可以被编码为特征标签、XML主体、新AVP、使用具有新代码点的现有AVP、或者新的头。

认证功能可以是HSS、AAA、PS-UDF或这三者的某种组合。

认证请求可以采用下面附录N中描述的形式。

如附录N所示，认证请求可以包括公共用户标识、专用用户标识、认证项的数量、认证数据、S-CSCF名称和路由信息等。

在接收到请求针对注册的公共用户标识的认证向量的消息时，认证功能获得与公共标识AVP中的公共标识相关联的专用用户ID PIN。使用UE在消息846中发送的指示，认证功能产生或请求认证向量，并且在用于创建向量的新机制的指示内发回响应。这样的消息可以被编码为例如特征标签、XML主体、新AVP、使用新代码点的现有AVP、或者新的头等。

现在参考图9，其示出了可能的密钥产生实现。

特别地，密钥产生包括HSS处理910，HSS处理910包括产生序列号(SQN)的块812和产生随机数(RAND)的块914。SQN和RAND被馈送到标记为F1到F5、并且用附图标记920、922、924、926和928示出的各种功能块中。

在图9的实施例中，块F1920包括SQN、认证管理字段(AMF)和RAND的输入，并且还包括密钥值K.认证令牌(AUTN)由AK||AMF||MAC组成。

此外，块F2至F5包括作为输入的密钥值K和RAND。

在图9的实施例中，如块930所示的新功能F6也被提供为到块920、922、924、926和928的输入。块930将公共用户ID PIN作为输入。PIN码可以是从PS-UDF(第二认证功能)获得的。

在UE侧935，功能f6由块840示出，并且具有公共用户ID PIN作为输入。来自块940的输出被提供到功能块F1942，还被提供到块944、块946、块948。此外，加密密钥K也被提供到这些块以及块950。RAND也被提供给块950，并且在块954处导出SQN。

然后，UE可以验证MAC＝XMAC，并验证SQN在正确的范围内。因此，图9示出了密钥产生处理，由此，公共用户ID PIN与F1至F5中一些或全部组合在一起。

为了隐藏公共用户ID PIN，也可以通过功能F6发送PIN。

基于公共用户ID的带内密钥操作的备选实施例

在备选实施例中，IMS AKA算法的输出现在与公共用户ID密钥组合以创建认证向量集。特别地，该解决方案与前述类似，但其优点是，HSS的运营商(传统上是公共运营商)看不到公共用户ID PIN。这通过将PIN与AAA/PS-UDF、而不是HSS中的专用用户ID认证向量组合来实现。该实施例与前述实施例的主要区别在于产生密钥的方式，如图10和图11所示。

特别地，现在参考图10，其示出了HSS和AAA/PS-UDF中的认证向量产生的示意图。注意，HSS、AAA和PS-UDF可以是单个节点或多个节点。

HSS处理块1010与AAA/PS-UDF处理块1020通信。因此，根据图10的实施例，提供了与图9的密钥产生块类似的密钥产生块，包括SQN块1012和RAND块1014。来自这些块的输出被输入到功能块1030、1032、1034、1036和1038。然而，来自块1030、1032、1034、1036和1038的输出被提供给AAA/PS-UDF处理1020，因此公用用户ID PIN不会在HSS处被使用。相反，公共用户ID PIN被提供用于如块1050所示的块F6，并且可以产生用于块1060、1062、1064、1066和1068的输出。

图11示出了在UE处的认证向量产生的示意图。特别地，参数密钥可以用作为到功能块1110、1112、1114、1116和1118的输入。此外，可以在块1120处产生SQN。

公共用户ID PIN是在功能块1130处提供的，并且可以与块1110、1112、1114和1116的输出一起被提供到块1140、1142、1144和1146。

因此，可以对运营商保密公共用户ID PIN的使用。

尽管以上针对带内解决方案提供了图9、图10和图11的解决方案，但是这些解决方案可以等同地用于下面描述的一些带外解决方案。

带外信令

在另一实施例中，带外信令可以用于认证IMS单个订户。带外信令意味着使用新信令路径来认证IMS UE，而不是当前用于认证IMSUE的信令。带外信令机制可以在IMS注册之前或之后使用。

在第一实施例中，设备可以向网络发信号通知第一认证过程。例如，该信号可以是需要认证的EAP消息。该消息可以包含需要认证的公共用户标识，以及可选地包括与公共用户标识符相关联的专用用户标识符。网络可以用适合于所使用的EAP认证机制的认证挑战来响应。

在成功认证公共用户标识时，UE然后以IMS注册消息向网络提供相同的公共用户标识、以及在第一认证过程中使用的专用标识符(如果它完全被提供的话)。这在下面的描述中被称为第二认证过程。

然后，网络将检查公共用户标识已经被成功认证，并且将公共用户标识发回，作为对注册的响应。例如，如果对公共用户标识的认证不成功，则网络可以用用于配置目的另一个默认公共用户标识进行响应，或者可以允许用户以有限的能力来联系工作人员以修复认证问题。备选地，网络可以用认证失败指示进行响应。

例如，可以利用上面关于图9、图10和图11描述的技术来产生用于第二认证机制的密钥。

因此，根据本公开的一个实施例，带外解决方案将公共用户ID和专用用户ID链接在一起。这意味着，在公共用户ID首先被认证之后，公共用户ID仅可以与特定的专用用户ID一起使用。

现在参考图12。图12中，UE 1210与P-CSCF 1212通信。此外，各种要素可以包括S-CSCF 1214、AAA 1216和HSS 1218。在一些实施例中，还可以提供PS-UDF(未示出)，并且PS-UDF可以与AAA 1216和/或HSS 1218共处一地。

在图12的实施例中，第一认证机制1220被示出为是首先被执行的。第二认证机制1222被示出为是然后才执行的。然而，在其它实施例中，第二认证机制1222可以同样首先执行，并且随后执行第一认证机制1220。在这种情况下，在一个实施例中，第一认证机制中对公共用户标识认证的响应可能需要已经可用于UE和HSS以用于第二认证。

第一认证机制1220包括各种消息。从UE 1210向AAA 1216发送的第一消息1230通常至少包含公共用户标识和可选的专用用户标识。

AAA 1216接收消息1230。如果消息1230不包含两个标识，则网络可以将消息1232发回UE 1210以请求公共用户标识和专用用户标识，或者在其它实施例中，仅请求公共用户标识。

附录O中提供了对3GPP TS 24.302规范的改变以允许消息1232的请求的一个示例。如附录O中所示，八位字节可以用于指示返回UE的针对各种标识的请求。

再次参考图12，一旦UE接收到消息1232，UE就确定是否发送一个或两个标识。如果仅发回一个标识，则EAP-AKA已支持发送该一个标识。

在一个实施例中，UE将附加地使用新的编码方案来发送第二标识。例如，参考附录P，提供了对3GPP TS 24.302的可能改变，其中提供了备选编码方案。

然后，UE将消息1234发回网络(例如，发送到AAA 1216)。然而，在其它实施例中，接收方可以是PS-UDF或MCPTT AS或HSS1218。

当网络接收到消息1234时，网络可以向HSS 1218提供包含专用用户ID和公共用户ID的消息，如图12中的消息1240所示。HSS 1218接收消息1240并且产生针对公共用户ID的认证向量，并且以消息1242将这些认证向量提供回AAA 1216。如先前的带内实施例和其它带外实施例中所述，HSS可以与PS-UDF通信以获得认证向量。此外，HSS可以是PS-UDF。

AAA 1216接收消息1242，并且以消息1244将挑战向量转发到UE 1210。

UE 1210接收消息1244，并且产生认证响应，以消息1250将认证响应提供回AAA1216。

AAA 1216接收认证响应，并且以消息1252将认证响应转发到HSS 1218，然后HSS1218检查认证响应并以消息1254反向提供结果。

如果消息1254是成功消息，则可以以消息1256将成功转发到UE 1210。

此时，第一认证机制1220已经成功。在这种情况下，UE和HSS都将公共用户ID标记为针对专用用户ID使用的公共用户ID，如针对UE 1210的块1260和针对HSS 1218的块1262所示。

然后，图12的处理进入第二认证机制1222。从UE的角度来看，UE按照3GPP TS24.229执行IMS注册，并且包括在第一认证机制1220中确定的公共用户ID和专用用户ID。

当UE从网络接收到401k挑战时，它可选地使用在第一认证机制1220中用于公共认证的响应来创建放入SIP寄存器中的、到往网络的响应。例如，可以使用上面的图9、图10和图11的机制，其中响应与公共用户标识符PIN相同。

从HSS 1218的角度来看，HSS接收请求以提供认证向量。可以如上面关于图9、图10和图11所描述的那样创建这些认证向量，其中第一认证步骤中的针对公共认证的响应与公共用户ID PIN相同。然后，HSS将公共用户ID绑定到专用用户ID。例如，关于图13提供了密钥概述。

在图13中，UE 1310和HSS 1312继续进行认证过程。第一认证处理1320包括公共ID1322作为来自UE和HSS两者的输入。

UE 1310和HSS 1312中的每一个处的第一认证处理的结果被提供给第二认证处理1330，并且特别地提供给UE的IMS AKA 1332和HSS的IMS AKA 1334。换句话说，作为第一认证处理的一部分，HSS 1312向UE 1310发送挑战。同时，HSS计算它期望从UE获得的响应。UE利用响应来响应挑战。由UE产生的响应用作IMS AKA 1332的输入，并且由HSS产生的响应用作IMS AKA 1334的输入。

在UE处，IMS AKA 1332包括针对专用标识符的输入。类似地，在HSS处，IMS AKA1334包括针对专用标识符的输入。

将第二认证处理(XRES)的结果提供给S-CSCF 1340，S-CSCF 1340确定成功或失败。

因此，上述提供了一种带外解决方案，其中在IMS注册之前，公共用户ID与专用ID绑定。然而，如上所述，在一些实施例中，在IMS注册之后也可以发生带外认证。

第二带外实施例

在备选实施例中，可以使用上面关于第一带外实施例提供的解决方案。然而，在第一公共安全服务提供商的用户向第二公共安全服务提供商提供帮助并且需要使用第二公共安全用户提供商的MCPTT服务的情况下，可以实现对上述图12的解决方案的增强。

例如，如果第一警察部门的第一警察正在协助第二警察部门并且需要使用第二警察部门的MCPTT服务，则可以使用下面关于图14描述的实施例。在第一公共安全服务提供商与第二公共安全服务提供商相同的情况下，同样可以使用图14。

在第二实施例中，设备执行第二认证机制。例如，这种认证机制可以是具有第二公共用户标识和专用用户标识的IMS注册。

然后，使用MCPTT AS执行IMS第三方注册。MCPTT AS使用增强的Sh接口，并且发送针对MCPTT服务用户标识现已成功注册的指示。

然后，设备可以经由安全隧道使用第一公共用户标识来执行第二认证机制，安全隧道是作为第一IMS注册的一部分而被创建的，或者可以是第二认证机制的一部分(比如，EAP-TLS)。

第一公共用户标识是UE想要用于通信的公共用户标识。在成功认证时，PS-UDF通过增强的Sh接口发信号通知针对MCPTT服务第一公共用户标识和专用用户标识已被成功认证。

在第二认证成功时，在一个实施例中，设备使用第一公共用户标识来执行第二IMS注册。在备选实施例中，当网络反向向设备指示成功认证时，网元(例如，HSS)用第一公共用户标识更新P-CSCF。这可以经由HSS-PCC-P-CSCF通过使用PCC来修改P-CSCF中的公共用户标识来实现。备选地，这可以由HSS-S-CSCF使用，其中改变S-CSCF中的简档中的公共用户标识的Cx接口命令或消息触发NOTIFY以将注册事件分组发送到P-CSCF以更新可以与专用用户标识一起使用的标识。

因此，当设备发送INVITE(邀请)时，P-CSCF将断言针对任何会话发起的第一公共用户标识。

因此，上面提供了一种触发配置机制的方式，使得UE可以漫游到第二MCPTT网络，从而提供互助。

现在参考图14。在图14的实施例中，UE 1410与P-CSCF 1412通信。此外，在系统中提供了S-CSCF 1414和AAA 1416。

此外，在系统中提供了MCPTT 1420、HSS 1422和PS-UDF 1424。

在图14的实施例中，首先执行第二认证机制1430。特别地，IMS认证注册1432使用第二公共标识而不是第一公共用户标识。该注册处理允许UE获得基本IMS服务但不获得MCPTT服务。

第三方注册1434仅向MCPTT服务注册第一专用用户标识和第二公共标识。然后，MCPTT服务利用已经向MCPTT服务注册的专用用户ID、第二公共用户标识或设备ID中的至少一个来更新PS-UDF 1424。

例如，可以使用对3GPP TS 29.328的改变来提供用于上述的信令。关于附录Q示出了这种改变的一个示例。

如附录Q中所示，可以针对诸如MCPTT的特定服务注册IMS用户状态，或者不针对诸如MCPTT的特定服务注册IMS用户状态。

当完成了使用第二公共用户标识符的第二认证机制时，可以在MCPTT 1420和S-CSCF 1414之间提供第三方注册消息(如消息1434所示)，并且可以在P-CSCF 1412和S-CSCF1414之间提供订户消息1436。

随后，可以执行第一认证机制1440。第一认证机制1440与上面关于图12的第一认证机制1220提供的相同。特别地，第一认证机制使用第一公共用户标识和第一专用用户标识进行认证。这由消息1442示出，消息1442被传送给AAA 1416。然后，以消息1444向PS-UDF1424提供第一公共用户标识和专用用户标识。

然后，针对第一公共用户ID向AAA 1416提供挑战向量，如消息1446所示。然后，AAA1416以消息1448向UE 1410提供这些挑战向量。

然后，UE向AAA 1416提供认证响应(由消息1450所示)。以消息1452将认证响应转发到PS-UDF 1424。如果认证处理成功，则PS-UDF 1424(或在一些情况下为AAA)经由Sh接口更新MCPTT服务器1420(如消息1460所示)。如上所述，关于附录K示出了示例消息。Sh接口上的消息包含第一公共用户标识和可选的第一专用用户标识。然后，MCPTT服务器能够将从设备注册的第一公共用户标识与在第二认证机制中从相同设备注册的第二公共用户标识进行关联。同样可以使用Sh接口，因此MCPTT服务器可以向PS-UDF提供第一专用用户标识和第二公共用户标识，由此PS-UDF可以创建第一公共用户标识、第二公共用户标识和第一专用用户标识之间的关系。然后，PS-UDF可以用这种关系更新HSS，如消息1474所示。本文中使用的术语“更新”意味着HSS可以向PS-UDF进行询问以确定第一公共用户标识是否可以与第一专用用户标识一起使用，或者PS-UDF向HSS提供信息以便HSS可以创建第一公共用户标识、第二公共用户标识和第一专用用户标识之间的关系。

可以提供消息1464和1466以显示成功。特别地，从PS-UDF 1424向AAA 1416提供消息1464。从AAA 1316向UE 1410提供消息1466。

可以增强Sh通知以提供针对MCPTT服务的认证已成功的指示。以下附录R中示出了增强的示例消息。

如附录R所示，提供了对3GPP TS 29.328的可能改变，其允许针对服务X(可以是MCPTT或PTT)将设备注册或不将设备注册。此外，该信元包含针对MCPTT服务已经注册了IMS用户的设备的设备ID。

在第一认证机制之后，可以如上面关于图12的第二认证机制1222所描述的那样发生第二认证机制1470。

此外，一旦第一认证步骤成功，HSS 1422就更新网络以使用不同的公共用户标识，提供了两个可选元素。在第一可选机制中，HSS 1422可以用更新的PCC消息1484更新PCC1482。然后，PCC可以以消息1486来更新P-CSCF 1412。

然后，P-CSCF 1412可以转换传入消息。因此，UE 1410可以发送具有第二公共标识的INVITE 1488，然后在P-CSCF 1412处转换该邀请以反映第一标识，如消息1490所示。

在另一备选方案中，HSS 1422可以修改针对第一公共用户标识的简档，如消息1494所示，然后可以以消息1495向P-CSCF 1412通知消息1494。

然后，UE 1410可以提供具有第二用户标识的INVITE，由消息1496所示，可以由P-CSCF 1412转换该邀请。然后，P-CSCF 1412可以转发INVITE，但该INVITE具有第一用户标识，如消息1498所示。

带外互助

在带外解决方案的另一实施例中，执行第一认证机制，其中附加增强允许网络请求并且UE提供与在认证机制中在其上注册了UE的PLMN有关的信息。然后，该PLMN信息用于确定应联系哪个公共服务安全提供商。

从第一公共安全运营商的MCPTT服务器向第二公共安全运营商的PS-UDF发送新消息以请求专用用户ID。这种消息可以包括被认证用户的公共用户ID。

然后，第二公共安全运营商的PS-UDF反向提供专用用户ID和公共用户ID。然后，可以经由消息发送向UE发送该信息，消息发送比如为开放移动联盟(OMA)设备管理、超文本传输简档(HTTP)、XML配置访问协议(XCAP)或空中下载(OTA)消息到USIM或ISIM应用，其中呈现了存储该信息的新字段。

然后，UE可以使用新的专用用户标识和公共用户标识符来执行第二认证机制。当第二安全运营商的PS-UDF接收到第二认证机制时，PS-UDF然后联系第一公共安全运营商的PS-UDF以获得凭证，并且使用这些凭证来认证用户。

现在参考图15，其中UE 1510通过TTLS/IPSec服务器1512与第一MCPTT运营商1520的PS-UDF 1514和MCPTT服务器1516通信。PLMN 1524的S-CSCF 1522用于第一运营商1520的MCPTT。注意，TTLS/IPSec服务器1512可以与PS-UDF 1514和MCPTT服务器1516中的任一个或两者组合。这样的实现如虚线1590所示。

第二MCPTT运营商1526具有第二PS-UDF 1528。

在图15的实施例中，UE 1510包含第一专用用户标识、第二公共用户标识、设备标识和可以链接到第一专用用户标识和/或公共用户标识的证书。

提供了第一认证机制1530。作为认证机制1530的可选第一部分的一部分，UE 1510可以与TTLS/ipsec服务器1512建立TTLS/ipsec隧道，如消息1532所示。在一个实施例中，TTLS/ipsec服务器可以是AAA服务器、PS-UDF或MCPTT AS，或者可以是这些服务器中的一些或全部服务器的组合。

作为隧道建立的一部分，UE 1510包括证书。可能的证书机制如下所述。证书可以具有设备和/或与该设备一起使用的专用用户ID之间的关系。作为这种机制的一部分，网络可以向UE请求特定属性。这样的属性可以包括但不限于：标识用户设备和在其上注册了UE的网络的标识。

通过从网络向UE发送请求来请求这些属性。如果TTLS/ipsec服务器1512与AAA服务器(未示出)或PS-UDF通信，则AAA服务器或PS-UDF可以经由TTLS/ipsec服务器向UE发送属性请求。或者，如果所有服务器都组合在网络节点中，则网络节点向UE发送针对属性的请求。

针对这样的请求可以提供EAP扩展属性。例如，这些在附录S中示出，附录S示出了八位字节可以用于请求某些信息。

然后可以使用第一认证机制。以上关于图12或图14描述了这种第一认证机制的示例。

如消息1534所示，认证机制可以提供某些信息。在一个选项中，UE可以发送包括要被认证的第二公共用户标识的标识。要被发送的可选附加信息可以包括但不限于标识设备和/或在其上UE正在或已注册的网络的设备标识符。该附加信息可以由网络节点获得，例如通过PS-UDF 1514向UE发送消息来获得。这样的消息可以包括请求附加信息的指示符，附加信息包括例如在其上注册了UE的PLMN、设备ID以及其它信息。UE接收该消息并向网络发送消息(例如，发送到PS-UDF)，消息包含标识设备和/或在其上UE正在或已注册的网络的设备标识符。

可以基于在UE处接收到消息请求来发送附加信息，如附录S中所示。

在成功认证之后，PS-UDF 1514向MCPTT AS 1516发送对第二公共用户标识的认证已成功的指示。这以消息1536示出。还可以指示第一专用用户标识、第一公共用户标识、第二公共用户标识、PLMN和IMEI。在一个实现中，PS-UDF 1514可以是MCPTT AS。以下附录T中示出了对3GPP TS 24.302规范的可能改变的一个示例。注意，第一公共用户标识可以从在认证机制1530中发生的证书交换中导出的，这在下面更详细地说明。

当第一认证机制1530完成时，配置机制1540可以发生。本领域技术人员将理解，以消息1534示出的认证机制可以被分解为如所述的但不限于认证机制1440、1220等。

在配置机制期间，可以从UE 1510向MCPTT AS1516提供消息1542。消息1542可以可选地向网络提供配置请求。消息1542可以包含在其上已经注册了UE的网络的PLMN标识。可以发生该请求，因为UE使用OMA管理对象来配置MCPTT标识。

然后，MCPTT AS1516可以向第二MCPTT运营商1526请求第二专用标识符和第三公共用户标识，如消息1544所示。消息1544可以包含如下项中的0个或多个：第一专用用户标识、第一公共用户标识、第二公共用户标识。可以基于静态配置或通过对UE注册的PLMN标识执行DNS查找来导出MCPTT运营商1526。

第二PS-UDF 1528接收消息1544。在一个实施例中，MCPTT AS可以仅向第二PS-UDF1528发送第一公共用户ID，以便确保不释放第一专用用户ID。

第二PS-UDF 1528将第二专用用户ID与以下内容(如果接收到的话)相关联：第一专用用户标识；第一公共用户标识；第二公共用户标识；和/或设备标识。

PS-UDF 1528以消息1546发回第二专用用户标识和第三公共用户标识中的至少一个。MCPTT AS 1516接收第二专用用户标识和第三公共用户标识中的至少一个。

然后可以向UE提供数据。数据模型可以在下面的图16中找到，其中UE提供有专用标识符和公共标识符。本领域技术人员将理解，这是描述数据集合的OMA设备管理(DM)对象的示例。然而，它可以同样用作抽象数据模型。例如，专用标识符可以是如在E.212中定义的IMSI或如在RFC 4282中定义的网络地址指示符(NAI)。公共ID可以是如由E.164定义的MSISDN或如由RFC 4282定义的NAI，其中NAI也可以包含表示MSISDN的数位串。

针对这些标识的有效区可以特定于PLMN、PLMN内的区域、地理区域或甚至WLAN或其组合。

出于描述图16的目的，应使用书/小说的类比。然而，如所确定的，OMA DM详细描述了图表的命名。因此，参考图16，MCPTT 1610可以具有0到多个页，如块1612所示。

在图16的实施例中，问号指示可选元素。因此，一个选项元素包括一系列标识符1620。每个标识符可以是专用标识符1622或公共标识符1624，并且可以包括各种段落(例如，数据项集合)1626和1628，段落1626和1628可以包括IMSI或专用用户标识符或者MSISDN或公共用户标识符。注意，一个集合可以包含0到多个条目。

每个页还可以包含有效区1630。有效区可以基于3GPP位置1632、3GPP2位置1634、WLAN位置1636或地理位置1638等。

然后，每个位置可以使用若干准则来进行确定。因此，3GPP位置可以具有各种段落1640，并且可以包括信息，信息比如为PLMN、类型分配码(TAC)、位置区码(LAC)、GSM边缘无线电接入网(GERAN)小区标识符(CI)、通用移动电信服务(UMTS)地面无线电接入网(UTRAN)CI、演进的通用地面无线电接入(EUTRA)CI、以及其它信息。

3GPP2位置可以具有检查以确定连接是否是1x连接(如块1650所示)，在这种情况下，可以提供多个段落1552。这些段落中的信息可以包括系统ID(SID)、网络ID(NID)或基本ID。

类似地，如果3GPP位置是高速分组数据(HRPD)(如块1654所示)，则可以提供多个页1656。这些页可以包括诸如扇区ID或网络掩码之类的信息。

WLAN位置1636可以具有各种段落1662。这些段落中的信息可以包括同质扩展服务集标识符(HESSID)、服务集标识符(SSID)、或基本服务集标识符(BSSID)以及其它信息。

地理位置1638可以具有检查以确定它是否是圆形位置(如块1670所示)，在这种情况下，可以提供多个段落1672。这些段落中的信息可以包括锚点纬度、锚点经度和半径等其它信息。

此外，地理位置1638可以进行检查以确定该位置是否是多边形(如块1684所示)，在这种情况下，可以提供多个段落1686。

段落1686可以包括包括坐标1688，坐标1688本身具有多个段落1690。段落1690中的信息可以包括纬度和经度。

再次参考图15，一旦MCPTT 1516接收到消息1546的信息，则可以在UE和MCPTT之间发生配置，如箭头1550所示。在箭头1550中，如果使用USIM/ISIM，则MCPTT AS发送至少包含但不限于第二专用用户ID和第三公共用户ID以及可选的PLMN信息的消息。

在一个实施例中，消息1546和1550是可选的，并且在这种情况下，MCPTT AS 1516将需要产生第三公共用户ID。然而，在这种情况下，将不会产生第二专用用户ID。

在MCPTT AS 1516中，在以下项中的一些或全部项之间发生映射：第一专用用户标识；第一公共用户标识；第二公共用户标识；设备标识；第二专用用户标识；以及第三公共用户标识。

消息1550可以是包含空中下载(OTA)信息的短消息服务(SMS)消息。空中下载消息序列可以包括具有限定符“MCPTT专用用户ID更新”的USAT REFRESH命令。

当在消息1550处接收到配置信息时，UE可以解码该消息。SMS目的地地址可以是第二公共用户ID。在一个实施例中，附录U示出了可以对3GPP TS 31.103规范的可能改变，这样的改变可以同样应用于3GPP TS 31.102。

此外，可以根据附录V提供命令细节，附录V示出了对ETSI TS 102 223规范的可能改变。

如果ME接收到“MCPTT专用用户ID更新”类型的USAT REFRESH命令限定符，则ME可以更新设备上的专用标识符。

备选地，如果使用OMA DM、HTPP或XCAP，则UE通过向网络(例如，MCPTT AS等)发送消息来接收针对UE的配置。网络将用可以包括专用ID、公共ID和网络代码中的一个或多个的配置信息来反向进行响应。关于图16示出了可以发送的信息。

一旦配置机制1540完成，就可以发生第二认证机制1560。第二认证机制1560包括注册消息1562。这样的消息可以是包含第二专用用户ID和可选的第三公共用户标识符的SIP注册。如果未能以消息1550的配置信息接收到第二专用用户ID，则第一专用用户ID将需要与第三公共用户标识符一起使用。

如本领域技术人员将认识到的，要使用的公共用户标识符和专用用户标识符将基于在其上注册了UE的PLMN。这意味着如果ME可以将注册的PLMN(RPLMN)与图16的有效区/3GPP位置/<x>/PLMN叶中的PLMN进行比较。如果匹配，则所使用的公共用户ID和专用用户ID与该PLMN相关联。当信息存储在如附录U所示的USIM/ISIM中时，ME将比较RPLMN和PLMN字段，并选择适当的数据。

S-CSCF接收消息1562并且可以可选地向PS-UDF 1528提供消息1564。仅在消息1562中使用了第二专用用户标识的情况下，才发生消息1564。第二PS-UDF 1528接收消息1564，并且PS-UDF 1528可以使用该信息来创建映射。然后，可以向MCPTT 1516发送消息1566以获得针对第一专用ID(如果可用的话)的认证向量，否则获得针对第一公共用户ID的认证向量。例如，消息1566在其内容中包含第一专用ID(如果可用)和/或第一公共用户ID。

MCPTT 1516接收该消息，并且向PS-UDF 1514发送消息1570，以请求针对第一专用ID(如果可用的话)和/或第一公共用户ID的认证向量。如果接收到第一公共用户ID，则MCPTT AS将使用上面创建的映射来确定专用用户ID。

PS-UDF 1514接收请求认证向量的消息1570并产生向量。然后，PS-UDF向MCPTT1516发回包含针对第一专用用户ID的认证向量的消息1572。

MCPTT 1516接收包含针对第一专用用户ID的认证向量的消息1572，并且向第二PS-UDF 1528发送该消息，如消息1574所示。然后，第二PS-UDF可以产生针对第三公共用户标识和第二专用用户标识的向量，并且这些向量可以被转发给UE，如消息1580和1582所不。

如本领域技术人员将会理解的，图15仅是示例。在备选实施例中，UE可以使用存储在UE上的专用用户标识和公共用户标识来首先执行第二认证。然后，UE可以随后执行第一认证机制。

此外，在以上公开的上下文中，在许多实施例中用标签1222、1430、1470、1560描述了第二认证机制。可以理解，这些示例是基于SIP REGISTRATION过程的，该过程也包括可选的认证组件。上面关于图2描述了这种SIP注册处理。根据3GPP TS 33.203，第二认证机制通过UE向网络发送SIP注册消息而开始，然后UE从网络接收包含认证挑战的消息，其中UE将用另一注册消息来对该认证挑战做出响应。

证书产生处理

在另一实施例中，替代用以获得专用ID、公共ID和设备ID的以上列出的对协议的增强，也可以使用证书，该证书也可以与上述那些实施例结合地使用。

UE执行如上所述的第一认证机制过程并建立隧道。在建立隧道之后，可以使用任何认证方案对第一公共用户标识进行认证。这些认证方案的示例包括EAP、挑战握手认证协议(CHAP)、密码认证协议(PAP)或消息摘要5(MD-5)等。

因此，在UE与网络之间建立第一安全隧道，然后在隧道内对公共用户标识进行认证。

在最初的隧道建立中，可以提供证书。例如，该证书可以是x.509证书。根据下面的描述，可以以新的方式创建证书。在一个实施例中，证书可以是预提供的，并且可以链接到设备ID或者来自UICC的专用用户标识符。

隧道的建立在网络中创建设备与专用标识符之间的关系。然后在ME和AAA服务器之间开始公共用户标识认证阶段。如果AAA服务器与TTLS服务器位于同一位置，则在TTLS服务器中存在设备ID、专用ID和公共用户ID之间的关系。TTLS/AAA服务器可以是IMS AS，并且在以上描述的上下文中，TTLS/AAA服务器也可以是MCPTT AS。

UE执行诸如IMS注册的第二认证机制，这样的认证机制可以在第一认证机制之前或之后发生(例如，第二认证机制可以是EAP-TTLS过程)。在IMS注册中，设备包括在第一认证机制(例如，其可以是EAP-TTLS操作)中链接到证书的专用用户标识符和第二公共用户标识。IMS网络中的S-CSCF向MCPTT AS执行第三方注册，第三方注册可以包括但不限于IMS专用用户标识符、针对IMS的第二公共用户标识符和设备标识符。

此时，现在，在MCPTT AS与IMS专用用户标识符、第二IMS公共用户标识符、第一公共IMS用户标识符和设备标识符之间存在着联系。

现在，当MCPTT AS接收到会话请求时，它可以选择向IMS网络隐藏IMS第二公共用户ID。

现在参考图17，其示出了UE 1710、P-CSCF 1712、具有S-CSCF 1716和MCPTT AS1718的第一公共安全机构1714。

MCPTT AS 1718包括PS-UDF 1720和AAA 1722。

第二公共安全机构1724包括HSS 1726。

在图17的实施例中，首先发生第二认证机制1730，在该机制中发生UE和第二公共安全机构之间的注册。注册包括第一专用标识和第二公共标识。特别地，如块1732所示，注册包括第一专用ID和第二公共用户ID。

基于块1732的注册消息，可以发生第三方注册1734。

UE将使用存储在设备上的IMSI中的第一专用用户ID和第二公用用户ID来开始第二认证处理。在该处理完成时，S-CSCF将向MCPTT AS进行第三方注册。第三方注册中包括第一专用用户ID和第二公共用户ID。MCPTT服务器将接收此信息，然后针对所存储的数据将第一专用用户ID与第二公共用户ID映射。

当第二认证成功时，开始第一认证机制1740。第一认证机制1740的第一部分是隧道建立1742。在图17的示例中，MCPTT AS 1718具有认证功能以及利用该MCPTT AS建立的隧道。

如块1744所示，接下来进行隧道认证。在UE和网络之间交换证书。证书使得可以根据其导出以下一些或全部项：(U)/ISIM上的第一专用用户ID；(U)/ISIM上的第二公共用户ID；以及IMEI或设备标识符。在隧道建立认证处理期间，MCPTT AS 1718将创建这些项目之间的关系的数据库。

如块1746所示，在成功创建隧道之后，将开始另一认证处理以认证使用设备的公共用户ID。例如，该ID可以是警察凭证。这将被称为第一公共用户ID。

在成功认证时，MCPTT会将该标识符与存储在上述数据库中的信息相关联，如箭头1750所示。

下文提供了证书的示例。

第一证书选项

现在参考图18，其示出了在块1810处检测新的专用标识符和在块1812处产生证书的设备。产生证书包括以设备标识符1814和专用标识符1816作为产生块1812的输入。块1810和1816都包含相同的专用用户标识。

证书1820被提供为产生块1812的输出。

在一个实施例中，该设备可以包含或不包含初始证书。当检测到新的UICC被插入到设备中，或者检测到IMSI或UICC码已经改变，或者新的USIM或ISIM被激活时，设备将请求新的证书。激活可以例如是IMSI或IMS专用用户标识已经改变。

所创建的证书将标识UICC/USIM/ISIM与ME的组合。

第二证书选项

在第二证书选项中，设备ME_A被提供有第一证书，其中第一证书包含用于验证由第一私钥创建的签名的第一公钥。第一私钥也被提供给ME_A。

USIM_A被插入到具有IMSI_A的设备中，并且用户User_A使用用户ID UserIdA和密码pwdA登录到设备中。

设备ME_A在时间T_now处签名[IMSI_A，pwdA，T_now]，以形成签名SigA。

设备向可以执行以下操作的公共安全运营商发送证书CertA、SigA、[IMSI_A，UserIdA，T_now]：

1)根据CertA识别ME_A

2)根据UserIdA和pwdA识别User_A(假设公共安全运营商有自己的pwdA副本)

3)根据IMSI_A识别USIM_A

所有这些标识可以通过验证SigA而被认证，其中：

1)使用IMSI_A、UserIdA和密钥KeyA、T_now来计算签名SigA。

2)使用SigA、IMSI_A、UserIdA、T_now和公钥PubKeyA来认证签名SigA

因此上述提供了在不需要改变UICC的情况下对共享设备的用户进行认证的手段。该解决方案为使用电话的用户提供各种程度的保密性。在后的带外解决方案提供了隐藏用户的手段，从而允许公共安全运营商决定在IMS网络中什么信息应该是可见的。在后的带外解决方案还提供了IMS认证机制和用户认证机制之间的各种程度的联系。

上文创建了一种联系，使得当用户在该设备上进行认证时，必须在该设备上继续会话，除非他们再次进行认证。单次登录不允许用户在设备之间交换UICC SIM卡以用于不良目的。设备上的证书可以使得它们只能由公共安全运营商来提供，从而在网络上仅允许使用有效设备。

上述图1至图17的实施例中的服务器和网元可以是任意网元，或者是任意网元的一部分，包括各种网络服务器。现在参考图19，其示出了一般化的网元。

在图19中，网元1910包括处理器1920和通信子系统1930，其中，处理器1920和通信子系统1930协作以执行上述实施例的方法。

处理器1920被配置为执行可编程逻辑，该可编程逻辑可以与数据一起存储在网元1910上并且在图19的示例中被示出为存储器1940。存储器1940可以是任意有形非暂时性存储介质。

备选地或者除了存储器1940之外，网元1910可以例如通过通信子系统1930从外部存储介质访问数据或可编程逻辑。

通信子系统1930允许网元1910与其它网元进行通信。用于通信子系统1930的协议的示例包括蜂窝、以太网、WiFi、WiLAN等等。

在一个实施例中，网元1910中的各个要素之间的通信可以通过内部总线1950进行。然而，其它形式的通信是可能的。

此外，以上可以通过任何UE来实现。以下关于图20描述了一个示例性设备。

UE 2000是典型的具有语音和数据通信能力的双向无线通信设备。UE 2000一般具有与互联网上的其它计算机系统通信的能力。根据所提供的精确功能，作为示例，UE可以称为数据消息收发设备、双向寻呼机、无线电子邮件设备、具有数据消息收发能力的蜂窝电话、无线互联网设备、无线设备、移动设备、或数据通信设备。

在UE 2000支持双向通信的情况下，其可以包含通信子系统2011，通信子系统1211包括接收机2012和发射机2014二者、以及相关联的组件(例如，一个或多个天线要素2016和2018、本地振荡器(LO)2013、以及诸如数字信号处理器(DSP)2020等的处理模块)。通信领域技术人员将显而易见，通信子系统2011的特定设计将取决于想要使设备操作于其间的通信网络。

网络接入需求还将根据网络2019的类型而变化。在一些网络中，网络接入与UE2000的订户或用户相关联。UE可以需要可移动用户标识模块(RUIM)或订户标识模块(SIM)卡以在CDMA网络上操作。SIM/RUIM 2044通常类似于可以向其插入和从其弹出SIM/RUIM卡的卡槽。SIM/RUIM卡可以具有存储器，并保存许多关键配置2051以及其它信息2053(比如，标识和与订户相关的信息)。

当已经完成了所需的网络注册或激活过程时，UE 2000可以通过网络2019发送和接收通信信号。如图20中所示，网络2019可以由与UE进行通信的多个基站组成。

将由天线2016通过通信网络2019接收的信号输入接收机2012，接收机2016可以执行诸如信号放大、下变频、滤波、信道选择之类的共用接收机功能。接收信号的A/D转换允许在DSP 2020中执行更复杂的通信功能(比如，解调和解码)。以类似的方式，通过DSP 2020处理(包括例如调制和编码)要被发送的信号，并且处理后的信号被输入到发射机2014以用于数模转换、上变频、滤波、放大、以及经由天线2018通过通信网络2019进行发送。DSP 2020不仅处理通信信号，而且还提供对接收机和发射机的控制。例如，可以通过在DSP 2020中实施的自动增益控制算法来自适应地控制施加于接收机2012和发射机2014中的通信信号的增益。

UE 2000通常包括处理器2038，处理器2038控制设备的整体操作。通过通信子系统2011来执行包括数据通信和语音通信的通信功能。处理器2038还与其它设备子系统进行交互，所述其它设备子系统例如是显示器2022、闪存2024、随机存取存储器(RAM)2026、辅助输入/输出(I/O)子系统2028、串行端口2030、一个或多个键盘或键区2032、扬声器2034、麦克风2036、诸如短距离通信子系统的其它通信子系统2040和概括地指定为2042的其它设备子系统。串行端口2030可以包括USB端口或本领域技术人员已知的其它端口。

图20中示出的一些子系统执行通信相关功能，而其它子系统可以提供“驻留”或机载(on-device)功能。值得注意的是，一些子系统(比如，键盘2032和显示器2022)例如可以既用于通信相关功能(比如，输入文本消息以用于通过通信网络发送)，也用于设备驻留功能(比如，计算器或任务列表)。

可以在诸如闪存2024(其替代地可以是只读存储器(ROM)或类似的存储单元(未示出))的永久性存储器中存储处理器2038使用的操作系统软件。本领域技术人员将理解，操作系统、设备专用应用或其一部分可以被暂时性地加载到易失性存储器(比如，RAM 2026)中。所接收的通信信号也可以存储在RAM 2026中。

如所示，可以将闪存2024分隔成用于计算机程序2058和程序数据存储2050、2052、2054和2056的不同区。这些不同的存储类型指示每个程序可以针对它们自己的数据存储需求而被分配闪存2024的一部分。处理器2038，除了其操作系统功能之外，还可以能够执行UE上的软件应用。一般将在制造期间在UE 2000上安装控制基本操作的预定应用集合(例如至少包括数据和语音通信应用)。可以随后或动态地安装其它应用。

应用和软件可以存储在任何计算机可读存储介质上。计算机可读存储介质可以是有形的或者暂时/非暂时的介质，例如光学的(如CD、DVD等)、磁的(如磁带)或本领域已知的其它存储器。

一种软件应用可以是个人信息管理器(PIM)应用，其具有组织和管理与UE的用户相关的数据项(例如但不限于，电子邮件、日历事件、语音邮箱、约会和任务项)的能力。当然，一个或多个存储器将在UE上可用，以便于存储PIM数据项。此PIM应用可以具有经由无线网络2019发送及接收数据项的能力。还可以通过网络2019、辅助I/O子系统2028、串行端口2030、短距离通信子系统2040或任何其它适合子系统2042将另外的应用加载到UE 2000中，并且可以由用户将这些应用安装于RAM 2026或非易失性存储器(未示出)中以供处理器2038执行。应用安装的这种灵活性增加了设备的功能，并且可以提供增强的机载功能、通信相关功能或两者。例如，安全通信应用可以使得能够使用UE 2000来执行电子商务功能和其它这种金融交易。

在数据通信模式中，将通过通信子系统2011处理诸如文本消息或网页下载之类的接收到的信号，并且将处理后的信号输入到处理器2038，处理器2038可以进一步处理接收到的信号，以输出至显示器2022或备选地输出至辅助I/O设备2028。

UE 2000的用户还可以例如使用键盘1232结合显示器2022和可能的辅助I/O设备2028编写诸如电子邮件消息之类的数据项，该键盘2032可以是全的字母数字键盘或电话类型的键区等。然后可以通过通信子系统2011、通过通信网络发送这种编写而成的项目。

对于语音通信，UE 2000的整体操作类似，除了通常可以将所接收的信号输出到扬声器2034，以及可以由麦克风2036来产生用于发送的信号。还可以在UE 2000上实现备选的语音或音频I/O子系统，例如语音消息记录子系统。尽管语音或音频信号输出通常主要通过扬声器2034来完成，但是显示器2022也可以用来提供对例如呼叫方的标识、语音呼叫的持续时间、或其它语音呼叫相关信息的指示。

图20中的串行端口2030通常实现在个人数字助理(PDA)类型的UE中，这种类型的UE可能需要与用户的台式计算机(未示出)的同步，但是串行端口2030是可选的设备组件。这样的端口2030将使用户能够通过外部设备或软件应用来设置偏好，并且可以通过除经由无线通信网络之外的其它方式向UE 2000提供信息或软件下载来扩展UE 2000的能力。例如可以使用备选下载路径通过直接连接(因此是可靠且可信的连接)将加密密钥下载到设备上，从而实现安全设备通信。本领域技术人员应该理解，串行端口2030还可用于将UE连接至计算机以充当调制解调器。

其它通信子系统2040(例如，短距通信子系统)是可以在UE 2000和不同系统或设备(不一定是类似设备)之间提供通信的另一可选组件。例如，子系统2040可以包括红外设备和相关联的电路和组件、或蓝牙^TM通信模块，以提供与支持类似功能的系统和设备的通信。子系统2040还可以包括非蜂窝通信，诸如WiFi或Wimax。

本文描述的实施例是结构、系统或方法的示例，其具有与本申请技术的要素相对应的要素。该书面描述可以使本领域技术人员能够做出并使用具有同样与本申请的技术的要素相对应的备选要素的实施例。本申请技术的意向范围因此包括并非不同于本文中所描述的本申请的技术的其它结构、系统或方法，并且还包括与本文中所描述的本申请技术具有非实质性差异的其它结构、系统或方法。

图21是示出了根据实现的示例MCPTT系统2100的应用层架构的示意图。

MCPTT用户标识也称为MCPTT ID。MCPTT ID是MCPTT服务中表示MCPTT用户的全局唯一标识符。MCPTT ID标识MCPTT用户。MCPTT ID指示其中定义了MCPTT ID的MCPTT系统，还可以标识在MCPTT应用层处的针对用户的MCPTT简档。

存在与MCPTT服务中配置的MCPTT ID相关联的属性，这些属性与MCPTT服务的人类用户相关。该信息可以通过姓名或角色标识MCPTT用户，并且还可以标识用户的组织或机构。MCPTT服务器可以使用与MCPTT ID相关联的这些属性来做出与向用户授予的MCPTT服务有关的认证决定。例如，MCPTT服务可以自动使用将用户角色标识为事件指挥官的属性，以向用户授予创建组或接入特权通话组的附加管理权限。

MCPTT ID被格式化为URI。MCPTT ID唯一标识MCPTT系统中的MCPTT用户。

MCPTT组标识也称为MCPTT组ID。MCPTT组ID是MCPTT服务中的表示MCPTT用户集合的全局唯一标识符。该MCPTT用户集合可以属于相同或不同的MCPTT系统。针对(组内的)每个用户的MCPTT系统由每个用户的相应MCPTT ID标识。

MCPTT组ID标识MCPTT系统中的MCPTT组。MCPTT组ID指示其中定义了MCPTT组的MCPTT系统、以及MCPTT系统中的其中定义了该组的MCPTT服务器。MCPTT组ID可以用于标识其组成员的标识集合，并且由MCPTT客户端用于寻址该MCPTT组。MCPTT组ID被格式化为URI。

在高级层面上，示例MCPTT系统2100包括通过EPS 2130与MCPTT UE 2140通信耦接的MCPTT服务器2110。MCPTT服务器2110还与公共服务核2120通信耦接。如所示，示例MCPTT系统2100还可以包括其它组管理服务器2108、其它MCPTT服务器2102、MCPTT用户数据库2104、以及与旧有(1egacy)系统的互通功能2106。

公共服务核2120表示可以被配置为提供共用服务的应用、应用集、软件、软件模块、硬件或其组合。如所示，公共服务核2120包括组管理服务器2122、配置管理服务器2124、标识管理服务器2126和密钥管理服务器2128。

组管理服务器2122表示可以被配置为管理MCPTT服务提供商内支持的组的应用、应用集、软件、软件模块、硬件或其组合。组管理服务器2122可以由SIP应用服务器(AS)和信令控制平面的HTTP服务器功能实体支持。在一些情况下，支持属于单个组的用户的组管理客户端可以针对该组使用相同的组管理服务器。支持涉及多个组的用户的组管理客户端可以与多个组管理服务器有关系。组管理服务器2122可以管理媒体策略信息以供UE用于媒体混合。组管理服务器还可以管理组呼叫策略信息以供UE用于联网和离网组呼叫控制。

配置管理服务器2124表示利用非组管理MCPTT服务相关信息配置MCPTT应用并且对配置管理客户端上的数据进行配置的应用、应用集、软件、软件模块、硬件或其组合。配置管理服务器2124管理MCPTT服务提供商内支持的MCPTT服务配置。配置管理服务器2124可以由SIP AS和信令控制平面的HTTP服务器功能实体支持。

标识管理服务器2126表示可以被配置为管理MCPTT用户的用户ID的代理的应用、应用集、软件、软件模块、硬件或其组合。标识管理服务器2126可以通过验证由MCPTT用户提供的凭证来认证用户ID。在一些情况下，标识管理服务器2126可以实现在与MCPTT服务器2110相同的域内。

密钥管理服务器2128表示可以被配置为存储安全相关信息(例如，加密密钥)的应用、应用集、软件、软件模块、硬件或其组合。密钥管理服务器2128可以向密钥管理客户端、组管理服务器2122、MCPTT服务器2110或其任何组合提供安全相关信息，以提供媒体和信令的保密性和完整性。

MCPTT服务器2110表示为MCPTT服务提供集中支持的应用、应用集、软件、软件模块、硬件或其组合。在一些情况下，支持属于单个组的用户的MCPTT客户端可以针对该组使用相同的MCPTT服务器。支持涉及多个组的用户的MCPTT客户端可以与多个MCPTT服务器有关系。

MCPTT服务器2110可以由SIP AS、HTTP客户端和信令控制平面的HTTP服务器功能实体支持。

MCPTT服务器2110可以支持控制角色和参与角色。针对专用呼叫和组呼叫，MCPTT服务器2110可以执行控制角色。针对专用呼叫或组呼叫执行控制角色的MCPTT服务器2110还可以针对相同的专用呼叫或组呼叫执行参与角色。对于每个专用呼叫和组呼叫，可以有一个MCPTT服务器承担控制角色，而在参与角色方面，可以涉及一个或多个MCPTT服务器。

执行控制角色的MCPTT服务器可以负责以下功能：

-面向组呼叫和专用呼叫的所有MCPTT用户的呼叫控制(例如，参与MCPTT组呼叫的策略实施)；

-管理在组呼叫和专用呼叫中的发言权(floor)控制实体；以及

-管理呼叫中的媒体处理实体(即，会议、转码)。

执行参与角色的MCPTT服务器可以负责以下功能：

-对针对组呼叫和专用呼叫的MCPTT用户的呼叫控制(例如，用于参与MCPTT组呼叫的认证)；

-针对MCPTT用户的组附属支持，包括用户实施最大N2数量个同时组附属；

-在MCPTT客户端和执行控制角色的MCPTT服务器之间中继呼叫控制和发言权控制消息；以及

-针对呼叫的MCPTT用户在呼叫中进行媒体处理，即针对单播和多播媒体的转码、记录、合法拦截。

对于涉及来自主要和伙伴MCPTT系统的多个组的组重新分组，

-临时组的组主机MCPTT服务器执行控制角色，负责集中发言权控制，并且根据临时组或用户策略(例如，优先级)进行仲裁；

-组成MCPTT组的组主机MCPTT服务器负责向其组成员提供呼叫邀请，并且根据组成组或用户策略(例如，优先级)过滤组成组成员的发言权控制请求；以及

-负责组成MCPTT组成员的MCPTT服务器执行参与角色。

MCPTT服务器2110可以包括媒体分发功能2112和发言权控制服务器2114。

媒体分发功能2112表示可以被配置为将媒体分发给呼叫参与者的应用、应用集、软件、软件模块、硬件或其组合。使用由MCPTT服务器2110提供的信息(例如，IP地址、传输层端口等)，媒体分发功能2112可以提供以下功能：

-借助于MCPTT-7参考点提供上行链路MCPTT UE媒体传输的接收；

-根据需要复制媒体，以便使用单播传输分发给那些参与者；

-通过借助于MCPTT-7参考点使用单播传输向那些参与者进行IP单播发送来向MCPTT UE分发下行链路媒体；

-借助于MCPTT-8参考点针对呼叫使用媒体的多播下行链路传输来向MCPTT UE分发下行链路媒体；以及

-提供媒体混合功能，其中多个媒体流被组合成单个媒体流，以用于向MCPTT UE发送。

如果在媒体分发功能2112内发生媒体混合功能，则媒体混合功能独立于UE中的媒体混合器而操作。在媒体被端对端加密的情况下，媒体分发功能2112内的媒体混合功能会是不可能的。

发言权控制服务器2114表示可以被配置为提供用于联网的集中发言权控制和用于离网操作的分发发言权控制的应用、应用集、软件、软件模块、硬件或其组合。发言权控制服务器2114可以在不同用户之间提供发言权控制请求之间的仲裁，响应于成功请求而授予发言权，并且在竞争的情况下提供排队。对于联网操作，发言权控制服务器2114可以位于与MCPTT服务器2110相同的位置处。对于离网操作，发言权控制服务器2114可以位于MCPTT UE2140中。

MCPTT UE 2140是参与MCPTT呼叫的UE。MCPTT UE 2140包括MCPTT客户端2150、组管理客户端2162、配置管理客户端2164、标识管理客户端2166、密钥管理客户端2168。

MCPTT客户端2150表示可以被配置为用于MCPTT应用事务的用户代理的应用、应用集、软件、软件模块、硬件或其组合。MCPTT客户端2150可以报告MCPTT客户端2150当前所处的位置的信息。MCPTT客户端2150包括媒体混合器2152和发言权参与者(floorparticipant)2154。

媒体混合器2152表示可以被配置为通过实施媒体策略信息来提供对将多个媒体流组合成一个媒体流的支持的应用、应用集、软件、软件模块、硬件或其组合。

发言权参与者2154表示可以被配置为处理发言权请求的应用、应用集、软件、软件模块、硬件或其组合。对于联网操作和离网操作两者，发言权参与者2154都可以位于与MCPTT UE 2140相同的位置处。

组管理客户端2162表示可以被配置为用于管理MCPTT组的应用用户代理的应用、应用集、软件、软件模块、硬件或其组合。组管理客户端2162与组管理服务器2122交互。组管理客户端2162可以由信令用户代理和信令控制平面的HTTP客户端功能实体支持。

配置管理客户端2164表示可以被配置为用于配置相关事务的应用用户代理的应用、应用集、软件、软件模块、硬件或其组合。配置管理客户端2164与配置管理服务器2124交互以提供和接收配置数据。配置管理客户端2164可以由信令用户代理和信令控制平面的HTTP客户端功能实体支持。

标识管理客户端2166表示可以被配置为用于针对MCPTT呼叫的用户ID事务的应用用户代理的应用、应用集、软件、软件模块、硬件或其组合。标识管理客户端2166与标识管理服务器2126交互。

密钥管理客户端2168表示可以被配置为用于密钥管理功能的应用用户代理的应用、应用集、软件、软件模块、硬件或其组合。密钥管理客户端2168与密钥管理服务器2128交互。密钥管理客户端2168和密钥管理服务器2128的功能可以包括在3GPP TS 33.179中指定的功能。

转到总体描述，UE(例如，MCPTT UE 2140)可以包括但不限于以下任何内容：计算设备、移动设备、移动电子设备、用户设备、移动站、订户站、便携式电子设备、移动通信设备、无线调制解调器、无线终端、电视机、打印机或其它外围设备、车辆或能够发送并接收数据的任何其它电子设备。移动设备的示例可以包括但不限于蜂窝电话、个人数字助理(PDA)、智能电话、膝上型电脑、平板电脑、个人计算机(PC)、寻呼机、便携式计算机、便携式游戏设备、可穿戴电子设备、健康/医疗/保健设备、相机、或具有用于经由无线通信网络传送语音或数据的组件的其它移动通信设备。无线通信网络可以包括在许可频谱和非许可频谱中至少一个上的无线链路。术语“移动设备”还可以指可以终止用户的通信会话的任何硬件或软件组件。此外，术语“用户装备”、“UE”、“用户装备设备”、“用户代理”、“UA”、“用户设备”和“移动设备”在本文中可以作为同义词使用。

MCPTT用户数据库2104表示可以被配置为存储与MCPTT服务提供商在应用平面处保存的MCPTT ID相关联的用户配置信息的信息的应用、应用集、软件、软件模块、硬件或其组合。用户配置信息可以由MCPTT服务提供商确定。

另一MCPTT服务器2102表示与MCPTT服务器2110交互的一个或多个MCPTT服务器。类似地，另一组管理服务器2108表示与组管理服务器2122交互的一个或多个组管理服务器。互通功能旧有系统2106表示在MCPTT系统2100与旧有系统之间提供互通功能的应用、应用集、软件、软件模块、硬件或其组合。

EPS 2130表示执行3GPP E-UTRAN网络的核网络功能的网络节点。在应用层，EPS2130提供MCPTT UE 2140与提供MCPTT服务的应用服务器之间的连接。

在操作时，MCPTT UE 2140中的标识管理客户端2166使用标识管理服务器向网络认证MCPTT用户标识A。然后，配置管理客户端2164与配置管理服务器2124建立安全(HTTPS/TLS)通信。配置管理客户端2164(使用配置管理服务器2124)从MCPTT用户数据库2104下载MCPTT用户简档。MCPTT用户简档可以包含用户可以联系的所有用户的MCPTT ID的联系人列表、以及用户可以联系的组的所有MCPTT组ID。MCPTT用户简档还包含下载用户简档的UE的用户的MCPTT ID。备选地，用户简档可以包含指向网络联系人列表或地址簿的一个或多个指针或引用，所述联系人列表或地址簿包含可以联系的MCPTT用户的MCPTT ID。这些联系人列表可以基于使用用户简档的MCPTT用户的角色(例如，现场急救人员)。用户简档或另一简档可以包含要使用的加密密钥以及可以由MCPTT UE 2140使用的服务的描述。MCPTT用户简档是XML文档，并且是使用HTTPS下载的。因此，可以使用TLS对MCPTT用户简档进行加密，并且在MCPTT用户简档递送到MCPTT UE 2140时可以不被PLMN运营商读取。

尽管将图21的要素示出为包括实现各种特征和功能的各种组件部件、部分或模块，然而这些要素可以代之以酌情包括多个子模块、第三方服务、组件、库等。此外，可以酌情将各组件的特征和功能组合到较少的组件中。例如，由图21中所示的多个实体执行的功能可以一起集成在单个软件或硬件实体中。备选地或附加地，由图21中所示的任何实体执行的功能可以在多个软件或硬件实体中单独实现。

图22是示出了根据实现的用于MCPTT用户认证的示例呼叫流程2200的流程图。如所示，呼叫流程2200可以由MCPTT UEa 2204、MCPTT UEb 2202、SIP核2210、标识管理服务器2214、MCPTT用户数据库2216和MCPTT服务器2218来实现。也可以使用附加的、更少的或不同的实体来实现呼叫流程2200。例如，由图22中所示的多个实体执行的功能可以一起集成在单个软件或硬件实体中。备选地或附加地，由图22中所示的任何实体执行的功能可以在多个软件或硬件实体中单独实现。

此外，也可以使用附加的、更少的或不同的操作来实现呼叫流程2200，所述操作可以按照所示的顺序或以不同的顺序执行。在一些情况下，例如可以将所述操作的一个或一组操作迭代或重复指定迭代次数或直到达到终止条件为止。

如所示，MCPTT UEa 2204执行MCPTT用户认证，并且可选地获回用户标识(专用和公共)、用户简档位置、以及将在随后SIP注册中使用的访间令牌。然后，MCPTT UEb 2202在某一时刻使用在认证步骤中接收的简档位置(如果接收到的话)或使用提供的信息从网络获得其用户简档。这两个操作都通过安全连接进行，上面描述了用户认证的示例。然后，MCPTT UEa 2204使用任何接收到的用户标识向网络进行IMS注册，并且包括令牌(如果在认证步骤中接收的话)。当MCPTT UEa 2204向MCPTT UEb 2202做出会话发起请求时，会话请求包括指向早期由MCPTT UEb 2202获得的并且还存储在网络中的用户简档中的条目的指针或引用，所述指针或引用标识用户简档内的使用MCPTT UEb的MCPTT用户b的条目。

在一些情况下，被标识为以用户简档发送的数据可以以不同用户简档发送。例如，可以接收地址簿、令牌、密钥值和向量来作为不同的用户简档。

在MCPTT用户认证阶段期间，标识管理服务器向UE指派MCPTT用户令牌。OpenID框架中使用的MCPTTUser令牌可以包括2个令牌：access_token和ID_token。可以使用OAuth2.0协议请求这些令牌。图25示出了根据实现的用于获得令牌的示例处理2500。如所示，在步骤7处，标识管理器服务器向UE返回access_token和ID_token。图26示出了根据实现的用于获得令牌的示例代码2602和2604。示例代码2602示出了包括access_token的消息，该access_token是字符串。id_token也显示为字符串。id_token和access_token是OPenID连接框架工作的一部分，其中使用JSON声明(也称为JSON属性)描述令牌。标准声明可以在例如http：//www.iana.org/assignments/jwt/jwt.xhtml找到。

id_token类似于标识卡的概念，并在JWT简档中被描述。id_token包含标识用户的属性，例如姓名、地址、电话号码等。示例代码2604示出了id_token的示例JSON声明模式。id_token被编码为字母数字字符串。如何在各方之间请求、加密和交换令牌的更详细描述可以在例如http：//openid.net/specs/openid-connect-core-1_0.html#CodeFlowAuth找到。

返回图22，在步骤1处，MCPTT UEa 2204向标识管理服务器2214发送请求以认证MCPTT UEa 2204。该请求可以包括针对MCPTT UEa 2204的MCPTT用户标识A。

标识管理服务器2214认证MCPTT用户标识A。可以使用图25中描述的处理来执行认证。可选地，在步骤1a处，标识管理服务器2214向MCPTT用户数据库发送MCPTT用户标识、第二IMS公共用户标识A、以及一个或多个令牌(例如，access_token、id_token)中的至少一个。

一个或多个令牌可以包括以下任何属性：

-来自网络的用户简档中的第二IMS公共用户标识A(IMPU2a)

-第二IMS专用用户标识A(IMPI2a)

-MCPTT用户标识

-密钥

-向量

-针对MCPTT用户简档的位置的URI。

以上属性可以被编码为JSON声明。在MPTT标识管理服务器2214中创建并存储在MCPTT用户标识A和第二IMS公共用户标识A(IMPU2a)、第二IMS专用用户标识A(IMPI2a)和令牌(例如，access_token、id_token)之间的关系。

MCPTT用户数据库2216可选地接收MCPTT用户标识A、第二IMS公共用户标识A、IMS专用用户标识A和一个或多个令牌中的至少一个。

一个或多个令牌可以包括以下任何属性：

-第二IMS公共用户标识A(IMPU2a)

-第二IMS专用用户标识A(IMPI2a)

-MCPTT用户标识

-密钥

-向量

-针对MCPTT用户简档的位置的URI。

MCPTT用户数据库2216更新包含MCPTT用户标识A的用户简档，并且创建与在步骤1中接收的数据(例如，第二IMS公共用户标识A、IMS专用用户标识A和令牌)的关系。MCPTT用户数据库2216可以用包含令牌中的一些属性(例如，与MCPTT用户标识A相关联的用户简档的URI)的消息来反向对标识管理服务器2214进行响应。这可以使标识管理服务器2214能够向MCPTT UEa 2204发送URI。

在步骤1b处，标识管理服务器2214反向向MCPTT UEa发送确认ack。ack可以包括以下至少一项：第二IMS公共用户标识A(IMPU2a)、一个或多个令牌(例如，access_token、id_token)。

一个或多个令牌可以包括以下任何属性：

-第二IMS公共用户标识A(IMPU2a)

-第二IMS专用用户标识A(IMPI2a)

-MCPTT用户标识

-密钥

-向量

-针对MCPTT用户简档的位置的URI。

以上这些属性可以被编码为JavaScript对象表示法(JSON)声明。当在MCPTT UEa2204的移动设备(ME)或通用集成电路卡(UICC)中接收到这些属性时，这些属性可以存储在存储器中。

在步骤2处，MCPTT Ueb 2202向标识管理服务器2214进行认证。与步骤1类似，MCPTT UEb 2202可以向标识管理服务器2214发送请求。该请求可以包括针对MCPTT UEb2202的MCPTT用户标识B。标识管理服务器2214可以认证MCPTT用户标识B，并反向向MCPTTUEb 2202发送ack。ack可以包括第二IMS公共用户标识B和一个或多个令牌(例如，access_token、id_token)中的至少一个。

一个或多个令牌可以包括以下任何属性：

-第二IMS公共用户标识B(IMPU2b)

-第二IMS专用用户标识B(IMPI2b)

-MCPTT用户标识

-密钥

-向量

-针对MCPTT用户简档的位置的URI。

标识管理服务器2214、MCPTT用户数据库2216或其组合可以存储MCPTT用户标识B与第二IMS公共用户标识B、第二IMS专用用户标识B和一个或多个令牌之间的关系。

在一些情况下，步骤2可以从另一网络节点或UE发起。步骤2还可以被包括作为接收针对用户简档的改变的通知的请求的步骤的一部分，这样的操作如结合步骤11所讨论的。

在步骤3处，MCPTT UEa 2204从网络获得用户简档。在一些情况下，用户简档的位置可以存储在MCPTT UEa 2204中的ME和UICC中或在MCPTT UEa 2204中的ME和UICC中预先提供、或者如前所述的在步骤1b处被接收。MCPTT UEa 2204可以接收以下信息之一：

-来自网络的用户简档中的第二IMS公共用户标识A(IMPU2a)

-第二IMS专用用户标识A(IMPI2a)

-密钥值

-向量值

-MCPTT用户标识。

在一些情况下，用户简档存储在ME或UICC的存储器中。当MCPTT用户标识签出，MCPTT用户标识C被认证或其组合时，可以删除或修改用户简档。

在步骤4处，MCPTT UEb 2202从网络获得用户简档。在一些情况下，用户简档的位置可以存储在MCPTT UEb 2204中的ME和UICC中或在MCPTT UEb 2202中的ME和UICC中预先提供、或者如前所述的在步骤2处被接收。MCPTT UEb 2202可以接收以下信息之一：

-来自网络的用户简档中的第二IMS公共用户标识B(IMPU2b)

-第二IMS专用用户标识B(IMPI2b)

-密钥值

-向量值

-MCPTT用户标识。

在步骤5处，MCPTT UEa 2204使用IMPU2a向SIP核2210进行注册。MCPTT UEa 2204还可以向SIP核2210发送令牌(例如，access_token)。在步骤5a处，SIP核2210向MCPTT服务器2218执行第三方注册过程。

在步骤6处，MCPTT UEb 2202使用IMPU2b向SIP核2210进行注册。MCPTT UEb 2202还可以向SIP核2210发送令牌(例如，access_token)。在步骤5a处，SIP核2210向MCPTT服务器2218执行第三方注册过程。

在步骤7处，MCPTT服务器2218发送消息以请求与第二IMS公共用户标识A和令牌(例如，access_token、id_token)中的至少一个相关联的MCPTT用户标识A。标识管理服务器2214确定与第二IMS公共用户标识A或令牌相关联的MCPTT用户标识A。标识管理服务器2214向MCPTT服务器2218发送包含所确定的MCPTT用户标识A的消息。

类似地，在步骤8处，MCPTT服务器2218发送消息以请求与第二IMS公共用户标识B和令牌(例如，access_token、id_token)中的至少一个相关联的MCPTT用户标识B。标识管理服务器2214确定与第二IMS公共用户标识A或令牌相关联的MCPTT用户标识A。标识管理服务器2214向MCPTT服务器2218发送包含所确定的MCPTT用户标识A的消息。

在步骤9处，MCPTT服务器2218发送消息以请求与MCPTT用户标识A、第二IMS公共用户标识A或一个或多个令牌(例如，access_token、id_token)中的至少一个相关联的用户简档。MCPTT用户数据库2216向MCPTT服务器2218发送与MCPTT用户标识A、第二IMS公共用户标识A或一个或多个令牌相关联的用户简档。用户简档可以包括密钥值、向量值、MCPTT用户标识或其任何组合。

在步骤10处，MCPTT服务器2218发送消息以请求与MCPTT用户标识B、第二IMS公共用户标识B或一个或多个令牌(例如，access_token、id_token)中的至少一个相关联的用户简档。MCPTT用户数据库2216向MCPTT服务器2218发送与MCPTT用户标识B、第二IMS公共用户标识B或一个或多个令牌相关联的用户简档。用户简档可以包括密钥值、向量值、MCPTT用户标识或其任何组合。

在步骤11处，MCPTT UEa 2204请求对用户简档的改变的通知。在一些情况下，该步骤可以在步骤2之前发生并且可能使得步骤2发生，因为MCPTT UEa 2204在其请求通知的存储器中没有用户简档。在步骤12处，MCPTT UEb 2202请求对用户简档的改变的通知。

在步骤13处，具有MCPTT用户标识A的MCPTT用户发起与具有MCPTT用户标识B的MCPTT用户的通信。MCPTT UEa 2204在存储器内确定哪个用户简档包含MCPTT用户标识B。在确定的步骤中，UE还确定与该用户简档相关联的引用或指针。MCPTT UEa 2204向网络发送包含指向要使用的用户简档的引用或指针的消息。引用或指针可以指示全局电话簿以及指向用户简档中的条目(指MCPTT用户标识B)的引用、指针或位置(例如，位置30)。在一些情况下，条目位置可以被加密。在一些情况下，加密后的条目位置可以包括偏移。该消息还可以包括第二IMS公共用户标识A(IMPU2a)。

在步骤13a处，MCPTT服务器2218从第二IMS公共用户标识A接收包括指向用户文件的引用或指针的消息。该消息还可以包括第二IMS公共用户标识A(IMPU2a)。

如果以该消息接收到偏移值，则MCPTT服务器2218可以确定条目位置被加密了。MCPTT服务器2218可以使用“密钥”和“向量”来执行解密并且获得条目位置。

在一些情况下，以下步骤a)至e)可以用于确定MCPTT用户标识A希望与之通信的MCPTT用户标识B。一旦找到MCPTT用户标识B，就可以通过反向使用相同的处理向PLMN运营商隐藏MCPTT用户标识A。在这些情况下，当向MCPTT用户标识B发送SIP消息时，既不显示MCPTT用户标识A也不显示MCPTT用户标识B。因此，可以发现IMS公共用户标识B，并且可以使用属于MCPTT用户标识B的用户简档，以便可以引用MCPTT用户标识A标识。

a)MCPTT服务器2218确定要使用哪个MCPTT用户标识A用户简档以及该简档内的数据。MCPTT服务器2218可以通过使用在步骤6中接收的第二IMS公共用户标识A并确定映射到哪个MCPTT用户标识来确定MCPTT用户标识A。映射可以如步骤3或步骤5那样执行。

b)一旦使用步骤a)获得了MCPTT用户标识B，MCPTT服务器2218就可以确定与MCPTT用户标识B相关联的第二IMS公共用户标识B。可以在步骤1执行第二IMS公共用户标识B和MCPTT用户标识B之间的映射。

c)MCPTT服务器2218确定哪个用户简档与MCPTT用户标识B相关联。

d)MCPTT服务器2218确定哪个MCPTT用户标识B用户简档包含MCPTT用户标识A。MCPTT服务器2218确定MCPTT用户标识B用户简档内的位置。

e)MCPTT服务器2218确定与第二IMS公共用户标识B相关联的MCPTT用户标识B。

在步骤14处，MCPTT服务器2218向SIP核2210发送消息。在步骤14a处，SIP核2210将该消息转发到MCPTT UEb 2202。该消息包括指向MCPTT用户B用户简档的引用或指针以及针对MCPTT用户标识A的条目位置。

在一些情况下，MCPTT服务器2218可以对条目位置进行加密。例如，MCPTT服务器2218可以使用“种子值”和“计数器”来创建要包括在消息中的偏移。可以获得“种子值”和“计数器”来作为获得用户简档的功能的一部分。

图23示出了根据实现的用于加密和解密的示例框架2300。如所示，可以使用ME2302和网络节点2304来实现示例框架2300。ME2302可以是MCPTT UE的ME。网络节点可以是执行MCPTT功能的网络节点(例如，MCPTT服务器)。也可以使用附加的或不同的实体来实现框架2300。

如所说明的那样，也可以使用附加的、更少的或不同的操作来实现框架2300，所述操作可以按照所示的顺序或以不同的顺序执行。在一些情况下，例如可以将所述操作的一个或一组操作迭代或重复指定迭代次数或直到达到终止条件为止。

如前所述，用户简档和用户简档内的条目位置可以用于指代MCPTT用户标识。如果用户简档在MCPTT信任域之外(例如，P-CSCF、S-CSCF、会话边界控制(SBC))可用，则数据可以被MCPTT域之外的妥协的第三方访问。在一些情况下，加密可以用于保护例如要在简档中使用的条目位置、MCPTT用户标识、或与用户简档相关联的任何其它数据。

示例框架2300包括以下数据：向量、密钥、偏移、种子ID seedID。密钥是私钥。对于一些或所有MCPTT用户标识来说，密钥可以是相同的。对于任何特定的MCPTT用户标识，密钥也可以是唯一的。密钥在网络和ME中是已知的。

向量是通过将其与偏移值组合而随时间改变的值。该向量在网络和ME中是已知的。向量可以是时间戳或计数器或不重数。在一些情况下，可以从网络节点向UE传送向量。在一些情况下，例如，当向量是时间戳时，可以不从网络节点向UE传送向量。

偏移量是可以与向量组合以用作为加密seedID的输入的值。偏移量为加密提供了一些随机性。在一些情况下，每次执行加密时都可以随机产生偏移。备选地或附加地，偏移可以以已知方式增加或减少。

seedID是要被加密的数据。seedID可以包括用户简档中的MCPTT用户标识、用于寻址用户简档中的数据项的位置标识符、或其组合。

如所示，在步骤1处，网络节点2304向ME 2302发送消息。该消息可以包括向量和密钥。消息可以被加密。可以使用传输层安全性(TLS)协议、OpenID框架或其组合来执行加密。在一些情况下，向量和密钥可以是图25中步骤7中交换的令牌的一部分。

在步骤2处，ME 2302确定要对seedID进行加密。ME 2302将偏移和向量进行组合，并且使用组合值、seedID和密钥作为加密算法的输入以产生加密值。

在步骤3处，ME 2302向网络节点2304发送加密值、偏移、ME的标识。在步骤4处，网络节点2304将偏移与向量组合，并且使用组合值、密钥和加密值来作为解密算法的输入，以产生解密数据。

在一些情况下，可以以相反的顺序执行操作。例如，网络节点2304可以使用偏移、向量、密钥或其任何组合来加密seedID，并向ME 2302发送加密值。ME 2302可以解密该加密值并且获得seedID。

在一个示例中，ME 2302从网络接收向量和密钥，并且存储这些值。ME 2302可以确定用户简档a和用户简档a中的位置5将用于传送用户标识。可以将数值5与密钥和“向量+偏移”一起输入到算法中，以产生加密值(例如，“x3e5”)。值“x3e5”与偏移一起发送到网络。网络节点2304接收值“x3e5”和偏移。网络节点2304取得与以该消息接收的标识相关联的向量和密钥。网络节点2304将偏移和向量进行组合，并且使用组合值、密钥和值“x3e5”来解密并产生位置5。

图24(包括图24A和图24B)是示出了根据实现的用于MCPTT呼叫的示例呼叫流程2400的流程图。如所示，呼叫流程2400可以由MCPTT UEa 2404、MCPTT UEb 2402、SIP核2410、标识管理服务器2414、MCPTT用户数据库2416、MCPTT服务器2418、归属订户服务器(HSS)2412、和SIP数据库2413实现。也可以使用附加的、更少的或不同的实体来实现呼叫流程2400。例如，由图24中所示的多个实体执行的功能可以一起集成在单个软件或硬件实体中。备选地或附加地，由图24中所示的任何实体执行的功能可以在多个软件或硬件实体中单独实现。

此外，也可以使用附加的、更少的或不同的操作来实现呼叫流程2400，所述操作可以按照所示的顺序或以不同的顺序执行。在一些情况下，例如可以将所述操作的一个或一组操作迭代或重复指定迭代次数或直到达到终止条件为止。

如果MCPTT用户(MCPTT用户标识A)希望向另一个MCPTT用户(MCPTT用户标识B)发出呼叫，则MCPTT用户可以向MCPTT服务器的公共服务标识(PSI)发送SIP INVITE请求。为了使被叫方的标识不被PLMN运营商读取，RFC 4483[x]中定义的内容间接机制可以用于将接受人列表元素包括为message/external-body MIME类型。接受人列表元素可以被格式化为URL或XML配置访问协议(XCAP)URI，该URI或XCAP URI指向用户的MCPTT用户简档的联系人列表中的被叫方的MCPTT ID。此外，可以加密指向用户简档内的位置的指针。加密部分可以是文本的，但使用私钥和随机分量(例如，计数器+偏移)。如果MCPTT用户标识A一次又一次地呼叫MCPTT用户标识B，则XCAP URI的位置部分可以是不同的。备选地，用户简档可以包含指向网络联系人列表或地址簿的一个或多个指针或引用，所述联系人列表或地址簿包含可以联系的MCPTT用户的MCPTT ID。可能地，这些联系人列表可以基于使用用户简档的MCPTT用户的角色(例如，现场急救人员)。第二级间接允许实际URI不指向特定MCPTT用户，而是指向标识用户角色的简档标识。

以下是联系人列表文档XML(//UserProfile/user-role-ID/contact-list)的示例：

备选地，联系人列表可以与MCPTT用户简档分开，而是网络存储的联系人目录。在这种情况下，XCAP URI可以指向网络目录XML文档的MCPTT ID。在一些情况下，MCPTT用户简档中的联系人列表可以包含指向MCPTT用户可以呼叫的网络存储的联系人目录中的每个单独MCPTT ID的XCAP URI列表。

如果用户希望私下向sip：joe@example.org(列表中的第4个条目)进行发送，则可以使用SIP INVITE的Multipart MIME主体中的以下Content-Type：

MIME-Version：1.0

Content-Type：multipart/mixed；boundary＝boundary42

--boundary42

Content-Type：message/external-body；

access-type＝″URL″；

expiration＝″Mon，24June 2016 09：01：32GMT″；URL＝″https：// xcap.example.com/UserProfile/user-role-ID/contact-list/～～/resource-lists/ list/entry％5b4％5d/@uri″；

NOTE％5b4％5d is equivalent to[4]THAT HAS BEEN ESCAPED(％5b＝[and％5d＝])

size＝62

hash＝10AB568E91245681AC1B

Content-Type：application/recipient-list+xml

Content-Disposition：recipient-liSt

----undary42--

UE可以包括message/external-bodyMIME主体，该MIME主体包含指向MCPTT用户简档内或MCPTT UE和MCPTT服务器均可访问的XML文档(比如，共用网络目录文档)内的MCPTTID的XCAP URI。

当MCPTT服务器接收包含接受人列表的SIP请求作为message/external-bodyMIME主体时，MCPTT通过解析message/external-body MIME主体中包括的XCAP URI来获得被叫方的MCPTT ID。如果被呼叫的MCPTT用户位于不同的MCPTT系统中，则MCPTT服务器可以将请求转发到目标系统中的MCPTT服务器，并且使用接受人列表message/external-bodyMIME主体中的XCAP URI，该MIME主体解析到两个MCPTT服务器均可访问的XML文档(比如，共用网络目录文档)。MCPTT服务器还可以包括message/external-body MIME主体，该MIME主体包含指向两个MCPTT服务器均可访问的XML文档(例如，共用网络目录文档)中的呼叫MCPTT用户的MCPTT ID的XCAP URI。

类似地，可以使用message/external-body MIME主体来标识MCPTT组ID，该MIME主体包含指向用户简档联系人列表中、或者备选地在定义该组的组文档中、或者备选地标识一个或多个组的共用文档中的MCPTT组ID的XCAP URI。

返回图24，在步骤0处，在MCPTT UEa 2404和标识管理服务器2414之间执行MCPTT用户认证。在一些情况下，可以使用图24中所示的处理来执行认证过程。作为该处理的一部分，标识管理服务器2414向MCPTT UEa 2404发送包含认证配置信息(例如，access_token、id_token或其组合)的消息。在令牌中，可以包括以下JSON声明：

-Phone_number或phone_number_verified包含向MCPTT用户标识A指派的E.164；

-向量；

-密钥；

-IMS_Private_identity：包含由标识管理服务器2414指派的IMS专用标识。它是SIP注册中使用的标识。

-IMS_Public_Identity：包含由标识管理服务器2414指派的IMS公共标识(例如，SIP URI)。

以下是使用针对id_token的JSON模式的示例实现，其中“priVate.randoml@example.com”表示IMPI2a，“public.random1@example.com”表示IMPU2a。

{

″sub″：″248289761001″.

″name″：″Jane Doe″，

″given_name″：″Jane″，

″family_name″：″Doe″，

″preferred_username″：″j.doe″，

″email″：″janedoe@examplepolice.com″，

″picture″：http：//example.com/ianedoe/me.ipa，

″phone_number″：+15105551212，

″Vector″：″janedoe@example.com″，

″Key″：″janedoe@example.com″，

″IMS_Private_identity″：″private.random1@example.com″，

″IMS_Public_identity″：″public.random1@example.com″，

″MCPTT_User_identity″：″jone.doe@examplepolice.com″，

″MCPTT_User profile″：https：//xcap.example.com/

}

MCPTT UEa 2404接收该消息并存储在步骤0中发送的数据。access_token、id_token或其组合可以用作MCPTT用户认证令牌。

在步骤1处，MCPTT UEa 2404向SIP核2410发送注册消息以执行SIP注册。注册消息可以包括基于接收的认证配置信息的认证信息。例如，认证信息可以包括IMPI2a、IMPU2a、向量、密钥或其任何组合。

在步骤5处，SIP数据库2413向标识管理服务器2414发送认证请求。认证请求包括IMPI2a、IMPU2a或其组合。标识管理服务器2414确定IMPl2a或IMPU2a映射到MCPTT用户标识A。在步骤5a处，标识管理服务器2414向HSS 2412发送认证请求。认证请求包括与MCPTT用户标识A相关联的IMPI1a、IMPU1a或其组合。在步骤5b处，标识管理服务器2414从HSS 2412接收认证响应。认证响应包括基于IMPI1a、IMPU1a或其组合产生的认证响应向量。

在一些情况下，在步骤5c处，标识管理服务器2414和MCPTT用户数据库2416将MCPTT用户标识A与IMPI2a或IMPU2a绑定。标识管理服务器2414可以向MCPTT用户数据库2416发送包括以下至少一项的消息：IMPI2a、IMPU2a、MCPTT用户认证令牌(作为MCPTT用户标识A的一部分产生)和MCPTT用户标识A。图27示出了使用3GPP Sh接口的示例实现。

MCPTT用户数据库2416可以检查包含MCPTT用户标识A的用户简档，并且更新那些用户简档以指示MCPTT用户标识A映射到IMPU2a。

MCPTT用户数据库2416向标识管理服务器2414发送消息，指示已经接收到MCPTT用户标识A，并且可选地包括指向与MCPTT用户标识A相关联的用户简档的URL/URI。

在一些情况下，步骤5c可以在步骤5之前执行，例如，当发生MCPTT用户认证(步骤0)时。

在步骤6处，标识管理服务器2414向SIP数据库2413发送认证响应。认证响应包括在步骤5b处接收的认证响应向量，该认证响应向量是基于IMPI1a、IMPU1a或其组合产生的。

在步骤8处，MCPTT UEa 2404使用SIP协议接收认证挑战请求。

在步骤9处，MCPTT UEa 2404发送认证响应。认证响应可以是SIP REGISTER消息。

在步骤21处，SIP核2410向MCPTT服务器2418发送第三方注册。第三方注册可以包含唯一地标识用户的令牌(MPCTT用户标识A)，并且还可以包含IMPU2a、IMPI2a，例如使用3GPP TS 24.229中的过程以第三方注册从UE递送REGISTER请求。

在步骤22处，MCPTT服务器2418与标识管理服务器2414交互以基于所接收的MCPTT用户认证令牌或IMPU2a或IMPI2a来获得MCPTT用户标识A。因此，可以创建IMPU2a到MCPTT用户标识A的映射。HTTP或DIAMETER协议可用于执行此步骤。图28(包括图28A和图28B)示出了使用3GPP Sh接口的示例实现。

MCPTT服务器2418发送包含以下至少一项的消息：IMPI2a、IMPU2a、MCPTT用户认证令牌。

标识管理服务器2414接收包含IMPI2a、IMPU2a、MCPTT用户认证令牌中的至少一个的消息和需要MCPTT用户标识映射的指示。标识管理服务器2414确定映射到IMPI2a、IMPU2a中的至少一个的MCPTT用户标识A。标识管理服务器2414向MCPTT服务器2418发送包含MCPTT用户标识A的消息。在一个示例中，发送SH-Pull Resp，其包含Sh-Pull Resp的用户数据AVP中的MCPTT用户标识A。

在步骤23处，MCPTT服务器2418向MCPTT用户数据库2416发送将消息#23a。消息#23a包含MCPTT用户标识A、IMPU2a、IMPI2a中的至少一个。该消息还可以包含请求用户简档的指示。图29示出了使用3GPP Sh接口的示例实现。MCPTT用户数据库2416搜索与MCPPT用户标识A相关的用户简档。以下是示例用户简档：

MCPTT用户标识A；可选地，第二IMS公共用户标识A、密钥、向量

A)位置1 MCPTT用户标识B

B)位置2 MCPTT用户标识C

C)位置3 组标识A；

D)位置4 组标识C

E)位置5 编解码AMR

f)位置6

MCPTT用户数据库2416发送消息#23b，其包含i)指向可以针对MCPTT用户标识A找到用户简档的指针或引用；或ii)针对MCPTT用户标识A的用户简档。图30和图31(包括图31A和图31B)示出了使用3GPP Sh接口的示例实现。

MCPTT服务器2418接收消息#23b。如果消息#23b包含用户简档数据，则MCPTT服务器2418向MCPTT用户数据库2416发送消息#23c，以请求在用户简档改变时进行通知。图32示出了使用3GPP Sh接口的示例实现。

如果针对消息#23c中包括的MCPTT用户标识A存储的数据中发生了改变，则MCPTT用户数据库2416可以发送消息#23d。消息#23d包含IMPI2a、IMPU2a、MCPTT用户标识A和已改变的数据中的至少一个。

备选地或附加地，可以使用以下过程来执行步骤23：

a)MCPTT服务器2418向MCPTT用户数据库2416发送SIP SUBSCRIBE(SIP订阅)消息。SIP SUBSCRIBE包含MCPTT用户标识A和可选的IMPU2a。

b)MCPTT用户数据库2416可选地搜索与MCPPT用户标识A相关的用户简档。

c)MCPTT用户数据库2416向MCPTT服务器2418发送200OK。

d)MCPTT用户数据库2416发送SIP NOTIFY(SIP通知)，其包含针对来自步骤23a)的MCPTT用户标识A的用户简档，或者指向针对来自步骤23a)的MCPTT用户标识A的用户简档的位置的指针或引用。

e)MCPTT服务器2418接收SIP NOTIFY，并且存储指向与在23a)中发送的MCPTT用户标识A相关联的用户简档的指针/引用。

如果用户简档改变(例如，由于步骤5c)b)正在使用其它MCPTT用户标识的结果)，则步骤23d)和23e)可以重复多次。

备选地，如果MCPTT服务器2418接收到指针或引用，则MCPTT服务器2418可以使用与步骤29相关联的过程来执行步骤23，例如使用HTTP Get和XCAP 200。R-URI可以是附加了MCPTT用户标识A的MCPTT用户数据库的R-URI。图33示出了消息的示例实现。

备选地，用户简档可以包含网络存储的联系人目录的URI。在这种情况下，XCAPURI可以指向网络目录XML文档的MCPTT ID。图34示出了消息的示例实现。

此外，MCPTT用户简档中的联系人列表可以包含指向允许MCPTT用户呼叫的网络存储的联系人目录中的每个单独MCPTT ID的XCAP URI列表。图35示出了根据实现的示例联系人列表(contactlist)。

如果未向MCPTT UEa 2404提供用户简档的位置，则可以执行步骤25至步骤30。

在步骤25处，MCPTT UEa 2404向MCPTT服务器2418发送SIP SUBSCRIBE。SIPSUBSCRIBE包含随后将由UE在SIP消息中使用的MCPTT用户标识A或第二IMS公共用户标识A。

在步骤26处，MCPTT服务器2418发送200OK。在步骤27处，MCPTT服务器2418向MCPTTUEa 2404发送SIP NOTIFY，SIP NOTIFY包含指向在步骤25中是参考的用户简档的引用或指针。

在一些情况下，可以向MCPTT UEa 2404提供针对MCPTT用户标识A的用户简档的位置。该信息可以以经由XML接收的作为Ortuth机制(在步骤0中)中的或者用于认证MCPTT用户标识A的其它机制中的MCPTT用户认证令牌的一部分的UICC，OMA DM MO来提供。

如果已经在UICC上提供了用户简档位置，则在USI/ISIM或另一应用中，ME可以从UICC上的应用取得用户简档位置信息。

在另一实现中，可以通过具有已知位置并附加MCPTT用户标识A，IMPU2a或IMPI2a来导出用户简档的位置。例如，MCPTT-User-A包括在下面的GET消息中：

GET

https：//xcap.example.com/UserProfile/user-role-ID/MCPTT-User-A.xmlHTTP/1.1.

在步骤29处，MCPTT UEa 2404发送消息(HTTP GET)以获得用户简档。该消息可以通过可选隧道(TL、TTLS、IPsec等)向MCPTT用户数据库发送。HTTP GET的R-URI是文档URI的R-URI。HTTP GET包含随后将由UE在SIP消息中使用(如果可用的话)的MCPTT用户标识A或第二IMS公共用户标识A。

MCPTT用户数据库2416接收HTTP GET。MCPTT用户数据库2416使用在HTTP GET中接收的标识(随后将由UEa在SIP消息中使用的MCPTT用户标识A或第二IMS公共用户标识A)来获得用户简档。

在步骤30处，MCPTT用户数据库2416向MCPTT UEa 2404发送用户简档。发送到MCPTT UEa 2404的用户简档可以包含IMPU2a、IMPI2a或其组合。MCPTT UEa 2404接收用户简档，并且将其存储部存储器或可移动卡(UICC)上。

在步骤31处，MCPTT UEa 2404发送SIP METHOD(SIP方法)。R-URI是MCPTT服务器。SIP METHOD可以包括指向用户简档的0或多个引用或指针。引用或指针可以包含指向用户简档内的特定条目(例如，TO地址、SDP条目)的附加信息。

如果用户希望私下向sip：joe@example.org(表Y1中所示的第4个条目)进行发送，则可以使用SIP INVITE的Multipart MIME主体中的以下Content-Type，“％564％5d”(转义4)可以被加密：

MIME-Version：1.0

Content-Type：multipart/mixed；boundary＝boundary42

----boundary42

Content-Type：message/external-body；

access-type＝″URL″；

expiration＝″Mon，24June 2016 09：01：32GMT″；

URL＝″https：//xcap.example.com/UserProfile/user-role-ID/contact-list/ ～～/resource-lists/list/entry％5b4％5d/＠uri″；

size＝62

hash＝10AB568E91245681AC1B

Content-Type：application/recipient-list+xml

Content-Disposition：recipient-list

---undary42--

在步骤32处，MCPTT服务器2418例如通过在用户简档中查找IMPU2a(例如，来自联系报头等)或检查包括的指针或引用已被取得和存储，来检查IMPU2a(在步骤31中接收的)是否在本地存储在MCPTT服务器2418上的用户简档中。如果用户简档未被存储，则MCPTT服务器2418通过向MCPTT用户数据库2416发送HTTP GET消息来获得用户简档。以下是GET消息的示例实现：

GET

https：//xcap.example.com/UserProfile/user-role-ID/contact-list/～～/resource-lists/list/entry％5b4％5d/@uri HTTP/1.1

User-Agent：IMS subscriber

Date：Thu，08Jan 2004 11：13：17GMT

Content-Length：O

在步骤34处，MCPTT用户数据库2416向MCPTT服务器2418发送用户简档。

在步骤34处，MCPTT服务器2418在用户简档中搜索被引用方。如果接收到偏移参数，则MCPTT服务器可以在搜索之前解密该位置。

如果引用B方(到达地址)，则MCPTT服务器2418根据A方用户数据来确定B方的MCPTT用户标识B。

MCPTT服务器2418通过在用户简档中查找B方MCPTT用户标识B来确定B方MCPTT用户标识B是否具有存储在MCPTT服务器2418中的用户简档。如果不存在用户简档，则MCPTT服务器2418使用先前描述的过程获得用户简档。

MCPTT服务器2418确定B方用户简档中是否存在MCPTT用户标识A。

MCPTT服务器2418确定在传入的接收消息中引用的其它引用数据是否在用户简档B中。如果相同用户简档A方中存在其它引用数据，则MCPTT服务器2418在SIP METHOD中包括指向该其它引用数据的引用或指针。如果其它引用的数据在另一B方用户简档中，则MCPTT服务器2418在SIP METHOD中包括指向该另一B方用户简档的引用或指针。

如果存在A方标识，则MCPTT服务器2418发送包含指向用户简档的引用的SIPMETHOD，其中用户简档包含A方。

如果数据不在B方用户简档中，则MCPTT服务器2418选择现有的B方用户简档。MCPTT服务器2418在所选择的用户简档中创建新条目。MCPTT服务器2418可以充当如3GPPTS 24.623/RFC 4825[x]中定义的XCAP客户端，并且执行动作以创建新属性。可以构建新属性以使B方能够基于条目导出A方MCPTT用户标识，例如：

位置X MCPTT用户标识；或者

IMPU2a MCPTT用户标识。

当MCPTT服务器2418发送SIP METHOD时，它还可以更新或改变URI有效期，以便MCPTT UEb 2402知道文档已经改变。

MCPTT UEb 2402接收SIP METHOD。SIP METHOD可以包含指向用户简档的0至多个引用或指针。如果MCPTT UEb 2402先前已获得以引用或指针引用的XML文档，则MCPTT UEb2402可以检查以查看URI有效期是否有效。如果URI有效期是无效的，则MCPTT UEb 2402可以执行步骤35。

如果URI有效期是有效的，或者MCPTT UEb 2402已使用步骤35和36取得了用户简档，则MCPTT UEb 2402可以使用所接收的引用或指针来获得信息。在引用或指针标识联系人标识的情况下，可以在屏幕上显示所述联系人标识。

如果URI有效期是无效的，则MCPTT UEb 2402可以取得在SIP METHOD中引用的用户简档。

尽管本公开包含许多特定的实施方式的细节，然而这些细节不应被解释为对要求保护的范围或任何发明的范围构成限制，而是用于描述特定于具体发明的具体实施方式的特征。例如，除了MCPTT之外，本文中描述的解决方案还可以应用于关键任务服务。这些关键任务服务的示例包括关键任务视频(MCVideo)、关键任务数据(MCData)或任何其它关键任务服务。在单个实现中，还可以组合实现本公开中在独立实现的上下文中描述的某些特征。反之，在单个实现的上下文中描述的各种特征也可以在多个实现中分开地或以合适的子组合来实现。此外，尽管特征可以在上面描述为在某些组合中起作用并且甚至最初如此要求保护，但是来自所要求保护的组合的一个或多个特征在一些情况下可以从组合中删除，并且所要求保护的组合可以针对子组合或子组合的变体。

已经描述了本主题的特定实现。对于本领域技术人员显而易见的是，所描述的实现的其它实现、改变和置换在所附权利要求的范围内。尽管在附图和权利要求中以特定顺序描述了操作，但这不应被理解为：为了实现期望的结果，要求按所示的特定顺序或按相继的顺序来执行这些操作，或者要求执行所有所示的操作(一些操作可以看作是可选的)。在一些情况下，多任务或并行处理(或者多任务和并行处理的组合)可以是有利的并且视情况来执行。

此外，在上述实现的各种系统模块和组件的分离或集成不应被理解为在所有实现中都要求这样的分离或集成，并且应该理解的是，所描述的程序组件和系统一般可以一起集成在单个软件产品中或封装为多个软件产品。

因此，上述对示例实现的描述不限定或限制本公开。在不脱离本公开的精神和范围的情况下，还可以存在其它改变、替换和变化。

此外，以下任何要求保护的实现被视为至少适用于计算机实现的方法；存储用于执行所述计算机实现的方法的计算机可读指令的非暂时性计算机可读介质；以及计算机系统，该计算机系统包括与硬件处理器彼此操作地耦接的计算机存储器，所述硬件处理器被配置为执行所述计算机实现的方法或存储在所述计算机可读介质上的指令。

附录A

对3GPP TS 24.229的可能改变

附录B

对3GPP 29.228的可能改变

附录C

对3GPP 29.228的可能改变

附录D

对3GPP 29.228的可能改变

附录E

对3GPP TS 24.229的可能改变

附录F

对3GPP TS 24.229的可能改变

附录G

对3GPP 29.228的可能改变

附录H

3GPP 29.228认证请求数据

附录I

对3GPP 29.228的可能改变

附录J

对3GPP 29.229的可能改变

附录K

对3GPP 29.229的可能改变

附录L

对3GPP 29.229的可能改变

附录M

对3GPP TS 31.103的可能改变

附录N

认证功能

附录O

对3GPP TS 24.302的可能改变

附录P

对3GPP TS 24.302的可能改变

附录Q

对3GPP TS 29.328的可能改变

附录R

对3GPP 29.328的可能改变

附录S

对3GPP TS 24.302的可能改变

附录T

对3GPP TS 24.302[16]的可能改变

附录U

对3GPP TS 31.103的可能改变

附录V

对ETSI TS 102 223的可能改变

Claims (20)

1.一种方法，包括：

从用户设备UE向第一网络节点发送请求认证配置信息的第一消息，其中，所述第一消息是根据第一协议来格式化的；

响应于所述第一消息，接收包括所述认证配置信息的第二消息；

基于所接收的认证配置信息，从所述UE向第二网络节点发送包括认证信息的第三消息，其中，所述第三消息是根据第二协议来格式化的；

从所述第二网络节点接收根据所述第二协议格式化的认证挑战请求；以及

响应于接收所述认证挑战请求，向所述第二网络节点发送认证响应。

2.根据权利要求1所述的方法，其中，所述第一网络节点执行针对关键任务一键通MCPTT用户的标识映射。

3.根据权利要求1所述的方法，其中，所述第二网络节点包括会话发起协议SIP核。

4.根据权利要求1所述的方法，其中，所述第一协议是超文本传输协议HTTP、可扩展认证协议EAP、或会话发起协议SIP中的至少一种。

5.根据权利要求1所述的方法，其中，所述第二协议是会话发起协议SIP。

6.根据权利要求1所述的方法，其中，所述第一消息包括与第一关键任务一键通MCPTT系统相关联的第一用户标识符ID，且所述认证信息包括与第二MCPTT系统相关联的第二用户ID。

7.根据权利要求6所述的方法，其中，所述第二用户ID包括公共用户ID或专用用户ID中的至少一个。

8.一种用户设备UE，包括：

至少一个硬件处理器；以及

非暂时性计算机可读存储介质，耦接到所述至少一个硬件处理器，并且存储用于由所述至少一个硬件处理器执行的编程指令，其中，所述编程指令指示所述至少一个硬件处理器执行以下操作：

从所述UE向第一网络节点发送请求认证配置信息的第一消息，其中，所述第一消息是根据第一协议来格式化的；

响应于所述第一消息，接收包括所述认证配置信息的第二消息；

基于所接收的认证配置信息，从所述UE向第二网络节点发送包括认证信息的第三消息，其中，所述第三消息是根据第二协议来格式化的；

从所述第二网络节点接收根据所述第二协议格式化的认证挑战请求；以及

响应于接收所述认证挑战请求，向所述第二网络节点发送认证响应。

9.根据权利要求8所述的UE，其中，所述第一网络节点执行针对关键任务一键通MCPTT用户的标识映射。

10.根据权利要求8所述的UE，其中，所述第二网络节点包括会话发起协议SIP核。

11.根据权利要求8所述的UE，其中，所述第一协议是超文本传输协议HTTP、可扩展认证协议EAP、或会话发起协议SIP中的至少一种。

12.根据权利要求8所述的UE，其中，所述第二协议是会话发起协议SIP。

13.根据权利要求8所述的UE，其中，所述第一消息包括与第一关键任务一键通MCPTT系统相关联的第一用户标识符ID，且所述认证信息包括与第二MCPTT系统相关联的第二用户ID。

14.根据权利要求13所述的UE，其中，所述第二用户ID包括公共用户ID或专用用户ID中的至少一个。

15.一种方法，包括：

在第一网络节点处接收第一认证请求，其中，所述第一认证请求包括与第一关键任务一键通MCPTT系统相关联的第一用户标识符ID；

确定所述第一用户ID被映射到与第二关键一键通MCPTT系统相关联的第二用户ID；

从所述第一网络节点向第二网络节点发送第二认证请求，其中，所述第二认证请求包括所述第二用户ID；

响应于所述第二认证请求，接收包括认证响应向量的第一认证响应；以及

响应于接收所述第一认证响应，发送包括所述认证响应向量的第二认证响应。

16.根据权利要求15所述的方法，其中，所述第一网络节点执行针对MCPTT用户的标识映射。

17.根据权利要求15所述的方法，其中，所述第一网络节点是公共服务核的一部分。

18.根据权利要求15所述的方法，其中，所述第一网络节点是标识管理服务器。

19.根据权利要求15所述的方法，其中，基于所述第二用户ID来产生所述认证响应向量。

20.根据权利要求15所述的方法，其中，所述第二用户ID包括公共用户ID或专用用户ID中的至少一个。