KR20170106490A - 기존의 크리덴셜들을 이용한 셀룰러 네트워크들에 대한 후원된 접속 - Google Patents

기존의 크리덴셜들을 이용한 셀룰러 네트워크들에 대한 후원된 접속 Download PDF

Info

Publication number
KR20170106490A
KR20170106490A KR1020177024843A KR20177024843A KR20170106490A KR 20170106490 A KR20170106490 A KR 20170106490A KR 1020177024843 A KR1020177024843 A KR 1020177024843A KR 20177024843 A KR20177024843 A KR 20177024843A KR 20170106490 A KR20170106490 A KR 20170106490A
Authority
KR
South Korea
Prior art keywords
service provider
application service
provider server
network
authentication
Prior art date
Application number
KR1020177024843A
Other languages
English (en)
Other versions
KR101819878B1 (ko
Inventor
수범 이
아난드 팔라니고운데르
개빈 버나드 호른
Original Assignee
퀄컴 인코포레이티드
Priority date (The priority date is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the date listed.)
Filing date
Publication date
Application filed by 퀄컴 인코포레이티드 filed Critical 퀄컴 인코포레이티드
Publication of KR20170106490A publication Critical patent/KR20170106490A/ko
Application granted granted Critical
Publication of KR101819878B1 publication Critical patent/KR101819878B1/ko

Links

Images

Classifications

    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L63/00—Network architectures or network communication protocols for network security
    • H04L63/10—Network architectures or network communication protocols for network security for controlling access to devices or network resources
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04W—WIRELESS COMMUNICATION NETWORKS
    • H04W12/00—Security arrangements; Authentication; Protecting privacy or anonymity
    • H04W12/06—Authentication
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L63/00—Network architectures or network communication protocols for network security
    • H04L63/08—Network architectures or network communication protocols for network security for authentication of entities
    • H04L63/0807—Network architectures or network communication protocols for network security for authentication of entities using tickets, e.g. Kerberos
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L63/00—Network architectures or network communication protocols for network security
    • H04L63/08—Network architectures or network communication protocols for network security for authentication of entities
    • H04L63/083—Network architectures or network communication protocols for network security for authentication of entities using passwords
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L63/00—Network architectures or network communication protocols for network security
    • H04L63/18—Network architectures or network communication protocols for network security using different networks or channels, e.g. using out of band channels
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L9/00—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols
    • H04L9/06—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols the encryption apparatus using shift registers or memories for block-wise or stream coding, e.g. DES systems or RC4; Hash functions; Pseudorandom sequence generators
    • H04L9/0643—Hash functions, e.g. MD5, SHA, HMAC or f9 MAC
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L9/00—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols
    • H04L9/08—Key distribution or management, e.g. generation, sharing or updating, of cryptographic keys or passwords
    • H04L9/0816—Key establishment, i.e. cryptographic processes or cryptographic protocols whereby a shared secret becomes available to two or more parties, for subsequent use
    • H04L9/085—Secret sharing or secret splitting, e.g. threshold schemes
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04W—WIRELESS COMMUNICATION NETWORKS
    • H04W12/00—Security arrangements; Authentication; Protecting privacy or anonymity
    • H04W12/06—Authentication
    • H04W12/062—Pre-authentication
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04W—WIRELESS COMMUNICATION NETWORKS
    • H04W12/00—Security arrangements; Authentication; Protecting privacy or anonymity
    • H04W12/08—Access security
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L63/00—Network architectures or network communication protocols for network security
    • H04L63/08—Network architectures or network communication protocols for network security for authentication of entities
    • H04L63/0892—Network architectures or network communication protocols for network security for authentication of entities by using authentication-authorization-accounting [AAA] servers or protocols

Landscapes

  • Engineering & Computer Science (AREA)
  • Computer Security & Cryptography (AREA)
  • Computer Networks & Wireless Communication (AREA)
  • Signal Processing (AREA)
  • Computer Hardware Design (AREA)
  • Computing Systems (AREA)
  • General Engineering & Computer Science (AREA)
  • Power Engineering (AREA)
  • Telephonic Communication Services (AREA)
  • Mobile Radio Communication Systems (AREA)

Abstract

애플리케이션 서비스 프로바이더에 의해 접속이 후원되는 서비스를 사용자 장비 (UE) 가 액세스할 수도 있도록 서빙 네트워크 상에서 사용자 장비의 후원된 접속을 용이하게 하기 위한 시스템들 및 기술들이 개시된다. 애플리케이션 서비스 프로바이더는 후원된 접속을 인식하도록 서빙 네트워크를 프로비저닝한다. 서빙 네트워크에 대한 어태치 시도에서, UE 는 어태치 요청과 함께 가입자 식별자 대신에 (UE 와 애플리케이션 서비스 프로바이더 사이에 확립된) 사전-존재 크리덴셜에 기초한 클라이언트 토큰을 제공한다. 애플리케이션 서비스 프로바이더의 서버는 UE 를 인증하기 위해 액세스 크리덴셜을 유효화하고, 서빙 네트워크가 UE 와 상호 인증하기 위해 사용하는 정보를 제공한다. UE 는 그러면, UE 가 셀룰러 네트워크와의 서브스크립션 및 가입자 아이덴티티를 갖지 않는 경우에도, 후원된 접속을 통해 서비스를 액세스하기 위해 서빙 네트워크를 이용할 수도 있다.

Description

기존의 크리덴셜들을 이용한 셀룰러 네트워크들에 대한 후원된 접속
관련 출원들에 대한 상호 참조 및 우선권 주장
본 출원은 "Sponsored Connectivity to Cellular Networks Using Existing Credentials" 라는 제목으로 2015년 3월 6일 출원된 미국 가특허출원 제 62/129,462 호의 이익을 주장하는, 2015년 8월 3일 출원된 미국 정규특허출원 제 14/817,123 호의 이익을 주장하고 그것에 대해 우선권을 주장하며, 양자의 개시는 그 전체가 본원에 참조에 의해 통합된다.
기술분야
이 출원은 일반적으로 무선 통신 시스템들에 관한 것이고, 보다 상세하게는, 하나 이상의 서비스들에 대해 서빙 (serving) 네트워크에 대한 액세스를 후원하는 애플리케이션 서비스 프로바이더에 관한 것이다. 특정 실시형태들은, 사용자들이 (예를 들어, 빌링/미터링 목적들을 위해) 스케일러블, 보안형, 및 추정가능형 방식의 네트워크 서브스크립션(들)을 결여할 수도 있는 경우들에서 네트워크 애플리케이션 서비스들을 액세스하도록 구성된 및/또는 액세스할 수 있는 디바이스들, 방법들, 및 시스템들을 가능하게 하고 제공한다.
네트워크로부터 서비스들을 수신하기 위해, 알려지지 않은 사용자 장비 (user equipment; UE) 는 네트워크에 등록하거나 그 외에 네트워크에 알려지게될 필요가 있다. 이것은 네트워크 어태치 절차를 이용하여 달성된다. 일반적으로, 서비스에 대한 서브스크립션 (subscription) 을 갖지 않는 UE 는 (예를 들어 미국에서 911 과 같은 긴급 서비스를 제외하고) 음성 또는 데이터 서비스를 수신하기 위해 서빙 네트워크에 어태치할 수 없다. 서빙 네트워크에 대한 UE 의 접속을 후원함으로써 UE 로 하여금 그래도 서비스를 수신하는 것을 가능하게 하기 위한 시도들이 이루어졌다. 후원된 접속은 통상적으로 특정 애플리케이션 또는 서비스에 의해 후원되는 특정 애플리케이션 또는 서비스에 대한 네트워크 액세스의 제한된 허용을 수반한다.
현재의 종래의 접근법들은 소정 유형들의 디바이스들 (예컨대, SIM 카드들 및/또는 서브스크립션들이 없는 UE 들) 은 후원된 접속의 이점을 취할 수 없도록 배제하고, 서빙 네트워크를 그것의 코어 네트워크 상에서 원하지 않는 (또는 악성) 트래픽에 노출시키거나 비효율적이다. 이하 논의되는 바와 같이, 이 개시의 양태들 및 실시형태들은 후원된 접속을 개선하는 것을 목적으로 한다.
다음은 논의되는 기술의 기본적인 이해를 제공하기 위해 본 개시의 일부 양태들을 요약한다. 이 요약은 본 개시의 모든 고려되는 피처들 (features) 의 확장적인 개관이 아니고, 본 개시의 모든 양태들의 중요한 또는 결정적인 엘리먼트들을 식별하려는 의도도 아니고 본 개시의 임의의 또는 모든 범위를 나타내려는 의도도 아니다. 그것의 유일한 목적은 나중에 제시되는 보다 상세한 설명에 대한 서두로서 요약 형태로 본 개시의 하나 이상의 양태들의 일부 개념들을 제시하려는 것이다.
본 개시의 하나의 양태에서, 서비스를 액세스 (access) 하는 방법은, 사용자 장비 (UE) 에 의해 서빙 (serving) 네트워크를 식별하는 단계로서, 이 서빙 네트워크를 통해 애플리케이션 서비스 프로바이더 서버가 서비스에 대한 액세스를 후원 (sponsor) 하는, 상기 서빙 네트워크를 식별하는 단계; 애플리케이션 서비스 프로바이더 서버와 확립된 사전-존재 크리덴셜 (pre-existing credential) 에 기초하는 클라이언트 토큰 (client token) 과 함께 서빙 네트워크에 어태치 요청을 전송하는 단계로서, 클라이언트 토큰은 서빙 네트워크에 대한 셀룰러 액세스 크리덴셜로서 인식가능하지 않은, 상기 어태치 요청을 전송하는 단계; 및, UE 에 의해, 사전-존재 크리덴셜에 기초하여 서비스에 대한 후원된 액세스에 대해 애플리케이션 서비스 프로바이더 서버를 통해 서빙 네트워크에 대해 인증하는 단계를 포함한다.
본 개시의 추가적인 양태에서, 애플리케이션 서비스 프로바이더 서버에 의해 후원된 서비스에 대한 액세스를 가능하게 하는 방법은, 중개 서빙 네트워크 (intervening serving network) 로부터, 사용자 장비 (UE) 로부터의 어태치 요청에 기초한 인증 정보 요청을 수신하는 단계로서, 이 중개 서빙 네트워크를 통해 애플리케이션 서비스 프로바이더 서버가 서비스에 대한 액세스를 후원하고, 인증 정보 요청은, 애플리케이션 서비스 프로바이더 서버와 확립된 사전-존재 크리덴셜에 기초하고 서빙 네트워크에 대한 셀룰러 액세스 크리덴셜로서 인식가능하지 않은 클라이언트 토큰을 포함하는, 상기 인증 정보 요청을 수신하는 단계; 애플리케이션 서비스 프로바이더 서버에 의해, 인증 정보 요청에 응답하여 애플리케이션 서비스 프로바이더 서버에 의해 액세스가능한 사전-존재 크리덴셜에 기초하여 인증 정보를 결정하는 단계; 및, 서빙 네트워크에 응답하여 인증 정보를, 애플리케이션 서비스 프로바이더 서버로부터 송신하는 단계로서, 인증 정보는, 사전-존재 크리덴셜에 기초하여 서비스에 대한 후원된 액세스를 위해 서빙 네트워크와 UE 사이에서의 인증을 돕는, 상기 인증 정보를 송신하는 단계를 포함한다.
본 개시의 추가적인 양태에서, 서비스를 액세스하기 위한 사용자 장비 (UE) 는, 서빙 네트워크를 식별하는 것을 보조하는 것으로서, 이 서빙 네트워크를 통해 애플리케이션 서비스 프로바이더 서버가 서비스에 대한 액세스를 후원하는, 상기 서빙 네트워크를 식별하는 것을 보조하는 것을 행하고; 애플리케이션 서비스 프로바이더 서버와 확립된 사전-존재 크리덴셜에 기초하는 클라이언트 토큰과 함께 서빙 네트워크에 어태치 요청을 전송하는 것으로서, 이 클라이언트 토큰은 서빙 네트워크에 대한 셀룰러 액세스 크리덴셜로서 인식가능하지 않은, 상기 어태치 요청을 전송하는 것을 행하도록 구성된 트랜시버; 및, 사전-존재 크리덴셜에 기초하여 서비스에 대한 후원된 액세스에 대해 애플리케이션 서비스 프로바이더 서버를 통해 서빙 네트워크에 대해 인증하도록 구성되는 프로세서를 포함한다.
본 개시의 추가적인 양태에서, 서비스에 대한 액세스를 후원하는 애플리케이션 서비스 프로바이더 서버는, 중개 서빙 네트워크로부터, 사용자 장비 (UE) 로부터의 어태치 요청에 기초한 인증 정보 요청을 수신하는 것으로서, 이 중개 서빙 네트워크를 통해 애플리케이션 서비스 프로바이더 서버가 서비스에 대한 액세스를 후원하고, 인증 정보 요청은 애플리케이션 서비스 프로바이더 서버와 확립된 사전-존재 크리덴셜에 기초하고 서빙 네트워크에 대한 셀룰러 액세스 크리덴셜로서 인식가능하지 않은 클라이언트 토큰을 포함하는, 상기 인증 정보 요청을 수신하는 것을 행하도록 구성된 트랜시버; 및, 인증 정보 요청에 응답하여 애플리케이션 서비스 프로바이더 서버에 의해 액세스가능한 사전-존재 크리덴셜에 기초하여 인증 정보를 결정하도록 구성되는 프로세서를 포함하고, 트랜시버는 서빙 네트워크에 응답하여 인증 정보를 송신하도록 더 구성되고, 그리고, 인증 정보는, 사전-존재 크리덴셜에 기초하여 서비스에 대한 후원된 액세스를 위해 서빙 네트워크와 UE 사이에서의 인증을 돕는다.
본 개시의 추가적인 양태에서, 프로그램 코드를 그 위에 기록한 컴퓨터 판독가능 매체는, 사용자 장비 (UE) 로 하여금 서빙 네트워크를 식별하게 하기 위한 코드로서, 이 서빙 네트워크를 통해 애플리케이션 서비스 프로바이더 서버가 서비스에 대한 액세스를 후원하는, 상기 서빙 네트워크를 식별하게 하기 위한 코드; UE 로 하여금, 애플리케이션 서비스 프로바이더 서버와 확립된 사전-존재 크리덴셜에 기초하는 클라이언트 토큰과 함께 서빙 네트워크에 어태치 요청을 전송하게 하기 위한 코드로서, 클라이언트 토큰은 서빙 네트워크에 대한 셀룰러 액세스 크리덴셜로서 인식가능하지 않은, 상기 어태치 요청을 전송하게 하기 위한 코드; 및, UE 로 하여금, 사전-존재 크리덴셜에 기초하여 서비스에 대한 후원된 액세스에 대해 애플리케이션 서비스 프로바이더 서버를 통해 서빙 네트워크에 대해 인증하게 하기 위한 코드를 포함하는, 프로그램 코드를 포함한다.
본 개시의 추가적인 양태에서, 프로그램 코드를 그 위에 기록한 컴퓨터 판독가능 매체는, 애플리케이션 서비스 프로바이더 서버로 하여금, 중개 서빙 네트워크로부터, 사용자 장비 (UE) 로부터의 어태치 요청에 기초한 인증 정보 요청을 수신하게 하기 위한 코드로서, 이 중개 서빙 네트워크를 통해 애플리케이션 서비스 프로바이더 서버가 서비스에 대한 액세스를 후원하고, 인증 정보 요청은 애플리케이션 서비스 프로바이더 서버와 확립된 사전-존재 크리덴셜에 기초하고 서빙 네트워크에 대한 셀룰러 액세스 크리덴셜로서 인식가능하지 않은 클라이언트 토큰을 포함하는, 상기 인증 정보 요청을 수신하게 하기 위한 코드; 애플리케이션 서비스 프로바이더 서버로 하여금, 인증 정보 요청에 응답하여 애플리케이션 서비스 프로바이더 서버에 의해 액세스가능한 사전-존재 크리덴셜에 기초하여 인증 정보를 결정하게 하기 위한 코드; 및, 애플리케이션 서비스 프로바이더 서버로 하여금, 서빙 네트워크에 응답하여 인증 정보를 송신하게 하기 위한 코드로서, 인증 정보는, 사전-존재 크리덴셜에 기초하여 서비스에 대한 후원된 액세스를 위해 서빙 네트워크와 UE 사이에서의 인증을 돕는, 상기 인증 정보를 송신하게 하기 위한 코드를 포함하는, 프로그램 코드를 포함한다.
본 개시의 추가적인 양태에서, 서비스를 액세스하기 위한 사용자 장비 (UE) 는, 서빙 네트워크를 식별하는 수단으로서, 이 서빙 네트워크를 통해 애플리케이션 서비스 프로바이더 서버가 서비스에 대한 액세스를 후원하는, 상기 서빙 네트워크를 식별하는 수단; 애플리케이션 서비스 프로바이더 서버와 확립된 사전-존재 크리덴셜에 기초하는 클라이언트 토큰과 함께 서빙 네트워크에 어태치 요청을 전송하는 수단으로서, 이 클라이언트 토큰은 서빙 네트워크에 대한 셀룰러 액세스 크리덴셜로서 인식가능하지 않은, 상기 어태치 요청을 전송하는 수단; 및, 사전-존재 크리덴셜에 기초하여 서비스에 대한 후원된 액세스에 대해 애플리케이션 서비스 프로바이더 서버를 통해 서빙 네트워크에 대해 인증하는 수단을 포함한다.
본 개시의 추가적인 양태에서, 서비스에 대한 액세스를 후원하는 애플리케이션 서비스 프로바이더 서버는, 중개 서빙 네트워크로부터, 사용자 장비 (UE) 로부터의 어태치 요청에 기초한 인증 정보 요청을 수신하는 수단으로서, 이 중개 서빙 네트워크를 통해 애플리케이션 서비스 프로바이더 서버가 서비스에 대한 액세스를 후원하고, 인증 정보 요청은 애플리케이션 서비스 프로바이더 서버와 확립된 사전-존재 크리덴셜에 기초하고 서빙 네트워크에 대한 셀룰러 액세스 크리덴셜로서 인식가능하지 않은 클라이언트 토큰을 포함하는, 상기 인증 정보 요청을 수신하는 수단; 인증 정보 요청에 응답하여 애플리케이션 서비스 프로바이더 서버에 의해 액세스가능한 사전-존재 크리덴셜에 기초하여 인증 정보를 결정하는 수단; 및, 서빙 네트워크에 응답하여 인증 정보를 송신하는 수단으로서, 이 인증 정보는, 사전-존재 크리덴셜에 기초하여 서비스에 대한 후원된 액세스를 위해 서빙 네트워크와 UE 사이에서의 인증을 돕는, 상기 인증 정보를 송신하는 수단을 포함한다.
본 개시의 다른 양태들, 특징들, 및 실시형태들은 첨부 도면들과 함께 본 개시의 구체적인, 예시적인 실시형태들의 이하의 설명을 검토 시에 당해 기술분야에서 통상의 지식을 가진 자 (이하, '통상의 기술자' 라 함) 에게 명백하게 될 것이다. 본 개시의 특징들은 이하의 소정의 실시형태들 및 도면들에 대해 논의될 수도 있지만, 본 개시의 모든 실시형태들은 본원에서 논의된 이로운 특징들 중 하나 이상을 포함할 수 있다. 달리 말하면, 하나 이상의 실시형태들은 소정의 유리한 특징들을 갖는 것으로서 논의될 수도 있지만, 이러한 특징들의 하나 이상은 또한 본원에서 논의된 개시의 다양한 실시형태들에 따라서 또한 사용될 수도 있다. 유사한 방식으로, 예시적인 실시형태들은 이하에서 디바이스, 시스템, 또는 방법 실시형태들로서 논의될 수도 있지만, 이러한 예시적인 실시형태들은 다양한 디바이스들, 시스템들, 및 방법들에서 구현될 수 있음을 이해하여야 한다.
도 1 은 본 개시의 다양한 양태들에 따른 무선 통신 네트워크를 나타낸다.
도 2 는 본 개시의 실시형태들에 따른 예시적인 UE 의 블록도이다.
도 3 은 본 개시의 실시형태들에 따른 예시적인 서버의 블록도이다.
도 4 는 본 개시의 다양한 양태들에 따른 예시적인 송신기 시스템을 예시하는 블록도이다.
도 5 는 본 개시의 다양한 양태들에 따른, 후원된 접속을 제공하기 위한 UE, 서빙 네트워크, 및 애플리케이션 서비스 프로바이더 사이의 예시적인 시그널링 양태들을 나타내는 프로토콜도이다.
도 6 은 본 개시의 다양한 양태들에 따른, 후원된 접속을 제공하기 위한 UE, 서빙 네트워크, 및 애플리케이션 서비스 프로바이더 사이의 예시적인 시그널링 양태들을 나타내는 프로토콜도이다.
도 7a 는 본 개시의 다양한 양태들에 따른, 서버에 의해 후원되는 서비스를 위해 네트워크에 액세스하기 위한 예시적인 방법을 나타내는 플로우차트이다.
도 7b 는 본 개시의 다양한 양태들에 따른, 서버에 의해 후원되는 서비스를 위한 네트워크 액세스를 승인하기 위한 예시적인 방법을 나타내는 플로우차트이다.
도 7c 는 본 개시의 다양한 양태들에 따른, 서버에 의해 후원되는 서비스를 위한 네트워크 액세스를 용이하게 하기 위한 예시적인 방법을 나타내는 플로우차트이다.
도 8a 는 본 개시의 다양한 양태들에 따른, 서버에 의해 후원되는 서비스를 위해 네트워크에 액세스하기 위한 예시적인 방법을 나타내는 플로우차트이다.
도 8b 는 본 개시의 다양한 양태들에 따른, 서버에 의해 후원되는 서비스를 위해 네트워크 액세스를 승인하기 위한 예시적인 방법을 나타내는 플로우차트이다.
도 8c 는 본 개시의 다양한 양태들에 따른, 서버에 의해 후원되는 서비스를 위한 네트워크 액세스를 용이하게 하기 위한 예시적인 방법을 나타내는 플로우차트이다.
아래에 기재된 상세한 설명은, 첨부된 도면들과 관련하여, 다양한 구성들의 설명으로서 의도되고 본 명세서에서 설명된 개념들이 실시될 수도 있는 유일한 구성들을 표현하도록 의도되지 않는다. 상세한 설명은 다양한 개념들의 철저한 이해를 제공하는 목적을 위해 특정 상세들을 포함한다. 그러나, 이들 개념들은 이들 특정 상세들 없이 실시될 수도 있다는 것이 통상의 기술자에게 명백할 것이다. 일부 경우들에서, 잘 알려진 구조들 및 컴포넌트들은 이러한 개념들을 모호하게 하는 것을 회피하기 위하여 블록도 형태로 도시된다.
본 명세서에서 설명된 기법들은 CDMA, TDMA, FDMA, OFDMA, SC-FDMA 및 다른 네트워크들과 같은 다양한 무선 통신 네트워크들을 위해 이용될 수도 있다. 용어들 "네트워크" 및 "시스템" 은 종종 상호교환가능하게 사용된다. CDMA 네트워크는 범용 지상 무선 액세스 (Universal Terrestrial Radio Access; UTRA), cdma2000 등과 같은 무선 기술을 구현할 수도 있다. UTRA 는 광대역 CDMA (WCDMA) 및 CDMA 의 다른 변형들을 포함한다. cdma2000 은 IS-2000, IS-95 및 IS-856 표준들을 커버한다. TDMA 네트워크는 GSM (Global System for Mobile Communications) 과 같은 무선 기술을 구현할 수도 있다. OFDMA 네트워크는 진화형 UTRA (E-UTRA), UMB (Ultra Mobile Broadband), IEEE 802.11 (Wi-Fi), IEEE 802.16 (WiMAX), IEEE 802.20, Flash-OFDMA 등과 같은 무선 기술을 구현할 수도 있다. UTRA 및 E-UTRA 는 범용 모바일 전기통신 시스템 (Universal Mobile Telecommunication System; UMTS) 의 일부이다. 3GPP 롱 텀 에볼루션 (Long Term Evolution; LTE) 및 LTE-어드밴스드 (LTE-A) 는 E-UTRA 를 이용하는 UMTS 의 새로운 릴리즈들이다. UTRA, E-UTRA, UMTS, LTE, LTE-A 및 GSM 은 "제 3 세대 파트너십 프로젝트" (3GPP) 로 명명된 기관으로부터의 문서들에 설명되어 있다. CDMA2000 및 UMB 는 "제 3 세대 파트너십 프로젝트 2" (3GPP2) 로 명명된 기관으로부터의 문서들에 설명되어 있다. 본 명세서에서 설명된 기법들은 상기 언급된 무선 네트워크들 및 무선 기술들 뿐만 아니라 다른 무선 네트워크들 및 무선 기술들, 이를 테면 차세대 (예를 들어, 제 5 세대 (5G)) 네트워크를 위해 이용될 수도 있다. 본 개시의 실시형태들은 상기 열거된 네트워크들 및/또는 아직 개발되지 않은 것들 중 임의의 하나 이상 상에서 이용될 수도 있는 임의의 타입의 변조 스킴에 관련된다.
본 개시의 실시형태들은 서빙 네트워크 (예컨대, 진화형 패킷 코어 (evolved packet core; EPC) 네트워크와 같은 코어 네트워크) 상에서 사용자 장비 (UE) 의 후원된 접속 (sponsored connectivity) 을 용이하게 하기 위한 시스템들 및 기법들을 도입한다.
후원된 접속의 하나의 예는 액세스 포인트 네임 (APN)-기반 포워딩이다. APN-기반 포워딩에서, UE 는 후원하는 애플리케이션 서비스 프로바이더 (예컨대, 온라인 마켓플레이스 등) 에 의해 APN 으로 구성된 SIM 카드를 갖는다. UE 는 서빙 네트워크에 데이터 트래픽을 전송하고, 서빙 네트워크는 UE 의 SIM 카드에서 구성된 정보로부터 제공된 서브스크립션 프로파일 정보에 기초하여 외부 네트워크에서의 공중 데이터 네트워크 (PDN) 게이트웨이에서 규칙을 시행한다. APN-기반 포워딩은 따라서, SIM 카드들을 가지지 않는 및/또는 셀룰러 서브스크립션을 가지지 않는 UE 들에 대해 사용될 수 없다는 점에서 제한된다. GBA (generic bootstrapping architecture) 는, 그것이 또한 현재의 서브스크립션 및 SIM 능력을 전제하기 때문에, 유사하게 제한된다.
후원된 접속의 또 다른 예는 애플리케이션-기반 포워딩이다. 이것은, 서빙 네트워크가 UE 로부터의 개별 데이터 패킷들의 인터넷 프로토콜 (IP) 목적지 어드레스들에 기초하여 UE 로부터의 데이터 트래픽을 필터링하는 경우이다. 이것은, UE 들이 SIM 능력 또는 서브스크립션을 가지지 않는 시나리오들에서 작용할 수도 있지만, 몇몇 다른 결점들을 갖는다. 애플리케이션-기반 포워딩은 인증되지 않은 및/또는 허가되지 않은 데이터 트래픽이 서빙 네트워크의 코어 네트워크를 통해 흐르도록 허용한다. 이것은 후원하는 애플리케이션/서비스에 대해 여전히 과금될 수도 있을, 게이트웨이에 의해 모두 핸들링될 수 없는 과도한 요청들/트래픽으로 (게이트웨이와 같은) 서비스 액세스 네트워크를 오버로딩하도록 어택커 (attacker) 에 의해 착취될 수도 있다. 애플리케이션-기반 포워딩은, 서빙 네트워크가 데이터 트래픽을 스캔하고 그것이 후원 수신자를 향해 의도되는지 여부를 결정하여야만 하기 때문에, 가장 자주 비효율적이다. 이 시나리오는 또한, 애플리케이션-기반 포워딩이 많은 다른 후원자들 및/또는 사용자들에 대해 스케일링하기 어렵게 만들 수도 있다.
본 개시의 양태들에 따른 후원된 접속의 용이화는, 특정 시나리오들에서 UE 가, (예컨대, EPC 네트워크에 대한 외부 네트워크 상에서) 접속을 후원하는 애플리케이션 서비스 프로바이더의 서버에 의해 하나 이상의 서비스들을 액세스할 수도 있는 것을 가능하게 할 수 있다. 서버를 통해 서비스를 후원하는 엔티티 (entity) 는 UE 에 의한 어태치 시도 이전에 서빙 네트워크를 프로비저닝할 수 있다. 이 프로비저닝 (provisioning) 은 서빙 네트워크의 오퍼레이터와 서버의 오퍼레이터 사이의 서비스-레벨 합의 (agreement) 의 형태를 취할 수도 있다. 프로비저닝 후에, 서빙 네트워크는 잠재적으로 관심대상의 사용자들에게 후원된 접속을 광고하는 것이 가능하다.
일 실시형태에서, UE 는 서빙 네트워크를 통해 후원된 접속을 발견한 후에 서빙 네트워크에 어태치하기를 시도할 수 있다. 어태치 요청의 일부로서, UE 는 가입자 식별자 대신에 서빙 네트워크에 UE 와 애플리케이션 서비스 프로바이더 사이에 확립된 사전-존재 크리덴셜에 기초하는 클라이언트 토큰 (또는 몇몇 다른 클라이언트-기반 정보) 을 제공한다. 예를 들어, UE 는 (예컨대, UE 는 SIM 카드를 가지지 않고 및/또는 홈 또는 셀룰러 네트워크에 대한 서브스크립션을 가지지 않기 때문에) 임의의 오퍼레이터/서비스 프로바이더 크리덴셜들로 프로비저닝되지 않을 수도 있다. 사전-존재 크리덴셜은 셀룰러 네트워크 특정적 크리덴셜이 아닐 수도 있다. 실제로, 그것은 셀룰러 네트워크 (예컨대, 콘텐츠 프로바이더) 를 동작시키지 않는 애플리케이션 서비스 프로바이더와 연관될 수도 있다. 서빙 네트워크는 후원하는 엔티티의 서버에 대해 어태치 요청을 포워딩할 수 있다. 어태치 요청은 서빙 네트워크의 식별자를 포함할 수 있다. 일 실시형태에서, 후원하는 엔티티의 서버는 (예컨대, 이하 추가로 설명되는 바와 같이 PDN-게이트웨이를 통해 액세스되는) 서빙 네트워크의 코어 네트워크에 대해 외부인 네트워크에 있다. 서버는 멀티-웨이 (multi-way) 핸드쉐이크 (handshake) 를 통해 UE 와 서버 사이에 새로운 공유된 비밀 키를 생성할 수도 있고, 또는 대안적으로, 사용자의 패스워드의 해쉬된 형태를 사용할 수도 있다. 하나의 예로서, 사전-존재 크리덴셜은 UE 와 서버 사이에 확립된 사전-존재 패스워드의 해쉬된 버전일 수 있다. 새로운 공유된 비밀 키의 사용은 인증 벡터 (authentication vector) 의 하나 이상의 엘리먼트들의 생성을 가능하게 한다.
서버는 그 다음, 네트워크 액세스를 용이하게 하는 것을 계속하기 위해 서빙 네트워크에 인증 벡터를 전송할 수 있다. 하나 이상의 네트워크 엘리먼트들은 인증 벡터로부터의 양태들 (예컨대, UE 로부터의 예상되는 응답 및 KASME) 을 추출 및 저장하고, 그 다음, 인증 요청의 일부로서 UE 에 (예컨대, 랜덤 넘버 및 인증 토큰을 포함하는) 나머지에 대해 포워딩할 수 있다. UE 는 인증 요청에 대한 응답을 생성하기 위해, 공유된 비밀 키 또는 대안적으로 사용자의 패스워드의 해쉬된 형태와 같은 동일한 사전-존재 크리덴셜을 사용한다. 이 데이터는 그 다음, 검증 (verification) 을 위해 서빙 네트워크에 다시 역으로 전송될 수 있다. UE 로부터의 응답이 서버에 의해 지정된 예상된 응답과 매치하는 경우에, 어태치 절차가 계속된다. 계속될 때, UE 는, UE 가 서비스 프로바이더와 가입자 아이덴티티 (subscriber identity) 및/또는 서브스크립션을 가지지 않는 경우에도, 후원되는 접속 덕분에 서비스를 액세스하기 위해 서빙 네트워크를 이용하는 것이 가능하다.
대안적인 실시형태에서, UE 는 후원되는 접속의 이점을 취하기 위해서 다른 인증 접근법을 이용할 수도 있다. UE 는 서빙 네트워크에 어태치하기를 시도하지만 어태치 요청과 함께 사전-존재 크리덴셜에 기초하는 클라이언트 토큰을 포함하지 않을 수도 있다. 예를 들어, 서빙 네트워크가 서버에 인증 요청을 포워딩한 후에, 서버는 UE 를 인증하고, 서버가 인증 및 어태치먼트를 완료하기 위해 UE 의 사용자와 연관된 사용자 프로파일을 액세스하기 위해 서빙 네트워크의 하나 이상의 네트워크 엘리먼트들을 승인하기 위한 허가를 수신하기 위해 서빙 네트워크를 통해 UE 와 통신한다. UE 가 (예컨대, 사전-존재 크리덴셜 또는 몇몇 그것의 유도체에 의해) 서버와 성공적으로 인증하는 경우에, 서버는 그 다음, 서빙 네트워크에서의 네트워크 엔티티와 상호작용하여 허가 코드를 네트워크 엘리먼트로 (UE 로 그 다음에 네트워크 엘리먼트로 대신에) 제공할 것이다. 허가 코드는 네트워크 엘리먼트로 하여금, 인증을 완료하고 후원 하에서 UE 를 서빙 네트워크에 어태치하기 위해 UE 와 연관된 사용자 프로파일을 액세스하기 위해 네트워크 엘리먼트들에 의해 사용될 수 있는 액세스 토큰을 획득하는 것을 가능하게 한다.
이제 도면들로 돌아가서, 도 1 은 본 개시의 다양한 양태들에 따른 무선 통신 네트워크 (100) 를 나타낸다. 무선 통신 네트워크 (100) 는 다수의 UE 들 (102), 및 다수의 무선 액세스 네트워크 (RAN) 들 (104) (각각 임의의 수의 기지국들을 포함할 수도 있다) 을 포함할 수도 있다. 도시 및 예시의 단순함을 위해 도 1 에서는 단일 UE (102) 및 단일 RAN (104) 이 예시되었다. RAN (104) 에서의 주어진 기지국은 진화형 노드 B (eNodeB) 를 포함할 수도 있다. 기지국은 또한 베이스 트랜시버 스테이션 또는 액세스 포인트로서 지칭될 수도 있다. 본원에서는 때로는 실시형태들이 LTE/4G 네트워크들을 참조하여 논의되지만, 이것은 예시적인 목적들을 위해 행해진 것이다. 본 개시의 실시형태들은 또한 다수의 다른 네트워크들과 동작가능 및 적용가능하다.
RAN (104) 은 도시한 바와 같이 UE (102) 와 통신한다. UE (102) 는 업링크 및 다운링크를 통해 RAN (104) 과 통신할 수도 있다. 다운링크 (또는 순방향 링크) 는 RAN (104) 에서의 기지국으로부터 UE (102) 로의 통신 링크를 지칭한다. 업링크 (또는 역방향 링크) 는 UE (102) 로부터 RAN (104) 에서의 기지국으로의 통신 링크를 지칭한다.
UE들 (102) 은 무선 네트워크 (100) 전반에 걸쳐 산재될 수도 있고, 각각의 UE (102) 는 정지식 또는 이동식일 수도 있다. UE (102) 는 또한 단말기, 이동국, 가입자 유닛 등으로 지칭될 수도 있다. UE (102) 는 셀룰러 폰, 스마트폰, 개인 휴대 정보 단말기, 무선 모뎀, 랩톱 컴퓨터, 태블릿 컴퓨터, 엔터테인먼트 디바이스, 웨어러블 통신 디바이스, 차량용 컴포넌트, 모바일 컴퓨팅 디바이스, 헬스 모니터링 디바이스, 메디컬 디바이스, 사물 인터넷 디바이스들, M2M/D2D 디바이스들 등일 수도 있다. 무선 통신 네트워크 (100) 는 본 개시의 다양한 양태들이 적용되는 네트워크의 하나의 예이다.
도 1 에는 또한, 이동성 관리 엔티티 (mobility management entity; MME) (106) 가 예시되어 있다. MME (106) 는 세션 관리 및 가입자들 (예를 들어, UE (102)) 에 관련된 제어 평면 기능들을 담당하고 있을 수도 있다. 예를 들어, MME (106) 는 이동성 세션 관리, 뿐만 아니라 다른 네트워크들로의 핸드오버들, 로밍, 및 가입자 인증에 대한 지원을 제공할 수도 있다. MME (106) 는, 몇 가지만 예로 들면, UE (102) 의 초기 어태치 동안의 서빙 게이트웨이 (S-GW) (108) 의 선택, NAS (non-access stratum) 시그널링, NAS 시그널링 보안, 패킷 데이터 네트워크 게이트웨이 (P-GW) (110) 선택, 전용 베어러 확립을 포함한 베어러 관리 기능들, 시그널링 트래픽의 합법적 도청, 및 다른 기능들을 도울 수도 있다. RAN (104), MME (106), S-GW (108), 및 P-GW (110) 는 동일한 서빙 네트워크 (112) (예를 들어, 진화형 패킷 코어 (EPC) 의 일부) 에 있을 수도 있다. 인지될 바와 같이, 서빙 네트워크 (112) 는 본 개시의 양태들의 논의의 단순함을 위해 도 1 에 도시되지 않은 많은 다른 네트워크 엘리먼트들을 포함한다.
MME (106) 는 서빙 네트워크 (112) 에서 S-GW (108) 와 통신한다. S-GW (108) 는, RAN (104) 을 향한 인터페이스를 종단하는 게이트웨이일 수도 있고, 기지국간 핸드오버를 보조하며, 단지 몇몇 예들을 들어보면, 상이한 표준들 (예컨대, 2G, 3G, 4G, LTE, 5G 및 장래의 네트워크들 등) 사이의 이동성을 위한 이동성 앵커링, 합법적 차단, 패킷-기반 라우팅 및 포워딩, 오퍼레이터 간 과금을 위한 어카운팅을 제공한다. S-GW (108) 는 UE (102) 로부터 예를 들어 P-GW (110) 로 데이터 패킷들을 라우팅 및 포워딩한다. 도 1 은 단순함을 위해 단일의 P-GW (110) 를 도시하지만, 데이터가 다이렉팅될 수도 있는 (서빙 네트워크 (112) 에 대한) 다수의 외부 네트워크들이 존재함을 인식할 것이고, 여기서, 네트워크 (114) 는 단지 하나의 예이다. P-GW (110) 는 UE (102) 로의/로부터의 데이터 트래픽에 대한 출입의 포인트로서 서빙 네트워크 (112) 와 외부 패킷 데이터 네트워크 사이의 접속을 제공한다. P-GW (110) 는 단지 몇몇 예들만 들어보면, 사용자 단위 당 기반의 패킷 필터링, 합법적 차단, 서비스 레벨 게이팅 제어, 서비스 레벨 레이트 시행, 및 패킷 스크리닝에서 관여될 수도 있다.
도 1 에서 예시된 바와 같이, P-GW (110) 는 UE (102) 와 서버 (116) 사이에 네트워크 (114) 를 통해 이동하는 데이터 패킷들에 대한 출입 포인트를 제공한다. 서버 (116) 는 후원을 제공하는 엔티티에 의해 동작될 수도 있다. 일 실시형태에서, 후원은 사용자가 하나 이상의 서비스들 (예컨대, 콘텐츠 스트리밍, 온라인 브라우징, 온라인 구매 등) 에 대해 애플리케이션 서비스 프로바이더에 지불하는 것을 포함할 수도 있다. 응답하여, 애플리케이션 서비스 프로바이더는 사용자와의 계약에 기초하여, 셀룰러 (서빙) 네트워크와 같이, 사용자의 UE 에 대해 네트워크를 통해 후원된 접속을 가능하게 한다. 다른 실시형태에서, 후원된 접속은, 사용자 기반을 증가시키기 위한 애플리케이션 서비스 프로바이더에 의한 시도에 기초하여 사용자의 UE 에 대해 무료로 이용가능하게 될 수도 있다 (예컨대, 애플리케이션 서비스 프로바이더가 서비스에 대해 셀룰러 네트워크에 지불한다). 대안적으로, 후원된 접속을 위한 요금은 사용자로부터 대신에 수익과 같은 다른 소스들로부터 수집된 요금으로부터 수집될 수도 있다.
서버 (116) 는 본 명세서에서 애플리케이션 서비스 프로바이더 또는 애플리케이션 서비스 프로바이더 서버로서 지칭될 수도 있다. 일 실시형태에서, 서버 (116) 는 그 자체로 하나 이상의 서비스들을 호스팅할 수도 있다. 비록 하나의 서버로서 도시되지만, 서버 (116) 는 단독형 시스템 또는 (예컨대, 하나 이상의 서비스들을 제공하기 위해) 협동하여 동작하는 다수의 시스템들일 수도 있다. 서비스들은, (애플리케이션 서비스 프로바이더의 서버 (116) 에 의해 호스팅되든지 또는 그외에서 호스팅되든지 간에) 예를 들어, 온라인 마켓플레이스, 소셜 미디어 네트워크, 서치 프로바이더, 일반적 인터넷/네트워크 액세스, 콘텐츠 프로바이더, 인터넷 액세스 통신 등 많은 것들 중에서 임의의 특정 서비스일 수도 있다.
후원되는 서비스는 서버 (116) 에 의해 호스팅되는 애플리케이션 서비스 프로바이더에 의해 결정될 수도 있다. 예를 들어, 이것은 서빙 네트워크 (112) 와 애플리케이션 서비스 프로바이더 사이의 합의의 프로비저닝 시에 발생할 수도 있다. 다른 시나리오에서, 후원되는 서비스는 서빙 네트워크 (112) 와 애플리케이션 서비스 프로바이더 사이의 이전에 합의된 (프로비저닝된) 서비스들의 리스트로부터의 어태치 요청 시에 서버 (116) 에 의해 결정될 수도 있다. 이것은 UE (102) 또는 서빙 네트워크 (112) 로 부터의 구체적으로 요청된 서비스, 또는 서버 (116) 에 의한 식별된 서비스 중 어느 일방에 기초할 수도 있다.
UE (102) 의 사용자는 예를 들어 서버 (116) 에 의해 유지되는 패스워드 및 사용자 명칭에 사용자 계정을 등록함으로써 애플리케이션 서비스 프로바이더와의 관계를 사전에 확립했을 수도 있다. 본 개시의 실시형태들에 따르면, 애플리케이션 서비스 프로바이더의 서버 (116) 는 또한, 서빙 네트워크 (112) 와의 UE 어태치 절차들을 위해 필요하거나 유용할 수도 있는 그들 양태들을 포함하는, 홈 가입자 서버 (home subscriber server; HSS) 의 수개의 양태들을 복제한다. 이것은, 몇몇 예들을 들어보면, UE 와 연관된 사용자의 사용자 명칭 및 패스워드 (및 그것의 임의의 해쉬들/기타) 및 (사용자 아이덴티티 키로부터의 보안 정보 생성 및 네트워크 엔티티들에 대한 보안 정보의 프로비저닝의 관리를 포함하는) 인증 기능들을 포함할 수도 있다.
UE, 서빙 네트워크, 및 애플리케이션 서비스 프로바이더의 서버를 포함하는 후속 도면들과 관련하여 이하 보다 자세히 설명되는 바와 같이, UE (102) 는 클라이언트 토큰을 이용하여 서빙 네트워크 (112) 및 서버 (116) 와 통신할 수도 있다. 클라이언트 토큰은 UE (102) 의 사용자 (또는 UE (102) 그 자체) 와 애플리케이션 서비스 프로바이더 사이에 이전에 확립된 사전-존재 크리덴셜 (예컨대, 패스워드, 하이 엔트로피 키 등의 일부 변형) 에 기초 (로부터 도출) 할 수 있다. 클라이언트 토큰/사전-존재 크리덴셜은 서빙 네트워크 (112) 를 통해 후원되는 접속을 획득하기 위해 본 개시의 실시형태들에 따라 사용될 수도 있다. 사전-존재 크리덴셜을 이용함으로써, SIM 카드들을 가지지 않고 및/또는 서브스크립션들을 가지지 않는 UE 들은, 사전-존재 크리덴셜과 연관된 애플리케이션 서비스 프로바이더를 통해, 및 (애플리케이션 서비스 프로바이더의 특정 후원에 기초하여 커버되는 그들의 다른 타입의 서비스 또는 데이터 사용을 가지기 위해) 서브스크립션들을 가질 수도 있는 UE 들을 통해, 후원된 접속을 여전히 획득할 수도 있다.
일 실시형태에서, 후원된 접속은 다양한 상이한 양태들을 지칭할 수도 있다. 예를 들어, 후원된 접속은 (예컨대, 서버 (116) 에 의해 제공되는 애플리케이션 서비스 또는 후원 하에 상이한 프로바이더로부터의 서비스를 액세스/사용할 목적을 위해) 서빙 네트워크 (112) 에 대한 전체적인 액세스를 지칭할 수도 있다. 다른 시나리오들은, 몇몇 예들을 들어 보면, 미리결정된 양의 시간 (및/또는 횟수) 동안 서비스에 대한 전체적 또는 부분적인 액세스, 일반적으로 특정된 기간/데이터 양/데이터 폭에 대한 네트워크에 대한 전체적 또는 부분적인 액세스, 일반적으로 미리결정된 양의 데이터 (예컨대, 바이트들 또는 몇몇 다른 사이즈/메트릭으로 추적됨) 에 대한 서비스 및/또는 네트워크에 대한 전체적 또는 부분적인 액세스를 포함한다.
일 예에서, UE (102) 는, RAN (104) 에 대한 그것의 초기 어태치 요청의 일부로서, 다른 전통적인 식별자들 대신에 사전-존재 크리덴셜에 기초하는 클라이언트 토큰을 전송할 수도 있다. 전통적인 식벼자의 일 예는 국제 모바일 가입자 아이덴티티 (international mobile subscriber identity; IMSI) 이다. 이것은, 본 개시의 실시형태들은 일부 종류의 가입자 식별자 대신에 사전-존재 크리덴셜의 사용을 가능하게 하여, 홈 네트워크에 대한 서브스크립션 또는 SIM 카드를 가지지 않는 UE 들이, (예컨대, P-GW (110) 에서 먼저 필터링되는 서빙 네트워크 (112) 상의 임의의 IP 트래픽을 허용하지 않음으로써) 서빙 네트워크들 (112) 에 걸친 더 큰 효율성 및 보안성을 초래하는 방식으로 후원된 접속을 여전히 이용할 수도 있기 때문이다. 어태치 요청은 또한 UE (102) 가 통신하기를 희망하지 않는 애플리케이션 서비스 프로바이더 (즉, 사용자가 사전-존재 크리덴셜 (해쉬된 패스워드/사용자명칭, 하이 엔트로피 키 등) 를 갖는 애플리케이션 서비스 프로바이더) 를 식별할 수도 있다. RAN (104) 은 UE 의 클라이언트 토큰 및 서비스 식별표시를 갖는 어태치 요청을 MME (106) 에 포워딩한다. MME (106) 는 어태치 요청에서 그 정보와 함께 서빙 네트워크 식별자를 포함하고, 인증 정보 요청으로서 S-GW (108) 에 그리고 그 다음에 P-GW (110) 에 포워딩한다. 서버 (116) 는 (예컨대, UE (102) 로부터의 어태치 요청에 의해 트리거되는) 서빙 네트워크 (112) 로부터의 인증 정보 요청에서 제공된 액세스 토큰에 기초하여 UE (102) 를 식별하는 것이 가능하다. 후원된 접속을 획득하기 위한 기존의 크리덴셜의 사용은 애플리케이션 서비스 프로바이더의 후원된 서비스 (또는 애플리케이션 서비스 프로바이더 (116) 에 의해 후원되는 다른 프로바이더에 의한 다른 서비스) 에 접속하는 UE 들의 양을 증가시킬 수도 있다.
도 2 는 본 개시의 실시형태들에 따른 예시적인 UE (102) 의 블록도이다. UE (102) 는 본원에서 설명된 많은 구성들 중 임의의 하나를 가질 수도 있다. UE (102) 는 프로세서 (202), 메모리 (204), 액세스 모듈 (208), 트랜시버 (210), 및 안테나 (216) 를 포함할 수도 있다. 이들 엘리먼트들은 예를 들어, 하나 이상의 버스들을 통해, 서로 직접 또는 간접 통신하고 있을 수도 있다.
프로세서 (202) 는 특정 타입의 프로세서로서 다양한 피처들을 가질 수도 있다. 예를 들어, 이들은 중앙 프로세싱 유닛 (CPU), 디지털 신호 프로세서 (DSP), 애플리케이션-특정 집적 회로 (ASIC), 제어기, 필드 프로그래밍가능 게이트 어레이 (FPGA) 디바이스, 다른 하드웨어 디바이스, 펌웨어 디바이스, 또는 도 1 에 대하여 상기 도입된 UE (102) 를 참조하여 본 명세서에서 설명되고 아래에 더 상세히 논의된 동작들을 수행하도록 구성된 그 임의의 조합을 포함할 수도 있다. 프로세서 (202) 는 또한 컴퓨팅 디바이스들의 조합, 예를 들어, DSP 와 마이크로프로세서의 조합, 복수의 마이크로프로세서들, DSP 코어와 결합된 하나 이상의 마이크로프로세서들, 또는 임의의 다른 이러한 구성으로서 구현될 수도 있다.
메모리 (204) 는 또한 다양한 피처들을 가질 수도 있다. 예를 들어, 이들은 캐시 메모리 (예를 들어, 프로세서 (442) 의 캐시 메모리), 랜덤 액세스 메모리 (RAM), 자기저항식 RAM (MRAM), 판독-전용 메모리 (ROM), 프로그래밍가능 판독-전용 메모리 (PROM), 소거가능한 프로그래밍가능 판독 전용 메모리 (EPROM), 전기적으로 소거가능한 프로그래밍가능 판독 전용 메모리 (EEPROM), 플래시 메모리, 솔리드 스테이트 메모리 디바이스, 하드 디스크 드라이브들, 멤리스터-기반 어레이들, 다른 형태들의 휘발성 및 비휘발성 메모리, 또는 상이한 타입들의 메모리의 조합을 포함할 수도 있다. 일부 실시형태들에서, 메모리 (204) 는 비일시적 컴퓨터 판독가능 매체를 포함할 수 있다.
메모리 (204) 는 명령들 (206) 을 저장할 수도 있다. 명령들 (206) 은, 프로세서 (202) 에 의해 실행될 때, 프로세서 (202) 로 하여금, 본 개시의 실시형태들과 관련하여 UE (102) 를 참조하여 본 명세서에서 설명된 동작들을 수행하게 하는 명령들을 포함할 수도 있다. 명령들 (206) 은 코드로 또한 지칭될 수도 있다. 용어들 "명령들" 및 "코드" 는 임의의 타입의 컴퓨터 판독가능 스테이트먼트(들)를 포함하는 것으로 폭넓게 해석되어야 한다. 예를 들어, 용어들 "명령들" 및 "코드" 는 하나 이상의 프로그램들, 루틴들, 서브-루틴들, 함수들, 펌웨어, 미들웨어, 마이크로코드, 절차들, 등을 지칭할 수도 있다. "명령들" 및 "코드" 는 단일의 컴퓨터 판독가능 스테이트먼트 또는 다수의 컴퓨터 판독가능 스테이트먼트들을 포함할 수도 있다.
액세스 모듈 (208) 은 본 개시의 다양한 양태들에 대해 사용될 수도 있다. 예를 들어, 액세스 모듈 (208) 은 UE (102) 에 의해 유지되는 하나 이상의 사전-존재 크리덴셜들 (및/또는 그것의 유도체) 의 저장 및 취출 (retrieval) 을 제어할 수도 있다. 액세스 모듈 (208) 은, 예컨대 UE (102) 의 사용자의 지시 하에, (몇몇 예들을 들어보면) 입력 소스로부터 패스워드, 사용자 명칭/패스워드 조합, 하이 엔트로피 키, 토큰, 또는 아이덴티티 증명서를 수신하고, (사용자 명칭 및 패스워드와 같은) 크리덴셜을 저장 로케이션으로 다이렉팅할 수도 있다. 일 실시형태에서, UE (102) 는 애플리케이션 서비스 프로바이더와 사용자에 의해 확립된 패스워드의 이미-해쉬된 버전으로서 애플리케이션 서비스 프로바이더로부터 사전-존재 크리덴셜을 수신할 수도 있다. 또한, 액세스 모듈 (208) 은 사전-존재 크리덴셜로부터 어태치 요청에서 사용될 클라이언트 토큰을 결정할 수도 있다. 클라이언트 토큰은 패스워드 크리덴셜로부터 결정될 수도 있다. 예를 들어, 클라이언트 토큰은, 나중의 도면들과 관련하여 이하 보다 자세히 논의되는 바와 같이, 솔트 (salt), 논스 (nonce) 값, 및/또는 다른 값들과 같이, 하나 이상의 추가들로 패스워드를 해쉬함으로써 결정될 수도 있다.
액세스 모듈 (208) 은 또한 어태치 절차 동안 역시 사용될 수도 있다. 예를 들어, UE (102) 가 후원된 접속을 이용하여 서빙 네트워크 (112) 에 대한 어태치를 시도하고 있을 때, 액세스 모듈 (208) 은 어태치 요청에 포함시키기 위해 사전-존재 크리덴셜에 기초하여 클라이언트 토큰을 취출 (요구되는 시간에 동적으로 도출/결정) 할 수도 있다. 나중에, UE (102) 가 서빙 네트워크 (112) 와의 상호 인증 동안 인증 토큰을 수신할 때, 액세스 모듈 (208) 은, 예컨대, 이 목적을 위해 액세스 모듈 (208) 에 의해 유지되는 (또는 결정된) 하나 이상의 키들을 액세스 (또는 결정) 함으로써, 인증 토큰에 응답하여 인증을 결정 및 생성하는 것을 도울 수도 있다.
트랜시버 (210) 는 모뎀 서브시스템 (212) 및 무선 주파수 (RF) 유닛 (214) 을 포함할 수도 있다. 트랜시버 (210) 는 UE (102) 의 통신 인터페이스일 수도 있고, 또는, UE (102) 를 위한 통신 인터페이스의 컴포넌트일 수도 있다. 트랜시버 (210) 는 RAN (104) 에서의 기지국들과 같은 다른 디바이스들과 양방향으로 통신하도록 구성된다. 모뎀 서브시스템 (212) 은 변조 및 코딩 스킴 (MCS), 예를 들어, 저밀도 패리티 체크 (low-density parity check; LDPC) 코딩 스킴, 터보 코딩 스킴, 콘볼루션 코딩 스킴, 등에 따라 액세스 모듈 (208) 및/또는 메모리 (204) 로부터 데이터를 변조 및/또는 인코딩하도록 구성될 수도 있다. RF 유닛 (214) 은 (아웃바운드 송신들에 대한) 모뎀 서브시스템 (212) 으로부터의 또는 RAN (104) 에서의 기지국과 같은 다른 소스에서 비롯되는 송신들의 변조된/인코딩된 데이터를 프로세싱 (예를 들어, 아날로그 투 디지털 컨버전 또는 디지털 투 아날로그 컨버전 등을 수행) 하도록 구성될 수도 있다. 트랜시버 (210) 에 함께 통합된 것으로서 도시되지만, 모뎀 서브시스템 (212) 및 RF 유닛 (214) 은 UE (102) 가 다른 디바이스들과 통신하는 것을 가능하게 하기 위해 UE (102) 에서 함께 커플링되는 별개의 디바이스들일 수도 있다.
RF 유닛 (214) 은 하나 이상의 다른 디바이스들로의 송신을 위해 안테나 (216) 에 변조된 및/또는 프로세싱된 데이터, 예를 들어, 데이터 패킷들 (또는, 더 일반적으로는, 하나 이상의 데이터 패킷들 및 PMSI 값들을 포함한 다른 정보를 포함할 수도 있는 데이터 메시지들) 을 제공할 수도 있다. 이것은, 예를 들어, 본 개시의 실시형태들에 따른 RAN (104) 으로의 데이터 메시지들의 송신을 포함할 수도 있다. 안테나 (216) 는 또한, RAN (104) 으로부터 송신된 데이터 메시지들을 수신하고 수신된 데이터 메시지들을 트랜시버 (210) 에서의 프로세싱 및/또는 복조를 위해 제공할 수도 있다. 도 2 는 단일의 안테나로서 안테나 (216) 를 예시하지만, 안테나 (216) 는 다수의 송신 링크들을 유지하기 위하여 유사한 또는 상이한 설계들의 다수의 안테나들을 포함할 수도 있다.
도 3 은 본 개시의 실시형태들에 따른 예시적인 서버 (116) 의 블록도이다. 서버 (116) 는 프로세서 (302), 메모리 (304), 액세스 모듈 (308), 서비스 (310), 데이터베이스 (312), 및 트랜시버 (314) 를 포함할 수도 있다. 이들 엘리먼트들은 예를 들어, 하나 이상의 버스들을 통해, 서로 직접 또는 간접 통신하고 있을 수도 있다. 도 1 에 대하여 상기 언급한 바와 같이, 서버 (116) 는 하나 이상의 서비스들을 호스팅하고, 사용자 크리덴셜들 (사용자 명칭/패스워드, 토큰, 증명서, 및/또는 패스워드 크리덴셜들로부터 도출되는 사전-존재 크리덴셜들 및/또는 사전-존재 크리덴셜들로부터 도출되는 클라이언트 토큰들) 의 데이터베이스를 유지하며, 또한 HSS 의 수개의 양태들을 복제할 수도 있다.
프로세서 (302) 는 특정-타입의 프로세서로서 다양한 특징들을 가질 수도 있다. 예를 들어, 이들은 CPU, DSP, ASIC, 제어기, FPGA 디바이스, 다른 하드웨어 디바이스, 펌웨어 디바이스, 또는 상기 도 1 에서 도입된 서버 (116) 를 참조하여 본 명세서에서 설명된 동작들을 수행하도록 구성된 그 임의의 조합을 포함할 수도 있다. 프로세서 (302) 는 또한, 컴퓨팅 디바이스들의 조합, 예를 들어, DSP 와 마이크로프로세서의 조합, 복수의 마이크로프로세서들, DSP 코어와 결합된 하나 이상의 마이크로프로세서들, 또는 임의의 다른 이러한 구성으로서 구현될 수도 있다.
메모리 (304) 는 캐시 메모리 (예를 들어, 프로세서 (302) 의 캐시 메모리), RAM, MRAM, ROM, PROM, EPROM, EEPROM, 플래시 메모리, 솔리드 스테이트 메모리 디바이스, 하나 이상의 하드 디스크 드라이브들, 멤리스터-기반 어레이들, 다른 형태들의 휘발성 및 비휘발성 메모리, 또는 상이한 타입들의 메모리의 조합을 포함할 수도 있다. 일부 실시형태들에서, 메모리 (304) 는 비일시적 컴퓨터 판독가능 매체를 포함할 수도 있다. 메모리 (304) 는 명령들 (306) 을 저장할 수도 있다. 명령들 (306) 은, 프로세서 (302) 에 의해 실행될 때, 프로세서 (302) 로 하여금, 본 개시의 실시형태들과 관련하여 서버 (116) 를 참조하여 본 명세서에서 설명된 동작들을 수행하게 하는 명령들을 포함할 수도 있다. 명령들 (306) 은 또한, 도 2 에 대하여 상기 논의한 바와 같은 임의의 타입의 컴퓨터 판독가능 스테이트먼트(들)를 포함하는 것으로 폭넓게 해석될 수도 있는 코드로 지칭될 수도 있다.
액세스 모듈 (308) 은 본 개시의 다양한 양태들을 위해 사용될 수도 있다. 예를 들어, 액세스 모듈 (308) 은 하나 이상의 서빙 네트워크들 (112) 을 통해 하나 이상의 식별된 서비스들의 후원된 접속을 확립하기 위해 서비스 네트워크의 초기 프로비저닝에 관여될 수도 있다. 또한, 액세스 모듈 (308) 은 애플리케이션-특정 서비스 (310) 와 협동하여 UE (102) 및/또는 UE (102) 의 사용자와 연관된 하나 이상의 저장된 (사전-존재) 크리덴셜들을 취출할 수도 있다. 예를 들어, 액세스 모듈 (308) 은, 서비스 (310) 가 그것을 거기에 저장한 후에 데이터베이스 (312) 로부터 사전-존재 크리덴셜을 취출할 수도 있다.
액세스 모듈 (308) 은 UE (102) 와의 초기 어태치 절차에 추가적으로 관여될 수도 있다. 서버 (116) 는 UE (102) 로부터의 초기 어태치 요청과 함께 제공되는 사전-존재 크리덴셜에 기초하는 클라이언트 토큰을 수신하고, 데이터베이스 (312) 에 저장된 사용자 정보에 대해 대응하는 사전-존재 크리덴셜 (및 사용자 명칭, 그것이 어태치 요청에서 포함되는 실시형태들에서) 을 체크할 수도 있다. UE (102) 로부터의 어태치 요청에 응답하여, 애플리케이션 서비스 프로바이더의 서버 (116) 는 사전-존재 크리덴셜에 기초한 예상되는 응답 및 하나 이상의 키들을 생성 또는 액세스하고, 이들을 초기 어태치 요청에 대한 인증 요청 응답 (예컨대, 인증 벡터) 의 일부로서 UE (102) 에 송신할 수도 있다.
서비스 (310) 는 많은 것들 중에서 임의의 특정 서비스, 예컨대, 온라인 마켓플레이스, 소셜 미디어 네트워크, 서치 프로바이더, 서비스 프로바이더 등일 수도 있다. 일 실시형태에서, 서버 (116) 에 의해 표현되는 애플리케이션 서비스 프로바이더는 서비스 (310) 에 대한 접속을 후원한다. 대안적인 실시형태에서, 서비스 (310) 는 애플리케이션 서비스 프로바이더와는 상이한 엔티티들에 의해 제공되지만 그것을 위해 (서버 (116) 에 의해 표현되는) 애플리케이션 서비스 프로바이더가 UE (102) 가 액세스하도록 서빙 네트워크 (112) 를 통해 후원을 제공하는 하나 이상의 서비스들을 나타낸다.
서버 (116) 를 동작시키는 애플리케이션 서비스 프로바이더는, 예를 들어, UE (102) 또는 몇몇 다른 통신 가능 디바이스를 통해, 애플리케이션-특정 서비스에 대한 액세스 권한들을 확립하기 위해 대역외 채널을 통해 UE (102) 의 사용자와 상호작용할 수도 있다. 이것은 예를 들어 애플리케이션 서비스 프로바이더와의 등록, 사용자 선호도들의 확립, (적용가능한 경우) 액세스 또는 사용 요금의 지불을 포함할 수도 있다. 대역외 채널을 통한 (여기서 서버 (116) 에 의해 표현되는 바와 같이) 애플리케이션 서비스 프로바이더와의 사용자 명칭 및 패스워드의 확립은, 후원된 접속에 대한 어태치 요청 이전의 몇몇 시점에서 발생할 수도 있고, 예를 들어, WLAN, LAN, Wi-Fi, 피어-투-피어, 메쉬, 또는 도 1 의 서빙 네트워크 (112) 와 같은 셀룰러 네트워크 외의 몇몇 다른 네트워크를 통해 발생할 수도 있다. 애플리케이션 서비스 프로바이더는, UE (102) 가 예를 들어 솔트, 논스 값, 및/또는 다른 값들과 같은, 하나 이상의 추가들로 패스워드들을 해쉬함으로써 후원된 접속을 획득하기 위한 기초로서 나중에 사용할 수도 있는 사전-존재 크리덴셜(들)을, 예를 들어 액세스 모듈 (308) 에 의해, 결정할 수도 있다.
데이터베이스 (312) 는 서버 (116) 에 의해 유지되는 하나 이상의 데이터베이스들, 예를 들어, 구체적으로 애플리케이션 서비스 프로바이더 및 액세스 모듈 (308) 을 대신하여 사용자 명칭들 및 대응하는 사전-존재 크리덴셜들 (또는 대안적인 실시형태들에서 패스워드들) 을 유지하는 데이터베이스를 포함할 수도 있다. 데이터베이스 (312) 는 (예를 들어, 애플리케이션 서비스 프로바이더를 통해 후원되는 접속을 획득 또는 요청하는 UE 들의 전부 또는 서브셋트의 모바일 전화 번호들의 하나 이상을 포함하는) 사용자 식별표시 및 주소와 같은 후원되는 액세스 정보, 프로파일 정보, 및 사전-존재 크리덴셜들 (예컨대, 사전-존재 크리덴셜, 패스워드, 아이덴티티 증명서, 하이 엔트로피 키, 및/또는 하나 이사으이 보안 키들) 을 갖는 사용자와 연관된 또는 그것들을 갖는 각각의 UE 와 연관된 보안 정보를 추적할 수도 있다.
트랜시버 (314) 는, 서버 (116) 로 하여금, 서빙 네트워크 (108) 와 같은 외부 소스들로부터 데이터를 송신 및 수신하기 위해 통신하는 것을 가능하게 한다. 트랜시버 (314) 는 무선 및/또는 유선 통신들을 가능하게 할 수도 있다. 트랜시버 (314) 는 인지될 바와 같이, 예를 들어, 이더넷 접속, WiFi 접속, 또는 다른 타입들의 모뎀 및/또는 RF 서브시스템들을 포함할 수도 있다. 트랜시버 (314) 는 서버 (116) 에 대한 통신 인터페이스이거나 서버 (116) 에 대한 통신 인터페이스의 컴포넌트일 수도 있다.
도 4 는 본 개시의 소정의 양태들에 따른 MIMO 시스템 (400) 에서의 예시적인 송신기 시스템 (410) (예를 들어, RAN (104) 에서의 기지국) 및 수신기 시스템 (450) (예를 들어, UE (102)) 을 예시하는 블록도이다. 송신기 시스템 (410) 에서, 다수의 데이터 스트림들에 대한 트래픽 데이터는 데이터 소스 (412) 로부터 송신 (TX) 데이터 프로세서 (414) 에 제공된다. 트래픽 데이터는 본 개시의 양태들에 따른 하나 이상의 MME 엔티티들로부터의 인증 요청들을 포함하여, 온갖 종류의 트래픽을 포함할 수도 있다.
예를 들어, 다운링크 송신에서, 각각의 데이터 스트림은 개별의 송신 안테나를 통해 송신된다. TX 데이터 프로세서 (414) 는 코딩된 데이터를 제공하기 위해 그 데이터 스트림에 대해 선택된 특정한 코딩 스킴에 기초하여 각각의 데이터 스트림에 대한 트래픽 데이터를 포맷팅, 코딩, 및 인터리빙한다.
각각의 데이터 스트림에 대한 코딩된 데이터는 OFDM 기법들을 이용하여 파일럿 데이터와 멀티플렉싱될 수도 있다. 파일럿 데이터, 예를 들어, 파일럿 시퀀스는, 통상적으로 알려진 방식으로 프로세싱되는 알려진 데이터 패턴이고 채널 응답 또는 다른 채널 파라미터들을 추정하기 위해 수신기 시스템에서 이용될 수도 있다. 파일럿 데이터는 파일럿 심볼들로 포맷팅될 수도 있다. OFDM 심볼 내의 파일럿 심볼들의 수 및 파일럿 심볼들의 배치는 프로세서 (430) 에 의해 수행된 명령들에 의해 결정될 수도 있다.
각각의 데이터 스트림에 대한 멀티플렉싱된 파일럿 및 코딩된 데이터는 그 후 변조 심볼들을 제공하기 위해 그 데이터 스트림에 대해 선택된 특정한 변조 스킴 (예를 들어, BPSK, QSPK, M-PSK, 또는 M-QAM) 에 기초하여 변조된다 (즉, 심볼 맵핑된다). 각각의 데이터 스트림에 대한 데이터 레이트, 코딩, 및 변조는 프로세서 (430) 에 의해 수행된 명령들에 의해 결정될 수도 있다. 각각의 프레임에서의 파일럿 심볼들의 수 및 파일럿 심볼들의 배치는 또한, 예를 들어, 도 2 또는 도 3 에 대하여 상기 설명한 바와 같이, 프로세서 (430) 에 의해 수행된 명령들에 의해 결정될 수도 있다. 송신기 시스템 (410) 은 물론 예를 들어, 도 2 또는 도 3 에 대하여 상기 설명한 바와 같이, 메모리 (432) 를 더 포함한다.
모든 데이터 스트림들에 대한 변조 심볼들은 그 후 (예를 들어, OFDM 을 위해) 변조 심볼들을 추가로 프로세싱할 수도 있는 TX MIMO 프로세서 (420) 에 제공된다. TX MIMO 프로세서 (420) 는 그 후 NT 개의 변조 심볼 스트림들을 NT 개의 송신기들 (TMTR) (422a 내지 422t) 에 제공한다. 일부 실시형태들에서, TX MIMO 프로세서 (420) 는 빔포밍 가중치들을 데이터 스트림들의 심볼들에 그리고 심볼이 송신되고 있는 안테나에 적용한다. 송신기 시스템 (410) 은 단 하나의 안테나를 갖거나 또는 다수의 안테나들을 갖는 실시형태들을 포함한다.
각각의 송신기 (422) 는 하나 이상의 아날로그 신호들을 제공하기 위해 개별의 심볼 스트림을 수신 및 프로세싱하고, MIMO 채널을 통한 송신에 적합한 변조된 신호를 제공하기 위해 아날로그 신호들을 추가로 컨디셔닝 (예를 들어, 증폭, 필터링, 및 업컨버팅) 한다. 송신기들 (422a 내지 422t) 로부터의 NT 개의 변조된 신호들은 그 후 각각 NT 개의 안테나들 (424a 내지 424t) 로부터 송신된다. 본 명세서에서 설명된 기법들은 또한 단 하나의 송신 안테나를 가진 시스템들에 적용된다. 하나의 안테나를 이용한 송신은 멀티-안테나 시나리오보다 더 단순하다. 예를 들어, 단일의 안테나 시나리오에서는 TX MIMO 프로세서 (420) 에 대한 필요성이 없을 수도 있다.
수신기 시스템 (450) 에서, 송신된 변조된 신호들은 NR 개의 안테나들 (452a 내지 452r) 에 의해 수신되고, 각각의 안테나 (452) 로부터의 수신된 신호는 개별의 수신기 (RCVR) (454a 내지 454r) 에 제공된다. 각각의 수신기 (454) 는 개별의 수신된 신호를 컨디셔닝 (예를 들어, 필터링, 증폭, 및 다운컨버팅) 하고, 컨디셔닝된 신호를 디지털화하여 샘플들을 제공하고, 샘플들을 추가로 프로세싱하여 대응하는 "수신된" 심볼 스트림을 제공한다. 본 명세서에서 설명된 기법들은 또한 단 하나의 안테나 (452) 를 갖는 수신기 시스템 (450) 의 실시형태들에 적용된다.
RX 데이터 프로세서 (460) 는 그 후 NT 개의 검출된 심볼 스트림들을 제공하기 위해 특정한 수신기 프로세싱 기법에 기초하여 수신기들 (454a 내지 454r) 로부터 NR 개의 수신된 심볼 스트림들을 수신 및 프로세싱한다. RX 데이터 프로세서 (460) 는 그 후 데이터 스트림에 대한 트래픽 데이터를 복구하기 위해 각각의 검출된 심볼 스트림을 필요에 따라 복조, 디인터리빙, 및 디코딩한다. 복구된 트래픽은 예를 들어, 본 개시의 양태들에 따라 MME 로부터의 인증 정보 요청에서의 정보를 포함할 수도 있다. RX 데이터 프로세서 (460) 에 의한 프로세싱은 송신기 시스템 (410) 에서 TX MIMO 프로세서 (420) 및 TX 데이터 프로세서 (414) 에 의해 수행한 것과 상보적일 수 있다.
RX 데이터 프로세서 (460) 에 의해 제공된 정보는 프로세서 (470) 가 TX 데이터 프로세서 (438) 에 제공할 채널 상태 정보 (CSI) 및 다른 정보와 같은 레포트들을 생성하는 것을 허용한다. 프로세서 (470) 는 송신기 시스템에 송신할 CSI 및/또는 파일럿 요청을 포함하는 역방향 링크 메시지를 포뮬레이션한다.
프로세서 (470) 는 예를 들어 도 2 또는 도 3 에서 설명된 프로세서들에 대하여 상기 설명한 바와 같이 구현될 수도 있다. 역방향 링크 메시지들에 더하여, 수신기 시스템 (450) 은, 서빙 네트워크 (112) 에 대한 후원되는 접속을 위한 사전-존재 크리덴셜들에 기초하는 클라이언트 토큰들을 포함하는 어태치 요청들, 상호 인증을 위한 응답들, 및 후원되는 통신 세션 뿐만 아니라 그 통신 세션 중의 데이터를 확립하기 위한 다른 정보를 포함하는 다른 다양한 타입들의 정보를 송신할 수도 있다. 메시지는 TX 데이터 프로세서 (438) 에 의해 프로세싱되고, TX MIMO 프로세서 (480) 에 의해 변조되고, 송신기들 (454a 내지 454r) 에 의해 컨디셔닝되고, 그리고 다시 송신기 시스템 (410) 에 송신될 수 있다. 도시한 바와 같이, TX 데이터 프로세서 (438) 는 데이터 소스 (436) 로부터 다수의 데이터 스트림들에 대한 트래픽 데이터를 또한 수신할 수도 있다.
송신기 시스템 (410) 에서, 수신기 시스템 (450) 으로부터의 변조된 신호들은 안테나들 (424) 에 의해 수신되고, 수신기들 (422) 에 의해 컨디셔닝되고, 복조기 (440) 에 의해 복조되고, 그리고 RX 데이터 프로세서 (442) 에 의해 프로세싱되어 수신기 시스템 (450) 에 의해 송신된 역방향 링크 메시지를 추출한다. 그 결과, 데이터는 송신기 시스템 (410) 과 수신기 시스템 (450) 사이에서 전송 및 수신될 수도 있다. 송신기 시스템 (410) 은 또한, 인지될 바와 같이, 그것이 수신기 시스템 (450) 으로부터 수신하는 정보를 그의 서빙 네트워크 내의 다른 네트워크 엘리먼트들에 송신하고 그리고 서빙 네트워크에서의 하나 이상의 다른 네트워크 엘리먼트들로부터 정보를 수신하는데 이용될 수도 있다. 도 4 에 예시된 실시형태는 단지 예시적이고, 본 개시의 실시형태들은 도 4 에 예시되지 않은 다른 송신기/수신기 시스템들에 적용가능하다.
도 5 는 본 개시의 다양한 양태들에 따른, 후원된 접속을 제공하기 위한 UE, 서빙 네트워크, 및 애플리케이션 서비스 프로바이더 사이의 예시적인 시그널링 양태들을 나타내는 프로토콜도이다. 논의의 단순성을 위해, 도 5 의 프로토콜도에서의 액션들을 설명하는데 있어서 도 1 에 도시된 엘리먼트들 (예를 들어, UE (102), RAN (104) (도 5 에서 eNB (104) 로서 도시), MME (106), GW (110), 및 애플리케이션-특정 서비스를 호스팅하는 애플리케이션 서비스 프로바이더로서의 서버 (116)) 을 참조하게 될 것이다. 게다가 단순성을 위해, 논의는 어태치 절차의 모든 양태들 대신에 본 개시의 실시형태들의 양태들을 설명하는 프로토콜 플로우의 그 양태들에 초점을 맞출 것이다. 도 5 에서 예시된 접근법은, 클라이언트 토큰이 UE (102) 와 서버 (116) 사이에 공유되는 (패스워드에 기초한) 사전-존재 크리덴셜에 기초하는 일 실시형태를 기술한다.
액션 (502) 에서, UE (102) 는 서빙 네트워크 (112) 와 서비스 발견 절차 (service discovery procedure) 에 착수한다. 서비스 발견은 서버 (116) 가 서빙 네트워크 (112) 와 이전에 관여한 서비스 프로비저닝 기능에 의해 가능하게 될 수도 있다. 일 실시형태에서, 서비스 프로비저닝 기능의 결과는 서빙 네트워크 (112)가 서버 (116) 에 의해 호스팅되는 애플리케이션 서비스 프로바이더에 의해 후원되는 접속을 식별하는 정보를 일부 또는 모든 수신자들 (예컨대, UE 들 (102)) 에게 브로드캐스팅하는 것을 포함한다. 다른 실시형태에서, UE (102) 는, 일부 또는 모든 신뢰된 네트워크들, 또는 서버 (116) 에 의해 호스팅되는 애플리케이션 서비스 프로바이더를 대신하여 후원되는 접속성을 제공하기 위해 합의들에 진입한 네트워크들을 식별하는 정보를 서버 (116) 로부터 제공받았을 수도 있다.
UE (102) 가 서빙 네트워크 (112) 를 발견한 후에, 액션 (504) 에서, UE (102) 는 eNB (104) 에 인증 요청을 전송한다. 이것은 서빙 네트워크 (112) 에 어태치하기 위한 시도에서 행해진다. 인증 요청을 수신 시, eNB (104) 는 인증 요청을 MME (106) 에 포워딩한다. 인증 요청은 서버 (116) 에 의해 호스팅되는 애플리케이션 서비스 프로바이더와 UE (102) (또는 UE (102) 의 그리고 UE (102) 에 제공되는 사용자) 사이에 사전에 확립되었던 사전-존재 크리덴셜에 기초하는 클라이언트 토큰을 포함한다. 인증 요청은 가입자 서버 (예컨대, IMSI 등) 를 포함하지 않는다. 일 실시형태에서, 애플리케이션 요청은 기존의 셀룰러 네트워크와 연관된 크리덴셜을 포함하지 않는다. 인증 요청은 또한 애플리케이션 서비스 프로바이더와 사전에 확립되는 바와 같은 사전-존재 크리덴셜과 연관된 사용자 명칭을 포함할 수도 있다. 인증 요청을 정확하게 라우팅함에 있어서 서빙 네트워크 (112) 를 보조하기 위해, UE (102) 는 또한, 서버 (116) 에서의 애플리케이션 서비스 프로바이더의 도메인 네임 또는 애플리케이션 ID 와 같은, 서버 (116) 를 식별하기 위한 정보를 포함할 수도 있다.
클라이언트 토큰은 다양한 형태들을 가정할 수도 있고, 다수의 상이한 피처들을 가질 수도 있다. 예를 들어, 사전-존재 크리덴셜은, 먼저, 애플리케이션 서비스 프로바이더의 명칭과 연접된 솔트와 함께 (예컨대, WLAN 접속과 같은 대역외 채널을 통해) 애플리케이션 서비스 프로바이더와 UE (102) 사이의 확립된 패스워드를 해쉬-함수 메시지 인증 코드 (hash-function message authentication code; HMAC) 내에 놓음으로써 생성될 수도 있다. HMAC 함수의 출력은 이 논의의 목적을 위해 "사전-존재 크리덴셜 (pre-existing credential)" 로서 지정될 수도 있다. "사전-존재 크리덴셜" 의 결과 값은 다른 HMAC 함수에 입력될 수도 있고, 여기서, 추가적인 입력은 논스 값이고, 출력은 클라이언트 토큰이다. 클라이언트 토큰은 애플리케이션 서비스 프로바이더가 유효한 사전-존재 크리덴셜의 보유를 검증하는 것을 가능하게 한다. 악성 어택커가 허가되지 않은 방식으로 UE (102) 와 연관된 사용자로서 가장하려고 시도하고 정보를 가로챌 수 없도록 하기 위해, 클라이언트 토큰이 사전-존재 크리덴셜 (또는 패스워드) 대신에 사용될 수도 있다. 비록 클라이언트 토큰이 인증 요청과 함께 포함되는 값으로서 본원에서 설명되지만, 사전-존재 크리덴셜이 클라이언트 토큰의 경우보다 사용자를 추가적인 보안 위험들에 노출시킬 수도 있지만, 사전-존재 크리덴셜이 대신 포함될 수도 있음을 인식할 것이다. 이들 값들의 생성은 식 1 및 식 2 에서 예시된다:
사전-존재 크리덴셜 = HMAC (패스워드, 솔트 | 서비스 명칭), 여기서, | 는 연접 연산자; 식 (1)
클라이언트 토큰 = HMAC (사전-존재 크리덴셜; 논스) 식 (2)
클라이언트 토큰은, 다시, 어태치 요청에서의 포함을 위해 클라이언트 벡터, 예컨대, 클라이언트 벡터 = [사용자 명칭, 논스, 클라이언트 토큰] 에 포함된다. 다른 예로서, 일 실시형태에서, UE (102) 는 클라이언트 토큰을 생성하기 위해 램포트 원-타임 해쉬 (Lamport one-time hash) 를 사용할 수도 있다. 이 대안적인 실시형태 하에서 사전-존재 크리덴셜에 도달하기 위해, 식 (1) 및 식 (2) 는 식 (3) 및 식 (4) 에서 다음과 같이 보이도록 변경된다:
사전-존재 크리덴셜 = HMACi (패스워드, 솔트 | 서비스 명칭), 여기서, i 는 해쉬 인덱스; 식 (3)
클라이언트 토큰 = HMAC (사전-존재 크리덴셜, 논스) 식 (4)
클라이언트 토큰은, 다시, 어태치 요청에서의 포함을 위해 클라이언트 벡터, 예컨대, 클라이언트 벡터 = [사용자 명칭, i, 논스, 클라이언트 토큰] 에 포함된다. 식 (3) 에서 볼 수 있는 바와 같이, 인덱스 i 가 추가된다. HMACi 는 해쉬 연산의 "i" 런들 (runs) 을 나타낸다. 따라서, 사전-존재 크리덴셜은 해쉬 인덱스 i 를 추가로 포함하고, 그래서, 서버 (116) 는 해쉬 연산이 얼마나 많이 수행되었는지를 아는 것이 가능할 것이고, 그렇게, 그것의 종단까지 유사한 단계들로 진행될 수도 있다.
다른 예로서, 패스워드에 기초하는 사전-존재 크리덴셜 대신에, 사전-존재 크리덴셜은 키 또는 UE (102) 와 서버 (116) 에 의해 사전에 프로비저닝되었던 다른 값일 수도 있다. 키는, 예를 들어, 서버 (116) 가 UE (102) 의 사용자의 계정과 연관시켰던 하이 엔트로피 키 (예컨대, 256 비트 키) 일 수도 있다. 하이 엔트로피 키는, 인식되는 바와 같이, 랜덤 선택 프로세스 또는 몇몇 다른 방식에 따라 생성될 수도 있다. 이 상황에서, 클라이언트 토큰을 생성하기 위해, 식 (1) 또는 식 (3) 의 어느 일방으로부터 각각 생성된 사전-존재 크리덴셜 대신에 식 (2) 또는 식 (4) 내로의 사전-존재 입력으로서 그 키가 취해진다.
상기 기술된 식들의 임의의 것에 대한 추가된 보안을 위해, 멀티-팩터 인증 (multi-factor authentication; MFA) 이 또한 사용될 수도 있다. 사용될 때, 클라이언트 토큰의 도출은 원-타임 패스코드 (OTP) 로서 지칭되는 다른 크리덴셜을 통합할 수도 있다. 따라서, 식 (2) 및 식 (4) 는 다음과 같이 수정될 것이다:
클라이언트 토큰 = HMAC (사전-존재 크리덴셜, 논스 | OTP) 식 (2)
클라이언트 토큰 = HMAC (사전-존재 크리덴셜, 논스 | OTP) 식 (4)
클라이언트 토큰은, 다시, 어태치 요청에서의 포함을 위해 클라이언트 벡터, 예컨대, 클라이언트 벡터 = [사용자 명칭, 논스, i (여기서, 식 (4) 가 사용됨), 클라이언트 토큰] 에 포함된다. 비록 일련의 도출들로서 상술되었지만, 사전-존재 크리덴셜 및 액세스 토큰을 결정하는 것은 대신에 (예를 들어, UE (102) 또는 서버 (116) 또는 몇몇 다른 엔티티에 의해 미리 도출되고 UE (102)/서버 (116) 에 제공되었던) 룩-업 테이블 (look-up table) 에서 하나 이상의 값들을 찾는 것을 수반할 수도 있음을 인식할 것이다.
MME (106) 는 eNB (104) 로부터 포워딩되었던 인증 요청을 수신하고, 액션 (506) 에서, 서빙 네트워크 (112) 에 대응하는 서빙 네트워크 식별자를 인증 요청에 부가한다. MME (106) 는, 서버 (116) 에 수정된 인증 요청을 송신하기 위해 GW (110) 를 통해 서버 (116) 에 대해 보안 접속을 추가로 확립할 수도 있다 (예컨대, 2 가지만 예를 들어 보면, 전송 계층 보안 (TLS) 또는 하이퍼텍스트 전송 프로토콜 보안 (HTTPS)).
액션 (508) 에서, MME (106) 는 서버 (116) 에 수정된 인증 요청을 송신한다.
액션 (510) 에서, 일단 서버 (116) 가 수정된 인증 요청을 수신하면, 서버 (116) 는 그 수정된 인증 요청을 검증하는 것을 진행한다. 이것은, 클라이언트 토큰으로부터 사전-존재 크리덴셜을 획득하는 것, 및 클라이언트 토큰으로부터의 사전-존재 크리덴셜과 데이터베이스에서의 것 사이에 매치가 존재하는지를 결정하기 위해 사전에 확립된 계정들과 연관된 사전-존재 크리덴셜들의 로컬 데이터베이스에 대해 사전-존재 크리덴셜을 비교하는 것을 포함할 수도 있다. 예를 들어, 이 비교는 타방으로부터 하나의 값을 차감하는 것, 및 제로 값이 초래되는지, 또는 제로의 미리결정된 범위 내의 몇몇 값인지 (양 또는 음 중 어느 일방) 를 결정하는 것을 포함할 수도 있다. 인식되는 바와 같이, 비교의 다른 방법들이 또한 본 개시의 범위로부터 벗어남이 없이 사용될 수도 있다.
이것이 가능한 이유는, 서버 (116) 가 또한, 주어진 사전-존재 크리덴셜에 대해 클라이언트 토큰에 도달함에 있어서 (그리고 주어진 패스워드에 대해 사전-존재 크리덴셜에 도달하기 위해) 상술된 것과 동일한 접근법을 따르기 때문이다. 일 실시형태에서, 이것은, UE (102) 및 서버 (116) 가, 클라이언트 토큰 (및 일부 실시형태들에서 사전-존재 크리덴셜) 에 대한 특정 도출 접근법에 대해, 예를 들어, 대역외 채널에서, 사전에 합의한 결과이다. 다른 실시형태에서, 이것은, UE (102) 가, (예컨대, 식들 1/2 또는 식들 3/4, 또는 키, 아이덴티티 증명서 등에 따라) 인증 타입이 의존되었던 식별표시를 인증 요청에 포함시킨 결과이다. 그 결과로서, 서버 (116) 는, 인증 요청에 포함된 사용자 명칭과 연관된 사전-존재 크리덴셜 (또는 패스워드) 을 액세스하고, UE (102) 에서 사전-존재 크리덴셜에 대해 행해졌던 바와 같이 서버 (116) 에서 사전-존재 크리덴셜 (또는 패스워드) 에 대해 동일한 동작들을 수행할 수도 있다. 대안적으로, 클라이언트 토큰은 사전에 도출될 수도 있고, 수신된 클라이언트 토큰은 서버 (116) 에서 로컬 버전에 대해 비교되었다.
서버 (116) 가 UE (102) 의 요청과 연관된 사전-존재 크리덴셜을 검증할 수 없는 경우에 (예컨대, 클라이언트 토큰으로부터의 사전-존재 크리덴셜의 값이 데이터베이스에서의 사전-존재 크리덴셜의 값과 매치하는 것을 확인할 수 없는 경우에), 서버 (116) 는 요청을 거부할 것이다. 서버 (116) 가 (예컨대, 매치를 확인함으로써) 사전-존재 크리덴셜을 검증하는 경우에, 서버 (116) 는 허가 벡터 (authorization vector) 를 컴파일링하는 것을 진행한다. 따라서, UE (102) 로부터 클라이언트 토큰을 포함시킨 인증 요청을 수신하는 것에 응답하여, 본 개시의 실시형태들에 따라, UE (102) 는, (UE 가 인증 요청의 일부로서 HSS 에 대해 인증되지 않는 현재의 실무에 반해) UE (102) 와 서빙 네트워크 (112) 사이에 상호 인증이 수행되기 전에, 서버 (116) 에 대해 인증된다. 일 실시형태에서, 허가 벡터 컴포넌트들은, UE (102) 에서 취해진 접근법에 의존하여 (나중에 UE (102) 와 MME (106) 사이에 상호 인증이 가능하도록 UE (102) 와 서버 (116) 사이에 동일한 접근법이 취해질 수 있다), 상기 식 (1) 또는 식 (3) 의 사전-존재 크리덴셜에 근거하여 도출된다. 허가 벡터는 KASME (Access Security Management Entity), 인증 토큰 (AUTN), 랜덤 넘버 (RAND), 및 UE 로부터의 예상되는 응답 (XRES) 을 포함할 수도 있다. KASME 는, 서버 (116) 가 그것을 MME (106) 와 공유하기 때문에 MME (106) 및 서버 (116) 양자에게 알려지는 MME (106) 베이스 키이다. 이 실시형태에 따르면, KASME 는 식 (1) 또는 식 (3) 및 논스 및 RAND 값들로부터의 "사전-존재 크리덴셜" 값에 기초한다.
다른 실시형태에서, 인증 벡터를 컴파일링하기 전에, 서버 (116) 는 UE (102) 와 서버 (116) 사이에 새로운 공유된 비밀 키에 도달하기 위해 PAKE (password-authenticated key agreement) 를 사용할 수도 있다. 예를 들어, PAKE 절차의 일부로서, 서버 (116) 는 UE (102) 와 4-웨이 핸드쉐이크에 관여할 수도 있다. 인식되는 바와 같이 다른 레벨들의 핸드쉐이크 (예컨대, 2-웨이, 3-웨이 등) 가 가능할 수도 있다. 서빙 네트워크 (112) 의 엘리먼트들은 (비록 어태치 절차가 아직 완료되지 않았음에도 불구하고) 4-웨이 핸드쉐이크 동안 UE (102) 와 서버 (116) 사이에 통신물들을 반송할 수도 있다. 일단 공유된 비밀 키가 합의되고 나면, UE (102) 및 서버 (116) 는 그 공유된 비밀 키를 저장하고, 서버 (116) 는 KASME 를 도출하기 위해 그 공유된 비밀 키를 사용한다. PAKE 절차의 완료는, UE (102) 가 서빙 네트워크 (112) 와 상호 인증을 수행하기 이전에 UE (102) 및 서버 (116) 가 서로 상호 인증하는 결과를 초래한다.
본 개시의 양태들에서, 서버 (116) 는 "사전-존재 크리덴셜" (식 (1) 또는 식 (3)) 에 기초하여 또는 새로운 공유된 비림 키에 기초하여 KASME 의 하나 또는 다른 도출을 이용한다. 다른 양태에서, E (102) 및 서버 (116) 양자에 의해 양 접근법들이 지원되는 경우에, 서버 (116) 는 먼저 "사전-존재 크리덴셜" 에 기초하여 KASME 의 도출을 시도하고, 몇가지 이유로 실패하는 경우에, 그 다음에, KASME 를 도출하는데 사용하기 위해 새로운 공유된 비밀 키를 확립하기 위해 PAKE 를 이용하는 것으로 천이할 수도 있다. KASME 는 인증 세션의 지속기간 동안 유효하게 남아 있을 수도 있다. 또한, KASME 는, NAS 암호화 및 무결성 키들 및 애플리케이션 서버 (AS) 암호화 및 무결성 키들을 포함하는, 후속 키들을 도출하기 위해서 사용될 수도 있다.
일단 인증 벡터가 컴파일링되고 나면, 액션 (512) 에서, 서버 (116) 는 보안 접속을 통해 MME (106) 에 인증 응답을 다시 역으로 전송한다.
액션 (514) 에서, MME (106) 는 인증 벡터로부터 예상되는 응답 XRES 및 KASME 를 추출한다. MME (106) 는 이들 값들을 저장하고, 액션 (516) 에서 (예컨대, 서빙 네트워크 (112) 에 대한 상호 인증을 위해) UE (102) 에 대한 인증 요청에서 UE (102) 에 인증 토큰 (AUTN) 및 랜덤 값 (RAND) 에 대해 포워딩한다.
액션 (518) 에서, 일단 UE (102) 가 MME (106) 로부터 인증 토큰 AUTN 및 RAND 와 함께 인증 요청을 수신하면, UE (102) 는 인증 토큰 (AUTN) 을 유효화하기 위해 시도한다. UE (102) 는 서버 (116) 와의 공유된 비밀 키에 기초하여 인증 토큰 (AUTN) 을 유효화한다. PAKE 가 사용되지 않는 실시형태들에서, 이것은 상기 식 (1) 또는 식 (3) 에 따라 도출되는 바와 같은 "사전-존재 크리덴셜" 값이다. 여기서, PAKE 가 사용되는 경우에, 그것은 4-웨이 핸드쉐이크로부터 서버 (116) 와의 합의 후에 UE (102) 에서 저장된 공유된 비밀 키이다. 예를 들어, UE (102) 는 공유된 비밀 (사전-존재 크리덴셜 또는 공유된 비밀 키) 에 기초하여 AUTN 의 그 자신의 버전을 결정하고, MME (106) 로부터 수신된 AUTN 에 대해 비교한다. 값들이 매치하지 않는 경우에, UE (102) 는 AUTN 을 유효화할 수 없고, 인증은 실패한다. 매치가 존재하는 경우에, AUTN 은 유효화되고, UE (102) 는, UE (102) 및 MME (106) 가 NAS 시그널링의 암호화 및 무결성 보호를 위해 다른 키들을 도출하기 위해 나중에 사용할, 응답 RES 및 KASME 의 그 자신의 버전을 결정하는 것으로 진행한다.
액션 (520) 에서, UE (102) 는 그 RES 를 MME (106) 에 전송하여, MME (106) 는 그것이 서버 (116) 로부터 이전에 저장하였던 XRES 를 UE (102) 로부터 수신된 RES 에 대해 비교할 수도 있다. 2 개가 매치하는 경우에, 인증은 성공적이었고, 프로세스는 그 다음 NAS 및 AS 키 셋업으로 진행할 수도 있다. 그 결과로서, UE (102) 는, 서빙 네트워크 (112) 와 UE (102) 의 접속을 후원하는 (예컨대, 특정 액세스에 대한 비용의 일부 또는 전부를 커버하는) 서버 (116) 에 의해 호스팅되는 애플리케이션 서비스 프로바이더와, 서빙 네트워크 (112) 를 통해, 서비스를 액세스할 수도 있다. 이것은, UE (102) 가 SIM 카드 또는 임의의 홈 네트워크/서비스 프로바이더와 기존의 서브스크립션을 가지지 않는 경우에도 참이다.
도 6 은 본 개시의 다양한 양태들에 따른, 후원된 접속을 제공하기 위한 UE, 서빙 네트워크, 및 애플리케이션 서비스 프로바이더 사이의 예시적인 시그널링 양태들을 나타내는 프로토콜도이다. 논의의 단순성을 위해, 도 6 의 프로토콜도에서의 액션들을 기술함에 있어서 도 1 에 도시된 엘리먼트들 (예컨대, 애플리케이션 서비스 프로바이더에 의해 동작되는 UE (102), MME (106), 서버 (116), 및 서버 (116) 와 별개이거나 서버 (116) 와 일체형일 수도 있는 허가 서버 (120)) 에 대한 참조가 이루어질 것이다. 도 6 은, UE (102) 가 서버 (116) 에서 UE (102) 의 사용과 연관된 크리덴셜들을 액세스하기 위해 MME (106) 에 대해 허가하는 일 실시형태를 기술한다.
액션 (602) 에서, UE (102) 는, 서버 (116) (애플리케이션 서비스 프로바이더) 를 통해 후원된 서비스를 액세스하기 위해, 서빙 네트워크 (112) 에 어태치 요청을 전송하고, 이것을 MME (106) 가 수신한다. 어태치 요청은, UE (102) 가, 논의된 도 5 의 액션 (504) 에서와 같이 인증 요청의 일부로서 사전-존재 크리덴셜에 기초하는 클라이언트 토큰을 제공하는 대신에, 서버 (116) 와 직접 인증하기를 희망하는 것을 나타내는 정보를 포함한다. 예를 들어, UE (102) 는 사전-존재 크리덴셜에 기초하여 클라이언트 토큰을 제공함이 없이 애플리케이션 서비스 프로바이더와 연관된 사용자 명칭을 포함할 수도 있다. 어태치 요청은, UE (102) 가 서버 (116) 와 직접 인증할 필요성이 있음을 나타내는 것으로 MME (106) 가 이해하는 식별자를 명시적으로 포함할 수도 있고, 또는, 그것은, 어태치 요청이 크리덴셜을 결여한다는 사실 때문에 MME (106) 에 의해 간접적으로 추론될 수도 있다. UE (102) 는 또한, 서버 (116) 에 대해 요청의 양태들을 라우팅함에 있어서 서빙 네트워크 (112) 를 보조하기 위해 (서버 (116) 에서의 애플리케이션 서비스 프로바이더의 도메인 네임 또는 애플리케이션 ID 와 같은) 서버 (116) 를 식별하기 위한 정보를 포함할 수도 있다. 어태치 요청은 어떤 종류의 가입자 식별자 (예컨대, IMSI 등) 도 포함하지 않는다. 어태치 요청은 또한 (예컨대, 서버 (116) 에 의한 서비스에 대한 후원된 접속을 위해) 서빙 네트워크 (112) 의 그것의 액세스의 요청된 범위를 식별할 수도 있다.
액션 (604) 에서, MME (106) 는, 사전-존재 크리덴셜에 기초하는 클라이언트 토큰이 없는 것을 결정하고 및/또는 명시적 식별 정보를 로케이팅하고, 따라서, 인증 요청을 허가 서버 (120) 에 전송한다. 상기 언급된 바와 같이, 허가 서버 (120) 는 서버 (116) 와는 별개의 엔티티일 수도 있거나 그것과 일체형일 수도 있다. MME (106) 는 서빙 네트워크 (112) 의 식별자를 인증 요청에 포함할 수도 있다. 식별자는, (서버 (116) 로서 표현된) 애플리케이션 서비스 프로바이더와 서빙 네트워크 (112) 사이에 후원된 관계가 프로비저닝되었던 이전 시간에서 허가 서버 (120) 에 제공되었거나 허가 서버 (120) 로부터 수신되었을 수도 있다.
액션 (606) 에서, 허가 서버 (120) 는 UE (102) 를 인증하기 위해 서빙 네트워크 (1120) 를 통해 UE (102) 와 통신을 개시한다. 서빙 네트워크 (112) 의 엘리먼트들은, (비록 어태치 절차가 아직 완료되지 않았음에도 불구하고) UE (102) 와 허가 서버 (120) 사이에서 전방향 및 후방향의 하나 이상의 요청들 및 응답들을 수반할 수도 있는, 사용자 인증 및 액세스 허가 프로세스 동안 UE (102) 와 인증 서버 (120) 사이에 통신물들을 반송할 수도 있다. 예를 들어, UE (102) 의 사용자 인터페이스는, 애플리케이션 서비스 프로바이더 동작 서버 (116) 와 이미 연관된 사용자를 인증하기 위해 사용자 인터페이스 (미도시) 를 통해 사용자 명칭 및 패스워드 (예컨대, 허가 서버에서 저장되거나 허가 서버에 의해 액세스가능한 프로파일에서의 것과 매치하는 사용자 명칭 패스워드) 를 입력하도록 UE (102) 의 사용자에게 지시 또는 요청할 수도 있다. 다른 예로서, UE (102) 는, 사용자로 하여금 사용자 인터페이스를 통해 상호작용하도록 요구 함이 없이 (예컨대, 액세스 모듈 (208) 을 통해) 메모리 (204) 에 사전에 저장되었던 애플리케이션 서비스 프로바이더에 대한 사전-존재 크리덴셜 (또는 키, 또는 아이덴티티 증명서) 을 액세스할 수도 있다.
액션 (606) 에서 애플리케이션 서비스 프로바이더와 연관된 사용자를 인증하는 것에 추가하여, 허가 서버 (120) 는 또한 UE (102) 로부터 액세스 허가를 획득하고, 이는 MME (106) (또는 서빙 네트워크 (112) 에서의 다른 적절한 네트워크 엘리먼트) 로 하여금 서버 (116) 로부터 UE (102) 와 연관된 사용자 프로파일을 액세스하도록 허용한다. 일 실시형태에서, 액세스 허가는 사용자 인증과는 별개로 그리고 구분되어 (예컨대, 별개의 쿼리) 획득된다. 다른 실시형태에서, 액세스 허가는 성공적인 사용자 인증으로부터 암시될 수도 있다. 사용자 인증 및/또는 액세스 허가가 실패하는 경우에, 프로세스는 중단되고, UE (102) 는, 허가 서버 (120) 로부터 통지되는 MME (106) 에 의해 통지된다.
사용자 인증 및 액세스 허가가 성공적인 경우에, 액션 (608) 에서, 허가 서버 (120) 는 허가 코드를 (예를 들어, UE (102) 에, 그리고 그 다음에 MME (106) 에 다시 역으로 다시 보내지는 대신에) MME (106) 에 전송한다. 허가 코드는 사전-존재 크리덴셜, 패스워드, 또는 사용자의 다른 관련 크리덴셜과는 상이한 값이고, 따라서 MME (106) 로부터 보호된다. 허가 코드와 함께, 허가 서버 (120) 는 또한, MME (106) 가 이하 설명되는 바와 같이 액세스 토큰을 요청할 때 검증을 위해 허가 코드를 사용하도록 하는 지시를 포함할 수도 있다.
허가 코드와 함께, MME (106) 는 서버 (116) 로부터 UE (102) 와 연관된 사용자 프로파일에 대한 액세스를 얻기 위해 허가 서버 (120) 로부터 액세스 토큰을 요청할 준비가 되어 있다. 액션 (610) 에서, MME (106) 는 액세스 토큰에 대해 허가 서버 (120) 에 요청을 전송한다. 요청의 일부로서, MME (106) 는 액션 (608) 에서 수신된 허가 코드를 포함한다. 요청은 서빙 네트워크 (112) (또는 적어도 MME (106)) 의 식별표시를 더 포함할 수도 있다.
액션 (612) 에서, 허가 서버 (120) 는 MME (106) (또는 보다 일반적으로, 서빙 네트워크 (112)) 를 인증하고 허가 코드를 유효화한 후에, 액션 (610) 의 액세스 토큰 요청에 응답한다. 성공적이지 못한 경우에, 응답은 거부, 일부 실시형태들에서는, 거부에 관한 이유 또는 표시를 나타낸다. 성공적인 경우에 (예컨대, 적절한 허가 코드가 제공된 경우에), 허가 서버 (120) 는 MME (106) 에 대해 요청된 액세스 토큰으로 응답한다. 응답은, 액세스 토큰에 추가하여, 액세스 토큰의 타입의 설명, 액세스 토큰이 만료될 (더 이상 유효하지 않을) 특정된 기간, 및 새로운 액세스 토큰을 획득하기 위해 사용될 수 있는) 액세스 토큰이 만료되는 경우에서의 리프레쉬 토큰을 포함할 수도 있다.
액션 (614) 에서, MME (106) 는 - 이제 액세스 토큰과 함께 - 사용자 크리덴셜들을 요청 및 수신하는 것으로 진행한다. 이것은, 서빙 네트워크 (112) 에 대한 접속이 이제 서버 (116) 에 의해 호스팅되는 애플리케이션 서비스 프로바이더에 의해 후원되는 경우에서 MME (106) 가 서빙 네트워크 (112) 에 대한 UE (102) 의 어태치를 완료하는 것을 돕기 위해서 행해질 수 있다. 그 결과로서, 도 6 의 실시형태들은 UE (102) 로 하여금 어태치 요청에서 사전-존재 크리덴셜에 기초하는 클라이언트 토큰 (예컨대, 패스워드, 해쉬된 패스워드, 또는 UE (102) 에서 사전에 저장된 액세스 토큰 등) 을 제공함이 없이 서빙 네트워크 (112) 에 어태치하는 것을 가능하게 한다.
이제 도 7a 로 가서, 플로우차트는 본 개시의 다양한 양태들에 따른, 서버를 동작시키는 애플리케이션 서비스 프로바이더에 의해 후원되는 서비스를 위해 네트워크에 액세스하기 위한 예시적인 방법 (700) 을 나타낸다. 방법 (700) 은 UE (102) 에서 구현될 수도 있다. 방법 (700) 은 논의의 단순성을 위해 단일의 UE (102) 에 대하여 설명될 것이지만, 본 명세서에서 설명된 양태들은 복수의 UE들 (102) 에 적용가능할 수도 있다는 것이 인지될 것이다. 상기 "액션들 (actions)" 및 이하의 "단계들 (steps)" 은 상호교환가능하게 사용될 수도 있음을 이해할 것이다. 추가적인 단계들이 방법 (700) 의 단계들 전에, 동안, 및 후에 제공될 수 있고, 설명된 단계들의 일부가 방법 (700) 의 다른 실시형태들을 위해 재정렬, 대체 또는 제거될 수 있는 것으로 또한 이해된다.
단계 (702) 에서, 후원된 접속이 이용가능할 수도 있는 하나 이상의 서빙 네트워크들 (112) 을 식별한다. 예를 들어, UE (102) 는 하나 이상의 서비스들에 대해 후원된 접속을 광고하는 서빙 네트워크들 (112) 로부터 하나 이상의 브로드캐스트들을 수신할 수도 있다. 다른 예로서, UE (102) 는 애플리케이션 서비스 프로바이더를 호스팅하는 서버로부터의 정보에 기초하여 사전에 UE (102) 에 저장되었을 수도 있는 신뢰된 네트워크들의 리스트에 대해 메모리 (204) 를 체크할 수도 있다.
UE (102) 가 제공되는 접속의 후원의 이점을 취하기 위해 서빙 네트워크 (112) 에 대해 인증하기 위해 사전-존재 크리덴셜을 사용할 수도 있다. UE (102) 가 서버 (116) 와 사용자 명칭 및 패스워드를 셋업한 경우에, 결정 단계 (704) 가 방법 (700) 을 단계 (706) 로 보낼 수도 있다.
단계 (706) 에서, UE (102) 는 예를 들어 상기 설명된 바와 같이 식 (1) 또는 식 (3) 중 어느 일방과 관련하여 솔트 값으로 패스워드를 해쉬하여, 사전-존재 크리덴셜을 발생시킨다. 대안적인 실시형태들에서, 서버 (116) 가 (예컨대, 대역외 채널을 통해) 사전에 패스워드의 사전-존재 크리덴셜로 UE (102) 를 프로비저닝한 경우에 이 단계는 불필요할 수도 있다.
단계 (708) 에서, UE (102) 는 사전-존재 크리덴셜을 취하고, 예를 들어 식 (2) 또는 식 (4) 중 어느 일방과 관련하여 상기 설명된 바와 같이, 그것을 논스 값 (및/또는 다른 값들) 으로 해쉬하여 클라이언트 토큰을 발생시킨다.
결정 단계 (704) 로 돌아가서, UE (102) 가 애플리케이션 서비스 프로바이더의 서버 (116) 에 로그인함에 있어서 사용하기 위해 이전 시간에서 서버 (116) 로부터 하이 엔트로피 키와 같은 키를 수신하는 대신 수신한 경우에, 방법 (700) 은 단계 (708) 로 진행하고 (단계 (706) 은 스킵), 여기서, 사전-존재 크리덴셜은 식 (2) 또는 식 (4) 중 어느 일방에서 사용되는 키이다.
단계 (710) 에서, UE (102) 는 후원된 접속의 이점을 취하기 위한 시도에서 서빙 네트워크 (112) 에 어태치 요청을 전송한다. UE (102) 는, 어태치 요청의 일부로서, IMSI 와 같은, 다른 전통적인 식별자들 대신에 클라이언트 토큰을 전송한다. 클라이언트 토큰은, 클라이언트 토큰에 추가하여 사전-존재 크리덴셜 및 논스 값 (및, 사용되는 경우에 인덱스) 과 연관된 사용자 명칭을 포함하는 클라이언트 벡터의 일부로서 포함될 수도 있다.
UE (102) 가 서빙 네트워크 (112) 에 어태치 요청을 전송한 후에, 상기 다양한 도면들과 관련하여 설명된 바와 같이, 서빙 네트워크 (112) 는 서버 (116) 에 대한 인증 정보 요청으로서 서버 (116) 에 대한 요청을 포워딩한다. 서버 (116) 는 그 다음에 그 요청을 검증할 수도 있다. 검증은, (UE (102) 의 사용자와 연관된) UE (102) 에 의해 제공된 사용자 명칭 및/또는 패스워드와 같은, 클라이언트 벡터의 양태들을 애플리케이션 서비스 프로바이더의 서버 (116) 에 의해 유지되는 액세스 정보와 비교하는 것을 포함할 수도 있다. 검증은 비교가 비교된 값들 사이에 매치의 결정을 초래하는 경우에 발생할 수도 있다. 검증 후에, 서버 (116) 는 인증 응답 (벡터) 을 컴파일링하는 것으로 진행한다. 허가 응답 (벡터) 은 KASME, AUTN, RAND, 및 XRES 를 포함할 수도 있고, 여기서, 서빙 네트워크 (112) 의 네트워크 노드 엘리먼트 (예컨대, MME (106)) 는 XRES 및 KASME 를 로컬로 저장하고 RAND 및 AUTN 에 대해 UE (102) 에 포워딩할 수도 있다.
UE (102) 및 서버 (116) 가 PAKE 에 대해 셋업되는 경우에, 결정 단계 (712) 에서, 방법 (700) 은 단계 (714) 로 진행한다.
단계 (714) 에서, UE (102) 는 서빙 네트워크 (112) 를 통해 반송되었던 서버 (116) 로부터의 통신물을 수신한다. 그 통신물은 UE (102) 와 서버 (116) 사이의 핸드쉐이크 (예컨대, 4-웨이) 의 초기 메시지이다.
단계 (716) 에서, UE (102) 및 서버 (116) 는 핸드쉐이크 동안 업데이트된 공유된 비밀 키에 대해 합의한다. 일단 공유된 비밀 키가 합의되고 나면, UE (102) 및 서버 (116) 양자는 그 공유된 비밀 키를 저장하고, 서버 (116) 는 KASME 와 같은 하나 이상의 다른 키들을 도출하기 위해 그 공유된 비밀 키를 사용한다.
UE (102) 및 서버 (116) 가 공유된 비밀 키에 대해 합의한 후에, 서버 (116) 는 서빙 네트워크 (112) 에 대한 그리고 부분적으로 UE (102) 에 대한 응답에서 제공될 인증 벡터의 하나 이상의 양태들을 생성하기 위해 그 공유된 비밀 키를 사용한다.
방법 (700) 은 단계 (718) 로 진행하고, 여기서, UE (102) 는 서버 (116) 로부터 서빙 네트워크 (112) 에서 수신된 인증 응답에 기초하는 서빙 네트워크 (112) 로부터의 인증 요청을 수신한다. 인증 요청은 서버 (116) 에 의해 생성되었거나 그 외에 결정되었고 서빙 네트워크 (112) 에 의해 포워딩되었던 인증 토큰을 포함한다. 인증 요청은 또한 서버 (116) 로부터의 랜덤 넘버를 포함할 수도 있다.
결정 단계 (712) 로 돌아가서, UE (102) 및 서버 (116) 가 PAKE 에 대해 셋업되지 않는 경우에, 방법 (700) 은 이미 설명된 바와 같은 단계 (718) 로 진행한다.
단계 (720) 에서, UE (102) 는 인증 토큰을 유효화한다. UE (102) 는 서버 (116) 와의 공유된 비밀 키 (여기서 PAKE 가 사용되었다) 또는 중간 패스워드 크리덴셜에 기초하여 인증 토큰 (AUTN) 을 유효화한다. 예를 들어, UE (102) 는 공유된 비밀 (사전-존재 크리덴셜 또는 공유된 비밀 키) 에 기초하여 AUTN 의 그 자신의 버전을 결정하고, 서빙 네트워크 (112) 로부터 수신된 AUTN 에 대해 비교한다.
매치가 존재하는 경우에, 방법 (700) 은 단계 (722) 로 진행하고, 여기서, UE (102) 는 응답 (RES) 및 KASME 의 그 자신의 버전을 결정하고, 이것은 UE (102) 및 서빙 네트워크 (112) (예컨대, MME (106)) 가 NAS 시그널링의 암호화 및 무결성 보호를 위한 다른 키들을 도출하기 위해 나중에 사용할 것이다.
UE (102) 로부터의 RES 가 MME (106) 에서의 서버 (116) 로부터의 XRES 와 매치하는 경우에, 인증은 성공적이었고, 프로세스는 그 다음, NAS 및 AS 키 셋업으로 진행할 수도 있다. 그 결과로서, UE (102) 는 서빙 네트워크 (112) 와 UE (102) 의 접속을 후원하는 (예컨대, 특정 액세스를 위한 비용의 일부 또는 전부를 커버하는) 애플리케이션 서비스 프로바이더 서버 (116) 와, 서빙 네트워크 (112) 를 통해, 서비스를 액세스할 수도 있다. 이것은, UE (102) 가 SIM 카드 또는 임의의 홈 네트워크/서비스 프로바이더와 기존의 서브스크립션을 가지지 않는 경우에도 참이다.
도 7b 는 본 개시의 다양한 양태들에 따른, 애플리케이션 서비스 프로바이더에 의해 후원되는 서비스를 위한 네트워크 액세스를 승인하기 위한 예시적인 방법 (740) 을 나타내는 플로우차트이다. 방법 (740) 은 서버 (116) 에서 구현될 수도 있다. 방법 (740) 은 논의의 단순성을 위해 단일의 서버 (116) 에 대하여 설명될 것이지만, 본 명세서에서 설명된 양태들은 복수의 서버들 (116) 에 적용가능할 수도 있다는 것이 인지될 것이다. 추가적인 단계들이 방법 (740) 의 단계들 전에, 동안, 및 후에 제공될 수 있고, 설명된 단계들의 일부가 방법 (740) 의 다른 실시형태들을 위해 재정렬, 대체 또는 제거될 수 있는 것으로 또한 이해된다.
단계 (742) 에서, 서버 (116) 는 (예컨대, 서비스 프로비저닝 기능에 의해) 서빙 네트워크 (112) 와 서비스 레벨 합의를 확립한다. 서비스 프로비저닝 기능의 결과로서, 서빙 네트워크 (112) 는 서버 (116) 를 대신하여 서비스에 대해 후원되는 접속을 식별하는 수신자의 정보를 브로드캐스트할 수도 있다. 일 실시형태에서, 이것은 또한, 서버 (116) 가 UE (102) 에 일부 또는 모든 신뢰된 네트워크들, 또는 서버 (116) 를 대신하여 서비스에 대해 후원되는 접속을 제공하기 위한 합의들에 진입한 네트워크들을 식별하는 정보를 제공하는 것을 수반할 수도 있다.
단계 (744) 에서, 서버 (116) 는 서빙 네트워크 (112) 가 (IMSI 또는 다른 셀룰러 식별자 대신에 클라이언트 토큰을 포함한) UE (102) 로부터의 어태치 요청을 수신하는 것에 응답하여 서빙 네트워크 (112) 로부터 인증 요청을 수신한다.
UE (102) 가 서버 (116) 에 의한 접속의 제공되는 후원의 이점을 취하기 위해 서빙 네트워크 (112) 에 대해 인증하기 위해 사용할 수도 있는 사전-존재 크리덴셜의 수개의 상이한 타입들이 존재한다. UE (102) 가 서버 (116) 와 사용자 명칭 및 패스워드를 셋업한 경우에, 결정 단계 (746) 는 방법 (740) 을 단계 (746) 로 보낼 수도 있다.
단계 (746) 에서, 서버 (116) 는 예를 들어 상기 설명된 바와 같이 식 (1) 또는 식 (3) 중 어느 일방과 관련하여 솔트 값으로, UE (102) 가 후원된 접속의 이점을 취하기 위해 시도하고 있는 사용자와 연관된, 패스워드를 해쉬하여, 사전-존재 크리덴셜을 발생시킨다. 대안적인 실시형태에서, 서버 (116) 가 사전에 패스워드의 사전-존재 크리덴셜을 프로비저닝한 경우에 이 단계는 스킵될 수도 있다.
단계 (748) 에서, 서버 (116) 는 사전-존재 크리덴셜을 취하고, 예를 들어 식 (2) 또는 식 (4) 중 어느 일방과 관련하여 상기 설명된 바와 같이, 그것을 논스 값 (및/또는 다른 값들) 으로 해쉬하여 클라이언트 토큰의 서버 측 카피 (copy) 를 발생시킨다.
단계 (750) 에서, 서버 (116) 는 사용자의 프로파일 (예컨대, 사용자 명칭, 크리덴셜, 등 비교) 에 대해 인증 요청을 검증한다. 일 실시형태에서, 이것은 수신된 클라이언트 토큰을 결정된 서버 측 카피와 비교하는 것을 포함할 수도 있다. 서버 (116) 및 UE (102) 는 클라이언트 토큰에 도달하기 위해 동일한 방식으로 사전-존재 크리덴셜을 각각 해쉬할 수도 있기 때문에, 매치가 가능하다.
결정 단계 (746) 로 돌아가서, 서버 (116) 및 UE (102) 가 서버 (116) 에 의해 표현되는 애플리케이션 서비스 프로바이더에 로그인함에 있어서 사용하기 위해 이전 시간에서 서버 (116) 로부터 전송된 (하이 엔트로피 키와 같은) 키에 대신 의존한 경우에, 방법 (740) 은 단계 (748) 로 진행하고, 여기서, 사전-존재 크리덴셜은 하이 엔트로피 키이다. 방법 (740) 은 논의된 바와 같이 단계 (750) 으로 진행한다.
서버 (116) 및 UE (102) 가 PAKE 에 대해 셋업되는 경우에, 결정 단계 (752) 에서, 방법 (740) 은 단계 (754) 로 진행한다.
단계 (754) 에서, 서버 (116) 는 서빙 네트워크 (112) 를 통해 UE (102) 와 통신을 개시한다. 그 통신물은 서버 (116) 와 UE (102) 사이의 핸드쉐이크 (예컨대, 4-웨이) 의 초기 메시지이다.
단계 (756) 에서, 서버 (116) 및 UE (102) 는 핸드쉐이크 동안 업데이트된 공유된 비밀 키에 대해 합의한다. 일단 공유된 비밀 키가 합의되고 나면, UE (102) 및 서버 (116) 양자는 (예컨대, 인증 세션의 지속기간 동안) 그 공유된 비밀 키를 저장한다.
단계 (758) 에서, 서버 (116) 는 KASME 와 같은 하나 이상의 다른 키들을 도출하기 위해 공유된 비밀 키를 사용하고, AUTN 을 포함하는 인증 벡터의 다른 양태들을 발생시킨다. 서버 (116) 는 또한 XRES 및 랜덤 넘버 RAND 를 포함하는 인증 벡터에의 포함을 위해 다른 값들을 생성/결정한다.
결정 단계 (752) 로 돌아가서, UE (102) 및 서버 (116) 가 PAKE 에 대해 셋업되지 않는 경우에, 방법 (740) 은 이미 설명된 바와 같은 단계 (758) 로 진행하고, 여기서, 공유된 비밀 키는 대신에 사전-존재 크리덴셜이다.
단계 (760) 에서, 서버 (116) 는 서빙 네트워크 (112) 에 (예컨대, MME (106) 에) 인증 벡터를 송신한다. MME (106) 는 KASME 및 XRES 를 저장하고, 상호 인증을 위해 UE (102) 에 AUTN 및 RAND 를 포함하는 다른 양태들을 포워딩한다. MME (106) 와 UE (102) 사이에 상호 인증이 성공적인 경우에, 프로세스는 그 다음에 서빙 네트워크 (112) 와 UE (102) 사이에 NAS 및 AS 키 셋업으로 진행하고, 종국적으로, UE (102) 는 후원되는 접속에 기초하여 서빙 네트워크 (112) 를 통해 서비스를 액세스하는 것으로 진행할 수도 있다. 서빙 네트워크 (112) 는 후원되는 접속의 양태들 (예컨대, 어카운팅, 미터링, 빌링, 및 다른 기능들) 을 추적한다.
단계 (762) 에서, 서빙 네트워크 (112) 에 대한 UE (102) 의 성공적인 어태치 후의 일부 시점에서, 서버 (116) 는 UE (102) 에 의해 사용되는 후원되는 접속의 양태들에 대해 서빙 네트워크 (112) 로부터 요금을 수신한다. 서버 (116) 는 그러면, 통상의 기술자에 의해 인식되는 바와 같이 하나 이상의 접근법들에 다라 수신된 요금을 해결한다. 그 결과로서, UE (102) 는 서빙 네트워크 (112) 와 UE (102) 의 접속을 후원하는 (예컨대, 특정 액세스를 위한 비용의 일부 또는 전부를 커버하는) 애플리케이션 서비스 프로바이더와, 서빙 네트워크 (112) 를 통해, 서비스를 액세스하는 것이 가능하다.
도 7c 는 본 개시의 다양한 양태들에 따른, 후원되는 서비스에 대한 네트워크 액세스를 용이하게 하기 위한 예시적인 방법 (770) 을 나타내는 플로우차트이다. 방법 (770) 은 MME (106) (및/또는 서빙 네트워크 (112) 의 다른 네트워크 엘리먼트들) 에서 구현될 수도 있다. 방법 (770) 은 논의의 단순성을 위해 MME (106) 에 대하여 설명될 것이지만, 본 명세서에서 설명된 양태들은 서빙 네트워크 (112) 의 하나 이상의 다른 네트워크 엘리먼트들에 적용가능할 수도 있다는 것이 인지될 것이다. 추가적인 단계들이 방법 (770) 의 단계들 전에, 동안, 및 후에 제공될 수 있고, 설명된 단계들의 일부가 방법 (770) 의 다른 실시형태들을 위해 재정렬, 대체 또는 제거될 수 있는 것으로 또한 이해된다.
단계 (772) 에서, MME (106) 는 UE (102) 로부터 서비스 발견 요청을 수신하고 응답한다. 예를 들어, MME (106) 는 하나 이상의 eNB 들과 같은 네트워크 엘리먼트들로 하여금 서버 (116) 에 의해 호스팅되는 애플리케이션 서비스 프로바이더에 의해 후원되는 접속을 브로드캐스트하게 했을 수도 있다. 서비스 발견 요청은 후원되는 접속의 존재 및/또는 그 때의 서빙 네트워크 (112) 의 이용가능성을 확인하기 위한 UE (102) 에 의한 시도일 수도 있다.
단계 (774) 에서, MME (106) 는 UE (102) 로부터 어태치 요청을 수신한다. 어태치 요청은, IMSI 와 같은 다른 전통적인 식별자들 대신에 서버 (116) 에 의해 호스팅되는 애플리케이션 서비스 프로바이더와 UE (102) (및/또는 UE (102) 의 사용자) 사이에 이전에 확립된 사전-존재 크리덴셜에 기초하는 클라이언트 토큰을 그것 안에 포함한다.
단계 (776) 에서, MME (106) 는 서빙 네트워크 (112) 에 대응하는 어태치 요청에 서빙 네트워크 식별자를 부가하고, 서버 (116) 에 포워딩하기 위해 인증 요청을 포뮬레이션한다. 또한, MME (106) 는 서버 (116) 에 인증 요청을 송신하기 위해 서버 (116) 에 대해 보안 접속 (예컨대, TLS 또는 HTTPS) 을 확립할 수도 있다.
단계 (778) 에서, MME (106) 는 예컨대 단계 (776) 에서 확립된 보안 접속을 통해 서버 (116) 에 인증 요청을 전송한다.
서버 (116) 및 UE (102) 가 PAKE 에 대해 셋업되는 경우에, 결정 단계 (780) 에서 방법 (770) 은 단계 (782) 로 진행한다.
단계 (782) 에서, MME (106) 는 서버 (116) 와 UE (102) 사이의 핸드쉐이크 (예컨대, 4-웨이) (또는 다른 레벨의 핸드쉐이크) 동안 서버 (116) 와 UE (102) 사이에 요청 및 응답 메시지들을 반송한다. MME (106) 는, 서버 (116) 및 UE (102) 가 공유된 비밀 키에 대해 합의할 때까지 요청/응답 메시지들을 반송한다.
단계 (784) 에서, 공유된 비밀 키가 합의된 후에, MME (106) 는 서버 (116) 로부터 인증 벡터를 수신한다. 인증 벡터는 KASME, 랜덤 넘버 RAND, 및 XRES 를 포함할 수도 있다.
결정 단계 (780) 로 돌아가서, UE (102) 및 서버 (116) 가 PAKE 에 대해 셋업되지 않는 경우에, 방법 (770) 은 이미 설명된 바와 같은 단계 (784) 로 진행한다.
단계 (786) 에서, MME (106) 는 단계 (784) 로부터 수신된 인증 벡터로부터 UE (102) 와 상호 인증에서의 사용을 위해 KASME 및 XRES 를 추출한다.
단계 (788) 에서, MME (106) 는 AUTN 및 RAND 값들을 포함하는 UE (102) 에 인증 요청을 전송한다. UE (102) 는 (PAKE 가 사용되었던) 서버 (116) 와의 공유된 비밀 키 또는 사전-존재 크리덴셜에 기초하여 AUTN 을 유효화하고, 응답 (RES) 을 결정한다. 예를 들어, UE (102) 는 공유된 비밀 키에 기초하여 AUTN 의 그 자신의 버전을 결정하고, MME (106) 로부터 수신된 AUTN 에 대해 비교한다. 값들이 매치하지 않는 경우에, UE (102) 는 AUTN 을 유효화할 수 없고 인증은 실패한다. 매치가 존재하는 경우에, AUTN 은 유효화된다.
단계 (790) 에서, MME (106) 는 UE (102) 로부터 RES 를 수신하고, 그것을, 단계 (786) 에서 MME (106) 가 저장하였던 XRES 에 대해 비교한다. UE (102) 로부터의 RES 가 MME (106) 에서의 서버 (116) 로부터의 XRES 에 매치하는 경우에, 인증은 성공적이었고, 프로세스는 NAS 및 AS 키 셋업으로 진행할 수도 있다. 그 결과로서, UE (102) 는 서빙 네트워크 (112) 와 UE (102) 의 접속을 후원하는 (예컨대, 특정 액세스에 대한 비용의 일부 또는 전부를 커버하는) 애플리케이션 서비스 프로바이더로 서빙 네트워크 (112) 를 통해 서비스를 액세스할 수도 있다. 이것은, UE (102) 가 SIM 카드 또는 임의의 홈 네트워크/서비스 프로바이더와 기존의 서브스크립션을 가지지 않는 경우에도 참이다.
도 8a 는 본 개시의 다양한 양태들에 따른, 애플리케이션 서비스 프로바이더에 의해 후원되는 서비스를 위해 네트워크를 액세스하기 위한 예시적인 방법 (800) 을 나타내는 플로우차트이다. 방법 (800) 은 UE (102) 에서 구현될 수도 있다. 방법 (800) 은 논의의 단순성을 위해 단일의 UE (102) 에 대하여 설명될 것이지만, 본 명세서에서 설명된 양태들은 복수의 UE들 (102) 에 적용가능할 수도 있다는 것이 인지될 것이다. 또한, 도 6 과 관련하여 언급된 바와 같이, 허가 서버 (120) 및 서버 (116) 는 동일 또는 상이한 엔티티들일 수도 있다. 논의의 단순성을 위해, 이하에서는 허가 서버 (120) 에 관련된 양태들을 논의하는 동안 서버 (116) 를 참조할 것이다. 추가적인 단계들이 방법 (800) 의 단계들 전에, 동안, 및 후에 제공될 수 있고, 설명된 단계들의 일부가 방법 (800) 의 다른 실시형태들을 위해 재정렬, 대체 또는 제거될 수 있는 것으로 이해된다.
단계 (802) 에서, UE (102) 는, 예를 들어 도 7a 의 단계 (702) 에 대해 상기 설명된 바와 같이, 후원된 접속이 이용가능할 수도 있는 하나 이상의 서빙 네트워크들 (112) 을 식별한다.
단계 (804) 에서, UE (102) 는 후원된 접속의 이점을 취하려는 시도로 서빙 네트워크 (112) 에 어태치 요청을 전송한다. 하지만 도 7a 의 단계 (710) 에 반해, UE (102) 는 어태치 요청과 함께 사전-존재 크리덴셜에 기초하는 클라이언트 토큰을 전송하지 않는다 (UE (102) 는 또한 IMSI 또는 다른 셀룰러 크리덴셜을 전송하지 않는다). 대신에, 도 8a 내지 도 8c 의 실시형태들에 따르면, UE (102) 는 서버 (116) 에 대해 인증함에 있어서 보조하기 위해 서버 (116) 와의 사용자 인증 및 액세스 허가 통신에 의존할 것이다. MME (106) 는 서버 (116) 에 인증 요청을 전송한다.
단계 (806) 에서, MME (106) 가 전송한 인증 요청에 응답하여, UE (102) 는 서빙 네트워크 (112) 를 통해 서버 (116) 로부터 사용자 인증 및 액세스 허가 요청을 수신한다. UE (102) 는 서버 (116) 에 대해 (예컨대, 요청되는 곳 또는 때에 (예를 들어 사전-존재 액세스 크리덴셜의 형태로) 사용자 명칭 및/또는 패스워드를 입력 또는 제공함으로써) 필요한 정보로 그 요청에 응답한다. 상기 도 6 과 관련하여 논의되었던 바와 같이, 그리고 도 8b 및 도 8c 에서 이하 추가로 논의될 바와 같이, MME (106) 는, UE (102) 및 서버 (116) 가 사용자 인증 /액세스 허가를 완료한 후에, 서버 (116) 로부터 허가 코드를 수신한다. MME (106) 는, 후원된 접속의 이점을 취하기 위해 서빙 네트워크 (112) 에 대해 UE (102) 를 인증하기 위해 사용하는 서버 (116) 로부터의 사용자 프로파일 정보를 요청 및 수신하기 위해 MME (106) 가 사용가능한 액세스 토큰을 요청 및 수신하기 위해 이 허가 코드를 사용한다.
도 8b 로 가서, 플로우차트는 본 개시의 다양한 양태들에 따른, 애플리케이션 서비스 프로바이더에 의해 후원되는 서비스를 위한 네트워크 액세스를 승인하기 위한 예시적인 방법 (820) 을 나타낸다. 방법 (820) 은 (이 논의의 목적을 위해 허가 서버 (120) 의 기능을 역시 기술하는) 서버 (116) 에서 구현될 수도 있다. 추가적인 단계들이 방법 (820) 의 단계들 전에, 동안, 및 후에 제공될 수 있고, 설명된 단계들의 일부가 방법 (820) 의 다른 실시형태들을 위해 재정렬, 대체 또는 제거될 수 있는 것으로 이해된다.
단계 (822) 에서, 서버 (116) 는, 예를 들어 (UE (102) 로부터의 어태치 요청에 응답하여 요청을 전송한) MME (106) 로부터, 서빙 네트워크 (112) 로부터 인증 요청을 수신한다.
단계 (824) 에서, 서버 (116) 는 UE (102) 와 사용자 인증 및 액세스 허가를 완료하기 위해 서빙 네트워크 (112) 를 통해 UE (102) 와 요청을 개시한다. 예를 들어, 서빙 네트워크 (112) 의 엘리먼트들은, 도 6 의 액션 (606) 과 관련하여 상기 설명된 바와 같이 UE (102) 와 서버 (116) 사이의 사전-존재 크리덴셜에 관한 전방향 및 후방향으로의 하나 이상의 요청들 및 응답들을 수반할 수도 있는, 사용자 인증 및 액세스 허가 프로세스 동안 UE (102) 와 서버 (116) 사이에 통신물들을 반송할 수도 있다.
단계 (826) 에서, 서버 (116) 는, 사용자 인증/액세스 허가 프로세스의 일부로서, (예컨대, 서버 (116) 에서 저장된 또는 서버 (116) 에 의해 액세스가능한 프로파일에서 저장된 대응하는 값들에 대해 비교되는 바와 같이 적절한 사용자 명칭 및/또는 패스워드 크리덴셜들을 제공함으로써) UE (102) 가 성공적으로 인증하였는지 여부를 결정하기 위해 UE (102) 로부터의 응답들을 분석한다. 서버 (116) 는, (예컨대, UE (102) 와 연관된 사용자에 대해 서버 (116) 에서 사전에-저장된 허가를 로케이팅하거나 허가를 제공함으로써) UE (102) 가 액세스 허가를 완료하였는지 여부를 추가로 결정한다. 사용자 인증 및/또는 액세스 허가가 실패하는 경우에, 방법 (820) 은 단계 (842) 로 진행하고, 여기서, 프로세스는 종료된다 (그리고, 서버 (116) 는, UE (102) 의 사용자와 연관된 사용자 프로파일을 액세스하기 위해 서빙 네트워크 (112) 에 대해 주어진 허가의 결여 및/또는 부정확한 사용자 명칭/패스워드 결합과 같은, 프로세스가 왜 실패했는지를 나타내는 정보를 UE (102) 에 전송할 수도 있다).
사용자 인증 및 액세스 허가가 성공적인 경우에, 방법 (820) 은 단계 (828) 로 진행하고, 여기서, 서버 (116) 는, 예를 들어 도 6 과 관련하여 상기 설명된 바와 같이, (예를 들어, UE (102) 에 그리고 그 다음에 MME (106) 에 다시 역으로 리다이렉팅되는 대신에) MME (106) 에 허가 코드를 전송한다.
단계 (830) 에서, 서버 (116) 는, 액세스 토큰을 위해, 허가 코드를 포함하는 요청을 MME (106) 로부터 수신한다.
단계 (832) 에서, 서버 (116) 는 MME (106) 로부터의 토큰 요청과 함께 포함되는 허가 코드를 분석한다. (서버 (116) 가 저장된 채로 유지하는) MME (106) 에 대해 주어진 허가 코드와 단계 (830) 에서 MME (106) 로부터 수신된 허가 코드 사이에 미스매치가 존재하는 경우에, 요청은 거절되고, 방법 (820) 은 단계 (842) 로 진행하며, 여기서, 프로세스는 종료된다 (그리고 서버 (116) 는 프로세스가 실패한 이유를 나타내는 정보를 UE (102) 에 전송할 수도 있다).
성공적인 경우에, 방법 (820) 은 단계 (834) 로 진행하고, 여기서, 서버 (116) 는, 예를 들어, 도 6 의 액션 (612) 과 관련하여 상기 설명된 바와 같이, MME (106) 에 대해 요청된 액세스 토큰으로 액세스 토큰 요청에 대해 응답한다.
단계 (836) 에서, 서버 (116) 는 UE (102) 를 서빙 네트워크 (112) 에 어태치하기 위해 UE (102) 의 사용자의 사용자 프로파일에 대한 MME (106) 로부터의 요청을 수신한다. 사용자 프로파일에 대한 요청은 단계 (834) 의 결과로서 MME (106) 가 서버 (116) 로부터 수신한 액세스 토큰을 포함한다.
단계 (838) 에서, 서버 (116) 는, MME (106) 에 대해 요청된 정보를 릴리스 (release) 할지 여부를 결정하기 위해 포함된 액세스 토큰 및 요청을 분석한다. 단계 (836) 에서 MME (106) 로부터 수신된 액세스 토큰과 MME (106) 에 주어진 액세스 토큰 사이에 미스매치가 존재하는 경우에, 요청은 거절되고, 방법 (820) 은 단계 (842) 로 진행하며, 여기서, 프로세스는 종료된다 (그리고 서버 (116) 는 프로세스가 왜 실패했는지를 나타내는 정보를 UE (102) 에 전송할 수도 있다).
성공적인 경우, 단계 (840) 에서, 서버 (116) 는 요청된 사용자 프로파일을 MME (106) 에 전송한다. 그 결과로서, UE (102) 는, MME (106) 로 하여금 적절한 정보를 획득하기 위해 서버 (116) 와 대응하는 것을 허용하는 대신에, MME (106) 에 대한 어태치 요청에서 사전-존재 크리덴셜 (예컨대, 패스워드, 해쉬된 패스워드, 또는 UE (102) 에서 사전에 저장된 액세스 토큰 등) 을 제공함이 없이 서빙 네트워크 (112) 에 어태치하는 것이 가능하다.
도 8c 는 본 개시의 다양한 양태들에 따른, 애플리케이션 서비스 프로바이더에 의해 후원되는 서비스를 위한 네트워크 액세스를 용이하게 하기 위한 예시적인 방법 (850) 을 나타내는 플로우차트이다. 방법 (850) 은 MME (106) (및/또는 서빙 네트워크 (112) 의 다른 네트워크 엘리먼트들) 에서 구현될 수도 있다. 방법 (850) 은 논의의 단순성을 위해 MME (106) 에 대하여 설명될 것이지만, 본 명세서에서 설명된 양태들은 서빙 네트워크 (112) 에서의 하나 이상의 다른 네트워크 엘리먼트들에 적용가능할 수도 있다는 것이 인지될 것이다. 추가적인 단계들이 방법 (850) 의 단계들 전에, 동안, 및 후에 제공될 수 있고, 설명된 단계들의 일부가 방법 (850) 의 다른 실시형태들을 위해 재정렬, 대체 또는 제거될 수 있는 것으로 이해된다.
단계 (852) 에서, MME (106) 는 (사전-존재 크리덴셜 또는 가입자 식별자/셀룰러 크리덴셜에 기초하는 클라이언트 토큰을 포함하지 않는) UE (102) 로부터의 어태치 요청을 수신하고, 응답하여, 서버 (116) 에 인증 요청을 전송한다. 어태치 요청은, UE (102) 가 상기 논의된 도 5 의 액션 (504) 에서 인증 요청의 일부로서 클라이언트 토큰을 제공하는 대신에 서버 (116) 와 직접 인증하기를 희망하는 것을 나타내는 정보를 포함한다. 어태치 요청은, UE (102) 가 서버 (116) 와 직접 인증할 필요성이 있음을 나타내기 위해 MME (106) 가 이해하는 식별자를 명시적으로 포함할 수도 있거나, 이것은 어태치 요청이 클라이언트 토큰을 결여한다는 사실 때문에 MME (106) 에 의해 간접적으로 추론될 수도 있다.
단계 (854) 에서, MME (106) 는, 서버 (116) 로부터 UE (102) 로 사용자 인증/액세스 허가 요청을 중계하고, 또한 (예를 들어 사전-존재 크리덴셜의 일부 형태를 포함할 수도 있는) 응답들을 다시 역으로 UE (102) 로부터 서버 (116) 로 중계한다.
UE (102) 와 서버 (116) 사이에 사용자 인증/액세스 허가가 성공적인 경우에, 단계 (856) 에서, MME (106) 는 액세스 토큰을 요청하기 위해 사용될 수 있는 허가 코드를 서버 (116) 로부터 수신한다. 허가 코드는 예를 들어 UE (102) 로 그리고 다시 역으로 MME (106) 로 리다이렉팅되는 대신에 MME (106) 로 전송된다.
단계 (858) 에서, MME (106) 는 서버 (116) 로부터 UE (102) 와 연관된 사용자 프로파일에 대한 액세스를 얻기 위해 서버 (116) 에 액세스 토큰에 대한 요청을 전송한다. 요청의 일부로서, MME (106) 는 단계 (856) 에서 수신된 허가 코드를 포함한다.
단계 (860) 에서, MME (106) 는, 서버 (116) 가 MME (106) 를 인증하고 MME (106) 에 의해 제공된 허가 코드를 유효화한 후에, 요청된 액세스 토큰을 수신한다.
단계 (862) 에서, MME (106) 는, 서버 (116) 에 의해 호스팅되는 애플리케이션 서비스 프로바이더에 의해 후원되는 접속을 이용할 수도 있도록 UE (102) 의 어태치를 완료함에 있어서 MME (106) 가 서빙 네트워크 (112) 를 보조할 수도 있도록, UE (102) 의 사용자와 연관된 사용자 프로파일에 대한 요청을 전송한다.
단계 (864) 에서, MME (106) 는, 서버 (116) 가 요청 및 단계 (862) 에서의 요청에 포함된 액세스 토큰을 분석한 후에, 요청된 사용자 프로파일을 수신한다. 그 결과로서, UE (102) 는 어태치 요청에서 사전-존재 크리덴셜 (예컨대, 패스워드, 해쉬된 패스워드, 또는 UE (102) 에서 사전에 저장된 액세스 토큰 등) 을 제공함이 없이 서빙 네트워크 (112) 에 어태치하는 것이 가능하다.
정보 및 신호들은 다양한 상이한 기술들 및 기법들 중 임의의 것을 이용하여 표현될 수도 있다. 예를 들어, 상기 설명 전반에 걸쳐 참조될 수도 있는 데이터, 명령들, 커맨드들, 정보, 신호들, 비트들, 심볼들, 및 칩들은 전압들, 전류들, 전자기파들, 자기장들 또는 입자들, 광학장들 또는 입자들, 또는 그 임의의 조합으로 표현될 수도 있다.
본 명세서의 개시와 관련하여 설명된 다양한 예시적인 블록들 및 모듈들은 범용 프로세서, DSP, ASIC, FPGA 또는 다른 프로그래밍가능 로직 디바이스, 이산 게이트 또는 트랜지스터 로직, 이산 하드웨어 컴포넌트들, 또는 본 명세서에서 설명된 기능들을 수행하도록 설계된 그 임의의 조합으로 구현 또는 수행될 수도 있다. 범용 프로세서는 마이크로프로세서일 수도 있지만, 대안으로, 프로세서는 임의의 종래의 프로세서, 제어기, 마이크로제어기, 또는 상태 머신일 수도 있다. 프로세서는 또한 컴퓨팅 디바이스들의 조합 (예를 들어, DSP 와 마이크로프로세서의 조합, 다수의 마이크로프로세서들, DSP 코어와 결합된 하나 이상의 마이크로프로세서들, 또는 임의의 다른 이러한 구성) 으로서 구현될 수도 있다.
본 명세서에서 설명된 기능들은 하드웨어, 프로세서에 의해 실행된 소프트웨어, 펌웨어, 또는 그 임의의 조합에서 구현될 수도 있다. 프로세서에 의해 실행된 소프트웨어에서 구현되면, 기능들은 컴퓨터 판독가능 매체 상에 하나 이상의 명령들 또는 코드로서 저장 또는 이를 통해 송신될 수도 있다. 다른 예들 및 구현들은 본 개시 및 첨부된 청구항들의 범위 내에 있다. 예를 들어, 소프트웨어의 본성으로 인해, 상기 설명된 기능들은 프로세서에 의해 실행된 소프트웨어, 하드웨어, 펌웨어, 하드와이어링, 또는 이들 중 임의의 것의 조합들을 이용하여 구현될 수 있다. 기능들을 구현하는 피처들은 또한, 기능들의 부분들이 상이한 물리적 로케이션들에서 구현되도록 분포되는 것을 포함하여, 다양한 포지션들에 물리적으로 로케이팅될 수도 있다.
또한, 청구항들을 포함하여 본 명세서에서 사용한 바와 같이, 아이템들의 리스트 (예를 들어, "중 적어도 하나" 또는 "중 하나 이상" 과 같은 어구가 앞에 오는 아이템들의 리스트) 에서 사용한 바와 같은 "또는" 은, 예를 들어, [A, B, 또는 C 중 적어도 하나] 의 리스트가 A 또는 B 또는 C 또는 AB 또는 AC 또는 BC 또는 ABC (즉, A 및 B 및 C) 를 의미하도록 포괄적 리스트를 표시한다. 하나의 실시형태에 대해 설명된 피처들, 컴포넌트들, 액션들, 및/또는 단계들은 본원에 제시된 것과 다른 순서로 구조화될 수도 있고, 및/또는, 본 개시의 다른 실시형태들에 대해 설명된 피처들, 컴포넌트들, 액션들, 및/또는 단계들과 결합될 수도 있음이 또한 고려된다.
본 개시의 실시형태들은 서비스를 액세스하기 위한 사용자 장비 (UE) 를 포함하고, 이 사용자 장비는, 서빙 네트워크를 식별하는 수단으로서, 이 서빙 네트워크를 통해 애플리케이션 서비스 프로바이더 서버가 서비스에 대한 액세스를 후원하는, 상기 네트워크를 식별하는 수단; 애플리케이션 서비스 프로바이더 서버와 확립된 사전-존재 크리덴셜에 기초하는 클라이언트 토큰과 함께 서빙 네트워크에 어태치 요청을 전송하는 수단으로서, 클라이언트 토큰은 서빙 네트워크에 대한 셀룰러 액세스 크리덴셜로서 인식가능하지 않은, 상기 어태치 요청을 전송하는 수단; 및, 사전-존재 크리덴셜에 기초하여 애플리케이션 서비스 프로바이더 서버를 통해 서빙 네트워크에 서비스에 대한 후원된 액세스에 대해 인증하는 수단을 포함한다.
UE 는, 서비스에 대한 후원된 액세스를 이용하기 위한 인증을 위해 UE 에 의해 사용되는 인증 타입의 식별표시 (identification) 를 어태치 요청에 포함시키는 수단을 더 포함한다. UE 는, 애플리케이션 서비스 프로바이더 서버를 어떻게 로케이팅할지를 식별하는 정보를 어태치 요청에 포함시키는 수단을 더 포함한다. UE 는, 사전-존재 크리덴셜은 대역외 채널을 통해 생성된, 애플리케이션 서비스 프로바이더 서버와 확립된 패스워드에 기초는 것을 더 포함하고, UE 는, 애플리케이션 서비스 프로바이더 서버 및 패스워드와 연관된 사용자 명칭을 어태치 요청과 함께 포함시키는 수단; 사전-존재 크리덴셜을 생성하기 위해 제 1 값으로 패스워드를 해쉬하는 수단; 및, 어태치 요청에서 UE 로부터 전송되는 클라이언트 토큰을 생성하기 위해 제 2 값으로 사전-존재 크리덴셜을 해쉬하는 수단을 더 포함한다. UE 는, UE 에서, 서빙 네트워크를 통해 애플리케이션 서비스 프로바이더 서버로부터 인증 토큰을 수신하는 수단으로서, 서빙 네트워크는 사전-존재 크리덴셜에 기초하여 애플리케이션 서비스 프로바이더 서버에 의해 결정된 키를 저장하는, 상기 인증 토큰을 수신하는 수단; 인증 토큰을 유효화하는 수단; 및, 유효화에 응답하여, UE 에 의해 생성된 중간 패스워드 크리덴셜에 기초하여 UE-기반 키를 결정하는 수단을 더 포함한다. UE 는, 클라이언트 토큰이 사전-존재 크리덴셜의 증거로서 포함되고, 사전-존재 크리덴셜은 어태치 요청의 전송 이전에 UE 와 애플리케이션 서비스 프로바이더 서버 사이에 확립되는 것을 더 포함한다. UE 는, 전송 후에, 공유된 비밀 키에 대해 합의하기 위해 UE 와 애플리케이션 서비스 프로바이더 서버 사이에 핸드쉐이크를 수행하는 수단; UE 와 애플리케이션 서비스 프로바이더 서버 사이에 인증 세션의 지속기간 동안 유효한 공유된 비밀 키에 기초하여 베이스 키를 결정하는 수단; 및, 베이스 키에 기초하여 핸드쉐이크 후에 어태치 요청에 응답하여 수신된 인증 정보를 유효화하는 수단을 더 포함한다. UE 는, 서빙 네트워크로부터 후원된 액세스의 광고 (advertisement) 를 수신하는 수단을 더 포함한다. UE 는, 사전-존재 크리덴셜과 연관된 사용자 프로파일을 애플리케이션 서비스 프로바이더 서버로부터 취출하도록 서빙 네트워크로부터의 네트워크 엘리먼트를 허가하는 수단을 더 포함한다. UE 는, UE 가 가입자 아이덴티티 모듈 (SIM) 카드 없이 동작하는 것을 더 포함한다.
본 개시의 실시형태들은, 서비스에 대한 액세스를 후원하는 애플리케이션 서비스 프로바이더 서버를 더 포함하고, 이 애플리케이션 서비스 프로바이더 서버는, 중개 서빙 네트워크로부터, 사용자 장비 (UE) 로부터의 어태치 요청에 기초한 인증 정보 요청을 수신하는 수단으로서, 이 중개 서빙 네트워크를 통해 애플리케이션 서비스 프로바이더 서버가 서비스에 대한 액세스를 후원하고, 인증 정보 요청은 애플리케이션 서비스 프로바이더 서버와 확립된 사전-존재 크리덴셜에 기초하고 네트워크에 대한 셀룰러 액세스 크리덴셜로서 인식가능하지 않은 클라이언트 토큰을 포함하는, 상기 인증 정보 요청을 수신하는 수단; 인증 정보 요청에 응답하여 애플리케이션 서비스 프로바이더 서버에 의해 액세스가능한 사전-존재 크리덴셜에 기초하여 인증 정보를 결정하는 수단; 및, 서빙 네트워크에 응답하여 인증 정보를 송신하는 수단으로서, 이 인증 정보는, 사전-존재 크리덴셜에 기초하여 서비스에 대한 후원된 액세스를 위해 서빙 네트워크와 UE 사이에서의 인증을 돕는, 상기 인증 정보를 송신하는 수단을 포함한다.
애플리케이션 서비스 프로바이더는, 사전-존재 크리덴셜이 대역외 채널을 통해 생성된, 애플리케이션 서비스 프로바이더 서버와 확립된 패스워드에 기초하고, 인증 정보 요청은 애플리케이션 서비스 프로바이더 서버 및 패스워드와 연관된 사용자 명칭을 포함하는 것을 더 포함하고, 애플리케이션 서비스 프로바이더는, 애플리케이션 서비스 프로바이더 서버에 의해 액세스가능한 하나 이상의 레코드들에 기초하여 사용자 명칭 및 클라이언트 토큰을 검증하는 수단으로서, 클라이언트 토큰은 제 1 값으로 해쉬된 사전-존재 크리덴셜을 포함하고, 사전-존재 크리덴셜은 제 2 값으로 해쉬된 패스워드를 포함하는, 상기 검증하는 수단을 더 포함한다. 애플리케이션 서비스 프로바이더는, 공유된 키, 인증 토큰, 및 사전-존재 크리덴셜에 기초한 예상되는 응답을 포함하는 인증 벡터를 생성하는 수단을 더 포함한다. 애플리케이션 서비스 프로바이더는, 인증 정보 요청을 수신하기 이전에, UE 가 사전-존재 크리덴셜을 보유하는 증거로서 사용하도록 UE 에 클라이언트 토큰을 제공하는 수단을 더 포함한다. 애플리케이션 서비스 프로바이더는, 수신 후에, UE 와 애플리케이션 서비스 프로바이더 서버 사이에 핸드쉐이크에 기초하여 공유된 비밀 키에 대해 합의하는 수단; 공유된 비밀 키에 기초하여 베이스 키를 결정하는 수단; 및, 베이스 키, 인증 토큰, 및 사전-존재 크리덴셜에 기초한 예상되는 응답을 포함하는 인증 벡터를 생성하는 수단을 더 포함한다. 애플리케이션 서비스 프로바이더는, UE 를 대신하여 사용자 프로파일을 액세스하기 위해 네트워크 엘리먼트에 대해 UE 허가에 기초하여 서빙 네트워크로부터 네트워크 엘리먼트에 사전-존재 크리덴셜과 연관된 사용자 프로파일을 제공하는 수단을 더 포함한다. 애플리케이션 서비스 프로바이더는, 애플리케이션 서비스 프로바이더 서버와 서빙 네트워크 사이에 서비스-레벨 합의를 확립하는 수단을 더 포함하고, 서비스-레벨 합의에 응답하여, 서빙 네트워크는 이용가능한 디바이스들에 대해 후원된 액세스를 광고한다. 애플리케이션 서비스 프로바이더는, UE 와 서빙 네트워크 사이에 인증을 UE 가 완료하고, 후원된 액세스를 이용하는 것을 더 포함하고, 애플리케이션 서비스 프로바이더는, 서빙 네트워크로부터, 서빙 네트워크 상에서 UE 에 의한 서비스에 대한 후원된 액세스와 연관된 요금을 수신하는 수단을 더 포함한다. 애플리케이션 서비스 프로바이더는, 인증 정보 요청을 수신하기 이전에, UE 에 신뢰된 서빙 네트워크의 리스트를 제공하는 수단을 더 포함한다. 애플리케이션 서비스 프로바이더는, 중개 서빙 네트워크가 진화형 패킷 코어 (EPC) 네트워크를 포함하고, 애플리케이션 서비스 프로바이더가 EPC 네트워크의 외부에 있는 데이터 네트워크의 일부인 것을 더 포함한다.
통상의 기술자가 이미 인식할 바와 같이 및 장래에 특정한 애플리케이션에 의존하여, 많은 변경들, 치환들 및 변동들이 본 개시의 사상 및 범위로부터 벗어남 없이 본 개시의 디바이스들의 이용의 방법들, 재료들, 장치, 및 구성들에서 그리고 이들에 대해 이루어질 수 있다. 이것을 고려하여, 본 개시의 범위는 그들이 단지 그의 일부 예들을 예로 들 뿐이기 때문에 본 명세서에서 예시 및 설명된 특정한 실시형태들의 범위에 제한되어서는 안되고, 오히려, 이후에 첨부된 청구항들 및 그들의 기능적 등가물들의 것과 완전히 상응해야 한다.

Claims (45)

  1. 서비스를 액세스하는 방법으로서,
    사용자 장비 (UE) 에 의해 네트워크를 식별하는 단계로서, 상기 네트워크를 통해 애플리케이션 서비스 프로바이더 서버가 상기 서비스에 대한 액세스를 가능하게 하는, 상기 네트워크를 식별하는 단계;
    상기 UE 로부터, 상기 UE 와 연관되고 상기 애플리케이션 서비스 프로바이더 서버와 확립된 사전-존재 크리덴셜 (credential) 에 기초하는 클라이언트 토큰과 함께 상기 네트워크에 어태치 요청을 전송하는 단계로서, 상기 클라이언트 토큰은 상기 네트워크에 대한 셀룰러 액세스 크리덴셜로서 인식가능하지 않은, 상기 어태치 요청을 전송하는 단계; 및
    상기 UE 에 의해, 상기 사전-존재 크리덴셜에 기초하여 상기 애플리케이션 서비스 프로바이더 서버를 통해 상기 네트워크에 상기 서비스에 대한 후원된 액세스에 대해 인증하는 단계를 포함하는, 서비스를 액세스하는 방법.
  2. 제 1 항에 있어서,
    상기 방법은, 상기 서비스에 대한 후원된 액세스를 이용하기 위한 인증을 위해 상기 UE 에 의해 사용되는 인증 타입의 식별표시를 상기 어태치 요청에 포함시키는 단계를 더 포함하고,
    상기 어태치 요청을 전송하는 단계는, 상기 애플리케이션 서비스 프로바이더를 어떻게 로케이팅할지를 식별하는 정보를 상기 어태치 요청에 포함시키는 단계를 더 포함하는, 서비스를 액세스하는 방법.
  3. 제 1 항에 있어서,
    상기 사전-존재 크리덴셜은 대역외 채널을 통해 생성된, 상기 애플리케이션 서비스 프로바이더 서버와 확립된 패스워드에 기초하고,
    상기 어태치 요청을 전송하는 단계는,
    상기 애플리케이션 서비스 프로바이더 서버 및 상기 패스워드와 연관된 사용자 명칭을 상기 어태치 요청과 함께 포함시키는 단계;
    상기 UE 에 의해, 상기 사전-존재 크리덴셜을 생성하기 위해 제 1 값으로 상기 패스워드를 해쉬하는 단계; 및
    상기 UE 에 의해, 상기 어태치 요청에서 상기 UE 로부터 전송되는 상기 클라이언트 토큰을 생성하기 위해 제 2 값으로 상기 사전-존재 크리덴셜을 해쉬하는 단계를 더 포함하는, 서비스를 액세스하는 방법.
  4. 제 3 항에 있어서,
    상기 UE 에서, 상기 네트워크를 통해 상기 애플리케이션 서비스 프로바이더 서버로부터 인증 토큰을 수신하는 단계로서, 상기 네트워크는 상기 사전-존재 크리덴셜에 기초하여 상기 애플리케이션 서비스 프로바이더 서버에 의해 결정된 세션 키를 포함하는 인증 정보를 저장하고, 상기 세션 키는 상기 네트워크가 상기 UE 와 인증하는 것을 가능하게 하는, 상기 인증 토큰을 수신하는 단계;
    상기 UE 에 의해, 상기 인증 토큰을 유효화하는 단계; 및
    상기 유효화에 응답하여, 상기 UE 에 의해 생성된 중간 패스워드 크리덴셜에 기초하여 UE-기반 키를 결정하는 단계를 더 포함하는, 서비스를 액세스하는 방법.
  5. 제 1 항에 있어서,
    상기 어태치 요청을 전송하는 단계는, 상기 사전-존재 크리덴셜을 보유하는 증거로서 상기 클라이언트 토큰을 포함시키는 단계를 더 포함하고, 상기 사전-존재 크리덴셜은 상기 어태치 요청의 전송 이전에 상기 UE 와 상기 애플리케이션 서비스 프로바이더 서버 사이에 확립되는, 서비스를 액세스하는 방법.
  6. 제 1 항에 있어서,
    상기 전송 후에, 공유된 비밀 키에 대해 합의하기 위해 상기 UE 와 상기 애플리케이션 서비스 프로바이더 서버 사이에 핸드쉐이크를 수행하는 단계;
    상기 UE 에 의해, 상기 UE 와 상기 애플리케이션 서비스 프로바이더 서버 사이에 인증 세션의 지속기간 동안 유효한 상기 공유된 비밀 키에 기초한 베이스 키를 결정하는 단계; 및
    상기 UE 에 의해, 상기 베이스 키에 기초하여 상기 핸드쉐이크 후에 상기 어태치 요청에 응답하여 수신된 인증 정보를 유효화하는 단계를 더 포함하는, 서비스를 액세스하는 방법.
  7. 제 1 항에 있어서,
    상기 네트워크를 식별하는 단계는, 상기 네트워크로부터 상기 후원된 액세스의 광고를 수신하는 단계를 더 포함하는, 서비스를 액세스하는 방법.
  8. 제 1 항에 있어서,
    상기 사전-존재 크리덴셜과 연관된 사용자 프로파일을 상기 애플리케이션 서비스 프로바이더 서버로부터 취출하도록 상기 네트워크로부터의 네트워크 엘리먼트를 허가하는 단계를 더 포함하는, 서비스를 액세스하는 방법.
  9. 제 1 항에 있어서,
    상기 UE 는,
    셀룰러 서비스 프로바이더에 대한 서브스크립션을 결여한 것; 및
    가입자 아이덴티티 모듈 (SIM) 카드 없이 동작하는 것
    중 적어도 하나에 해당하는, 서비스를 액세스하는 방법.
  10. 애플리케이션 서비스 프로바이더 서버에 의한 후원된 서비스에 대한 액세스를 가능하게 하는 방법으로서,
    중개 네트워크로부터, 사용자 장비 (UE) 로부터의 어태치 요청에 기초한 인증 정보 요청을 수신하는 단계로서, 상기 중개 네트워크를 통해 상기 애플리케이션 서비스 프로바이더 서버가 상기 서비스에 대한 액세스를 후원하고, 상기 인증 정보 요청은 상기 UE 와 연관되고 상기 애플리케이션 서비스 프로바이더 서버와 확립된 사전-존재 크리덴셜 (credential) 에 기초하는 클라이언트 토큰을 포함하며, 상기 클라이언트 토큰은 상기 네트워크에 대한 셀룰러 액세스 크리덴셜로서 인식가능하지 않은, 상기 인증 정보 요청을 수신하는 단계;
    상기 애플리케이션 서비스 프로바이더 서버에 의해, 상기 인증 정보 요청에 응답하여 상기 애플리케이션 서비스 프로바이더 서버에 의해 액세스가능한 상기 사전-존재 크리덴셜에 기초하여 인증 정보를 결정하는 단계; 및
    상기 네트워크에 응답하여 상기 인증 정보를, 상기 애플리케이션 서비스 프로바이더 서버로부터 송신하는 단계로서, 상기 인증 정보는, 상기 사전-존재 크리덴셜에 기초하여 상기 서비스에 대한 후원된 액세스를 위해 상기 네트워크와 상기 UE 사이에서의 인증을 돕도록 구성되는, 상기 인증 정보를 송신하는 단계를 포함하는, 후원된 서비스에 대한 액세스를 가능하게 하는 방법.
  11. 제 10 항에 있어서,
    상기 사전-존재 크리덴셜은 대역외 채널을 통해 생성된, 상기 애플리케이션 서비스 프로바이더 서버와 확립된 패스워드에 기초하고, 상기 인증 정보 요청은 상기 애플리케이션 서비스 프로바이더 서버 및 상기 패스워드와 연관된 사용자 명칭을 포함하며,
    상기 인증 정보를 결정하는 단계는,
    상기 애플리케이션 서비스 프로바이더 서버에 의해 액세스가능한 하나 이상의 레코드들에 기초하여 상기 사용자 명칭 및 클라이언트 토큰을 상기 애플리케이션 서비스 프로바이더 서버에 의해 검증하는 단계로서, 상기 클라이언트 토큰은 제 1 값으로 해쉬된 상기 사전-존재 크리덴셜을 포함하고, 상기 사전-존재 크리덴셜은 제 2 값으로 해쉬된 상기 패스워드를 포함하는, 상기 검증하는 단계를 더 포함하는, 후원된 서비스에 대한 액세스를 가능하게 하는 방법.
  12. 제 11 항에 있어서,
    상기 애플리케이션 서비스 프로바이더 서버에 의해, 공유된 키, 인증 토큰, 및 상기 사전-존재 크리덴셜에 기초한 예상되는 응답을 포함하는 인증 벡터를 생성하는 단계를 더 포함하는, 후원된 서비스에 대한 액세스를 가능하게 하는 방법.
  13. 제 10 항에 있어서,
    상기 인증 정보 요청을 수신하는 단계는, 상기 애플리케이션 서비스 프로바이더 서버에 의해, 상기 인증 정보 요청을 수신하기 이전에, 상기 UE 가 상기 사전-존재 크리덴셜을 보유하는 증거로서 사용하도록 상기 UE 에 상기 클라이언트 토큰을 제공하는 단계를 더 포함하는, 후원된 서비스에 대한 액세스를 가능하게 하는 방법.
  14. 제 10 항에 있어서,
    상기 인증 정보 요청의 수신 후에, 상기 UE 와 상기 애플리케이션 서비스 프로바이더 서버 사이에 핸드쉐이크에 기초하여 공유된 비밀 키에 대해 합의하는 단계;
    상기 애플리케이션 서비스 프로바이더 서버에 의해, 상기 공유된 비밀 키에 기초하여 베이스 키를 결정하는 단계; 및
    상기 애플리케이션 서비스 프로바이더 서버에 의해, 상기 베이스 키, 인증 토큰, 및 상기 사전-존재 크리덴셜에 기초한 예상되는 응답을 포함하는 인증 벡터를 생성하는 단계를 더 포함하는, 후원된 서비스에 대한 액세스를 가능하게 하는 방법.
  15. 제 10 항에 있어서,
    상기 인증 정보 요청의 수신 이전에, 신뢰된 네트워크들의 리스트를 상기 UE 에 제공하는 단계를 더 포함하는, 후원된 서비스에 대한 액세스를 가능하게 하는 방법.
  16. 서비스를 액세스하기 위한 사용자 장비 (UE) 로서,
    네트워크를 식별하는 것을 보조하는 것으로서, 상기 네트워크를 통해 애플리케이션 서비스 프로바이더 서버가 상기 서비스에 대한 액세스를 가능하게 하는, 상기 네트워크를 식별하는 것을 보조하는 것을 행하고; 그리고
    상기 UE 와 연관되고 상기 애플리케이션 서비스 프로바이더 서버와 확립된 사전-존재 크리덴셜 (credential) 에 기초하는 클라이언트 토큰과 함께 상기 네트워크에 어태치 요청을 전송하는 것으로서, 상기 클라이언트 토큰은 상기 네트워크에 대한 셀룰러 액세스 크리덴셜로서 인식가능하지 않은, 상기 어태치 요청을 전송하는 것을 행하도록
    구성된 트랜시버; 및
    상기 사전-존재 크리덴셜에 기초하여 상기 애플리케이션 서비스 프로바이더 서버를 통해 상기 네트워크에 상기 서비스에 대한 후원된 액세스에 대해 인증하도록 구성되는 프로세서를 포함하는, 서비스를 액세스하기 위한 사용자 장비.
  17. 제 16 항에 있어서,
    상기 프로세서는,
    상기 서비스에 대한 후원된 액세스를 이용하기 위한 인증을 위해 상기 UE 에 의해 사용되는 인증 타입의 식별표시를 상기 어태치 요청에 포함시키고,
    상기 애플리케이션 서비스 프로바이더를 어떻게 로케이팅할지를 식별하는 정보를 상기 어태치 요청에 포함시키도록 더 구성되는, 서비스를 액세스하기 위한 사용자 장비.
  18. 제 16 항에 있어서,
    상기 사전-존재 크리덴셜은 대역외 채널을 통해 생성된, 상기 애플리케이션 서비스 프로바이더 서버와 확립된 패스워드에 기초하고,
    상기 프로세서는,
    상기 애플리케이션 서비스 프로바이더 서버 및 상기 패스워드와 연관된 사용자 명칭을 상기 어태치 요청과 함께 포함시키고;
    상기 사전-존재 크리덴셜을 생성하기 위해 제 1 값으로 상기 패스워드를 해쉬하며; 그리고
    상기 어태치 요청에서 상기 UE 로부터 전송되는 상기 클라이언트 토큰을 생성하기 위해 제 2 값으로 상기 사전-존재 크리덴셜을 해쉬하도록 더 구성되는, 서비스를 액세스하기 위한 사용자 장비.
  19. 제 18 항에 있어서,
    상기 트랜시버는, 상기 네트워크를 통해 상기 애플리케이션 서비스 프로바이더 서버로부터 인증 토큰을 수신하도록 더 구성되고, 상기 네트워크는 상기 사전-존재 크리덴셜에 기초하여 상기 애플리케이션 서비스 프로바이더 서버에 의해 결정된 세션 키를 포함하는 인증 정보를 저장하고, 상기 세션 키는 상기 네트워크가 상기 UE 와 인증하는 것을 가능하게 하며; 그리고
    상기 프로세서는, 상기 인증 토큰을 유효화하고, 상기 유효화에 응답하여, 상기 UE 에 의해 생성된 사전-존재 크리덴셜에 기초하여 UE-기반 키를 결정하도록 더 구성되는, 서비스를 액세스하기 위한 사용자 장비.
  20. 제 16 항에 있어서,
    상기 클라이언트 토큰은 상기 사전-존재 크리덴셜을 보유하는 증거를 나타내며, 그리고
    상기 사전-존재 크리덴셜은 상기 어태치 요청의 전송 이전에 상기 UE 와 상기 애플리케이션 서비스 프로바이더 서버 사이에 확립되는, 서비스를 액세스하기 위한 사용자 장비.
  21. 제 16 항에 있어서,
    상기 트랜시버는, 상기 어태치 요청의 전송 후에, 공유된 비밀 키에 대해 합의하기 위해 상기 UE 와 상기 애플리케이션 서비스 프로바이더 서버 사이에 핸드쉐이크를 수행하도록 더 구성되고; 그리고
    상기 프로세서는, 상기 UE 와 상기 애플리케이션 서비스 프로바이더 서버 사이에 인증 세션의 지속기간 동안 유효한, 상기 공유된 비밀 키에 기초한 베이스 키를 결정하고, 상기 베이스 키에 기초하여 상기 핸드쉐이크 후에 상기 어태치 요청에 응답하여 수신된 인증 정보를 유효화하도록 더 구성되는, 서비스를 액세스하기 위한 사용자 장비.
  22. 제 16 항에 있어서,
    상기 트랜시버는, 상기 네트워크로부터 상기 후원된 액세스의 광고를 수신하도록 더 구성되는, 서비스를 액세스하기 위한 사용자 장비.
  23. 제 16 항에 있어서,
    상기 프로세서는, 상기 사전-존재 크리덴셜과 연관된 사용자 프로파일을 상기 애플리케이션 서비스 프로바이더 서버로부터 취출하도록 상기 네트워크로부터의 네트워크 엘리먼트를 허가하도록 더 구성되는, 서비스를 액세스하기 위한 사용자 장비.
  24. 제 16 항에 있어서,
    상기 UE 는 가입자 아이덴티티 모듈 (SIM) 카드 없이 동작하는, 서비스를 액세스하기 위한 사용자 장비.
  25. 서비스에 대한 액세스를 후원하는 애플리케이션 서비스 프로바이더 서버로서,
    중개 네트워크로부터, 사용자 장비 (UE) 로부터의 어태치 요청에 기초한 인증 정보 요청을 수신하는 것으로서, 상기 중개 네트워크를 통해 상기 애플리케이션 서비스 프로바이더 서버가 상기 서비스에 대한 액세스를 후원하고, 상기 인증 정보 요청은 상기 UE 와 연관되고 상기 애플리케이션 서비스 프로바이더 서버와 확립된 사전-존재 크리덴셜 (credential) 에 기초하는 클라이언트 토큰을 포함하며, 상기 클라이언트 토큰은 상기 네트워크에 대한 셀룰러 액세스 크리덴셜로서 인식가능하지 않은, 상기 인증 정보 요청을 수신하는 것을 행하도록 구성된 트랜시버; 및
    상기 인증 정보 요청에 응답하여 상기 애플리케이션 서비스 프로바이더 서버에 의해 액세스가능한 상기 사전-존재 크리덴셜에 기초하여 인증 정보를 결정하도록 구성되는 프로세서를 포함하고,
    상기 트랜시버는, 상기 네트워크에 응답하여 상기 인증 정보를 송신하도록 더 구성되고, 그리고
    상기 인증 정보는, 상기 사전-존재 크리덴셜에 기초하여 상기 서비스에 대한 후원된 액세스를 위해 상기 네트워크와 상기 UE 사이에서의 인증을 돕는, 서비스에 대한 액세스를 후원하는 애플리케이션 서비스 프로바이더 서버.
  26. 제 25 항에 있어서,
    상기 사전-존재 크리덴셜은 대역외 채널을 통해 생성된, 상기 애플리케이션 서비스 프로바이더 서버와 확립된 패스워드에 기초하고, 상기 인증 정보 요청은 상기 애플리케이션 서비스 프로바이더 서버 및 상기 패스워드와 연관된 사용자 명칭을 포함하며,
    상기 프로세서는,
    상기 애플리케이션 서비스 프로바이더 서버에 의해 액세스가능한 하나 이상의 레코드들에 기초하여 상기 사용자 명칭 및 클라이언트 토큰을 검증하도록 더 구성되고, 상기 클라이언트 토큰은 제 1 값으로 해쉬된 상기 사전-존재 크리덴셜을 포함하고, 상기 사전-존재 크리덴셜은 제 2 값으로 해쉬된 상기 패스워드를 포함하는, 서비스에 대한 액세스를 후원하는 애플리케이션 서비스 프로바이더 서버.
  27. 제 26 항에 있어서,
    상기 프로세서는, 공유된 키, 인증 토큰, 및 상기 사전-존재 크리덴셜에 기초한 예상되는 응답을 포함하는 인증 벡터를 생성하도록 더 구성되는, 서비스에 대한 액세스를 후원하는 애플리케이션 서비스 프로바이더 서버.
  28. 제 25 항에 있어서,
    상기 트랜시버는, 상기 인증 정보 요청을 수신하기 이전에, 상기 UE 가 상기 사전-존재 크리덴셜을 보유하는 증거로서 사용하도록 상기 UE 에 상기 클라이언트 토큰을 제공하도록 더 구성되는, 서비스에 대한 액세스를 후원하는 애플리케이션 서비스 프로바이더 서버.
  29. 제 25 항에 있어서,
    상기 프로세서는,
    상기 인증 정보 요청의 수신 후에, 상기 UE 와 상기 애플리케이션 서비스 프로바이더 서버 사이에 핸드쉐이크에 기초하여 공유된 비밀 키에 대해 합의하고;
    상기 공유된 비밀 키에 기초하여 베이스 키를 결정하며; 그리고
    상기 베이스 키, 인증 토큰, 및 상기 사전-존재 크리덴셜에 기초한 예상되는 응답을 포함하는 인증 벡터를 생성하도록 더 구성되는, 서비스에 대한 액세스를 후원하는 애플리케이션 서비스 프로바이더 서버.
  30. 제 25 항에 있어서,
    상기 프로세서는, 상기 인증 정보 요청의 수신 이전에, 신뢰된 네트워크들의 리스트를 상기 UE 에 제공하도록 더 구성되는, 서비스에 대한 액세스를 후원하는 애플리케이션 서비스 프로바이더 서버.
  31. 프로그램 코드를 기록한 컴퓨터 판독가능 저장 매체로서,
    상기 프로그램 코드는,
    사용자 장비 (UE) 로 하여금 네트워크를 식별하게 하기 위한 코드로서, 상기 네트워크를 통해 애플리케이션 서비스 프로바이더 서버가 상기 서비스에 대한 액세스를 가능하게 하는, 상기 네트워크를 식별하게 하기 위한 코드;
    상기 UE 로 하여금, 상기 UE 와 연관되고 상기 애플리케이션 서비스 프로바이더 서버와 확립된 사전-존재 크리덴셜 (credential) 에 기초하는 클라이언트 토큰과 함께 상기 네트워크에 어태치 요청을 전송하게 하기 위한 코드로서, 상기 클라이언트 토큰은 상기 네트워크에 대한 셀룰러 액세스 크리덴셜로서 인식가능하지 않은, 상기 어태치 요청을 전송하게 하기 위한 코드; 및
    상기 UE 로 하여금, 상기 사전-존재 크리덴셜에 기초하여 상기 애플리케이션 서비스 프로바이더 서버를 통해 상기 네트워크에 상기 서비스에 대한 후원된 액세스에 대해 인증하게 하기 위한 코드를 포함하는, 컴퓨터 판독가능 저장 매체.
  32. 제 31 항에 있어서,
    상기 UE 로 하여금, 상기 서비스에 대한 후원된 액세스를 이용하기 위한 인증을 위해 상기 UE 에 의해 사용되는 인증 타입의 식별표시를 상기 어태치 요청에 포함시키게 하기 위한 코드; 및
    상기 UE 로 하여금, 상기 애플리케이션 서비스 프로바이더 서버를 어떻게 로케이팅할지를 식별하는 정보를 상기 어태치 요청에 포함시키게 하기 위한 코드를 더 포함하는, 컴퓨터 판독가능 저장 매체.
  33. 제 31 항에 있어서,
    상기 사전-존재 크리덴셜은 대역외 채널을 통해 생성된, 상기 애플리케이션 서비스 프로바이더 서버와 확립된 패스워드에 기초하고,
    상기 컴퓨터 판독가능 저장 매체는,
    상기 UE 로 하여금, 상기 애플리케이션 서비스 프로바이더 서버 및 상기 패스워드와 연관된 사용자 명칭을 상기 어태치 요청과 함께 포함시키게 하기 위한 코드;
    상기 UE 로 하여금, 상기 사전-존재 크리덴셜을 생성하기 위해 제 1 값으로 상기 패스워드를 해쉬하게 하기 위한 코드; 및
    상기 UE 로 하여금, 상기 어태치 요청에서 상기 UE 로부터 전송되는 상기 클라이언트 토큰을 생성하기 위해 제 2 값으로 상기 사전-존재 크리덴셜을 해쉬하게 하기 위한 코드를 더 포함하는, 컴퓨터 판독가능 저장 매체.
  34. 제 33 항에 있어서,
    상기 UE 로 하여금, 상기 네트워크를 통해 상기 애플리케이션 서비스 프로바이더 서버로부터 인증 토큰을 수신하게 하기 위한 코드로서, 상기 네트워크는 상기 사전-존재 크리덴셜에 기초하여 상기 애플리케이션 서비스 프로바이더 서버에 의해 결정된 세션 키를 포함하는 인증 정보를 저장하고, 상기 세션 키는 상기 네트워크가 상기 UE 와 인증하는 것을 가능하게 하는, 상기 인증 토큰을 수신하게 하기 위한 코드;
    상기 UE 로 하여금, 상기 인증 토큰을 유효화하게 하기 위한 코드; 및
    상기 UE 로 하여금, 상기 유효화에 응답하여, 상기 UE 에 의해 생성된 중간 패스워드 크리덴셜에 기초하여 UE-기반 키를 결정하게 하기 위한 코드를 더 포함하는, 컴퓨터 판독가능 저장 매체.
  35. 제 31 항에 있어서,
    상기 UE 로 하여금, 상기 사전-존재 크리덴셜을 보유하는 증거로서 상기 클라이언트 토큰을 포함시키게 하기 위한 코드를 더 포함하고, 상기 사전-존재 크리덴셜은 상기 어태치 요청의 전송 이전에 상기 UE 와 상기 애플리케이션 서비스 프로바이더 서버 사이에 확립되는, 컴퓨터 판독가능 저장 매체.
  36. 제 31 항에 있어서,
    상기 UE 로 하여금, 상기 전송 후에, 공유된 비밀 키에 대해 합의하기 위해 상기 UE 와 상기 애플리케이션 서비스 프로바이더 서버 사이에 핸드쉐이크를 수행하게 하기 위한 코드;
    상기 UE 로 하여금, 상기 UE 와 상기 애플리케이션 서비스 프로바이더 서버 사이에 인증 세션의 지속기간 동안 유효한 상기 공유된 비밀 키에 기초한 베이스 키를 결정하게 하기 위한 코드; 및
    상기 UE 로 하여금, 상기 베이스 키에 기초하여 상기 핸드쉐이크 후에 상기 어태치 요청에 응답하여 수신된 인증 정보를 유효화하게 하기 위한 코드를 더 포함하는, 컴퓨터 판독가능 저장 매체.
  37. 제 31 항에 있어서,
    상기 UE 로 하여금, 상기 네트워크로부터 상기 후원된 액세스의 광고를 수신하게 하기 위한 코드를 더 포함하는, 컴퓨터 판독가능 저장 매체.
  38. 제 31 항에 있어서,
    상기 UE 로 하여금, 상기 사전-존재 크리덴셜과 연관된 사용자 프로파일을 상기 애플리케이션 서비스 프로바이더 서버로부터 취출하도록 상기 네트워크로부터의 네트워크 엘리먼트를 허가하게 하기 위한 코드를 더 포함하는, 컴퓨터 판독가능 저장 매체.
  39. 제 31 항에 있어서,
    상기 UE 는 가입자 아이덴티티 모듈 (SIM) 카드 없이 동작하는, 컴퓨터 판독가능 저장 매체.
  40. 프로그램 코드를 기록한 컴퓨터 판독가능 저장 매체로서,
    상기 프로그램 코드는,
    애플리케이션 서비스 프로바이더 서버로 하여금, 중개 네트워크로부터, 사용자 장비 (UE) 로부터의 어태치 요청에 기초한 인증 정보 요청을 수신하게 하기 위한 코드로서, 상기 중개 네트워크를 통해 상기 애플리케이션 서비스 프로바이더 서버가 상기 서비스에 대한 액세스를 후원하고, 상기 인증 정보 요청은 상기 UE 와 연관되고 상기 애플리케이션 서비스 프로바이더 서버와 확립된 사전-존재 크리덴셜 (credential) 에 기초하는 클라이언트 토큰을 포함하며, 상기 클라이언트 토큰은 상기 네트워크에 대한 셀룰러 액세스 크리덴셜로서 인식가능하지 않은, 상기 인증 정보 요청을 수신하게 하기 위한 코드;
    상기 애플리케이션 서비스 프로바이더 서버로 하여금, 상기 인증 정보 요청에 응답하여 상기 애플리케이션 서비스 프로바이더 서버에 의해 액세스가능한 상기 사전-존재 크리덴셜에 기초하여 인증 정보를 결정하게 하기 위한 코드; 및
    상기 애플리케이션 서비스 프로바이더 서버로 하여금, 상기 네트워크에 응답하여 상기 인증 정보를 송신하게 하기 위한 코드로서, 상기 인증 정보는, 상기 사전-존재 크리덴셜에 기초하여 상기 서비스에 대한 후원된 액세스를 위해 상기 네트워크와 상기 UE 사이에서의 인증을 돕도록 구성되는, 상기 인증 정보를 송신하게 하기 위한 코드를 포함하는, 컴퓨터 판독가능 저장 매체.
  41. 제 40 항에 있어서,
    상기 액세스 크리덴셜은 대역외 채널을 통해 생성된, 상기 애플리케이션 서비스 프로바이더 서버와 확립된 패스워드에 기초하고, 상기 인증 정보 요청은 상기 애플리케이션 서비스 프로바이더 서버 및 상기 패스워드와 연관된 사용자 명칭을 포함하며,
    상기 컴퓨터 판독가능 저장 매체는, 상기 애플리케이션 서비스 프로바이더 서버로 하여금, 상기 애플리케이션 서비스 프로바이더 서버에 의해 액세스가능한 하나 이상의 레코드들에 기초하여 상기 사용자 명칭 및 클라이언트 토큰을 상기 애플리케이션 서비스 프로바이더 서버에 의해 검증하게 하기 위한 코드를 더 포함하고, 상기 클라이언트 토큰은 제 1 값으로 해쉬된 상기 사전-존재 크리덴셜을 포함하고, 상기 사전-존재 크리덴셜은 제 2 값으로 해쉬된 상기 패스워드를 포함하는, 컴퓨터 판독가능 저장 매체.
  42. 제 41 항에 있어서,
    상기 애플리케이션 서비스 프로바이더 서버로 하여금, 공유된 키, 인증 토큰, 및 상기 사전-존재 크리덴셜에 기초한 예상되는 응답을 포함하는 인증 벡터를 생성하게 하기 위한 코드를 더 포함하는, 컴퓨터 판독가능 저장 매체.
  43. 제 40 항에 있어서,
    상기 애플리케이션 서비스 프로바이더 서버로 하여금, 상기 인증 정보 요청을 수신하기 이전에, 상기 UE 가 상기 사전-존재 크리덴셜을 보유하는 증거로서 사용하도록 상기 UE 에 상기 클라이언트 토큰을 제공하게 하기 위한 코드를 더 포함하는, 컴퓨터 판독가능 저장 매체.
  44. 제 40 항에 있어서,
    상기 애플리케이션 서비스 프로바이더 서버로 하여금, 상기 인증 정보 요청의 수신 후에, 상기 UE 와 상기 애플리케이션 서비스 프로바이더 서버 사이에 핸드쉐이크에 기초하여 공유된 비밀 키에 대해 합의하게 하기 위한 코드;
    상기 애플리케이션 서비스 프로바이더 서버로 하여금, 상기 공유된 비밀 키에 기초하여 베이스 키를 결정하게 하기 위한 코드; 및
    상기 애플리케이션 서비스 프로바이더 서버로 하여금, 상기 베이스 키, 인증 토큰, 및 상기 사전-존재 크리덴셜에 기초한 예상되는 응답을 포함하는 인증 벡터를 생성하게 하기 위한 코드를 더 포함하는, 컴퓨터 판독가능 저장 매체.
  45. 제 40 항에 있어서,
    상기 애플리케이션 서비스 프로바이더 서버로 하여금, 상기 인증 정보 요청의 수신 이전에, 신뢰된 네트워크들의 리스트를 상기 UE 에 제공하게 하기 위한 코드를 더 포함하는, 컴퓨터 판독가능 저장 매체.
KR1020177024843A 2015-03-06 2016-02-22 기존의 크리덴셜들을 이용한 셀룰러 네트워크들에 대한 후원된 접속을 위한 방법, 사용자 장비 및 컴퓨터 판독가능 저장매체 KR101819878B1 (ko)

Applications Claiming Priority (5)

Application Number Priority Date Filing Date Title
US201562129462P 2015-03-06 2015-03-06
US62/129,462 2015-03-06
US14/817,123 US9717003B2 (en) 2015-03-06 2015-08-03 Sponsored connectivity to cellular networks using existing credentials
US14/817,123 2015-08-03
PCT/US2016/018855 WO2016144516A1 (en) 2015-03-06 2016-02-22 Sponsored connectivity to cellular networks using existing credentials

Related Child Applications (1)

Application Number Title Priority Date Filing Date
KR1020177037511A Division KR101858929B1 (ko) 2015-03-06 2016-02-22 기존의 크리덴셜들을 이용한 셀룰러 네트워크들에 대한 후원된 접속

Publications (2)

Publication Number Publication Date
KR20170106490A true KR20170106490A (ko) 2017-09-20
KR101819878B1 KR101819878B1 (ko) 2018-02-28

Family

ID=56850049

Family Applications (2)

Application Number Title Priority Date Filing Date
KR1020177037511A KR101858929B1 (ko) 2015-03-06 2016-02-22 기존의 크리덴셜들을 이용한 셀룰러 네트워크들에 대한 후원된 접속
KR1020177024843A KR101819878B1 (ko) 2015-03-06 2016-02-22 기존의 크리덴셜들을 이용한 셀룰러 네트워크들에 대한 후원된 접속을 위한 방법, 사용자 장비 및 컴퓨터 판독가능 저장매체

Family Applications Before (1)

Application Number Title Priority Date Filing Date
KR1020177037511A KR101858929B1 (ko) 2015-03-06 2016-02-22 기존의 크리덴셜들을 이용한 셀룰러 네트워크들에 대한 후원된 접속

Country Status (11)

Country Link
US (2) US9717003B2 (ko)
EP (1) EP3266180B1 (ko)
JP (1) JP6470846B2 (ko)
KR (2) KR101858929B1 (ko)
CN (2) CN110086833B (ko)
AU (2) AU2016229439B2 (ko)
BR (1) BR112017019089B1 (ko)
ES (1) ES2724099T3 (ko)
HU (1) HUE041995T2 (ko)
TW (1) TWI616084B (ko)
WO (1) WO2016144516A1 (ko)

Families Citing this family (44)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US9083739B1 (en) 2014-05-29 2015-07-14 Shape Security, Inc. Client/server authentication using dynamic credentials
US9717003B2 (en) 2015-03-06 2017-07-25 Qualcomm Incorporated Sponsored connectivity to cellular networks using existing credentials
US9807086B2 (en) * 2015-04-15 2017-10-31 Citrix Systems, Inc. Authentication of a client device based on entropy from a server or other device
US9979562B2 (en) * 2015-05-27 2018-05-22 Sprint Communications Company L.P. Network function virtualization requirements to service a long term evolution (LTE) network
CZ2015473A3 (cs) * 2015-07-07 2017-02-08 Aducid S.R.O. Způsob zabezpečení autentizace při elektronické komunikaci
US10425414B1 (en) * 2015-08-31 2019-09-24 United Services Automobile Association (Usaa) Security platform
US10582382B2 (en) * 2015-09-01 2020-03-03 Telefonaktiebolaget Lm Ericsson (Publ) Methods and devices of authenticating non-SIM mobile terminals accessing a wireless communication network
US9826379B2 (en) * 2015-09-29 2017-11-21 Verizon Patent And Licensing Inc. Methods and systems for facilitating subsidized access by a user to network content
KR102381377B1 (ko) * 2015-10-07 2022-03-31 삼성전자주식회사 통신 시스템에서 프로파일을 원격으로 제공하는 방법 및 장치
US20170171752A1 (en) * 2015-12-14 2017-06-15 Qualcomm Incorporated Securing signaling interface between radio access network and a service management entity to support service slicing
RU2706173C1 (ru) * 2016-01-05 2019-11-14 Хуавей Текнолоджиз Ко., Лтд. Способ, аппаратура и устройство мобильной связи
US11197331B2 (en) * 2016-06-10 2021-12-07 Apple Inc. Zero-round-trip-time connectivity over the wider area network
WO2018000396A1 (zh) * 2016-06-30 2018-01-04 华为技术有限公司 一种身份认证方法及通信终端
CN108377495B (zh) * 2016-10-31 2021-10-15 华为技术有限公司 一种数据传输方法、相关设备及系统
US10693867B2 (en) * 2017-03-01 2020-06-23 Futurewei Technologies, Inc. Apparatus and method for predictive token validation
WO2019010101A1 (en) * 2017-07-01 2019-01-10 Shape Security, Inc. SECURE DETECTION AND MANAGEMENT OF COMPROMISED IDENTITY SUPPORTERS
WO2019017865A1 (en) * 2017-07-17 2019-01-24 Sony Mobile Communications Inc. APPLICATION-LEVEL SERVICE IDENTITY SUPPORTERS FOR NETWORK ACCESS AUTHENTICATION
US10932129B2 (en) * 2017-07-24 2021-02-23 Cisco Technology, Inc. Network access control
WO2019075608A1 (zh) * 2017-10-16 2019-04-25 Oppo广东移动通信有限公司 一种加密数据流的识别方法、设备、存储介质及系统
WO2019076025A1 (zh) * 2017-10-16 2019-04-25 Oppo广东移动通信有限公司 一种加密数据流的识别方法、设备、存储介质及系统
CN107708138B (zh) * 2017-11-06 2020-09-22 Oppo广东移动通信有限公司 一种接入网络的方法、终端及存储介质
JP2021509548A (ja) 2017-11-16 2021-03-25 オッポ広東移動通信有限公司Ｇｕａｎｇｄｏｎｇ Ｏｐｐｏ Ｍｏｂｉｌｅ Ｔｅｌｅｃｏｍｍｕｎｉｃａｔｉｏｎｓ Ｃｏｒｐ．， Ｌｔｄ． ハンドオーバ方法、装置、並びにコンピュータ記憶媒体
US11075906B2 (en) * 2017-12-28 2021-07-27 Shoppertrak Rct Corporation Method and system for securing communications between a lead device and a secondary device
FR3077175A1 (fr) * 2018-01-19 2019-07-26 Orange Technique de determination d'une cle destinee a securiser une communication entre un equipement utilisateur et un serveur applicatif
CN112154634A (zh) * 2018-05-18 2020-12-29 瑞典爱立信有限公司 应用程序访问控制
WO2020011332A1 (en) * 2018-07-09 2020-01-16 Huawei Technologies Co., Ltd. System and method for creating a secure connection
US11481509B1 (en) 2018-07-10 2022-10-25 United Services Automobile Association (Usaa) Device management and security through a distributed ledger system
WO2020036947A1 (en) * 2018-08-13 2020-02-20 Intel Corporation Techniques in evolved packet core for restricted local operator services access
CN110972135A (zh) * 2018-09-28 2020-04-07 华为技术有限公司 一种安全通信方法、加密信息确定方法及装置
CN111385369B (zh) * 2018-12-28 2021-06-22 华为技术有限公司 一种域名服务器的分配方法和装置
US11728973B2 (en) * 2019-08-14 2023-08-15 Royal Bank Of Canada System and method for secure access management
US10785652B1 (en) * 2019-09-11 2020-09-22 Cisco Technology, Inc. Secure remote access to a 5G private network through a private network slice
US11589226B2 (en) * 2019-12-17 2023-02-21 Cisco Technology, Inc. Multi-factor authentication for mobile security protocol
US11509476B2 (en) * 2020-02-12 2022-11-22 Verizon Patent And Licensing Inc. System and method for enabling secure service-based communications via 5G proxies
US20230171603A1 (en) * 2020-05-15 2023-06-01 Telefonaktiebolaget Lm Ericsson (Publ) Onboarding Devices in Standalone Non-Public Networks
EP4002766B1 (en) * 2020-11-18 2024-04-24 Deutsche Telekom AG Method and system for reachability of services specific to one specific network access over a different network access and system thereof
CN115021950A (zh) * 2021-03-03 2022-09-06 美光科技公司 用于端点的在线服务商店
CN113810367A (zh) * 2021-08-02 2021-12-17 浪潮软件股份有限公司 一种基于动态令牌方式的混合数据验证访问控制方法
WO2023249519A1 (en) * 2022-06-20 2023-12-28 Telefonaktiebolaget Lm Ericsson (Publ) Providing an authentication token for authentication of a user device for a third-party application using an authentication server.
US11546323B1 (en) * 2022-08-17 2023-01-03 strongDM, Inc. Credential management for distributed services
US11736531B1 (en) 2022-08-31 2023-08-22 strongDM, Inc. Managing and monitoring endpoint activity in secured networks
US11765159B1 (en) 2022-09-28 2023-09-19 strongDM, Inc. Connection revocation in overlay networks
US11916885B1 (en) 2023-01-09 2024-02-27 strongDM, Inc. Tunnelling with support for dynamic naming resolution
US11765207B1 (en) 2023-03-17 2023-09-19 strongDM, Inc. Declaring network policies using natural language

Family Cites Families (31)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US5560008A (en) * 1989-05-15 1996-09-24 International Business Machines Corporation Remote authentication and authorization in a distributed data processing system
WO1997015885A1 (en) * 1995-10-25 1997-05-01 Open Market, Inc. Managing transfers of information in a communications network
US8191124B2 (en) * 2006-09-06 2012-05-29 Devicescape Software, Inc. Systems and methods for acquiring network credentials
US20080108322A1 (en) * 2006-11-03 2008-05-08 Motorola, Inc. Device and / or user authentication for network access
US8117648B2 (en) * 2008-02-08 2012-02-14 Intersections, Inc. Secure information storage and delivery system and method
EP2420077A1 (en) * 2009-04-17 2012-02-22 Panasonic Corporation Apparatus for management of local ip access in a segmented mobile communication system
US8776214B1 (en) * 2009-08-12 2014-07-08 Amazon Technologies, Inc. Authentication manager
WO2011115407A2 (en) * 2010-03-15 2011-09-22 Samsung Electronics Co., Ltd. Method and system for secured remote provisioning of a universal integrated circuit card of a user equipment
EP2670174B1 (en) 2011-01-28 2020-03-25 Samsung Electronics Co., Ltd Device and method for controlling charging in a mobile communication system
US9130935B2 (en) * 2011-05-05 2015-09-08 Good Technology Corporation System and method for providing access credentials
US8699709B2 (en) 2011-07-08 2014-04-15 Motorola Solutions, Inc. Methods for obtaining authentication credentials for attaching a wireless device to a foreign 3GPP wireless domain
US8752154B2 (en) * 2011-08-11 2014-06-10 Bank Of America Corporation System and method for authenticating a user
US8594628B1 (en) 2011-09-28 2013-11-26 Juniper Networks, Inc. Credential generation for automatic authentication on wireless access network
KR101929299B1 (ko) 2011-12-06 2019-03-13 삼성전자주식회사 이동통신 네트워크에서 요금 지불을 대행하는 인터넷 서비스 제공 방법 및 장치
US20130298209A1 (en) 2012-05-02 2013-11-07 Interdigital Patent Holdings, Inc. One round trip authentication using sngle sign-on systems
CN103428696B (zh) * 2012-05-22 2017-04-19 中兴通讯股份有限公司 实现虚拟sim卡的方法、系统及相关设备
US8769651B2 (en) * 2012-09-19 2014-07-01 Secureauth Corporation Mobile multifactor single-sign-on authentication
US9338130B2 (en) * 2013-02-11 2016-05-10 Broadcom Corporation Apparatus and method to register Wi-Fi clients on a Wi-Fi network
US10313532B2 (en) 2013-06-13 2019-06-04 Kajeet, Inc. Platform for enabling users to sign up for sponsored functions on computing devices
CN104243362B (zh) * 2013-06-24 2018-07-20 新华三技术有限公司 一种报文转发方法和装置
US8646060B1 (en) * 2013-07-30 2014-02-04 Mourad Ben Ayed Method for adaptive authentication using a mobile device
US20150312248A1 (en) * 2014-04-25 2015-10-29 Bank Of America Corporation Identity authentication
US9667424B2 (en) * 2014-06-26 2017-05-30 Xiaomi Inc. Methods and apparatuses for binding token key to account
CN104469765B (zh) * 2014-07-28 2020-10-23 北京佰才邦技术有限公司 用于移动通信系统中的终端认证方法和装置
US9356921B2 (en) * 2014-08-28 2016-05-31 Sap Se Different authentication profiles
US9402093B2 (en) * 2014-09-03 2016-07-26 Spotify Ab Systems and methods for temporary access to media content
US9813400B2 (en) * 2014-11-07 2017-11-07 Probaris Technologies, Inc. Computer-implemented systems and methods of device based, internet-centric, authentication
US9705864B2 (en) * 2014-12-10 2017-07-11 Futurewei Technologies, Inc. Media session resumption in web session restoration
US9717003B2 (en) 2015-03-06 2017-07-25 Qualcomm Incorporated Sponsored connectivity to cellular networks using existing credentials
US9801055B2 (en) * 2015-03-30 2017-10-24 Qualcomm Incorporated Authentication and key agreement with perfect forward secrecy
US9853965B2 (en) * 2015-08-24 2017-12-26 Verizon Patent And Licensing Inc. Authentication service for third party applications

Also Published As

Publication number Publication date
AU2016229439A1 (en) 2017-08-10
KR20180004310A (ko) 2018-01-10
JP2018513462A (ja) 2018-05-24
AU2016229439B2 (en) 2018-11-08
US20170230829A1 (en) 2017-08-10
US9717003B2 (en) 2017-07-25
JP6470846B2 (ja) 2019-02-13
TW201644250A (zh) 2016-12-16
KR101819878B1 (ko) 2018-02-28
ES2724099T3 (es) 2019-09-06
HUE041995T2 (hu) 2019-06-28
CN107431701A (zh) 2017-12-01
BR112017019089A2 (pt) 2018-04-17
US20160262021A1 (en) 2016-09-08
WO2016144516A1 (en) 2016-09-15
AU2019200920A1 (en) 2019-02-28
CN110086833A (zh) 2019-08-02
US9769665B2 (en) 2017-09-19
BR112017019089B1 (pt) 2024-02-06
CN107431701B (zh) 2019-06-28
CN110086833B (zh) 2021-07-30
EP3266180B1 (en) 2019-01-30
EP3266180A1 (en) 2018-01-10
AU2019200920B2 (en) 2020-05-14
KR101858929B1 (ko) 2018-05-17
TWI616084B (zh) 2018-02-21

Similar Documents

Publication Publication Date Title
AU2019200920B2 (en) Sponsored connectivity to cellular networks using existing credentials
US10063377B2 (en) Network-based authentication for third party content
US11785447B2 (en) Identifier-based access control in mobile networks
KR102434877B1 (ko) 다른 디바이스의 네트워크 서브스크립션과 디바이스의 연관
CN108781216B (zh) 用于网络接入的方法和设备
US9716999B2 (en) Method of and system for utilizing a first network authentication result for a second network
KR102042327B1 (ko) 무선 네트워크들에서의 아이덴티티 프라이버시
EP3335453A1 (en) Network access identifier including an identifier for a cellular access network node
Santos et al. Identity federation for cellular internet of things
US20220038904A1 (en) Wireless-network attack detection
WO2023144649A1 (en) Application programming interface (api) access management in wireless systems

Legal Events

Date Code Title Description
A201 Request for examination
A302 Request for accelerated examination
E701 Decision to grant or registration of patent right
GRNT Written decision to grant