KR102514133B1

KR102514133B1 - 세션 개시 프로토콜 세션의 확립

Info

Publication number: KR102514133B1
Application number: KR1020187023773A
Authority: KR
Inventors: 아드리안 버클리; 앤드류 마이클 알렌; 마이클 오언 버클리
Original assignee: 블랙베리 리미티드
Priority date: 2016-01-25
Filing date: 2017-01-25
Publication date: 2023-03-23
Also published as: WO2017132277A1; EP3408993B1; CN108886520A; KR20180107776A; CN108886520B; CA3011821C; EP3408993A1; CA3011821A1

Abstract

본 개시는 세션 개시 프로토콜 세션을 확립하기 위한 방법 및 시스템을 설명한다. 하나의 방법은, 인증 구성 정보를 요청하는 제1 메시지를 송신하는 것; 상기 제1 메시지에 응답하여, 인증 구성 정보를 포함하는 제2 메시지를 수신하는 것; 수신된 인증 구성 정보에 기초하여 인증 정보를 포함하는 제3 메시지를 송신하는 것; 제2 프로토콜에 따라 포맷되는 인증 시도 요청을 수신하는 것; 및 인증 시도 요청을 수신하는 것에 응답하여, 인증 응답을 제2 네트워크 노드로 송신하는 것을 포함한다.

Description

세션 개시 프로토콜 세션의 확립

<관련 출원에 대한 교차 참조>

본 출원은 2016년 1월 25일자로 출원된 미국 출원 제62/286,739호에 대한 우선권 및 2015년 1월 30일자로 출원된 미국 출원 제14/788,099호의 계속 출원인 2016년 8월 25일자로 출원된 미국 출원 제15/247,065호에 대한 우선권을 주장하는데, 이들 출원 모두는 그 전체가 참조에 의해 본원에 통합된다.

<개시의 분야>

본 개시는 인터넷 프로토콜(internet protocol; IP) 멀티미디어 서브시스템(IP multimedia subsystem; IMS)에 관한 것으로, 특히 IMS 네트워크에서의 아이덴티티의 확인에 관한 것이다.

IP 멀티미디어 서브시스템은 표준화된 방식으로 패킷 데이터를 모바일 디바이스에 제공하기 위한 아키텍쳐 프레임워크(architectural framework)이다. 이러한 IMS 네트워크는 회선 교환 시스템보다는 패킷 시스템을 통한 음성 호를 허용한다. 그것은 푸시 투 토크(push to talk; PTT), 특히, 최초 대처자(first responder)에 대해 사용되는 미션 크리티컬 푸시 투 토크(mission critical push to talk; MCPTT)와 같은 다른 기능성을 허용한다.

IMS 인증은 IMS 네트워크 상에서 사용하기 위한 개인(private) 식별자 및 공개(public) 식별자 둘 모두를 인증한다. 그러나, IMS 인증은 상이한 개개의 IMS 공개 유저 아이덴티티가, 동일한 또는 상이한 IMS 개인 유저 아이덴티티를 가지고 별도로 인증되는 것을 허용하지 않는다. 이것은 다양한 상황에서 문제로 이어질 수 있다. 예를 들면, 최초 대처자에 의해 사용되는 경우, MCPTT 애플리케이션은, 디바이스의 개인 아이덴티티에 연결되는 장치와는 상이한 공개 아이덴티티에 의해 디바이스가 인증되는 것을 필요로 할 수도 있다.

본 개시는 도면을 참조하여 더 잘 이해될 것인데, 도면에서:
도 1은 예시적인 IMS 네트워크의 블록도이다;
도 2는 IM 가입자의 인증을 도시하는 데이터 흐름도이다;
도 3은 IMS 시스템에서의 개인 유저 아이덴티티와 공개 유저 아이덴티티 사이의 관련성을 도시하는 블록도이다;
도 4는 다양한 네트워크 엘리먼트를 비롯한, 공공 안전 오퍼레이터(public safety operator)와 공공 안전 UE 사이의 시그널링을 도시하는 블록도이다;
도 5a는 EAP 인증을 위한 프로토콜 스택의 블록도이다;
도 5b는 EAP가 유저 인증 프로토콜인 경우의 프로토콜 스택의 블록도이다;
도 6은 이중 인증을 위한 표시(indication)를 제공하는 제1 대역 내(in band) 실시형태를 도시하는 데이터 흐름도이다;
도 7은 인증에서 제2 공개 유저 아이덴티티가 사용되는 대안적인 대역 내 실시형태에 대한 데이터 흐름도이다;
도 8은 공개 유저 식별자에 기초한 키잉(keying)을 도시하는 대역 내 실시형태의 데이터 흐름도이다;
도 9는 HSS 및 UE에서의 키 생성을 위한 프로세스를 도시하는 블록도이다;
도 10은 공개 유저 PIN이 캐리어로부터 불명확하게 되는 네트워크 엘리먼트에서의 키 생성 프로세스의 블록도이다;
도 11은 공개 유저 PIN이 캐리어로부터 불명확하게 되는 유저 기기에서의 키 생성 프로세스의 블록도이다;
도 12는 IMS 인증을 위한 대역 외(out of band) 실시형태를 도시하는 데이터 흐름도이다;
도 13은 대역 외 인증 프로세스를 도시하는 블록도이다;
도 14는 인증을 위해 상이한 공개 유저 아이덴티티를 활용하는 대역 외 실시형태를 도시하는 데이터 흐름도이다;
도 15는 UE가 제2 MCPTT 네트워크로 로밍할 수 있는 대역 외 실시형태를 도시하는 데이터 흐름도이다;
도 16은 MCPTT 데이터에 대한 예시적인 데이터 구조를 도시하는 블록도이다;
도 17은 인증서(certificate)를 활용한 인증을 도시하는 데이터 흐름도이다;
도 18은 인증서의 생성을 도시하는 블록도이다;
도 19는 예시적인 네트워크 엘리먼트의 간략화된 블록도이다;
도 20은 본 개시의 실시형태와 함께 사용하기 위한 예시적인 유저 기기의 블록도이다.
도 21은, 한 구현예에 따른, 예시적인 MCPTT 시스템의 애플리케이션 레이어 아키텍쳐를 예시하는 개략도이다.
도 22는, 한 구현예에 따른, MCPTT 유저 인증을 위한 예시적인 호 흐름을 도시하는 흐름도이다.
도 23은, 한 구현예에 따른, 암호화 및 복호화를 위한 예시적인 프레임워크를 예시한다.
도 24a 및 도 24b는, 한 구현예에 따른, MCPTT 호에 대한 예시적인 호 흐름을 도시하는 흐름도이다.
도 25는, 한 구현예에 따른, 토큰을 획득하기 위한 예시적인 프로세스를 예시한다.
도 26은, 한 구현예에 따른, 토큰을 획득하기 위한 예시적인 코드를 예시한다.
도 27 내지 도 32는 3GPP Sh 인터페이스를 사용하는 예시적인 구현예를 예시한다.
도 33 내지 도 34는, 한 구현예에 따른, 예시적인 메시지를 예시한다.
도 35는, 한 구현예에 따른, 예시적인 연락처 목록을 예시한다.

본 개시는 인터넷 프로토콜(IP) 멀티미디어 서브시스템(IMS)을 사용하여 제3 네트워크 노드에 등록하기 위한 유저 기기에서의 방법을 제공하는데, 그 방법은: 유저 기기와 제1 네트워크 노드 사이에 터널을 생성하는 것; 유저 기기와 관련되는 제1 공개 아이덴티티를 제1 네트워크 노드에 인증시키는 것; 제2 개인 유저 식별자 및 제2 공개 유저 식별자 - 제2 개인 유저 식별자 및 제2 공개 유저 식별자는 제2 네트워크 노드와 관련됨 - 를 갖는 구성 정보를 상기 제1 네트워크 노드로부터 수신하는 것; 및 제2 개인 유저 식별자 및 제2 공개 유저 식별자를 사용하여 제3 네트워크 노드에 등록하는 것을 포함한다.

본 개시는 또한 인터넷 프로토콜(IP) 멀티미디어 서브시스템(IMS)을 사용하여 제3 네트워크 노드에 등록하도록 구성되는 유저 기기를 제공하는데, 유저 기기는: 프로세서; 및 통신 서브시스템을 포함하고, 유저 기기는: 유저 기기와 제1 네트워크 노드 사이에 터널을 생성하도록; 유저 기기와 관련되는 제1 공개 아이덴티티를 제1 네트워크 노드에 인증시키도록; 제2 개인 유저 식별자 및 제2 공개 유저 식별자 - 제2 개인 유저 식별자 및 제2 공개 유저 식별자는 제2 네트워크 노드와 관련됨 - 를 갖는 구성 정보를 제1 네트워크 노드로부터 수신하도록; 그리고 제2 개인 유저 식별자 및 제2 공개 유저 식별자를 사용하여 제3 네트워크 노드에 등록하도록 구성된다.

본 개시는 또한 인터넷 프로토콜(IP) 멀티미디어 서브시스템(IMS)을 사용하여 유저 기기와 제3 네트워크 노드 사이의 인증을 위해 구성되는 제1 네트워크 노드에서의 방법을 제공하는데, 그 방법은: 유저 기기와의 터널을 확립하는 것; 제1 네트워크 노드에서 유저 기기의 제1 공개 아이덴티티를 인증하는 것; 유저 기기로부터 구성 정보 메시지 - 구성 정보 메시지는, 유저 기기가 등록되어 있는 네트워크에 대한 네트워크 식별자를 포함함 - 를 수신하는 것; 제2 네트워크 노드로부터, 제2 개인 유저 식별자 및 제2 공개 유저 식별자를 획득하는 것; 및 제2 개인 유저 식별자 및 제2 공개 유저 식별자를 유저 기기로 제공하는 것을 포함한다.

본 개시는 또한 인터넷 프로토콜(IP) 멀티미디어 서브시스템(IMS)을 사용하여 유저 기기와 제3 네트워크 노드 사이의 인증을 위해 구성되는 제1 네트워크 노드를 제공하는데, 제1 네트워크 노드는: 프로세서; 및 통신 서브시스템을 포함하고, 제1 네트워크 노드는: 유저 기기와의 터널을 확립하도록; 제1 네트워크 노드에서 유저 기기의 제1 공개 아이덴티티를 인증하도록; 유저 기기로부터 구성 정보 메시지 - 구성 정보 메시지는, 유저 기기가 등록되어 있는 네트워크에 대한 네트워크 식별자를 포함함 - 를 수신하도록; 제2 네트워크 노드로부터, 제2 개인 유저 식별자 및 제2 공개 유저 식별자를 획득하도록; 그리고 제2 개인 유저 식별자 및 제2 공개 유저 식별자를 유저 기기에 제공하도록 구성된다.

본 개시는 일반적으로 IMS 시스템에서의 인증에 관한 것이다. 이러한 인증의 하나의 양태에서, MCPTT에 관한 IMS 시스템의 사용이 이하에서 논의된다. 그러나, 이것은 IMS 네트워크의 유일한 용도는 아니며 IMS 인증은 별개의 또는 상이한 애플리케이션에 대해 동일하게 사용될 수 있을 것이다. 따라서, 아래의 MCPTT의 사용은 예시적인 것으로만 의도된다.

IMS 인증의 결함의 하나의 예가 MCPTT와 관련하여 예시된다. MCPTT는, 예를 들면, 최초 대처자에 의해 활용되며, 다양한 요건을 갖는다. 이들은, 임의의 유저가 임의의 디바이스를 픽업하여 그것을 사용할 수 있어야 한다는 것을 포함할 수도 있지만, 그러나 이것으로 제한되는 것은 아니다. 따라서, 개별적으로 할당되지는 않았지만, 그러나 필요에 따라 유저에게 제공되는 다수의 디바이스가 소방서에 있는 경우, 임의의 소방관은 이용 가능한 디바이스 중 임의의 것을 픽업하여 그러한 디바이스를 활용할 수 있어야 한다.

MCPTT는 또한, 공공 안전 서비스 공급자 및 공공 안전 유저의 안전 요건을 충족하기 위해, 디바이스 상의 MCPTT 애플리케이션의 인증이 셀룰러/IMS 네트워크와는 독립적일 필요가 있다는 것을 요구할 수도 있다.

제3 양태에서, MCPTT는 디바이스를 사용하고 있는 유저의 아이덴티티 또는 역할을 숨기거나 불명확하게 할 수 있을 필요가 있을 수도 있다. 예를 들면, 최초 대처자가 경찰관인 경우, 몇몇 상황에서는, MCPTT 애플리케이션을 사용할 때 그 경찰관의 아이덴티티의 기밀성을 보호하는 것이 바람직할 수도 있다. 불명확하게 하는 것은, 캐리어 또는 네트워크 오퍼레이터로부터 진정한 공개 아이덴티티를 불명확하게 하는 것을 포함할 필요가 있을 수도 있다.

상기에서 설명되는 세 개의 양태, 및 IMS 인증이 이하에 설명되는 바와 같이 동작하는 방식이 주어지면, IMS 인증은 MCPTT와 호환 가능한 기능성을 제공하지 않는다. 구체적으로, 인증의 현재의 IMS 방법은 IMS 개인 유저 아이덴티티에 기초하며, 상이한 개개의 IMS 공개 유저 아이덴티티가, 동일한 또는 상이한 IMS 개인 유저 아이덴티티를 가지고 개별적으로 인증되는 것을 허용하지 않는다. 따라서, 예를 들면, 제1 유저 및 제2 유저가 비동시적인 방식으로 동일한 모바일 디바이스를 사용하는 경우, 시스템은 유저가 누구인지를 구별할 수 없고 그러므로 두 유저를 상이하게 인증할 수 없으며 다른 액세스를 허여하는 동안 하나의 액세스를 거절할 수 없다. 따라서, 본 개시는, 디바이스와 유저 둘 모두를 인증하기 위한 그리고 그 다음 유저가 디바이스를 사용하도록 허용되어야 하는지 또는 그렇지 않은지의 결정을 제공하기 위한 방법 및 시스템을 제공한다.

본원에서 사용되는 바와 같이, 용어 개인 식별자 및 개인 유저 식별자는 상호 교환 가능하게 사용될 수도 있다.

이하의 본 개시에 따라, 상기의 문제점에 대한 다양한 솔루션이 제공된다. 특히, 본 개시는, 별개의 공개 아이덴티티 검증을 피기 백(piggy back)하기 위해 현재의 IMS 인증 메시징을 활용하는 다양한 대역 내 솔루션을 설명한다. 하기에 설명되는 다른 솔루션은, 일반 IMS 인증 이외의 메시징을 활용하여 공개 아이덴티티의 검증을 제공하는 대역 외 솔루션을 포함한다. 또한, 하기에 설명되는 대역 내 또는 대역 외 시그널링 솔루션 중 어느 하나에서 사용될 수도 있는, 공개 유저 아이덴티티에 기초한 다양한 키잉이 제공된다. 기술 분야에서 숙련된 자는, 이들 대역 내, 대역 외 및 공개 유저 아이덴티티에 기초한 키잉이 다양한 방식으로 결합되어 추가적인 실시형태로 귀결될 수 있다는 것을 인식할 것이다.

하기에 설명되는 실시형태의 하나의 양태에서, 특정한 유저의 유저 아이덴티티는 시스템에서 불명료하게 될 수도 있고, 공개 아이덴티티를 불명확하게 하기 위한 다양한 솔루션이 제공된다.

이제, 4 세대(4th Generation; 4G) 네트워크에 연결되는 예시적인 IMS 네트워크의 개요를 도시하는 도 1에 대한 참조가 이루어진다. 도 1의 예는 네트워크 아키텍쳐 내의 다양한 컴포넌트를 예시하도록 의도되는 것에 불과하다. 도 1의 실시형태는 제한적이지 않으며, 실제 네트워크는, 대부분의 경우, 추가적인 컴포넌트와 함께, 컴포넌트 중 일부 또는 모두를 가질 것이다.

또한, 하기에서 설명되는 바와 같이, 엘리먼트의 각각은 로직 블록으로 간주될 수도 있다. 즉, 엘리먼트의 기능성은 하나의 서버에 결합될 수도 있다. 또한, 단일의 엘리먼트의 기능성은 다수의 물리적 서버에 걸쳐 분할될 수도 있고, 본 개시는 임의의 특정한 물리적 아키텍쳐의 사용으로 제한되지 않는다.

도 1의 예에서, 4 세대(4G) 네트워크(110)는 표준화된 패킷 데이터 통신을 제공하기 위해 IMS 네트워크(130)를 활용할 수도 있다. 특히, 4G 네트워크(110)는, 디바이스(112) 또는 디바이스(114)가 통신할 수도 있는 3 세대(third generation; 3G) 롱 텀 에볼루션(long term evolution; LTE) 또는 시스템 아키텍쳐 에볼루션(system architecture evolution; SAE) 네트워크일 수도 있다. 디바이스(112 및 114)는 셀룰러 네트워크를 통해 통신할 수 있는 임의의 디바이스일 수도 있으며, 예를 들면, 유저 기기(user equipment; UE), 모바일 디바이스, 스마트폰, 랩탑, 태블릿, 또는 임의의 다른 데이터 가능 디바이스를 포함할 수도 있다.

디바이스(112)는 LTE-Uu 인터페이스를 통한 직교 주파수 분할 멀티플렉싱(orthogonal frequency division multiplexing; OFDM) 통신을 활용하여 진화된 Node-B(evolved Node-B; eNB)(116)를 통해 통신한다.

마찬가지로, 디바이스(114)는 LTE-Uu 인터페이스를 통해 eNB(118)와 통신한다.

eNB(116 및 118)의 각각은 두 개의 엔티티, 즉 서빙 게이트웨이(120) 및 이동성 관리 엔티티(mobility management entity; MME)(122)와 통신한다. MME(122)는 유휴 모드 UE 페이징을 담당하고, UE가 연결 모드(connected mode)로 이동할 때 서빙 게이트웨이(120)를 선택하는 역할도 또한 담당한다.

서빙 게이트웨이(120)는 디바이스(112 및 114)로부터의 패킷을 라우팅 및 포워딩한다.

서빙 게이트웨이(120)는 SAE 앵커(124)와 통신한다. SAE 앵커(124)는, 다른 비 3세대 파트너십 프로젝트(3rd Generation Partnership Project; 3GPP) 액세스 시스템 중에서도, 미국 전기 전자 기술자 협회(Institute for Electrical and Electronics Engineers; IEEE) 802.11(Wi-Fi; 와이파이)과 같은 시스템에 대한 비 3GPP 액세스 계층과 3GPP 액세스 계층 사이의 이동성을 위해 유저 평면을 앵커링하는 기능적 엔티티이다.

MME(122)는 3GPP 앵커(126)와 통신한다. 3GPP 앵커(126)는 제2 세대 및 제3 세대 액세스 계층과 LTE 액세스 시스템 사이의 이동성을 위해 유저 평면을 앵커링하는 기능적 엔티티이다.

IMS 네트워크(130)는 다양한 논리적 엔티티를 통해 4G 네트워크(110)와 통신할 수도 있다. 제1 양태에서, MME(122)는 홈 가입자 서버(home subscriber server; HSS)(132)와 통신할 수도 있다. HSS(132)는, 아이덴티티 및 그들이 가입한 서비스를 포함하는 가입자의 프로파일을 포함하는, 그리고 위치 결정 기능성뿐만 아니라 인증 데이터베이스를 제공하는 데이터베이스이다.

MME(122)는 또한 정책 및 과금 규칙 기능(policy and charging rules function; PCRF) 서버(134)와 통신할 수도 있다. PCRF(134)는, 가입자의 정책뿐만 아니라 이러한 가입자에게 청구되는 금액 둘 모두를 제어하는 IMS 네트워크 내의 엘리먼트이다.

PCRF(134) 및 HSS(132)뿐만 아니라 3GPP 앵커(126)는, IMS 네트워크(130)의 호 서버 제어 기능(call server control function; CSCF)(136)과 통신할 수도 있다. CSCF(136)는 IMS 네트워크(130)에서 SIP 시그널링 패킷을 프로세싱하기 위해 사용되는 몇몇 세션 개시 프로토콜(session initiation protocol; SIP) 서버 또는 프록시를 제공한다.

특히, CSCF(136)는 IMS 네트워크로의 제1 진입 지점인 프록시 호 세션 제어 기능(proxy call session control function; P-CSCF)을 포함하는 다양한 논리적 엔티티를 포함할 수도 있다. 또한, 서빙 호 세션 제어 기능(serving call session control function; S-CSCF)은 네트워크 내의 세션을 핸들링하고 SIP 메시지를 적절한 P-CSCF뿐만 아니라 IMS 애플리케이션 서버(IMS application server; IMS AS)로 라우팅한다. 또한, CSCF(136)는 네트워크에서 가입자를 발견하고 가입자가 네트워크에 등록할 때 S-CSCF를 할당함에 있어서 보조하기 위해 진입 지점으로서 사용되는 질의 호 세션 제어 기능(interrogating call session control function; I-CSCF)을 포함할 수도 있다.

IMS 애플리케이션 서버(application server; AS)(138)는 IMS 가입자에 대한 서비스를 실행하는 로직 및 소프트웨어를 갖는 애플리케이션 서버이다. IMS 네트워크(130)는 네트워크에서 이들 IMS AS(138)를 0과 다수 개 사이에서 가질 수도 있다. CSCF(136)는 도 1의 예에서 도시되는 바와 같이, 인터넷 전화(voice-over IP) 서비스(VOIP)에 출력을 제공할 수도 있다.

CSCF(136)는 또한, 미디어 조작과 같은 미디어 관련 기능을 제공하는 미디어 리소스 기능(media resource function; MRF)(140)과 통신할 수도 있다. MRF(140)는 또한 미디어 서버(142)에 연결될 수도 있다.

CSCF(136)는, 도메인 네임 서버(domain name server; DNS) 라우팅이 사용될 수 없을 때 S-CSCF로부터의 SIP 요청의 프로세싱을 허용하는 브레이크아웃 게이트웨이 제어 기능(breakout gateway control function; BGCF)(144)과 연결될 수도 있다.

CSCF(136) 및 BGCF(144) 둘 모두는, 회선 교환 도메인에 대한 액세스를 허용하기 위해 IMS 미디어 게이트웨이(IMS media gateway; IMS MG)(148)와 통신하는 미디어 게이트웨이 제어 기능(media gateway control function; MGCF)(146)과 통신할 수도 있다.

또한, MGCF(146)는, 회선 교환 도메인과의 통신을 또한 허용할 수도 있는 시그널링 게이트웨이(signaling gateway; SG)(150)와 통신할 수도 있다.

소정의 상황에서, 4G 네트워크(110) 외에, 3G 네트워크 또는 3.5G 네트워크(160)가 활용될 수도 있다. 이 경우, 디바이스(162 또는 164)는, Uu 인터페이스를 통한 고속 패킷 액세스(high speed packet access; HSPA)를 활용하여, node-B(166) 및 node-B(168)와 각각 통신할 수도 있다.

node-B(166 및 168) 둘 모두는, RNC(170)에 연결되는 node-B를 제어하는 무선 네트워크 제어부(radio network control; RNC)(170)와 통신한다.

RNC(170)는, SGSN(172)의 지리적 위치에 있는 이동국으로 그리고 이동국으로부터 패킷을 전달하는 것을 담당하는 서빙 범용 패킷 무선 서비스(general packet radio service; GPRS) 지원 노드(serving GPRS support node; SGSN)(172)와 통신한다. RNC(170)는 또한, 네트워크 스위칭 소자를 제어하는 모바일 스위칭 센터(mobile switching center; MSC)(174)와 통신한다.

SGSN(172)은 게이트웨이 GPRS 지원 노드(GGSN)(176)에 연결될 수도 있다. SGSN(172)은 또한, 4G 네트워크와 3G 네트워크 사이에서 디바이스를 이동시키기 위해 4G 네트워크의 서빙 게이트웨이(120)와 그리고 MME(122)와 통신한다.

GGSN(176)은 또한, CSCF(136)를 통해 IMS 네트워크(130)를 활용할 수도 있다.

도 1의 실시형태에서, 펨토셀(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 등록은 기저의 액세스 네트워크와는 독립적이고, 그 결과 액세스 무관 서비스(access agnostic service)가 표준화되는 것을 허용하게 된다.

유저가 네트워크에 등록하면, 네트워크와 IMS 디바이스 사이에 보안 관련성이 생성된다. 이것은, 유저가 그들이 가입한 IMS 서비스를 사용하는 것, 및 디바이스와 P-CSCF 사이에 인터넷 프로토콜 보안(internet protocol security; IPSec) 터널을 셋업하는 것에 의해 데이터를 또한 보호하는 것을 허용한다.

이하에서 설명되는 바와 같이, IMS 디바이스는 SIP 유저 에이전트(User Agent; UA)로 지칭될 것이다. 그러나 이것은 제한적이지 않으며 임의의 디바이스가 활용될 수 있을 것이다.

SIP UA는 클라이언트 SIP 기능성을 구현하는 논리적 엔티티이다. SIP UA의 몇몇 구현예는 무선일 수 있거나 또는 고정될 수 있는데, 예컨대 셋탑 박스, 랩탑, 데스크탑 등등일 수 있지만 그러나 이들로 제한되지는 않는다. SIP UA는 네트워크에 두 개의 아이덴티티를 제공한다. 첫 번째는, IMS 개인 아이덴티티(IMS private identity; IMPI)로 알려진 개인 IMS 아이덴티티이며 다른 하나는 IMS 공개 아이덴티티(IMS public identity; IMPU)로 칭해지는 공개 유저 아이덴티티로 알려져 있다.

공개 아이덴티티는, 유저와 접촉하기 위해 사용될 수도 있는 아이덴티티이다. IMPI는, SIP UA를 인증하기 위해 그리고 IMS 시스템에 대한 액세스를 허여하기 위해 사용되는 아이덴티티이다. IMPI는 홈 오퍼레이터의 네트워크 내의 HSS(132)에 저장되며, 범용 가입자 식별 모듈(universal subscriber identity module; USIM) 상에 저장되는 국제 가입자 식별 정보(international subscriber identity; IMSI)로부터 도출될 수도 있거나 또는 IMS 가입자 식별 모듈(IMS subscriber identity module; ISIM)에 저장될 수도 있다.

상기의 것은, 예를 들면, 2012년 12월의 3세대 파트너십 프로젝트(3GPP) 기술 명세(Technical Specification; TS) 33.203, "3G security; Access security for IP-based services", v.12.8.0에서 설명되는데, 그 내용은 참조에 의해 본원에 통합된다.

이 기술 표준의 섹션 6.1은 인증 및 키 합의(authentication and key agreement; AKA)를 다룬다. 특히, 섹션 6.1.0에서 설명되는 바와 같이, IMS AKA는, 존재하는 경우 ISIM, 그렇지 않으면 USIM과 홈 네트워크(home network; HN) 사이의 상호 인증을 달성한다. 가입자를 인증하기 위해 사용되는 아이덴티티는, 예를 들면, RFC 4282에서 설명되는 바와 같은 포맷인 3GPP TS 23.228에서 설명되는 바와 같이, 네트워크 액세스 식별자(network access identifier; NAI)의 형태를 갖는 개인 아이덴티티인 IMPI이다. HSS 및 ISIM/USIM은 IMPI와 관련되는 장기간 키(long-term key)를 공유한다.

또한, 3GPP TS 33.203 명세의 섹션 6.1.1에서 설명되는 바와 같이, 유저가 IM 서비스에 액세스할 수 있기 이전에, 적어도 하나의 IMPU가 등록될 필요가 있고 IMPI는 애플리케이션 레벨에서 IMS에서 인증될 필요가 있다. 따라서 IMPI는 또한, 가입 프로파일이 저장되는 HSS를 식별하기 위해 사용된다.

IMPI 및 IMPU 둘 모두는 오버 디 에어(Over The Air; OTA) 기능성을 사용하여 USIM/ISIM 상에서 변경될 수 있다. 이 OTA 기능성은 오퍼레이터가 ISIM/USIM 상에서 데이터 항목을 변경하는 것을 허용한다.

SIP UA 기능성과 관련되는 하드웨어가 3GPP 시스템에 액세스하기 위해 사용되는 경우, 범용 집적 회로 카드(universal integrated circuit card; UICC)도 또한 존재할 것이다. UICC는 USIM 애플리케이션 및 어쩌면 ISIM 애플리케이션과 같은 애플리케이션을 포함한다. USIM 및 ISIM 애플리케이션은 3GPP 네트워크에 액세스하기 위한 인증 알고리즘 및 아이덴티티를 포함한다.

USIM은 3GPP AKA로 칭해지는 인증 메커니즘 및 IMSI를 포함한다. ISIM은 username@domain 형태의 개인 아이덴티티를 포함하며 공개 유저 아이덴티티도 또한 같은 형태이다. ISIM은 IMS AKA로 칭해지는 인증 메커니즘을 또한 포함하지만, 알고리즘의 출력은 상이하다.

따라서, SIP UA의 인증은 IMPI를 사용하여 수행된다. 인증을 위해 사용되는 IMPI는 IMSI의 것에 비유될 수 있으며 ISIM 개인 아이덴티티로부터 획득될 수 있거나; 또는 ISIM이 존재하지 않거나 또는 IMPI를 저장하고 있지 않으면 USIM IMSI로부터 도출될 수 있다.

IMPI는 IMPU와 함께, SIP REGISTRATION 메시지에서 네트워크로 전송된다. 네트워크는, AKA 메커니즘과 연계하여 사용되는 IMPI에 기초하여, 다수의 인증 벡터를 되전송할(send back) 것이다. 이들은, 예를 들면, 섹션 6.1.1의 3GPP TS 33.203에서 설명된다.

이제, 도 2에 대한 참조가 이루어진다. 특히, 도 2에서 보여지는 바와 같이, UE(210)는 SIP 레지스터 메시지(230)를 P-CSCF(212)로 전송한다. 그 다음, SIP 레지스터 메시지는 메시지(232)로서 l-CSCF(214)로 포워딩된다. 그 다음, l-CSCF(214)는, 블록(234) 및 메시지(236)에 의해 도시되는 바와 같이, 레지스터 메시지에 대해 HSS(216) 및 S-CSCF(218)를 선택한다.

그 다음, 시도(challenge)가 UE로 되전송되고 시도에 기초하여 등록이 발생한다. 특히, S-CSCF는, 블록(240)에 의해 도시되는 바와 같이, HSS(216)와 함께 PUT를 수행하고, 그 다음, 메시지(242)에 의해 도시되는 AV-요청(AV-request)을 HSS(216)로 전송한다. AV-요청-응답(AV-request-response)(244)은 S-CSCF(218)에서 HSS(216)로부터 수신된다.

그 다음, S-CSCF(218)는 메시지(250)에서 인증 시도(authentication challenge)를 l-CSCF(214)로 전송한다. 인증 시도는 메시지(252)에서 P-CSCF(212)로, 그 다음, 메시지(254)에서 UE(210)로 포워딩된다.

시도에 대한 응답은 IMSI에 관한 벡터의 형태이며, 그 다음, 응답은 HSS 및 S-CSCF로 되전송되는데, HSS 및 S-CSCF는, 그 다음, 인증이 올바른지 또는 그렇지 않은지의 여부를 확인할 수도 있다. 구체적으로, 응답은, UE(210)로부터 P-CSCF(212)로 전송되는 등록 메시지(register message)(260)이다. 그 다음, 응답은 메시지(262)에서 l-CSCF(214)로 포워딩된다. I-CSCF(214)는, HSS(216)와 함께, 블록(264)에 의해 도시되는 Cx-Query를 수행하고, 그 다음, 메시지(266)에 의해 도시되는 바와 같이 S-CSCF(218)로 응답을 포워딩한다.

그 다음, S-SCSF(218)는 HSS(216)와 함께 응답을 검증하는 데, Cx-Put 블록(270) 및 Cx-Pull 블록(272)으로 도시된다. 인증이 성공적이면, 성공 메시지(280)가 S-CSCF(218)로부터 I-CSCF(214)로 전송된다. 그 다음, 성공 메시지는 메시지(282)로서 P-CSCF(212)로, 그리고 메시지(284)로서 UE(210)로 포워딩된다.

IMS는 또한 복수의 공개 유저 아이덴티티가 개인 유저 아이덴티티와 관련되는 것을 허용한다. 실제로 공개 유저 아이덴티티는, 예를 들면, 도 3과 관련하여 도시되는 바와 같이, 많은 개인 유저 아이덴티티와 관련될 수 있다.

도 3은, 2015년 3월의 3GPP TS 23.228의 도 4.6인 "IP Multimedia Subsystem(IMS); Stage 2", v.13.2.0의 재현인데, 그 내용은 참조에 의해 본원에 통합된다. 특히, 도 3에서 알 수 있는 바와 같이, IMS 가입(310)은 두 개의 개인 유저 아이덴티티(320 및 330)를 포함한다. 개인 유저 아이덴티티(320)는 두 개의 공개 유저 아이덴티티, 즉 공개 유저 아이덴티티(322 및 324)를 포함한다.

개인 유저 아이덴티티(330)는 공개 유저 아이덴티티(324)뿐만 아니라 공개 유저 아이덴티티(332)를 더 포함한다.

공개 유저 아이덴티티(322)는 서비스 프로파일(340)과 관련되고 공개 유저 아이덴티티(324) 및 공개 유저 아이덴티티(332)는 서비스 프로파일(342)을 공유한다.

따라서, 도 3에서 보여지는 바와 같이, IMS 가입은, 개인 유저 아이덴티티 중 하나 이상과 관련되는 다양한 개인 유저 아이덴티티 및 공개 유저 아이덴티티를 가질 수도 있다.

공개 유저 아이덴티티(322, 324 또는 332)와 관련되는 인증은 없다. 어떤 유저 아이덴티티가 UE에 의해 사용될 수 있는지의 감시(policing)는, HSS가 디바이스에 의해 사용될 수 있는 공개 유저 아이덴티티를 S-CSCF를 통해 P-CSCF로 다운로드하는 것에 의해 수행된다. 디바이스가 세션을 시작하면, P-CSCF는 유효한 공개 유저 아이덴티티만이 사용되는 것을 보장할 것이다.

IMPU가 IMS 네트워크에 등록되면, HSS는 S-CSCF로 서비스 프로파일을 다운로드할 것이다. 도 3의 서비스 프로파일(340 또는 342)과 같은 서비스 프로파일은, 어떤 상황 하에서 IMS 애플리케이션 서버가 호/세션에 수반되어야 하는지를 설명한다. 예를 들면, 서버는 공개 유저 아이덴티티와 관련되는 서비스의 실행에서 수반될 수도 있고 S-CSCF에 의해 제어될 것이다.

상기에서 확인되는 바와 같이, IMS 인증 메커니즘은 IMS AKA로 칭해진다. IMS는 또한, SIP 다이제스트(SIP Digest), 전송 레이어 보안(Transport Layer Security; TLS), GPRS-IMS-번들 인증(GPRS-IMS-Bundled Authentication; GIBA)을 포함하는, 그러나 이들로 제한되지는 않는 다른 인증 스킴(scheme)이 지원되는 것을 허용한다. 네트워크 액세스 서브시스템(Network Access Subsystem; NASS)-IMS 번들 인증은 또한, 고정된 특정 위치로부터의 인증 또는 IMS AKA가 이용 불가능한 초기 IMS 배치에 대한 인증 중 어느 하나에 대해 사용되도록 허용된다. GPRS IMS 번들 인증은, 번들링되는 NASS-IMS의 다른 변형이며 초기 IMS 배치에 대해 사용된다. 이러한 인증 스킴은, 예를 들면, 3GPP TS 33.203에서 섹션 N.1, O.1.1, R.1 및 T.1에서 설명된다.

그러나, 공개 유저 아이덴티티를 검증하는 방식은 없다. 이것은 소정의 애플리케이션에서 문제를 제기한다. 예를 들면, 이것이 문제를 제시할 수도 있는 하나의 애플리케이션은, 하기에 설명되는 미션 크리티컬 푸시 투 토크(MCPTT)이다.

미션 크리티컬 푸시 투 토크

미션 크리티컬 푸시 투 토크는 긴급 서비스와 같은 미션 크리티컬 타입 동작을 위해 사용되는 푸시 투 토크 서비스이다. 그러나, 그것은 또한, 다른 것들 중에서도, 공익 사업(utility), 택시를 포함하는 상업적 유저로 확장할 수도 있다. 몇몇 경우에, MCPTT는, 오늘날 개인 모바일 무선(private mobile radio; PMR) 시스템이 존재하는 곳이면 어디에서나 사용될 수도 있다.

MCPTT 3GPP 서비스는, 2015년 3월의 3GPP TS 22.179, "Mission Critical Push to Talk(MCPTT) over LTE; Stage 1", v.13.1.0에서 설명되는데, 그 내용은 참조에 의해 본원에 통합된다.

본 명세의 섹션 4.5에서 다음과 같이 설명된다:

또한, 3GPP TS 22.179 명세의 섹션 4.5.1은 다음을 나타낸다:

또한, 3GPP TS 22.179의 섹션 4.5.2로서 명세는 다음과 같이 설명한다:

마지막으로, 이 기술 명세의 섹션 4.5.4는 다음과 같이 설명한다:

상기 기술 명세로부터, 다양한 것이 추론될 수도 있다. 하나의 요건은, 예를 들면, 제1 그룹으로부터의 유저가 제2 그룹에 속하는 디바이스를 사용할 수 있을 것이다는 것이다. 예를 들면, 프랑스 경찰이 네덜란드 경찰에 속하는 디바이스를 사용할 수 있을 수도 있다.

MCPTT 아키텍쳐의 하나의 예는, 2015년 2월의 3GPP TS 23.779, "Study on application architecture to support Mission Critical Push To Talk over LTE(MCPTT) services", v.0.5.0에서 제공되며, 예를 들면, 그 명세의 도 5.2.1.1.1-1에서 도시되어 있는데, 그 내용은 참조에 의해 본원에 통합된다. 특히, 공공 안전 유저는 서버 또는 서버의 그룹에 그들 자신의 애플리케이션을 가질 수도 있다. 이러한 애플리케이션은, 공공 안전청(Public Safety Administration)에 의해 운영되고 "모바일 가상 네트워크 오퍼레이터"의 타입으로서 기능하며 IMS 및 공공 안전 애플리케이션에 의해 요구되는 HSS의 기능을 제공하는 PS-UDF(public safety-user data function; 공공 안전-유저 데이터 기능)를 포함하는 그리고 IMS 네트워크의 S-CSCF와 통신하는 애플리케이션을 포함할 수도 있다. 따라서 PS-UDF는 HSS를 대체한다.

HSS의 대체로 인해, 전통적인 가상의 공공 지상 모바일 네트워크(virtual public land mobile network; VPLMN)와의 로밍이 요구될 수 있을 것이다. 그러나, 몇몇 실시형태에서, EPC 레벨 보안은 종래의 HSS를 사용하고 한편 공공 안전 관리는 PS-UDF를 사용한다.

공공 안전 기관 서버(public safety authority server)의 일부일 수도 있는 다른 애플리케이션은 MCPTT 서버를 포함할 수도 있다. 이 경우, PS-UDF는 모바일 종료 호/세션 확립 및 서비스 호출에 대한 인가를 제공하고 공공 안전 애플리케이션 서버에 의해 유저에게 제공될 서비스를 트리거하기 위한 필터 기준을 사용하여 S-CSCF를 업데이트한다. PS-UDF는 IMS에서 MCPTT 서비스를 지원하기 위해 MCPTT 서버 및 그룹 관리 기능과 통신한다. 하나의 실시형태에서, MCPTT 서버는, 오픈 모바일 얼라이언스(open mobile alliance; OMA) 공공 안전을 위한 푸시 투 커뮤니케이트(push to communicate for public safety; PCPS) 아키텍쳐에서의 셀룰러를 통한 푸시 투 토크(push to talk over cellular; PoC) 서버와 등가이다.

이상으로부터, 공공 안전 서비스의 아키텍쳐는 S-CSCF를 통해 IMS 시스템과 통신하고 PS-UDF 및 MCPTT 서버를 포함하는 하나 이상의 서버를 포함한다.

동작에서, MCPTT는 도 4에서 설명되는 바와 같이 전개될 수도 있다. 특히, 도 4에서 설명되는 바와 같이, 공공 안전 오퍼레이터는 애플리케이션 기반 구조(applications infrastructure)(410)뿐만 아니라, 공공 안전 오퍼레이터(412)를 지원하는 SIP IMS 코어를 구비할 수도 있다.

그 다음, 정규 PLMN은, 공공 안전 오퍼레이터(420)를 지원하는 IP(EPC) 코어뿐만 아니라, LTE(424)와 같은 액세스 네트워크를 포함하는 소정의 시그널링을 위해 사용될 수도 있다.

공공 안전 UE(430)는 그룹 관리 클라이언트(432)뿐만 아니라 MCPTT 클라이언트(434)를 포함할 수도 있다.

도 4에 의해 알 수 있는 바와 같이, 공공 안전 기관의 애플리케이션 기반 구조 사이의 제어 시그널링은 그룹 관리 클라이언트(432)뿐만 아니라 MCPTT 클라이언트(434)로 제어 시그널링을 제공한다.

또한, 유저 데이터 및 내장된 제어가 애플리케이션 기반 구조(410)로부터 MCPTT 클라이언트(434)로 제공된다.

도 4의 배치 모델의 하나의 사용에서, 디바이스가 무엇을 위해, 또는 누구에 의해 사용되고 있는지를 셀룰러 오퍼레이터가 알지 못하는 IMS 레이어의 완전한 제어가 제공될 수도 있다. 이 경우, 디바이스는, 셀룰러 네트워크에서 사용될 일반 공개 유저 아이덴티티를 가질 것이다. 그러나, IMS 네트워크에서, 이 아이덴티티는 셀룰러 오퍼레이터에 대한 변경의 가시성이 없어도 변경될 것이다.

확장성 인증 프로토콜

확장성 인증 프로토콜은 확장성 인증 프레임워크이다. 그것은 기본 메시징 구조에 다른 인증 스킴을 통합하기 위한 필요한 도구를 제공한다. 생성된 다수의 EAP 메커니즘이 존재한다. 하나의 EAP 메커니즘은 EAP 터널 전송 레이어 보안(EAP-tunneled transport layer security; EAP-TTLS)이다. 이 인증 스킴에서, 클라이언트는, 클라이언트와 TTLS 서버 사이에 보안 터널을 셋업하는 것에 의해, 그 다음, 보안 터널 내에서, 다른 인증 프로토콜이 클라이언트를 인증하도록 사용되는 것을 허용하는 것에 의해, 인증, 인가 및 과금(authentication, authorization and accounting; AAA) 기반 구조에서 확실하게 인증될 수 있다.

EAP-TTLS는, 예를 들면, 2008년 8월의 국제 인터넷 표준화 기구(Internet Engineering Task Force; IETF)의 코멘트에 대한 요청(request for comments; RFC) 5281"Extensible Authentication Protocol Tunneling Transport Layer Security Authenticated Protocol version 0"에서 설명되는데, 그 내용은 참조에 의해 본원에 통합된다. 이제, RFC 5281의 섹션 6으로부터의 프로토콜 스택을 도시하는 도 5a 및 도 5b에 대한 참조가 이루어진다.

특히, 도 5a에서 보여지는 바와 같이, 유저 인증 프로토콜 자체가 EAP가 아닌 경우, EAP-TTLS 패킷은 EAP 내에 캡슐화되고 그 다음 EAP는 캐리어 프로토콜이 그것을 전송하는 것을 필요로 한다. EAP-TTLS 패킷 자체는 TLS를 캡슐화하는 데, TLS는, 그 다음, 유저 인증 또는 다른 정보를 전달할 수도 있는 속성-값 쌍(attribute-value pair; 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를 캡슐화하기 위한 방법이 이미 정의된 EAP법 레이어(538)를 더 포함한다. 예를 들면, 클라이언트와 액세스 포인트 사이에서 EAP를 전송하기 위해 포인트 투 포인트 프로토콜(Point to Point Protocol; PPP) 또는 LAN을 통한 확장성 인증 프로토콜(Extensible Authentications Protocol over LAN; EAPOL)이 사용될 수도 있거나 또는 액세스 포인트와 TTLS 서버 사이에서 EAP를 전송하기 위해 RADIUS(반경) 또는 Diameter(다이어미터)이 사용된다.

MCPTT에 대한 IMS 인증

따라서, MCPTT는, 임의의 유저가 임의의 디바이스를 픽업하여 그것을 사용할 수 있어야 한다는 것을 규정한다. 예를 들면, 소방서에는 임의의 소방관이 픽업하여 사용할 수도 있는 디바이스의 박스가 구비될 수도 있다. 또한, MCPTT 애플리케이션의 인증은 공공 안전 서비스 공급자 및 공공 안전 유저의 보안 요건을 충족하기 위해 셀룰러/IMS 네트워크와는 독립적일 필요가 있고, 몇몇 경우에, 디바이스를 사용하고 있는 유저의 아이덴티티 또는 역할을 숨기거나 불명확하게 하는 것이 바람직할 수도 있다. 따라서, MCPTT는 현재의 IMS 인증 프로토콜에 잘 맞지 않다.

본 개시의 실시형태에 따르면, 개별적인 공개 및 개인 유저 아이덴티티를 제공하기 위한 다양한 인증 스킴이 설명된다. 또한, 유저의 아이덴티티를 불분명하게 하기 위한 방법 및 시스템이 설명된다. 이하의 본 개시가 MCPTT와 관련하여 설명되지만, 이하에서 설명되는 인증 시스템 및 방법의 사용은 다른 애플리케이션에 대해 동일하게 사용될 수 있다. 따라서, 본 개시는 MCPTT로 제한되지 않는다.

하기에 설명되는 실시형태에서, 솔루션은 대역 내 시그널링 및 대역 외 시그널링 둘 모두에 대해 제공된다. 본원에서 사용되는 바와 같이, 대역 내 시그널링은, 새로운 형태의 인증이 수행될 필요가 있다는 것을 나타내기 위해 추가적인 정보를 전달하도록 향상되는 IMS UE를 인증하기 위해 현존하는 IMS 메시징을 활용하는 신호를 의미한다. 또한, 본원에서 사용되는 바와 같이, 대역 외 시그널링은 IMS UE를 인증하기 위해 사용되는 현재의 시그널링 경로의 것 이외의 새로운 시그널링 경로가 사용된다는 것을 의미한다. 다시 말하면, 대역 외 시그널링은, IMS UE를 인증하기 위해 현재 사용되는 시그널링이 향상되지 않고 개개의 가입자를 인증하기 위해 다른 메커니즘이 사용된다는 것을 의미한다.

다양한 대역 내 및 대역 외 실시형태가 하기에서 제공된다.

하기에 설명되는 실시형태는 완전한 실시형태로서 제공된다. 그러나, 기술 분야에서 숙련된 자는, 각각의 솔루션의 일부가 다른 솔루션과 함께 사용되어 다른 잠재적인 솔루션을 형성할 수 있다는 것을 인식할 것이다. 또한, 몇몇 인코딩 메커니즘이 특정한 구현예와 함께 나타내어진다. 그러나, 특정한 구현예는 다양한 솔루션에 걸쳐 혼합 및 매치될 수 있다. 또한, 표준에 대한 다양한 변경이 부록(Appendix) 및 표에서 설명된다. 이들은 다른 특정한 실시형태를 나타내며 동일하게 혼합 및 매치될 수 있다. 기술 분야에서 숙련된 자는, 이러한 예시적인 변경이 예시적인 목적을 위해서 또한 사용되며 코딩이 다수의 다른 방식으로 동등하게 행해질 수 있을 것이다는 것을 인식할 것이다.

이중 인증을 위한 대역 내 표시

하나의 실시형태에서, IMS 등록 메시지가 새로운 표시를 포함하도록 향상된다. 새로운 표시는, IMS 개인 유저 아이덴티티(1차 인증 메커니즘)만을 인증하는 대신, IMS 공개 유저 아이덴티티 인증도 또한 수행될 필요가 있다는 것(2차 인증 메커니즘)을 네트워크에 시그널링한다. 그 표시는, UE에서 두 세트의 인증 벡터가 필요로 된다는 것을 나타내기 위해, HSS 또는 PS-UDF와 같은 인증 데이터베이스로 전송될 수도 있다.

이제 도 6에 대한 참조가 이루어진다. 도 6의 실시형태에서, UE(610)는 IMS 시스템에서 인증되기를 원한다. 통신은 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)는 메시지(630)를 P-CSCF(612)로 전송한다. 메시지(630)는, 제1 공개 유저 아이덴티티, 제1 개인 유저 아이덴티티, 및 "이중 인증"(개인 및 공개 유저 ID의 인증)이 지원 또는 필요로 된다는 것을 나타내는 표시자(indicator)를 포함하는, 그러나 이들로 제한되지는 않는 다양한 정보를 포함한다. 하나의 실시형태에서, 메시지(630)의 식별자는 새로운 보안 방법을 식별하는 새로운 메커니즘/이름으로서 인코딩될 수도 있다. 예를 들면, 이러한 방법은 IPSEC-MCPTT로 지칭될 수도 있다. 대안적으로, 또는 추가적으로, 식별자는, 예를 들면, IETF RFC 3329에서 설명되는 바와 같이, security-client(보안-클라이언트) 필드에서 mech-parameters(mech-파라미터)로서 코딩될 수도 있다.

대안적인 실시형태에서, 메시지(630) 내의 식별자는 인가 헤더 필드 내의 새로운 파라미터일 수도 있다. 예를 들면, 새로운 AKA 버전 번호가 사용될 수도 있다.

또 다른 실시형태에서, 식별자는 지원되는 또는 요구되는 헤더 필드에서 옵션 태그로서 인코딩될 수도 있다.

또 다른 실시형태에서, 식별자는 피쳐 태그로서 인코딩될 수도 있다.

또한, 식별자는 예를 들면, "doubleauthentication(이중인증)=yes(예)"와 같은 범용 리소스 식별자(universal resource identifier; URI) 파라미터로서 인코딩될 수도 있다.

또 다른 실시형태에서, 식별자는 확장성 마크업 랭기지(eXtensible Markup Language; XML) 본문(body)으로서 인코딩될 수도 있다. 그것은 또한 새로운 헤더로서 인코딩될 수도 있거나 또는 제1 공개 유저 아이덴티티 또는 제1 개인 유저 아이덴티티 중 어느 하나에 추가될 수도 있다.

예를 들면, 아래의 표 1에서, 굵은 글씨체의 항목은 상기에서 설명되는 다양한 방법의 일부 코딩을 나타낸다. 하기의 표 1은 동일한 등록 메시지 내에 모두 배치되는 다양한 옵션을 나타낸다. 그러나, 기술 분야에서 숙련된 자는, 몇몇 상황에서, 오직 하나의 식별자만이 필요로 되며, 하기의 굵은 글씨체로 나타내어진 것 중 임의의 것일 수 있을 것이다는 것을 알 것이다. 다른 상황에서는, 복수의 표시자가 있을 수 있을 것이다.

마찬가지로, 3GPP TS 24.229는 본원에 첨부되는 부록 A에 따라 변경될 수도 있다. 부록 A에서 굵은 글씨체로 나타내어지는 바와 같이, TS 24.229의 본문에 대해 추가 사항이 제공된다. 그러나, 상기의 표 1에서와 같이, 다양한 변경 모두가 부록 A로 그룹화되고, 기술 분야에서 숙련된 자는, 실제로는 굵은 글씨체의 변경 중 단지 하나의 변경 또는 부분 조합만이 필요로 될 수도 있다는 것을 인식할 것이다.

도 6을 다시 참조하면, P-CSCF(612)가 메시지(630)를 수신하면, 그것은 메시지(630)의 내용을 포함하는 메시지(632)를 S-CSCF(614)로 전송한다.

S-CSCF는 메시지(632)를 수신하고 인증 요청 메시지(634)를 HSS(618)로 전송한다. 3GPP TS 29.228 명세에서 메시지(634)에 대해 이루어질 수도 있는 변경의 하나의 예가 부록 B에서 굵은 글씨체로 제공된다. 부록 B에서 보여지는 바와 같이, 인증의 설명은, 예로서, 생체 인식 지문 데이터 및 IMS-AKA 인증을 포함할 수도 있다. 그러나, 부록 B의 변경은 예로서 의도되는 것에 불과하다.

S-CSCF가 제2 인증 다이제스트 헤더를 인식하고, 사용될 인증 스킴의 표시와 함께 새로운 MCPTT SIP 인증 스킴 속성 값 쌍(AVP)을 포함하는 부록 C에 관한 대안적인 실시형태가 도시된다.

구체적으로, 부록 C에서 보여지는 바와 같이, 완전히 새로운 인증 스킴이 정의된다.

제1 데이터베이스 기능, 예를 들면, HSS(618)는 메시지(634)를 수신하고, 그 다음, 메시지(636)에 의해 도시되는 바와 같이, 제2 데이터베이스 기능, 예를 들면, PS-UDF(620)로부터 인증 벡터를 획득할 수도 있다. 구체적으로, HSS는 도 6의 메시지(636)와 관련하여 도시되는 바와 같이 PS-UDF로부터 공개 유저 아이덴티티 번호에 대한 벡터의 세트를 획득할 수도 있다. HSS는 상기에서 식별되는 바와 같은 데이터 중 임의의 것 또는 전부를 포함하는 인증 요청 메시지를 PS-UDF로 전송할 것이다.

구현예와 관련하여, HSS(618)는 몇몇 실시형태에서 PS-UDF(620)와 결합될 수도 있다.

PS-UDF(620)는 공개 유저 아이덴티티를 수신하고 벡터의 세트로 응답할 것이다. 비록 시도 응답이 아래의 예로 제한되지는 않지만, 벡터는 다음의 시도 중 하나 이상을 포함할 수 있다. 구체적으로, AKA에 기초한 벡터의 예시적인 세트는 다음과 같은데:

여기서:

- RAND: XRES, CK, IK 및 AUTN의 일부를 생성하기 위해 사용되는 난수. 그것은 또한 UE에서 RES를 생성하기 위해 사용된다.

- AUTN: 인증 토큰(MAC 및 SQN을 포함함).

- XRES: UE로부터의 예상(올바른) 결과.

- CK: 암호 키(옵션 사항).

- IK: 무결성 키.

그러나, 벡터는 사용되고 있는 알고리즘에 기초하여 상이할 수 있을 것이다. 예를 들면, 벡터는, 차후 부록 B의 엔트리로 변환되는 SIP 레지스터에서 전달되는 데이터에 기초할 수도 있다. 다음과 같은 메시지: 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)로 다시(back) 제공할 수도 있다. 메시지(640) 내의 시도 벡터는 제1 개인 유저 아이덴티티 및 제1 공개 유저 아이덴티티에 대한 것일 수 있다. 제1 공개 유저 아이덴티티에 대한 시도 벡터는, 다른 가능성 중에서도, 피쳐 태그; XML 본문; AVP; 또는 새로운 헤더 중 임의의 하나로서 인코딩될 수도 있다. 예를 들면, 부록 D는 AVP 시도에 대한 3GPP 29.228에 대한 하나의 가능한 변경을 굵은 글씨체로 도시한다.

도 6의 실시형태에서, 따라서, HSS는 이중 인증 스킴의 식별로 인해 인증 벡터의 제2 세트를 포함하였다. 그 다음 이 정보 엘리먼트 후속하는 데이터는, 제1 공개 유저 아이덴티티와 관련된다. 부록 D의 변경에서, 마지막 네 개의 행은 제2 IMS AKA 기능과 관련되는 데이터 항목이지만 그러나 인증 메커니즘은 임의의 인증 메커니즘일 수 있을 것이다. 따라서, 부록 D에서 나타내어지는 SIP-authenticate는, 제1 공개 유저 아이덴티티에 제시되는 시도를 포함한다. 또한, 제1 공개 유저 아이덴티티가 인가된 엔티티에 의해 시도되고 있다는 것을 보장하기 위해 제1 공개 유저 아이덴티티가 사용할 수 있는 데이터 항목이 또한 존재한다.

부록 D의 SIP-authorization 엘리먼트는 시도에 대한 예상 결과이다. S-CSCF(614)는 메시지(640)를 수신하고 메시지(642)를 P-CSCF(612)로 제공한다. 메시지(642)는 개인 유저 및 공개 유저 아이덴티티 둘 모두에 대한 시도 벡터를 제공한다. 예를 들면, 아래의 표 2에서 보여지는 바와 같이, 굵은 글씨체의 섹션은 인증을 위한 메시지에 추가 사항을 제공한다. 굵은 글씨체의 섹션은 인증 벡터의 제2 세트를 나타낸다.

상기의 표 2에서, 제2 논스(nonce)는 제1 논스와 유사한 다양한 세트의 데이터의 구성이다. 이러한 제2 논스의 사용은 예시적인 목적을 위한 것에 불과하며, 중요한 것은, 시도 및 그 시도가 정당한 출처로부터 유래했는지를 검증하기 위한 추가적인 데이터를 제2 논스가 포함한다는 것이다는 것을 기술 분야에서 숙련된 자는 인식할 것이다.

P-CSCF(612)는 메시지(642)를 수신하고, 메시지(644)에 의해 나타내어지는 바와 같이, 공개 유저 ID 및 개인 유저 ID에 대한 시도 벡터를 UE(610)로 포워딩한다. 메시지(644)는 통상적으로 논스, 사용할 알고리즘, 제2 논스 및 제2 논스와 관련되는 제2 알고리즘을 포함할 것이다.

예를 들면, 메시지(644)에 대해 이루어질 수도 있는 추가 사항을 굵은 글씨체로 나타내는 표 3에 대한 참조가 이루어진다.

UE(610)가 두 개의 인증 시도 벡터를 포함하는 메시지(644)를 수신하는 경우, 시도 벡터의 제2 세트는, 다른 것들 중에서도, 피쳐 태그, XML 본문, AVP, 새로운 헤더 또는 www-authenticate-header로서 인코딩될 수도 있다.

UE(610)는 모바일 엘리먼트(ME) 및 UICC 둘 모두를 포함한다. ME는 제1 인증을 수행한다. UICC가 ME에 포함되면, 인증 벡터는 ME-UICC 인터페이스를 통해 전송될 수도 있다.

제1 인증 이후 또는 제1 인증 동안 ME는 제2 인증 시도를 실행할 것이고 제2 인증 시도는 이하에서 상세히 설명된다.

UE에서 이러한 이중 인증을 지원하기 위한 3GPP TS 24.229 명세에 대한 변경의 하나의 예가 이하의 부록 E와 관련하여 나타내어진다. 특히, UE가 시도 및 인증 파라미터를 추출하고 인증 파라미터의 유효성을 검사할 수 있다는 것을 나타내기 위해 부록 E의 예에서 3GPP TS 24.229의 섹션 5.1.1.5가 수정되었다. 인증 파라미터가 유효한 경우, UE는 MCPTT 애플리케이션 인증을 실행할 수도 있다.

일단 UE(610)가 제1 인증을 완료하면, UE는 두 개의 응답을 포함하는 인증 응답(650)을 전송할 수도 있다. 제2 시도 응답은, 다른 옵션 중에서도: 피쳐 태그; XML 본문; AVP; 제2 인증 헤더; 새로운 헤더 중 임의의 하나로서 인코딩될 수도 있거나; 또는 구분 문자(separator character) 예를 들면 XXXXX yyyyyy를 사용하여 현존하는 응답 값에 추가될 수도 있는데, 여기서 XXXXX는 제1 응답 값이고 YYYYY는 제2 응답 값이다. 이러한 응답 값은 길이가 임의의 수인 문자일 수 있다.

제2 응답에 포함된 것을 포함하는 제2 인증 헤더를 굵은 글씨체로 나타내는 아래의 표 4에 대한 참조가 이루어진다. 유저명은 제1 공개 유저 아이덴티티의 것이다.

응답을 위한 3GPP TS 24.229에 대한 변경의 예가 아래의 부록 F에서 굵은 글씨체로 제공된다.

부록 F에서 보여지는 바와 같이, 응답은, 부록 F에서 굵은 글씨체로 나타내어지는 바와 같이, 제1 응답에 추가되는 제2 계산된 응답을 구비한다.

메시지(650)는, 메시지(652)에 의해 도시되는 바와 같이, P-CSCF(612)에서 수신되고 S-CSCF(614)로 포워딩된다. 그 다음, S-CSCF(614)는, 블록(654)에 의해 도시되는 바와 같이, 예상 응답의 검사를 수행할 수도 있다. 논스 및 논스2 둘 모두가 도 6의 블록(641)에서 S-CSCF(614)에 저장되어 있는 것과 성공적으로 매치하면, UE(610)는 MCPTT 서비스에 대해 등록될 것이다. 제2 논스가 S-CSCF에 저장되어 있는 값과 매치하지 않으면, UE는 IMS 서비스에 대해서만 등록될 것이다. 제1 논스가 S-CSCF(614)에 저장되어 있는 것과 매치하지 않으면, UE(610)는 어떤 서비스에 대해서도 등록되지 않을 것이다.

옵션적인 실시형태에서, S-CSCF(614)가 공개 유저 아이덴티티에 대한 저장된 벡터를 아직 가지지 않는 경우, 메시지(660)가 HSS(618)로 전송될 수도 있다. 3GPP TS 29.228에 대한 제안된 변경을 굵은 글씨체로 나타내는 부록 G와 관련한 메시지(660)의 예가 도시된다.

HSS(618) 또는 다른 인증 기능, 예를 들면, PS-UDF는 메시지(660)를 수신하고 인증 벡터에 대한 요청이 공개 유저 아이덴티티 필드에 포함되는 공개 유저 아이덴티티에 대한 것이다는 것을 결정한다. 결정은 상기에서 식별되는 표시에 기초한다. 특히, 부록 H는 3GPP TS 29.228에서의 인증 요청 데이터를 제공하기 위한 잠재적인 변경을 굵은 글씨체로 나타낸다.

HSS(618)와 같은 인증 기능은 인증 벡터를 생성할 것이거나, 메시지를 포워딩하는 것에 의해 또는 대안적인 프로토콜을 사용하는 것에 의해 인증 벡터를 생성하는 다른 기능을 요청할 것이다. 그 다음, HSS(618)와 같은 인증 기능은 공개 유저 아이덴티티에 대한 인증 벡터를 전송한다. 3GPP TS 29.228에 대한 잠재적인 변경은 굵은 글씨체로 부록 I에 의해 나타내어진다.

부록 I에서 나타내어지는 바와 같이, 공개 유저 인증 벡터는 응답에서 제공된다. 따라서, 메시지(660)는 public-user-authentication을 식별하는 것을 통해 공개 유저 아이덴티티에 대한 인증 벡터의 사이트(site)를 포함하는 HSS를 갖는다. 그 다음 이 정보 엘리먼트 후속하는 데이터는, 제1 공개 유저 아이덴티티와 관련된다. 기술 분야에서 숙련된 자는, 부록 I의 마지막 네 개 행이 제2 IMS AKA 기능과 관련되는 데이터 항목이지만 그러나 인증 메커니즘은 임의의 것일 수 있다는 것을 인식할 것이다. 또, 하나의 양태는 SIP-authentication이 공개 유저 아이덴티티에 제시되는 시도를 포함한다는 것이다. 예를 들면, 제1 공개 유저 아이덴티티가 인증되고 있는 경우, 그 시도는 그 제1 공개 인증 유저 아이덴티티를 대상으로 한다. 또한, 메시지 내의 제1 공개 유저 아이덴티티 데이터 항목에는, 제1 공개 유저 아이덴티티가 인가된 엔티티에 의해 시도되고 있다는 것을 보장하기 위해 제1 공개 유저 아이덴티티가 사용할 수 있는 데이터 항목이 있다. 또한, 부록 I의 SIP authorization 필드는 시도의 예상 결과이다.

도 6을 다시 참조하면, UE(610)가 MCPTT 서비스에 대해 등록된 경우, S-CSCF(614)는 제2 인증이 인증 기능, 예를 들면, HSS, PS-UDF 등등에 대해 성공했다는 표시를 포함하는 메시지(662)를 전송할 수도 있다. 이 표시는, 다른 것들 중에서도, 피쳐 태그, XML 본문, AVP 또는 새 헤더로서 인코딩될 수도 있지만, 그러나 이들로 제한되는 것은 아니다.

업데이트될 수 있는 AVP의 한 예가 부록 J와 관련하여 나타내어져 있다. 부록 J에서 굵은 글씨체로 나타내어지는 바와 같이, 3GPP 29.229 명세 및 특히 섹션 6.3.15에 대한 변경이 제공된다.

새로운 AVP의 다른 예가 부록 K와 관련하여 나타내어져 있다. 부록 K에서, 굵은 글씨체로 나타내어지는 바와 같이, 등록되고 있는 애플리케이션은 3GPP TS 29.229의 섹션 6.1.3에서 식별된다.

UE가 공공 안전/MCPTT 서비스에 대해 등록되지 않았고 IMS 서비스에 대해서만 등록된 경우, 메시지(662)가 또한 사용될 수도 있다. 이 경우, S-CSCF(614)는 3GPP TS 29.228을 따르는 정보를 포함하는 메시지(662)를 전송할 수도 있다.

도 6에서, 일단 성공이 S-CSCF(614)로 확인되면, 성공 메시지(670)가 UE(610)로 제공될 수도 있다.

상기에서, UE가 제2 인증 시도에 대한 데이터를 수신하는 경우, UE는 응답을 네트워크로 제공할 필요가 있다. 이것은 ME 또는 UICC 상의 애플리케이션 중 어느 하나에서 수행될 수도 있다. 결과는 자동화된 프로세스 또는 수동 프로세스 중 어느 하나에 의해 생성될 수도 있다. 자동화된 응답은 외부 인증 토큰을 활용할 수 있을 것이다. 외부 인증 토큰은 ME의 카드 판독기에서 판독될 수 있을 것이고, ME는, 다른 것들 중에서도, 예를 들면, Bluetooth™, 근거리 통신(near field communications; NFC), 무선 주파수 식별자(radio frequency identifier; RFID)를 사용하여, 무선 메커니즘을 통해 인증 토큰과 통신할 수 있을 것이다. 기본적으로 ME는 외부 노드로 메시지를 전송하고 외부 노드는 인증 자격 증명(authentication credential)을 가지고 ME에 응답한다.

수동 인증에서, ME는, 청각적, 시각적 또는 다른 메시지(이들로 제한되는 것은 아님) 중 임의의 하나일 수 있는 표시를 제공한다. ME는, 다른 옵션 중에서도, 키보드, 스크린, ME의 움직임, 지문 판독기, 망막 스캐너, NFC, 스와이프 카 리더(swipe car reader)를 통해 데이터를 수신한다. 그 다음, 수신되는 데이터는 시도 응답으로서 사용되며, 예를 들면, MIME 타입 메시지에서 인코딩된다.

따라서, 상기로부터, IMS 등록 메시지는 새로운 표시를 포함하도록 향상된다. 새로운 표시는, IMS 개인 아이덴티티만을 인증하는 대신, IMS 공개 유저 아이덴티티 인증도 또한 수행되어야 한다는 것을 네트워크에 시그널링한다. 새로운 표시는, 두 세트의 인증 벡터가 필요하다는 것을 나타내기 위해, 인증 데이터베이스로 또한 전송된다.

네트워크는, 새로운 표시의 수신시, 보안 관련성이 IMPI에 대해 이미 존재하는 경우, IMS 공개 유저 아이덴티티와 관련되는 하나 또는 단일 세트의 인증 벡터 대신, 두 세트의 인증 벡터로 응답할 것이다.

디바이스는 두 세트의 인증 벡터를 수신할 수 있어야 하고, IMS 개인 유저 아이덴티티 세트의 성공적인 확인 시, 그 다음, 디바이스는 인증 벡터의 제2 세트를 확인 및 실행할 수도 있다. 인증 벡터의 제2 세트는, 다른 것들 중에서도, 지문, ID 카드로부터의 QR 코드, 망막 스캔과 같은 생체 인식 데이터와 같은 유저의 몇몇 다른 고유한 식별 정보 또는 패스워드일 수 있을 것이다.

인증 벡터의 제1 세트에 대한 디바이스로부터의 성공적인 응답은, 디바이스가 예컨대 구성 정보를 수신하기 위해 IMS 네트워크에서 제한된 기능을 수행하는 것을 허용할 수도 있다.

제2 인증 벡터에 대한 성공적인 응답은 디바이스가 특정한 유저에 의해 사용되는 것을 허용한다. 정확한 기능성은, 성공적으로 인증된 그 공개 유저 아이덴티티와 관련되는 서비스 설명 특성 및 필터 기준에 의해 좌우된다.

대역 내 제2 공개 유저 Id 및 인증 응답

본 개시의 또 다른 실시형태에 따르면, IMS 등록은, 제1 공개 유저 아이덴티티 및 제1 개인 유저 아이덴티티를 포함하여, 정상적으로 수행된다. 그러나, 디바이스가 인증 시도에 응답하는 경우, 그것은 또한, 초기 IMS 등록에서 전송되었던 제1 공개 유저 아이덴티티 대신 제2 공개 유저 아이덴티티를 포함하는 새로운 추가적인 정보를 시도 응답에서 포함할 수도 있다.

몇몇 실시형태에서, UE는, 공개 유저 아이덴티티에 대한 시도 벡터를 알고 있는 경우, 그 제2 공개 유저 아이덴티티에 대한 시도 응답을 또한 제공할 수도 있다. 특히, 제1 아이덴티티에 대해 제공되었던 것과 동일한 시도 벡터가 제2 공개 아이덴티티에 대해 활용되는 경우, 시도 응답은 상이할 것이지만 그러나 네트워크에서 도출 가능할 것이다.

하나의 실시형태에서, 제2 공개 유저 아이덴티티에 대한 시도 응답은, 다른 것들 중에서도, 지문, ID 카드로부터의 QR 코드 또는 망막 스캔과 같은 다른 생체 인식 데이터와 같은 유저의 몇몇 다른 고유한 식별 정보 또는 패스워드일 수 있을 것이다. 몇몇 경우에, 제2 공개 유저 아이덴티티는 평문으로 전송될 수도 있거나 또는 디바이스에 의해 암호화되거나 또는 불명료하게 될 수도 있으며, 따라서 HSS와 같은 네트워크 엔티티에 의해 암호 해제되어야 하거나 또는 명확하게 되어야 한다. 제2 공개 유저 아이덴티티가 암호화된 경우, 이러한 암호화를 나타내기 위해 IMS 등록 동안 식별자가 제공되는 것을 필요로 할 수도 있다. 암호화는 디바이스 및 HSS, PS-UDF 또는 공공 안전 AAA 서버에 알려지는 공개 키에 기초할 수 있다.

제1 공개 유저 아이덴티티와 매치하지 않는 제2 공개 유저 아이덴티티를 네트워크가 수신하는 경우, S-CSCF는 제2 공개 유저 아이덴티티에 대한 인증 벡터를 획득할 필요가 있을 수도 있다. 제2 공개 유저 아이덴티티에 대한 시도 응답이 제2 공개 유저 아이덴티티에 대해 정확하면, 네트워크는 디바이스에 대해 사용될 것으로서 제2 유저 아이덴티티로 응답한다. 그러나, 시도 응답이 제2 공개 유저 아이덴티티에 대해 올바르지 않은 경우, 네트워크는 디바이스에 의해 사용될 것으로서 제1 공개 아이덴티티로 응답한다.

이제 도 7에 대한 참조가 이루어진다. 도 7에서, UE(710)는 P-CSCF(712)와 통신한다. 네트워크의 다른 엘리먼트는 S-CSCF(714), AAA(716), HSS(718), 및 PS-UDF(720)를 포함한다. 다시, 기술 분야에서 숙련된 자는, 이들이 논리적인 기능이며 함께 결합될 수 있을 것이다는 것을 인식할 것이다.

도 7의 실시형태에서, UE(710)는 IMS 네트워크, 예를 들면, 공공 안전 IMS 네트워크에 등록하기를 원한다. 이 경우, UE(710)는, 제1 공개 유저 아이덴티티 및 제1 개인 아이덴티티를 제공하는 P-CSCF(712)로 메시지(730)를 제공한다. P-CSCF(712)는 메시지(730)를 수신하고 메시지(732)에 의해 나타내어지는 S-CSCF(714)로 메시지를 포워딩하는데, 그 메시지는 제1 유저 아이덴티티 및 제1 개인 아이덴티티를 또 제공한다.

그 다음, S-CSCF(714)는 HSS(718)로 인증 요청(718)을 제공하고, HSS(714)는 개인 식별자에 대한 시도 벡터를 획득할 수도 있고 그들을 메시지(740)에서 S-CSCF(734)로 제공할 수도 있다. 시도 벡터는, 몇몇 경우에, 화살표(741)에 의해 나타내어지는 바와 같이, P-UDF(720)로부터 획득될 수도 있다.

그 다음, 시도 벡터는 메시지(742)에서 S-CSCF(714)로부터 P-CSCF(712)로 전달되고 그 다음 메시지(744)에서 UE(710)로 전달된다.

UE(710)는, 메시지(744)의 인증 시도의 수신시, P-CSCF(712)로 메시지(750)를 다시 제공한다. UE가 MCPTT 서비스를 지원하면, 메시지는, 제1 개인 유저 아이덴티티, 제2 공개 유저 아이덴티티 및 제2 공개 유저 아이덴티티와 관련되는 자격 증명으로 구성되는, 그러나 이들로 제한되지는 않는 정보를 포함할 수도 있다. 이러한 경우, 제2 공개 유저 아이덴티티 및/또는 자격 증명이 암호화되었다는 옵션적 표시가 또한 제공될 수도 있다.

메시지(750) 내의 정보는 새로운 보안 방법을 식별하는 새로운 mechanism-name(메커니즘 명)를 포함하도록 인코딩될 수도 있다. 예를 들면, 이것은 security-client(보안-클라이언트) 헤더 필드에서 IPSEC-MCPTT 및/또는 MEC-PARAMETERS일 수도 있다. 예를 들면, IETF RFC 3329는 이러한 인코딩을 설명한다. 또한, 인코딩은 IETF RFC 3310에서 설명되는 이러한 새로운 AKA 버전과 같은 인가 헤더 필드 내의 새로운 파라미터일 수도 있다. 또한, 정보는, 지원되는 또는 요구되는 헤더 필드에서의 옵션 태그, 피쳐 태그, URI 파라미터, XML 본문, 새로운 헤더로서 인코딩될 수도 있거나 또는 제1 공개 아이덴티티 또는 제1 개인 유저 아이덴티티 중 어느 하나에 추가될 수도 있다.

예를 들면, 3GPP TS 24.229, 및 특히 이 명세의 섹션 5.1.1.5에 대한 잠재적 변경을 나타내는 부록 L에 대한 참조가 이루어진다. 부록 L의 굵은 글씨체 섹션은 추가된 섹션이다.

또한, 표 5는 메시지(750)를 제공하기 위한 메시징의 두 가지 구현에서의 잠재적 변경을 나타낸다.

P-CSCF(712)는 메시지(750)를 수신하고 S-CSCF(714)로 메시지(752)를 포워딩한다. 메시지(752)는 메시지(750)와 동일한 정보를 포함한다.

도 7의 예에서 그리고 표 5에 의해 도시되는 바와 같이, S-CSCF는, 수신되는 정보가 메시지(732)에서 제공된 그리고 후속하여 저장된 정보와 매치하지 않는다는 것을 알게 된다. 이러한 정보는, 알고리즘, 논스 또는 유저명 헤더에서 수신되는 공개 유저 아이덴티티를 포함할 수도 있다. 그 다음, S-CSCF는, 블록(754)에 의해 나타내어지는, 공개 아이덴티티에 대한 벡터를 아직 저장하지 않은 경우, HSS(718) 또는 P-UDF(720) 또는 AAA(716)와 같은 인증 기능에 인증 벡터를 요청할 것이다.

벡터의 획득은 메시지(756)에 의해 나타내어지며, 정보가 제2 유저 아이덴티티를 포함한다는 것을 제외하고는 상기의 도 6으로부터의 메시지(660)와 동일하다.

도 7에서 보여지는 바와 같이, 메시지(752)는 제2 공개 유저 아이덴티티의 성공적인 인증을 허용하기 위한 파라미터 및 인증 응답을 제공한다. 따라서, 일단 메시지(756)로부터 인증이 검사되고, 그 다음, 인증이 성공적이면, 메시지(760)가 S-CSCF(714)와 HSS(718) 사이에서 제공된다.

또한, 성공 메시지(762)가 UE(710)로 제공될 수도 있고, 이러한 메시지는 도 6의 메시지(670)로서 제공되는 것과 동일할 수도 있다.

반대로, 인증이 제2 공개 유저 식별자에 대해 성공적이지 않은 경우, 메시지(770)는, 제2 공개 유저 식별자가 아닌, 그러나 오직 제1 공개 유저 식별자에 대해서만 성공을 포함한다. 그러므로, 메시지(772)는 제1 공개 유저 식별자를 활용하는 것을 제외하면 성공을 제공한다.

그러므로, 상기의 것은 ISM에 대한 대역 내 인증 메커니즘을 사용하여 이러한 제2 공개 유저 아이덴티티의 인증 및 공개 유저 아이덴티티를 불명확하게 하는 것을 허용한다.

공개 유저 Id에 기초한 대역 내 키잉

또 다른 실시형태에서, UE로부터의 IMS 등록은, 인증이 MCPTT 또는 공개 유저 식별에 대해 또한 필요로 된다는 새로운 표시를 가지고 정상적으로 수행된다. 이 표시는 S-CSCF와 HSS/PS-UDF로 그리고 이들로부터 전송된다.

키 도출 프로세스 및 시도 응답 프로세스는, 시스템에 액세스하기 위해 사용되고 있는 공개 유저 아이덴티티와 관련되는 개인 식별 번호(personal identification number; PIN)를 포함하도록 향상된다. PIN은 인증 벡터를 생성하기 위해 IMS AKA 알고리즘에 결합된다.

용어 PIN은, 본원에서 사용될 때, 일반적인 양식으로 사용되고 있으며, 다른 옵션 중에서도, 알파벳 숫자 문자, 그림, 홍채 스캔, 생체 인식 데이터, 지문, 음성 프린트, 키 카드, 바코드, Qcode, 상기의 것 중 일부 또는 전체의 조합을 포함할 수 있지만, 그러나 이들로 제한되는 것은 아니다.

이제, 이러한 키잉에 대한 정보 흐름을 도시하는 도 8에 대한 참조가 이루어진다. 특히, UE(810)는 P-CSCF(812)와 통신하여 S-CSCF(814), AAA(816) 및 HSS(818)와 통신한다. 몇몇 실시형태에서, HSS(818)는 또한 PS-UDF와 통신할 수도 있다.

도 8에서 보여지는 바와 같이, UE(810)는 공개 유저 식별자 및 개인 유저 식별자를 포함하는 메시지(830)를 전송한다. 그 다음, 이 메시지는, 메시지(832)에 의해 나타내어지는 바와 같이, P-CSCF(812)로부터 S-CSCF(814)로 포워딩된다. S-CSCF(814)는, 메시지(832)의 수신시, 메시지(834)에 의해 나타내어지는 바와 같이, AAA(816)로 인증 요청을 제공할 수도 있다. AAA(816)는 메시지(836)에서 HSS(818)로 인증 요청을 제공한다.

시도 벡터가 생성되고 HSS(818)는 개인 ID에 대한 시도 벡터를 메시지(840)에서 AAA(816)로 제공한다. 그 다음, 시도 벡터는 메시지(842)에서 AAA(816)로부터 S-CSCF(814)로 제공된다.

그 다음, 시도 벡터는 메시지(844)에서 S-CSCF(814)로부터 P-CSCF(812)로 포워딩되고, 최종적으로, 메시지(846)에서 UE(810)로 제공된다. UE는, 하기에서 설명되는 바와 같이, 인증을 수행하고 인증 응답(850)을 P-CSCF(812)로 다시 제공한다. 그 다음, 인증 응답은 메시지(852)에 의해 나타내어지는 바와 같이 S-CSCF(814)로 포워딩된다.

S-CSCF(814)가 시도 벡터 응답을 포함하거나 또는 시도 벡터 응답을 저장한 경우, 블록(854)으로서 나타내어지는 바와 같이, 검사가 이루어질 수도 있다. 그렇지 않으면, 메시지(860)에 의해 나타내어지는 바와 같이, S-CSCF(814)와 HSS(818) 사이에서 응답 요청이 이루어질 수도 있다.

인증이 성공적이면, 메시지(862)는 결정을 위해 사용되고 메시지(864)는 UE(810)로 다시 제공된다.

따라서, 상기에서, UE는 MCPTT 애플리케이션에 대해 인증이 수행된다는 표시를 포함하는 메시지에 대한 등록을 네트워크로 전송한다. 이러한 표시는: Security-Client 헤더 필드에서 ipsec-MCPTT 및/또는 mech-parameters와 같은 새로운 보안 방법을 식별하는 새로운 mechanism-name; Authorization(인증) 헤더 필드에서의 새로운 파라미터; Supported 또는 Require 헤더 필드의 옵션 태그; 피쳐 태그; URI 파라미터; XML 본문; 새로운 헤더 중 임의의 하나로서 인코딩될 수도 있거나; 또는 제1 공개 유저 아이덴티티 또는 제1 개인 유저 아이덴티티 중 어느 하나에 추가될 수도 있다. 아래의 표 6에서 인코딩되는 예는, 새로운 Security-Client가 "ipsec-3GPP-MCPTT"로 명명된 변경을 굵은 글씨체로 나타낸다.

또한, UE에서, 메시지(846)의 수신시, UE는 "from" 헤더 내의 IMS 등록 메시지에서 전송된 공개 유저 아이덴티티와 관련되는 시도 응답을 획득할 수도 있다. 그 다음, 공개 유저 ID PIN으로 칭해지는 시도 응답은, ME 또는 UICC 중 어느 하나에서, 시도 응답을 수정하는 기능 안으로 전송될 수도 있고, 그 다음 ME로부터 응답은 ME-UICC를 통해 UICC로 전송될 수도 있다. UICC는 공개 유저 ID PIN을 수신할 수도 있고 그것을 사용하여 키 및 시도 응답을 생성할 수도 있다.

3GPP TS 31.103에 대한 잠재적 변경의 예가 아래의 부록 M에서 굵은 글씨체로 나타내어져 있다.

키잉의 경우, S-CSCF(814)는 인증 벡터를 획득하기 위해 메시지를 인증 기능으로 전송하는 것에 의해 향상될 수도 있다. 메시지는, 그것이 MCPTT 서비스에 대한 것임을 나타내는 표시를 포함할 수도 있고 피쳐 태그, XML 본문, 새로운 AVP, 새로운 코드 포인트와의 현존하는 AVP의 사용, 또는 새로운 헤더로서 인코딩될 수도 있다.

인증 기능은 HSS, AAA, PS-UDF 또는 이 세 가지의 몇몇 조합일 수 있을 것이다.

인증 요청은 하기의 부록 N에서 설명되는 형태일 수도 있다.

부록 N에서 보여지는 바와 같이, 인증 요청은, 다른 정보 중에서도, 공개 유저 아이덴티티, 개인 유저 아이덴티티, 인증 항목의 수, 인증 데이터, S-CSCF 이름 및 라우팅 정보를 포함할 수도 있다.

등록되어 있는 공개 유저 아이덴티티에 대한 인증 벡터를 요청하는 메시지의 수신시, 인증 기능은 공개 아이덴티티 AVP에서 공개 아이덴티티와 관련되는 개인 유저 ID PIN을 획득한다. 메시지(846)에서 UE에 의해 전송되는 표시를 사용하여, 인증 기능은 인증 벡터를 생성 또는 요청하고, 벡터를 생성하기 위해 사용되는 새로운 메커니즘의 표시 내에서 응답을 되전송한다. 이러한 메시지는, 다른 옵션 중에서도, 예를 들면, 피쳐 태그, XML 본문, 새로운 AVP, 새로운 코드 포인트를 사용하는 현존하는 AVP 또는 새로운 헤더로서 인코딩될 수도 있다.

이제, 가능한 키 생성 구현을 나타내는 도 9에 대한 참조가 이루어진다.

특히, 키 생성은, 시퀀스 번호(sequence number; SQN) 블록(812)의 생성 및 난수(RAND) 블록(914)의 생성을 포함하는 HSS 프로세스(910)를 포함한다. 이들은, F1 내지 F5로 표시되며 참조 번호(920, 922, 924, 926 및 928)로 도시되는 다양한 기능 블록으로 공급된다.

도 9의 실시형태에서, 블록 F1(920)은 SQN, 인증 관리 필드(authentication management field; AMF) 및 RAND의 입력을 포함하고, 키 값(K)을 더 포함한다. 인증 토큰(AUTN)은 SQN

AK || AMF || MAC로 구성된다.

또한, 블록(F2 내지 F5)은 입력으로서 RAND와 함께 키 값(K)을 포함한다.

도 9의 실시형태에서, 블록(930)에 의해 도시되는 바와 같은 새로운 기능(F6)이 블록(920, 922, 924, 926 및 928)에 대한 입력으로서 또한 제공된다. 블록(930)은 공개 유저 ID PIN을 입력으로 취한다. PIN은 PS-UDF(제2 인증 기능)로부터 획득되었을 수도 있다.

UE 측(935)에서, 기능(f6)은 블록(840)에 의해 도시되고 공개 유저 ID PIN을 입력으로서 갖는다. 블록(940)으로부터의 출력은 기능 블록 F1(942)뿐만 아니라, 블록(944), 블록(946), 블록(948)으로 제공된다. 또한, 이들 블록뿐만 아니라 블록(950)으로 암호화 키(K)가 제공된다. RAND가 또한 블록(950)으로 제공되고 SQN은 블록(954)에서 도출된다.

그 다음, UE는, MAC=XMAC이다는 것을 검증할 수 있고 SQN이 정확한 범위 내에 있다는 것을 검증할 수 있다. 따라서, 도 9는 공개 유저 ID PIN이 F1 내지 F5 중 일부와 또는 전부와 결합되는 키 생성 프로세스를 도시한다.

공개 유저 ID PIN을 숨기기 위해, PIN은 기능 F6을 통해 또한 전송될 수도 있다.

공개 유저 ID에 기초한 대역 내 키잉, 대안적인 실시형태

대안적인 실시형태에서, IMS AKA 알고리즘의 출력은, 인증 벡터의 세트를 생성하기 위해, 이제 공개 유저 ID 키와 결합된다. 특히, 솔루션은 상기의 것과 유사하지만, 그러나 전통적으로 공개 오퍼레이터 캐리어(public operator carrier)인 HSS의 오퍼레이터는 공개 유저 ID PIN의 가시성을 얻지 않는다는 이점을 갖는다. 이것은, HSS 대신 AAA/PS-UDF에서 PIN을 개인 유저 ID 인증 벡터와 결합하는 것에 의해 달성된다. 이 실시형태와 상기의 실시형태 사이의 주요 차이점은 키가 생성되는 방식인데, 이것은 도 10 및 도 11에서 도시된다.

특히, 이제, HSS 및 AAA/PS-UDF에서의 인증 벡터 생성의 개략도를 도시하는 도 10에 대한 참조가 이루어진다. HSS, AAA 및 PS-UDF는 단일의 노드 또는 다수의 노드일 수 있을 것이다.

HSS 프로세스 블록(1010)은 AAA/PS-UDF 프로세스 블록(1020)과 통신한다. 따라서, 도 10의 실시형태에 따라, SQN 블록(1012), 및 RAND 블록(1014)을 비롯한, 도 9의 것과 유사한 키 생성 블록이 제공된다. 이들 블록으로부터의 출력은 기능 블록(1030, 1032, 1034, 1036 및 1038)으로 입력된다. 그러나, 블록(1030, 1032, 1034, 1036 및 1038)으로부터의 출력은 AAA/PS-UDF 프로세스 공개 유저 ID PIN은 HSS에서 결코 사용되지 않는다. 대신, 공개 유저 ID PIN은 블록(1050)에 의해 도시되는 바와 같은 블록(F6)에 대해 제공되고 블록(1060, 1062, 1064, 1066 및 1068)에 대한 출력을 생성할 수 있다.

도 11은 UE에서의 인증 벡터 생성의 개략도를 도시한다. 특히, 파라미터 키는 기능 블록(1110, 1112, 1114, 1116 및 1118)에 대한 입력으로서 사용될 수도 있다. 또한, SQN은 블록(1120)에서 생성될 수 있다.

공개 유저 ID(PIN)는 기능 블록(1130)에서 제공되고 제공될 수도 있다. 블록(1110, 1112, 1114 및 1116)의 출력과 함께 블록(1140, 1142, 1144 및 1146)으로.

따라서, 공개 유저 아이덴티티 PIN의 사용은 캐리어로부터 비밀로 유지될 수도 있다.

도 9, 도 10 및 도 11의 솔루션이 대역 내 솔루션에 대해 상기에서 제공되지만, 그들은 하기에 설명되는 대역 외 솔루션 중 일부와 함께 동등하게 활용될 수도 있다.

대역 외 시그널링

또 다른 실시형태에서, 대역 외 시그널링은 IMS 개별 가입자를 인증하기 위해 사용될 수도 있다. 대역 외 시그널링은, IMS UE를 인증하기 위해 현재 사용되는 시그널링 이외의 새로운 시그널링 경로가 사용된다는 것을 의미한다. 대역 외 시그널링 메커니즘은 IMS 등록 이전 또는 이후에 사용할 수 있다.

제1 실시형태에서, 디바이스는 네트워크에 제1 인증 절차를 시그널링할 수도 있다. 이것은, 예를 들면, 인증이 요구되는 EAP 메시지일 수도 있다. 메시지는, 인증이 요구되는 공개 유저 아이덴티티, 및 옵션적으로, 공개 유저 식별자가 관련되는 개인 유저 식별자를 포함할 수도 있다. 네트워크는, 사용되고 있는 EAP 인증 메커니즘에 적절한 인증 시도로 응답할 수도 있다.

공개 유저 아이덴티티의 성공적인 인증시, UE는 네트워크에 대한 IMS 등록 메시지에서 동일한 공개 유저 아이덴티티뿐만 아니라 (어쨌든 제1 인증 절차가 제공되었다면) 제1 인증 절차에서 사용되는 개인 식별자를 제공한다. 이것은 이하의 설명에서 제2 인증 절차로 알려진다.

그 다음, 네트워크는 공개 유저 아이덴티티가 성공적으로 인증된 것을 검사할 것이고, 등록에 응답하여 공개 유저 아이덴티티를 다시 시그널링할 것이다. 공개 유저 아이덴티티의 인증이 실패한 경우, 네트워크는, 예를 들면, 구성 목적을 위해 사용되는 다른 기본 공개 유저 아이덴티티로 응답할 수도 있거나 또는 인증 문제를 해결하기 위해 직원에게 연락하는 제한된 기능을 유저에게 허용할 수도 있다. 대안적으로, 네트워크는 인증 실패 표시로 응답할 수도 있다.

제2 인증 메커니즘에 대한 키는, 예를 들면, 도 9, 도 10 및 도 11과 관련하여 상기에서 설명되는 기술을 활용하여 생성될 수도 있다.

따라서, 본 개시의 하나의 실시형태에 따르면, 대역 외 솔루션은 공개 및 개인 유저 ID를 함께 연결한다. 이것은, 공개 유저 ID가 처음 인증된 이후 공개 유저 ID만이 특정한 개인 유저 ID와 함께 사용될 수 있다는 것을 의미한다.

이제 도 12에 대한 참조가 이루어진다. 도 12에서, UE(1210)는 P-CSCF(1212)와 통신한다. 또한, 다양한 엘리먼트는 S-CSCF(1214), AAA(1216) 및 HSS(1218)를 포함할 수도 있다. 몇몇 실시형태에서, PS-UDF(도시되지 않음)가 또한 제공될 수도 있고 AAA(1216) 및/또는 HSS(1218)와 함께 병치될 수 있을 것이다.

도 12의 실시형태에서, 제1 인증 메커니즘(1220)이 먼저 수행되는 것으로 도시된다. 그 다음, 제2 인증 메커니즘(1222)이 수행되는 것으로 도시된다. 그러나, 다른 실시형태에서, 제2 인증 메커니즘(1222)이 먼저 동일하게 수행될 수 있을 것이고, 제1 인증 메커니즘(1220)이 후속하여 수행될 수 있을 것이다. 이 경우, 하나의 실시형태에서, 제1 인증 메커니즘에서의 공개 유저 아이덴티티 인증에 대한 응답은 이미 제2 인증을 위해 UE 및 HSS에 이용 가능할 필요가 있을 수도 있다.

제1 인증 메커니즘(1220)은 다양한 메시지를 포함한다. UE(1210)로부터 AAA(1216)로 전송되는 제1 메시지(1230)는 통상적으로 적어도 공개 유저 아이덴티티 및 옵션적으로 개인 유저 아이덴티티를 포함한다.

AAA(1216)는 메시지(1230)를 수신한다. 메시지(1230)가 두 개의 아이덴티티를 포함하지 않으면, 네트워크는 메시지(1232)를 다시 UE(1210)에 전송하여 공개 유저 아이덴티티 및 개인 유저 아이덴티티 둘 모두를 요청하거나, 또는, 다른 실시형태에서는, 공개 유저 아이덴티티만을 요청할 수도 있다.

메시지(1232)의 요청을 허용하기 위한 3GPP TS 24.302 명세에 대한 변경의 하나의 예가 부록 O에서 제공된다. 부록 O에서 보여지는 바와 같이, 다양한 아이덴티티에 대한 요청을 다시 UE에게 나타내기 위해 옥텟(octet)이 사용될 수도 있다.

도 12를 다시 참조하면, 일단 UE가 메시지(1232)를 수신하면, UE는 하나 또는 둘 모두의 아이덴티티를 전송할지 또는 전송하지 않을지의 여부를 결정한다. 단지 하나의 아이덴티티만이 되전송되면, EAP-AKA는 이 하나의 아이덴티티의 전송을 이미 지원한다.

하나의 실시형태에서, UE는 새로운 인코딩 스킴을 사용하여 제2 아이덴티티를 추가적으로 전송할 것이다. 예를 들면, 부록 P를 참조하면, 대안적인 인코딩 스킴이 제공되는 3GPP TS 24.302에 대한 가능한 변경이 제공된다.

그 다음, UE는 메시지(1234)를 네트워크로, 예를 들면, AAA(1216)로 되전송할 것이다. 그러나, 다른 실시형태에서, 수신 측은 PS-UDF 또는 MCPTT AS 또는 HSS(1218)일 수도 있다.

일단 네트워크가 메시지(1234)를 수신하면, 그 다음, 도 12의 메시지(1240)에 의해 나타내어지는 바와 같이, 개인 유저 ID 및 공개 유저 ID 둘 모두를 포함하는 메시지를 HSS(1218)로 제공할 수도 있다. HSS(1218)는 메시지(1240)를 수신하고 공개 유저 ID에 대한 인증 벡터를 생성하고 이들을 메시지(1242)에서 AAA(1216)로 다시 제공한다. 이전의 대역 내 실시형태 및 다른 대역 외 실시형태에서 설명되는 바와 같이, HSS는 PS-UDF와 통신하여 인증 벡터를 획득할 수 있다. 또한, HSS는 PS-UDF일 수도 있다.

AAA(1216)는 메시지(1242)를 수신하고 시도 벡터를 메시지(1244)에서 UE(1210)로 포워딩한다.

UE(1210)는 메시지(1244)를 수신하고, 메시지(1250)에서 AAA(1216)로 다시 제공되는 인증 응답을 생성한다.

AAA(1216)는 인증 응답을 수신하고 그것을 메시지(1252)에서 HSS(1218)로 포워딩하는 데, HSS(1218)는, 그 다음, 인증 응답을 검사하고 결과를 메시지(1254)에서 다시 제공한다.

메시지(1254)가 성공 메시지이면, 성공은 메시지(1256)에서 UE(1210)로 포워딩될 수도 있다.

이 시점에서, 제1 인증 메커니즘(1220)은 성공적이다. 이 경우, UE 및 HSS 둘 모두는 공개 유저 ID를, UE(1210)에 대한 블록(1260) 및 HSS(1218)에 대한 블록(1262)에 의해 도시되는 바와 같이, 개인 유저 ID에 대해 사용할 공개 유저 ID로서 마킹한다.

그 다음, 도 12의 프로세스는 제2 인증 메커니즘(1222)으로 진행한다. UE 관점에서, UE는 3GPP TS 24.229에 따라 IMS 등록을 수행하고, 제1 인증 메커니즘(1220)에서 결정되는 공개 유저 ID 및 개인 유저 ID를 포함한다.

UE가 네트워크로부터 401k 시도를 수신하면, UE는, 옵션적으로, SIP 레지스터에서 네트워크로 주어지는 응답을 생성함에 있어서 제1 인증 메커니즘(1220)에서 공개 인증을 위해 사용한 응답을 옵션적으로 사용한다. 예를 들면, 응답이 공개 유저 식별자 PIN과 동일한 상기의 도 9, 도 10 및 도 11의 메커니즘이 활용될 수도 있다.

HSS(1218) 관점으로부터, HSS는 인증 벡터를 제공하라는 요청을 수신한다. 이들 인증 벡터는 도 9, 도 10 및 도 11과 관련하여 상기에서 설명되는 바와 같이 생성될 수도 있는데, 여기서 제1 인증 단계에서의 공개 인증에 대한 응답은 공개 유저 ID PIN과 동일하다. 그 다음, HSS는 공개 유저 ID를 개인 유저 ID에 결부시킨다. 예를 들면, 도 13과 관련하여 핵심 개요가 제공된다.

도 13에서, UE(1310) 및 HSS(1312)는 인증 절차를 진행한다. 제1 인증 프로세스(1320)는 UE 및 HSS 둘 모두로부터의 입력으로서 공개 ID(1322)를 포함한다.

UE(1310) 및 HSS(1312) 각각에서의 제1 인증 프로세스의 결과는 제2 인증 프로세스(1330)로 그리고 특히 UE의 경우 IMS AKA(1332)로 HSS의 경우 IMS AKA(1334)로 제공된다. 다른 방식으로 설명하면, 제1 인증 프로세스의 일부로서, HSS(1312)는 시도를 UE(1310)로 전송한다. 동시에 HSS는 UE로부터 얻을 것으로 예상되는 응답을 계산한다. UE는 시도에 대해 응답으로 응답한다. UE에 의해 생성되는 응답은 IMS AKA(1332)로의 입력으로서 사용되고, HSS에 의해 생성되는 응답은 IMS AKA(1334)로의 입력으로서 사용된다.

IMS AKA(1332)는 UE에서의 개인 식별자에 대한 입력을 포함한다. 마찬가지로, IMS AKA(1334)는 HSS에서의 개인 식별자에 대한 입력을 포함한다.

제2 인증 프로세스의 결과(XRES)는, 성공 또는 실패를 결정하는 S-CSCF(1340)로 제공된다.

따라서, 상기의 것은, 공개 유저 ID가 IMS 등록 이전에 개인 ID에 결부되는 대역 외 솔루션을 제공한다. 그러나, 상기에서 나타내어지는 바와 같이, 대역 외 인증은 몇몇 실시형태에서 IMS 등록 이후에도 또한 발생할 수도 있다.

제2 대역 외 실시형태

대안적인 실시형태에서, 제1 대역 외 실시형태에 관련하여 상기에서 제공되는 솔루션이 활용될 수도 있다. 그러나, 제1 공공 안전 서비스 공급자의 유저가 제2 공공 안전 서비스 공급자에게 도움을 제공하고 있고 제2 공공 안전 유저 공급자의 MCPTT 서비스를 사용할 필요가 있는 상황에서, 상기의 도 12의 솔루션에 대한 향상이 이루어질 수도 있다.

예를 들면, 제1 경찰력의 제1 경찰관이 제2 경찰력을 보조하고 있고 제2 경찰력의 MCPTT 서비스를 사용할 필요가 있는 경우, 도 14와 관련하여 하기에 설명되는 실시형태가 활용될 수도 있다. 도 14는 제1 공공 안전 서비스 공급자가 제2 공공 안전 서비스 공급자와 동일한 경우에 동일하게 사용될 수도 있다.

제2 실시형태에서, 디바이스는 제2 인증 메커니즘을 수행한다. 예를 들면, 이러한 인증 메커니즘은 제2 공개 유저 아이덴티티 및 개인 유저 아이덴티티를 갖는 IMS 등록일 수도 있다.

그 다음, MCPTT AS에서 IMS 제3자 등록이 수행된다. MCPTT AS는 향상된 Sh 인터페이스를 사용하며, 유저 아이덴티티가 이제 MCPTT 서비스에 성공적으로 등록되었다는 표시를 전송한다.

그 다음, 디바이스는 제1 IMS 등록의 일부로서 생성되었던 또는 EAP-TLS와 같은 제2 인증 메커니즘의 일부일 수 있는 보안 터널을 통해 제1 공개 유저 아이덴티티를 사용하여 제2 인증 메커니즘을 수행할 수도 있다.

제1 공개 유저 아이덴티티는 UE가 통신을 위해 사용하기를 원하는 공개 유저 아이덴티티이다. 성공적인 인증시, 향상된 Sh 인터페이스를 통해 PS-UDF는, 제1 공개 유저 아이덴티티 및 개인 유저 아이덴티티가 MCPTT 서비스에 대해 성공적으로 인증되었다는 것을 시그널링한다.

제2 인증의 성공시, 하나의 실시형태에서, 디바이스는 제1 공개 유저 아이덴티티를 사용하여 제2 IMS 등록을 수행한다. 대안적인 실시형태에서, 네트워크가 성공적인 인증을 디바이스에 다시 나타낼 때, HSS와 같은 네트워크 엘리먼트는 P-CSCF를 제1 공개 유저 아이덴티티를 사용하여 업데이트한다. 이것은, PCC를 사용하는 것에 의해 P-CSCF의 공개 유저 아이덴티티를, HSS-PCC-P-CSCF를 통해, 수정하는 것일 수 있다. 대안적으로 이것은 HSS-S-CSCF를 통해 사용될 수도 있는데, 여기서 S-CSCF의 프로파일에서 공개 유저 아이덴티티를 변경하는 Cx 인터페이스 커맨드 또는 메시지는, 등록 이벤트 패키지가 P-CSCF로 전송되어 개인 유저 아이덴티티와 함께 사용될 수 있는 아이덴티티를 업데이트하도록 NOTIFY를 트리거한다.

따라서, 디바이스가 INVITE를 전송하는 경우, P-CSCF는 임의의 세션 시작을 위해 제1 공개 유저 아이덴티티를 어써트할 것이다.

따라서, 상기의 것은, UE가 제2 MCPTT 네트워크로 로밍할 수 있고 따라서 상호 지원을 제공할 수 있도록, 구성 메커니즘을 트리거하는 방식을 제공한다.

이제 도 14에 대한 참조가 이루어진다. 도 14의 실시형태에서, UE(1410)는 P-CSCF(1412)와 통신한다. 또한, S-CSCF(1414) 및 AAA(1416)가 시스템에 제공된다.

또한, MCPTT(1420), HSS(1422) 및 PS-UDF(1424)가 시스템에 제공된다.

도 14의 실시형태에서, 제2 인증 메커니즘(1430)이 먼저 수행된다. 특히, IMS 인증 등록(1432)은 제1 공개 유저 아이덴티티 대신 제2 공개 아이덴티티를 활용한다. 이 등록 프로세스는, UE가 MCPTT 서비스가 아닌 기본적인 IMS 서비스를 얻는 것을 허용한다.

제3자 등록(1434)은, 오로지, MCPTT 서비스에 제1 개인 유저 아이덴티티 및 제2 공개 아이덴티티를 등록한다. 그 다음, MCPTT 서비스는, MCPTT 서비스에 등록된 개인 유저 ID, 제2 공개 유저 아이덴티티 또는 디바이스 ID 중 적어도 하나를 사용하여 PS-UDF(1424)를 업데이트한다.

상기에 대한 시그널링은, 예를 들면, 3GPP TS 29.328에 대한 변경을 활용하여 제공될 수도 있다. 이러한 변경의 하나의 예가, 부록 Q와 관련하여 나타내어진다.

부록 Q에서 보여지는 바와 같이, IMS 유저 상태는 MCPTT와 같은 특정한 서비스에 대해 등록될 수도 있거나 또는 MCPTT와 같은 특정한 서비스에 대해 등록되지 않을 수도 있다.

일단 제2 공개 유저 식별자가 사용된 제2 인증 메커니즘이 완료되면, 제3자 레지스터 메시지가, 메시지(1436)에 의해 도시되는 바와 같이 MCPTT(1420)와 S-CSCF(1414) 사이에서 제공될 수도 있고, 가입자 메시지(1412)가 P-CSCF(1414)와 S-CSCF(1434) 사이에서 제공될 수도 있다.

후속하여, 제1 인증 메커니즘(1440)이 수행될 수도 있다. 제1 인증 메커니즘(1440)은 도 12의 제1 인증 메커니즘(1220)과 관련하여 상기에서 제공되는 것과 동일하다. 특히, 제1 인증 메커니즘은 인증을 위해 제1 공개 유저 아이덴티티 및 제1 개인 유저 아이덴티티를 활용한다. 이것은, AAA(1416)로 전달되는 메시지(1442)에 의해 나타내어진다. 그 다음, 제1 공개 유저 아이덴티티 및 개인 유저 아이덴티티는 메시지(1444)에서 PS-UDF(1424)로 제공된다.

그 다음, 제1 공개 유저 ID에 대해, 시도 벡터가, 메시지(1446)에서 나타내어지는 바와 같이, AAA(1416)로 제공된다. 그 다음, AAA(1416)는 이들 시도 벡터를 메시지(1448)에서 UE(1410)로 제공한다.

그 다음, UE는 메시지(1450)에 의해 나타내어지는 인증 응답을 AAA(1416)로 제공한다. 인증 응답은 메시지(1452)에서 PS-UDF(1424)로 포워딩된다. 인증 프로세스가 성공적이면, Sh 인터페이스를 통해 메시지(1460)에 의해 나타내어지는 바와 같이, PS-UDF(1424)(또는 몇몇 경우에 AAA)는 MCPTT 서버(1420)를 업데이트한다. 상기에서 설명되는 바와 같이, 부록 K와 관련하여 예시적인 메시지가 나타내어진다. Sh 인터페이스 상의 메시지는 제1 공개 유저 아이덴티티 및 옵션적으로 제1 개인 유저 아이덴티티를 포함한다. 그 다음, MCPTT 서버는, 제2 인증 메커니즘에서 제2 공개 유저 아이덴티티가 등록되었던 동일한 디바이스로부터 제1 공개 유저 아이덴티티가 등록되었다는 것을 상관시킬 수 있다. 마찬가지로, Sh 인터페이스는, MCPTT 서버가 PS-UDF에 제1 개인 유저 아이덴티티 및 제2 공개 유저 아이덴티티를 제공할 수 있고 따라서 제1 공개 유저 아이덴티티, 제2 공개 유저 아이덴티티 및 제1 개인 유저 아이덴티티 사이의 관계를 PS-UDF가 생성할 수 있도록, 사용될 수 있다. 그 다음, PS-UDF는, 메시지(1474)에 의해 나타내어지는 바와 같이, 이 관계를 사용하여 HSS를 업데이트할 수 있다. 본원에서 사용되는 바와 같은 용어 "업데이트"는, 제1 공개 유저 아이덴티티가 제1 개인 유저 아이덴티티와 함께 사용될 수 있는지를 결정하기 위해 HSS가 PS-UDF에 질의할 수도 있다는 것, 또는 HSS가 제1 공개 유저 아이덴티티, 제2 공개 유저 아이덴티티 및 제1 개인 유저 아이덴티티 사이의 관계를 생성할 수 있도록 PS-UDF가 HSS로 정보를 제공한다는 것을 의미한다.

메시지(1464 및 1466)는 성공을 나타내기 위해 제공될 수도 있다. 특히 메시지(1464)는 PS-UDF(1424)로부터 AAA(1416)로 제공된다. 메시지(1466)는 AAA(1316)로부터 UE(1410)로 제공된다.

Sh 통지는, MCPTT 서비스에 대한 인증이 성공했다는 표시를 제공하도록 향상될 수 있을 것이다. 향상된 예시적인 메시지는 하기의 부록 R에서 나타내어진다.

부록 R에서 보여지는 바와 같이, 디바이스가 서비스 X(MCPTT 또는 PTT일 수 있음)에 대해 등록되는 것 또는 등록되는 것을 허용하지 않는 3GPP TS 29.328에 대한 가능한 변경이 제공된다. 또한, 정보 엘리먼트는 IMS 유저가 MCPTT 서비스에 대해 등록한 디바이스의 디바이스 ID를 포함한다.

제1 인증 메커니즘 이후, 제2 인증 메커니즘(1470)은 도 12의 제2 인증 메커니즘(1222)과 관련하여 상기에서 설명되는 바와 같이 발생할 수도 있다.

또한, 일단 제1 인증 단계가 성공했다면, HSS(1422)는 상이한 공개 유저 아이덴티티를 사용하도록 네트워크를 업데이트하고, 두 개의 옵션적인 엘리먼트가 제공된다. 제1 옵션적인 메커니즘에서, HSS(1422)는 업데이트된 PCC 메시지(1484)를 사용하여 PCC(1482)를 업데이트할 수도 있다. 그 다음, PCC는 메시지(1486)에서 P-CSCF(1412)를 업데이트할 수도 있다.

그 다음, P-CSCF(1412)는 착신 메시지를 변환할 수도 있다. 따라서, UE(1410)는 제2 공개 아이덴티티를 갖는 INVITE(1488)를 전송할 수도 있고, 이 초대는, 그 다음, 메시지(1490)에 의해 나타내어지는 바와 같이, 제1 아이덴티티를 반영하도록 P-CSCF(1412)에서 변환된다.

또 다른 대안예에서, HSS(1422)는, 메시지(1495)에서, 차후, P-CSCF(1412)로 통지될 수도 있는 메시지(1494)에 의해 나타내어지는 바와 같이, 제1 공개 유저 아이덴티티에 대한 프로파일을 수정할 수도 있다.

그 다음, UE(1410)는 P-CSCF(1412)에 의해 변환될 수도 있는 메시지(1496)에 의해 나타내어지는 제2 유저 아이덴티티를 INVITE에 제공할 수도 있다. 그 다음, P-CSCF(1412)는, 메시지(1498)로 나타내어지는 바와 같이, INVITE를 포워딩할 수도 있지만, 그러나 제1 유저 아이덴티티를 가질 수도 있다.

대역 외 상호 지원

대역 외 솔루션의 또 다른 실시형태에서, 인증 메커니즘에서 UE가 등록되어 있는 PLMN에 관한 정보를, 네트워크가 요청하는 것, 및 UE가 제공하는 것을 추가적인 향상이 허용하는 제1 인증 메커니즘이 수행된다. 그 다음, 이 PLMN 정보는 어떤 공공 서비스 안전 공급자에 연락해야 하는지를 결정하기 위해 사용된다.

개인 유저 ID를 요청하기 위해, 새로운 메시지가 제1 공공 안전 오퍼레이터의 MCPTT 서버로부터 제2 공공 안전 오퍼레이터의 PS-UDF로 전송된다. 어쩌면, 이러한 메시지는 인증되고 있는 유저의 공개 유저 ID를 포함할지도 모른다.

그 다음, 제2 공공 안전 오퍼레이터의 PS-UDF는 개인 유저 ID 및 공개 유저 ID를 다시 제공한다. 그 다음, 이 정보는, 오픈 모바일 얼라이언스(OMA) 디바이스 관리, 하이퍼 텍스트 전송 프로파일(hypertext transfer profile; HTTP), XML 구성 액세스 프로토콜(XML Configuration Access Protocol; XCAP), 또는 이 정보를 저장하는 새로운 필드가 존재하는 USIM 또는 ISIM 애플리케이션으로의 오버 디 에어(over the air; OTA) 메시지와 같은 메시징을 통해 UE로 전송될 수도 있다.

그 다음, UE는 새로운 개인 및 공개 유저 식별자를 사용하여 제2 인증 메커니즘을 수행할 수도 있다. 제2 안전 오퍼레이터의 PS-UDF가 제2 인증 메커니즘을 수신하면, 제1 공공 안전 오퍼레이터의 PS-UDF와 연락하여 자격 증명을 획득하고 그들을 사용하여 유저를 인증한다.

이제, UE(1510)가 TTLS/IPSec 서버(1512)를 통해 제1 MCPTT 오퍼레이터(1520)의 PS-UDF(1514) 및 MCPTT 서버(1516)와 통신하는 도 15에 대한 참조가 이루어진다. PLMN(1524)의 S-CSCF(1522)는 제1 오퍼레이터(1520)의 MCPTT에 활용된다. TTLS/IPSec 서버(1512)는 PS-UDF(1514) 및 MCPTT 서버(1516) 중 어느 하나 또는 둘 모두와 결합될 수 있을 것임을 유의한다. 이러한 구현은 점선(1590)으로 도시된다.

제2 MCPTT 오퍼레이터(1526)는 제2 PS-UDF(1528)를 갖는다.

도 15의 실시형태에서, UE(1510)는 제1 개인 유저 아이덴티티, 제2 공개 유저 아이덴티티, 디바이스 아이덴티티 및 제1 개인 및/또는 공개 유저 아이덴티티에 링크될 수 있는 인증서를 포함한다.

제1 인증 메커니즘(1530)이 제공된다. 인증 메커니즘(1530)의 옵션적인 제1 부분의 일부로서, UE(1510)는, 메시지(1532)에 의해 나타내어지는 바와 같이, TTLS/ipsec 서버(1512)와의 TTLS/ipsec 터널을 셋업할 수 있을 것이다. 하나의 실시형태에서, 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에서 나타내어진다.

그 다음, 제1 인증 메커니즘이 사용될 수도 있다. 이러한 제1 인증 메커니즘의 예는 도 12 또는 도 14와 관련하여 상기에서 설명되었다.

메시지(1534)에 의해 나타내어지는 바와 같이, 인증 메커니즘은 소정의 정보를 제공할 수도 있다. 하나의 옵션에서, UE는 인증될 제2 공개 유저 아이덴티티를 포함하는 아이덴티티를 전송할 수도 있다. 전송될 옵션적인 추가 정보는, 기기를 식별하는 디바이스 식별자 및/또는 UE가 등록되어 있는 또는 등록되었던 네트워크를 포함할 수도 있지만, 그러나 이들로 제한되지는 않는다. 이러한 추가 정보는 네트워크 노드에 의해, 예를 들면 PS-UDF(1514)가 UE로 메시지를 전송하는 것에 의해 획득될 수도 있다. 이러한 메시지는, 다른 정보 중에서도, 예를 들면, UE가 등록되어 있는 PLMN, 디바이스 ID를 비롯한 추가 정보를 요청하는 표시자를 포함할 수도 있다. UE는 이 메시지를 수신하고, 유저 기기를 식별하는 디바이스 식별자 및/또는 UE가 등록되어 있는 또는 등록되었던 네트워크를 포함하는 메시지를 네트워크, 예를 들면, PS-UDF로 전송한다.

추가 정보는 부록 S에서 나타내어지는 바와 같이 메시지의 요청의, UE에서의 수신에 기초하여 전송될 수도 있다.

성공적인 인증시, PS-UDF(1514)는, 제2 공개 유저 아이덴티티에 대한 인증이 성공적이었다는 표시를 MCPTT AS(1516)로 전송한다. 이것은 메시지(1536)에서 나타내어진다. 제1 개인 유저 아이덴티티, 제1 공개 유저 아이덴티티, 제2 공개 유저 아이덴티티, PLMN 및 IMEI가 또한 나타내어질 수도 있다. PS-UDF(1514)는 하나의 구현예에서 MCPTT AS일 수 있을 것이다. 이것을 위한 3GPP TS 24.302 명세에 대한 가능한 변경의 하나의 예가 아래의 부록 T를 사용하여 나타내어진다. 제1 공개 유저 아이덴티티는, 인증 메커니즘(1530)에서 이루어질 수 있으며 이하에서 더 상세히 설명되는 인증서 교환으로부터 도출될 수 있다는 것을 유의한다.

일단 제1 인증 메커니즘(1530)이 종료되면, 구성 메커니즘(1540)이 발생할 수도 있다. 기술 분야에서 숙련된 자는, 메시지(1534)에서 나타내어지는 인증 메커니즘이, 다른 것들 중에서도, 인증 메커니즘(1440, 1220)(이들로 제한되지는 않음)에서 설명되는 것이 되도록 분해될 수 있다는 것을 인식할 것이다.

구성 메커니즘 동안, 메시지(1542)는 UE(1510)로부터 MCPTT AS(1516)로 제공될 수도 있다. 메시지(1542)는 옵션적으로 네트워크에 구성 요청을 제공할 수도 있다. 그것은 UE가 등록한 네트워크의 PLMN 아이덴티티를 포함할 수도 있다. 이 요청은, UE가 MCPTT 아이덴티티의 구성을 위해 OMA 관리 오브젝트를 사용하기 때문에 발생할 수도 있다.

그 다음, MCPTT AS(1516)는 메시지(1544)에 의해 나타내어지는 바와 같이 제2 MCPTT 오퍼레이터(1526)에게 제2 개인 식별자 및 제3 공개 유저 아이덴티티를 요청할 수도 있다. 메시지(1544)는 다음의 것 중 0개 이상을 포함할 수도 있다: 제1 개인 유저 아이덴티티, 제1 공개 유저 아이덴티티, 제2 공개 유저 아이덴티티. MCPTT 오퍼레이터(1526)는 정적 구성에 기초하여 또는 UE가 등록에서 사용한 PLMN 아이덴티티에 대한 DNS 룩업을 수행하는 것에 의해 도출될 수도 있다.

제2 PS-UDF(1528)는 메시지(1544)를 수신한다. 하나의 실시형태에서, MCPTT AS는, 제1 개인 유저 ID가 공개되지 않는 것을 보장하기 위해 제1 공개 유저 ID만을 제2 PS-UDF(1528)로 전송할 수도 있다.

제2 PS-UDF(1528)는 제2 개인 유저 ID를, 다음의 것과, 수신되면, 관련시킨다: 제1 개인 유저 아이덴티티; 제1 공개 유저 아이덴티티; 제2 공개 유저 아이덴티티; 및/또는 기기 아이덴티티.

PS-UDF(1528)는 메시지(1546)에서 제2 개인 유저 아이덴티티 및 제3 공개 유저 아이덴티티 중 적어도 하나를 되전송한다. MCPTT AS(1516)는 제2 개인 유저 아이덴티티 및 제3 공개 유저 아이덴티티 중 적어도 하나를 수신한다.

그 다음, 데이터가 UE에 프로비저닝될 수도 있다. 데이터 모델은, 개인 식별자 및 공개 식별자가 UE에 프로비저닝되는 아래의 도 16에서 발견될 수 있다. 기술 분야의 숙련된 자는, 이것이 데이터의 세트를 설명하는 OMA 디바이스 관리(Device Management; DM) 오브젝트의 예이다는 것을 인식할 것이다. 그러나, 그것은 추상 데이터 모델로서 동등하게 사용될 수 있다. 예를 들면, 개인 식별자는 E.212에 정의되는 바와 같은 IMSI 또는 RFC 4282에서 정의되는 바와 같은 네트워크 주소 표시자(network address indicator; NAI)일 수 있을 것이다. 공개 ID는 E.164에 의해 정의되는 바와 같은 MSISDN 또는 RFC 4282에 의해 정의되는 바와 같은 NAI일 수 있을 것이며, NAI는 MSISDN을 나타내는 숫자 문자열을 또한 포함할 수도 있다.

PLMN, PLMN 내의 영역, 지리적 영역 또는 심지어 WLAN 또는 이들의 조합에 고유할 수 있는 이들 아이덴티티에 대한 유효 영역이 식별될 수 있다.

도 16을 설명하는 목적을 위해, 책/소설의 유추가 사용될 것이다. 그러나, 식별되는 바와 같이, OMA DM은 다이어그램의 명명법을 자세히 설명한다. 따라서, 도 16을 참조하면, 블록(1612)에 의해 나타내어지는 바와 같이, MCPTT(1610)는 0 내지 다수의 페이지를 가질 수도 있다.

도 16의 실시형태에서, 물음표는 옵션적인 엘리먼트를 나타낸다. 따라서, 하나의 옵션 엘리먼트는 일련의 식별자(1620)를 포함한다. 각각의 식별자는 개인 식별자(1622) 또는 공개 식별자(1624)일 수도 있고, IMSI 또는 개인 유저 식별자 또는 MSISDN 또는 공개 유저 식별자를 포함할 수도 있는 다양한 패러그래프(paragraph)(예를 들면, 데이터 항목의 세트)(1626 및 1628)를 포함할 수도 있다. 세트는 0개 내지 많은 엔트리를 포함할 수도 있다는 것을 유의한다.

페이지 각각은 유효 영역(1630)을 또한 포함할 수도 있다. 유효 영역은, 다른 것들 중에서도, 3GPP 위치(1632), 3GPP2 위치(1634), WLAN 위치(1636) 또는 지리적 위치(1638)에 기초할 수도 있다.

이 때, 각각의 위치는 결정을 행하기 위한 몇 가지 기준을 가질 수도 있다. 따라서, 3GPP 위치는 다양한 패러그래프(1640)를 가질 수도 있으며, 다른 정보 중에서도, PLMN, 타입 할당 코드(Type Allocation Code; TAC), 위치 영역 코드(Location Area Code; LAC), GSM 에지 무선 액세스 네트워크(GSM Edge Radio Access Network; GERAN) 셀 식별자(Cell Identifier; CI), 범용 모바일 원격통신 서비스(Universal Mobile Telecommunications Service; UMTS) 지상 무선 액세스 네트워크(UMTS Terrestrial Radio Access Network; UTRAN) CI, 진화형 범용 지상 무선 액세스(Evolved Universal Terrestrial Radio Access; EUTRA) CI와 같은 정보를 포함할 수도 있다.

3GPP2 위치는, 블록(1650)에 의해 나타내어지는 바와 같이 연결이 1x 연결인지를 결정하기 위한 검사를 가질 수도 있는데, 이 경우 다수의 패러그래프(1552)가 제공될 수도 있다. 이들 패러그래프의 정보는 시스템 ID(system ID; SID), 네트워크 ID(network ID; NID) 또는 기본 ID를 포함할 수도 있다.

마찬가지로, 3GPP 위치가 블록(1654)에 의해 나타내어지는 바와 같이 고속 패킷 데이터(high rate packet data; HRPD)인 경우, 다수의 페이지(1656)가 제공될 수도 있다. 이들 페이지는 섹터 ID 또는 넷마스크와 같은 정보를 포함할 수도 있다.

WLAN 위치(1636)는 다양한 패러그래프(1662)를 가질 수도 있다. 이들 패러그래프의 정보는, 다른 정보 중에서도, 동질의 확장 서비스 세트 식별자(homogenous extended service set identifier; HESSID), 서비스 세트 식별자(service set identifier; SSID), 또는 기본 서비스 세트 식별자(basic service set identifier; BSSID)를 포함할 수도 있다.

지리적 위치(1638)는, 그것이 블록(1670)에 의해 나타내어지는 원형 위치인지를 결정하기 위한 검사를 가질 수도 있는데, 이 경우 다수의 패러그래프(1672)가 제공될 수도 있다. 이들 패러그래프의 정보는, 다른 정보 중에서도, 앵커 위도, 앵커 경도, 및 반경을 포함할 수도 있다.

또한, 지리적 위치(1638)는 블록(1684)에 의해 나타내어지는 바와 같이 그 위치가 다각형인지를 결정하기 위해 이것을 검사할 수도 있는데, 이 경우 다수의 패러그래프(1686)가 제공될 수도 있다.

패러그래프(1686)는, 좌표(1688)를 포함할 수도 있는데, 좌표(1688) 자체는 다수의 패러그래프(1690)를 갖는다. 패러그래프(1690)의 정보는 위도 및 경도를 포함할 수도 있다.

다시 도 15를 참조하면, 일단 MCPTT(1516)가 메시지(1546)의 정보를 수신하면, 화살표(1550)로 도시되는 바와 같이, UE와 MCPTT 사이에서 구성이 발생할 수도 있다. 화살표(1550)에서, USIM/ISIM이 사용되면, MCPTT AS는, 적어도 제2 개인 유저 ID 및 제3 공개 유저 ID, 및 옵션적으로 PLMN 정보를 포함하는, 그러나 이들로 제한되지는 않는 메시지를 전송한다.

하나의 실시형태에서, 메시지(1546 및 1550)는 옵션적이며, 이 경우, MCPTT AS(1516)는 제3 공개 유저 ID를 생성할 필요가 있을 것이다. 그러나, 이 경우 제2 개인 유저 ID는 생성되지 않을 것이다.

MCPTT AS(1516)에서, 다음의 것 중 몇몇 사이에서 또는 전체 사이에서 매핑이 발생한다: 제1 개인 유저 아이덴티티; 제1 공개 유저 아이덴티티; 제2 공개 유저 아이덴티티; 기기 아이덴티티; 제2 개인 유저 아이덴티티; 및 제3 공개 유저 아이덴티티.

메시지(1550)는 오버 디 에어(OTA) 정보를 포함하는 단문 메시지 서비스(short message service; SMS) 메시지일 수 있을 것이다. 오버 디 에어 메시지 시퀀스는 한정자(qualifier) "MCPTT 개인 유저 ID 업데이트"를 갖는 USAT REFRESH 커맨드를 포함할 수 있을 것이다.

UE는, 메시지(1550)에서 구성 정보의 수신시, 메시지를 디코딩할 수 있을 것이다. SMS 목적지 어드레스는 제2 공개 유저 ID일 수 있을 것이다. 하나의 실시형태에서, 부록 U는 3GPP TS 31.102에서 동등하게 적용될 수 있는 3GPP TS 31.103 명세에 대한 가능한 변경을 나타낸다.

또한, 커맨드 세부 사항은 ETSI TS 102 223 명세에 대한 가능한 변경을 나타내는 부록 V에 따라 제공될 수 있을 것이다.

ME가 타입 "MCPTT 개인 유저 ID 업데이트"의 USAT REFRESH 커맨드 한정자를 수신하면, ME는 디바이스 상의 개인 식별자를 업데이트할 수 있다.

대안적으로, OMA DM, HTPP 또는 XCAP가 사용되면, UE는 네트워크(예를 들면, MCPTT AS 등등)로 메시지를 전송하는 것에 의해 UE에 대한 구성을 수신한다. 네트워크는, 개인 ID, 공개 ID 및 네트워크 코드 중 하나 이상을 포함할 수 있는 구성 정보를 가지고 다시 응답할 것이다. 전송될 수도 있는 정보는 도 16과 관련하여 나타내어진다.

일단 구성 메커니즘(1540)이 완료되면, 제2 인증 메커니즘(1560)이 발생할 수 있을 것이다. 제2 인증 메커니즘(1560)은 등록 메시지(1562)를 포함한다. 이러한 메시지는, 제2 개인 유저 ID 및 옵션적으로 제3 공개 유저 식별자를 포함하는 SIP 레지스터일 수도 있다. 제2 개인 유저 ID가 메시지(1550)의 구성 정보에서 수신되지 않으면, 제1 개인 유저 ID는 제3 공개 유저 식별자와 함께 사용될 필요가 있을 것이다.

기술 분야의 숙련된 자에 의해 인식되는 바와 같이, 사용할 공개 및 개인 유저 식별자는 UE가 등록되어 있는 PLMN에 기초할 것이다. 이것은, ME가, 등록된 PLMN(registered PLMN; RPLMN)을, 도 16의 유효성 영역/3GPP 위치/<x>/PLMN 리프의 PLMN과 비교할 수도 있다는 것을 의미한다. 매치가 존재하면, 사용되는 공개 및 개인 유저 ID는 그 PLMN과 관련된다. 정보가 부록 U에서 나타내어지는 바와 같이 USIM/ISIM 상에 저장되면, ME는 RPLMN을 PLMN 필드와 비교할 것이고 적절한 데이터를 선택할 것이다.

S-CSCF는 메시지(1562)를 수신하고 옵션적으로 메시지(1564)를 PS-UDF(1528)로 제공할 수도 있다. 메시지(1564)는, 메시지(1562)에서 제2 개인 유저 아이덴티티가 사용된 경우에만 발생한다. 제2 PS-UDF(1528)는 메시지(1564)를 수신하고 PS-UDF(1528)는 매핑을 생성하기 위해 이 정보를 사용할 수도 있다. 그 다음, 메시지(1566)는 MCPTT(1516)로 전송되어, 이용 가능한 경우 제1 개인 ID에 대한 인증 벡터를 획득할 수도 있고, 그렇지 않다면, 제1 공개 유저 ID에 대한 인증 벡터를 획득할 수도 있다. 예를 들면, 메시지(1566)는, 이용 가능한 경우 제1 개인 ID 및 또는 제1 공개 유저 ID를 자신의 내용 내에 포함한다.

MCPTT(1516)는 메시지를 수신하고, 이용 가능한 경우 제1 개인 ID에 대한 및/또는 제1 공개 유저 ID에 대한 인증 벡터를 요청하는 메시지(1570)를 PS-UDF(1514)로 전송한다. 제1 공개 유저 ID가 수신되면, MCPTT AS는 상기에서 생성되는 매핑을 사용하여 개인 유저 ID를 결정할 것이다.

PS-UDF(1514)는 인증 벡터를 요청하는 메시지(1570)를 수신하고 벡터를 생성한다. 그 다음, PS-UDF는 제1 개인 유저 ID에 대한 인증 벡터를 포함하는 메시지(1572)를 MCPTT(1516)로 되전송한다.

메시지(1574)에 의해 나타내어지는 바와 같이, MCPTT(1516)는 제1 개인 유저 ID에 대한 인증 벡터를 포함하는 메시지(1572)를 수신하고 그 메시지를 제2 PS-UDF(1528)로 전송한다. 그 다음, 메시지(1580 및 1582)에 의해 나타내어지는 바와 같이, 제2 PS-UDF는 제3 공개 유저 아이덴티티 및 제2 개인 유저 아이덴티티에 대한 벡터를 생성할 수도 있고 이들은 UE로 포워딩될 수도 있다.

기술 분야의 숙련된 자에 의해 인식되는 바와 같이, 도 15는 예에 불과할 뿐이다. 대안적인 실시형태에서, UE는, UE 상에 저장되는 개인 유저 아이덴티티 및 공개 유저 아이덴티티를 사용하여, 제2 인증을 먼저 수행할 수도 있다. 그 다음, UE는 제1 인증 메커니즘을 후속하여 수행할 수도 있다.

또한, 상기의 본 개시의 맥락에서, 제2 인증 메커니즘은 라벨(1222, 1430, 1470, 1560)을 가지고 다수의 실시형태에서 설명된다. 그 예는 옵션적인 인증 컴포넌트를 또한 포함하는 SIP REGISTRATION 절차에 기초한다는 것이 인식될 것이다. 이러한 SIP 등록 프로세스는 도 2와 관련하여 상기에서 설명되었다. 3GPP TS 33.203에 따라, 제2 인증 메커니즘은, UE가 SIP 레지스터 메시지를 네트워크로 전송하는 것에 의해 시작하고, 그 다음, UE는, UE가 다른 레지스터 메시지를 가지고 응답할 인증 시도를 포함하는 메시지를 네트워크로부터 수신한다.

인증(Certification) 생성 프로세스

또 다른 실시형태에서, 개인 ID, 공개 ID 및 디바이스 ID를 획득하기 위한 상기에서 열거되는 프로토콜에 대한 향상 대신, 상기에서 설명되는 실시형태와 연계하여 또한 사용될 수 있는 인증서를 사용하는 것이 또한 가능하다.

UE는 상기에서 설명되는 바와 같이 제1 인증 메커니즘 절차를 수행하고 터널을 셋업한다. 터널이 셋업된 이후, 제1 공개 유저 아이덴티티의 인증이 임의의 인증 스킴을 사용하여 수행될 수 있다. 이러한 인증 스킴의 예는, 다른 것들 중에서도, EAP, 시도 핸드쉐이크 인증 프로토콜(challenge handshake authentication protocol; CHAP), 패스워드 인증 프로토콜(password authentication protocol; PAP), 또는 메시지 다이제스트 5(Message-Digest 5; MD-5)를 포함한다.

따라서, 제1 보안 터널이 UE와 네트워크 사이에서 셋업되고, 그 다음, 터널 내에서, 공개 유저 아이덴티티의 인증이 발생한다.

초기 터널 셋업에서, 인증서가 제공될 수도 있다. 이것은, 예를 들면, x.509 인증서일 수 있을 것이다. 인증서는 하기의 설명에 따라 새로운 방식으로 생성될 수도 있다. 하나의 실시형태에서, 인증서는 사전 제공될 수도 있고 UICC로부터 디바이스 ID 또는 개인 유저 식별자 중 어느 하나에 링크될 수도 있다.

터널의 셋업은 디바이스와 개인 식별자 사이의 네트워크에서의 관계를 생성한다. 그 다음, 공개 유저 아이덴티티 인증 단계가 ME와 AAA 서버 사이에서 시작한다. AAA 서버가 TTLS 서버와 병치되면, TTLS 서버에서 디바이스 ID, 개인 ID, 및 공개 유저 ID 사이의 관계가 존재한다. TTLS/AAA 서버는 IMS AS일 수 있으며 상기의 설명에서 그것은 또한 MCPTT AS일 수도 있다.

UE는, 제1 인증 메커니즘 이전 또는 이후에 발생할 수도 있는 IMS 등록과 같은 제2 인증 메커니즘을 수행한다(예를 들면, 제2 인증 메커니즘은 EAP-TTLS 절차일 수 있을 것이다). IMS 등록에서, 디바이스는 제1 인증 메커니즘(예를 들면, EAP-TTLS 동작일 수 있음)의 인증서에 링크되는 개인 유저 식별자 및 제2 공개 유저 아이덴티티를 포함한다. IMS 네트워크 내의 S-CSCF는, IMS 개인 유저 식별자, IMS에 대한 제2 공개 유저 식별자 및 디바이스 식별자를 포함할 수도 있는, 그러나 이들로 제한되지는 않는 MCPTT AS와의 제3자 등록을 수행한다.

이 시점에서, 이제, MCPTT AS와 IMS 개인 유저 식별자, 제2 IMS 공개 유저 식별자, 제1 공개 IMS 유저 식별자 및 디바이스 식별자 사이에 연결성(linkage)이 존재한다.

이제, MCPTT AS가 세션 요청을 수신하는 경우, 그것은 IMS 네트워크로부터 IMS 제2 공개 유저 ID를 숨기는 옵션을 갖는다.

이제, UE(1710), P-CSCF(1712), 제1 공공 안전 기관(1714)(S-CSCF(1716) 및 MCPTT AS(1718)을 구비함)을 도시하는 도 17에 대한 참조가 이루어진다.

MCPTT AS(1718)는 PS-UDF(1720) 및 AAA(1722)를 포함한다.

제2 공공 안전 기관(1724)은 HSS(1726)를 포함한다.

도 17의 실시형태에서, UE와 제2 공공 안전 기관 사이의 등록이 발생하는 제2 인증 메커니즘(1730)이 먼저 발생한다. 등록은 제1 개인 아이덴티티 및 제2 아이덴티티 아이덴티티를 포함한다. 특히, 블록(1732)에 의해 나타내어지는 바와 같이, 등록은 제1 개인 ID 및 제2 공개 유저 ID를 포함한다.

블록(1732)의 등록 메시지에 기초하여, 제3자 등록(1734)이 발생할 수도 있다.

UE는 디바이스 상의 IMSI에 저장되는 제1 개인 유저 ID 및 제2 공개 유저 ID를 사용하여 제2 인증 프로세스를 시작할 것이다. 프로세스의 완료시, S-CSCF는 MCPTT AS에서 제3자 등록을 행할 것이다. 제3자 등록에서, 제1 개인 유저 ID 및 제2 공개 유저 ID가 포함된다. MCPTT 서버는 이 정보를 수신할 것이고, 그 다음, 저장되는 데이터에 대해 제1 공개 유저 ID를 제2 공개 유저 ID와 매핑할 것이다.

성공적인 제2 인증시, 제1 인증 메커니즘(1740)이 시작한다. 제1 인증 메커니즘(1740)의 제1 부분은 터널 셋업(1742)이다. 도 17의 예에서, MCPTT AS와의 터널 셋업 및 인증 기능을 갖는 것은 MCPTT AS(1718)이다.

블록(1744)에 의해 나타내어지는 바와 같이, 다음에, 터널 인증이 발생한다. UE와 네트워크 사이에서 인증서가 교환된다. 인증서는, 다음 중 일부 또는 전부가 인증서로부터 도출될 수도 있는 그러한 것이다:(U)/ISIM 상의 제1 개인 유저 ID; (U)/ISIM 상의 제2 공개 유저 ID; 및 IMEI 또는 디바이스 식별자. 터널 셋업 인증 프로세스 동안, MCPTT AS(1718)는 이들 항목 사이의 관계의 데이터베이스를 생성할 것이다.

블록(1746)에 의해 나타내어지는 바와 같이, 터널의 성공적인 생성 이후, 디바이스를 사용하고 있는 공개 유저 ID를 인증하기 위해 다른 인증 프로세스가 시작될 것이다. 예를 들면, 이러한 ID는 경찰관의 자격 증명일 수도 있다. 이것은 제1 공개 유저 ID로 칭해질 것이다.

성공적인 인증시, MCPTT는, 화살표(1750)에 의해 나타내어지는 바와 같이, 이 식별자를, 상기에서 설명되는 데이터베이스에 저장되어 있는 정보와 관련시킬 것이다.

인증서의 예가 하기에서 제공된다.

제1 인증서 옵션

이제, 블록(1810)에서 새로운 개인 식별자를 검출하고 블록(1812)에서 인증서를 생성하는 디바이스를 도시하는 도 18에 대한 참조가 이루어진다. 인증서를 생성하는 것은, 생성 블록(1812)에 대한 입력으로서 디바이스 식별자(1814) 및 개인 식별자(1816)를 포함한다. 블록(1810 및 1816) 둘 모두는 동일한 개인 유저 아이덴티티를 포함한다.

인증서(1820)는 생성 블록(1812)으로의 출력으로서 제공된다.

하나의 실시형태에서, 디바이스는 초기 인증서를 포함할 수도 있거나 또는 포함하지 않을 수도 있다. 새로운 UICC가 디바이스에 삽입되는 것의 검출시 또는 IMSI 또는 UICC 코드가 변경되었다는 또는 새로운 USIM 또는 ISIM이 활성화되었다는 검출시, 디바이스는 새로운 인증서를 요청할 것이다. 활성화는, 예를 들면, IMSI 또는 IMS 개인 유저 아이덴티티가 변경된 것일 수도 있다.

생성되는 인증서는 ME와의 UICC/USIM/ISIM 조합을 식별할 것이다.

제2 인증서 옵션

제2 인증서 옵션에서, 디바이스 ME_A에 제1 인증서가 프로비저닝되는데, 여기서 제1 인증서는, 제1 개인 키에 의해 생성되는 서명을 검증하기 위해 사용되는 제1 공개 키를 포함한다. 제1 개인 키는 ME_A에도 또한 프로비저닝된다.

USIM_A는 IMSI_A와 함께 디바이스에 삽입되고 User_A는 UserIdA 및 pwdA를 사용하여 디바이스에 로그인한다.

디바이스 ME_A는 시간 T_now에서 [IMSI_A, pwdA, T_now]를 서명하여 서명 SigA를 형성한다.

디바이스는 CertA, SigA, [IMSI_A, UserIDA T_now]를, 이제 다음을 할 수 있는 공공 안전 오퍼레이터에게 전송한다:

1) CertA로부터 ME_A를 식별함

2) UserldA 및 pwdA로부터 User_A(공공 안전 오퍼레이터가 pwdA의 자기 자신의 사본을 가지고 있다고 가정함)

3) IMSI_A로부터 USIM_A

이들 아이덴티티 모두는 SigA를 검증하는 것에 의해 인증될 수도 있는데, 여기서:

1) 서명 SigA는 IMSI_A, UserldA 및 KeyA, T_now를 사용하여 계산된다.

2) 서명 SigA는 SigA, IMSI_A, UserldA, T_now 및 PubKeyA를 사용하여 인증된다

따라서, 상기의 것은, UICC를 변경할 필요 없이, 공유 디바이스의 유저를 인증하는 수단을 제공한다. 그 솔루션은 전화를 사용하는 유저의 다양한 정도의 기밀 유지성을 제공한다. 나중의(later) 대역 외 솔루션은 유저를 숨기기 위한 수단을 제공하고, 따라서 IMS 네트워크에서 어떤 정보가 가시적이어야 하는지를 공공 안전 오퍼레이터가 결정하는 것을 허용한다. 그들은 또한, IMS 인증 메커니즘과 유저 인증 메커니즘 사이에 다양한 정도의 연결성을 제공한다.

상기의 것은, 유저가, 그 디바이스 상에서 인증되면, 그들이 다시 인증되지 않는 한, 그 디바이스 상에서 세션을 계속해야 하도록, 연결성을 생성한다. 단일의 로그온은, 유저가 악의적인 목적을 위해 디바이스 사이에서 UICC SIM 카드를 교환하는 것을 허용하지 않는다. 디바이스 상의 인증서는, 그들이 공공 안전 오퍼레이터에 의해서만 프로비저닝될 수 있도록 하는 그러한 것일 수 있고, 유효한 디바이스만이 네트워크 상에서 사용되는 것을 허용하게 된다.

상기의 도 1 내지 도 17의 실시형태에서의 서버 및 네트워크 엘리먼트는, 다양한 네트워크 서버를 비롯하여, 임의의 네트워크 엘리먼트, 또는 임의의 네트워크 엘리먼트의 일부일 수 있다. 이제, 일반화된 네트워크 엘리먼트를 도시하는 도 19에 대한 참조가 이루어진다.

도 19에서, 네트워크 엘리먼트(1910)는 프로세서(1920) 및 통신 서브시스템(1930)을 포함하는데, 여기서 프로세서(1920) 및 통신 서브시스템(1930)은 상기에서 설명되는 실시형태의 방법을 수행하도록 협력한다.

프로세서(1920)는 프로그래밍 가능한 로직을 실행하도록 구성되는데, 프로그래밍 가능한 로직은, 데이터와 함께, 네트워크 엘리먼트(1910) 상에 저장될 수 있고, 도 19의 예에서 메모리(1940)로서 도시될 수도 있다. 메모리(1940)는 임의의 유형의(tangible) 비일시적인 저장 매체일 수 있다.

대안적으로, 또는 메모리(1940)에 추가하여, 네트워크 엘리먼트(1910)는, 예를 들면, 통신 서브시스템(1930)을 통해 외부 저장 매체로부터 데이터 또는 프로그래밍 가능한 로직에 액세스할 수도 있다.

통신 서브시스템(1930)은 네트워크 엘리먼트(1910)가 다른 네트워크 엘리먼트와 통신하는 것을 허용한다. 통신 서브시스템(1930)에 대한 프로토콜의 예는, 다른 것들 중에서도, 셀룰러, 이더넷, WiFi, WiLAN을 포함한다.

네트워크 엘리먼트(1910)의 다양한 엘리먼트 사이의 통신은, 하나의 실시형태에서 내부 버스(1950)를 통할 수도 있다. 그러나, 다른 형태의 통신도 가능하다.

또한, 상기의 것은 임의의 UE에 의해 구현될 수도 있다. 하나의 예시적인 디바이스가 도 20과 관련하여 하기에서 설명된다.

UE(2000)는, 통상적으로, 음성 및 데이터 통신 능력을 갖는 양방향 무선 통신 디바이스이다. UE(2000)는, 일반적으로, 인터넷 상의 다른 컴퓨터 시스템과 통신하는 능력을 구비한다. 제공되는 정확한 기능성에 따라, UE는, 예로서, 데이터 메시징 디바이스, 양방향 페이저, 무선 이메일 디바이스, 데이터 메시징 성능을 갖는 셀룰러 전화, 무선 인터넷 어플라이언스(wireless Internet appliance), 무선 디바이스, 모바일 디바이스, 또는 데이터 통신 디바이스로 칭해질 수도 있다.

UE(2000)가 양방향 통신에 대응하는 경우, 그것은, 수신기(2012) 및 송신기(2014) 둘 모두를 포함하는 통신 서브시스템(2011)뿐만 아니라, 관련 컴포넌트 예컨대 하나 이상의 안테나 엘리먼트(2016 및 2018), 로컬 발진기(local oscillator; LO)(2013), 및 디지털 신호 프로세서(digital signal processor; DSP)(2020)와 같은 프로세싱 모듈을 통합할 수도 있다. 통신 분야에서 숙련된 자에게 명백한 바와 같이, 통신 서브시스템(2011)의 특정한 설계는, 디바이스가 동작하도록 의도되는 통신 네트워크에 의존할 것이다.

네트워크 액세스 요건은 또한 네트워크(2019)의 타입에 따라 변할 것이다. 몇몇 네트워크에서, 네트워크 액세스는 UE(2000)의 유저 또는 가입자와 관련된다. UE는, CDMA 네트워크 상에서 동작하기 위해, 착탈식 유저 식별 모듈(removable user identity module; RUIM) 또는 가입자 식별 모듈(subscriber identity module; SIM) 카드를 필요로 할 수도 있다. SIM/RUIM 인터페이스(2044)는, 일반적으로, SIM/RUIM 카드가 삽입 및 배출될 수 있는 카드 슬롯과 유사하다. SIM/RUIM 카드는 메모리를 가질 수 있고 다수의 키 구성(2051), 및 식별 정보 및 가입자 관련 정보와 같은 다른 정보(2053)를 유지할 수 있다.

필수 네트워크 등록 또는 활성화 절차가 완료되면, UE(2000)는 네트워크(2019)를 통해 통신 신호를 전송 및 수신할 수도 있다. 도 20에서 예시되는 바와 같이, 네트워크(2019)는 UE와 통신하는 다수의 기지국으로 구성될 수 있다.

통신 네트워크(2019)를 통해 안테나(2016)에 의해 수신되는 신호는 수신기(2012)로 입력되는데, 수신기(2012)는 신호 증폭, 주파수 하향 변환, 필터링, 채널 선택 및 등등과 같은 공통 수신기 기능을 수행할 수도 있다. 수신된 신호의 A/D 변환은, 복조 및 디코딩과 같은 더욱 복잡한 통신 기능이 DSP(2020)에서 수행되는 것을 허용한다. 유사한 방식으로, 송신될 신호가 DSP(2020)에 의해 프로세싱되고(예를 들면, 변조 및 인코딩을 포함함) 디지털 아날로그 변환, 주파수 상향 변환, 필터링, 증폭 및 안테나(2018)를 경유한 통신 네트워크(2019)를 통한 송신을 위해 송신기(2014)로 입력된다. DSP(2020)는 통신 신호를 프로세싱할뿐만 아니라, 또한, 수신기 및 송신기 제어를 제공한다. 예를 들면, 수신기(2012) 및 송신기(2014)에서 통신 신호에 적용되는 이득은, DSP(2020)에서 구현되는 자동 이득 제어 알고리즘을 통해 적응적으로 제어될 수도 있다.

UE(2000)는 일반적으로, 디바이스의 전체 동작을 제어하는 프로세서(2038)를 포함한다. 데이터 및 음성 통신을 비롯한 통신 기능은 통신 서브시스템(2011)을 통해 수행된다. 프로세서(2038)는 또한 다른 디바이스 서브시스템, 예컨대 디스플레이(2022), 플래시 메모리(2024), 랜덤 액세스 메모리(random access memory; RAM)(2026), 보조 입/출력(input/output; I/O) 서브시스템(2028), 직렬 포트(2030), 하나 이상의 키보드 또는 키패드(2032), 스피커(2034), 마이크(2036), 단거리 통신 서브시스템과 같은 다른 통신 서브시스템(2040) 및 2042로 일반적으로 지정되는 임의의 다른 디바이스 서브시스템과 상호작용한다. 직렬 포트(2030)는 USB 포트 또는 기술 분야의 숙련된 자에게 공지된 다른 포트를 포함할 수 있을 것이다.

도 20에서 도시되는 서브시스템 중 일부는 통신 관련 기능을 수행하는 반면, 다른 서브시스템은 "상주(resident)" 또는 온 디바이스(on-device) 기능을 제공할 수도 있다. 특히, 몇몇 서브시스템, 예컨대 키보드(2032) 및 디스플레이(2022)는, 예를 들면, 통신 네트워크를 통한 송신을 위해 텍스트 메시지를 입력하는 것과 같은 통신 관련 기능, 및 계산기 또는 작업 목록과 같은 디바이스 상주 기능 둘 모두에 대해 사용될 수도 있다.

프로세서(2038)에 의해 사용되는 오퍼레이팅 시스템 소프트웨어는, 대신, 판독 전용 메모리(ROM) 또는 유사한 저장 엘리먼트(도시되지 않음)일 수도 있는 플래시 메모리(2024)와 같은 영구적 저장소에 저장될 수도 있다. 기술 분야의 숙련된 자는, 오퍼레이팅 시스템, 특정한 디바이스 애플리케이션, 또는 그 일부가 RAM(2026)과 같은 휘발성 메모리에 일시적으로 로딩될 수도 있다는 것을 인식할 것이다. 수신된 통신 신호는 RAM(2026)에 또한 저장될 수도 있다.

도시되는 바와 같이, 플래시 메모리(2024)는 컴퓨터 프로그램(2058) 및 프로그램 데이터 저장소(2050, 2052, 2054 및 2056) 둘 모두에 대해 상이한 영역으로 분리될 수 있다. 이들 상이한 저장소 타입은, 각각의 프로그램이 그들 자신의 데이터 저장 요건을 위해 플래시 메모리(2024)의 일부를 할당할 수 있다는 것을 나타낸다. 프로세서(2038)는, 자신의 오퍼레이팅 시스템 기능에 추가하여, UE 상의 소프트웨어 애플리케이션의 실행을 가능하게 할 수도 있다. 예를 들면, 적어도 데이터 및 음성 통신 애플리케이션을 비롯한, 기본 동작을 제어하는 애플리케이션의 미리 결정된 세트는, 일반적으로, 제조 동안 UE(2000) 상에 설치될 것이다. 다른 애플리케이션이 후속하여 또는 동적으로 설치될 수 있을 것이다.

애플리케이션 및 소프트웨어는 임의의 컴퓨터 판독 가능 저장 매체 상에 저장될 수도 있다. 컴퓨터 판독 가능 저장 매체는, 유형의 또는 일시적/비일시적 매체 예컨대 광학적(예를 들면 CD, DVD 등등), 자기적(예를 들면, 테이프) 또는 기술 분야에서 공지된 다른 메모리일 수도 있다.

하나의 소프트웨어 애플리케이션은, 전자 메일, 캘린더 이벤트, 음성 메일, 약속, 및 작업 항목과 같은 그러나 이들로 제한되지는 않는, UE의 유저에 관련이 있는 데이터 항목을 편제 및 관리하는 능력을 갖는 개인 정보 매니저(personal information manager; PIM) 애플리케이션일 수도 있다. 당연히, PIM 데이터 항목의 저장을 용이하게 하기 위해 하나 이상의 메모리 저장소가 UE 상에서 이용 가능할 것이다. 이러한 PIM 애플리케이션은, 무선 네트워크(2019)를 통해, 데이터 아이템을 전송 및 수신하는 능력을 가질 수도 있다. 또한, 추가적인 애플리케이션이 네트워크(2019), 보조 I/O 서브시스템(2028), 직렬 포트(2030), 근거리 통신 서브시스템(2040) 또는 임의의 다른 적절한 서브시스템(2042)을 통해 UE(2000) 상으로 로딩될 수도 있으며, 프로세서(2038)에 의한 실행을 위해 RAM(2026) 또는 불휘발성 저장소(도시되지 않음)에 유저에 의해 설치될 수도 있다. 애플리케이션 설치에서의 이러한 유연성은 디바이스의 기능성을 증가시키고 향상된 온 디바이스 기능, 통신 관련 기능, 또는 둘 모두를 제공할 수도 있다. 예를 들면, 보안 통신 애플리케이션은 전자 상거래 기능 및 다른 이러한 금융 트랜잭션이 UE(2000)를 사용하여 수행되는 것을 가능하게 할 수도 있다.

데이터 통신 모드에서, 텍스트 메시지 또는 웹 페이지 다운로드와 같은 수신된 신호는 통신 서브시스템(2011)에 의해 프로세싱될 것이고 프로세서(2038)에 입력될 것인데, 프로세서(2038)는 수신된 신호를 디스플레이(2022)로의, 또는 대안적으로 보조 I/O 디바이스(2028)로의 출력을 위해 추가로 프로세싱할 수도 있다.

또한, UE(2000)의 유저는, 디스플레이(2022) 및 어쩌면 보조 I/O 디바이스(2028)와 연계하여, 다른 것들 중에서도, 완전한 영숫자 키보드 또는 전화 타입 키패드일 수도 있는 키보드(2032)를 사용하여, 예를 들면 이메일 메시지와 같은 데이터 항목을 작성할 수도 있다. 그 다음, 이렇게 작성된 항목은 통신 서브시스템(2011)을 통해 통신 네트워크를 통해 송신될 수도 있다.

음성 통신의 경우, UE(2000)의 전체적인 동작은, 수신된 신호가 통상적으로 스피커(2034)로 출력될 것이고 송신을 위한 신호가 마이크(2036)에 의해 생성될 것이다는 점을 제외하면, 유사하다. 음성 메시지 기록 서브시스템과 같은 대안적인 음성 또는 오디오 I/O 서브시스템도 또한 UE(2000) 상에 구현될 수도 있다. 비록 음성 또는 오디오 신호 출력이 일반적으로 주로 스피커(2034)를 통해 달성되지만, 예를 들면, 발신자의 아이덴티티, 음성 호의 지속 기간, 또는 다른 음성 호 관련 정보의 표시를 제공하기 위해 디스플레이(2022)가 또한 사용될 수도 있다.

도 20의 직렬 포트(2030)는 일반적으로, 유저의 데스크탑 컴퓨터(도시되지 않음)와의 동기화가 바람직할 수도 있는 개인 휴대형 정보 단말(personal digital assistant; PDA) 타입의 UE에서 구현될 것이지만, 그러나 옵션적인 디바이스 컴포넌트이다. 이러한 포트(2030)는 유저가 외부 디바이스 또는 소프트웨어 애플리케이션을 통해 선호도를 설정하는 것을 가능하게 할 것이고 무선 통신 네트워크를 통하는 대신 UE(2000)에 정보 또는 소프트웨어 다운로드를 제공하는 것에 의해 UE(2000)의 성능을 확장시킬 것이다. 대안적인 다운로드 경로는, 예를 들면, 직접적이고 따라서 확실하고 신뢰된 연결을 통해 디바이스 상으로 암호화 키를 로딩하고 그에 의해 보안 디바이스 통신을 가능하게 하도록 사용될 수도 있다. 기술 분야의 숙련된 자에 의해 인식되는 바와 같이, 직렬 포트(2030)는 또한, 모뎀으로서 작용하는 컴퓨터에 UE를 연결하도록 사용될 수 있다.

단거리 통신 서브시스템과 같은 다른 통신 서브시스템(2040)은, UE(2000)와 상이한 시스템 또는 디바이스(반드시 유사한 디바이스일 필요는 없음) 사이의 통신을 제공할 수도 있는 추가적인 옵션적 컴포넌트이다. 예를 들면, 서브시스템(2040)은, 유사하게 인에이블된 시스템 및 디바이스와의 통신을 제공하기 위해, 적외선 디바이스 및 관련 회로 및 컴포넌트 또는 Bluetooth™ 통신 모듈을 포함할 수도 있다. 서브시스템(2040)은 WiFi 또는 WiMAX와 같은 비 셀룰러 통신을 더 포함할 수도 있다.

본원에서 설명되는 실시형태는, 본 출원의 기술의 엘리먼트에 대응하는 엘리먼트를 갖는 구조, 시스템 또는 방법의 예이다. 이 서술된 설명은, 기술 분야의 숙련된 자가, 본 출원의 기술의 엘리먼트에 마찬가지로 대응하는 대안적 엘리먼트를 구비하는 실시형태를 만들고 사용하는 것을 가능하게 할 수도 있다. 따라서, 본 출원의 기술의 의도된 범위는, 본원에서 설명되는 바와 같은 본 출원의 기술과는 상이하지 않은 다른 구조, 시스템 또는 방법을 포함하며, 본원에서 설명되는 바와 같은 본 출원의 기술과는 실질적이지 않은 차이를 갖는 다른 구조, 시스템 또는 방법을 더 포함한다.

도 21은, 한 구현예에 따른, 예시적인 MCPTT 시스템(2100)의 애플리케이션 레이어 아키텍쳐를 예시하는 개략도이다.

MCPTT 유저 아이덴티티는 또한 MCPTT ID로서 알려져 있다. MCPTT ID는 MCPTT 유저를 나타내는 MCPTT 서비스 내에서 전역으로 고유한 식별자이다. MCPTT ID는 MCPTT 유저를 식별한다. MCPTT ID는 MCPTT 시스템에 대해 MCPTT ID가 정의되는 곳이 MCPTT 애플리케이션 레이어의 유저에 대한 MCPTT 프로파일을 또한 식별할 수도 있다는 것을 나타낸다.

MCPTT 서비스의 인간 유저에 관련되는 MCPTT 서비스 내에 구성되는 MCPTT ID와 관련되는 속성이 있다. 이 정보는, 이름 또는 역할별로, MCPTT 유저를 식별할 수도 있고, 유저의 조직 또는 기관을 또한 식별할 수도 있다. MCPTT ID와 관련되는 이러한 속성은, 유저에게 허여되는 MCPTT 서비스에 대한 인가 결정을 행하기 위해 MCPTT 서버에 의해 사용될 수 있다. 예를 들면, 사고 지휘관(incident commander)으로서의 유저의 역할을 식별하는 속성이 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 그룹이 정의되는 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), 및 레거시 시스템에 대한 연동 기능(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 control entity)를 관리하는 것; 및

- 호, 즉 회의, 트랜스코딩에서 미디어 핸들링 엔티티를 관리하는 것.

참여 역할을 수행하는 MCPTT 서버는 다음 기능성을 담당할 수 있다:

- 그룹 호 및 개인 호에 대한 자신의 MCPTT 유저에 대한 호 제어(예를 들면, MCPTT 그룹 호에 참여하기 위한 정책 집행);

- 유저에 의한 최대 N2 개수의 동시적 그룹 가입의 시행을 비롯한, MCPTT 유저에 대한 그룹 가입 지원;

- 제어 역할을 수행하는 MCPTT 서버와 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 UE(2140) 내에 위치할 수 있다.

MCPTT UE(2140)는 MCPTT 호에 참여하는 UE이다. MCPTT UE(2140)는, MCPTT 클라이언트(2150), 그룹 관리 클라이언트(2162), 구성 관리 클라이언트(2164), 아이덴티티 관리 클라이언트(2166), 키 관리 클라이언트(2168)를 포함한다.

MCPTT 클라이언트(2150)는, MCPTT 애플리케이션 트랜잭션을 위한 유저 에이전트로서 구성될 수 있는 애플리케이션, 애플리케이션의 세트, 소프트웨어, 소프트웨어 모듈, 하드웨어, 또는 이들의 조합을 나타낸다. MCPTT 클라이언트(2150)는, MCPTT 클라이언트(2150)가 현재 위치하는 곳의 정보를 보고할 수 있다. MCPTT 클라이언트(2150)는 미디어 믹서(2152) 및 플로어 참가자(2154)를 포함한다.

미디어 믹서(2152)는, 미디어 정책 정보의 시행을 통해 다수의 미디어 스트림을 하나의 미디어 스트림으로 결합하기 위한 지원을 제공하도록 구성될 수 있는 애플리케이션, 애플리케이션의 세트, 소프트웨어, 소프트웨어 모듈, 하드웨어, 또는 이들의 조합을 나타낸다.

플로어 참가자(2154)는, 플로어 요청을 핸들링하도록 구성될 수 있는 애플리케이션, 애플리케이션의 세트, 소프트웨어, 소프트웨어 모듈, 하드웨어, 또는 이들의 조합을 나타낸다. 층 참가자(2154)는 온 네트워크 및 오프 네트워크 동작 둘 모두를 위해 MCPTT UE(2140) 내에 위치할 수 있다.

그룹 관리 클라이언트(2162)는, MCPTT 그룹의 관리를 위해 애플리케이션 유저 에이전트로서 구성될 수 있는 애플리케이션, 애플리케이션의 세트, 소프트웨어, 소프트웨어 모듈, 하드웨어, 또는 이들의 조합을 나타낸다. 그룹 관리 클라이언트(2162)는 그룹 관리 서버(2122)와 상호 작용한다. 그룹 관리 클라이언트(2162)는 시그널링 제어 플레인의 시그널링 유저 에이전트 및 HTTP 클라이언트 기능 엔티티에 의해 지원될 수 있다.

구성 관리 클라이언트(2164)는, 구성 관련 트랜잭션을 위한 애플리케이션 유저 에이전트로서 구성될 수 있는 애플리케이션, 애플리케이션의 세트, 소프트웨어, 소프트웨어 모듈, 하드웨어, 또는 이들의 조합을 나타낸다. 구성 관리 클라이언트(2164)는, 구성 데이터를 제공 및 수신하기 위해 구성 관리 서버(2124)와 상호 작용한다. 구성 관리 클라이언트(2164)는 시그널링 제어 플레인의 시그널링 유저 에이전트 및 HTTP 클라이언트 기능 엔티티에 의해 지원될 수 있다.

아이덴티티 관리 클라이언트(2166)는, MCPTT 호에 대한 유저 ID 트랜잭션을 위한 애플리케이션 유저 에이전트로서 구성될 수 있는 애플리케이션, 애플리케이션의 세트, 소프트웨어, 소프트웨어 모듈, 하드웨어, 또는 이들의 조합을 나타낸다. 아이덴티티 관리 클라이언트(2166)는 아이덴티티 관리 서버(2126)와 상호 작용한다.

키 관리 클라이언트(2168)는, 키 관리 기능을 위한 애플리케이션 유저 에이전트로서 구성될 수 있는 애플리케이션, 애플리케이션의 세트, 소프트웨어, 소프트웨어 모듈, 하드웨어, 또는 이들의 조합을 나타낸다. 그것은 키 관리 서버(2128)와 상호 작용한다. 키 관리 클라이언트(2168) 및 키 관리 서버(2128)의 기능성은 3GPP TS 33.179에서 명시되는 기능성을 포함할 수 있다.

일반적인 설명으로 돌아가면, UE, 예를 들면, MCPTT UE(2140)는, 제한 없이, 다음의 것 중 임의의 것을 포함할 수도 있다: 컴퓨팅 디바이스, 모바일 디바이스, 모바일 전자 디바이스, 유저 디바이스, 이동국, 가입자 스테이션, 휴대용 전자 디바이스, 이동 통신 디바이스, 무선 모뎀, 무선 단말, 텔레비젼, 프린터 또는 다른 주변장치, 차량, 또는 데이터를 전송 및 수신할 수 있는 임의의 다른 전자 디바이스. 모바일 디바이스의 예는, 무선 통신 네트워크를 통해 음성 또는 데이터를 통신하기 위한 컴포넌트를 구비하는, 셀룰러 폰, 개인 휴대형 정보 단말(PDA), 스마트 폰, 랩탑, 태블릿 퍼스널 컴퓨터(personal computer; PC), 페이저, 휴대형 컴퓨터, 휴대형 게임용 디바이스, 웨어러블 전자 디바이스, 헬스/의료/피트니스 디바이스, 카메라, 또는 다른 모바일 통신 디바이스를, 제한 없이, 포함할 수도 있다. 무선 통신 네트워크는 인가된 스펙트럼 및 라이센스 불요 스펙트럼(unlicensed spectrum) 중 적어도 하나를 통한 무선 링크를 포함할 수도 있다. 용어 "모바일 디바이스"는 또한, 유저에 대한 통신 세션을 종료할 수 있는 임의의 하드웨어 또는 소프트웨어 컴포넌트를 가리킬 수 있다. 또한, 용어 "유저 기기", "UE", "유저 기기 디바이스", "유저 에이전트", "UA", "유저 디바이스" 및 "모바일 디바이스"는 본원에서 같은 뜻으로 사용될 수 있다.

MCPTT 유저 데이터베이스(2104)는, 애플리케이션 플레인에서 MCPTT 서비스 공급자에 의해 보유되는 MCPTT ID와 관련되는 유저 구성 정보의 정보를 저장하도록 구성될 수 있는 애플리케이션, 애플리케이션의 세트, 소프트웨어, 소프트웨어 모듈, 하드웨어, 또는 이들의 조합을 나타낸다. 유저 구성 정보는 MCPTT 서비스 공급자에 의해 결정될 수 있다.

다른 MCPTT 서버(2102)는 MCPTT 서버(2110)와 상호 작용하는 하나 이상의 MCPTT 서버를 나타낸다. 마찬가지로, 다른 그룹 관리 서버(2108)는 그룹 관리 서버(2122)와 상호 작용하는 하나 이상의 그룹 관리 서버를 나타낸다. 연동 기능 레거시 시스템(2106)은, MCPTT 시스템(2100)과 레거시 시스템 사이의 연동 기능을 제공하는 애플리케이션, 애플리케이션의 세트, 소프트웨어, 소프트웨어 모듈, 하드웨어, 또는 이들의 조합을 나타낸다.

EPS(2130)는 3GPP E-UTRAN 네트워크의 핵심 네트워크 기능성을 수행하는 네트워크 노드를 나타낸다. 애플리케이션 레이어에서, EPS(2130)는, MCPTT 서비스를 제공하는 애플리케이션 서버와 MCPTT UE(2140) 사이의 연결을 제공한다.

동작에서, MCPTT UE(2140)의 아이덴티티 관리 클라이언트(2166)는, 아이덴티티 관리 서버를 사용하여 네트워크에서의 MCPTT 유저 아이덴티티 A를 인증한다. 그 다음, 구성 관리 클라이언트(2164)는 구성 관리 서버(2124)와의 보안(HTTPS/TLS) 통신을 확립한다. 구성 관리 클라이언트(2164)는 MCPTT 유저 데이터베이스(2104)로부터 (구성 관리 서버(2124)를 사용하여) MCPTT 유저 프로파일을 다운로드한다. MCPTT 유저 프로파일은, 유저가 연락할 수 있는 모든 유저의 MCPTT ID 및 또한 유저가 연락할 수 있는 그룹에 대한 모든 MCPTT 그룹 ID의 연락처 목록을 포함할 수 있다. MCPTT 유저 프로파일은 또한 유저 프로파일을 다운로드하는 UE의 유저의 MCPTT ID를 포함한다. 대안적으로, 유저 프로파일은, 연락될 수 있는 MCPTT 유저의 MCPTT ID를 포함하는 주소록 또는 네트워크 연락처 목록에 대한 하나 이상의 포인터 또는 레퍼런스를 포함할 수 있다. 이들 연락처 목록은 유저 프로파일을 사용하는 MCPTT 유저의 역할(예를 들면, 최초 대처자)에 기초할 수 있다. 유저 프로파일, 또는 다른 프로파일은, 암호화 키뿐만 아니라, MCPTT UE(2140)에 의해 사용될 수 있는 서비스의 설명을 포함할 수 있다. MCPTT 유저 프로파일은 XML 문서이며 HTTPS를 사용하여 다운로드된다. 따라서, 그것은 TLS를 사용하여 암호화될 수 있고, MCPTT UE(2140)로 전달될 때 PLMN 오퍼레이터에 의해 판독될 수 없을 수도 있다.

도 21의 엘리먼트가, 다양한 피쳐 및 기능성을 구현하는 다양한 컴포넌트 부품, 부분, 또는 모듈을 포함하는 것으로 도시되지만, 그럼에도 불구하고, 이들 엘리먼트는, 대신, 적절히, 다수의 서브 모듈, 써드파티(third-party) 서비스, 컴포넌트, 라이브러리, 및 등등을 포함할 수도 있다. 또한, 다양한 컴포넌트의 피쳐 및 기능성은, 적절히, 더 적은 수의 컴포넌트로 결합될 수 있다. 예를 들면, 도 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 유저 토큰은 MCPTT 유저 인증 단계 동안 아이덴티티 관리 서버에 의해 UE로 할당된다. OpenID 프레임워크에서 사용되는 MCPTTUser 토큰은 2 개의 토큰을 포함할 수 있다: access_token 및 ID_token. 이들 토큰은 OAuth 2.0 프로토콜을 사용하여 요청될 수 있다. 도 25는, 한 구현예에 따른, 토큰을 획득하기 위한 예시적인 프로세스(2500)를 예시한다. 예시되는 바와 같이, 단계 7에서, 아이덴티티 관리자 서버는 access_token 및 ID_token을 UE로 반송한다. 도 26은, 한 구현예에 따른, 토큰을 획득하기 위한 예시적인 코드(2602 및 2604)를 예시한다. 예시적인 코드(2602)는, 문자의 스트링인 access_token을 포함하는 메시지를 도시한다. id_token은 또한, 문자의 문자열로도 나타난다. id_token 및 access_token은, JSON 속성으로 또한 알려져 있는 JSON 클레임(JSON claim)을 사용하여 토큰이 설명되는 OPenID 연결 프레임 워크의 일부이다. 표준 클레임은, 예를 들면, http://www.iana.org/assignments/jwt/jwt.xhtml에서 발견될 수 있다.

id_token은 아이덴티티 카드의 개념과 유사하며 JWT 프로파일에서 설명된다. 그것은, 유저를 식별하는 속성, 예를 들면, 이름, 주소, 전화 번호, 등등을 포함한다. 예시적인 코드(2604)는 id_token에 대한 30 개의 예시적인 JSON 클레임 스키마를 예시한다. id_token은 영숫자 문자열로서 코딩된다. 당사자(party) 사이에서 토큰이 요청, 암호화 및 교환될 수 있는 방법에 대한 더욱 상세한 설명은, 예를 들면, http://openid.net/specs/openid-connect-core-1_0.html#CodeFlowAuth에서 발견될 수 있다.

도 22로 돌아가서, 단계 1에서, MCPTT UEa(2204)는 MCPTT UEa(2204)를 인증하라는 요청을 아이덴티티 관리 서버(2214)로 전송한다. 요청은 MCPTT UEa(2204)에 대한 MCPTT 유저 아이덴티티 A를 포함할 수 있다.

아이덴티티 관리 서버(2214)는 MCPTT 유저 아이덴티티 A를 인증한다. 인증은 도 25에서 설명되는 프로세스를 사용하여 수행될 수 있다. 아이덴티티 관리 서버(2214)는, 옵션적으로, 단계 1a에서, MCPTT 유저 아이덴티티, 제2 IMS 공개 유저 아이덴티티 A, 및 하나 이상의 토큰, 예를 들면, access_token, id_token 중 적어도 하나를 MCPTT 유저 데이터베이스로 전송한다.

하나 이상의 토큰은 다음 속성 중 임의의 것을 포함할 수 있다:

- 네트워크로부터의 유저 프로파일에서의 제2 IMS 공개 유저 아이덴티티 A(IMPU2a)

- 제2 IMS 개인 유저 아이덴티티 A(IMPI2a)

- MCPTT 유저 아이덴티티

- 키

- 벡터

- MCPTT 유저 프로파일(들)의 위치에 대한 URI(들)

이들 상기 속성은 JSON 클레임으로서 인코딩될 수 있을 것이다. MCPTT 유저 아이덴티티 A와 제2 IMS 공개 유저 아이덴티티 A(IMPU2a), 제2 IMS 개인 유저 아이덴티티 A(IMPI2a), 및 토큰, 예를 들면, access_token, id_token 사이의 관계가 생성되어 MPCTT 아이덴티티 관리 서버(2214)에 저장된다.

MCPTT 유저 데이터베이스(2216)는 옵션적으로, MCPTT 유저 아이덴티티 A, 제2 IMS 공개 유저 아이덴티티 A, IMS 개인 유저 아이덴티티 A 및 하나 이상의 토큰 중 적어도 하나를 수신한다.

- 제2 IMS 공개 유저 아이덴티티 A(IMPU2a)

- 제2 IMS 개인 유저 아이덴티티 A(IMPI2a)

- MCPTT 유저 아이덴티티

- 키

- 벡터

- MCPTT 유저 프로파일(들)의 위치에 대한 URI(들)

MCPTT 유저 데이터베이스(2216)는, MCPTT 유저 아이덴티티 A를 포함하는 유저 프로파일을 업데이트하고 단계 1에서 수신되는 데이터, 예를 들면, 제2 IMS 공개 유저 아이덴티티 A, IMS 개인 유저 아이덴티티 A 및 토큰(들)과의 관계를 생성한다. MCPTT 유저 데이터베이스(2216)는 토큰의 속성 중 일부, 예를 들면, MCPTT 유저 아이덴티티 A와 관련되는 유저 프로파일(들)의 URI를 포함하는 메시지로 아이덴티티 관리 서버(2214)에 다시 응답할 수도 있다. 이것은 아이덴티티 관리 서버(2214)가 URI를 MCPTT UEa(2204)에 전송하는 것을 가능하게 할 수도 있다.

단계 1b에서, 아이덴티티 관리 서버(2214)는 ack를 MCPTT UEa에 전송한다. ack는 다음 중 적어도 하나를 포함할 수 있다: 제2 IMS 공개 유저 아이덴티티 A(IMPU2a), 하나 이상의 토큰, 예를 들면, access_token, id_token.

하나 이상의 토큰은 다음의 속성 중 임의의 것을 포함할 수 있다:

- 제2 IMS 공개 유저 아이덴티티 A(IMPU2a)

- 제2 IMS 개인 유저 아이덴티티 A(IMPI2a)

- MCPTT 유저 아이덴티티

- 키

- 벡터

- MCPTT 유저 프로파일(들)의 위치에 대한 URI(들)

이들 상기 속성은 JavaScript Object Notation(JSON) 클레임으로서 인코딩될 수 있다. 이들은 모바일 기기(mobile equipment; ME) 또는 MCPTT UEa(2204)의 범용 집적 회로 카드(UICC) 중 어느 하나에서 수신될 때 메모리에 저장될 수 있다.

단계 2에서, MCPTT UEb(2202)는 아이덴티티 관리 서버(2214)에서 인증한다. 단계 1과 유사하게, MCPTT UEb(2202)는 아이덴티티 관리 서버(2214)에 요청을 전송할 수 있다. 요청은 MCPTT UEb(2202)에 대한 MCPTT 유저 아이덴티티 B를 포함할 수 있다. 아이덴티티 관리 서버(2214)는 MCPTT 유저 아이덴티티 B를 인증할 수 있고, Ack를 MCPTT UEb(2202)에 전송할 수 있다. ack는 제2 IMS 공개 유저 아이덴티티 B, 및 하나 이상의 토큰, 예를 들면, access_token, id_token 중 적어도 하나를 포함할 수 있다.

- 제2 IMS 공개 유저 아이덴티티 B(IMPU2b)

- 제2 IMS 개인 유저 아이덴티티 B(IMPI2b)

- MCPTT 유저 아이덴티티

- 키

- 벡터

- MCPTT 유저 프로파일(들)의 위치에 대한 URI(들)

아이덴티티 관리 서버(2214), MCPTT 유저 데이터베이스(2216), 또는 이들의 조합은, MCPTT 유저 아이덴티티 B와 제2 IMS 공개 유저 아이덴티티 B, 제2 IMS 개인 유저 아이덴티티 B, 및 하나 이상의 토큰 사이의 관계를 저장할 수 있다.

몇몇 경우에, 단계 2는 다른 네트워크 노드 또는 UE로부터 개시될 수 있다. 단계 2는, 단계 11과 관련하여 논의되는 바와 같이, 유저 프로파일의 변경에 대한 통지에 대한 요청을 수신하는 단계의 일부로서 또한 포함될 수도 있다.

단계 3에서, MCPTT UEa(2204)는 네트워크로부터 유저 프로파일(들)을 획득한다. 몇몇 경우에, 유저 프로파일(들)의 위치는, 앞서 논의되는 바와 같이, MCPTT UEa(2204)의 ME 및 UICC에 저장될 수도 있거나 또는 미리 프로비저닝될 수도 있거나, 또는 단계 1b에서 수신될 수도 있다. MCPTT UEa(2204)는 다음의 정보 중 하나를 수신할 수 있다:

- 제2 IMS 개인 유저 아이덴티티 A(IMPI2a)

- 키 값

- 벡터 값

- MCPTT 유저 아이덴티티

몇몇 경우에, 유저 프로파일은 ME 또는 UICC 중 어느 하나의 메모리에 저장된다. 유저 프로파일은, MCPTT 유저 아이덴티티가 로그 아웃되거나, MCPTT 유저 아이덴티티 C가 인증되거나, 또는 이들의 조합인 경우에, 삭제 또는 수정될 수도 있다.

단계 4에서, MCPTT UEb(2202)는 네트워크로부터 유저 프로파일(들)을 획득한다. 몇몇 경우에, 유저 프로파일(들)의 위치는, 앞서 논의되는 바와 같이, MCPTT UEb(2202)의 ME 및 UICC에 저장될 수도 있거나 또는 미리 프로비저닝될 수도 있거나, 또는 단계 2에서 수신될 수도 있다. MCPTT UEb(2202)는 다음의 정보 중 하나를 수신할 수 있다:

- 네트워크로부터의 유저 프로파일에서의 제2 IMS 공개 유저 아이덴티티 B(IMPU2b)

- 제2 IMS 개인 유저 아이덴티티 B(IMPI2b)

- 키 값

- 벡터 값

- MCPTT 유저 아이덴티티

단계 5에서, MCPTT UEa(2204)는 IMPU2a를 사용하여 SIP 코어(2210)에 등록한다. MCPTT UEa(2204)는 또한, 토큰, 예를 들면, access_token을 SIP 코어(2210)로 전송할 수 있다. 단계 5a에서, SIP 코어(2210)는 MCPTT 서버(2218)와의 제3자 등록 절차를 수행한다.

단계 6에서, MCPTT UEb(2202)는 IMPU2b를 사용하여 SIP 코어(2210)에 등록한다. MCPTT UEb(2202)는 또한, 토큰, 예를 들면, access_token을 SIP 코어(2210)로 전송할 수 있다. 단계 5a에서, SIP 코어(2210)는 MCPTT 서버(2218)와의 제3자 등록 절차를 수행한다.

단계 7에서, MCPTT 서버(2218)는 제2 IMS 공개 유저 아이덴티티 A 및 토큰, 예를 들면, access_token, id_token 중 적어도 하나와 관련되는 MCPTT 유저 아이덴티티 A를 요청하기 위한 메시지를 전송한다. 아이덴티티 관리 서버(2214)는 제2 IMS 공개 유저 아이덴티티 A 또는 토큰과 관련되는 MCPTT 유저 아이덴티티 A를 결정한다. 아이덴티티 관리 서버(2214)는 결정된 MCPTT 유저 아이덴티티 A를 포함하는 메시지를 MCPTT 서버(2218)로 전송한다.

마찬가지로, 단계 8에서, MCPTT 서버(2218)는, 제2 IMS 공개 유저 아이덴티티 B 및 토큰, 예를 들면, access_token, id_token 중 적어도 하나와 관련되는 MCPTT 유저 아이덴티티 B를 요청하기 위한 메시지를 전송한다. 아이덴티티 관리 서버(2214)는 제2 IMS 공개 유저 아이덴티티 A 또는 토큰과 관련되는 MCPTT 유저 아이덴티티 A를 결정한다. 아이덴티티 관리 서버(2214)는 결정된 MCPTT 유저 아이덴티티 A를 포함하는 메시지를 MCPTT 서버(2218)로 전송한다.

단계 9에서, MCPTT 서버(2218)는, MCPTT 유저 아이덴티티 A, 제2 IMS 공개 유저 아이덴티티 A 또는 하나 이상의 토큰, 예를 들면, access_token, id_token 중 적어도 하나와 관련되는 유저 프로파일을 요청하기 위한 메시지를 전송한다. MCPTT 유저 데이터베이스(2216)는, MCPTT 유저 아이덴티티 A, 제2 IMS 공개 유저 아이덴티티 A, 또는 하나 이상의 토큰과 관련되는 유저 프로파일을 MCPTT 서버(2218)로 전송한다. 유저 프로파일은, 키 값, 벡터 값, MCPTT 유저 아이덴티티, 또는 이들의 임의의 조합을 포함할 수도 있다.

단계 10에서, MCPTT 서버(2218)는, MCPTT 유저 아이덴티티 B, 제2 IMS 공개 유저 아이덴티티 B 또는 하나 이상의 토큰, 예를 들면, access_token, id_token 중 적어도 하나와 관련되는 유저 프로파일을 요청하기 위한 메시지를 전송한다. MCPTT 유저 데이터베이스(2216)는, MCPTT 유저 아이덴티티 B, 제2 IMS 공개 유저 아이덴티티 B, 또는 하나 이상의 토큰과 관련되는 유저 프로파일을 MCPTT 서버(2218)로 전송한다. 유저 프로파일은, 키 값, 벡터 값, MCPTT 유저 아이덴티티, 또는 이들의 임의의 조합을 포함할 수도 있다.

단계 11에서, MCPTT UEa(2204)는 유저 프로파일에 대한 변경의 통지를 요청한다. 몇몇 경우에, 이 단계는 단계 2 이전에 발생할 수도 있으며, MCPTT UE(2204)가 통지를 요청하는 유저 프로파일을 메모리에서 갖지 않기 때문에, 단계 2를 발생시킬 수도 있을 것이다. 단계 12에서, MCPTT UEb(2202)는 유저 프로파일에 대한 변경의 통지를 요청한다.

단계 13에서, MCPTT 유저 아이덴티티 A를 갖는 MCPTT 유저는, MCPTT 유저 아이덴티티 B를 갖는 MCPTT 유저와의 통신을 모방한다. MCPTT UEa(2204)는 메모리 내에서 어떤 유저 프로파일이 MCPTT 유저 아이덴티티 B를 포함하는지를 결정한다. 결정하는 단계에서, UE는 또한 이 유저 프로파일과 관련되는 레퍼런스 또는 포인터를 결정한다. MCPTT UEa(2204)는, 어떤 유저 프로파일을 사용할지에 대한 레퍼런스 또는 포인터를 포함하는 메시지를 네트워크로 전송한다. 레퍼런스 또는 포인트는, MCPTT 유저 아이덴티티 B를 나타내는, 유저 프로파일에서의 엔트리, 예를 들면, 위치(30)에 대한 레퍼런스, 포인터, 또는 위치 및 전역적 전화 번호부를 나타낼 수도 있다. 몇몇 경우에, 엔트리 위치는 암호화될 수도 있다. 몇몇 경우에, 암호화된 엔트리 위치는 오프셋을 포함할 수도 있다. 메시지는 또한 제2 IMS 공개 유저 아이덴티티 A(IMPU2a)를 포함할 수 있다.

단계 13a에서, MCPTT 서버(2218)는 유저 프로파일에 대한 레퍼런스 또는 포인터를 포함하는 제2 IMS 공개 유저 아이덴티티 A로부터 메시지를 수신한다. 메시지는 또한 제2 IMS 공개 유저 아이덴티티 A(IMPU2a)를 포함할 수도 있다.

오프셋 값이 메시지에서 수신되면, MCPTT 서버(2218)는 엔트리 위치가 암호화되어 있다는 것을 결정할 수도 있다. MCPTT 서버(2218)는 "키" 및 "벡터"를 사용하여 암호 해제를 수행하고 엔트리 위치를 획득할 수도 있다.

몇몇 경우에, MCPTT 유저 아이덴티티 A가 통신하기를 원하는 MCPTT 유저 아이덴티티 B를 결정하기 위해, 다음의 단계 a) 내지 e)가 사용될 수도 있다. 일단 MCPTT 유저 아이덴티티 B가 발견되면, MCPTT 유저 아이덴티티 A는 동일한 프로세스를 역으로 사용하는 것에 의해 PLMN 오퍼레이터에게 숨겨질 수도 있다. 이들 경우에, SIP 메시지가 MCPTT 유저 아이덴티티 B로 전송되면, MCPTT 유저 아이덴티티 A도 MCPTT 유저 아이덴티티 B도 노출되지 않는다. 따라서, IMS 공개 유저 아이덴티티 B는 발견될 수 있고, MCPTT 유저 아이덴티티 A가 참조될 수 있도록 MCPTT 유저 아이덴티티 B에 속하는 유저 프로파일이 사용될 수 있다.

a) MCPTT 서버(2218)는, 어떤 MCPTT 유저 아이덴티티 A를 그리고 그 프로파일 내에서 어떤 데이터를 사용할지를 결정한다. MCPTT 서버(2218)는 단계 6에서 수신되는 제2 IMS 공개 유저 아이덴티티 A를 사용하는 것에 의해 그리고 어떤 MCPTT 유저 아이덴티티로 매핑할지를 결정하는 것에 의해 MCPTT 유저 아이덴티티 A를 결정할 수 있다. 매핑은 단계 3 또는 단계 5로서 수행될 수도 있다.

b) 일단 MCPTT 유저 아이덴티티 B가 단계 a)를 사용하여 획득되면, MCPTT 서버(2218)는 MCPTT 유저 아이덴티티 B와 관련되는 제2 IMS 공개 유저 아이덴티티 B를 결정할 수 있다. 제2 IMS 공개 유저 아이덴티티 B와 MCPTT 유저 아이덴티티 B 사이의 매핑은 단계 1에서 수행될 수도 있다.

c) MCPTT 서버(2218)는 어떤 유저 프로파일이 MCPTT 유저 아이덴티티 B와 관련되는지를 결정한다.

d) MCPTT 서버(2218)는 어떤 MCPTT 유저 아이덴티티 B 유저 프로파일이 MCPTT 유저 아이덴티티 A를 포함하는지를 결정한다. MCPTT 서버(2218)는 MCPTT 유저 아이덴티티 B 유저 프로파일 내의 위치를 결정한다.

e) MCPTT 서버(2218)는 제2 IMS 공개 유저 아이덴티티 B와 관련되는 MCPTT 유저 아이덴티티 B를 결정한다.

단계 14에서, MCPTT 서버(2218)는 SIP 코어(2210)로 메시지를 전송한다. 단계 14a에서, SIP 코어(2210)는 메시지를 MCPTT UEb(2202)로 포워딩한다. 메시지는, MCPTT 유저 아이덴티티 A에 대한 엔트리 위치 및 MCPTT 유저 B 유저 프로파일에 대한 레퍼런스 또는 포인터를 포함한다.

몇몇 경우에, MCPTT 서버(2218)는 엔트리 위치를 암호화할 수도 있다. 예를 들면, MCPTT 서버(2218)는 "시드 값" 및 "카운터"를 사용하여 메시지에 포함될 오프셋을 생성할 수 있다. "시드 값" 및 "카운터"는 유저 프로파일을 획득하는 기능의 일부로서 획득될 수도 있다.

도 23은, 한 구현예에 따른, 암호화 및 암호 해제를 위한 예시적인 프레임워크(2300)를 예시한다. 예시되는 바와 같이, 예시적인 프레임워크(2300)는 ME(2302) 및 네트워크 노드(2304)를 사용하여 구현될 수 있다. ME(2302)는 MCPTT UE의 ME일 수도 있다. 네트워크 노드는, MCPTT 기능성, 예를 들면, MCPTT 서버를 수행하는 네트워크 노드일 수도 있다. 프레임워크(2300)는 또한, 추가적인, 더 적은, 또는 상이한 엔티티를 사용하여 구현될 수 있다.

프레임워크(2300)는 또한, 도시되는 순서로 또는 상이한 순서로 수행될 수 있는, 예시되는 바와 같은 추가적인, 더 적은, 또는 상이한 동작을 사용하여 구현될 수 있다. 몇몇 경우에, 동작 또는 동작의 그룹은, 예를 들면, 명시된 수의 반복 동안 또는 종료 조건에 도달될 때까지, 되풀이 또는 반복될 수 있다.

앞서 논의되는 바와 같이, 유저 프로파일 및 유저 프로파일 내에서의 엔트리 위치는 MCPTT 유저 아이덴티티를 가리키기 위해 사용될 수 있다. 유저 프로파일이 MCPTT 신뢰 도메인, 예를 들면, P-CSCF, S-CSCF, 세션 경계 제어(session border control; SBC) 외부에서 이용 가능해야 하는 경우, 데이터는 MCPTT 도메인 외부의 손상된(compromised) 제3자가 액세스할 수도 있다. 몇몇 경우에, 예를 들면, 프로파일, MCPTT 유저 아이덴티티, 또는 유저 프로파일과 관련되는 임의의 다른 데이터에서 사용할 엔트리 위치를 보호하기 위해 암호화가 사용될 수도 있다.

예시적인 프레임워크(2300)는 다음 데이터를 포함한다: 벡터, 키, 오프셋, seedID. 키는 개인 키이다. 키는 일부 또는 모든 MCPTT 유저 아이덴티티에 대해 동일할 수도 있다. 키는 또한 임의의 특정한 MCPTT 유저 아이덴티티에 대해 고유할 수도 있다. 키는 네트워크 및 ME에서 알려져 있다.

벡터는, 오프셋 값과 결합하는 것에 의해 시간에 따라 변하는 값이다. 벡터는 네트워크 및 ME에서 알려져 있다. 벡터는 타임스탬프 또는 카운터 또는 논스일 수 있다. 몇몇 경우에, 벡터는 네트워크 노드로부터 UE로 전달될 수 있다. 몇몇 경우에, 벡터는, 예를 들면, 벡터가 타임스탬프인 경우, 네트워크 노드로부터 UE로 전달되지 않을 수도 있다.

오프셋은 seedID를 암호화하기 위한 입력으로서 사용될 벡터와 결합될 수 있는 값이다. 오프셋은 암호화에 어떤 랜덤한 성질(nature)을 제공한다. 몇몇 경우에, 오프셋은 매 시간마다 랜덤하게 생성될 수 있고 암호화가 수행된다. 대안적으로 또는 추가적으로, 오프셋은 공지된 방식으로 증가 또는 감소될 수 있다.

seedID는 암호화될 데이터이다. seedID는 유저 프로파일 내의 MCPTT 유저 아이덴티티, 유저 프로파일 내의 데이터의 항목을 주소 지정하기 위해 사용되는 위치 식별자, 또는 이들의 조합을 포함할 수 있다.

예시되는 바와 같이, 단계 1에서, 네트워크 노드(2304)는 ME(2302)로 메시지를 전송한다. 메시지는 벡터 및 키를 포함할 수도 있다. 메시지는 암호화될 수도 있다. 암호화는 전송 레이어 보안(TLS) 프로토콜, OpenID 프레임워크, 또는 이들의 조합을 사용하여 수행될 수 있다. 몇몇 경우에, 벡터 및 키는 도 25의 단계 7 단계에서 교환되는 토큰의 일부일 수 있다.

단계 2에서, ME(2302)는 seedID가 암호화되어야 한다는 것을 결정한다. ME(2302)는 오프셋과 벡터를 결합하고, 결합된 값, seedID, 및 키를 암호화 알고리즘에 대한 입력으로 사용하여 암호화된 값을 생성한다.

단계 3에서, ME(2302)는 암호화된 값, 오프셋, ME의 아이덴티티를 네트워크 노드(2304)로 전송한다. 단계 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 서버의 공개 서비스 아이덴티티(Public Service Identity; PSI)에 대한 SIP INVITE 요청을 주소 지정할 수 있고 본문에 피호출 측(called party)(또는 잠재적으로 피호출 측들)의 아이덴티티를 포함하는 수신자 목록을 포함한다. 피호출 측의 아이덴티티를 PLMN 오퍼레이터가 읽을 수 없도록 만들기 위해, RFC 4483 [x]에서 정의되는 콘텐츠 인디렉션 메커니즘(content indirection mechanism)이 사용되어 수신자 목록 엘리먼트를 메시지/외부 본문 MIME 타입으로서 포함할 수 있다. 수신자 목록 엘리먼트는, 유저의 MCPTT 유저 프로파일의 연락처 목록 내의 피호출 측의 MCPTT ID를 가리키는 XML 구성 액세스 프로토콜(XML Configuration Access Protocol; XCAP) URI 또는 URL로서 포맷될 수 있다. 또한, 유저 프로파일 내의 위치에 대한 포인터는 암호화될 수 있다. 암호화된 부분은, 개인 키 및 랜덤 컴포넌트(예를 들면, 카운터 + 오프셋)를 사용하는 것을 제외하면, 텍스트일 수 있다. MCPTT 유저 아이덴티티 A가 MCPTT 유저 아이덴티티 B를 호출하면, 매번 XCAP URI의 위치 부분은 상이할 수 있다. 대안적으로, 유저 프로파일은, 연락될 수 있는 MCPTT 유저의 MCPTT ID를 포함하는 주소록 또는 네트워크 연락처 목록에 대한 하나 이상의 포인터 또는 레퍼런스를 포함할 수 있다. 잠재적으로 이들 연락처 목록은 유저 프로파일을 사용하는 MCPTT 유저의 역할(예를 들면, 최초 대처자)에 기초할 수 있다. 이 제2 레벨의 인디렉션은 실제 URI가 특정한 MCPTT 유저가 아니라 유저의 역할을 식별하는 프로파일 아이덴티티를 가리키는 것을 허용한다.

다음은 연락처 목록 문서 XML(//UserProfile/user-role-ID/contact-list)의 예이다:

대안적으로, 연락처 목록은 MCPTT 유저 프로파일로부터 분리될 수 있고 대신 연락처의 네트워크 저장 디렉토리일 수 있다. 그 경우 XCAP URI는 네트워크 디렉토리 XML 문서의 MCPTT ID를 가리킬 수 있다. 몇몇 경우에, MCPTT 유저 프로파일의 연락처 목록은, 개개의 MCPTT ID의 각각에 대한 XCAP URI의 목록을, MCPTT 유저가 호출할 수 있는 연락처의 네트워크 저장 디렉토리에 포함할 수 있다.

유저가 sip:joe@example.org(목록에서의 제4 엔트리)에 개인적으로 전송하기를 원하는 경우, SIP INVITE의 Multipart MIME 본문 내의 다음의 Content-Type이 사용될 수 있다.

UE는, MCPTT 유저 프로파일 내의 또는 MCPTT UE 및 MCPTT 서버 둘 모두가 액세스 가능한 XML 문서(예컨대, 공통 네트워크 디렉토리 문서) 내의 MCPTT ID를 가리키는 XCAP URI를 포함하는 메시지/외부 본문 MIME 본문을 포함할 수도 있다.

MCPTT 서버가 수신자 목록을 포함하는 SIP 요청을 메시지/외부 본문 MIME 본문으로서 수신하는 경우, 메시지/외부 본문 MIME 본문에 포함되는 XCAP URI를 분해하는 것에 의해 MCPTT는 피호출 측의 MCPTT ID를 획득한다. 호출된 MCPTT 유저가 상이한 MCPTT 시스템에 있으면, MCPTT 서버는 목적지 시스템의 MCPTT 서버로 요청을 포워딩할 수 있고, MCPTT 서버 둘 모두가 액세스 가능한 XML 문서(예컨대 공통 네트워크 디렉토리 문서)로 분해하는 XCAP URI를 수신자 목록 메시지/외부 본문 MIME 본문에서 사용할 수 있다. MCPTT 서버는 또한, 호출하는 MCPTT 유저의 MCPTT ID를 가리키는 XCAP URI를 포함하는 메시지/외부 본문 MIME 본문을, MCPTT 서버 둘 모두가 액세스 가능한 XML 문서(예컨대 공통 네트워크 디렉토리 문서)에 포함할 수 있다.

마찬가지로, MCPTT 그룹 ID는, 유저 프로파일 연락처 목록에서의 또는 대안적으로 그 그룹을 정의하는 그룹 문서에서의 또는 대안적으로 하나 이상의 그룹을 식별하는 공통 문서에서의 MCPTT 그룹 ID를 가리키는 XCAP URI를 포함하는 메시지/외부 본문 MIME 본문을 사용하여 식별될 수 있다.

도 24로 돌아와서, 단계 0에서, MCPTT 유저 인증은, MCPTT UEa(2404)와 아이덴티티 관리 서버(2414) 사이에서 수행된다. 몇몇 경우에, 인증 절차는 도 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_ldentity: IMS 공개 아이덴티티(예를 들면, SIP URI)를 포함하며, ID 관리 서버(2414)에 의해 할당됨.

다음은 id_token에 대해 JSON 스키마를 사용하는 예시적인 구현예인데, 여기서 "private.random1@example.com"은 IMPI2a를 나타내고, "public.random1@example.com"은 IMPU2a를 나타낸다.

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)는 IMPI2a 또는 IMPU2a가 MCPTT 유저 아이덴티티 A로 매핑한다는 것을 결정한다. 단계 5a에서, 아이덴티티 관리 서버(2414)는 인증 요청을 HSS(2412)로 전송한다. 인증 요청은, MCPTT 유저 아이덴티티 A와 관련되는 IMPM1a, IMPU1a, 또는 이들의 조합을 포함한다. 단계 5b에서, 아이덴티티 관리 서버(2414)는 HSS(2412)로부터 인증 응답을 수신한다. 인증 응답은 IMPM1a, IMPU1a, 또는 이들의 조합에 기초하여 생성되는 인증 응답 벡터를 포함한다.

몇몇 경우에, 단계 5c에서, 아이덴티티 관리 서버(2414) 및 MCPTT 유저 데이터베이스(2416)는 MCPTT 유저 아이덴티티 A를 IMPI2a 또는 IMPU2a와 바인딩한다. 아이덴티티 관리 서버(2414)는, IMPI2a, IMPU2a, MCPTT 유저 인증 토큰(MCPTT 유저 아이덴티티 A의 일부로서 생성됨) 및 MCPTT 유저 아이덴티티 A, 인증 토큰 및 MCPTT 유저 아이덴티티 A: 중 적어도 하나를 포함하는 메시지를, MCPTT 유저 데이터베이스(2416)로 전송할 수 있다. 도 27은 3GPP Sh 인터페이스를 사용하는 예시적인 구현예를 예시한다.

MCPTT 유저 데이터베이스(2416)는, MCPTT 유저 아이덴티티 A를 포함하는 유저 프로파일을 검사할 수 있고, MCPTT 유저 아이덴티티 A가 IMPU2a에 매핑한다는 것을 나타내도록 이들 유저 프로파일을 업데이트할 수 있다.

MCPTT 유저 데이터베이스(2416)는 MCPTT 유저 아이덴티티 A가 수신되었다는 것을 나타내는 메시지를 아이덴티티 관리 서버(2414)로 전송하고, MCPTT 유저 아이덴티티 A와 관련되는 유저 프로파일에 대한 URL/URI를 옵션적으로 포함한다.

몇몇 경우에, 단계 5c는 단계 5 이전에, 예를 들면, MCPTT 유저 인증(단계 0)이 발생했을 때 수행될 수 있다.

단계 6에서, 아이덴티티 관리 서버(2414)는 인증 응답을 SIP 데이터베이스(2413)로 전송한다. 인증 응답은, IMPM1a, IMPU1a, 또는 이들의 조합에 기초하여 생성되는, 단계 5b에서 수신되는 인증 응답 벡터를 포함한다.

단계 8에서, MCPTT UEa(2404)는 SIP 프로토콜을 사용하여 인증 시도 요청을 수신한다.

단계 9에서, MCPTT UEa(2404)는 인증 응답을 전송한다. 인증 응답은 SIP REGISTER 메시지일 수 있다.

단계 21에서, SIP 코어(2410)는 MCPTT 서버(2418)로 제3자 등록을 전송한다. 제3자 등록은 유저를 고유하게 식별하는 토큰(MPCTT 유저 아이덴티티 A)을 포함할 수 있고, 예를 들면, 제3자 등록에서 UE로부터의 REGISTER 요청을 전달하기 위한 3GPP TS 24.229의 절차를 사용하여, IMPU2a, IMPI2a를 또한 포함할 수 있다.

단계 22에서, MCPTT 서버(2418)는 수신되는 MCPTT 유저 인증 토큰 또는 IMPU2a 또는 IMPI2a에 기초하여 MCPTT 유저 아이덴티티 A를 획득하기 위해 아이덴티티 관리 서버(2414)와 상호 작용한다. 따라서 MCPTT 유저 아이덴티티 A로의 IMPU2a의 매핑이 생성될 수 있다. 이 단계를 수행하기 위해 HTTP 또는 DIAMETER 프로토콜이 사용될 수 있다. 도 28(도 28a 및 도 28b를 포함함)은 3GPP Sh 인터페이스를 사용하는 예시적인 구현예를 예시한다.

MCPTT 서버(2418)는 다음 중 적어도 하나를 포함하는 메시지를 전송한다: IMPI2a, IMPU2a, MCPTT 유저 인증 토큰.

아이덴티티 관리 서버(2414)는, IMPI2a, IMPU2a, MCPTT 유저 인증 토큰 중 적어도 하나를 포함하는 메시지 및 MCPTT 유저 아이덴티티 매핑이 필요하다는 표시를 수신한다. 아이덴티티 관리 서버(2414)는 IMPI2a, IMPU2a 중 적어도 하나로 매핑되는 MCPTT 유저 아이덴티티 A를 결정한다. 아이덴티티 관리 서버(2414)는 MCPTT 유저 아이덴티티 A를 포함하는 메시지를 MCPTT 서버(2418)로 전송한다. 하나의 예에서, SH-Pull Resp의 유저 데이터 AVP에서 MCPTT 유저 아이덴티티 A를 포함하는 Sh-Pull Resp가 전송된다.

단계 23에서, MCPTT 서버(2418)는 메시지 #23a를 MCPTT 유저 데이터베이스(2416)로 전송한다. 메시지 #23a는 MCPTT 유저 아이덴티티 A, IMPU2a, IMPI2a 중 적어도 하나를 포함한다. 메시지는 또한, 유저 프로파일이 요청된다는 표시를 포함할 수도 있다. 도 29는, 3GPP Sh 인터페이스를 사용하는 예시적인 구현예를 예시한다. MCPTT 유저 데이터베이스(2416)는 MCPPT 유저 아이덴티티 A에 관련되는 유저 프로파일을 검색한다. 다음은 유저 프로파일의 예이다:

MCPTT 유저 아이덴티티 A; 옵션적으로 제2 IMS 공개 유저 아이덴티티 A, 키, 벡터

a) 위치 1 MCPTT 유저 아이덴티티 B

b) 위치 2 MCPTT 유저 아이덴티티 C

c) 위치 3 그룹 아이덴티티 A

d) 위치 4 그룹 아이덴티티 C

e) 위치 5 코덱 AMR

f) 위치 6

MCPTT 유저 데이터베이스(2416)는, i) MCPTT 유저 아이덴티티 A에 대한 유저 프로파일이 발견될 수 있는 곳에 대한 포인터 또는 레퍼런스; 또는 ii) MCPTT 유저 아이덴티티 A에 대한 유저 프로파일을 포함하는, 메시지 #23b를 전송한다. 도 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)는 SIP SUBSCRIBE 메시지를 MCPTT 유저 데이터베이스(2416)로 전송한다. SIP 가입은 MCPTT 유저 아이덴티티 A 및 옵션적으로 IMPU2a를 포함한다.

b) MCPTT 유저 데이터베이스(2416)는 옵션적으로 MCPPT 유저 아이덴티티 A에 관련되는 유저 프로파일을 검색한다.

c) MCPTT 유저 데이터베이스(2416)는 200 OK를 MCPTT 서버(2418)로 전송한다.

d) MCPTT 유저 데이터베이스(2416)는 단계 23a)로부터의 MCPTT 유저 아이덴티티 A에 대한 유저 프로파일, 또는 단계 23a)로부터의 MCPTT 유저 아이덴티티 A에 대한 유저 프로파일의 위치에 대한 포인터 또는 레퍼런스를 포함하는 SIP NOTIFY를 전송한다.

e) MCPTT 서버(2418)는 SIP NOTIFY(s)를 수신하고 포인터(들)/레퍼런스(들)를 23a)에서 전송되는 MCPTT 유저 아이덴티티 A와 관련되는 유저 프로파일(들)에 저장한다.

예를 들면, 다른 MCPTT 유저 아이덴티티가 사용되는 것으로부터의 단계 5c)b)의 결과로서 유저 프로파일이 변경되는 경우 단계 23d) 및 e)가 다수 회 반복될 수 있다.

대안적으로, 포인터 또는 레퍼런스가 MCPTT 서버(2418)에 의해 수신되면, MCPTT 서버(2418)는, 예를 들면, HTTP Get 및 XCAP(200)를 사용하여 단계 29와 관련된 절차를 사용하여 단계 23을 수행할 수도 있다. R-URI는 MCPTT 유저 ID A가 첨부된 MCPTT 유저 데이터베이스의 것일 수 있다. 도 33은 메시지의 예시적인 구현예를 예시한다.

대안적으로, 유저 프로파일은 연락처의 네트워크 저장 디렉토리에 대한 URI를 포함할 수 있다. 그 경우 XCAP URI는 네트워크 디렉토리 XML 문서의 MCPTT ID를 가리킬 수 있다. 도 34는 메시지의 예시적인 구현예를 예시한다.

또한, MCPTT 유저 프로파일 내의 연락처 목록은, MCPTT 유저가 호출하도록 허용되는 연락처의 네트워크 저장 디렉토리 내의 개개의 MCPTT ID의 각각에 대한 XCAP URI의 목록을 포함할 수 있다. 도 35는, 한 구현예에 따른, 예시적인 연락처 목록을 예시한다.

유저 프로파일(들)의 위치가 MCPTT UEa(2404)로 프로비저닝되지 않으면, 단계 25 내지 30이 수행될 수 있다.

단계 25에서, MCPTT UEa(2404)는 SIP SUBSCRIBE를 MCPTT 서버(2418)로 전송한다. SIP SUBSCRIBE는 MCPTT 유저 아이덴티티 A 또는 SIP 메시지에서 UE에 의해 후속하여 사용될 제2 IMS 공개 유저 아이덴티티 A를 포함한다.

단계 26에서, MCPTT 서버(2418)는 200 OK를 전송한다. 단계 27에서, MCPTT 서버(2418)는 SIP NOTIFY를 MCPTT UEa(2404)로 전송하는데, SIP NOTIFY는 단계 25에서 레퍼런스였던 유저 프로파일에 대한 레퍼런스 또는 포인터를 포함한다.

몇몇 경우에, MCPTT 유저 아이덴티티 A에 대한 유저 프로파일의 위치가 MCPTT UEa(2404)에 프로비저닝될 수도 있다. 그 정보는 Oauth 메커니즘에서(단계 0에서) 또는 MCPTT 유저 아이덴티티 A를 인증하기 위해 사용된 다른 메커니즘에서 MCPTT 유저 인증 토큰의 일부로서 수신되는 XML을 통해 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.xml HTTP/1.1.

단계 29에서, MCPTT UEa(2404)는 유저 프로파일을 획득하기 위해 메시지(HTTP GET)를 전송한다. 메시지는 옵션적 터널(TL, TTLS, IPsec 등등)을 통해 MCPTT 유저 데이터베이스로 전송될 수 있다. HTTP GET의 R-URI는 문서 URI의 것이다. HTTP GET은, MCPTT 유저 아이덴티티 A 또는, 이용 가능한 경우, SIP 메시지에서 UE에 의해 후속하여 사용될 제2 IMS 공개 유저 아이덴티티 A를 포함한다.

MCPTT 유저 데이터베이스(2416)는 HTTP GET을 수신한다. MCPTT 유저 데이터베이스(2416)는, 유저 프로파일을 획득하기 위해 HTTP GET에서 수신되었던 아이덴티티(MCPTT 유저 아이덴티티 A 또는 SIP 메시지에서 UEa에 의해 후속하여 사용될 제2 IMS 공개 유저 아이덴티티 A)를 사용한다.

단계 30에서, MCPTT 유저 데이터베이스(2416)는 유저 프로파일을 MCPTT UEa(2404)로 전송한다. MCPTT UEa(2404)로 전송되는 유저 프로파일은, IMPU2a, IMPI2a, 또는 이들의 조합을 포함할 수도 있다. MCPTT UEa(2404)는 유저 프로파일을 수신하고 그것을 내부 메모리 또는 착탈식 카드(UICC) 중 어느 하나 상에 저장한다.

단계 31에서, MCPTT UEa(2404)는 SIP METHOD를 전송한다. R-URI는 MCPTT 서버이다. SIP METHOD, 유저 프로파일에 대한 0 개 내지 많은 레퍼런스 또는 포인터를 포함할 수 있다. 레퍼런스 또는 포인터는, 유저 프로파일 내의 특정한 엔트리, 예를 들면, TO 어드레스, SDP 엔트리를 가리키는 추가적인 정보를 포함할 수도 있다.

유저가 sip:joe@example.org(표 Y1에서 나타내어지는 바와 같은 목록의 제4 엔트리)로 개인적으로 전송하기를 원하는 경우, SIP INVITE의 Multipart MIME 본문에 있는 다음의 Content-Type이 사용될 수 있고, "%5b4%5d"(이스케이프 처리된(escaped) 4)는 암호화될 수도 있다:

단계 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

유저 에이전트: IMS 가입자

날짜: 2004년 1월 8일 목요일 11:13:17 GMT

콘텐츠 길이: 0

단계 34에서, MCPTT 유저 데이터베이스(2416)는 유저 프로파일을 MCPTT 서버(2418)로 전송한다.

단계 34에서, MCPTT 서버(2418)는 참조된 당사자(party)을 유저 프로파일에서 검색한다. 오프셋 파라미터가 수신되면, MCPTT 서버는 검색 이전에 위치를 암호 해제할 수 있다.

B 당사자(To address)가 참조되면, MCPTT 서버(2418)는 A 당사자 유저 데이터로부터 B 당사자용 MCPTT 유저 아이덴티티 B를 결정한다.

MCPTT 서버(2418)는, 유저 프로파일에서 B 당사자 MCPTT 유저 아이덴티티 B를 검색하는 것에 의해, B 당사자 MCPTT 유저 아이덴티티 B가 MCPTT 서버(2418)에 저장된 유저 프로파일을 갖는지를 결정한다. 유저 프로파일이 존재하지 않으면, MCPTT 서버(2418)는 앞서 설명되는 절차를 사용하여 유저 프로파일을 획득한다.

MCPTT 서버(2418)는, MCPTT 유저 아이덴티티 A가 B 당사자 유저 프로파일에 존재하는지를 결정한다.

MCPTT 서버(2418)는, 착신하는 수신 메시지에서 참조되었던 다른 참조된 데이터가 유저 프로파일 B에 있는지를 결정한다. 동일한 유저 프로파일 A 당사자 내의 다른 참조된 데이터가 존재하면, MCPTT 서버(2418)는 SIP METHOD 내의 다른 참조된 데이터에 대한 레퍼런스 또는 포인터를 포함한다. 다른 참조된 데이터가 다른 B 당사자 유저 프로파일에 있으면, MCPTT 서버(2418)는 SIP METHOD의 다른 B 당사자 유저 프로파일에 대한 레퍼런스 또는 포인터를 포함한다.

A 당사자 아이덴티티가 존재하면, MCPTT 서버(2418)는, A 당사자를 포함하는 유저 프로파일에 대한 레퍼런스를 포함하는 SIP METHOD를 전송한다.

데이터가 B 당사자 유저 프로파일에 있지 않으면, MCPTT 서버(2418)는 현존하는 B 당사자 유저 프로파일을 선택한다. MCPTT 서버(2418)는 선택된 유저 프로파일에서 새로운 엔트리를 생성한다. MCPTT 서버(2418)는 3GPP TS 24.623/RFC 4825 [x]에서 정의되는 바와 같이 XCAP 클라이언트로서 작용할 수도 있고 새로운 속성을 생성하기 위한 액션을 수행할 수도 있다. 새로운 속성은 B 당사자가 엔트리, 예를 들면, 다음에 기초하여 A 당사자 MCPTT 유저 아이덴티티를 도출하는 것을 가능하게 하도록 구성될 수 있다:

위치 X MCPTT 유저 아이덴티티 또는

IMPU2a MCPTT 유저 아이덴티티

MCPTT 서버(2418)가 SIP METHOD를 전송하는 경우, 그것은 또한, 문서가 변경되었다는 것을 MCPTT UEb(2402)가 알도록, URI 수명을 업데이트 또는 변경할 수도 있다.

MCPTT UEb(2402)는 SIP METHOD를 수신한다. SIP METHOD는, 유저 프로파일에 대한 0 내지 다수의 레퍼런스 또는 포인터를 포함할 수도 있다. MCPTT UEb(2402)가 레퍼런스 또는 포인터에서 참조가 이루어진 XML 문서를 이전에 획득한 경우, MCPTT UEb(2402)는 URI 수명이 유효한지를 보기 위해 검사할 수도 있다. URI 수명이 유효하지 않다면, MCPTT UEb(2402)는 단계 35를 수행할 수도 있다.

URI 수명이 유효하거나, 또는 MCPTT UEb(2402)가 단계 35 및 36을 사용하여 유저 프로파일을 검색한 경우, MCPTT UEb(2402)는 수신된 레퍼런스 또는 포인터를 사용하여 정보를 획득할 수도 있다. 연락처 아이덴티티를 식별하는 레퍼런스 또는 포인터의 경우에, 상기 연락처 아이덴티티는 스크린 상에 디스플레이될 수도 있다.

URI 수명이 유효하지 않은 경우, MCPTT UEb(2402)는 SIP METHOD에서 참조되었던 유저 프로파일을 검색할 수도 있다.

본 개시가 다수의 특정한 구현 세부 사항을 포함하지만, 이들은 임의의 발명의 범위에 대한 또는 청구될 수도 있는 것의 범위에 대한 제한으로서 해석되어서는 안되며, 오히려 특정한 발명의 특정한 구현예에 고유할 수도 있는 피쳐의 설명으로서 해석되야 한다. 예를 들면, 본원에서 설명되는 솔루션은 MCPTT 외에도 미션 크리티컬 서비스에 적용될 수 있다. 이들 미션 크리티컬 서비스의 예는, 미션 크리티컬 비디오(mission critical video; MCVideo), 미션 크리티컬 데이터(mission critical data; MCData), 또는 임의의 다른 미션 크리티컬 서비스를 포함한다. 별개의 구현예의 맥락에서 본 개시에서 설명되는 소정의 피쳐는, 조합하여, 단일의 구현예에서 또한 구현될 수 있다. 반대로, 단일의 구현예의 맥락에서 설명되는 다양한 피쳐는 또한, 다수의 구현예에서, 개별적으로 또는 임의의 적절한 하위 조합에서 구현될 수 있다. 또한, 비록 피쳐가 상기에서는 소정의 조합에서 동작하는 것으로 설명될 수도 있고 심지어 초기에는 그와 같이 주장될 수도 있지만, 주장된 조합으로부터의 하나 이상의 피쳐는, 몇몇 경우에서, 그 조합으로부터 제거될 수 있고, 주장된 조합은 하위 조합 또는 하위 조합의 변형을 대상으로 할 수도 있다.

본 주제의 특정한 구현예가 설명되었다. 설명된 구현예의 다른 구현예, 변경예, 및 치환예는, 기술 분야의 숙련된 자에게 자명한 바와 같이, 다음의 청구범위의 범위 내에 있다. 동작이 도면 및 청구범위에서 특정한 순서로 묘사되지만, 이것은, 소망하는 결과를 달성하기 위해, 그러한 동작이 도시되는 특정한 순서로 또는 순차적인 순서로 수행되어야 한다는 것, 또는 모든 예시된 동작이 수행되어야 한다는 것을 규정하는 것으로 이해되지 않아야 한다(몇몇 동작은 옵션적인 것으로 간주될 수도 있다). 소정의 상황에서, 멀티태스킹 또는 병렬 프로세싱(또는 멀티태스킹과 병렬 프로세싱의 조합)이 유리할 수도 있고 적절하다고 판단될 때 수행될 수도 있다.

또한, 상기에서 설명되는 구현예에서의 다양한 시스템 모듈 및 컴포넌트의 분리 및/또는 통합은, 모든 구현예에서 그러한 분리 또는 통합을 필요로 하는 것으로 이해되어서는 안되며, 설명된 프로그램 컴포넌트 및 시스템은 일반적으로 단일 소프트웨어 제품에서 함께 통합될 수 있거나 또는 다수의 소프트웨어 제품으로 패키징될 수 있다는 것이 이해되어야 한다.

따라서, 예시적인 구현예의 상기의 설명은 본 개시를 정의하거나 또는 제한하지 않는다. 본 개시의 취지 및 범위를 벗어나지 않으면서 다른 변경예, 대안예, 및 수정예도 또한 가능하다.

또한, 이하의 임의의 청구된 구현예는, 적어도 컴퓨터 구현 방법; 컴퓨터 구현 방법을 수행하기 위한 컴퓨터 판독 가능 명령어를 저장하는 비일시적 컴퓨터 판독 가능 매체; 및 컴퓨터 구현 방법 또는 컴퓨터 판독 가능 매체 상에 저장된 명령어를 수행하도록 구성되는 하드웨어 프로세서와 상호 동작 가능하게 커플링되는 컴퓨터 메모리를 포함하는 컴퓨터 시스템에 적용 가능한 것으로 고려된다.

Claims

방법에 있어서,
인증 구성 정보를 요청하는 제1 메시지 - 상기 제1 메시지는 제1 프로토콜에 따라 포맷됨 - 를, 유저 기기(user equipment; UE)로부터 제1 네트워크 노드로, 송신하는 단계;
상기 제1 메시지에 응답하여, 상기 인증 구성 정보를 포함하는 제2 메시지를 수신하는 단계;
상기 수신된 인증 구성 정보에 기초한 인증 정보를 포함하는 제3 메시지 - 상기 제3 메시지는 제2 프로토콜에 따라 포맷됨 - 를, 상기 UE로부터 제2 네트워크 노드로 송신하는 단계;
상기 제2 프로토콜에 따라 포맷되는 인증 시도 요청(authentication challenge request)을, 상기 제2 네트워크 노드로부터 수신하는 단계; 및
상기 인증 시도 요청을 수신하는 것에 응답하여, 인증 응답을 상기 제2 네트워크 노드로 송신하는 단계를 포함하는, 방법.
제1항에 있어서,
상기 제1 네트워크 노드는 미션 크리티컬 푸시 투 토크(Mission Critical Push to Talk; MCPTT) 유저에 대한 아이덴티티 매핑을 수행하는, 방법.
제1항에 있어서,
상기 제2 네트워크 노드는 세션 개시 프로토콜(Session Initiation Protocol; SIP) 코어를 포함하는, 방법.
제1항에 있어서,
상기 제1 프로토콜은 하이퍼텍스트 전송 프로토콜(Hypertext Transfer Protocol; HTTP), 확장성 인증 프로토콜(Extensible Authentication Protocol; EAP), 또는 세션 개시 프로토콜(SIP) 중 적어도 하나인, 방법.
제1항에 있어서,
상기 제2 프로토콜은 세션 개시 프로토콜(SIP)인, 방법.
제1항에 있어서,
상기 제1 메시지는 제1 미션 크리티컬 푸시 투 토크(MCPTT) 시스템과 관련되는 제1 유저 식별자(ID)를 포함하고, 상기 인증 정보는 제2 MCPTT 시스템과 관련되는 제2 유저 ID를 포함하는, 방법.
제6항에 있어서,
상기 제2 유저 ID는 공개 유저 ID 또는 개인 유저 ID 중 적어도 하나를 포함하는, 방법.
유저 기기(UE)에 있어서,
적어도 하나의 하드웨어 프로세서; 및
상기 적어도 하나의 하드웨어 프로세서에 커플링되며 상기 적어도 하나의 하드웨어 프로세서에 의한 실행을 위한 프로그래밍 명령어를 저장하는 비일시적 컴퓨터 판독 가능 저장 매체를 포함하며,
상기 프로그래밍 명령어는 상기 적어도 하나의 하드웨어 프로세서로 하여금,
인증 구성 정보를 요청하는 제1 메시지 - 상기 제1 메시지는 제1 프로토콜에 따라 포맷됨 - 를, UE로부터 제1 네트워크 노드로, 송신하고;
상기 제1 메시지에 응답하여, 상기 인증 구성 정보를 포함하는 제2 메시지를 수신하고;
상기 수신된 인증 구성 정보에 기초한 인증 정보를 포함하는 제3 메시지 - 상기 제3 메시지는 제2 프로토콜에 따라 포맷됨 - 를, 상기 UE로부터 제2 네트워크 노드로 송신하고;
상기 제2 프로토콜에 따라 포맷되는 인증 시도 요청을, 상기 제2 네트워크 노드로부터 수신하고;
상기 인증 시도 요청을 수신하는 것에 응답하여, 인증 응답을 상기 제2 네트워크 노드로 송신하도록 지시하는, 유저 기기(UE).
제8항에 있어서,
상기 제1 네트워크 노드는 미션 크리티컬 푸시 투 토크(Mission Critical Push to Talk; MCPTT) 유저에 대한 아이덴티티 매핑을 수행하는, 유저 기기(UE).
제8항에 있어서,
상기 제2 네트워크 노드는 세션 개시 프로토콜(Session Initiation Protocol; SIP) 코어를 포함하는, 유저 기기(UE).
제8항에 있어서,
상기 제1 프로토콜은 하이퍼텍스트 전송 프로토콜(Hypertext Transfer Protocol; HTTP), 확장성 인증 프로토콜(Extensible Authentication Protocol; EAP), 또는 세션 개시 프로토콜(SIP) 중 적어도 하나인, 유저 기기(UE).
제8항에 있어서,
상기 제2 프로토콜은 세션 개시 프로토콜(SIP)인, 유저 기기(UE).
제8항에 있어서,
상기 제1 메시지는 제1 미션 크리티컬 푸시 투 토크(MCPTT) 시스템과 관련되는 제1 유저 식별자(ID)를 포함하고, 상기 인증 정보는 제2 MCPTT 시스템과 관련되는 제2 유저 ID를 포함하는, 유저 기기(UE).
제13항에 있어서,
상기 제2 유저 ID는 공개 유저 ID 또는 개인 유저 ID 중 적어도 하나를 포함하는, 유저 기기(UE).
방법에 있어서,
제1 네트워크 노드에서, 제1 인증 요청 - 상기 제1 인증 요청은 제1 미션 크리티컬 푸시 투 토크(MCPTT) 시스템과 관련되는 제1 유저 식별자(ID)를 포함함 - 을 수신하는 단계;
상기 제1 유저 ID가 제2 미션 크리티컬 푸시 투 토크(MCPTT) 시스템과 관련되는 제2 유저 ID로 매핑된다는 것을 결정하는 단계;
제2 인증 요청 - 상기 제2 인증 요청은 상기 제2 유저 ID를 포함함 - 을, 상기 제1 네트워크 노드로부터 제2 네트워크 노드로 송신하는 단계;
상기 제2 인증 요청에 응답하여, 인증 응답 벡터를 포함하는 제1 인증 응답을 수신하는 단계; 및
상기 제1 인증 응답을 수신하는 것에 응답하여, 상기 인증 응답 벡터를 포함하는 제2 인증 응답을 송신하는 단계를 포함하는, 방법.
제15항에 있어서,
상기 제1 네트워크 노드는 MCPTT 유저에 대한 아이덴티티 매핑을 수행하는, 방법.
제15항에 있어서,
상기 제1 네트워크 노드는 공통 서비스 코어의 일부인, 방법.
제15항에 있어서,
상기 제1 네트워크 노드는 아이덴티티 관리 서버인, 방법.
제15항에 있어서,
상기 인증 응답 벡터는 상기 제2 유저 ID에 기초하여 생성되는, 방법.
제15항에 있어서,
상기 제2 유저 ID는 공개 유저 ID 또는 개인 유저 ID 중 적어도 하나를 포함하는, 방법.