KR102487923B1

KR102487923B1 - 서비스들 - 사용자-평면 접근법에 대한 네트워크 토큰들을 이용한 효율적인 정책 집행

Info

Publication number: KR102487923B1
Application number: KR1020177022720A
Authority: KR
Inventors: 수범 이; 개빈 버나드 호른; 존 나시엘스키; 스테파노 파킨
Original assignee: 퀄컴 인코포레이티드
Priority date: 2015-02-24
Filing date: 2016-01-14
Publication date: 2023-01-11
Also published as: CN107409125A; TW201644238A; US20220150699A1; KR20170118732A; WO2016137598A3; BR112017018021A2; US20160248682A1; TWI668976B; WO2016137598A2; US11910191B2; US11570622B2; US11265712B2; JP2018508146A; US10505850B2; US20230091356A1; EP3262821A2; JP6687636B2; CN107409125B; US20190349306A1

Abstract

하나의 양태는 디바이스에 의해, 하나 이상의 애플리케이션 서비스들과 연관된 애플리케이션 서버와의 접속을 개시하는 것에 관한 것이다. 게이트웨이는 업링크 네트워크 토큰 및/또는 다운링크 네트워크 토큰을 유도한다. 토큰들은 사용자-평면 상에서 디바이스 및/또는 애플리케이션 서버에 제공된다. 토큰들은 각각 업링크 및/또는 다운링크 패킷들과 함께 포함된다. 또 다른 양태는 게이트웨이에서 데이터 패킷을 수신하는 것에 관한 것이다. 게이트웨이는 패킷으로부터 네트워크 토큰에 대한 요건을 결정한다. 게이트웨이는 네트워크에 의해 유지된 디바이스 가입 프로파일에 기초하여 네트워크 토큰을 유도한다. 네트워크 토큰은 패킷과 함께, 패킷과 연관된 목적지 어드레스로 전송될 수도 있다. 네트워크 토큰을 포함하는 패킷은 게이트웨이에서 수신될 수도 있다. 게이트웨이는 네트워크 토큰을 검증할 수도 있고, 검증이 성공적일 경우에, 데이터 패킷을 애플리케이션 서버 또는 디바이스로 전송할 수도 있다.

Description

서비스들 - 사용자-평면 접근법에 대한 네트워크 토큰들을 이용한 효율적인 정책 집행{EFFICIENT POLICY ENFORCEMENT USING NETWORK TOKENS FOR SERVICES - USER-PLANE APPROACH}

이 출원은 그 전체 내용들이 참조로 본원에 편입되는, 2015 년 2 월 24 일자로 미국 특허상표청에 출원된 가출원 제 62/120,159 호, 2015 년 5 월 14 일자로 미국 특허상표청에 출원된 가출원 제 62/161,768 호, 및 2015 년 9 월 25 일자로 미국 특허상표청에 출원된 정규 출원 제 14/866,425 호의 우선권 및 이익을 주장한다.

하나의 양태는 일반적으로 네트워크 토큰들에 관한 것으로, 더욱 구체적으로, 네트워크 정책들의 집행 (예컨대, 디바이스가 오직 인가된 애플리케이션 서비스들을 액세스하고 있다는 것을 검증함) 및/또는 패킷 스티어링 (packet steering) 을 가능하게 하기 위하여 업링크 및 다운링크 사용자-평면 데이터 흐름들과 연관되는 업링크 및 다운링크 네트워크 토큰들의 유도, 프로비저닝, 및 이용에 관한 것이다.

일부 클라이언트 디바이스들은 네트워크 액세스를 가질 수도 있지만, 그 네트워크 액세스는 애플리케이션 서비스들의 세트로 한정될 수도 있다. 네트워크 운영자들은 이러한 제한들을 부과하기 위하여 정책들을 이용할 수도 있다. 하나의 예에서, 특정한 애플리케이션 서비스 제공자는 클라이언트 디바이스의 네트워크 액세스를 후원할 수도 있다. 클라이언트 디바이스는 그 서버 상에서 애플리케이션 서비스 제공자에 의해 실행된 애플리케이션 서비스들로 제한될 수도 있다. 또 다른 예에서, 네트워크 액세스를 갖는 클라이언트 디바이스는 주어진 애플리케이션 서비스와 연관된 데이터 (예컨대, 비트 레이트 또는 서비스 품질) 의 특수한 과금 또는 핸들링을 허용하는 계약의 일부일 수도 있다. 예를 들어, 클라이언트 디바이스는 셀룰러 제공자를 통한 셀룰러 가입을 가질 수도 있고, 그 셀룰러 제공자는 클라이언트 디바이스에 관한 하나 이상의 제한들을 부과하는 것을 희망할 수도 있다. 하나의 예에서는, 오늘 날에 소셜 미디어의 제공자로서 알려져 있지만, 셀룰러 제공자로서 알려져 있지는 않은 기업이 미래에 셀룰러 제공자로서 역할을 할 수도 있다. 이 예에서, 클라이언트 디바이스는 기업에 대한 가입을 가질 수도 있다. 그 가입 협정의 일부로서, 클라이언트 디바이스는 인터넷에 대한 액세스를 얻을 수도 있지만, 다른 소셜 미디어 사이트들을 제외하고, 기업의 소셜 미디어 사이트를 이용하도록 제한될 수도 있다. 또 다른 예로서, 클라이언트 디바이스는 스트리밍 미디어 서비스들의 제공자에 대한 가입을 가질 수도 있다. 이 예에서, 협정의 일부로서, 클라이언트 디바이스는 다양한 셀룰러 제공자들 (예컨대, 이동 네트워크 운영자들) 을 통해 인터넷에 대한 액세스를 얻을 수도 있다. 그러나, 액세스는 모든 스트리밍 미디어 서비스들에 대한 미디어 서비스들의 제공자의 사이트를 이용하도록 (스트리밍 미디어 서비스들의 제공자와 다양한 셀룰러 제공자들 및/또는 클라이언트 디바이스의 이용자 사이의) 협정에 의해 제한될 수도 있다. 또 다른 예로서, 어떤 액세스 포인트 명칭 (access point name; APN) 들에 대하여, 오직 어떤 트래픽 (예컨대, 제어-평면 시그널링 및/또는 사용자-평면 메시지들) 이 정책 또는 가입 제한에 기초하여 클라이언트 디바이스로부터 전송되도록 허용될 수도 있다.

네트워크 정책들은 클라이언트 디바이스가 임의의 협정들을 위반하고 있지 않고, 합의된 애플리케이션 서비스들에 대한 액세스를 제공받고 있고, 및/또는 합의된 레벨의 서비스를 제공받고 있다는 것을 보장하기 위하여 애플리케이션 서비스들과 관련하여 마련될 수도 있다. 네트워크는 클라이언트 디바이스로부터 예를 들어, 패킷 데이터 네트워크 (예컨대, 인터넷) 상의 애플리케이션 서버를 향해 전송된 업링크 (uplink; UL) 패킷들에 대하여 이러한 정책들을 집행할 수도 있다. 네트워크는 애플리케이션 서버로부터 클라이언트 디바이스를 향해 전송된 다운링크 (downlink; DL) 패킷들에 대하여 이러한 정책들을 추가적으로 집행할 수도 있다.

오늘 날에, 애플리케이션 서비스들에 대한 정책 집행은 네트워크로의 게이트웨이에서 발생한다. 이러한 게이트웨이의 예는 코어 네트워크 (예컨대, 진화형 패킷 코어 (evolved packet core; EPC)) 와 인터넷과 같은 패킷 데이터 네트워크 (packet data network; PDN) 사이의 게이트웨이의 역할을 하는 패킷 데이터 네트워크 게이트웨이 (packet data network gateway; P-GW) 이다. 하나의 문제는 정책 집행 (예컨대, 서비스 액세스 정책들의 집행) 이 클라이언트 디바이스와 애플리케이션 서버들 사이에서 전송된 모든 UL 및 DL 패킷들의 유효성을 확인할 것을 P-GW 에 요구할 수도 있다는 점에 존재한다. 또한, 각각의 UL 패킷 및 DL 패킷은 특정한 베어러 또는 데이터 흐름을 통해 그 목적지 어드레스 (destination address) 로 스티어링 (steering) 될 필요가 있을 수도 있다. 목적지 어드레스는 2 개의 부분들: 프리픽스 (prefix) 부분 및 서픽스 (suffix) 부분으로 이루어질 수도 있다.

네트워크 정책들은 P-GW 에서의 UL 및 DL 패킷들의 유효성확인 (validation) 에 의해 집행될 수도 있다. 집행은 클라이언트 디바이스가 패킷들을 허가된 애플리케이션 서비스로/로부터 오직 전송하고/수신하는 것을 보장할 수도 있다. 유효성확인은 P-GW 를 통과하는 패킷들의 목적지 어드레스 또는 목적지 어드레스 및 포트 번호를 검증하는 것을 포함할 수도 있다. 유효성확인은 각각의 패킷의 소스 어드레스 (source address) 를 검증하는 것을 추가적으로 포함할 수도 있다. 각각의 패킷의 소스 어드레스를 검증하는 것은 (예컨대, 비인가된 클라이언트 디바이스들로부터의 패킷들이 인가된 클라이언트 디바이스로부터 나오는 것처럼 보임으로써 네트워크를 속이는 것 (fooling) 을 방지함으로써) 안티-스푸핑 (anti-spoofing) 을 위하여 유용할 수도 있다. 패킷 스티어링은 합의된 서비스 품질 (quality of service; QoS) 이 달성된다는 것을 보장하기 위하여 필요하게 될 수도 있다.

현재의 실시들은 상당한 오버헤드 (overhead) 를 초래하고 프로세싱 지연으로 인해 포워딩 레이턴시 (forwarding latency) 를 추가한다. 현재의 실시는 패킷 검사 (예컨대, 깊은 패킷 검사 (deep packet inspection), 얕은 패킷 검사 (shallow packet inspection)) 및 트래픽 흐름 템플릿 (traffic flow template; TFT) 및 서비스 데이터 흐름 (service data flow; SDF) 템플릿들을 이용하여 전형적으로 실현된다. P-GW 는 각각의 패킷의 헤더들을 검사함으로써, 패킷들이 서비스 (들) 에 대하여 정의된 TFT/SDF 템플릿을 준수하는 것을 확인한다.

도 1 은 서비스 데이터 흐름 (104) 의 다운링크 부분을 검출하고 그 부분을, 도시된 인터넷 프로토콜-접속성 액세스 네트워크 (Internet Protocol-Connectivity Access Network; IP-CAN) 베어러들 (106) 과 같은 베어러들에 맵핑함에 있어서, SDF 템플릿 (102) 의 역할의 종래 기술의 예시도이다. 도 1 은 3GPP 기술적 사양 (technical specification; TS) 23.203, 도 6.4 에 기초하고 있다.

SDF 템플릿 (102) 은 다운링크 패킷들의 유효성을 확인하고 다운링크 패킷들을 맵핑하기 위하여 생성된다. 그러나, 패킷 필터들 (예컨대, SDF 템플릿 (102) 에서의 패킷 필터들 a 내지 f 참조) 의 세트의 이용은 테이블들 및 테이블 룩업 절차들의 이용을 요구한다. 이러한 테이블들 및 절차들의 이용은 이용이 절차들을 실행하기 위하여 메모리 저장 공간 및 프로세서 자원들을 요구한다는 점에서 효율에 영향을 준다. 추가적으로, 임의의 주어진 패킷이 필터의 요건들의 전부를 충족시키는 필터에 적용되기 전에 각각의 패킷이 복수의 필터들을 통해 필터링되어야 한다는 점에서, 시간 자원들이 낭비된다.

그러므로, (업링크 및 다운링크 패킷들의 어느 하나 또는 양자에 대하여) P-GW 에서 패킷 검사 및 TFT/SDF 템플릿들을 이용하는 것은 예를 들어, 그 이용이 상당한 오버헤드 (예컨대, 메모리 룩업 및 패턴 정합을 위한 프로세싱 및 메모리 자원들) 를 초래하고 프로세싱 지연으로 인해 포워딩 레이턴시를 추가하므로 문제가 있다. 추가적으로, 패킷은 TFT/SDF 템플릿들에 의해 실현된 추가적인 필터링 규칙들에 대하여 테스트될 필요가 있을 것이기 때문에 추가적인 정책 제어는 추가적인 오버헤드 및 프로세싱 지연을 초래할 것이므로, (예컨대, 서비스 당) 세립 정책 제어 (fine-grain policy control) 가 어렵다. 또한, TFT/SDF 템플릿들의 이용은 후원된 접속성에 대하여 스케일링가능하지 않다. 상이한 서비스들 (아마도, 앞으로 수 년 내에 나올 수 천 개의 서비스들) 의 후원자들의 수에 있어서의 증가는 대응하여 증가된 수의 TFT/SDF 템플릿들을 통해 패킷들을 필터링하기 위하여 필요한 시간에 있어서의 증가를 의미할 것이다. 이것은 추가적인 오버헤드 및 프로세싱 지연을 다시 초래할 것이다.

요구되는 것은 패킷 검사를 보충하거나 및/또는 개량하고 업링크 및 다운링크 네트워크 정책들의 집행에서의 효율을 개선시키기 위한 대안이다.

제 1 양태에 따르면, 방법은 디바이스에서 동작할 수도 있다. 방법은 디바이스에 의해, 하나 이상의 애플리케이션 서비스들과 연관된 애플리케이션 서버와의 접속을 개시하는 단계를 포함할 수도 있다. 접속을 개시하는 것에 응답하여, 디바이스는 네트워크 토큰을 획득할 수도 있다. 네트워크 토큰은 하나 이상의 흐름들의 세트의 제 1 흐름과 연관될 수도 있고, 하나 이상의 애플리케이션 서비스들의 제 1 애플리케이션 서비스와 연관될 수도 있고, 하나 이상의 사용자-평면 메시지들을 통해 디바이스에 프로비저닝 (provisioning) 될 수도 있다. 방법은 또한, 하나 이상의 업링크 (UL) 패킷들과 함께 네트워크 토큰을 사용자-평면에서 디바이스로부터 애플리케이션 서버로 전송하는 단계를 포함할 수도 있다.

추가적인 양태들에 따르면, 네트워크 토큰은 애플리케이션 서버 및/또는 게이트웨이 디바이스 중의 하나로부터 획득될 수도 있다. 네트워크 토큰은 코어 네트워크의 게이트웨이 디바이스에 의해 유도될 수도 있다. 그것은 디바이스의 디바이스 가입 프로파일 및/또는 제 1 애플리케이션 서비스의 정책에 기초할 수도 있다. 그것은 디바이스에 대하여 코어 네트워크에 의해 집행된 정책을 반영할 수도 있다. 접속을 개시하는 양태는 접속 요청을 전송하는 단계를 포함할 수도 있고, 접속 요청은 네트워크 토큰에 대한 명시적 요청을 포함한다. 그것은 네트워크 토큰에 대한 묵시적 요청을 표현하는 패킷을 전송하는 단계를 포함할 수도 있다.

일부 양태들에 따르면, 묵시적 요청은 제 1 패킷을 애플리케이션 서버로 전송함으로써 표현될 수도 있다. 접속을 개시하는 단계는 애플리케이션 서버로부터의 확인응답을 요구하는 패킷을 전송하는 단계를 포함할 수도 있고, 여기서, 확인응답은 네트워크 토큰을 디바이스로 전송한다. 네트워크 토큰은 사용자-평면 심 헤더 (shim header) 에서 디바이스로부터 패킷 데이터 네트워크 (PDN) 게이트웨이 (PDN gateway; P-GW) 로 전송될 수도 있다. 사용자-평면 심 헤더는 인터넷 프로토콜 (Internet Protocol; IP) 계층 위에 위치될 수도 있다. 네트워크 토큰은 IP 버전 6 (IP version 6; IPv6) 에서 정의된 바와 같이, 인터넷 프로토콜 (IP) 확장 헤더에서 디바이스로부터 패킷 데이터 네트워크 (PDN) 게이트웨이 (P-GW) 로 전송될 수도 있다. 그것은 패킷 데이터 컨버전스 프로토콜 (packet data convergence protocol; PDCP) 계층에서 디바이스로부터 액세스 노드로 전송될 수도 있고, 액세스 노드에서 사용자-평면에 대한 범용 패킷 라디오 서비스 (general packet radio service; GPRS) 터널링 프로토콜 (GPRS tunneling protocol; GTP) 계층 (GTP layer for user-plane; GTP-U) 계층으로 복사될 수도 있고, GTP-U 계층에서 액세스 노드로부터 패킷 데이터 네트워크 (PDN) 게이트웨이 (P-GW) 로 전송될 수도 있다.

하나의 양태에 따르면, 무선 네트워크 상에서 통신하도록 구성된 네트워크 통신 인터페이스 및 네트워크 통신 인터페이스에 결합된 프로세싱 회로를 포함하는 디바이스는 위에서 설명된 방법을 수행할 수도 있다.

또 다른 양태에 따르면, 방법은 네트워크에서의 게이트웨이 디바이스에서 동작할 수도 있다. 방법은 게이트웨이 디바이스에서, 사용자-평면을 통해 제 1 데이터 패킷을 수신하는 단계를 포함할 수도 있다. 방법은 제 1 데이터 패킷을 평가함으로써 네트워크 토큰이 요청되는지를 결정하는 단계, 및 네트워크 토큰이 요청될 경우에 네트워크 토큰을 획득하는 단계를 더 포함할 수도 있다. 네트워크 토큰은 네트워크에 의해 유지된 디바이스 가입 프로파일에 기초할 수도 있다. 방법은 네트워크 토큰이 요청될 경우에 제 1 데이터 패킷과 함께 네트워크 토큰을 포함하는 단계; 및 제 1 데이터 패킷 및 네트워크 토큰을 목적지로 전송하는 단계를 추가로 수반할 수도 있다.

추가적인 양태들에 따르면, 제 1 데이터 패킷은 애플리케이션 서버로 전송될 수도 있고, 네트워크 토큰은 업링크 네트워크 토큰이다. 제 1 데이터 패킷은 애플리케이션 서버로 전송될 수도 있고, 네트워크 토큰은 다운링크 네트워크 토큰이다. 제 1 데이터 패킷은 디바이스로 전송될 수도 있고, 네트워크 토큰은 다운링크 네트워크 토큰이다. 제 1 데이터 패킷이 디바이스로 전송되고 네트워크 토큰은 다운링크 네트워크 토큰일 경우, 방법은 게이트웨이 디바이스에서, 디바이스로부터 다운링크 네트워크 토큰을 포함하는 제 2 데이터 패킷을 수신하는 단계, 및 제 2 데이터 패킷 및 다운링크 네트워크 토큰을 애플리케이션 서버로 전송하는 단계를 더 포함할 수도 있다. 일부 양태들에 따르면, 네트워크 토큰은 업링크 네트워크 토큰 및 다운링크 네트워크 토큰이고, 업링크 네트워크 토큰은 다운링크 네트워크 토큰과는 상이하다. 게이트웨이 디바이스는 패킷 데이터 네트워크 (PDN) 게이트웨이 (P-GW) 일 수도 있다. 제 1 패킷은 네트워크 토큰에 대한 명시적 요청을 포함할 수도 있거나, 또는 그것은 네트워크 토큰에 대한 묵시적 요청을 표현할 수도 있다. 일부 양태들에 따르면, 네트워크 토큰이 요청되는지를 결정하는 단계는, 제 1 패킷이 전송될 애플리케이션 서버, 또는 제 1 패킷이 수신될 애플리케이션 서버가 네트워크 토큰을 요구하는지를 결정하는 단계에 기초할 수도 있다.

네트워크 토큰을 획득하는 단계는 게이트웨이 디바이스에서 네트워크 토큰을 유도함으로써 달성될 수도 있다. 네트워크 토큰은 게이트웨이 디바이스에 알려진 비밀 키 (secret key), 클래스 인덱스, 소스 인터넷 프로토콜 (IP) 어드레스, 소스 포트 번호, 목적지 IP 어드레스, 목적지 포트 번호, 프로토콜 식별자 (protocol identifier; ID), 애플리케이션 ID, 우선순위, 및/또는 서비스 품질 클래스 식별자 (quality of service class identifier; QCI) 를 포함하는 입력 파라미터들의 세트를 가지는 함수를 이용하여 유도될 수도 있다. 클래스 인덱스는 네트워크 토큰 유도를 위하여 이용된 필드들을 정의한다. 네트워크 토큰은 클래스 인덱스 및 함수의 출력의 연결 (concatenation) 일 수도 있다.

하나의 양태에 따르면, 무선 네트워크 상에서 통신하도록 구성된 네트워크 통신 인터페이스 및 네트워크 통신 인터페이스에 결합된 프로세싱 회로를 포함하는 게이트웨이 디바이스는 위에서 설명된 방법을 수행할 수도 있다.

또 다른 양태에 따르면, 게이트웨이 디바이스에서 동작하는 방법은 디바이스로부터 하나 이상의 애플리케이션 서비스들과 연관된 애플리케이션 서버로 전송된 제 1 네트워크 토큰에 대한 요청에 응답하여, 게이트웨이 디바이스에서, 제 1 네트워크 토큰을 유도하는 단계를 포함할 수도 있다. 방법은 게이트웨이 디바이스에서, 디바이스로부터 데이터 패킷을 수신하는 단계를 포함할 수도 있고, 데이터 패킷은 애플리케이션 서버에 대응하는 적어도 목적지 어드레스 프리픽스를 포함하고, 데이터 패킷은 제 2 네트워크 토큰을 포함한다. 방법은 제 2 네트워크 토큰을 검증하는 단계, 검증이 성공적이지 않을 경우에 데이터 패킷을 폐기하는 단계, 및 검증이 성공적일 경우에 데이터 패킷을 애플리케이션 서버로 전송하는 단계를 더 포함할 수도 있다. 데이터 패킷은 사용자-평면 메시지에서 수신될 수도 있다. 게이트웨이 디바이스는 패킷 데이터 네트워크 (PDN) 게이트웨이 (P-GW) 일 수도 있다. 제 2 네트워크 토큰을 검증하는 단계는 데이터 패킷으로부터 획득된 입력 파라미터들 및 게이트웨이 디바이스에 알려진 키를 이용하여 제 1 함수로부터 제 1 네트워크 토큰의 복제본 (duplicate) 을 유도하는 단계를 포함할 수도 있다. 제 2 네트워크 토큰을 검증하는 단계는 제 1 네트워크 토큰의 복제본을 제 2 네트워크 토큰과 비교하는 단계를 더 포함할 수도 있고, 여기서, 검증은 제 1 네트워크 토큰의 복제본이 제 2 네트워크 토큰과 동일할 경우에 성공적이다.

일부 양태들에 따르면, 제 2 네트워크 토큰은 IP 헤더로부터 분리된 심 헤더에서 디바이스로부터 게이트웨이 디바이스로 전송될 수도 있다. 제 2 네트워크 토큰은 인터넷 프로토콜 (IP) 버전 6 (IPv6) 에서 정의된 IP 확장 헤더에서 디바이스로부터 게이트웨이 디바이스로 전송될 수도 있다. 일부 양태들에 따르면, 제 2 네트워크 토큰은 패킷 데이터 컨버전스 프로토콜 (PDCP) 계층에서 디바이스로부터 액세스 노드로 전송될 수도 있고, 액세스 노드에서 사용자-평면에 대한 범용 패킷 라디오 서비스 (GPRS) 터널링 프로토콜 (GTP) 계층 (GTP-U) 계층으로 복사될 수도 있고, GTP-U 계층에서 액세스 노드로부터 게이트웨이 디바이스로 전송될 수도 있다.

또 다른 양태에 따르면, 애플리케이션 서버에서 동작하는 방법은 하나 이상의 애플리케이션 서비스들과 연관된 애플리케이션 서버에 의해, 디바이스로 제 1 애플리케이션 서비스를 개시하기 위한 요청을 전송하는 단계를 포함할 수도 있다. 방법은 제 1 애플리케이션 서비스를 개시하기 위한 요청을 전송하는 것에 응답하여, 네트워크 토큰을 획득하는 단계를 더 포함할 수도 있다. 네트워크 토큰은 하나 이상의 흐름들의 세트의 제 1 흐름과 연관될 수도 있고, 제 1 애플리케이션 서비스와 연관될 수도 있고, 하나 이상의 사용자-평면 메시지들을 통해 디바이스로 전송될 수도 있다. 방법은 사용자-평면에서 애플리케이션 서버로부터 디바이스로 전송된 하나 이상의 다운링크 (DL) 패킷들과 함께 네트워크 토큰을 전송하는 단계를 더 포함할 수도 있다. 네트워크 토큰은 코어 네트워크의 게이트웨이 디바이스에 의해 유도될 수도 있다. 그것은 디바이스의 디바이스 가입 프로파일 및/또는 제 1 애플리케이션 서비스의 정책에 기초할 수도 있다. 그것은 디바이스에 대하여 코어 네트워크에 의해 집행된 정책을 반영할 수도 있다. 제 1 애플리케이션 서비스를 개시하기 위한 요청은 네트워크 토큰에 대한 명시적 요청을 포함할 수도 있거나, 또는 그것은 네트워크 토큰에 대한 묵시적 요청을 표현하는 패킷을 전송하는 단계를 포함할 수도 있다.

하나의 양태에 따르면, 무선 네트워크 상에서 통신하도록 구성된 네트워크 통신 인터페이스 및 네트워크 통신 인터페이스에 결합된 프로세싱 회로를 포함하는 애플리케이션 서버는 위에서 설명된 방법을 수행할 수도 있다.

도 1 은 서비스 데이터 흐름의 다운링크 부분을 검출하고 그 부분을, 도시된 인터넷 프로토콜-접속성 액세스 네트워크 (IP-CAN) 베어러들과 같은 베어러들에 맵핑함에 있어서, SDF 템플릿의 역할의 종래 기술의 예시도이다.
도 2 는 예시적인 동작 환경을 예시한다.
도 3 은 본원에서 설명된 양태들에 따라 예시적인 업링크 동작을 예시한다.
도 4 는 본원에서 설명된 양태들에 따라 예시적인 다운링크 동작을 예시한다.
도 5 는 본원에서 설명된 양태들에 따라 하나 이상의 사용자-평면 메시지들과 관련하여 네트워크 토큰 유도, 프로비저닝, 및 이용을 예시하는 예시적인 호출 흐름이다.
도 6 은 본원에서 설명된 양태들에 따라 하나 이상의 사용자-평면 메시지들과 관련하여 네트워크 토큰 유도, 프로비저닝, 및 이용을 예시하는 예시적인 호출 흐름이다.
도 7 은 본원에서 설명된 양태들에 따라 하나 이상의 사용자-평면 메시지들과 관련하여 네트워크 토큰 유도, 프로비저닝, 및 이용을 예시하는 예시적인 호출 흐름이다.
도 8 은 본원에서 설명된 양태들에 따라 하나 이상의 사용자-평면 메시지들과 관련하여 2 개의 네트워크 토큰들 (예컨대, 업링크 네트워크 토큰 및 다운링크 네트워크 토큰) 의 유도, 프로비저닝, 및 이용을 예시하는 예시적인 호출 흐름이다.
도 9 는 본원에서 설명된 하나의 양태에 따른, 시스템의 사용자-평면 프로토콜 스택들의 예시적인 예시도이다.
도 10 은 본원에서 설명된 또 다른 양태에 따른, 시스템의 사용자-평면 프로토콜 스택들의 예시적인 예시도이다.
도 11 은 본원에서 설명된 또 다른 양태에 따른, 시스템의 사용자-평면 프로토콜 스택들의 예시적인 예시도이다.
도 12 는 본원에서 설명된 또 다른 양태에 따른, 시스템의 사용자-평면 프로토콜 스택들의 예시적인 예시도이다.
도 13 은 본원에서 설명된 양태들에 따라, 네트워크 토큰들을 이용하여 네트워크 정책 집행 및/또는 패킷 스티어링을 지원하도록 구성된 예시적인 디바이스를 예시하는 블록도이다.
도 14 는, 디바이스 (예컨대, 칩 컴포넌트, 클라이언트 디바이스) 가 애플리케이션 서버와 통신하기 위한 요청을 개시하고 통신과 관련하여 네트워크 토큰들을 사용할 수도 있는 예시적인 방법이다.
도 15 는, 디바이스 (예컨대, 칩 컴포넌트, 클라이언트 디바이스) 가 통신을 개시하기 위한 요청에 대해 응답할 수도 있고 통신과 관련하여 네트워크 토큰들을 사용할 수도 있는 예시적인 방법이다.
도 16 은 본원에서 설명된 양태들에 따라, 네트워크 토큰들을 이용하여 네트워크 정책 집행 및/또는 패킷 스티어링을 지원하도록 구성된 예시적인 게이트웨이 디바이스를 예시하는 블록도이다.
도 17 은 본원에서 설명된 양태에 따라, 네트워크 토큰의 이용을 위하여, 사용자-평면 메시징을 통해, 디바이스로부터의 요청을 검출하고, 네트워크 토큰을 유도하고, 네트워크 토큰을 애플리케이션 서버를 통해 요청하는 디바이스에 프로비저닝하기 위한, 게이트웨이 디바이스 (예컨대, P-GW) 에서 동작하는 예시적인 방법을 예시한다.
도 18 은 본원에서 설명된 양태에 따라, 사용자-평면 메시징을 통해 게이트웨이 디바이스 (예컨대, P-GW) 에서 네트워크 토큰을 설정하고 이용하는, 게이트웨이 디바이스 (예컨대, P-GW) 에서 동작하는 예시적인 방법을 예시한다.
도 19 는 본원에서 설명된 양태에 따라, 네트워크 정책들의 집행 및/또는 패킷들의 스티어링을 위한 네트워크 토큰의 이용과 관련하여, 네트워크 토큰을 검증하기 (예컨대, 네트워크 토큰의 검증) 위한, 게이트웨이 디바이스 (예컨대, P-GW) 에서 동작하는 예시적인 방법을 예시한다.
도 20 은 다운링크 토큰 유효성확인 및 패킷 맵핑을 지원하도록 구성된 예시적인 애플리케이션 서버를 예시하는 블록도이다.
도 21 은 본원에서 설명된 양태에 따라, 애플리케이션 서버에서 네트워크 토큰을 설정하는 예시적인 방법의 플로우차트이다.

다음의 설명에서는, 예시로서, 개시물이 실시될 수도 있는 특정 실시형태들이 도시되어 있는 동반된 도면들에 대해 참조가 행해진다. 실시형태들은 당해 분야의 당업자들이 발명을 실시하는 것을 가능하게 할 정도로 충분히 상세하게 개시물의 양태들을 설명하도록 의도된다. 다른 실시형태들이 사용될 수도 있고, 개시물의 범위로부터 이탈하지 않으면서, 개시된 실시형태들에 대해 변경들이 행해질 수도 있다. 다음의 상세한 설명은 한정적인 의미로 취해지지 않아야 되고, 본 발명의 범위는 오직 첨부된 청구항들에 의해 정의된다.

용어 "디바이스" 는 다른 디바이스들 중에서, 이동 디바이스, 이동 전화, 이동 통신 디바이스, 이동 컴퓨팅 디바이스, 디지털 태블릿, 스마트폰, 사용자 장비, 사용자 디바이스, 단말과 같은 칩 컴포넌트 및/또는 클라이언트 디바이스를 지칭하기 위하여 본원에서 이용될 수도 있다. 본원에서 이용된 바와 같이, 용어 "유도" 는 디바이스로부터 국소적으로 유도하는 것, 또는 또 다른 디바이스로부터 획득하는 것을 의미할 수도 있다.

개관

본원에서 설명된 양태들은 일반적으로, 업링크 및 다운링크 네트워크 토큰들의 유도, 프로비저닝, 및 이용에 관한 것이다. 네트워크 토큰들은 사용자-평면에서 패킷들과 함께 전송될 수도 있다. 업링크 네트워크 토큰 또는 다운링크 네트워크 토큰은 하나 이상의 패킷들 내에 임베딩될 수도 있거나, 또는 그렇지 않을 경우에, 하나 이상의 패킷들과 함께 포함될 수도 있고, 네트워크 정책 집행 및/또는 트래픽 스티어링 (예컨대, 하나 이상의 사용자-평면 메시지들의 스티어링) 을 위하여 이용될 수도 있다.

네트워크 토큰에 대한 요청은 명시적 또는 묵시적일 수 있다. 명시적 요청은 예를 들어, 디바이스로부터 애플리케이션 서버로, 또는 애플리케이션 서버로부터 디바이스로 행해진 접속 요청 내에 포함될 수도 있다. 애플리케이션 서버는 하나 이상의 애플리케이션 서비스들과 연관될 수 있다. 요청은 명시적일 경우, 접속 요청을 포함하는 하나 이상의 패킷들과 함께 전송될 수 있다. 디바이스로부터 애플리케이션 서버로, 또는 애플리케이션 서버로부터 디바이스로의 패킷은 그 소스 (source) 로부터 그 목적지 (destination) 로의 그 도중에 패킷 데이터 네트워크 게이트웨이 (P-GW) 를 통과한다. P-GW 에서, 패킷은 그것이 네트워크 토큰에 대한 요청을 명시적으로 포함 (또는 묵시적으로 표현) 하는지를 결정하기 위하여 검사/검토/분석될 수 있다.

예를 들어, 네트워크 토큰에 대한 요청이 접속 요청과 함께 포함될 경우, P-GW 는 암호 함수, P-GW 에 알려진 비공유 비밀 키, 및 서비스들과 연관된 패킷 및 파라미터들로부터 획득될 수 있는 파라미터들을 이용하여 네트워크 토큰을 유도할 수도 있다. 그러나, P-GW 는 방금-유도된 (just-derived) 네트워크 토큰을, 네트워크 토큰을 요청하였던 엔티티 (entity) 로 직접적으로 전송하지 않을 수도 있다. 그 대신에, 그것은 접속 요청 (및 네트워크 토큰에 대한 요청) 을 반송 (carry) 하였던 패킷과 함께 네트워크 토큰을 임베딩할 수도 있거나, 또는 그렇지 않을 경우에 이를 포함할 수도 있고, (방금-유도된 네트워크 토큰과 함께) 패킷을 그 목적지, 예컨대, 패킷 헤더에서의 목적지 어드레스 (또는 적어도 목적지 어드레스 프리픽스) 로부터 식별된 목적지로 전송할 수도 있다. 프로세싱 회로는 목적지에서, 접속 요청에 대한 응답 (예컨대, 접속 응답) 을 준비하고, 접속 응답을 포함하는 패킷 내에, 또는 이 패킷과 함께 네트워크 토큰을 포함한다. 패킷은 사용자-평면을 통해, 네트워크 토큰에 대한 요청의 소스 및 접속 요청의 개시자로 전송될 수도 있다. 그 후에, 소스가 목적지로 전송하기 위한 추가적인 패킷들을 가질 때, 소스는 추가적인 패킷들 중의 하나 이상 내에 (또는 그것과 함께) 네트워크 토큰의 복사본 (copy) 을 포함할 수도 있다.

업링크 네트워크 토큰들 및/또는 다운링크 네트워크 토큰들은 네트워크 정책들을 집행하기 위하여 P-GW 에 의해 이용될 수도 있다. 본원에서 설명된 양태들에 따르면, 이전에 유도된 원래의 네트워크 토큰의 복사본을 포함하는 패킷은 P-GW 에서 수신될 수도 있다. 이전에 유도된 원래의 네트워크 토큰의 복사본은 업링크 네트워크 토큰 또는 다운링크 네트워크 토큰일 수도 있다. P-GW 는 이전에 유도된 원래의 네트워크 토큰의 복사본을 검증할 수도 있다. 검증 프로세스는 원래의 네트워크 토큰의 복제본을 유도하는 것을 포함할 수도 있다. 복제 네트워크 토큰은 동일한 암호 함수, P-GW 에 알려진 동일한 비공유 비밀 키, 및 패킷으로부터 획득될 수도 있는 동일한 다른 파라미터들을 이용하여 원래의 네트워크 토큰과 동일한 방법으로 유도될 수도 있다. 원래의 네트워크 토큰의 복사본과 연관된 새롭게 수신된 패킷은 원래의 네트워크 토큰과 연관된 패킷과는 상이하지만; 그러나, 원래의 패킷으로부터 획득된 것들과 동일한 새롭게 수신된 패킷으로부터 획득될 수 있는 파라미터들이 있다. 이 공통적인 파라미터들은 복제 네트워크 토큰을 유도하기 위하여 암호 함수에서 이용될 수도 있다. 복제 네트워크 토큰이 원래의 네트워크 토큰의 복사본과 동일할 경우, 원래의 네트워크 토큰의 방금-수신된 (just-received) 복사본은 성공적으로 검증된 것으로 고려될 수도 있다. 성공적인 검증 시에, 패킷은 그 목적지로 전송될 수도 있다. 검증이 성공적이지 않을 경우, 패킷은 폐기될 수 있다.

예시적인 동작 환경

도 2 는 예시적인 동작 환경 (200) 을 예시한다. 이러한 예시적인 동작 환경 (200) 에서, 하나 이상의 클라이언트 디바이스들 (202, 204) (예컨대, 클라이언트 A, 클라이언트 B) 은 액세스 노드 (206) (예컨대, 노드 B, eNodeB, 액세스 포인트 (access point; AP)) 와 무선으로 통신할 수도 있다. 액세스 노드 (206) 는 라디오 액세스 네트워크 (radio access network; RAN) (208) (예컨대, 진화형 유니버셜 지상 라디오 액세스 네트워크 (evolved universal terrestrial radio access network; E-UTRAN)) 내에 포함될 수도 있다. 당해 분야의 당업자들에 알려진 바와 같이, RAN (208) 은 전형적으로, 하나보다 많은 액세스 노드 (206) 를 포함한다. 도면은 혼잡함을 감소시키기 위하여 오직 하나의 액세스 노드 (206) 를 예시한다.

셀룰러 통신 시스템 (예컨대, 4G, LTE, LTE-A) 의 비한정적인 예에서, RAN (208) 은 제어-평면 시그널링 및 사용자-평면 메시지들을 코어 네트워크 (core network; CN) (210) (예컨대, 진화형 패킷 코어 (EPC)) 로 통신할 수도 있다. 도 2 의 예시도에서, 파선들은 제어 신호 경로들을 표현하고, 실선들은 사용자 데이터 메시지 경로들을 표현한다. 제어 평면은 제어 신호들 (예컨대, 제어-평면 시그널링) 을 전달한다. 사용자-평면은 사용자 데이터 (예컨대, 사용자-평면 메시지들) 를 전달한다. 본원에서 설명된 양태들의 구현예들은 사용자-평면을 이용하고; 제어 평면 시그널링은 요구되지 않는다. 제어 평면 시그널링이 요구되지 않으므로, 네트워크 기능성은 대부분의 부분에 대하여 영향받지 않는다. 클라이언트 디바이스 및 P-GW 의 사용자-평면 프로토콜 스택들의 수정은 본원에서 설명된 양태들의 일부와 연관되어 구현될 수도 있다. 예를 들어, 네트워크 토큰 설정 절차는 프로토콜 스택 수정을 요구할 수도 있다. 다시 말해서, 클라이언트 디바이스가 네트워크 토큰에 대한 요청의 표시로 접속 요청을 개시할 때, 게이트웨이 디바이스는 네트워크 토큰을 유도하고, (예컨대, 접속 요청을 갖는 패킷에서) 접속 요청을 갖는 네트워크 토큰을 임베딩하거나, 또는 그렇지 않을 경우에 이를 포함한다. 본원에서 설명된 양태들은 네트워크 토큰을 임베딩하기 위한 대안들 (예컨대, TCP, IP, 심 (Shim) 등) 을 제공하고, 네트워크 토큰들의 임베딩을 구현하기 위한 프로토콜 스택들에 대한 대응하는 예시적인 수정들을 설명한다.

CN (210) 은 이동성 관리 엔티티 (mobility management entity; MME) (212), 서빙 게이트웨이 (serving gateway; S-GW) (216), 홈 가입자 서버 (home subscriber server; HSS) (218), 및 패킷 데이터 네트워크 게이트웨이 (P-GW) (220) 를 포함할 수도 있다. P-GW (220) 는 패킷 데이터 네트워크 (PDN) (222) (예컨대, 인터넷) 와 통신할 수도 있다. 더욱 구체적으로, P-GW (220) 는 PDN (222) 에서의 서버들 (224, 226, 228, 230) (예컨대, 애플리케이션 서버들) 과 통신할 수도 있다. 서버들 (224, 226, 228, 230) 은 예를 들어, 판매 서비스들, 정보 서비스들, 스트리밍 비디오 서비스들, 및 소셜 미디어 서비스들을 제공하는 서비스 제공자들과 같은 서비스 제공자들과 연관될 수도 있다.

도 3 은 본원에서 설명된 양태들에 따라 예시적인 업링크 동작 (300) 을 예시한다. 예시적인 업링크 동작 (300) 은 편의상 롱텀 에볼루션 (long term evolution; LTE) 시스템의 맥락에서 제시된다. 예는 본원에서 설명된 임의의 양태들의 범위에 관하여 임의의 제한을 두도록 의도된 것이 아니다.

도 3 에서 표현된 것은 디바이스 (302) (예컨대, 칩 컴포넌트, 클라이언트 디바이스, 사용자 장비, 사용자 디바이스, 단말, 이동 디바이스), 액세스 노드 (304) (예컨대, eNodeB), 서빙 게이트웨이 (S-GW) (306), 패킷 게이트웨이 (P-GW) (308), 및 패킷 데이터 네트워크 (PDN) (310) (예컨대, 인터넷) 이다.

도 3 의 예시적인 업링크 동작 (300) 이 이제 설명된다. (예컨대, 디바이스 (302) 의 애플리케이션들/애플리케이션 서비스들 (312) 로부터의) IP 흐름들 (314) 은 트래픽 흐름 템플릿 (TFT) (316) 과 함께 포함된 패킷 필터들 (도시되지 않음) 에 적용된다. 도시된 IP 흐름들 (314) 의 수는 예시적이고, 한정적으로 의도된 것이 아니다.

TFT (316) 의 패킷 필터들은 IP 흐름들을 베어러들 (318) (예컨대, 진화형 패킷 시스템 (evolved packet system; EPS) 베어러들) 로 필터링한다. 3 개의 베어러들 (318) (예컨대, 베어러 1, 베어러 N-1, 및 베어러 N) 은 입증의 목적들을 위하여 예시되어 있다. 하나의 양태에서, 베어러는 다수의 애플리케이션들/애플리케이션 서비스들에 의해 공유될 수 있다. 각각의 베어러는 고유한 파라미터들의 세트와 연관될 수도 있다.

IP 흐름들 (315) 은 예를 들어, 디폴트 베어러 또는 하나 이상의 전용 베어러들에 맵핑될 수 있다. 디폴트 베어러는 전형적으로, 비-보장된 (non-guaranteed) 비트 레이트를 가질 수도 있는 반면, 전용 베어러들은 전형적으로, 보장된 또는 비-보장된 비트 레이트들의 어느 하나를 가질 수도 있다. 베어러들 (318) 은 액세스 노드 (304) 및 S-GW (306) 를 통과할 수도 있다. 액세스 노드 (304) 및 S-GW (306) 의 양태들은 본원에서 설명되지 않고, 당해 분야의 당업자들에게 알려져 있다.

하나의 양태에서, 베어러들 (318) 로부터의 IP 흐름들 (314) 은 판단 및 프로세싱 회로/기능부/모듈 (320) 로 전달될 수도 있다. 판단 및 프로세싱 회로/기능부/모듈 (320) 은 베어러들 (318) 로부터 수신된 UL 패킷들로 하여금, 암호-유효성확인 및 트래픽-스티어링 회로/기능부/모듈 (322) 로, 또는 서비스 데이터 흐름 (service data flow; SDF) 템플릿들 (324) 및 그것에 포함된 패킷 필터들 (도시되지 않음) 로 전달되게 할 수도 있다. 트래픽-스티어링은 시그널링 관련된 패킷들 및/또는 사용자 데이터 메시지 관련된 패킷들의 스티어링 (예컨대, 지향, 안내) 을 포함한다.

그것과 함께 포함된 네트워크 토큰들을 가지는 UL 패킷들은 암호-유효성확인 및 트래픽-스티어링 회로/기능부/모듈 (322) 로 전달될 수도 있다. 네트워크 토큰과 연관된 하나 이상의 정책들의 집행은 네트워크 토큰의 성공적인 유효성확인 시에 수행될 수도 있다.

그것과 함께 포함된 네트워크 토큰들을 가지지 않는 UL 패킷들은 판단 및 프로세싱 회로/기능부/모듈 (320) 에 의해 SDF 템플릿들 (324) 로 전달될 수도 있다. SDF 템플릿들 (324) 의 패킷 필터들의 이용은 암호-유효성확인 및 트래픽-스티어링 회로/기능부/모듈 (322) 의 이용보다 더 많은 프로세싱 및 메모리 자원들을 요구할 수도 있다. SDF 템플릿들 (324) 의 패킷 필터들을 이용하여 필터링을 수행하기 위하여, 예를 들어, P-GW (308) 는 각각의 SDF 에 대한 별도의 테이블 엔트리 테이블을 유지해야 한다.

따라서, 네트워크 토큰들의 이용 (및 암호-유효성확인 및 트래픽-스티어링 회로/기능부/모듈 (322) 의 결과적인 이용) 은 자원들을 절감하고 레이턴시를 감소시킨다. 하나의 양태에서, 암호 네트워크 토큰 (예컨대, 소프트웨어 토큰) 은 패킷 검사를 보충/향상시키기 위하여 이용될 수도 있다. 이 양태의 하나의 장점은 스케일러빌러티 (scalability) 를 포함한다. 즉, 테이블 엔트리들 또는 상태들은 고속-경로 (fast-path) (고속-패스 (fast-pass) 로도 알려짐) 상에서 유지될 필요가 없다. 이 양태의 또 다른 장점은 낮은 레이턴시를 포함한다. 즉, 단일 암호 동작 (예컨대, 더욱 고속으로 실행할 수도 있든지, 또는 적절하게 결정될 수도 있든지 간에, SHA-1, SHA-2, 또는 SHA-3 (여기서, SHA 는 보안 해시 알고리즘 (secure hash algorithm) 을 나타냄) 과 같은 암호 해시, 또는 진보된 암호화 표준 (advanced encryption standard; AES)) 은 액세스 제어를 위하여 충분할 수도 있다. 또한, 네트워크 토큰에 관한 암호 동작을 수행하기 위하여 요구된 시간은 P-GW 에 의해 서빙될 수도 있는 애플리케이션 서비스들의 수에 독립적이어야 한다. 대조적으로, SDF 템플릿의 패킷 필터들을 통해 순환시키기 위하여 요구된 시간은 P-GW 에 의해 서빙될 수도 있는 애플리케이션 서비스들의 수에 종속적이고; 애플리케이션 서비스들의 수를 증가시키는 것은 패킷 필터들의 수를 증가시킨다. 따라서, 정책 집행 및/또는 사용자-평면 메시지들의 스티어링을 위한 암호 네트워크 토큰들의 이용은 유익하다.

또 다른 장점은 유연성 (flexibility) 을 포함할 수도 있다. 즉, 암호 네트워크 토큰은 다양한 메타 데이터에 기초하여 유도될 수도 있다. 이러한 메타 데이터는 TFT/SDF 템플릿들에서 필터링되는 파라미터들에 한정되지 않는다. 추가적으로, 다양한 정책들 (예컨대, 인증성 정책들 및/또는 패킷의 허가 정책들) 은 네트워크 토큰에 적용될 수도 있다. 또 다른 장점은 분산된 서비스 거부 (distributed denial of service; DDoS) 공격들에 대한 레질리언스 (resilience) 를 포함할 수도 있다. 즉, 오류 있는/부적당한/진짜가 아닌 암호 네트워크 토큰을 포함하는 임의의 패킷은 서버 (예컨대, 도 1 의 서버 (124, 126, 128, 130)) 로 전송되기 전에 드롭시킴으로써, 패킷들에 의한 서버의 플러딩 (flooding) 을 방지할 것이다. 또 다른 장점은 재배치성 (relocatability) 의 특징에 있을 수도 있다. 이 장점의 실현은 제 1 게이트웨이 디바이스에서 대응하는 비밀 키에 대한 필터링 규칙 (또는 규칙들의 세트) 를 정의/맵핑함으로써, 그리고 그 다음으로, 제 2 게이트웨이 디바이스와 비밀 키를 공유함으로써 이해될 수도 있다. 이에 따라, 제 1 및 제 2 게이트웨이들 사이의 핸드오버 동안, 양태는 비밀 키의 전송/공유를 통한 SDF 필터들의 재배치 (relocation) 를 허용한다. 이것은 주어진 SDF 필터와 연관된 필터링 규칙 (또는 규칙들의 세트) 에 관련된 데이터의 전부를 전송할 필요성을 없애준다. 그러므로, 재배치성의 장점은, 프로세싱 자원들을 풀어주는데, 이 프로세싱 자원들은 그렇지 않았다면 다른 목적들을 위하여, 데이터의 전부를 전송하기 위하여 이용되었을 수도 있다.

도 4 는 본원에서 설명된 양태들에 따라 예시적인 다운링크 동작 (400) 을 예시한다. 예는 편의상 롱텀 에볼루션 (LTE) 시스템의 맥락에서 제시된다. 예는 본원에서 설명된 임의의 양태들의 범위에 관하여 임의의 제한을 두도록 의도된 것이 아니다.

도 4 에서 표현된 것은 디바이스 (402) (예컨대, 칩 컴포넌트, 클라이언트 디바이스, 사용자 장비, 사용자 디바이스, 단말, 이동 디바이스), 액세스 노드 (404) (예컨대, eNodeB), 서빙 게이트웨이 (S-GW) (406), P-GW (408), 및 PDN (410) (예컨대, 인터넷) 이다.

도 4 에서의 다운링크 동작이 이제 설명된다. (예컨대, PDN (410) 에서 상주하는 애플리케이션 서버들, 애플리케이션들, 애플리케이션 서비스들로부터의) 다운링크 IP 흐름들 (414) 은 P-GW (408) 의 판단 및 프로세싱 회로/모듈/디바이스 (420) 에 적용될 수도 있다. 도시된 다운링크 IP 흐름들 (414) 의 수는 예시적이고, 한정적으로 의도된 것이 아니다. 판단 및 프로세싱 회로/모듈/디바이스 (420) 는 다운링크 IP 흐름들 (414) 로부터 수신된 다운링크 패킷들로 하여금, 암호-검증 및 트래픽-스티어링 회로/모듈/디바이스 (422) 로, 또는 서비스 데이터 흐름 (SDF) 템플릿들 (424) 및 그것에 포함된 패킷 필터들 (도시되지 않음) 로 전달되게 할 수도 있다.

그것에 임베딩되거나 또는 그렇지 않을 경우에 그것과 함께 포함된 DL 다운링크 토큰들을 가지는 다운링크 패킷들은 암호-검증 및 트래픽-스티어링 회로/모듈/디바이스 (422) 로 전달될 수도 있다. 하나의 양태에서, DL 네트워크 토큰 및 애플리케이션 식별자 (App ID) 는 단일 다운링크 패킷 내에 임베딩될 수도 있거나, 또는 그렇지 않을 경우에 그것과 함께 포함될 수도 있다. App ID 는 애플리케이션 액세스 정책을 결정하기 위하여 이용될 수도 있다. 애플리케이션 액세스 정책은 애플리케이션 서버로부터 취출 (retrieve) 될 수도 있다. 일부 실시형태들에서, 애플리케이션 서버는 디바이스와 통신하기 위한 요청을 개시하는 애플리케이션 서버일 수도 있거나, 또는 그것은 디바이스가 통신을 개시하는 것을 추구하는 애플리케이션 서버일 수도 있지만; 그러나, 제 3 애플리케이션 서버가 또한 허용가능하다. 일부 양태들에서, 애플리케이션 액세스 정책은 애플리케이션 서버의 애플리케이션 기능부 (Application Function; AF) 로부터 취출될 수도 있다. 다른 양태들에서, 애플리케이션 액세스 정책은 정책 및 과금 규칙들 기능 서버 또는 디바이스와 연관된 가입자 프로파일 저장소 (Subscriber Profile Repository; SPR) 로부터 취출될 수도 있다.

하나의 양태에서, 애플리케이션 액세스 정책은 예를 들어, 서비스 우선순위, 최대 대역폭, 보장된 대역폭, 및/또는 최대 지연을 포함하는 서비스 품질 (Quality of Service; QoS) 파라미터들을 포함할 수도 있다. 이 정보는 DL 네트워크 토큰과 연관된 다운링크 패킷에 대한 데이터 흐름 또는 베어러를 선택하기 위하여, 암호-검증 및 트래픽-스티어링 회로/모듈/디바이스 (422) 또는 일부 다른 회로/모듈/디바이스에 의해 이용가능할 수도 있다.

그것에 임베딩되거나, 또는 그렇지 않을 경우에 그것과 함께 포함된 DL 네트워크 토큰들을 가지지 않는 다운링크 IP 흐름들 (414) 에서의 다운링크 패킷들은 판단 및 프로세싱 회로/모듈/디바이스 (420) 또는 다른 회로/모듈/디바이스 (도시되지 않음) 에 의해 SDF 템플릿들 (424) 로 전달될 수도 있다.

패킷 필터들 (도시되지 않음) 은 SDF 템플릿들 (424) 과 함께 포함될 수도 있다. SDF 템플릿들 (424) 의 패킷 필터들의 이용은 암호-검증 및 트래픽-스티어링 회로/모듈/디바이스 (422) 의 이용보다 더 많은 프로세싱 및 메모리 자원들을 요구할 수도 있다. SDF 템플릿들 (424) 의 패킷 필터들을 이용하여 필터링을 수행하기 위하여, P-GW (408) 는 각각의 SDF 에 대한 별도의 테이블 엔트리들을 가지는 테이블 (들) (424a) 을 유지할 필요가 있을 수도 있다. 각각의 테이블 엔트리는 애플리케이션 ID, 최대 비트 레이트 (maximum bit rate; MBR), 및 액세스 포인트 명칭-총 최대 비트 레이트 (access point name-aggregate maximum bit rate; APN-AMBR) 와 같은, 그러나 이것으로 한정되지 않은, 다수의 파라미터들의 식별을 요구할 수도 있다.

SDF 템플릿들 (424) 의 패킷 필터들은 IP 흐름들을 베어러들 (418) (예컨대, 진화형 패킷 시스템 (EPS) 또는 IP-CAN 베어러들) 로 필터링하도록 서빙한다. 3 개의 베어러들 (418) 은 설명의 목적들을 위하여 예시되어 있다. 하나의 양태에서, 베어러는 다수의 애플리케이션들/애플리케이션 서비스들에 의해 공유될 수 있다. 각각의 베어러는 고유한 파라미터들의 세트와 연관될 수도 있다.

다운링크 IP 흐름들 (414) 은 예를 들어, 디폴트 베어러 또는 하나 이상의 전용 베어러들에 맵핑될 수 있다. 디폴트 베어러는 전형적으로, 비-보장된 비트 레이트를 가질 수도 있는 반면, 전용 베어러들은 전형적으로, 보장된 또는 비-보장된 비트 레이트들의 어느 하나를 가질 수도 있다. 베어러들은 S-GW (406) 및 액세스 노드 (404) 를 통과할 수도 있다. 액세스 노드 (404) 및 S-GW (406) 의 양태들은 본원에서 설명되지 않고, 당해 분야의 당업자들에게 알려져 있다.

데이터 흐름들

본원에서 설명된 양태들에서, IP 흐름들, 데이터 흐름들, 또는 흐름들은 도 2 의 예시적인 예시도에서 제시된 바와 같이, 베어러들로 한정될 필요가 없다. 클라이언트 디바이스는 하나 이상의 애플리케이션들을 동작시킬 수도 있거나 실행할 수도 있다. 각각의 클라이언트 애플리케이션은 애플리케이션 서버 상에서 동작하거나 실행되는 애플리케이션 서비스에 맵핑될 수도 있다. 애플리케이션 서버는 하나 이상의 애플리케이션 서비스들과 연관될 수 있다. 그러므로, 흐름은 디바이스에서, 그리고 애플리케이션 서버 상에서 동작하는 애플리케이션에 기초하여 정의될 수도 있다. 흐름은 패킷들이 클라이언트 디바이스에서 실행되는 애플리케이션과, 애플리케이션 서버에서 실행되는 애플리케이션 서비스 사이에서 취하는 경로로서 정의될 수도 있다. 흐름은 클라이언트 디바이스 상에서 동작하는 애플리케이션과 연관될 수도 있지만, 흐름은 반드시 클라이언트 디바이스를 식별하지는 않는다. 네트워크 토큰은 하나 이상의 흐름들을 식별하기 위하여 이용될 수도 있다. 따라서, 네트워크 토큰은 다수의 흐름들과 연관될 수도 있다.

하나의 흐름은 네트워크에서의 동일한 서버 상에서 실행되는 다수의 서비스들에 맵핑될 수도 있다. 예를 들어, 클라이언트 디바이스는 서버 상에서 하나의 제공자에 의해 제공된 하나의 서비스를 이용할 수도 있다. 서버는 전형적으로 하나의 IP 어드레스를 가진다. 그러나, 서비스는 서버 상에서 다수의 애플리케이션들을 호스팅할 수도 있다. 다수의 애플리케이션들은 예를 들어, 맵핑 애플리케이션, 정보 검색 애플리케이션, 및 소셜 네트워킹 애플리케이션을 포함할 수도 있다. 그러므로, 다수의 애플리케이션들은 동일한 목적지 IP 어드레스를 가지고, 따라서, 코어 네트워크의 게이트웨이 (예컨대, P-GW) 의 관점으로부터, 다수의 애플리케이션들은 다수의 흐름들 대신에 단일 흐름으로서 고려될 수 있다. 따라서, 단일 흐름은 다수의 서비스들에 맵핑될 수 있다.

흐름은 다수의 서비스들과 연관될 수 있다. 게다가, 네트워크 토큰은 다수의 서비스들과 연관될 수 있고, 여기서, 다수의 애플리케이션 서비스 제공자들은 서비스들을 실행할 수도 있다. 예를 들어, 클라이언트 디바이스는 다수의 후원자들 (예컨대, 다수의 서비스 제공자들) 을 가질 수도 있다. 본원에서 설명된 양태들에서, 게이트웨이 디바이스는 다수의 애플리케이션 서비스 제공자들과 연관되는 네트워크 토큰을 유도할 수도 있다. 결과적으로, 단일 토큰은 하나 이상의 애플리케이션 서비스들에 맵핑될 수도 있고 이들은 차례로 하나 이상의 흐름들과 연관된다.

본원에서 제공된 몇몇 예들에서, 네트워크 토큰은 애플리케이션 식별자 (App ID) 에 기초하여 유도될 수도 있다. 그러나, 네트워크 토큰들의 유도는 이러한 예들로 한정되지 않는다. 다른 파라미터들, 및/또는 파라미터들의 조합들은 네트워크 토큰을 유도하기 위하여 이용될 수도 있다. App ID 는 하나 이상의 서버들과 연관될 수도 있다. 예를 들어, 주어진 서비스 제공자는 상이한 지리적 로케이션들에서 상이한 데이터 센터들 (각각이 그 자신의 서버를 가짐) 을 가질 수도 있다. 이러한 경우, App ID 는 하나보다 많은 서버와 연관될 것이다. 토큰은 서버 IP 어드레스 대신에, App ID 를 유익하게 이용할 수도 있다. 게이트웨이 디바이스는 네트워크 토큰이 목적지 서버의 IP 어드레스를 특정하지 않더라도, 네트워크 토큰과 연관된 패킷이 주어진 서비스 제공자의 서버를 향해 가고 있다는 것을 검증할 수 있다.

토큰 설정 및 이용 - 예시적인 시스템 레벨 호출 흐름들

본원에서 기재된 예들은 초기 PDN 접속성 요청 절차 (그 동안 디폴트 베어러가 설정될 수도 있음) 및 전용 베어러 설정 절차들 (그 동안 하나 이상의 전용 베어러들이 설정될 수도 있음) 에 적용할 수도 있다.

도 5 는 본원에서 설명된 양태들에 따라 하나 이상의 사용자-평면 메시지들과 관련하여 네트워크 토큰 유도, 프로비저닝, 및 이용을 예시하는 예시적인 호출 흐름 (500) 이다. 언급된 바와 같이, 호출 흐름은 사용자-평면에서 구현될 수도 있다. 도 5 는 디바이스 (502) (예컨대, 칩 컴포넌트, 클라이언트 디바이스), 액세스 노드 (504) (예컨대, eNB), MME (506), S-GW (508), P-GW (510), 정책 및 과금 규칙들 기능 (policy and charging rules function; PCRF) (512) 디바이스, 홈 가입자 서버 (HSS) (514), 및 애플리케이션 서버 (516) 의 표현들을 포함한다.

도 5 의 예시적인 호출 흐름에서, 디바이스 (502) 는 접속 요청을 애플리케이션 서버 (516) 로 전송할 수도 있다 (518). 접속 요청은 애플리케이션 식별자 (App ID) 와 같은 식별자를 포함할 수도 있다. 접속 요청은 P-GW (510) 로 코어 네트워크를 통과할 수도 있다. P-GW (510) 는 정책 집행을 위한 게이트웨이일 수도 있다. P-GW (510) 는 또한, 네트워크 토큰에 대한 명백한 또는 묵시적 요청을 검출하기 위하여 이용될 수도 있다.

하나의 양태에 따르면, 액세스 노드 (504) (예컨대, eNodeB) 는 애그노스틱 (agnostic) 일 수도 있다. 즉, 액세스 노드 (504) 는 디바이스가 사용자-평면에서의 접속 요청을 애플리케이션 서버 (516) 로 전송하였다는 것을 알지 못할 수도 있고, 여기서, 접속 요청은 네트워크 토큰에 대한 요청을 명백히 포함하거나, 네트워크 토큰에 대한 묵시적 요청을 표현한다. 이러한 양태에 따르면, 네트워크 토큰들의 요청 및 교환은 애그노스틱 액세스 노드 (504) 에 인식되지 못할 수도 있다.

결정은 디바이스로부터 전송된 접속 요청을 포함하는 패킷이 네트워크 토큰에 대한 명백한 요청을 포함하거나, 또는 네트워크 토큰에 대한 묵시적 요청을 표현하는지 여부에 대하여, P-GW (510) 에서 행해질 수도 있다. 결정이 네트워크 토큰에 대한 필요성이 존재하는 것으로 결론내릴 경우, P-GW (510) 는 네트워크 토큰을 유도하기 위하여 요구된 정보를 획득하는 것, 네트워크 토큰을 유도하는 것, 및 디바이스 (502) 로부터의 접속 요청을 포함하였던 패킷과 함께 네트워크 토큰을 임베딩/포함하는 것을 포함하는 액션들을 수행할 수도 있다. 본원에서 이용된 바와 같이, 용어 "유도" 는 또 다른 디바이스로부터 획득하거나 또는 로컬적으로 유도하는 것을 의미할 수도 있다.

하나의 양태에 따르면, P-GW (510) 는 패킷과 연관된 입력 파라미터들의 해시 (hash) 에 기초하여 네트워크 토큰을 유도할 수도 있다 (522). 이러한 패킷에서는, 패킷에 관련되는 추가적인 정보를 획득할 필요성이 없을 수도 있다. 추가적인 정보가 필요하게 될 경우, P-GW (510) 는 PCRF (512) 로부터 디바이스 (502) 의 프로파일을 획득할 수도 있다 (520). PCRF (512) 는 PCRF (512) 에 결합된 가입 프로파일 저장소 (SPR) 로부터 디바이스의 가입 프로파일을 획득할 수도 있다. 디바이스 (502) 의 프로파일을 획득하는 다른 방법들이 허용가능할 수도 있다.

P-GW (510) 는 네트워크 토큰을 유도할 수도 있다 (522). 하나의 양태에 따르면, 네트워크 토큰은 패킷과 연관된 입력 파라미터들의 해시에 기초하여 유도될 수도 있다. 하나의 양태에 따르면, 네트워크 토큰은 접속 요청 및/또는 디바이스 프로파일과 연관된 정보에 기초하여 유도될 수도 있다. 하나의 예에 따르면, 네트워크 토큰은 이하로서 유도될 수도 있다:

네트워크 토큰 = CI | HMAC (K_P-GW, CI | IP_C | IP_S | P_C | P_S | Proto | App ID | …),

여기서: CI 는 토큰 유도를 위하여 이용된 필드들을 정의하는 클래스 인덱스이고, HMAC 는 키잉된-해시 (keyed-hash) 메시지 인증 코드이고, K_P _-GW 는 P-GW 의 비밀 키이고, IP_C 는 클라이언트 (예컨대, 디바이스) IP 어드레스이고, P_C 는 클라이언트 포트 번호이고, IP_S 는 서버 (예컨대, 목적지 또는 애플리케이션 서버) IP 어드레스이고, P_S 는 서버 포트 번호이고, Proto 는 프로토콜 번호 또는 식별자이고, App ID 는 애플리케이션 식별자이다. 추가적인 또는 대안적인 파라미터들은 우선순위 및/또는 서비스 품질 클래스 식별자 (QCI) 를 포함할 수도 있다. 네트워크 토큰의 유도를 위한 다른 공식들이 허용가능할 수도 있다.

P-GW (510) 는 접속 요청을 포함하였던 패킷과 함께 네트워크 토큰을 임베딩/포함할 수도 있다 (524). 그 다음으로, P-GW 는 P-GW (510) 에 의해 유도된 네트워크 토큰을 포함하는 접속 요청을 애플리케이션 서버 (516) 로 전송할 수도 있다 (526). 접속 요청은 애플리케이션 식별자 (App ID) 를 포함할 수도 있다.

그 다음으로, 애플리케이션 서버 (516) 는 접속 응답을 디바이스 (502) 로 전송할 수도 있다 (528). 접속 응답은 네트워크 토큰을 포함할 수도 있다. 그 후에, 디바이스 (502) 는 애플리케이션 서버 (516) 로의 데이터 송신을 위하여 구성된 하나 이상의 업링크 데이터 패킷들과 함께 네트워크 토큰을 포함할 수도 있다. 일부 양태들에서, 디바이스 (502) 는 애플리케이션 서버 (516) 에 대하여 예정된 매 업링크 데이터 패킷과 함께 네트워크 토큰을 포함할 수도 있다.

집행에 대하여, 디바이스 (502) 는 업링크 데이터 패킷을 애플리케이션 서버 (516) 로 전송할 수도 있다 (530). 업링크 데이터 패킷은 네트워크 토큰을 포함할 수도 있다. 네트워크 토큰을 포함하는 업링크 데이터 패킷은 P-GW (510) 로 코어 네트워크를 통과할 수도 있다. 기재된 바와 같이, P-GW (510) 는 정책 집행을 위한 게이트웨이일 수도 있다.

P-GW (510) 가 디바이스 (502) 로부터 전송된 업링크 데이터 패킷을 수신할 때, P-GW (510) 는 업링크 데이터 패킷과 함께 포함된 네트워크 토큰을 검증할 수도 있다 (532). 하나의 양태에 따르면, 검증은 토큰을 재유도 (re-derive) 하는 것 (즉, 검증 토큰 또는 원래의 네트워크 토큰의 복제본을 유도함) 과, 재유도된 토큰을, 업링크 데이터 패킷과 함께 임베딩된 네트워크 토큰과 비교하는 것에 의한 것일 수도 있다. 검증이 성공적일 경우, P-GW (510) 는 임베딩된 네트워크 토큰을 폐기할 수 있고, 업링크 데이터 패킷을 애플리케이션 서버 (516) 로 전송할 수도 있다 (534). 검증이 성공적이지 않을 경우, P-GW 는 업링크 데이터 패킷 및 임베딩된 네트워크 토큰을 폐기할 수도 있다.

P-GW (510) 에 알려진 비밀 키는 원래의 네트워크 토큰 및 검증 토큰 (예컨대, 원래의 네트워크 토큰의 복제본) 을 유도하기 위하여 암호 함수에서 이용될 수도 있다. 하나의 예에서, P-GW (510) 는 애플리케이션 기능부 (AF) 로부터 취출된 애플리케이션 액세스 정책을 고려하여 네트워크 토큰을 유도할 수도 있다. 하나의 양태에서, 액세스 정책은 흐름을 애플리케이션에 연관시킬 수도 있다. 네트워크 토큰은 예컨대, App ID 가 네트워크 토큰에 대한 요청과 함께 포함될 경우에, App ID 를 고려하여 추가로 유도될 수도 있다. 일부 양태들에서, 네트워크 토큰은 암호화된 정보를 포함할 수도 있다. 복호화는 하나의 예에서, P-GW (510) 에 알려진 비밀 키를 그 입력으로서 가지는 암호 함수를 이용하여 달성될 수도 있다. 예로서, 네트워크 토큰의 성공적인 복호화는 네트워크 토큰을 포함하였던 UL 패킷과 연관시켜서, 서버 및/또는 애플리케이션 서비스의 목적지 어드레스 또는 목적지 어드레스 프리픽스, 및/또는 UL 패킷이 소싱 (source) 되었던 클라이언트 디바이스 및/또는 액세스 노드의 소스 어드레스를 표시할 수도 있는 값을 산출할 수도 있다. 하나의 양태에서, 예를 들어, 네트워크 토큰으로부터 서버 및/또는 애플리케이션 서비스의 목적지 어드레스 또는 목적지 어드레스 프리픽스를 획득하기 위한 능력은 토큰과 연관된 패킷이 그 목적지로 전송되도록 허가된다는 것을 의미할 수도 있고, SDF 템플릿들 (및 그 연관된 패킷 필터들) 이 필요하지 않다는 것을 추가로 의미할 수도 있다. 패킷 검사는 이에 따라 회피될 수도 있다.

본원에서 설명된 바와 같이 사용자-평면을 이용하는 양태들은 업링크 및 다운링크 방향들에 동일하게 잘 적용할 수도 있다.

도 6 은 본원에서 설명된 양태들에 따라 하나 이상의 사용자-평면 메시지들과 관련하여 네트워크 토큰 유도, 프로비저닝, 및 이용을 예시하는 예시적인 호출 흐름 (600) 이다. 언급된 바와 같이, 호출 흐름은 사용자-평면에서 구현될 수도 있다. 도 6 은 디바이스 (602) (예컨대, 칩 컴포넌트, 클라이언트 디바이스), 액세스 노드 (604) (예컨대, eNB), MME (606), S-GW (608), P-GW (610), 정책 및 과금 규칙들 기능 (PCRF) (612) 디바이스, 홈 가입자 서버 (HSS) (614), 및 애플리케이션 서버 (616) 의 표현들을 포함한다. 예시적인 호출 흐름 (600) 에 따르면, 다운링크 (DL) 네트워크 토큰은 디바이스 (602) 에 의한 DL 네트워크 토큰의 이용에 대한 묵시적 또는 명시적 요청을 통해 P-GW (610) 에 의해 애플리케이션 서버 (616) 에 발행될 수도 있다.

도 6 의 예시적인 호출 흐름에서, 디바이스 (602) 는 애플리케이션 서버 (616) 로 애플리케이션 서비스를 개시하기 위한 요청을 P-GW (610) 를 통해 전송한다 (618). 요청은 애플리케이션 식별자 (App ID) 에 의해 동반될 수도 있거나, 또는 애플리케이션 식별자 (App ID) 를 포함할 수도 있다. 당해 분야의 당업자들에 의해 이해되는 바와 같이, 디바이스 (602) 로부터 애플리케이션 서버 (616) 로 제공된 요청은 디바이스와 네트워크 사이의 접속을 확립하거나 재확립하기 위한 임의의 타입의 접속 요청과는 상이하고, 이와 혼동되지 않아야 한다. 전자의 경우, 디바이스는 애플리케이션 서버로부터 서비스를 요청하고 있는 반면 (서비스는 심지어 무접속 서비스일 수도 있음), 후자의 경우에는, 디바이스가 네트워크로의 접속을 요청하고 있다.

하나의 양태에서, 애플리케이션 서비스를 개시하기 위한 요청은 다운링크 (DL) 네트워크 토큰의 이용에 대한 묵시적 요청을 표현한다. 다운링크 네트워크 토큰의 이용에 대한 묵시적 요청은 초기 패킷을 P-GW (710) 를 통해 디바이스 (702) 로부터 애플리케이션 서버 (716) 로 전송함으로써 인식될 수도 있다. 하나의 예에서, 묵시적 요청은 DL 네트워크 토큰들을 반송하기 위하여 애플리케이션 서버로부터의 패킷들을 요구하는 운영자의 정책에 의해 트리거링될 수도 있다. 이러한 정책의 인식은 예를 들어, 서비스에 의해 제공된 패킷들에 관한 패킷 검사를 수행하고 서비스가 사전-정의된 (pre-defined) 네트워크 정책의 집행을 위하여 DL 네트워크 토큰을 요구하는 것으로 판단하는 P-GW 에 의해 획득될 수도 있다. 다운링크 네트워크 토큰의 이용에 대한 묵시적 요청을 표시하기 위한 다른 방법들이 허용가능하다.

하나의 양태에서, 애플리케이션 서비스를 개시하기 위한 요청은 애플리케이션 서버로부터 디바이스로 전송된 송신들에서의 DL 네트워크 토큰의 이용에 대한 명시적 요청을 포함할 수도 있다. 하나의 양태에서, 명시적 요청은 애플리케이션 서버 (716) 로 전송된 제 1 패킷 내에 포함될 수 있지만; 그러나, 이것은 요건이 아니다.

DL 네트워크 토큰들의 이용은 애플리케이션 서비스의 개시 또는 애플리케이션 서비스의 수정 시에 발생할 수도 있다.

DL 네트워크 토큰들을 이용하기 위한 명시적 또는 묵시적 요청의 수신에 응답하여, 하나의 양태에서, P-GW (610) 는 PCRF (612) 로부터 디바이스 프로파일을 획득할 수도 있다 (620). P-GW (610) 는 오직 예로서, 다음의 공식을 이용하여 DL 네트워크 토큰을 유도할 수도 있다 (622):

DL 네트워크 토큰 = KeyID | CI | 정책 ID | H(KP-GW, 정책 ID | IPS | IPC | PS| PC | Proto | App ID | …),

여기서: KeyID 는 토큰 유도를 위하여 이용된 키 (즉, K_P-GW) 의 식별자이고, CI 는 토큰 유도를 위하여 이용된 필드들, 또는 토큰을 유도하기 위하여 이용된 입력 파라미터들의 리스트를 정의하는 클래스 인덱스이고, 정책 ID 는 흐름 취급 정책 (예컨대, QoS 정책, 흐름을 베어러에 맵핑하는 것, 및 당해 분야의 당업자들에 의해 이용된 바와 같은 흐름 취급 정책들의 다른 양태들) 을 정의하는 정책 식별자이고, H 는 보안 해시 함수 (대안적으로, 해시 메시지 인증 코드 (hash message authentication code; HMAC) 가 이용될 수 있음) 이고, K_P _-GW 는 P-GW 의 비밀 키이고, IP_C 는 클라이언트 (예컨대, 디바이스) IP 어드레스이고, P_C 는 클라이언트 포트 번호이고, IP_S 는 서버 IP 어드레스이고, P_S 는 서버 포트 번호이고, Proto 는 프로토콜 번호이고, App ID 는 애플리케이션 식별자이다. 다운링크 토큰 내에 포함된 정책 ID 는 다운링크 패킷을 주어진 베어러에 맵핑하기 위하여 이용될 수도 있다. 대안적으로, 정책 ID 에 대한 KeyID 를 이용하는 것이 가능할 수도 있고; 이 경우, 정책 ID 값은 DL 네트워크 토큰의 계산에서 필요하지 않을 수도 있다.

일단 유도되면, DL 네트워크 토큰은 애플리케이션 서비스를 개시하기 위한 요청을 갖는 패킷 내에 임베딩될 수도 있거나, 또는 그렇지 않을 경우에 그 패킷과 함께 포함될 수도 있다 (624).

임의적으로, P-GW (610) 는 디바이스 개시된 접속을 식별하기 위하여 이용될 수 있는 접속 식별자 (접속 ID 또는 Conn ID) 를 유도할 수도 있다 (626). 하나의 양태에서, 접속 ID 는 이하로서 유도될 수도 있다:

접속 ID = KeyID | CI | HMAC (K'_P-GW, IP_S | IP_C | P_S | P_C | Proto).

여기서, K'_P-GW 는 DL 네트워크 토큰을 유도하기 위하여 이용된 비밀 키와는 상이한, P-GW 에 알려진 비밀 키일 수도 있다. 접속 ID 는 P-GW (610) 내에서의 캐시 내에 저장될 수도 있다 (628).

P-GW (610) 에 의해 유도된 임베딩된/포함된 DL 네트워크 토큰을 포함하는, 애플리케이션 서비스를 개시하기 위한 요청은 애플리케이션 서버 (616) 로 전송될 수도 있다 (630). 애플리케이션 서비스를 개시하기 위한 요청은 애플리케이션 식별자 (App ID), DL 네트워크 토큰, 및 유도될 경우, 접속 ID 를 포함할 수도 있다.

애플리케이션 서버 (616) 는 DL 네트워크 토큰 (예컨대, DL 네트워크 토큰의 복사본) 및 유도될 경우, 접속 ID 를 포함하는 애플리케이션 서비스 응답을 P-GW (610) 를 통해 디바이스 (602) 로 전송할 수도 있다 (632).

P-GW (610) 가 그것에 임베딩된 DL 네트워크 토큰을 가지는 패킷을 수신할 때, P-GW (610) 는 예를 들어, 원래의 네트워크 토큰을 유도하는 것과 관련하여 위에서 설명된 것과 동일한 공식을 이용하여 패킷 내에 포함된 데이터로부터 토큰을 유도함으로써, DL 네트워크 토큰을 검증할 수도 있다 (634). 즉, P-GW (610) 는 디바이스 (602) 로부터 수신된 데이터 대신에, 애플리케이션 서버 (616) 로부터 수신된 패킷으로부터의 데이터로 원래의 DL 네트워크 토큰을 재유도할 수도 있다. 당해 분야의 당업자들에 의해 이해되는 바와 같이, 디바이스 (602) 로부터 수신된 패킷에서의 데이터의 전부가 애플리케이션 서버 (616) 로부터 수신된 패킷에서의 데이터와 동일하지는 않을 것이다. 그러나, 당해 분야의 당업자에 의해 또한 이해되는 바와 같이, 하나의 양태에서, 디바이스 (602) 로부터 수신된 패킷 및 애플리케이션 서버 (616) 로부터 수신된 패킷의 양자 내에 포함된 공통적인 데이터는 원래의 DL 네트워크 토큰 (또한, 검증 토큰으로서 본원에서 지칭됨) 을 재유도하기 위하여 이용될 수 있다. 원래의 DL 네트워크 토큰의 예시적인 유도와 관련하여 위에서 설명된 바와 같이, 이러한 공통적인 데이터는 CI, IP_S, IP_C, P_S, P_C, Proto, 및/또는 App ID 를 포함할 수도 있다. 이 리스트는 예시적이고 한정적이지 않도록 의도된 것이다.

이러한 양태에서, 검증은 재유도된 DL 네트워크 토큰을, 애플리케이션 서버 (616) 로부터 수신된 패킷 내에 임베딩된 DL 네트워크 토큰과 비교함으로써 달성될 수도 있다.

유효성확인이 성공적이었을 경우, 애플리케이션 서버 (616) 로부터의 애플리케이션 서비스 응답은 디바이스 (602) 로 전송될 수도 있다 (636). 하나의 양태에서, P-GW (610) 는 응답과 함께 DL 네트워크 토큰을 임베딩할 수도 있거나, 또는 임베딩되거나 또는 그렇지 않을 경우에 첨부된 상태로 둘 수도 있다. 또 다른 양태에서, P-GW (610) 는 응답이 디바이스 (602)로 전송 (636) 되기 전에 DL 네트워크 토큰을 폐기할 수도 있다 (도시되지 않음). 유효성확인이 성공적이지 않았을 경우, P-GW (610) 는 응답을 폐기할 수도 있다 (도시되지 않음).

그 후에, 애플리케이션 서버 (616) 는 P-GW (610) 를 통해 애플리케이션 서버 (616) 로부터 디바이스 (602) 로 전송된 (DL 네트워크 토큰이 유도되었던 통신 세션에 관련된) 하나 이상의 패킷들 내에 DL 네트워크 토큰의 복사본을 임베딩/포함할 수도 있다. 일부 양태들에서, 애플리케이션 서버 (616) 는 P-GW (610) 를 통해 애플리케이션 서버 (616) 로부터 디바이스 (602) 로 전송된 (DL 네트워크 토큰이 유도되었던 통신 세션에 관련된) 매 패킷 내에 DL 네트워크 토큰의 복사본을 임베딩/포함할 수도 있다.

도 7 은 본원에서 설명된 양태들에 따라 하나 이상의 사용자-평면 메시지들과 관련하여 네트워크 토큰 유도, 프로비저닝, 및 이용을 예시하는 예시적인 호출 흐름도 (700) 이다. 언급된 바와 같이, 호출 흐름은 사용자-평면에서 구현될 수도 있다. 도 7 은 디바이스 (702) (예컨대, 칩 컴포넌트, 클라이언트 디바이스), 액세스 노드 (704) (예컨대, eNB), MME (706), S-GW (708), P-GW (710), 정책 및 과금 규칙들 기능 (PCRF) (712) 디바이스, 홈 가입자 서버 (HSS) (714), 및 애플리케이션 서버 (716) 의 표현들을 포함한다. 예시적인 호출 흐름도 (700) 에 따르면, 다운링크 (DL) 네트워크 토큰은 애플리케이션 서버 (716) 에 의해 행해진 DL 네트워크 토큰의 이용에 대한 묵시적 또는 명시적 요청을 통해 P-GW (710) 에 의해 애플리케이션 서버 (716) 에 발행될 수도 있다.

도 7 의 예시적인 호출 흐름에서, 애플리케이션 서버 (716) 는 디바이스 (702) 로 애플리케이션 서비스를 개시하기 위한 요청을 P-GW (710) 를 통해 전송한다 (718). 요청은 애플리케이션 식별자 (App ID) 에 의해 수반될 수도 있거나, 또는 애플리케이션 식별자 (App ID) 를 포함할 수도 있다. 당해 분야의 당업자들에 의해 이해되는 바와 같이, 애플리케이션 서버 (716) 로부터 디바이스 (702) 로 제공된 요청은 애플리케이션 서버와 네트워크 사이의 접속을 확립하거나 재확립하기 위한 임의의 타입의 접속 요청과는 상이하고, 이와 혼동되지 않아야 한다. 전자의 경우, 애플리케이션 서버는 애플리케이션 서비스를 디바이스에 제공하도록 요청하고 있는 반면 (서비스는 무접속 서비스일 수도 있음), 후자의 경우에는, 애플리케이션 서버가 네트워크로의 접속을 요청하고 있다.

하나의 양태에서, 애플리케이션 서비스를 개시하기 위한 요청은 다운링크 (DL) 네트워크 토큰의 이용에 대한 묵시적 요청을 표현한다. 다운링크 네트워크 토큰의 이용에 대한 묵시적 요청은 초기 패킷을 P-GW (710) 를 통해 애플리케이션 서버 (716) 로부터 디바이스 (702) 로 전송함으로써 인식될 수도 있다. 하나의 예에서, 묵시적 요청은 DL 네트워크 토큰들을 반송하기 위하여 애플리케이션 서버로부터의 패킷들을 요구하는 운영자의 정책에 의해 트리거링될 수도 있다. 이러한 정책의 인식은 예를 들어, 서비스에 의해 제공된 패킷들에 관한 패킷 검사를 수행하고 서비스가 사전-정의된 (pre-defined) 네트워크 정책의 집행을 위하여 DL 네트워크 토큰을 요구하는 것으로 판단하는 P-GW 에 의해 획득될 수도 있다. 다운링크 네트워크 토큰의 이용에 대한 묵시적 요청을 표시하기 위한 다른 방법들이 허용가능하다.

하나의 양태에서, 애플리케이션 서비스를 개시하기 위한 요청은 애플리케이션 서버로부터 디바이스로 전송된 송신들에서의 DL 네트워크 토큰의 이용에 대한 명시적 요청을 포함할 수도 있다. 하나의 양태에서, 명시적 요청은 디바이스 (702) 로 전송된 제 1 패킷 내에 포함될 수 있지만; 그러나, 이것은 요건이 아니다.

DL 네트워크 토큰들을 이용하기 위한 명시적 또는 묵시적 요청의 수신에 응답하여, 하나의 양태에서, P-GW (710) 는 PCRF (712) 로부터 디바이스 프로파일을 획득할 수도 있다 (720). P-GW (710) 는 오직 예로서, 다음의 공식을 이용하여 DL 네트워크 토큰을 유도할 수도 있다 (722):

DL 네트워크 토큰 = KeyID | CI | 정책 ID | H(K_P-GW, 정책 ID | IP_S | IP_C | P_S| P_C | Proto | App ID | …),

여기서: KeyID 는 토큰 유도를 위하여 이용된 키 (즉, K_P-GW) 의 식별자이고, CI 는 토큰 유도를 위하여 이용된 필드들, 또는 토큰을 유도하기 위하여 이용된 입력 파라미터들의 리스트를 정의하는 클래스 인덱스이고, 정책 ID 는 흐름 취급 정책 (예컨대, QoS 정책, 흐름을 베어러에 맵핑하는 것, 및 당해 분야의 당업자들에 의해 이용된 바와 같은 흐름 취급 정책들의 다른 양태들) 을 정의하는 정책 식별자이고, H 는 보안 해시 함수 (대안적으로, 해시 메시지 인증 코드 (HMAC) 가 이용될 수 있음) 이고, K_P _-GW 는 P-GW 의 비밀 키이고, IP_C 는 클라이언트 (예컨대, 디바이스) IP 어드레스이고, P_C 는 클라이언트 포트 번호이고, IP_S 는 서버 IP 어드레스이고, P_S 는 서버 포트 번호이고, Proto 는 프로토콜 번호이고, App ID 는 애플리케이션 식별자이다. 다운링크 토큰 내에 포함된 정책 ID 는 다운링크 패킷을 주어진 베어러에 맵핑하기 위하여 이용될 수도 있다. 대안적으로, 정책 ID 에 대한 KeyID 를 이용하는 것이 가능할 수도 있고; 이 경우, 정책 ID 값은 DL 네트워크 토큰의 계산에서 필요하지 않을 수도 있다.

일단 유도되면, DL 네트워크 토큰은 애플리케이션 서비스를 개시하기 위한 요청을 갖는 패킷 내에 임베딩될 수도 있거나, 또는 그렇지 않을 경우에 그 패킷과 함께 포함될 수도 있다 (724).

임의적으로, P-GW (710) 는 서버 개시된 접속을 식별하기 위하여 이용될 수 있는 접속 식별자 (접속 ID 또는 Conn ID) 를 유도할 수도 있다 (726). 하나의 양태에서, 접속 ID 는 이하로서 유도될 수도 있다:

접속 ID = KeyID | CI | HMAC (K'_P-GW, IP_S | IP_C | P_S | P_C | Proto)

여기서, K'_P-GW 는 DL 네트워크 토큰을 유도하기 위하여 이용된 비밀 키와는 상이한, P-GW 에 알려진 비밀 키일 수도 있다. 접속 ID 는 P-GW (710) 내에서의 캐시 내에 저장될 수도 있다 (728).

P-GW (710) 에 의해 유도된 임베딩된/포함된 DL 네트워크 토큰을 포함하는, 애플리케이션 서비스를 개시하기 위한 요청은 디바이스 (702) 로 전송될 수도 있다 (730). 애플리케이션 서비스를 개시하기 위한 요청은 애플리케이션 식별자 (App ID), DL 네트워크 토큰, 및 유도될 경우, 접속 ID 를 포함할 수도 있다.

디바이스 (702) 가 임베딩된 DL 네트워크 토큰을 포함하는, 애플리케이션 서비스를 개시하기 위한 요청을 수신할 때, 디바이스 (702) 는 요청을 검증할 수도 있다 (732). 임의적으로, 디바이스 (702) 는 인증을 위한 또 다른 토큰을 발행할 수도 있다 (733).

디바이스 (702) 는 DL 네트워크 토큰을 포함하는 애플리케이션 서비스 응답을 P-GW (710) 를 통해 애플리케이션 서버 (716) 로 전송함으로써 애플리케이션 서버 (716) 에 대한 DL 네트워크 토큰을 승인할 수도 있다. 디바이스 (702) 는 애플리케이션 서비스 응답 내에 DL 네트워크 토큰을 임베딩할 수도 있거나, 또는 그렇지 않을 경우에 이를 포함할 수도 있다. 접속 ID 가 디바이스 (702) 로 전송되었을 경우, 디바이스 (702) 는 또한, 애플리케이션 서비스 응답 내에 접속 ID 를 임베딩할 수도 있거나, 또는 그렇지 않을 경우에 이를 포함할 수도 있다.

접속 ID 가 유도 (726) 되었고 저장 (728) 되었을 경우, 그것에 임베딩되거나, 또는 그렇지 않을 경우에 그것에 첨부된 접속 ID 및 DL 네트워크 토큰을 가지는, 디바이스 (702) 로부터의 패킷을 수신할 때, P-GW (710) 는 접속 ID 를 검증할 수도 있다 (736). DL 네트워크 토큰은 다운링크 방향에서의 검증 및 패킷 맵핑을 위하여 이용되므로, 하나의 양태에서, P-GW (710) 는 이 때에 DL 네트워크 토큰을 검증하지 않을 수도 있지만; 그러나, 기재된 바와 같이, P-GW (710) 는 접속 ID 를 검증할 수도 있다 (736).

접속 ID 의 검증은 예를 들어, 원래의 접속 ID 를 유도하는 것과 관련하여 위에서 설명된 것과 동일한 공식을 이용하여 패킷 내에 포함된 데이터로부터 원래의 접속 ID 를 재유도함으로써 달성될 수도 있다. 즉, P-GW (710) 는 애플리케이션 서버 (716) 로부터 수신된 데이터 대신에, 디바이스 (702) 로부터 수신된 패킷으로부터의 데이터로 원래의 접속 ID 를 재유도할 수도 있다. 당해 분야의 당업자들에 의해 이해되는 바와 같이, 디바이스 (702) 로부터 수신된 패킷에서의 데이터의 전부가 애플리케이션 서버 (716) 로부터 수신된 패킷에서의 데이터와 동일하지는 않을 것이다. 그러나, 당해 분야의 당업자에 의해 또한 이해되는 바와 같이, 하나의 양태에서, 디바이스 (702) 로부터 수신된 패킷 및 애플리케이션 서버 (716) 로부터 수신된 패킷의 양자 내에 포함된 오직 공통적인 데이터는 원래의 접속 ID (또한, 제 2 접속 ID 또는 검증 접속 ID 로서 본원에서 지칭됨) 를 재유도하기 위하여 이용될 것이다. 원래의 접속 ID 의 예시적인 유도와 관련하여 위에서 설명된 바와 같이, 이러한 공통적인 데이터는 CI, IP_C, IP_S, P_C, P_S, 및/또는 Proto 를 포함할 수도 있다. 이 리스트는 예시적이고 한정적인 것이 아니다. 이러한 양태에서, 검증은 재유도된 접속 ID 를, 디바이스 (702) 로부터 수신된 패킷 내에 임베딩된 접속 ID 와 비교함으로써 달성될 수도 있다.

검증이 성공적이었을 경우, 또는 접속 ID 를 검증하는 임의적인 단계가 수행되지 않았을 경우, 디바이스 (702) 로부터의 애플리케이션 서비스 응답은 애플리케이션 서버 (716) 로 전송될 수도 있다 (738). 하나의 양태에서, P-GW (710) 는 애플리케이션 서비스 응답과 함께 DL 네트워크 토큰을 임베딩할 수도 있거나, 임베딩된 상태로 둘 수도 있거나, 또는 그렇지 않을 경우에 첨부할 수도 있거나 포함할 수도 있다. 이러한 방식으로, 애플리케이션 서버 (716) 에는 DL 네트워크 토큰이 제공된다. 접속 ID 의 임의적인 유효성확인이 성공적이지 않았을 경우, P-GW (710) 는 애플리케이션 서비스 응답을 폐기할 수도 있다 (도시되지 않음).

그 후에, 애플리케이션 서버 (716) 는 P-GW (710) 를 통해 애플리케이션 서버 (716) 로부터 디바이스 (702) 로 전송된 (740) (DL 네트워크 토큰이 유도되었던 통신 세션에 관련된) 각각의 패킷 내에 DL 네트워크 토큰의 복사본을 임베딩할 수도 있다. P-GW (710) 는 DL 네트워크 토큰을 이용하여 데이터 패킷을 검증할 수도 있다 (742). 검증이 성공적일 경우, P-GW (710) 는 데이터 패킷을 디바이스 (702) 로 전송할 수도 있다 (744). 검증이 성공적이지 않을 경우, P-GW (710) 는 데이터 패킷을 폐기할 수도 있다 (도시되지 않음).

도 8 은 본원에서 설명된 양태들에 따라 하나 이상의 사용자-평면 메시지들과 관련하여 2 개의 네트워크 토큰들 (예컨대, 업링크 네트워크 토큰 및 다운링크 네트워크 토큰) 의 유도, 프로비저닝, 및 이용을 예시하는 예시적인 호출 흐름 (800) 이다. 도 8 의 호출 흐름 (800) 은 사용자-평면에서 구현될 수도 있다. 다음의 설명은 업링크 및 다운링크 토큰들의 양자의 유도, 프로비저닝, 및 집행에 관한 것이다.

도 8 은 디바이스 (802) (예컨대, 칩 컴포넌트, 클라이언트 디바이스), 액세스 노드 (804) (예컨대, eNB), MME (806), S-GW (808), P-GW (810), 정책 및 과금 규칙들 기능 (PCRF) (812) 디바이스, 홈 가입자 서버 (HSS) (814), 및 애플리케이션 서버 (816) 의 표현들을 포함한다.

도 8 의 예시적인 호출 흐름에서, 디바이스 (802) 는 접속 요청을 애플리케이션 서버 (816) 로 전송할 수도 있다 (818). 접속 요청은 애플리케이션 식별자 (App ID) 와 같은 식별자를 포함할 수도 있다. 접속 요청은 P-GW (810) 로 코어 네트워크를 통과할 수도 있다. P-GW (810) 는 정책 집행을 위한 게이트웨이일 수도 있다. P-GW (810) 는 또한, 네트워크 토큰에 대한 명백한 또는 묵시적 요청을 검출하기 위하여 이용될 수도 있다.

하나의 양태에 따르면, 액세스 노드 (804) (예컨대, eNodeB) 는 애그노스틱일 수도 있다. 즉, 액세스 노드 (804) 는 디바이스가 사용자-평면에서의 접속 요청을 애플리케이션 서버 (816) 로 전송하였다는 것을 알지 못할 수도 있고, 여기서, 접속 요청은 네트워크 토큰에 대한 요청을 명백히 포함하거나, 또는 네트워크 토큰에 대한 묵시적 요청을 표현한다. 이러한 양태에 따르면, 네트워크 토큰들의 요청 및 교환은 애그노스틱 액세스 노드 (804) 에 인식되지 못할 수도 있다.

결정은 디바이스로부터 전송된 접속 요청을 포함하는 패킷이 네트워크 토큰에 대한 명백한 요청을 포함하거나, 네트워크 토큰에 대한 묵시적 요청을 표현하는지 여부에 대하여, P-GW (810) 에서 행해질 수도 있다. 결정이 네트워크 토큰에 대한 필요성이 존재하는 것으로 결론내릴 경우, P-GW (810) 는 UL 네트워크 토큰 및 DL 네트워크 토큰을 유도하기 위하여 요구된 정보를 획득하는 것; UL 및 DL 네트워크 토큰들을 유도하는 것; 및 디바이스 (802) 로부터의 접속 요청을 포함하였던 패킷과 함께 UL 및 DL 네트워크 토큰들을 임베딩/포함하는 것을 포함하는 액션들을 수행할 수도 있다. 본원에서 이용된 바와 같이, 용어 "유도" 는 또 다른 디바이스로부터 획득하거나 또는 로컬적으로 유도하는 것을 의미할 수도 있다.

하나의 양태에 따르면, P-GW (810) 는 패킷과 연관된 입력 파라미터들의 해시 (hash) 에 기초하여 UL 네트워크 토큰을 유도할 수도 있다 (822). 이러한 패킷에서는, 패킷에 관련되는 추가적인 정보를 획득할 필요성이 없을 수도 있다. 추가적인 정보가 필요하게 될 경우, 하나의 양태에 따르면, P-GW (810) 는 PCRF (812) 로부터 디바이스 (802) 의 프로파일을 획득할 수도 있다 (820). PCRF (812) 는 PCRF (812) 에 결합된 가입 프로파일 저장소 (SPR) 로부터 디바이스의 가입 프로파일을 획득할 수도 있다. 디바이스 (802) 의 프로파일을 획득하는 다른 방법들이 허용가능할 수도 있다. 유사한 방식으로, P-GW (810) 는 DL 네트워크 토큰을 유도할 수도 있다 (823).

P-GW (810) 는 접속 요청을 포함하였던 패킷과 함께 UL 및 DL 네트워크 토큰들을 임베딩/포함할 수도 있다 (824). 그 다음으로, P-GW (810) 는 P-GW (810) 에 의해 유도된 UL 및 DL 네트워크 토큰들을 포함하는 접속 요청을 애플리케이션 서버 (816) 로 전송할 수도 있다 (826). 접속 요청은 애플리케이션 식별자 (App ID) 를 포함할 수도 있다.

그 다음으로, 애플리케이션 서버 (816) 는 접속 응답을 P-GW (810) 를 통해 디바이스 (802) 로 전송할 수도 있다 (828). 접속 응답은 UL 네트워크 토큰을 포함할 수도 있고, 또한, DL 네트워크 토큰을 포함할 수도 있다. DL 네트워크 토큰이 접속 응답과 함께 포함될 경우, P-GW (810) 는 접속 응답과 함께 포함된 DL 네트워크 토큰을 검증할 수도 있다 (830). 하나의 양태에 따르면, 검증은 원래의 DL 네트워크 토큰의 복제본을 유도하는 것 (즉, DL 검증 토큰을 유도함), 및 재유도된 원래의 DL 토큰을, 접속 응답 내에/그것과 함께 임베딩된/포함된 DL 네트워크 토큰과 비교하는 것에 의한 것일 수도 있다. 검증이 성공적일 경우, P-GW (810) 는 DL 네트워크 토큰을 폐기할 수 있고, 접속 응답을 UL 네트워크 토큰과 함께 디바이스 (902) 로 전송할 수도 있다 (832). 검증이 성공적이지 않을 경우, P-GW (810) 는 접속 요청 및 임베딩/포함된 DL 네트워크 토큰 및 UL 네트워크 토큰을 폐기할 수도 있다. 그 후에, 디바이스 (802) 는 애플리케이션 서버 (816) 로의 데이터 송신을 위하여 구성된 하나 이상의 업링크 데이터 패킷들과 함께 UL 네트워크 토큰을 포함할 수도 있다 (834). 일부 양태들에서, 디바이스 (802) 는 애플리케이션 서버 (816) 에 대하여 예정된 매 업링크 데이터 패킷과 함께 UL 네트워크 토큰을 포함할 수도 있다 (834).

애플리케이션 서버 (816) 는 DL 네트워크 토큰 (예컨대, DL 네트워크 토큰의 복사본) 을 보유할 수도 있다. 그 후에, 애플리케이션 서버 (816) 는 디바이스 (802) 로의 데이터 송신을 위하여 구성된 하나 이상의 다운링크 데이터 패킷들과 함께 DL 네트워크 토큰을 전송할 수도 있다 (840). 일부 양태들에서, 애플리케이션 서버 (816) 는 디바이스 (802) 에 대하여 예정된 매 다운링크 데이터 패킷과 함께 DL 네트워크 토큰을 포함할 수도 있다.

업링크 방향에서의 집행에 대하여, 디바이스 (802) 는 업링크 데이터 패킷을 P-GW (810) 를 통해 애플리케이션 서버 (816) 로 전송할 수도 있다 (834). 업링크 데이터 패킷은 UL 네트워크 토큰을 포함할 수도 있다. UL 네트워크 토큰을 포함하는 업링크 데이터 패킷은 P-GW (810) 로 코어 네트워크를 통과할 수도 있다. 기재된 바와 같이, P-GW (810) 는 정책 집행을 위한 게이트웨이일 수도 있다.

P-GW (810) 가 디바이스 (802) 로부터 전송된 UL 데이터 패킷을 수신할 때, P-GW (810) 는 업링크 데이터 패킷과 함께 포함된 UL 네트워크 토큰을 검증할 수도 있다 (836). 하나의 양태에 따르면, 검증은 토큰을 재유도하는 것 (즉, UL 검증 네트워크 토큰을 유도함) 과, 재유도된 토큰을, 업링크 데이터 패킷과 함께 임베딩된 네트워크 토큰과 비교하는 것에 의한 것일 수도 있다. 검증이 성공적일 경우, P-GW (810) 는 임베딩된 네트워크 토큰을 폐기할 수 있고, 업링크 데이터 패킷을 애플리케이션 서버 (816) 로 전송할 수도 있다 (838). 검증이 성공적이지 않을 경우, P-GW 는 업링크 데이터 패킷 및 임베딩된 UL 네트워크 토큰을 폐기할 수도 있다.

다운링크 방향에서의 집행에 대하여, 애플리케이션 서버 (816) 는 다운링크 데이터 패킷을 P-GW (810) 를 통해 디바이스 (802) 로 전송할 수도 있다 (840). 다운링크 데이터 패킷은 패킷이 지향되는 디바이스를 나타내기 위하여 디바이스 ID 를 포함할 수도 있다. 다운링크 데이터 패킷은 DL 네트워크 토큰을 포함할 수도 있다. DL 네트워크 토큰은 디바이스 (802) 로부터 명시적으로 또는 묵시적으로 수신된 다운링크 토큰들의 이용에 대한 요청에 응답하여 P-GW (810) 에 의해 유도되었을 수도 있다. P-GW (810) 는 DL 네트워크 토큰을 사용자-평면에서 애플리케이션 서버 (816) 에 프로비저닝하였을 수도 있다. P-GW (810) 는 다운링크 데이터 패킷과 함께 포함된 DL 네트워크 토큰을 검증할 수도 있다 (842). 하나의 양태에 따르면, 검증은 원래의 DL 네트워크 토큰의 복제본을 유도하는 것 (즉, DL 검증 토큰을 유도함), 및 재유도된 원래의 DL 토큰을, 다운링크 데이터 패킷과 함께 임베딩된 DL 네트워크 토큰과 비교하는 것에 의한 것일 수도 있다. 검증이 성공적일 경우, P-GW (810) 는 임베딩된 DL 네트워크 토큰을 폐기할 수 있고, 다운링크 데이터 패킷을 디바이스 (802) 로 전송할 수도 있다 (844). 검증이 성공적이지 않을 경우, P-GW 는 다운링크 데이터 패킷 및 임베딩된 DL 네트워크 토큰을 폐기할 수도 있다.

이 양태에서, P-GW (810) 는 다운링크 방향에서 뿐만 아니라, 업링크 방향에서도 IP 흐름들을 효율적으로 지향시킬 수 있을 수도 있다. P-GW (810) 가 원래의 DL 네트워크 토큰을 유도하였으므로, P-GW (810) 는 애플리케이션 서버 (816) 로부터 패킷들과 함께 수신된 DL 네트워크 토큰의 유효성을 확인할 수 있을 수도 있다. 이것은 유용할 수도 있고, TFT/SDF 를 이용하는 다운링크 패킷 검사에 대한 효율적인 대안일 수도 있다.

예를 들어, P-GW (810) 에 알려진 비밀 키는 원래의 DL 네트워크 토큰 및 검증 DL 네트워크 토큰을 유도하기 위하여 암호 함수에서 이용될 수도 있다. 하나의 예에서, P-GW (810) 는 애플리케이션 기능부 (AF) 로부터 취출된 애플리케이션 액세스 정책을 고려하여 네트워크 토큰을 유도할 수도 있다. 하나의 양태에서, 액세스 정책은 흐름을 애플리케이션에 연관시킬 수도 있다. 네트워크 토큰은 App ID 또는 디바이스 ID 를 고려하여 추가로 유도될 수도 있다. 일부 양태들에서, DL 네트워크 토큰은 암호화된 정보를 포함할 수도 있다. 복호화는 하나의 예에서, P-GW (810) 에 알려진 비밀 키를 그 입력으로서 가지는 암호 함수를 이용하여 달성될 수도 있다. 예로서, DL 네트워크 토큰의 성공적인 복호화는 DL 네트워크 토큰을 포함하였던 DL 패킷과 연관시켜서, DL 패킷이 예정되는 디바이스 및/또는 액세스 노드의 목적지 어드레스 또는 목적지 어드레스 프리픽스를 표시할 수도 있는 값을 산출할 수도 있다. 하나의 양태에서, 예를 들어, DL 네트워크 토큰으로부터 디바이스 어드레스를 획득하기 위한 능력은 DL 네트워크 토큰과 연관된 패킷이 그 목적지로 전송되도록 인가된다는 것을 의미할 수도 있고, 패킷 검사가 필요하지 않다는 것을 추가로 의미할 수도 있다. 패킷 검사는 이에 따라 회피될 수도 있다.

네트워크 토큰들, DL 네트워크 토큰들 및 UL 네트워크 토큰들의 양자는 오직 어떤 조건들 하에서 유효할 수도 있다. 예를 들어, 일부 양태들에서, 네트워크 토큰들은 주기적으로 변경될 수도 있다. 또 다른 양태에서, 네트워크 토큰은 네트워크 토큰의 유도 이후의 미리 결정된 시간에 기초하여 만료될 수도 있다. 네트워크 토큰은 미리 결정된 시간의 만료 시에 유효한 것을 중단시킬 수도 있다. 일부 양태들에서, 네트워크 토큰은 네트워크 토큰을 유도하기 위하여 이용된 키 (K_P _-GW) 에 두어진 제한들에 기초하여 만료될 수도 있다. 예를 들어, 네트워크 토큰을 유도하기 위하여 이용된 키는 새로운 키 (K''_P _-GW) 에 의해 대체될 수도 있다. 새롭고 상이한 키 (예컨대, K''_P-GW) 로 기존 키 (예컨대, K'_P-GW) 를 교체하는 것은 예를 들어, 기존 키, 키 식별자, 또는 일부 다른 이벤트의 미리 결정된 타이밍된 만료로 인한 것일 수도 있다. 기존 네트워크 토큰이 더 이상 유효하지 않거나, 또는 네트워크 토큰으로서의 이용을 위하여 더 이상 희망되지 않는 것으로 결정될 때, P-GW 는 현재 이용된 네트워크 토큰을 교체하기 위하여 새로운 네트워크 토큰을 유도할 수도 있다.

새로운 네트워크 토큰을 유도하기 위한 판단은 예를 들어, P-GW 에 달려 있을 수도 있다. 그러나, 판단은 다른 엔티티들에 의해 행해질 수도 있다. 예를 들어, 하나의 양태에서, 디바이스는 새로운 네트워크 토큰이 필요한 것으로 결정할 수도 있다. 또 다른 양태에서, 애플리케이션 서버는 새로운 네트워크 토큰이 필요한 것으로 결정할 수도 있다. 일부 양태들에서는, 현재 이용된 네트워크 토큰이 유효하더라도, 네트워크 토큰의 이용을 개시하였던 엔티티와 상이한 엔티티가 새로운 네트워크 토큰의 이용을 개시할 수도 있다. 임의의 양태에서, 새로운 네트워크 토큰 설정은 본원에서 설명된 바와 같이 선행할 수도 있다. 당해 분야의 당업자들은 새로운 네트워크 토큰이 기존 네트워크 토큰과 동일하지 않도록, (네트워크 토큰을 유도하기 위하여 이용된 복수의 파라미터들 중에서) 적어도 하나의 파라미터가 변경되도록 요구될 수도 있다는 것을 이해할 것이다.

하나의 양태에서, 네트워크 토큰을 유도하는 것은 디바이스와 연관된 애플리케이션 식별자 (App ID) 및 애플리케이션 액세스 정책을 검증하는 것을 포함할 수도 있다. App ID 는 이전에 수신된 패킷 내에 포함될 수도 있고, 여기서, 이전에 수신된 패킷은 네트워크 토큰을 유도하기 위하여 이용되었다. App ID 는 애플리케이션 액세스 정책을 결정하기 위하여 이용될 수도 있다. 애플리케이션 액세스 정책은 애플리케이션 서버로부터 취출될 수도 있다. 하나의 양태에서, 애플리케이션 액세스 정책은 애플리케이션 서버의 애플리케이션 기능부 (AF) 로부터 취출될 수도 있다. 또 다른 양태에서, 애플리케이션 액세스 정책은 애플리케이션 서버에서의 가입자 프로파일 저장소 (SPR) 로부터 취출될 수도 있다. 하나의 양태에서, 애플리케이션 액세스 정책은 서비스 우선순위, 최대 대역폭, 보장된 대역폭, 및/또는 최대 지연을 포함하는 서비스 품질 (QoS) 파라미터들을 포함할 수도 있다.

토큰 이용/집행 - 예시적인 시스템 레벨 프로토콜 스택들

위에서 설명된 네트워크 토큰들과 관련된 이용 및 집행의 양태들이 이제 제시될 것이다.

네트워크 토큰들의 이용은 클라이언트 디바이스, 액세스 노드, 게이트웨이 디바이스, 및 애플리케이션 서버의 사용자-평면 프로토콜 스택들 중에서의 네트워크 토큰들의 이동에 대하여 설명될 수도 있다. 본원에서 예시된 것은 사용자-평면 프로토콜 스택들의 예시적인 세트들을 예시하는 2 개의 도면들이다. 각각의 도면은 프로토콜 스택들 중에서의 네트워크 토큰 이동의 그 도시에서의 다음 것과 상이하다. 프로토콜 스택들에서 표현된 계층들의 다수 및 계층들 중에서의 상호접속들은 잘 알려져 있다. 이 계층들은 도 5 의 예시도에 대하여 간략하게 설명될 것이다. 그 설명들은 반복을 회피하고 출원의 간결함을 개선시키기 위하여 각각의 예시적인 도면에 대하여 반복되지 않을 것이다. 도면들 중의 하나는 심 계층 (shim layer) 을 포함하고, 심 계층은 그것에 예시된 개개의 양태들과 관련하여 네트워크 토큰들의 이동에 대하여 사용된 계층으로서 고려될 수도 있다.

도 9 는 본원에서 설명된 하나의 양태에 따른, 시스템의 사용자-평면 프로토콜 스택들 (900) 의 예시적인 예시도이다. 도 9 는 클라이언트 디바이스 (902), 액세스 노드 (904), 게이트웨이 디바이스 (906), 및 애플리케이션 서버 (908) 를 도시한다. 도 9 에서의 예시적인 예시도에서, 클라이언트 디바이스 (902) 의 프로토콜 스택은 최저 계층으로부터 상방으로, 물리적 (PHY) 계층 (910), 매체 액세스 제어 (medium access control; MAC) 계층 (912), 라디오 링크 제어 (radio link control; RLC) 계층 (914), 패킷 데이터 컨버전스 프로토콜 (PDCP) 계층 (916), 및 인터넷 프로토콜 (IP) 계층 (918) 을 포함할 수도 있다. 하나의 양태에서, 네트워크 토큰은 인터넷 프로토콜 (IP) 버전 6 (IPv6) 에서 정의된 IP 확장 헤더에서 반송될 수 있다.

하나의 양태에서, 심 계층 (920) 은 클라이언트 디바이스 (902) 의 사용자-평면 프로토콜 스택에 추가될 수도 있고, 대응하는 심 계층 (922) 은 게이트웨이 디바이스 (906) 의 프로토콜 스택에 추가될 수도 있다. 심 계층 (920) 및 대응하는 심 계층 (922) 은 본원에서 설명된 양태들에 따라, 클라이언트 디바이스 (902) 로부터 게이트웨이 디바이스 (906) 로의 네트워크 토큰들의 이동을 가능하게 한다. 하나의 양태에서, 심 계층 (920) 은 클라이언트 디바이스 (902) 의 IP 계층 (918) 아래에, 그리고 MAC 계층 (912) 위에 놓여 있다. 이 양태에서, 대응하는 심 계층 (922) 은 게이트웨이 디바이스 (906) 의 IP 계층 (924) 아래에, 그리고 사용자-평면에 대한 일반 패킷 라디오 서비스 (GPRS) 터널링 프로토콜 (GTP) 계층 (GTP-U) 위에 놓여 있다. 당해 분야의 당업자들에게 알려진 바와 같이, GTP-U 는 GPRS 백본 네트워크에서 사용자 데이터 패킷들을 반송하기 위한 서비스들을 제공한다.

도 9 에 의해 예시된 양태는 액세스 노드 (904) 에 의한 임의의 프로세싱에 대한 필요성 없이, 클라이언트 디바이스 (902) 로부터 게이트웨이 디바이스 (906) 로의 네트워크 토큰 (960) 의 이동을 위하여 유용할 수도 있다. 대안적인 방법들이 허용가능하다. 예로서, 클라이언트 디바이스 (902) 는 위에서 설명된 바와 같이, 사용자-평면 메시징을 통해 애플리케이션 서버 (908) 로부터 네트워크 토큰 (960) 을 수신할 수도 있다. 네트워크 토큰의 이용의 하나의 양태에 따르면, 클라이언트 디바이스 (902) 는 애플리케이션 서버 (908) 에 대하여 예정된 패킷들 내에 네트워크 토큰을 포함할 수도 있다. 네트워크 토큰 (960) 은 도 9 에서 도시된 바와 같이, 게이트웨이 디바이스 (906) 로의 심 계층 (920) 의 심 헤더에서 반송될 수도 있다. 네트워크 토큰 (960) 은 IP 헤더로부터 분리된 심 헤더에서 반송될 수도 있다.

게이트웨이 디바이스 (906) 에서의 네트워크 토큰의 검증이 성공적일 경우, 게이트웨이 디바이스 (906) 는 네트워크 토큰을 폐기한 후에 패킷을 애플리케이션 서버 (908) 로 포워딩할 수도 있다. 게이트웨이 디바이스 (906) 에서의 네트워크 토큰 (960) 의 검증이 성공적이지 않을 경우, 게이트웨이 디바이스 (906) 는 패킷 및 네트워크 토큰을 폐기할 수도 있다. 예시된 양태에 따르면, 네트워크 토큰 기반 애플리케이션 액세스를 지원하기 위하여, 애플리케이션 서버 (908) 에서 변경이 필요하지 않을 것이다.

설명의 완전성을 위하여, 액세스 노드 (904), 게이트웨이 디바이스 (906), 및 애플리케이션 서버 (908) 의 사용자-평면 프로토콜 스택들의 계층들이 이제 간략하게 설명될 것이다. 도 9 의 예시적인 예시도에서, 액세스 노드 (904) 의 프로토콜 스택은 최저 계층으로부터 상방으로, 클라이언트 디바이스 (902) 의 유사하게 거명된 계층들 (910, 912, 914, 및 916) 과 각각 결합하는, 물리적 (PHY) 계층 (930), 매체 액세스 제어 (MAC) 계층 (932), 라디오 링크 제어 (RLC) 계층 (934), 및 패킷 데이터 컨버전스 프로토콜 (PDCP) 계층 (936) 을 포함할 수도 있다. 도 9 의 예시적인 예시도에서, 액세스 노드 (904) 의 프로토콜 스택은 최저 계층으로부터 상방으로, 이더넷 계층 (940), MAC 계층 (942), IP 계층 (944), 사용자 데이터그램 프로토콜 (user datagram protocol; UDP) 계층 (946), 및 GTP-U 계층 (948) 을 추가적으로 포함할 수도 있다. 이 개개의 계층들은 게이트웨이 디바이스 (906) 의 유사하게 거명된 계층들 (1250, 952, 954, 956, 및 926) 과 함께한다. 도 9 의 예시적인 예시도에서, 클라이언트 디바이스 IP 계층 (918) 은 게이트웨이 디바이스 (906) 의 IP 계층 (924) 과 결합하는 반면, 게이트웨이 디바이스 (906) 의 IP 계층 (924) 은 애플리케이션 서버 (908) 의 IP 계층 (958) 과 함께한다.

도 10 은 본원에서 설명된 또 다른 양태에 따른, 시스템의 사용자-평면 프로토콜 스택들 (1000) 의 예시적인 예시도이다. 도 10 은 클라이언트 디바이스 (1002), 액세스 노드 (1004), 게이트웨이 디바이스 (1006), 및 애플리케이션 서버 (1008) 를 도시한다.

도 10 에 의해 예시된 양태는 액세스 노드 (1004) 를 통한 클라이언트 디바이스 (1002) 로부터 게이트웨이 디바이스 (1006) 로의 네트워크 토큰 (1060) 의 이동을 위하여 유용할 수도 있다. 이 양태에서는, 심 계층이 요구되지 않는다. 예로서, 클라이언트 디바이스 (1002) 는 위에서 설명된 바와 같이, 사용자-평면 메시징을 통해 애플리케이션 서버 (1008) 로부터 네트워크 토큰 (1060) 을 수신할 수도 있다. 네트워크 토큰의 이용의 하나의 양태에 따르면, 클라이언트 디바이스 (1002) 는 애플리케이션 서버 (1008) 에 대하여 예정된 패킷들 내에 네트워크 토큰 (1060) 을 포함할 수도 있다. 네트워크 토큰 (1060) 을 포함하는 패킷은 클라이언트 디바이스 (1002) 로부터 액세스 노드 (1004) 의 PDCP 계층 (1036) 으로 PDCP 계층 (1016) 헤더에서 반송될 수도 있다. 액세스 노드 (1004) 는 PDCP 헤더에서 발견된 네트워크 토큰을 GTP-U 헤더로 복사할 수도 있다. 그 다음으로, 네트워크 토큰 (1060) 을 포함하는 패킷은 액세스 노드 (1004) 로부터 게이트웨이 디바이스 (1006) 의 GTP-U 계층 (1026) 으로 GTP-U 계층 (1048) 헤더에서 반송될 수도 있다. 즉, 하나의 양태에서, 네트워크 토큰은 일반 패킷 라디오 서비스 (GPRS) 터널링 프로토콜 (GTP) 헤더에서 반송될 수도 있다. 하나의 예시적인 양태에서, 애플리케이션 서버 (1008) 로부터 클라이언트 디바이스 (1002) 로 원래 전송된 네트워크 토큰은 게이트웨이 디바이스에 알려진 비밀 키를 이용하여 게이트웨이 디바이스 (1006) 에서 생성되었을 수도 있다. 이러한 양태에서, 액세스 노드 (1004) 는 (그것이 검증을 위하여 필요한 비밀 키를 소유하지 않을 것이므로) 네트워크 토큰을 검증할 수 없을 것이다. 따라서, 도 10 의 예시도에서의 액세스 노드 (1004) 의 예시적인 목적은 네트워크 토큰을 하나의 헤더로부터 또 다른 것으로 복사함으로써, 네트워크 토큰을 이미 기존 PDCP 계층 (1036) 헤더 및 GTP-U 계층 (1048) 헤더를 통해 클라이언트 디바이스 (1002) 로부터 게이트웨이 디바이스 (1006) 로 포워딩하기 위한 것이다. 일단 네트워크 토큰이 게이트웨이 디바이스에 도달하면, 게이트웨이 디바이스 (1006) 에서의 네트워크 토큰의 검증이 성공적일 경우, 게이트웨이 디바이스 (1006) 는 네트워크 토큰을 폐기한 후에 패킷을 애플리케이션 서버 (1008) 로 포워딩할 수도 있다. 게이트웨이 디바이스 (1006) 에서의 네트워크 토큰 (1060) 의 검증이 성공적이지 않을 경우, 게이트웨이 디바이스 (1006) 는 패킷 및 네트워크 토큰을 폐기할 수도 있다. 예시된 양태에 따르면, 토큰 기반 애플리케이션 액세스를 지원하기 위하여, 애플리케이션 서버 (1008) 에서 변경이 필요하지 않을 것이다.

도 10 과 관련하여 설명되지 않았던 클라이언트 디바이스 (1002), 액세스 노드 (1004), 게이트웨이 디바이스 (1006), 및 애플리케이션 서버 (1008) 의 사용자-평면 프로토콜 스택들의 계층들은, 그 설명들이 도 9 에서의 유사하게 거명된 계층들의 그것들과 동일하거나 유사하므로 설명되지 않을 것이다.

도 11 은 본원에서 설명된 또 다른 양태에 따른, 시스템의 사용자-평면 프로토콜 스택들 (1100) 의 예시적인 예시도이다. 도 11 의 사용자-평면 프로토콜 스택들 (1100) 은 토큰 임베딩 및 전송을 위하여 IP 헤더를 이용한다. 도 11 은 클라이언트 디바이스 (1102), 액세스 노드 (1104), 게이트웨이 디바이스 (1106), 및 애플리케이션 서버 (1108) 를 도시한다. 도 11 에서의 예시적인 예시도에서, 클라이언트 디바이스 (1102) 의 프로토콜 스택은 최저 계층으로부터 상방으로, 물리적 (PHY) 계층 (1110), 매체 액세스 제어 (MAC) 계층 (1112), 라디오 링크 제어 (RLC) 계층 (1114), 패킷 데이터 컨버전스 프로토콜 (PDCP) 계층 (1116), 및 인터넷 프로토콜 (IP) 계층 (1118) 을 포함할 수도 있다.

하나의 양태에서, IP 계층 (1118) 의 헤더는 본원에서 설명된 양태들에 따라, 클라이언트 디바이스 (1102), 게이트웨이 디바이스 (1106), 및 애플리케이션 서버 (1108) 사이의 네트워크 토큰들의 이동을 가능하게 할 수도 있다. IPv4 및 IPv6 는 본원에서 설명된 양태들을 양자 모두 채용할 수도 있다.

도 11 에 의해 예시된 양태는 액세스 노드 (1104) 에 의한 임의의 프로세싱에 대한 필요성 없이, 게이트웨이 디바이스 (1106) 와 클라이언트 디바이스 (1102) 사이의 다운링크 네트워크 토큰 (1160) 의 이동을 위하여 유용할 수도 있다. 예로서, 집행 동작들 동안에, 클라이언트 디바이스 (1102) 는 하나 이상의 사용자-평면 메시지들에서 게이트웨이 디바이스 (1106) 를 통해 애플리케이션 서버 (1108) 로부터 다운링크 네트워크 토큰 (1160) 을 수신할 수도 있다. 다운링크 네트워크 토큰의 이용의 하나의 양태에 따르면, 애플리케이션 서버 (1108) 는 클라이언트 디바이스 (1102) 에 대하여 예정된 패킷들에서 주어진 다운링크 네트워크 토큰의 복사본을 포함할 수도 있다. IP 계층 (1118, 1124, 1158) 에서의 IP 헤더는 도 11 에서 도시된 바와 같이 (예컨대, 다운링크 패킷 내에 임베딩된) 다운링크 네트워크 토큰 (1160) 을 게이트웨이 디바이스 (1106) 로 반송할 수도 있다. 게이트웨이 디바이스 (1106) 에서의 다운링크 네트워크 토큰의 검증이 성공적일 경우, 게이트웨이 디바이스 (1106) 는 패킷을 클라이언트 디바이스 (1102) 로 포워딩할 수도 있다. 게이트웨이 디바이스 (1106) 는 검증된 다운링크 네트워크 토큰을 포함하였던 패킷을 포워딩하기 전에, 네트워크 토큰을 폐기할 수도 있거나 폐기하지 않을 수도 있다. 게이트웨이 디바이스 (1106) 에서의 다운링크 네트워크 토큰 (1160) 의 검증이 성공적이지 않을 경우, 게이트웨이 디바이스 (1106) 는 패킷 및 네트워크 토큰을 폐기할 수도 있다. 예시된 양태에 따르면, DL 토큰 기반 정책 집행 프로토콜을 지원하기 위하여, 애플리케이션 서버 (1108) 에서 변경이 필요하지 않을 것이다.

DL 토큰들을 포함하는 패킷들의 전달에 관하여, 하나의 양태에서, DL 토큰은 IP 버전 4 (IPv4) 헤더 또는 IP 버전 6 (IPv6) 헤더와 같은 IP 헤더 내에 임베딩될 수도 있다. IPv4 에서의 IP 헤더는 IPv4 옵션들 필드일 수도 있다. IP 옵션들 필드에 관하여, 새로운 옵션 번호는 예시적인 IPv4 옵션들 필드의 이용을 위하여 인터넷 공학 태스크 포스 (Internet Engineering Task Force; IETF) 에서 정의될 필요가 있을 수도 있다. IPv6 에서의 IP 헤더는 IP 확장 헤더일 수도 있다. IP 확장 헤더에 관하여, 다음 헤더 코드와 같은 코드는 예시적인 IPv6 확장 헤더의 이용을 위하여 인터넷 공학 태스크 포스 (IETF) 에서 정의될 필요가 있을 수도 있다. 하나의 양태에서, DL 토큰은 송신 제어 프로토콜 (Transmission Control Protocol; TCP) 헤더 내에 임베딩될 수도 있다. DL 토큰은 TCP 헤더의 옵션들 필드 내에 임베딩될 수도 있다. 하나의 양태에서, DL 토큰은 전송 계층 보안성 (Transport Layer Security; TLS) 레코드 헤더 내에 임베딩될 수도 있다. TLS 레코드에 관하여, 새로운 레코드 타입은 예시적인 TLS 레코드 프로토콜에 대한 인터넷 공학 태스크 포스 (IETF) 에서 정의될 필요가 있을 수도 있다. 하나의 양태에서, DL 토큰은 IP 헤더와 송신 제어 프로토콜/사용자 데이터그램 프로토콜 (TCP/UDP) 헤더 사이의 심 헤더 내에 임베딩될 수도 있다. 또 다른 양태에서, DL 토큰은 하이퍼텍스트 전송 프로토콜 (Hypertext Transfer Protocol; HTTP) 헤더 내에 임베딩될 수도 있다. HTTP 헤더는 HTTP 실험적 (eXperimental) 또는 확장 (eXtension) 헤더일 수도 있다. HTTP 실험적 또는 확장 헤더는 비보안 HTTP 접속들에 대한 X-태그를 이용할 수도 있다.

도 11 과 관련하여 설명되었던 클라이언트 디바이스 (1102), 액세스 노드 (1104), 게이트웨이 디바이스 (1106), 및 애플리케이션 서버 (1108) 의 프로토콜 스택들의 계층들은, 그 설명들이 도 9 에서의 유사하게 거명된 계층들의 그것들과 동일하거나 유사하므로 설명되지 않을 것이다.

도 12 는 본원에서 설명된 또 다른 양태에 따른, 시스템의 사용자-평면 프로토콜 스택들 (1200) 의 예시적인 예시도이다. 도 12 의 사용자-평면 프로토콜 스택들 (1200) 에서, 심 계층들 (1220, 1222, 1223) 은 네트워크 토큰 전송을 위하여 추가되었다. 도 12 는 클라이언트 디바이스 (1202), 액세스 노드 (1204), 게이트웨이 디바이스 (1206), 및 애플리케이션 서버 (1208) 를 도시한다.

도 12 에 의해 예시된 양태는 게이트웨이 디바이스 (1206) 를 통한 애플리케이션 서버 (1208) 로부터 클라이언트 디바이스 (1202) 를 향한 다운링크 네트워크 토큰 (1260) 의 이동을 위하여 유용할 수도 있다. 일부 양태들에서, 다운링크 네트워크 토큰은 애플리케이션 서버 (1208) 로부터 게이트웨이 디바이스 (1206) 로 전송될 수도 있지만, 클라이언트 디바이스 (1202) 로 전송되지 않을 수도 있다. 예로서, 애플리케이션 서버 (1208) 는 사용자-평면 메시징을 통해 게이트웨이 디바이스 (1206) 로부터 다운링크 네트워크 토큰 (1260) 을 수신할 수도 있다.

예시적인 예시도 도 12 에서, 클라이언트 디바이스 (1202) 의 프로토콜 스택은 최저 계층으로부터 상방으로, 물리적 (PHY) 계층 (1210), 매체 액세스 제어 (MAC) 계층 (1212), 라디오 링크 제어 (RLC) 계층 (1214), 패킷 데이터 컨버전스 프로토콜 (PDCP) 계층 (1216), 인터넷 프로토콜 (IP) 계층 (1218), 및 심 계층 (1220) 을 포함할 수도 있다.

하나의 양태에서, 심 계층 (1220) 은 클라이언트 디바이스 (1202) 의 프로토콜 스택에 추가될 수도 있고, 대응하는 심 계층 (1222) 은 게이트웨이 디바이스 (1206) 의 프로토콜 스택에 추가될 수도 있고, 또 다른 대응하는 심 계층 (1223) 은 애플리케이션 서버 (1208) 의 프로토콜 스택에 추가될 수도 있다. 심 계층 (1220), 대응하는 심 계층 (1222), 및 대응하는 심 계층 (1223) 은 본원에서 설명된 양태들에 따라, 클라이언트 디바이스 (1202), 게이트웨이 디바이스 (1206), 및 애플리케이션 서버 (1208) 사이의 네트워크 토큰들의 이동을 가능하게 할 수도 있다. 하나의 양태에서, 심 계층 (1220) 은 클라이언트 디바이스 (1202) 의 IP 계층 (1218) 위에 놓여 있다. 이 양태에서, 대응하는 심 계층 (1222) 은 게이트웨이 디바이스 (1206) 의 IP 계층 (1224) 위에 놓여 있고, 대응하는 심 계층 (1223) 은 애플리케이션 서버 (1208) 의 IP 계층 (1258) 위에 놓여 있다.

도 12 에 의해 예시된 양태는 애플리케이션 서버 (1208) 와 게이트웨이 디바이스 (1206) 사이의 다운링크 네트워크 토큰 (1260) 의 이동을 위하여 유용할 수도 있다. 다운링크 네트워크 토큰을 클라이언트 디바이스 (1202) 로 전송하는 것이 필요할 경우, 도 12 에 의해 예시된 양태는 액세스 노드 (1204) 에 의한 임의의 프로세싱에 대한 필요성 없이 이러한 전송을 제공한다.

예로서, 집행 동작들 동안에, 게이트웨이 디바이스 (1206) 는 하나 이상의 사용자-평면 메시지들에서 애플리케이션 서버 (1208) 로부터 다운링크 네트워크 토큰을 수신할 수도 있다. 심 헤더는 다운링크 네트워크 토큰 (1260) 을 게이트웨이 디바이스 (1206) 로 반송할 수도 있다.

게이트웨이 디바이스 (1206) 에서의 다운링크 네트워크 토큰 (1260) 의 검증이 성공적일 경우, 게이트웨이 디바이스 (1206) 는 다운링크 네트워크 토큰 (1260) 과 연관된 패킷을 클라이언트 디바이스 (1202) 로 포워딩할 수도 있다. 게이트웨이 디바이스는 패킷을 클라이언트 디바이스 (1202) 로 포워딩하기 전에 다운링크 네트워크 토큰 (1260) 을 폐기할 수도 있다. 게이트웨이 디바이스 (1206) 에서의 다운링크 네트워크 토큰 (1260) 의 검증이 성공적이지 않을 경우, 게이트웨이 디바이스 (1206) 는 패킷 및 다운링크 네트워크 토큰 (1260) 을 폐기할 수도 있다.

도 12 와 관련하여 설명되지 않았던 클라이언트 디바이스 (1202), 액세스 노드 (1204), 게이트웨이 디바이스 (1206), 및 애플리케이션 서버 (1208) 의 사용자-평면 프로토콜 스택들의 계층들은, 그 설명들이 도 9 에서의 유사하게 거명된 계층들의 그것들과 동일하거나 유사하므로 설명되지 않을 것이다.

예시적인 디바이스

도 13 은 본원에서 설명된 양태들에 따라, 네트워크 토큰들을 이용하여 네트워크 정책 집행 및/또는 패킷 스티어링을 지원하도록 구성된 예시적인 디바이스 (1300) 를 예시하는 블록도이다. 본원에서 이용된 바와 같이, 용어 "디바이스" 는 칩 컴포넌트 및/또는 클라이언트 디바이스 (예컨대, 이동 디바이스, 사용자 장비, 사용자 디바이스) 와 같은 최종 사용자 디바이스를 설명할 수도 있다. 하나의 예에서, 디바이스 (1300) 는 무선 네트워크 상에서 통신하기 위한 네트워크 통신 인터페이스 회로 (1302), 네트워크 통신 인터페이스 회로 (1302) 에 결합된 프로세싱 회로 (1304), 및 프로세싱 회로 (1304) 에 결합된 메모리 디바이스 (1306) 를 포함할 수도 있다. 이 리스트는 비한정적이다.

무선 네트워크 상에서 통신하기 위한 네트워크 통신 인터페이스 회로 (1302) 는 사용자와의 입력/출력 동작들을 위한 제 1 입력/출력 모듈/회로/기능부 (1308) 를 포함할 수도 있다. 네트워크 통신 인터페이스 회로 (1302) 는 액세스 노드들과의 무선 통신을 위한 수신기/송신기 모듈/회로/기능부 (1310) 를 포함할 수도 있다. 이 리스트는 비한정적이다.

프로세싱 회로 (1304) 는 토큰 기반 애플리케이션 액세스를 지원하도록 구성되는, 하나 이상의 프로세서들, 애플리케이션 특정 프로세서들, 하드웨어 및/또는 소프트웨어 모듈들 등을 포함할 수도 있거나 구현할 수도 있다. 예를 들어, 네트워크 토큰 핸들링 모듈/회로/기능부 (1312) 는 메모리 디바이스 (1306) 내에 저장될 수도 있는, 비공유 비밀 키, 또는 공유 비밀 키에 기초하여 토큰들을 유도하도록 구성될 수도 있다. 또 다른 예로서, 네트워크 토큰 추출/임베딩 모듈/회로/기능부 (1314) 는 디바이스로부터의 업링크 패킷들로부터 네트워크 토큰들을 추출하고 및/또는 게이트웨이 디바이스로 전송된 다운링크 패킷들 내에 네트워크 토큰들을 임베딩 (포함) 하도록 구성될 수도 있다. 또 다른 예로서, 암호 유효성확인/검증 모듈/회로/기능부 (1316) 는 예를 들어, 패킷들과 함께 수신된 네트워크 토큰들을 유효성확인/검증하도록 구성될 수도 있다. 이 리스트는 비한정적이다.

메모리 디바이스 (1306) 는 네트워크 토큰 핸들링 명령들 (1320), 네트워크 토큰 추출/임베딩 명령들 (1322), 암호 유효성확인/검증 명령들 (1324), 및 공유 및 비공유 비밀 키 저장 및 명령들 (1326) 을 포함하도록 구성될 수도 있다. 이 리스트는 비한정적이다.

네트워크 통신 인터페이스 회로 (1302), 프로세싱 회로 (1304), 메모리 디바이스 (1306), 및 디바이스 (1300) 의 다른 컴포넌트들 (도시되지 않음) 사이의 통신은 통신 버스 (1334) 를 통한 것일 수도 있다.

디바이스에서 동작하는 방법들

도 14 는, 디바이스 (예컨대, 칩 컴포넌트, 클라이언트 디바이스) 는 하나 이상의 애플리케이션 서비스들과 연관된 애플리케이션 서버와 통신하기 위한 요청을 개시할 수도 있고 통신과 관련하여 네트워크 토큰들을 사용할 수도 있는 예시적인 방법 (1400) 이다. 네트워크 토큰들은 네트워크 정책 집행 및 데이터 패킷 스티어링 (예컨대, 사용자 데이터 메시지 관련된 패킷들을 스티어링함) 을 위하여 이용될 수도 있다. 네트워크 토큰들은 애플리케이션 서버와 디바이스 사이의 애플리케이션 서비스 송신들을 유효성 확인하고 맵핑하기 위하여 이용될 수도 있다. 방법 (1400) 은 디바이스에서 동작할 수도 있다. 방법 (1400) 은 디바이스가 네트워크 토큰을 이용하기 위하여 요청을 개시하는 경우에 적용할 수도 있다. 네트워크 토큰들은 업링크 (UL) 네트워크 토큰들, 다운링크 (DL) 네트워크 토큰, 또는 양자의 UL 및 DL 네트워크 토큰들일 수도 있다.

하나의 양태에서, 디바이스는 사용자-평면 메시징을 이용하여 하나 이상의 애플리케이션 서비스들과 연관된 애플리케이션 서버와의 접속을 개시할 수도 있다 (1402).

접속을 개시하는 것에 응답하여, 디바이스는 애플리케이션 서버로부터 네트워크 토큰을 획득할 수도 있다 (1404). 네트워크 토큰은 하나 이상의 흐름들의 세트에서의 제 1 흐름과 연관될 수도 있다. 네트워크 토큰은 하나 이상의 애플리케이션 서비스들의 제 1 애플리케이션 서비스와 연관될 수도 있다. 네트워크 토큰은 하나 이상의 사용자-평면 메시지들을 통해 디바이스에 프로비저닝될 수도 있다.

네트워크 토큰을 수신한 후에, 디바이스는 사용자-평면에서 디바이스로부터 애플리케이션 서버로 추후에 전송된 하나 이상의 업링크 (UL) 패킷들과 함께 네트워크 토큰을 포함할 수도 있다 (1406). 일부 양태들에 따르면, 디바이스는 사용자-평면에서 디바이스로부터 애플리케이션 서버로 추후에 전송되는 매 업링크 (UL) 패킷과 함께 네트워크 토큰을 포함할 수도 있다.

네트워크 토큰은 코어 네트워크의 게이트웨이 디바이스 (예컨대, P-GW) 에 의해 유도될 수도 있다. 즉, 일부 양태들에 따르면, 애플리케이션 서버는 네트워크 토큰을 디바이스에 제공하지만; 그러나, 애플리케이션 서버는 네트워크 토큰을 유도하지 않았다. 본원에서 설명된 양태들에 따르면, 네트워크 토큰은 게이트웨이 디바이스에 의해 유도될 수도 있고 애플리케이션 서버로 전송될 수도 있다. 이것은 사용자-평면에서 애플리케이션 서버로부터 디바이스로의 네트워크 토큰의 전달을 허용할 수도 있다. 네트워크 토큰은 패킷 내에 임베딩될 수도 있거나, 또는 그렇지 않을 경우에 그것과 함께 포함될 수도 있다. 일부 양태들에서, 네트워크 토큰은 하나 이상의 패킷들 사이에서 분산될 수도 있다.

일부 양태들에 따르면, 네트워크 토큰은 디바이스에 대하여 코어 네트워크에 의해 집행된 정책을 반영한다. 일부 양태들에 따르면, 코어 네트워크에서의 게이트웨이 디바이스는 코어 네트워크에 의해 유지된 디바이스의 디바이스 가입 프로파일 및/또는 제 1 애플리케이션 서비스의 정책에 기초하여 네트워크 토큰을 유도할 수도 있다.

디바이스 가입 프로파일은 가입 프로파일 저장소 (SPR) 내에 저장될 수도 있다. PCRF 는 SPR 과 통신할 수도 있다. 다시 말해서, PCRF 는 SPR 로부터 사용자 및/또는 디바이스의 가입 프로파일을 요청할 수도 있다. 네트워크 토큰은 가입 프로파일에 대하여 코어 네트워크에 의해 집행된 정책을 반영할 수도 있다. 예를 들어, 정책은 음성 트래픽 또는 실시간 미디어 트래픽에 대한 특정 QoS 요건을 포함할 수도 있다.

본원에서 설명된 다양한 양태들에 따르면, 접속을 개시하는 것은 접속 요청을 전송하는 것을 포함할 수도 있고, 접속 요청은 네트워크 토큰에 대한 명시적 요청을 포함할 수도 있다. 다른 양태들에 따르면, 접속을 개시하는 것은 네트워크 토큰에 대한 묵시적 요청을 표현하는 패킷을 전송하는 것을 포함할 수도 있다.

명시적 또는 묵시적의 어느 하나인, 네트워크 토큰에 대한 요청에 응답한 네트워크 토큰의 수신을 보장하기 위하여, 접속을 개시하는 프로세스는 애플리케이션 서버로부터의 확인응답을 요구하는 패킷을 전송하는 것을 포함할 수도 있고, 여기서, 확인응답은 네트워크 토큰을 디바이스로 전송한다. 그러므로, 하나의 양태에 따르면, 네트워크 토큰은 디바이스에 의해 수신된 확인응답 패킷 내에 포함될 수도 있다. 예를 들어, 패킷은 송신 제어 프로토콜 동기화 (TCP SYN) 패킷일 수도 있다. 이 양태에 따르면, 디바이스에 의해 수신된 네트워크 토큰은 디바이스에 의해 수신된 TCP SYN 확인응답 (ACK) 패킷 내에 포함될 수도 있다.

네트워크 토큰에 대한 묵시적 요청은 몇몇 방법들로 인식될 수도 있다. 하나의 양태에 따르면, 묵시적 요청은 예를 들어, 네트워크 토큰들 (예컨대, DL 네트워크 토큰들) 을 반송하기 위하여 주어진 애플리케이션 서버로부터의 패킷들을 요구하는 운영자의 정책의 인식에 의해 인식될 수도 있다. 하나의 양태에 따르면, 묵시적 요청은 디바이스가 애플리케이션 서버와 접속하기 위하여 먼저 탐색할 때에 인식될 수도 있다. 이러한 양태에서, P-GW 는 그것이 디바이스 (예컨대, 칩 컴포넌트, 클라이언트 디바이스) 로부터 애플리케이션 서버로 지향된 제 1 패킷을 검출할 때에 묵시적 요청이 행해진 것으로 결정할 수도 있다. 또 다른 양태에 따르면, 묵시적 요청은 (P-GW 가 목적지 애플리케이션 서버가 네트워크 토큰들의 이용을 요구한다는 것을 인식할 경우에) 네트워크 토큰들을 요구하는 애플리케이션 서버의 목적지 어드레스 또는 목적지 어드레스 프리픽스를 포함하는 패킷의 송신 내에 포함될 수도 있다. 추가의 예로서, 제 1 네트워크 토큰에 대한 묵시적 요청은 (P-GW 가 애플리케이션 식별자와 연관된 애플리케이션 서비스, 애플리케이션 서버, 또는 애플리케이션이 네트워크 토큰들의 이용을 요구한다는 것을 인식할 경우에) 디바이스로부터 전송된 패킷과 함께 포함된 애플리케이션 식별자 (App ID) 에 기초하여 확립될 수도 있다. 일부 양태들에서, (예를 들어, 제어-평면에서의) 새로운 시그널링은 네트워크 토큰의 명시적 및/또는 묵시적 이용을 구현하도록 요구되지 않을 수도 있다.

일단 디바이스가 네트워크 토큰을 수신하면, 집행의 목적들을 위하여, 업링크 데이터 패킷들과 연관시켜서, 네트워크 토큰을 P-GW 로 전송하기 위한 몇몇 방법들이 있을 수도 있다. 하나의 양태에 따르면, 네트워크 토큰은 사용자-평면 심 헤더에서 디바이스로부터 패킷 데이터 네트워크 (PDN) 게이트웨이 (P-GW) 로 전송될 수도 있다. 사용자-평면 심 헤더는 인터넷 프로토콜 (IP) 계층 위에 위치될 수도 있다. 대안적으로, 사용자-평면 심 헤더는 인터넷 프로토콜 (IP) 계층 아래에 위치될 수도 있다. 또 다른 양태에 따르면, 네트워크 토큰은 IP 버전 6 (IPv6) 에서 정의된 바와 같이, 인터넷 프로토콜 (IP) 확장 헤더에서 디바이스로부터 패킷 데이터 네트워크 (PDN) 게이트웨이 (P-GW) 로 전송될 수도 있다. 또 다른 양태에 따르면, 네트워크 토큰은 패킷 데이터 컨버전스 프로토콜 (PDCP) 계층에서 디바이스로부터 액세스 노드로 전송될 수도 있다. 그 다음으로, 네트워크 토큰은 액세스 노드에서 사용자-평면에 대한 일반 패킷 라디오 서비스 (GPRS) 터널링 프로토콜 (GTP) 계층 (GTP-U) 헤더로 복사될 수도 있다. 그 다음으로, 네트워크 토큰은 GTP-U 계층에서 액세스 노드로부터 패킷 데이터 네트워크 (PDN) 게이트웨이 (P-GW) 로 전송될 수도 있다.

하나의 양태에서, 네트워크 토큰은 베어러 및/또는 데이터 흐름과 연관될 수도 있다. 네트워크 토큰은 애플리케이션 서버, 애플리케이션 서비스, 및/또는 디바이스에 바인딩될 수도 있다. 하나의 양태에서, 애플리케이션 서비스를 개시하기 위한 요청은 요청의 목적지인 애플리케이션 서버 또는 애플리케이션 서비스를 식별하기 위한 애플리케이션 식별자 (App ID) 를 포함할 수도 있다. 이러한 양태에서, 또는 임의의 다른 양태에서, 네트워크 토큰은 애플리케이션 서버, App ID, 및 디바이스에 바인딩될 수도 있다. 본원에서 이용된 바와 같이, ("토큰이 파라미터에 '바인딩' 된다"에서와 같이) 용어 "바인딩" 은 토큰 (즉, DL 토큰) 이 거명된 바인딩 파라미터 (들) 를 포함하지만, 이것으로 제한되지는 않는 함수를 이용하여 유도될 수도 있다는 것을 표시한다. 함수는 거명된 파라미터들로 제한되지는 않는다는 것이 이해될 것이다. 예로서, DL 토큰은 애플리케이션 서버 및 디바이스에 바인딩될 수도 있다 (즉, 토큰은 식별된 애플리케이션 서버 및 식별된 디바이스에 특정적임); 그러나, DL 토큰을 유도하기 위하여 이용된 수학식은 애플리케이션 서버 및/또는 디바이스를 구체적으로 식별하는 것들에 추가하여 파라미터들을 포함할 수도 있다. 본원에서 인용된 파라미터들은 네트워크 토큰을 유도하기 위하여 이용된 수학식들의 예들과 관련하여, 망라하거나 한정적이도록 의도된 것은 아니라는 것이 이해될 것이다.

DL 토큰은 예를 들어, 비밀 키, 정책 식별자, 소스 인터넷 프로토콜 (IP) 어드레스, 소스 포트 번호, 목적지 IP 어드레스, 목적지 포트 번호, 프로토콜 식별자 (ID), App ID, 우선순위, 및/또는 서비스 품질 클래스 식별자 (QCI) 를 포함하는 입력 파라미터들의 세트를 갖는 함수를 이용하여 유도될 수도 있다. 하나의 예에서, DL 토큰은 함수의 결과와, 방금 열거된 파라미터들 및/또는, DL 토큰 유도를 위하여 이용된 키를 식별하는 키 식별자 (KeyID) 와 같은 다른 파라미터들의 일부의 연결을 포함할 수도 있다. DL 토큰은 토큰 유도를 위하여 이용된 필드들, 또는 토큰을 유도하기 위하여 이용된 입력 파라미터들의 리스트를 정의하는 클래스 인덱스 (CI) 를 포함할 수도 있다. 일부 양태들에서, 비밀 키 (예컨대, K_P _-GW, 도 4 및 도 5) 는 게이트웨이 디바이스에만 알려질 수도 있다.

하나의 양태에서, 키 식별자는 토큰 유도를 위하여 이용된 비밀 키를 정의할 수도 있다. 키 식별자는 주기적으로, 또는 P-GW 로부터의 명령에 따라 변경될 수도 있다. 게이트웨이 디바이스만이 비밀 키를 알 수도 있다. 일부 양태들에서, P-GW 는 토큰 유도를 위한 다수의 키들을 가질 수도 있다. P-GW 가 토큰 유도 키를 변경할 경우, 2 개의 키들이 동시에 유효할 수도 있다. 따라서, 키 식별자는 이러한 시나리오에서 즉각적인 토큰 폐지 (revocation) 를 회피하기 위하여 이용될 수 있다.

클래스 인덱스 (CI) 는 토큰 유도를 위하여 이용된 필드들을 정의할 수도 있거나, 또는 토큰을 유도하기 위하여 이용된 입력 파라미터들의 리스트를 정의할 수도 있다.

하나의 양태에서, DL 토큰은 키 식별자, 클래스 인덱스 (CI), 정책 식별자, 및 DL 토큰의 유도와 관련하여 이용된 함수의 출력의 연결일 수도 있다. 일부 양태들에서, 함수는 SHA-1, SHA-2, 또는 SHA-3 과 같은 보안 해시 알고리즘 (SHA) 과 같은 보안 해시 함수일 수도 있다. 다른 실시형태들에서, 함수는 해시 메시지 인증 코드 (HMAC) 함수일 수도 있다. 또 다른 실시형태들에서, 함수는 메시지 인증 코드 (message authentication code; MAC) 유도 함수일 수도 있다. MAC 유도 함수는 암호 블록 연쇄 메시지 인증 코드 (cipher block chaining message authentication code; CBC-MAC) 함수, 암호-기반 MAC (cypher-based MAC; CMAC) 함수, 또는 갈루아 메시지 인증 코드 (Galois message authentication code; GMAC) 함수를 포함할 수도 있다.

P-GW 는 또한, DL 토큰에 대한 명시적 또는 묵시적 요청을 발신하였던 디바이스 또는 애플리케이션 서버를 식별하기 위하여 P-GW 에 의해 이용될 수도 있는 접속 식별자를 유도할 수도 있다. 접속 ID 는 DL 토큰의 유도 전에, 그 동안에, 또는 그 후에 유도될 수도 있다. 접속 ID 는 P-GW 와 함께 유지될 수도 있고, 오직 P-GW 에게 유용할 수도 있다. 접속 ID 는 P-GW 의 임시 저장소 (예컨대, 캐시 (428), 도 4) 내에 저장될 수도 있다. 접속 ID 가 애플리케이션 서버 및 디바이스가 주어진 인터체인지와 관련하여 패킷들을 교환하고 있는 시간 동안에 오직 유용할 수도 있으므로, 캐시는 적절한 저장 로케이션일 수도 있다. 일단 애플리케이션 서버와 디바이스 사이의 서비스가 종결되면, 또는 미리 결정된 양의 시간 또는 일부 다른 트리거링 이벤트 후에, 접속 ID 는 P-GW 에서의 저장소로부터 제거될 수 있다 (예컨대, P-GW 의 캐시로부터 겹쳐쓰기되거나 또는 삭제됨).

P-GW 는 사용자-평면 메시지들에 관련된 다운링크 정책들을 포함하는 다운링크 트래픽 정책들을 집행하기 위하여 DL 토큰을 이용할 수도 있다. 집행은 예를 들어, 애플리케이션 서버로부터 주어진 패킷에서 수신된 DL 토큰을 검증함으로써, 그리고 패킷을 적절한 디바이스로 포워딩하기 위하여 DL 토큰으로부터 획득된 정보를 이용함으로써 수행될 수도 있다. 적절한 디바이스로 포워딩된 패킷은 DL 토큰을 포함할 수도 있거나 포함하지 않을 수도 있다. P-GW 는 또한, (이전에 유도될 경우에) 접속 ID 를 검증할 수도 있다.

네트워크 토큰은 네트워크에서 애플리케이션 서버와 디바이스 사이의 애플리케이션 서비스 송신들을 유효성 확인하고 맵핑하기 위한 보안성 있는 방법일 수도 있다. 이러한 목적을 위한 네트워크 토큰의 이용은 애플리케이션 서버 ID 만을 패킷에 추가하는 것보다 더욱 큰 보안성을 제공한다. 게다가, 위에서 언급된 바와 같이, 네트워크 토큰은 유효성확인을 위하여 이용되는 보안 해시, 보안 해시가 유효성확인을 위하여 어떻게 이용되는지를 결정하기 위하여 이용되는 인덱스, 및/또는 패킷이 유효성 확인된 후에 패킷을 어떻게 프로세싱할 것인지를 결정하기 위하여 이용되는 정책 중의 하나 이상을 포함할 수도 있다.

임의적인 단계로서, 디바이스는 제 2 애플리케이션 서버와의 접속을 확립할 수도 있거나 개시할 수도 있다. 그 후에, 디바이스는 제 2 애플리케이션 서버로부터, 제 1 네트워크 토큰과는 상이한 제 2 네트워크 토큰을 임의적으로 획득할 수도 있다. 제 1 애플리케이션 서버 및 제 2 애플리케이션 서버는 애플리케이션 서비스 또는 목적지 IP 어드레스와 연관될 수도 있다. 추가적으로 또는 대안적으로, 제 1 애플리케이션 서버 및 제 2 애플리케이션 서버는 제 1 애플리케이션 서비스 및 제 2 애플리케이션 서비스와 연관될 수도 있다.

도 15 는, 디바이스 (예컨대, 칩 컴포넌트, 클라이언트 디바이스) 가 통신을 개시하기 위한 요청에 대해 응답할 수도 있고 통신과 관련하여 네트워크 토큰들을 사용할 수도 있는 예시적인 방법 (1500) 이다. 통신을 개시하기 위한 요청은 네트워크 토큰을 사용하기 위한 요청을 포함할 수도 있다. 방법 (1500) 은 디바이스에서 동작할 수도 있다. 방법 (1500) 은 애플리케이션 서버가 통신을 개시하기 위한 요청 및/또는 네트워크 토큰을 사용하기 위한 요청을 개시하였던 경우에 적용할 수도 있다.

통신을 개시하기 위한 요청 (예컨대, 애플리케이션 서비스를 개시하기 위한 요청) 은 애플리케이션 서버로부터 나올 수도 있다. 요청, 예를 들어, 애플리케이션 서비스 요청은 네트워크 토큰을 사용하기 위한 명시적 요청을 포함할 수도 있다. 대안적으로, 네트워크 토큰을 사용하기 위한 요청은 묵시적일 수도 있다. 요청은 요청을 개시하였던 애플리케이션 서버 또는 서비스를 식별하기 위한 애플리케이션 식별자 (App ID) 를 포함할 수도 있다.

하나의 양태에서, 디바이스는 애플리케이션 서버로부터 애플리케이션 서비스를 개시하기 위한 요청을 수신할 수도 있다 (1502). 디바이스는 네트워크 토큰을 획득할 수도 있다 (1504). 하나의 양태에서, 네트워크 토큰은 게이트웨이 (예컨대, P-GW) 로부터 획득될 수도 있다. 디바이스는 (예컨대, IP 어드레스, 디바이스 ID, 또는 애플리케이션 크리덴셜 (Application Credential) 에 기초하여) 애플리케이션 서비스를 개시하기 위한 요청을 검증할 수도 있다 (1506).

디바이스는 애플리케이션 서비스를 개시하기 위한 요청에 응답하여 네트워크 토큰을 임베딩하거나, 또는 그렇지 않을 경우에 포함함으로써 애플리케이션 서버에 대한 네트워크 토큰을 승인할 수도 있다 (1508). 네트워크 토큰은 애플리케이션 서비스를 개시하기 위한 요청에 대한 응답을 포함하는 패킷 내에 임베딩될 수도 있다. 하나의 양태에서, 네트워크 토큰은 예를 들어, 애플리케이션 서비스를 개시하기 위한 요청에 대한 응답의 일부 또는 전부를 포함할 수도 있는 복수의 패킷들 사이에서 분산될 수도 있다.

그 다음으로, 디바이스는 임베딩된 네트워크 토큰을 포함하는 응답을 애플리케이션 서버로 전송할 수도 있다 (1510). 이러한 방법으로, 애플리케이션 서버는 네트워크 토큰을 제공받을 수도 있고, 차례로, 애플리케이션 서버로부터 디바이스로 다운링크 방향에서 전송되는 하나 이상의 패킷들내에 네트워크 토큰의 복사본을 임베딩할 수 있거나, 또는 그렇지 않을 경우에 포함할 수 있다. 일부 양태들에서, 애플리케이션 서버는 애플리케이션 서버로부터 디바이스로 다운링크 방향에서 전송되는 매 패킷내에 네트워크 토큰의 복사본을 임베딩할 수도 있거나, 또는 그렇지 않을 경우에 포함할 수도 있다.

일부 양태들에서, 네트워크 토큰은 다운링크 네트워크 토큰일 수도 있다. 네트워크 토큰은 디바이스에서 게이트웨이 디바이스 (예컨대, P-GW) 로부터 수신될 수도 있다. 일부 양태들에서, DL 토큰은 게이트웨이 디바이스로부터 수신된 패킷 내에 임베딩될 수도 있거나, 또는 그렇지 않을 경우에 그것과 함께 포함될 수도 있다. 패킷은 사용자-평면에서 전송될 수도 있다.

네트워크 토큰은 애플리케이션 서버 및 디바이스에 바인딩될 수도 있거나, 애플리케이션 서버, 애플리케이션 서비스, 및 디바이스에 바인딩될 수도 있다. 하나의 양태에서, DL 토큰은 베어러 및/또는 데이터 흐름과 연관될 수도 있다. DL 토큰은 다운링크 패킷들의 유효성확인을 위하여, 그리고 베어러로의 다운링크 흐름에서 수신된 다운링크 패킷을 맵핑하기 위하여 이용될 수도 있다.

디바이스 또는 애플리케이션 서버가 통신을 확립하기 위한 요청을 개시하는지 여부에 관계 없이, 요청은 전송 계층 요청 또는 애플리케이션 계층 요청일 수도 있다. 초기 요청에서의 패킷은 송신 제어 프로토콜 동기화 (TCP SYN) 패킷일 수도 있다. 초기 요청에서의 패킷이 TCP SYN 패킷일 경우, 제 1 네트워크 토큰은 TCP SYN 확인응답 (ACK) 패킷에서 디바이스 또는 애플리케이션 서버로 반송될 수도 있다.

네트워크 토큰을 사용하기 위한 요청은 명시적 요청 또는 묵시적 요청일 수도 있다. 명시적 요청은 사용자-평면에서 애플리케이션 서버로부터 (또는 그것으로) 전송된 요청 내에 임베딩될 수도 있다. 묵시적 요청은 예를 들어, 애플리케이션 서버로부터 디바이스로 (또는 그 반대로) 초기 메시지를 전송하는 것 덕분에 인식될 수도 있다. 즉, 시스템은 새로운 통신 서비스가 확립될 때마다 네트워크 토큰들을 이용하기 위한 필요성을 인식하도록 준비될 수도 있다. 추가의 예로서, 서비스를 개시하는 것은 제 1 네트워크 토큰에 대한 묵시적 요청을 표현하는 패킷을 전송하는 것을 포함할 수도 있고, 여기서, 묵시적 요청은 애플리케이션 서버로 (또는 디바이스로) 지향된 제 1 패킷의 송신인 것으로서 인식될 수도 있다. 추가의 예로서, 서비스를 개시하는 것은 네트워크 토큰에 대한 묵시적 요청을 표현하는 패킷을 전송하는 것을 포함할 수도 있고, 여기서, 묵시적 요청은 (예를 들어, P-GW 가 목적지 애플리케이션 서버가 네트워크 토큰들의 이용을 요구한다는 것을 인식할 경우에) 네트워크 토큰들을 요구하는 애플리케이션 서버의 목적지 어드레스 또는 적어도 목적지 어드레스 프리픽스를 포함하는 패킷의 송신인 것으로서 인식될 수도 있다. 추가의 예로서, 서비스를 확립하거나 개시하는 것은 제 1 네트워크 토큰에 대한 묵시적 요청을 표현하는 패킷을 전송하는 것을 포함할 수도 있고, 여기서, 묵시적 요청은 패킷과 함께 포함된 애플리케이션 식별자 (App ID) 에 기초하여 인식될 수도 있다. 일부 양태들에서, (예를 들어, 제어-평면에서의) 새로운 시그널링은 사용자-평면 메시징을 통해 구현된 토큰 요청의 명시적 및/또는 묵시적 이용을 구현하도록 요구되지 않을 수도 있다.

하나의 양태에서, 네트워크 토큰은 사용자-평면 심 계층 헤더에서 수신될 수도 있다. 사용자-평면 심 계층은 사용자-평면 프로토콜 스택에서 인터넷 프로토콜 (IP) 계층 위에 위치될 수도 있다. 대안적으로, 사용자-평면 심 계층은 사용자-평면 프로토콜 스택에서 인터넷 프로토콜 (IP) 계층 아래에 위치될 수도 있다.

하나의 양태에서, 네트워크 토큰은 IP 버전 4 (IPv4) 헤더 또는 IP 버전 6 (IPv6) 헤더와 같은 IP 헤더 내에 임베딩될 수도 있다. IPv4 에서의 IP 헤더는 IP 옵션들 필드일 수도 있다. IPv6 에서의 IP 헤더는 IP 확장 헤더일 수도 있다.

하나의 양태에서, 네트워크 토큰은 송신 제어 프로토콜 (TCP) 헤더 내에 임베딩될 수도 있다. 네트워크 토큰은 TCP 헤더의 옵션들 필드 내에 임베딩될 수도 있다.

하나의 양태에서, 네트워크 토큰은 전송 계층 보안성 (TLS) 레코드 헤더 내에 임베딩될 수도 있다.

하나의 양태에서, 네트워크 토큰은 IP 헤더와 송신 제어 프로토콜/사용자 데이터그램 프로토콜 (TCP/UDP) 헤더 사이의 심 헤더 내에 임베딩될 수도 있다.

또 다른 양태에서, 네트워크 토큰은 하이퍼텍스트 전송 프로토콜 (HTTP) 헤더 내에 임베딩될 수도 있다. HTTP 헤더는 HTTP 실험적 또는 확장 헤더일 수도 있다.

예시적인 게 이트웨이 디바이스

도 16 은 본원에서 설명된 양태들에 따라, 네트워크 토큰들을 이용하여 네트워크 정책 집행 및/또는 패킷 스티어링을 지원하도록 구성된 예시적인 게이트웨이 디바이스 (1600) 를 예시하는 블록도이다. 하나의 예에서, 예시적인 게이트웨이 디바이스 (1600) 는 무선 네트워크 상에서 통신하기 위한 네트워크 통신 인터페이스 회로 (1602), 네트워크 통신 인터페이스 회로 (1602) 에 결합된 프로세싱 회로 (1604), 및 프로세싱 회로 (1604) 에 결합된 메모리 디바이스 (1606) (예컨대, 데이터를 저장하기 위한 자기 및/또는 광학 디바이스) 를 포함할 수도 있다. 이 리스트는 비한정적이다.

무선 네트워크 상에서 통신하기 위한 네트워크 통신 인터페이스 회로 (1602) 는 서빙 게이트웨이와 통신하기 위한 제 1 입력/출력 회로/기능부/모듈 (1608), 및 패킷 데이터 네트워크와 통신하기 위한 제 2 입력/출력 회로/기능부/모듈 (1610) 을 포함할 수도 있다. 제 1 입력/출력 회로/기능부/모듈 (1608) 은 다수의 베어러들 상에서 확립된 다수의 IP 흐름들을 핸들링할 수도 있다. 제 2 입력/출력 회로/기능부/모듈 (1610) 은 패킷 데이터 네트워크 상에서의 다수의 서버들로 다수의 IP 흐름들을 핸들링할 수도 있다. 이 리스트는 비한정적이다.

프로세싱 회로 (1604) 는 토큰 기반 애플리케이션 액세스를 지원하도록 구성되는, 하나 이상의 프로세서들, 애플리케이션 특정 프로세서들, 하드웨어 및/또는 소프트웨어 모듈들 등을 포함할 수도 있거나 구현할 수도 있다. 예를 들어, 네트워크 토큰 유도/검증 회로/기능부/모듈 (1612) 은 메모리 디바이스 (1606) 내에 저장될 수도 있는 비밀 키에 기초하여 토큰들을 유도하도록 구성될 수도 있다. 오직 게이트웨이 디바이스가 비밀 키를 알 수도 있다. 또 다른 예로서, 키 유도 회로/기능부/모듈 (1614) 은 예를 들어, 메모리 디바이스 (1606) 내에 저장될 수도 있는 비밀 키 및 주어진 액세스 노드의 식별자에 기초하여 액세스 노드에 특정적인 비밀 키를 유도하도록 구성될 수도 있다. 또 다른 예로서, 판단 및 프로세싱 회로/기능부/모듈 (1616) 은 EPS 베어러들로부터 수신된 (또는 더욱 일반적으로 디바이스들로부터 수신된) 업링크 패킷들 및/또는 애플리케이션 서버들로부터 수신된 다운링크 패킷들이 네트워크 토큰들을 포함하는지를 판단하도록 구성될 수도 있고, 그러할 경우, 수신된 패킷들을 암호-유효성확인 및 트래픽-스티어링 회로/기능부/모듈 (1618) 로 전달하도록 추가로 구성될 수도 있다. 또 다른 예로서, 암호 유효성확인/검증 모듈/회로/기능부 (1630) 는 예를 들어, 디바이스들 또는 애플리케이션 서버들로부터 수신된 네트워크 토큰들을 유효성확인/검증하도록 구성될 수도 있다. 판단 및 프로세싱 회로/기능부/모듈 (1616) 은 네트워크 토큰들을 포함하지 않는 수신된 패킷들을 서비스 데이터 흐름 필터 뱅크 (도시되지 않음) 로 전달하도록 추가로 구성될 수도 있다. 이 리스트는 비한정적이다.

메모리 디바이스 (1606) 는 네트워크 토큰 유도/검증 명령들 (1620), 키 유도 명령들 (1622), 판단 및 프로세싱 명령들 (1624), 암호-유효성확인 및 트래픽-스티어링 명령들 (1626), 및 공유 및 비공유 비밀 키 저장 및 명령들을 포함하도록 구성될 수도 있다. 이 리스트는 비한정적이다.

네트워크 통신 인터페이스 회로 (1602), 프로세싱 회로 (1604), 메모리 디바이스 (1606), 및 예시적인 게이트웨이 디바이스 (1600) 의 다른 컴포넌트들 (도시되지 않음) 사이의 통신은 통신 버스 (1634) 를 통한 것일 수도 있다.

게이트웨이 디바이스에서 동작하는 방법들

도 17 은 본원에서 설명된 양태에 따라, 네트워크 토큰의 이용을 위하여, 사용자-평면 메시징을 통해, 디바이스로부터의 요청을 검출하고, 네트워크 토큰을 유도하고, 네트워크 토큰을 요청하는 디바이스에 애플리케이션 서버를 통해 프로비저닝하기 위한, 게이트웨이 디바이스 (예컨대, P-GW) 에서 동작하는 예시적인 방법 (1700) 을 예시한다.

하나의 양태에 따르면, 네트워크에서의 게이트웨이 디바이스 (예컨대, P-GW) 에서 동작하는 방법은 사용자-평면을 통해, 게이트웨이 디바이스에서 데이터 패킷을 수신하는 것 (1702) 을 포함할 수도 있다. 그 다음으로, 게이트웨이 디바이스는 네트워크 토큰이 (예컨대, 명시적으로 또는 묵시적으로) 요청되는지를 결정하기 위한 단계들 (1704) 을 수행할 수도 있다. 네트워크 토큰이 요청될 경우, 게이트웨이 디바이스는 네트워크 토큰을 획득할 수도 있다 (1706). 네트워크 토큰은 네트워크에 의해 유지된 디바이스 가입 프로파일에 기초할 수도 있다.

하나의 양태에 따르면, 네트워크 토큰은 게이트웨이 디바이스에서 그것을 로컬적으로 유도함으로써 획득될 수도 있다. 본원에서 설명된 양태들에 따르면, 네트워크 토큰은 게이트웨이 디바이스와 연관된 코어 네트워크에 의해 유지된 디바이스 가입 프로파일에 기초하여 게이트웨이 디바이스에 의해 유도될 수도 있다. 디바이스 가입 프로파일은 가입 프로파일 저장소 (SPR) 내에 저장될 수도 있다. 네트워크 토큰은 디바이스에 대하여 코어 네트워크에 의해 집행된 정책을 반영할 수도 있다. 다시 말해서, 네트워크 토큰은 애플리케이션 서버의 정책을 반영할 필요가 없다. 네트워크 토큰은 네트워크를 대신하여, 그리고 네트워크의 목적들을 위하여, 게이트웨이 디바이스에 의해 유도될 수도 있고 이용될 수도 있다.

일단 게이트웨이 디바이스가 네트워크 토큰을 획득하면, 게이트웨이 디바이스는 데이터 패킷과 함께 네트워크 토큰을 포함 (1708) 하기 위하여 필요한 단계들을 수행할 수도 있다. 그 다음으로, 게이트웨이 디바이스는 데이터 패킷 및 네트워크 토큰을 목적지로 전송할 수도 있다 (1710).

일부 양태들에서, 데이터 패킷은 애플리케이션 서버로 전송될 것이고, 네트워크 토큰은 업링크 네트워크 토큰이다. 일부 양태들에서, 데이터 패킷은 애플리케이션 서버로 전송될 것이고, 네트워크 토큰은 다운링크 네트워크 토큰이다. 일부 양태들에서, 데이터 패킷은 디바이스로 전송될 것이고, 네트워크 토큰은 다운링크 네트워크 토큰이다. 일부 양태들에서, 데이터 패킷이 디바이스로 전송될 것이고 네트워크 토큰이 다운링크 네트워크 토큰일 때, 방법은 디바이스로부터 다운링크 네트워크 토큰을 포함하는 제 2 패킷을 수신하는 것, 및 제 2 패킷 및 다운링크 네트워크 토큰을 애플리케이션 서버로 전송하는 것을 더 포함할 수도 있다. 이 후자의 양태에서, 애플리케이션 서버는 다운링크 네트워크 토큰을 요청하였을 수도 있고; 요청된 다운링크 네트워크 토큰은 게이트웨이로부터 디바이스로 전송될 것이고; 게이트웨이는 다운링크 네트워크 토큰을 포함하는, 디바이스로부터의 데이터 패킷을 추후에 수신할 것이고; 게이트웨이는 다운링크 네트워크 토큰의 그 복사본을, 다운링크 네트워크 토큰을 원래 요청하였던 애플리케이션 서버로 전송할 것이다. 또 다른 양태들에서, 네트워크 토큰은 업링크 네트워크 토큰 및 다운링크 네트워크 토큰일 수 있고, 업링크 네트워크 토큰은 다운링크 네트워크 토큰과는 상이하다. 이러한 양태에서, 게이트웨이 디바이스는 업링크 네트워크 토큰 및 다운링크 네트워크 토큰의 양자 모두를 유도하고 목적지로 양자 모두룰 전송할 수도 있다.

위에서 표시된 바와 같이, 게이트웨이 디바이스는 패킷 데이터 네트워크 (PDN) 게이트웨이 (P-GW) 일 수도 있다.

네트워크 토큰이 요청되는지를 결정하는 단계는 패킷이 네트워크 토큰에 대한 명시적 요청을 포함하는지 여부, 또는 패킷이 네트워크 토큰에 대한 묵시적 요청을 표현하는지 (예컨대, 나타내는지) 여부에 의존할 수도 있다. 일부 양태들에 따르면, 네트워크 토큰이 요청되는지를 결정하는 것은 패킷이 전송될 애플리케이션 서버가 네트워크 토큰들을 요구하는지를 결정하는 것에 기초한다. 패킷이 전송될 애플리케이션 서버가 네트워크 토큰들을 요구할 경우, 게이트웨이 디바이스는 네트워크 토큰을 획득할 수도 있다. 네트워크 토큰에 대한 필요성을 결정하기 위한 묵시적 표시들에 대한 다른 테스트들이 허용가능하다.

네트워크 토큰이 요청될 경우, 게이트웨이 디바이스는 네트워크 토큰을 획득할 수도 있다. 하나의 양태에 따르면, 네트워크 토큰을 획득하는 것은 게이트웨이 디바이스에서 네트워크 토큰을 유도함으로써 달성된다. 네트워크 토큰은 게이트웨이 디바이스에 알려진 비밀 키, 클래스 인덱스, 소스 인터넷 프로토콜 (IP) 어드레스, 소스 포트 번호, 목적지 IP 어드레스, 목적지 포트 번호, 프로토콜 식별자 (ID), 애플리케이션 ID, 우선순위, 및/또는 서비스 품질 클래스 식별자 (QCI) 를 포함하는 입력 파라미터들의 세트를 가지는 함수를 이용하여 유도될 수도 있다. 클래스 인덱스는 네트워크 토큰 유도를 위하여 이용된 필드들을 정의할 수도 있다.

위에서 제공되고 편의상 이하에서 재현된 하나의 예에 따르면, 네트워크 토큰은 이하로서 유도될 수도 있다:

여기서: CI 는 토큰 유도를 위하여 이용된 필드들을 정의하는 클래스 인덱스이고, HMAC 는 키잉된-해시 메시지 인증 코드이고, K_P _-GW 는 P-GW 의 비밀 키이고, IP_C 는 클라이언트 (예컨대, 디바이스) IP 어드레스이고, P_C 는 클라이언트 포트 번호이고, IP_S 는 서버 (예컨대, 목적지 또는 애플리케이션 서버) IP 어드레스이고, P_S 는 서버 포트 번호이고, Proto 는 프로토콜 번호 또는 식별자이고, App ID 는 애플리케이션 식별자이다. 추가적인 또는 대안적인 파라미터들은 우선순위 및/또는 서비스 품질 클래스 식별자 (QCI) 를 포함할 수도 있다.

상기 예에서 도시된 바와 같이, 네트워크 토큰은 클래스 인덱스 및 예시적인 함수의 출력의 연결일 수도 있다. 일부 양태들에 따르면, 함수는 해시 메시지 인증 코드 (HMAC) 함수일 수도 있다. 일부 양태들에 따르면, 함수는 메시지 인증 코드 (MAC) 유도 함수일 수도 있다. MAC 유도 함수는 암호 블록 연쇄 메시지 인증 코드 (CBC-MAC) 함수, 암호-기반 MAC (CMAC) 함수, 또는 갈루아 메시지 인증 코드 (GMAC) 함수를 포함한다. 네트워크 토큰의 유도를 위한 다른 공식들이 수용가능할 수도 있다.

도 18 은 본원에서 설명된 양태에 따라, 사용자-평면 메시징을 통해 게이트웨이 디바이스 (예컨대, P-GW) 에서 네트워크 토큰을 설정하고 이용하는, 게이트웨이 디바이스 (예컨대, P-GW) 에서 동작하는 예시적인 방법 (1800) 을 예시한다.

하나의 양태에서, 네트워크 토큰을 설정하는 방법은 게이트웨이 디바이스에서, 네트워크 서비스에 대한 요청 (예컨대, 제 1 패킷) 을 수신 (1802) 하는 것을 포함할 수도 있다. 네트워크 서비스에 대한 요청은 네트워크 토큰에 대한 요청을 명시적으로 포함할 수도 있거나, 또는 묵시적으로 표현할 수도 있다. 네트워크 서비스에 대한 요청은 (예컨대, 업링크 데이터 흐름에서) 클라이언트 디바이스로부터, 또는 (예컨대, 다운링크 데이터 흐름에서) 애플리케이션 서버로부터 수신될 수도 있다. 게이트웨이 디바이스는 네트워크 토큰에 대한 요청에 응답하여, 업링크 네트워크 토큰, 다운링크 네트워크 토큰, 또는 업링크 네트워크 토큰 및 다운링크 네트워크 토큰의 양자를 요청에 적절하게 유도할 수도 있다 (1804).

임의적으로, 게이트웨이 디바이스는 또한, 네트워크 토큰과 연관된 접속을 개시하였던 클라이언트 디바이스 또는 애플리케이션 서버를 식별할 수도 있는 접속 식별자를 유도할 수도 있다 (1806). 유도될 경우, 접속 식별자는 게이트웨이 디바이스에 임의적으로 저장될 수도 있다 (1808). 저장소는 예를 들어, 게이트웨이 디바이스의 캐시 내에 있을 수도 있다.

게이트웨이 디바이스는 디바이스 또는 애플리케이션 서버의 어느 하나로 전송될 패킷 내에 네트워크 토큰을 임베딩할 수도 있거나, 또는 그렇지 않을 경우에 포함할 수도 있다 (1810). 하나의 양태에서, 패킷은 애플리케이션 서비스에 대한 요청과 연관될 수도 있다. 게이트웨이 디바이스는 임베딩된/포함된 네트워크 토큰을 포함하는, 애플리케이션 서비스에 대한 요청을 디바이스 또는 애플리케이션 서버의 어느 하나로 전송할 수도 있다 (1812).

추후에, 게이트웨이 디바이스는 이전에 유도된 (또는 이전에 유도된 것의 복사본) 네트워크 토큰을 포함하는 패킷을 수신할 수도 있다 (1814). 애플리케이션 서비스에 대한 요청 (예컨대, 서비스 개시 요청) 의 비한정적인 예를 계속하면, 수신된 패킷은 서비스 개시 응답과 연관될 수도 있다. 게이트웨이 디바이스는 네트워크 토큰을 유효성 확인함으로써 (1816), 수신된 패킷을 유효성 확인할 수도 있다. 임의적으로, 이전에 유도된 경우, 게이트웨이 디바이스는 접속 ID 를 유효성 확인할 수도 있다 (1818). 게이트웨이 디바이스는 네트워크 토큰이 유효성 확인되었을 경우에, 개시 응답을 그 목적지로 전송할 수도 있다 (1820). 일부 양태들에서, 게이트웨이 디바이스는 개시 응답과 함께 네트워크 토큰을 포함할 수도 있다. 다른 양태들에서, 게이트웨이 디바이스는, 개시 응답이 그 목적지로 전송될 때, 네트워크 토큰은 개시 응답과 함께 포함되지 않도록, 네트워크 토큰을 폐기할 수도 있다.

일부 양태들에서, 네트워크 토큰은 디바이스 (예컨대, 칩 컴포넌트, 클라이언트 디바이스) 및 애플리케이션 서버에 바인딩될 수도 있거나, 또는 디바이스, App ID, 및 애플리케이션 서버에 바인딩될 수도 있다.

도 19 는 본원에서 설명된 양태에 따라, 네트워크 정책들의 집행 및/또는 패킷들의 스티어링을 위한 네트워크 토큰의 이용과 관련하여, 네트워크 토큰을 검증하기 위한, 게이트웨이 디바이스 (예컨대, P-GW) 에서 동작하는 예시적인 방법 (1900) 을 예시한다. 일부 양태들에 따르면, 어떤 특징들은 게이트웨이 디바이스가 정책 집행 및/또는 패킷 스티어링을 위하여 데이터 패킷과 함께 포함된 네트워크 토큰을 이용할 수 있을 수도 있다는 것을 표시할 수도 있다. 하나의 예에서, 플래그는 패킷이 정책 집행 및/또는 패킷 스티어링을 위하여 네트워크 토큰을 포함한다는 것을 표시하도록 설정될 수도 있다.

하나의 양태에 따르면, 방법은 제 1 네트워크 토큰에 대한 요청에 응답하여, 게이트웨이 디바이스에서 제 1 네트워크 토큰을 유도하는 것 (1902) 을 포함할 수도 있다. 제 1 네트워크 토큰에 대한 요청은 디바이스로부터, 하나 이상의 애플리케이션 서비스들과 연관된 애플리케이션 서버로 전송될 수도 있다. 게이트웨이 디바이스에서, 디바이스로부터 데이터 패킷을 수신한다 (1904). 데이터 패킷은 애플리케이션 서버에 대응하는 적어도 목적지 어드레스 프리픽스를 포함할 수도 있다. 데이터 패킷은 제 2 네트워크 토큰을 포함할 수도 있다.

방법은 제 2 네트워크 토큰을 검증 (1906) 함으로써 진행할 수도 있다. 하나의 양태에 따르면, 제 2 네트워크 토큰을 검증하는 것 (1906) 은 패킷으로부터 획득된 입력 파라미터들 및 게이트웨이 디바이스에 알려진 키를 이용하여 제 1 함수로부터 제 1 네트워크 토큰의 복제본을 유도하는 것을 포함할 수도 있다. 제 1 네트워크 토큰은 이전에 유도되었고, 디바이스로의 후속 전달을 위하여 애플리케이션 서버로 전송되었다. 일단 디바이스가 제 1 네트워크 토큰을 수신하였으면, 그것은 동일한 애플리케이션 서버로 전송된 업링크 패킷들과 함께 제 1 네트워크 토큰의 복사본을 포함하였다. 이제 고려 중인 수신된 업링크 패킷 내에 포함하는 제 2 네트워크 토큰은 제 1 네트워크 토큰의 복사본이어야 한다. 양자의 네트워크 토큰들이 동일한 함수, 게이트웨이 디바이스에 알려진 동일한 비밀 키, 및 동일한 디바이스로부터 게이트웨이 디바이스로 전송된 상이한 패킷들로부터 인출된 동일한 공통적인 파라미터들을 이용하여 유도되었을 경우, 제 2 네트워크 토큰은 제 1 네트워크 토큰의 복제본과 동일할 것이다.

임의적으로, 접속 식별자가 유도되었고, 원래의 네트워크 토큰의 유도와 관련하여 게이트웨이 디바이스에서 저장되었을 경우, 게이트웨이 디바이스에서의 회로/모듈/기능부는 접속 식별자를 검증할 수도 있다 (1908).

(예컨대, 제 2 네트워크 토큰 및 임의적으로 접속 식별자의) 검증이 성공적인지 여부에 대하여, 결정 (1910) 이 행해질 수도 있다. 검증이 성공적이지 않을 경우, 방법은 패킷 및 그 연관된 제 2 네트워크 토큰을 폐기 (1912) 함으로써 진행할 수도 있다. 검증이 성공적일 경우, 방법은 제 2 네트워크 토큰을 임의적으로 폐기 (1914) 하고 패킷을 애플리케이션 서버로 전송 (1916) 함으로써 진행할 수도 있다.

예시적인 애 플리케이션 서버

도 20 은 다운링크 토큰 유효성확인 및 패킷 맵핑을 지원하도록 구성된 예시적인 애플리케이션 서버 (2000) 를 예시하는 블록도이다. 하나의 예에서, 애플리케이션 서버 (2000) 는 무선 네트워크 상에서 통신하기 위한 네트워크 통신 인터페이스 회로 (2002), 네트워크 통신 인터페이스 회로 (2002) 에 결합된 프로세싱 회로 (2004), 및 프로세싱 회로 (2004) 에 결합된 메모리 디바이스 (2006) 를 포함할 수도 있다. 이 리스트는 비한정적이다.

무선 네트워크 상에서 통신하기 위한 네트워크 통신 인터페이스 회로 (2002) 는 S-GW 를 통한 P-GW 와의 통신을 위한 제 1 입력/출력 모듈/회로/기능부 (2008) 를 포함할 수도 있다. 네트워크 통신 인터페이스 회로 (2002) 는 디바이스들과의 무선 통신을 위한 수신기/송신기 모듈/회로/기능부 (2010) 를 포함할 수도 있다. 이 리스트는 비한정적이다.

프로세싱 회로 (2004) 는 토큰 기반 애플리케이션 액세스를 지원하도록 구성되는, 하나 이상의 프로세서들, 애플리케이션 특정 프로세서들, 하드웨어 및/또는 소프트웨어 모듈들 등을 포함할 수도 있거나 구현할 수도 있다. 예를 들어, 네트워크 토큰 핸들링 모듈/회로/기능부 (2012) 는 메모리 디바이스 (2006) 내에 저장될 수도 있는, 비공유 비밀 키, 또는 공유 비밀 키에 기초하여 토큰들을 유도하도록 구성될 수도 있다. 또 다른 예로서, 네트워크 토큰 추출/임베딩 모듈/회로 기능부 (2014) 는 디바이스로부터의 업링크 패킷들로부터 네트워크 토큰들을 추출하거나 및/또는 게이트웨이 디바이스로 포워딩된 패킷들 내에 네트워크 토큰들을 임베딩 (포함) 하도록 구성될 수도 있다. 또 다른 예로서, 암호 유효성확인/검증 메모리 디바이스 (2016) 는 예를 들어, 디바이스들로부터 수신된 네트워크 토큰들을 유효성확인/검증하도록 구성될 수도 있다. 이 리스트는 비한정적이다.

메모리 디바이스 (2006) 는 네트워크 토큰 핸들링 명령들 (2020), 네트워크 토큰 추출/임베딩 명령들 (2022), 암호 유효성확인/검증 명령들 (2024), 및 공유 및 비공유 비밀 키 저장 및 명령들 (2026) 을 포함하도록 구성될 수도 있다. 이 리스트는 비한정적이다.

네트워크 통신 인터페이스 회로 (2002), 프로세싱 회로 (2004), 메모리 디바이스 (2006), 및 애플리케이션 서버 (2000) 의 다른 컴포넌트들 (도시되지 않음) 사이의 통신은 통신 버스 (2034) 를 통한 것일 수도 있다.

애플리케이션 서버에서 동작하는 방법

도 21 은 본원에서 설명된 양태에 따라, 애플리케이션 서버에서 네트워크 토큰을 설정하는 예시적인 방법 (2100) 의 플로우차트이다.

하나의 양태에 따르면, 애플리케이션 서버가 애플리케이션 서비스를 디바이스 (예컨대, 칩 컴포넌트, 클라이언트 디바이스) 에 제공하기 위한 요청을 개시할 것인지 여부에 대하여, 결정 (2102) 이 행해질 수도 있다. 애플리케이션 서버가 요청을 개시할 경우, 애플리케이션 서버는 네트워크 토큰 (예컨대, DL 네트워크 토큰) 의 사용에 대한 요청을 명시적으로 포함하거나 묵시적으로 표현하는, 사용자-평면에서 송신된 패킷을 포함하는 요청을 전송할 수도 있다 (2104). 그 다음으로, 애플리케이션 서버는 네트워크 토큰을 획득하기 위하여 대기할 수도 있다 (2106). 2102 로 돌아가면, 애플리케이션 서버가 요청을 개시하지 않는 것으로 결정될 경우, 애플리케이션 서버는 예를 들어, 디바이스 (예컨대, 칩 컴포넌트, 클라이언트 디바이스) 로부터 전송된 네트워크 토큰의 이용에 대한 명시적 또는 묵시적 요청에 기초하여 전송된 네트워크 토큰을 획득하기 위하여 대기할 수도 있다 (2106).

애플리케이션 서버는 네트워크 토큰을 다음으로 획득할 수도 있다 (2108). 본원에서 설명된 양태들에 따르면, 코어 네트워크와 연관된 게이트웨이 디바이스는 코어 네트워크에 의해 유지된 디바이스 가입 프로파일에 기초하여 네트워크 토큰을 유도하였을 수도 있다. 디바이스 가입 프로파일은 가입 프로파일 저장소 (SPR) 내에 저장될 수도 있다. SPR 은 PCRF 에 결합될 수도 있다. 네트워크 토큰은 디바이스에 대하여 코어 네트워크에 의해 집행된 정책을 반영할 수도 있다. 다시 말해서, 네트워크 토큰은 애플리케이션 서버의 정책을 반영할 필요가 없다. 네트워크 토큰은 네트워크를 대신하여, 그리고 네트워크의 목적들을 위하여, 게이트웨이 디바이스에 의해 유도될 수도 있고 이용될 수도 있다.

네트워크 토큰을 획득 (예컨대, 수신) 할 시에, 예를 들어, 네트워크 토큰이 디바이스와의 접속에 관련된 DL 네트워크 토큰일 경우, 애플리케이션 서버는 디바이스로 전송된 적어도 일부 패킷들 내에 DL 네트워크 토큰의 복사본을 임베딩할 수도 있거나, 또는 그렇지 않을 경우에 포함할 수도 있다. 일부 양태들에서, 애플리케이션 서버는 디바이스로 전송된 매 패킷 내에 DL 네트워크 토큰의 복사본을 임베딩할 수도 있거나, 또는 그렇지 않을 경우에 포함할 수도 있다.

일부 양태들에서, 애플리케이션 서버로부터 디바이스로 전송된 패킷들과 함께 DL 토큰들을 전송하는 것은, 인터넷 프로토콜 (IP) IP 버전 4 (IPv4) 헤더 또는 IP 버전 6 (IPv6) 헤더로서, 여기서, IPv4 헤더에서의 토큰은 IP 옵션들 필드에 있을 수도 있고 IPv6 헤더에서의 토큰은 IP 확장 헤더에 있을 수도 있는, 상기 인터넷 프로토콜 (IP) IP 버전 4 (IPv4) 헤더 또는 IP 버전 6 (IPv6) 헤더; 송신 제어 프로토콜 (TCP) 헤더; 보안 소켓 계층 (Secure Socket Layer; SSL) 헤더; 전송 계층 보안성 (TLS) 레코드 헤더; 인터넷 프로토콜 (IP) 헤더와 송신 제어 프로토콜/사용자 데이터그램 프로토콜 (TCP/UDP) 헤더 사이의 심 헤더; 및/또는 하이퍼텍스트 전송 프로토콜 (HTTP) 헤더 내에 DL 토큰을 포함하는 것을 포함할 수도 있다.

하나의 양태에서, DL 토큰이 애플리케이션 서버에 의해 요청되었을 경우, DL 토큰은 디바이스로부터 전송된 응답을 포함하는 패킷으로부터 획득될 수도 있다. 또 다른 양태에서, DL 토큰은 디바이스로부터 전송된 애플리케이션 서비스를 개시하기 위한 요청으로부터 획득될 수도 있다.

도시되고 설명된 특정 구현예들은 단지 예들이고, 본원에서 이와 다르게 특정되지 않으면, 본 개시물을 구현하기 위한 유일한 방법으로서 해석되지 않아야 한다. 본 개시물에서의 다양한 예들이 여러 다른 파티셔닝 해결책들에 의해 실시될 수도 있다는 것은 당해 분야의 당업자에게 용이하게 명백하다.

본원에서 설명되고 도면들에서 예시된 컴포넌트들, 액트 (act) 들, 특징들, 및/또는 기능들 중의 하나 이상은 단일 컴포넌트, 액트, 특징, 또는 기능으로 재배열 및/또는 조합될 수도 있거나, 몇몇 컴포넌트들, 액트들, 또는 기능들로 구체화될 수도 있다. 추가적인 엘리먼트들, 컴포넌트들, 액트들, 및/또는 기능들은 또한 발명으로부터 이탈하지 않으면서 추가될 수도 있다. 본원에서 설명된 알고리즘들은 또한 소프트웨어로 효율적으로 구현될 수도 있고 및/또는 하드웨어로 구체화될 수도 있다.

설명에서, 엘리먼트들, 회로들, 기능부들, 및 모듈들은 본 개시물을 불필요하게 상세하게 모호하게 하지 않기 위하여 블록도 형태로 도시될 수도 있다. 반대로, 도시되고 설명된 특정 구현예들은 단지 예시적이고, 본원에서 이와 다르게 특정되지 않으면, 본 개시물을 구현하기 위한 유일한 방법으로서 해석되지 않아야 한다. 추가적으로, 블록 정의들 및 다양한 블록들 사이의 로직의 파티셔닝은 특정 구현예의 예시이다. 본 개시물이 여러 다른 파티셔닝 해결책들에 의해 실시될 수도 있다는 것은 당해 분야의 당업자에게 용이하게 명백하다. 대부분의 부분에 대하여, 타이밍 고려사항들 등등에 관한 세부사항들이 생략되었고, 여기서, 이러한 세부사항들은 본 개시물의 완전한 이해를 획득하기 위하여 필요한 것이 아니고, 관련 기술에서의 당업자들의 능력들 내에 있다.

게다가, 실시형태들은 플로우차트, 흐름도, 구조도, 또는 블록도로서 도시되어 있는 프로세스로서 설명될 수도 있다는 것이 주목된다. 플로우차트는 동작들을 순차적인 프로세스로서 설명할 수도 있지만, 동작들 중의 다수는 병렬로 또는 동시에 수행될 수 있다. 게다가, 동작들의 순서는 재배열될 수도 있다. 프로세스는 그 동작들이 완료될 때에 종결된다. 프로세스는 방법, 함수, 프로시저 (procedure), 서브루틴, 서브프로그램 등에 대응할 수도 있다. 프로세스가 함수에 대응할 때, 그 종결은 호출 함수 또는 주 함수로의 함수의 복귀에 대응한다.

당해 분야의 당업자들은 정보 및 신호들이 다양한 상이한 기술들 및 기법들 중의 임의의 것을 이용하여 표현될 수도 있다는 것을 이해할 것이다. 예를 들어, 이 설명의 전반에 걸쳐 참조될 수도 있는 데이터, 명령들, 커맨드들, 정보, 신호들, 비트들, 심볼들, 및 칩들은 전압들, 전류들, 전자기파들, 자기장들 또는 입자들, 광학 필드들 또는 입자들, 또는 그 임의의 조합에 의해 표현될 수도 있다. 일부 도면들은 제시 및 설명의 명료성을 위하여, 신호들을 단일 신호로서 예시할 수도 있다. 신호는 신호들의 버스를 표현할 수도 있고, 여기서, 버스는 다양한 비트 폭들을 가질 수도 있고, 본 개시물은 단일 데이터 신호를 포함하는 임의의 수의 데이터 신호들 상에서 구현될 수도 있다는 것이 당해 분야의 당업자에 의해 이해될 것이다.

"제 1", "제 2" 등과 같은 지정을 이용한 본원에서의 엘리먼트에 대한 임의의 참조는, 이러한 제한이 명시적으로 기재되지 않으면, 그 엘리먼트들의 수량 또는 순서를 제한하지 않는다는 것이 이해되어야 한다. 오히려, 이 지정들은 2 개 이상의 엘리먼트들 또는 엘리먼트의 사례들 사이를 구별하는 편리한 방법으로서 본원에서 이용될 수도 있다. 이에 따라, 제 1 및 제 2 엘리먼트들에 대한 참조는, 2 개의 엘리먼트들만이 거기에서 채용될 수도 있다는 것, 또는 제 1 엘리먼트가 일부의 방식으로 제 2 엘리먼트를 선행해야 한다는 것을 의미하지 않는다. 게다가, 이와 다르게 기재되지 않으면, 엘리먼트들의 세트는 하나 이상의 엘리먼트들을 포함할 수도 있다.

또한, 저장 매체는 판독 전용 메모리 (read-only memory; ROM), 랜덤 액세스 메모리 (random access memory; RAM), 자기 디스크 저장 매체들, 광학 저장 매체들, 플래시 메모리 디바이스들 및/또는 다른 머신-판독가능 매체들, 및 프로세서-판독가능 매체들, 및/또는 정보를 저장하기 위한 컴퓨터-판독가능 매체들을 포함하는, 데이터를 저장하기 위한 하나 이상의 디바이스들을 표현할 수도 있다. 용어들 "머신-판독가능 매체", "컴퓨터-판독가능 매체", 및/또는 "프로세서-판독가능 매체" 는 휴대용 또는 고정식 저장 디바이스들, 광학 저장 디바이스들, 및 명령 (들) 및/또는 데이터를 저장하거나, 포함하거나 운반할 수 있는 다양한 다른 매체들과 같은 비-일시적 (non-transitory) 매체들을 포함할 수도 있지만, 이것으로 제한되지는 않는다. 따라서, 본원에서 설명된 다양한 방법들은, "머신-판독가능 매체", "컴퓨터-판독가능 매체", 및/또는 "프로세서-판독가능 매체" 에 저장될 수도 있으며 하나 이상의 프로세서들, 머신들 및/또는 디바이스들에 의해 실행될 수도 있는 명령들 및/또는 데이터에 의해 완전히 또는 부분적으로 구현될 수도 있다.

또한, 실시형태들은 하드웨어, 소프트웨어, 펌웨어, 미들웨어, 마이크로코드, 또는 그 임의의 조합에 의해 구현될 수도 있다. 소프트웨어, 펌웨어, 미들웨어 또는 마이크로코드로 구현될 때, 필요한 태스크 (task) 들을 수행하기 위한 프로그램 코드 또는 코드 세그먼트들은 저장 매체 또는 다른 저장장치 (들) 과 같은 머신-판독가능 매체에 저장될 수도 있다. 프로세서는 필요한 태스크들을 수행할 수도 있다. 코드 세그먼트는 프로시저, 함수, 서브프로그램, 프로그램, 루틴, 서브루틴, 모듈, 소프트웨어 패키지, 클래스, 또는 명령들, 데이터 구조들, 또는 프로그램 명령문들의 임의의 조합을 표현할 수도 있다. 코드 세그먼트는 정보, 데이터, 아규먼트 (argument) 들, 파라미터들, 또는 메모리 내용들을 및/또는 전달함으로써 또 다른 코드 세그먼트 또는 하드웨어 회로에 결합될 수도 있다. 정보, 아규먼트들, 파라미터들, 데이터, 등은 메모리 공유, 메시지 전달, 토큰 전달, 네트워크 송신, 트래픽 등을 포함하는 임의의 적당한 수단을 통해 전달되거나, 포워딩되거나, 송신될 수도 있다.

본원에서 개시된 예들과 관련하여 설명된 다양한 예시적인 논리적 블록들, 엘리먼트들, 회로들, 모듈들, 기능부들, 및/또는 컴포넌트들은 범용 프로세서, 디지털 신호 프로세서 (DSP), 주문형 집적 회로 (ASIC), 필드 프로그래밍가능한 게이트 어레이 (FPGA) 또는 다른 프로그래밍가능한 로직 컴포넌트, 개별 게이트 또는 트랜지스터 로직, 개별 하드웨어 컴포넌트들, 또는 본원에서 설명된 기능들을 수행하도록 설계된 그 임의의 조합으로 구현되거나 수행될 수도 있다. 범용 프로세서는 마이크로프로세서일 수도 있지만, 대안적으로, 프로세서는 임의의 기존의 프로세서, 제어기, 마이크로제어기, 또는 상태 머신 (state machine) 일 수도 있다. 프로세서는 또한, 컴퓨팅 컴포넌트들의 조합, 예를 들어, DSP 및 마이크로프로세서, 다수의 마이크로프로세서들, DSP 코어와 함께 하나 이상의 마이크로프로세서들, 또는 임의의 다른 이러한 구성의 조합으로서 구현될 수도 있다. 본원에서 설명된 실시형태들을 실행하기 위하여 구성된 범용 프로세서는 이러한 실시형태들을 수행하기 위한 특수 목적 프로세서로 고려된다. 유사하게, 범용 컴퓨터는 본원에서 설명된 실시형태들을 수행하기 위하여 구성될 때에 특수 목적 컴퓨터로 고려된다.

본원에서 개시된 예들과 관련하여 설명된 방법들 또는 알고리즘들은 직접 하드웨어로, 프로세서에 의해 실행가능한 소프트웨어 모듈로, 또는 양자의 조합으로, 프로세싱 유닛, 프로그래밍 명령들, 또는 다른 방향들의 형태로 구체화될 수도 있고, 단일 디바이스 내에 포함될 수도 있거나 다수의 디바이스들에 걸쳐 분포될 수도 있다. 소프트웨어 모듈은 RAM 메모리, 플래시 메모리, ROM 메모리, EPROM 메모리, EEPROM 메모리, 레지스터들, 하드 디스크, 분리가능한 디스크, CD-ROM, 또는 당해 분야에서 알려진 임의의 다른 형태의 저장 매체에서 상주할 수도 있다. 저장 매체는 프로세서가 저장 매체로부터 정보를 판독할 수 있고 정보를 저장 매체에 기록할 수 있도록 프로세서에 결합될 수도 있다. 대안적으로, 저장 매체는 프로세서에 일체적일 수도 있다.

당해 분야의 당업자들은 본원에서 개시된 실시형태들과 관련하여 설명된 다양한 예시적인 논리적 블록들, 회로들, 기능부들, 모듈들, 및 알고리즘 단계들이 전자 하드웨어, 컴퓨터 소프트웨어, 또는 양자의 조합들로서 구현될 수도 있다는 것을 추가로 인식할 것이다. 하드웨어 및 소프트웨어의 이 교환가능성을 명확하게 예시하기 위하여, 다양한 예시적인 엘리먼트들, 컴포넌트들, 블록들, 회로들, 기능부들, 모듈들, 및 단계들은 일반적으로 그 기능성의 측면에서 위에서 설명되었다. 이러한 기능성이 하드웨어, 소프트웨어, 또는 그 조합으로서 구현되는지 여부는 특정한 애플리케이션과, 전체적인 시스템에 부과된 설계 제약들에 종속된다.

본원에서 설명된 발명의 다양한 특징들은 발명으로부터 이탈하지 않으면서 상이한 시스템들에서 구현될 수 있다. 상기한 실시형태들은 예들에 불과하고 발명을 제한하는 것으로 해석되지 않아야 한다는 것에 주목해야 한다. 실시형태들의 설명은 청구항들의 범위를 제한하는 것이 아니라, 예시적인 것으로 의도된 것이다. 이와 같이, 본 교시내용들은 다른 타입들의 장치들에 용이하게 적용될 수 있고, 다수의 대안들, 수정들, 및 변동들은 당해 분야의 당업자들에게 명백할 것이다.

Claims

디바이스에서 동작하는 방법으로서,
상기 디바이스에 의해, 하나 이상의 애플리케이션 서비스들과 연관된 애플리케이션 서버와의 접속을 개시하는 단계;
상기 접속을 개시하는 것에 응답하여, 네트워크 토큰을 상기 애플리케이션 서버로부터 획득하는 단계로서, 상기 네트워크 토큰은,
상기 디바이스 및 상기 애플리케이션 서버와 분리된 게이트웨이에 의해, 상기 애플리케이션 서버에 알려지지 않고 상기 디바이스에 알려지지 않은 비밀 키를 포함하는 입력 파라미터들의 세트를 갖는 함수로 유도되고,
하나 이상의 사용자-평면 데이터 흐름들의 세트의 제 1 사용자-평면 데이터 흐름과 연관되고,
상기 하나 이상의 애플리케이션 서비스들의 제 1 애플리케이션 서비스와 연관되고, 그리고
하나 이상의 사용자-평면 메시지들을 통해 상기 애플리케이션 서버로부터 상기 디바이스에 프로비저닝되는, 상기 네트워크 토큰을 획득하는 단계; 및
하나 이상의 업링크 (UL) 패킷들과 함께 상기 네트워크 토큰을, 상기 사용자-평면에서 상기 디바이스로부터 상기 애플리케이션 서버로 전송하는 단계를 포함하는, 디바이스에서 동작하는 방법.
삭제
삭제
제 1 항에 있어서,
상기 네트워크 토큰은 상기 디바이스의 디바이스 가입 프로파일 및 상기 제 1 애플리케이션 서비스의 정책 중 적어도 하나에 기초하는, 디바이스에서 동작하는 방법.
제 1 항에 있어서,
상기 네트워크 토큰은 상기 디바이스에 대하여 코어 네트워크에 의해 집행된 정책을 반영하는, 디바이스에서 동작하는 방법.
제 1 항에 있어서,
상기 접속을 개시하는 단계는 접속 요청을 전송하는 단계를 포함하고, 상기 접속 요청은 상기 네트워크 토큰에 대한 명시적 요청을 포함하는, 디바이스에서 동작하는 방법.
제 1 항에 있어서,
상기 접속을 개시하는 단계는 상기 네트워크 토큰의 묵시적 요청을 표시하는 패킷을 전송하는 단계를 포함하는, 디바이스에서 동작하는 방법.
제 7 항에 있어서,
상기 묵시적 요청은 제 1 패킷을 상기 애플리케이션 서버로 전송함으로써 표현되는, 디바이스에서 동작하는 방법.
제 1 항에 있어서,
상기 접속을 개시하는 단계는 상기 애플리케이션 서버로부터의 확인응답을 요구하는 패킷을 전송하는 단계를 포함하고, 상기 확인응답은 상기 네트워크 토큰을 상기 디바이스로 전송하는, 디바이스에서 동작하는 방법.
제 1 항에 있어서,
상기 네트워크 토큰은 사용자-평면 심 헤더 (shim header) 에서 상기 디바이스로부터 패킷 데이터 네트워크 (packet data network; PDN) 게이트웨이 (PDN gateway; P-GW) 로 전송되는, 디바이스에서 동작하는 방법.
제 10 항에 있어서,
상기 사용자-평면 심 헤더는 인터넷 프로토콜 (IP) 계층 위에 위치되는, 디바이스에서 동작하는 방법.
제 1 항에 있어서,
상기 네트워크 토큰은 IP 버전 6 (IPv6) 에서 정의된 바와 같이 인터넷 프로토콜 (IP) 확장 헤더에서 상기 디바이스로부터 패킷 데이터 네트워크 (PDN) 게이트웨이 (P-GW) 로 전송되는, 디바이스에서 동작하는 방법.
제 1 항에 있어서,
상기 네트워크 토큰은 패킷 데이터 컨버전스 프로토콜 (packet data convergence protocol; PDCP) 계층에서 상기 디바이스로부터 액세스 노드로 전송되고, 상기 액세스 노드에서 사용자-평면에 대한 범용 패킷 라디오 서비스 (general packet radio service; GPRS) 터널링 프로토콜 (GPRS tunneling protocol; GTP) 계층 (GTP layer for user-plane; GTP-U) 계층으로 복사되고, 상기 GTP-U 계층에서 상기 액세스 노드로부터 패킷 데이터 네트워크 (PDN) 게이트웨이 (P-GW) 로 전송되는, 디바이스에서 동작하는 방법.
디바이스로서,
무선 네트워크 상에서 통신하도록 구성된 네트워크 통신 인터페이스; 및
상기 네트워크 통신 인터페이스에 결합된 프로세싱 회로를 포함하고,
상기 프로세싱 회로는,
하나 이상의 애플리케이션 서비스들과 연관된 애플리케이션 서버와의 접속을 개시하고;
상기 접속을 개시하는 것에 응답하여, 네트워크 토큰을 상기 애플리케이션 서버로부터 획득하는 것으로서, 상기 네트워크 토큰은,
상기 디바이스 및 상기 애플리케이션 서버와 분리된 게이트웨이에 의해, 상기 애플리케이션 서버에 알려지지 않고 상기 디바이스에 알려지지 않은 비밀 키를 포함하는 입력 파라미터들의 세트를 갖는 함수로 유도되고,
하나 이상의 사용자-평면 데이터 흐름들의 세트의 제 1 사용자-평면 데이터 흐름과 연관되고,
상기 하나 이상의 애플리케이션 서비스들의 제 1 애플리케이션 서비스와 연관되고, 그리고
하나 이상의 사용자-평면 메시지들을 통해 상기 애플리케이션 서버로부터 상기 디바이스에 프로비저닝되는, 상기 네트워크 토큰을 획득하고; 그리고
하나 이상의 업링크 (UL) 패킷들과 함께 상기 네트워크 토큰을, 상기 사용자-평면에서 상기 디바이스로부터 상기 애플리케이션 서버로 전송하도록 구성되는, 디바이스.
네트워크에서의 게이트웨이 디바이스에서 동작하는 방법으로서,
상기 게이트웨이 디바이스에서, 사용자-평면을 통해 제 1 데이터 패킷을 수신하는 단계;
상기 제 1 데이터 패킷을 평가함으로써, 네트워크 토큰이 요청되는지를 결정하는 단계;
상기 네트워크 토큰이 요청될 경우에 상기 게이트웨이 디바이스에서 상기 네트워크 토큰을 유도하는 단계로서, 상기 네트워크 토큰은 상기 네트워크에 의해 유지된 디바이스 가입 프로파일에 기초하는, 상기 네트워크 토큰을 유도하는 단계;
상기 네트워크 토큰이 요청될 경우에 상기 제 1 데이터 패킷과 함께 상기 네트워크 토큰을 포함하는 단계; 및
상기 제 1 데이터 패킷 및 네트워크 토큰을 목적지로 전송하는 단계를 포함하는, 네트워크에서의 게이트웨이 디바이스에서 동작하는 방법.
제 15 항에 있어서,
상기 제 1 데이터 패킷은 애플리케이션 서버로 전송될 것이고, 상기 네트워크 토큰은 업링크 네트워크 토큰인, 네트워크에서의 게이트웨이 디바이스에서 동작하는 방법.
제 15 항에 있어서,
상기 제 1 데이터 패킷은 애플리케이션 서버로 전송될 것이고, 상기 네트워크 토큰은 다운링크 네트워크 토큰인, 네트워크에서의 게이트웨이 디바이스에서 동작하는 방법.
제 15 항에 있어서,
상기 제 1 데이터 패킷은 디바이스로 전송될 것이고, 상기 네트워크 토큰은 다운링크 네트워크 토큰인, 네트워크에서의 게이트웨이 디바이스에서 동작하는 방법.
제 18 항에 있어서,
상기 게이트웨이 디바이스에서, 상기 디바이스로부터 상기 다운링크 네트워크 토큰을 포함하는 제 2 데이터 패킷을 수신하는 단계; 및
상기 제 2 데이터 패킷 및 상기 다운링크 네트워크 토큰을 애플리케이션 서버로 전송하는 단계를 더 포함하는, 네트워크에서의 게이트웨이 디바이스에서 동작하는 방법.
제 15 항에 있어서,
상기 네트워크 토큰은 업링크 네트워크 토큰 및 다운링크 네트워크 토큰이고, 상기 업링크 네트워크 토큰은 상기 다운링크 네트워크 토큰과는 상이한, 네트워크에서의 게이트웨이 디바이스에서 동작하는 방법.
제 15 항에 있어서,
상기 게이트웨이 디바이스는 패킷 데이터 네트워크 (PDN) 게이트웨이 (P-GW) 인, 네트워크에서의 게이트웨이 디바이스에서 동작하는 방법.
제 15 항에 있어서,
상기 제 1 패킷은 상기 네트워크 토큰에 대한 명시적 요청을 포함하는, 네트워크에서의 게이트웨이 디바이스에서 동작하는 방법.
제 15 항에 있어서,
상기 제 1 패킷은 상기 네트워크 토큰에 대한 묵시적 요청을 표현하는, 네트워크에서의 게이트웨이 디바이스에서 동작하는 방법.
제 15 항에 있어서,
상기 네트워크 토큰이 요청되는지를 결정하는 단계는, 상기 제 1 패킷이 전송될 애플리케이션 서버, 또는 상기 제 1 패킷이 수신되는 애플리케이션 서버가 상기 네트워크 토큰을 요구하는지를 결정하는 것에 기초하는, 네트워크에서의 게이트웨이 디바이스에서 동작하는 방법.
삭제
제 15 항에 있어서,
상기 네트워크 토큰은: 상기 게이트웨이 디바이스에 알려진 비밀 키 (secret key), 클래스 인덱스, 소스 인터넷 프로토콜 (IP) 어드레스, 소스 포트 번호, 목적지 IP 어드레스, 목적지 포트 번호, 프로토콜 식별자 (protocol identifier; ID), 애플리케이션 ID, 우선순위, 및 서비스 품질 클래스 식별자 (quality of service class identifier; QCI) 중 적어도 하나를 포함하는 입력 파라미터들의 세트를 가지는 함수를 이용하여 유도되는, 네트워크에서의 게이트웨이 디바이스에서 동작하는 방법.
제 26 항에 있어서,
상기 클래스 인덱스는 네트워크 토큰 유도를 위하여 이용된 필드들을 정의하는, 네트워크에서의 게이트웨이 디바이스에서 동작하는 방법.
제 26 항에 있어서,
상기 네트워크 토큰은 상기 클래스 인덱스 및 상기 함수의 출력의 연결 (concatenation) 인, 네트워크에서의 게이트웨이 디바이스에서 동작하는 방법.
게이트웨이 디바이스로서,
무선 네트워크 상에서 통신하도록 구성된 네트워크 통신 인터페이스;
상기 네트워크 통신 인터페이스에 결합된 프로세싱 회로를 포함하고,
상기 프로세싱 회로는,
상기 게이트웨이 디바이스에서, 사용자-평면을 통해, 애플리케이션 서버로 전송될 패킷을 수신하고;
상기 패킷을 평가함으로써, 네트워크 토큰이 요청되는지를 결정하고;
상기 네트워크 토큰이 요청될 경우에 상기 게이트웨이 디바이스에서 상기 네트워크 토큰을 유도하는 것으로서, 상기 네트워크 토큰은 디바이스 가입 프로파일에 기초하는, 상기 네트워크 토큰을 유도하고;
상기 네트워크 토큰이 요청될 경우에 상기 패킷과 함께 상기 네트워크 토큰을 포함하고; 그리고
상기 패킷 및 네트워크 토큰을 상기 애플리케이션 서버로 전송하도록 구성되는, 게이트웨이 디바이스.
게이트웨이 디바이스에서 동작하는 방법으로서,
디바이스로부터 하나 이상의 애플리케이션 서비스들과 연관된 애플리케이션 서버로 전송된 제 1 네트워크 토큰에 대한 요청에 응답하여, 상기 게이트웨이 디바이스에서, 제 1 네트워크 토큰을 유도하는 단계;
상기 게이트웨이 디바이스에서, 상기 디바이스로부터 데이터 패킷을 수신하는 단계로서, 상기 데이터 패킷은 상기 애플리케이션 서버에 대응하는 적어도 목적지 어드레스 프리픽스를 포함하고, 상기 데이터 패킷은 제 2 네트워크 토큰을 포함하는, 상기 데이터 패킷을 수신하는 단계;
상기 제 2 네트워크 토큰을 검증하는 단계;
상기 검증이 성공적이지 않을 경우에, 상기 데이터 패킷을 폐기하는 단계; 및
상기 검증이 성공적일 경우에, 상기 데이터 패킷을 상기 애플리케이션 서버로 전송하는 단계를 포함하는, 게이트웨이 디바이스에서 동작하는 방법.
제 30 항에 있어서,
상기 데이터 패킷은 사용자-평면 메시지에서 수신되는, 게이트웨이 디바이스에서 동작하는 방법.
제 30 항에 있어서,
상기 게이트웨이 디바이스는 패킷 데이터 네트워크 (PDN) 게이트웨이 (P-GW) 인, 게이트웨이 디바이스에서 동작하는 방법.
제 30 항에 있어서,
상기 제 2 네트워크 토큰을 검증하는 단계는,
상기 데이터 패킷으로부터 획득된 입력 파라미터들 및 상기 게이트웨이 디바이스에 알려진 키를 이용하여 제 1 함수로부터 상기 제 1 네트워크 토큰의 복제본 (duplicate) 을 유도하는 단계; 및
상기 제 1 네트워크 토큰의 상기 복제본을 상기 제 2 네트워크 토큰과 비교하는 단계를 포함하고,
검증은 상기 제 1 네트워크 토큰의 상기 복제본이 상기 제 2 네트워크 토큰과 동일할 경우에 성공적인, 게이트웨이 디바이스에서 동작하는 방법.
제 30 항에 있어서,
상기 제 2 네트워크 토큰은 IP 헤더로부터 분리된 심 헤더에서 상기 디바이스로부터 상기 게이트웨이 디바이스로 전송되는, 게이트웨이 디바이스에서 동작하는 방법.
제 30 항에 있어서,
상기 제 2 네트워크 토큰은 인터넷 프로토콜 (IP) 버전 6 (IPv6) 에서 정의된 IP 확장 헤더에서 상기 디바이스로부터 상기 게이트웨이 디바이스로 전송되는, 게이트웨이 디바이스에서 동작하는 방법.
제 30 항에 있어서,
상기 제 2 네트워크 토큰은 패킷 데이터 컨버전스 프로토콜 (PDCP) 계층에서 상기 디바이스로부터 액세스 노드로 전송되고, 상기 액세스 노드에서 사용자-평면에 대한 범용 패킷 라디오 서비스 (GPRS) 터널링 프로토콜 (GTP) 계층 (GTP-U) 계층으로 복사되고, 상기 GTP-U 계층에서 상기 액세스 노드로부터 상기 게이트웨이 디바이스로 전송되는, 게이트웨이 디바이스에서 동작하는 방법.
게이트웨이 디바이스로서,
무선 네트워크 상에서 통신하도록 구성된 네트워크 통신 인터페이스;
상기 네트워크 통신 인터페이스에 결합된 프로세싱 회로를 포함하고,
상기 프로세싱 회로는,
디바이스로부터 하나 이상의 애플리케이션 서비스들과 연관된 애플리케이션 서버로 전송된 제 1 네트워크 토큰에 대한 요청에 응답하여, 제 1 네트워크 토큰을 유도하고;
상기 디바이스로부터 데이터 패킷을 수신하는 것으로서, 상기 데이터 패킷은 상기 애플리케이션 서버에 대응하는 적어도 목적지 어드레스 프리픽스를 포함하고, 상기 데이터 패킷은 제 2 네트워크 토큰을 포함하는, 상기 데이터 패킷을 수신하고;
상기 제 2 네트워크 토큰을 검증하고;
검증이 성공적이지 않을 경우에, 상기 데이터 패킷을 폐기하고; 그리고
검증이 성공적일 경우에, 상기 데이터 패킷을 상기 애플리케이션 서버로 전송하도록 구성되는, 게이트웨이 디바이스.
애플리케이션 서버에서 동작하는 방법으로서,
하나 이상의 애플리케이션 서비스들과 연관된 상기 애플리케이션 서버에 의해, 디바이스로 제 1 애플리케이션 서비스를 개시하기 위한 요청을 전송하는 단계;
상기 제 1 애플리케이션 서비스를 개시하기 위한 상기 요청을 전송하는것에 응답하여, 네트워크 토큰을 상기 디바이스로부터 획득하는 단계로서, 상기 네트워크 토큰은,
상기 디바이스 및 상기 애플리케이션 서버와 분리된 게이트웨이에 의해, 상기 애플리케이션 서버에 알려지지 않고 상기 디바이스에 알려지지 않은 비밀 키를 포함하는 입력 파라미터들의 세트를 갖는 함수로 유도되고,
하나 이상의 사용자-평면 데이터 흐름들의 세트의 제 1 사용자-평면 데이터 흐름과 연관되고,
상기 제 1 애플리케이션 서비스와 연관되고, 그리고
하나 이상의 사용자-평면 메시지들을 통해 상기 디바이스로부터 상기 애플리케이션 서버로 전송되는, 상기 네트워크 토큰을 획득하는 단계; 및
상기 사용자-평면에서 상기 애플리케이션 서버로부터 상기 디바이스로 하나 이상의 다운링크 (DL) 패킷들과 함께 상기 네트워크 토큰을 전송하는 단계를 포함하는, 애플리케이션 서버에서 동작하는 방법.
삭제
제 38 항에 있어서,
상기 네트워크 토큰은 상기 디바이스의 디바이스 가입 프로파일 및 상기 제 1 애플리케이션 서비스의 정책 중 적어도 하나에 기초하는, 애플리케이션 서버에서 동작하는 방법.
제 38 항에 있어서,
상기 네트워크 토큰은 상기 디바이스에 대하여 코어 네트워크에 의해 집행된 정책을 반영하는, 애플리케이션 서버에서 동작하는 방법.
제 38 항에 있어서,
상기 제 1 애플리케이션 서비스를 개시하기 위한 상기 요청은 상기 네트워크 토큰에 대한 명시적 요청을 포함하는, 애플리케이션 서버에서 동작하는 방법.
제 38 항에 있어서,
상기 제 1 애플리케이션 서비스를 개시하기 위한 상기 요청을 전송하는 단계는 상기 네트워크 토큰에 대한 묵시적 요청을 표현하는 패킷을 전송하는 단계를 포함하는, 애플리케이션 서버에서 동작하는 방법.
하나 이상의 애플리케이션 서비스들과 연관된 애플리케이션 서버로서,
네트워크 통신 인터페이스;
상기 네트워크 통신 인터페이스에 결합된 프로세싱 회로를 포함하고,
상기 프로세싱 회로는,
디바이스로 애플리케이션 서비스를 개시하기 위한 요청을 전송하고;
상기 디바이스로 상기 애플리케이션 서비스를 개시하기 위한 상기 요청을 전송하는 것에 응답하여, 네트워크 토큰을 상기 디바이스로부터 획득하는 것으로서, 상기 네트워크 토큰은,
상기 디바이스 및 상기 애플리케이션 서버와 분리된 게이트웨이에 의해, 상기 애플리케이션 서버에 알려지지 않고 상기 디바이스에 알려지지 않은 비밀 키를 포함하는 입력 파라미터들의 세트를 갖는 함수로 유도되고,
하나 이상의 사용자-평면 데이터 흐름들의 세트의 제 1 사용자-평면 데이터 흐름과 연관되고;
상기 하나 이상의 애플리케이션 서비스들의 제 1 애플리케이션 서비스와 연관되고; 그리고
하나 이상의 사용자-평면 메시지들을 통해 상기 디바이스로부터 상기 애플리케이션 서버로 전송되는, 상기 네트워크 토큰을 획득하고, 그리고
상기 사용자-평면에서 상기 애플리케이션 서버로부터 상기 디바이스로 하나 이상의 다운링크 (DL) 패킷들과 함께 상기 네트워크 토큰을 전송하도록 구성되는, 애플리케이션 서버.