KR102585690B1

KR102585690B1 - 사용량 모니터링 데이터 제어

Info

Publication number: KR102585690B1
Application number: KR1020217018912A
Authority: KR
Inventors: 푸엔시슬라 가르시아 아조레로; 수사나 페르난데즈 알론소; 안토니오 이니에스타 곤잘레즈; 아이린 마르틴 카벨로; 이그나시오 리바스 몰리나
Original assignee: 텔레호낙티에볼라게트 엘엠 에릭슨(피유비엘)
Priority date: 2018-11-19
Filing date: 2019-09-24
Publication date: 2023-10-06
Also published as: KR20210091302A; JP7247337B2; CN113169893A; EP3868057A2; US20220014562A1; CN117714291A; EP4270891A1; KR20230145224A; CN113169893B; EP3868057B1; WO2020104867A3; JP2024150489A; JP2023085329A; CN117579490A; ZA202104186B; JP7516598B2; DK3868057T3; JP2022511662A; WO2020104867A2

Abstract

방법은, 정책 기능이 정보에 대한 요청을 디포지토리 기능으로 송신하는 단계; 및 정책 기능이 요청에 대한 응답을 수신하는 단계를 포함하고, 여기서, 응답은, 한계 식별자를 포함하는 usageMonDataLimit 인스턴스; 및 usageMonDataLimit 인스턴스에 대응하는 usageMonData 인스턴스를 포함하고, 여기서, usageMonData 인스턴스가 또한 한계 식별자를 포함한다.

Description

사용량 모니터링 데이터 제어

본 개시내용은 사용량 모니터링 데이터의 관리에 관한 것이다.

사용량 모니터링 기능성은 네트워크 운영자가 가입자의 데이터 사용량을 제어할 수 있게 한다. 이는 서비스 레벨에서 또는 PDU 세션 레벨마다 이루어질 수 있다. 예컨대, 네트워크 운영자는 특정 가입자가 한 달에 5 기가바이트 초과의 넷플릭스 데이터를 다운로드할 수 없는 것을 지정할 수 있다.

사용량 모니터링 기능성은 정책 기능(예컨대, 4G 정책 및 과금 규칙 기능(Policy and Charging Rules Function)(PCRF) 또는 5G 정책 제어 기능(Policy Control Function)(PCF))을 구현하는 네트워크 노드에 의해 제어된다. 모니터링 키는, 트래픽 핸들링 네트워크 기능(예컨대, 4G PGW/UP 또는 5G SMF/UPF)이 그 모니터링 키와 연관된 트래픽을 모니터링할 수 있게 하기 위해, 정책 기능(예컨대, PCRF/PCF)에 의해 배정된다.

모니터링 키는 정책 기능에 의해 배정되고, 모니터링이 서비스 레벨에서 적용될 때 정책 규칙들(예컨대, PCC 규칙(들))의 일부로서 제공되거나, 또는 모니터링이 세션(예컨대, IP-CAN/PDU 세션)에 적용될 때 세션 정보의 일부로서 제공된다. 동일한 모니터링 키를 공유하는 모든 서비스 데이터 흐름들 또는 애플리케이션들은, APN(4G)/DNN(5G) 기반으로, 가입자의 단말 디바이스(사용자 장비(UE)로 또한 알려져 있음)에 대한 공통 허용 사용량을 가질 것이다.

사용량 모니터링 정보는 SPR(4G) 또는 UDR(4G 및 5G)에 저장된다.

데이터 베이스에 대한 인터페이스는 비-5G 시나리오들 경우 지정되지 않는다. 5G에서, 3GPP TS 23.503(스테이지 2) 및 TS 29.519(스테이지 3)는 PCF와 UDR 사이의 인터페이스를 지정한다.

특정 난제들이 현재 존재한다. 3GPP TS 29.519 V15.1.0("TS 29.519")은 PCF와 통합 데이터 리포지토리(Unified Data Repository)(UDR) 사이의 인터페이스를 지정한다. TS 29.519에 따르면, 사용량 모니터링 정보를 제어하기 위한 특정 리소스가 정의된다. 사용량 모니터링 정보는 이 구조: {apiRoot}/nudr-dr/v1/policy-data{ueId}/sm-data/{usageMonId}에 따라 저장된다.

PCF는 UsageMonId와 관련된 남아 있는 사용량을 저장하기 위해 사용량 모니터링 리소스를 생성할 수 있다. 이 리소스는 또한, 대응하는 한계가 더 이상 존재하지 않으면 제거될 수 있다. PCF는 PDU 세션의 수명 동안 임의의 순간에 UE id 및 usageMonId와 연관된 사용량 모니터링 정보를 획득 및 수정할 수 있다:

PCF가 usageMonId를 어떻게 도출하는지, 또는 usageMonId가 사용량 한계들(UsageMonDataLimit 데이터 타입) 또는 모니터링 데이터(UsageMonData) 내의 정보와 어떻게 관련되는지는 특정되지 않는다.

UsageMonitoringInformation 리소스에 대한 리소스 정의는 "usageMonId" 변수 필드에서 어떤 식별자를 사용할지를 명확하게 정의하지 않는다.

"usageMonId" 변수 필드는 PCF가 SMF에 대해 트래픽을 모니터링하기 위해 사용하는 모니터링 키에 대응하는 것으로 가정될 수 있다. 그러나, 모니터링 키가 "usageMonId"에서 사용되는 경우, 현재 지정된 바와 같이 (즉, UE 및 DNN마다) 모니터링 키의 스코프(scope)를 제한할 필요가 있다. 모니터링 키 값들의 다음의 가능한 새로운 스코프들이 고려될 수 있다.

1) S-NSSAI/DNN 쌍마다 모니터링 키 값들을 스코핑(scoping)한다. 그러나, 모니터링 키 값들이 S-NSSAI/DNN 쌍마다 스코핑되는 경우, 이는 상이한 S-NSSAI/DNN 조합들에 대한 사용량의 누적의 가능성을 제한할 것이다. 추가하여, 현재의 규격에 대해 다음의 수정들이 요구될 것이다: UsageMonitoringInformation 개별 리소스는 상이한 한계들에 대응하는 누적 사용량 정보를 표현할 수 있다. 결과로서, UsageMonData는 S-NSSAI/DNN 정보를 포함하도록 업데이트될 필요가 있고, 누산기 업데이트들 동안 더 높은 제어를 유지하기 위해, PATCH 방법이 PUT 대신에 사용되어야 한다.

2) 동일한 한계 정의에 속하는 DNN/S-NSSAI 쌍들에 대해 동일한 모니터링 키 값이 할당되고, 상이한 한계들이 항상 모니터링 키들에 대해 상이한 값들을 획득하도록, 한계 정의마다 모니터링 키 값들을 스코핑한다. 이와 같이 이루어지는 경우, 이는 SMF에서의 모니터링 사용량과 누적 사용량을 링크하여 현재 모니터링 키가 정의되는 방식을 제한할 것이다. 다음의 암시들이 고려될 필요가 있을 것이다: UsageMonitoringInformation 개별 리소스는 한계에 대응하는 누적 사용량 정보를 표현한다. 결과적으로, DNN/S-NSSAI 정보는, Sm-Data 리소스에서의 한계 정의에서 DNN/S-NSSAI 정보가 고려되기 때문에, UsageMonitoringInformation 리소스와 관련되지 않는다. S-NSSAI/DNN 질의 파라미터들이 제거될 수 있다.

3) 모니터링 키들에 대한 값들이 고유하도록, 배포(deployment)마다 모니터링 키 값들을 스코핑한다. 이는 UsageMonitoringInformation 개별 리소스가 S-NSSAI/DNN 쌍에 대한 최신 업데이트에 대응하는 누적 사용량 정보를 표현하게 한다. 결과적으로, DNN/S-NSSAI 정보는, 모니터링 키를 이미 포함하는 Sm-Data 리소스에서의 한계 정의에서 DNN/S-NSSAI 정보가 고려되기 때문에, UsageMonitoringInformation 리소스와 관련되지 않는다. S-NSSAI/DNN 질의 파라미터들은 제거될 수 있고, UsageMonitoringInformation 개별 리소스는 정확한 한계들의 정보를 포함하지 않지만, 최종 PDU 세션 업데이트에서 남아 있는 값을 포함한다.

위의 가능성들 각각은, 사용자 데이터 베이스에서 누적이 수행되는 방식으로부터 SMF/UPF에서의 사용량 모니터링의 컨텍스트에서의 그의 사용량을 분리하는, 현재 모니터링 키가 사용되는 방식을 제한한다.

따라서, 본 개시내용은 특정 사용량 한계를 식별하는 "usageMonId" 리소스 식별자(예컨대, URI) 변수에서 식별자를 사용하는 것을 제안한다. 이 식별자는 "누산기/한계 식별자" 또는 (약어 "limitId")로 지칭될 수 있다. UsageMonitoringInformation 개별 리소스는 한계 식별자에 의해 식별되는 특정 한계에 대응하는 누적 사용량 정보를 표현한다. 결과적으로, 모니터링 키 값들의 정의에서 제한이 없다. 이러한 솔루션은 또한, UsageMonDataLimit 및 UsageMonData 데이터 타입들에 limitId가 포함될 것을 요구한다. 제안된 솔루션의 이점은 모니터링 키의 현재 스코프에 관하여 가장 높은 정도의 유연성을 제공한다는 것이다. 제안된 솔루션은 또한, UDR에서 누적이 이루어지는 방식으로부터의 모니터링 키의 사용의 분리를 허용하고, 누적이 이루어지는 방식에서 유연한 모델들을 추가로 허용한다. 모니터링 키의 정의에서 제한이 없는 것으로 인해, DNN과 S-NSSAI의 상이한 조합들마다 누적이 이루어질 수 있는 상이한 비즈니스 모델들이 허용된다. 추가적인 이점은 사용량 모니터링이 지정된 방식에 영향이 없다는 것이다.

따라서, 일 양태에서, 방법이 제공되고, 방법은 정책 기능(예컨대, PCF)이 정보에 대한 요청을 디포지토리(depository) 기능(예컨대, UDR)로 송신하는 단계를 포함한다. 방법은 또한, 정책 기능이 응답을 수신하는 단계를 포함하고, 여기서, 응답은: 한계 식별자를 포함하는 usageMonDataLimit 인스턴스; 및 usageMonDataLimit 인스턴스에 대응하는 usageMonData 인스턴스를 포함하고, 여기서, usageMonData 인스턴스가 또한 한계 식별자를 포함한다.

일부 실시예들에서, 방법은 또한, 요청을 송신하기 전에, 정책 기능이 관리 기능으로부터 요청을 수신하는 단계; 및 요청에 대한 응답으로, 정책 기능이 디포지토리 기능으로부터 정보를 인출할 필요가 있는지 여부를 정책 기능이 결정하는 단계를 포함한다.

일부 실시예들에서, 방법은 또한, UsageMonDataLimit 인스턴스와 연관된 UsageMonData 인스턴스에 변경들이 발생할 때 정책 기능에 통지를 제공할 것을 디포지토리 기능에게 요청하는 요청을 정책 기능이 디포지토리 기능으로 송신하는 단계를 포함한다.

일부 실시예들에서, 방법은 또한, 정책 기능이 업데이트 요청을 디포지토리 기능으로 송신하는 단계를 포함한다. 일부 실시예들에서, 업데이트 요청은 한계 식별자를 포함하는 UsageMonData 인스턴스를 포함하는 HTTP PATCH 요청이거나, 또는 업데이트 요청은 한계 식별자를 포함하는 리소스 식별자(예컨대, URI)를 포함하는 HTTP PUT 요청이다.

일부 실시예들에서, 방법은 또한, 정책 기능이 가입해지 요청을 디포지토리 기능으로 송신하는 단계를 더 포함하고, 여기서, 가입해지 요청을 송신하는 단계는 한계 식별자를 포함하는 리소스 식별자를 포함하는 바디를 포함하는 HTTP PUT 요청을 송신하는 단계를 포함한다.

일부 실시예들에서, usageMonDataLimit 인스턴스는: usageMonDataLimit 인스턴스가 PDU 세션 레벨에서 적용되는지 또는 서비스 레벨에서 적용되는지를 표시하는 사용량 모니터링 레벨 인스턴스, 시작 일자 및 시간을 표시하는 시작 일자 정보, 종료 일자 및 시간을 표시하는 종료 일자 정보, 최대 허용 트래픽 볼륨을 표시하는 사용량 한계 임계값, 또는 허용 사용량이 리셋될 필요가 있는 시간을 표시하는 데 사용하기 위한 리셋 기간 중 적어도 하나를 더 포함한다.

일부 실시예들에서, usageMonDataLimit 인스턴스는 usageMonDataLimit 인스턴스가 적용되는 S-NSSAI와 DNN 조합을 표시하는 데이터 스코프를 더 포함한다.

일부 실시예들에서, usageMonData 인스턴스는, usageMonData 인스턴스가 PDU 세션 레벨에서 적용되는지 또는 서비스 레벨에서 적용되는지를 표시하는 사용량 모니터링 레벨(umLevel) 인스턴스, 또는 허용 사용량 값 중 적어도 하나를 더 포함하고, 여기서, 허용 사용량 값은 남아 있는 허용 트래픽 볼륨을 표시하고/표시하거나 허용 사용량 값은 남아 있는 시간 길이를 표시한다.

일부 실시예들에서, usageMonData 인스턴스는 허용 사용량을 사용량 한계 임계값으로 리셋하기 위한 시간을 표시하는 정보를 더 포함한다.

다른 양태에서, 방법이 제공되고, 방법은, 디포지토리 기능(예컨대, UDR)이 정책 기능(예컨대, PCF)으로부터 정보에 대한 요청을 수신하는 단계를 포함한다. 방법은 또한, 디포지토리 기능이 요청에 대한 응답으로 응답을 송신하는 단계를 포함하고, 여기서, 응답은: 한계 식별자를 포함하는 usageMonDataLimit 인스턴스; 및 usageMonDataLimit 인스턴스에 대응하는 usageMonData 인스턴스를 포함하고, 여기서, usageMonData 인스턴스가 또한 한계 식별자를 포함한다.

일부 실시예들에서, 방법은 또한, 디포지토리 기능이 정책 기능으로부터 업데이트 요청을 수신하는 단계를 포함한다. 일부 실시예들에서, 업데이트 요청은 한계 식별자를 포함하는 UsageMonData 인스턴스를 포함하는 HTTP PATCH 요청이거나, 또는 업데이트 요청은 한계 식별자를 포함하는 리소스 식별자를 포함하는 HTTP PUT 요청이다.

일부 실시예들에서, 방법은 또한, 디포지토리 기능이 정책 기능으로부터 가입해지 요청을 수신하는 단계를 포함한다. 일부 실시예들에서, 가입해지 요청은 한계 식별자를 포함하는 리소스 식별자를 포함하는 바디를 포함하는 HTTP PUT 요청이다.

다른 양태에서, 명령어들을 포함하는 컴퓨터 프로그램이 제공되고, 명령어들은, 장치의 프로세싱 회로부에 의해 실행될 때, 장치로 하여금 본원에서 설명되는 방법들을 수행하게 한다. 다른 양태에서, 이전의 문단에서 설명된 컴퓨터 프로그램을 포함하는 캐리어가 제공되고, 캐리어는 전자 신호, 광 신호, 라디오 신호, 및 컴퓨터 판독가능 저장 매체 중 하나이다.

다른 양태에서, 정책 기능 장치가 제공된다. 정책 기능 장치는 정보에 대한 요청을 디포지토리 기능으로 송신하고, 요청에 대한 응답을 수신하도록 적응된다. 응답은, 한계 식별자를 포함하는 usageMonDataLimit 인스턴스, 및 usageMonDataLimit 인스턴스에 대응하는 usageMonData 인스턴스를 포함하고, 여기서, usageMonData 인스턴스가 또한 한계 식별자를 포함한다.

다른 양태에서, 디포지토리 기능 장치가 제공된다. 디포지토리 기능 장치는 정책 기능으로부터 정보에 대한 요청을 수신하고, 정책 기능으로부터의 요청에 대한 응답으로 응답을 송신하도록 적응된다. 응답은: 한계 식별자를 포함하는 usageMonDataLimit 인스턴스, 및 usageMonDataLimit 인스턴스에 대응하는 usageMonData 인스턴스를 포함하고, 여기서, usageMonData 인스턴스가 또한 한계 식별자를 포함한다.

본원에 포함되고 본 명세서의 일부를 형성하는 첨부 도면들은 다양한 실시예들을 예시한다.
도 1은 예시적인 리소스 구조를 예시한다.
도 2는 예시적인 메시지 흐름도이다.
도 3은 예시적인 메시지 흐름도이다.
도 4는 실시예에 따른 프로세스를 예시하는 순서도이다.
도 5는 실시예에 따른 프로세스를 예시하는 순서도이다.
도 6은 일 실시예에 따른 장치의 블록도이다.

위에서 언급된 바와 같이, TS 29.519는 PCF와 UDR 사이의 인터페이스를 지정한다. TS 29.519에 따르면, 사용량 모니터링 정보를 제어하기 위한 특정 리소스가 정의된다. 사용량 모니터링 정보는 이 구조: {apiRoot}/nudr-dr/v1/policy-data/{ueId}/sm-data/{usageMonId}에 따라 저장된다. 리소스 구조는 도 1에 도시된다.

제안된 솔루션은 TS 29.519의 현재 버전에 대한 변경들을 요구한다. TS 29.519의 섹션 5.4.2는 다양한 구조화된 데이터 타입들을 정의한다. 정의된 구조화된 데이터 타입들 중 하나는 "UsageMonDataLimit" 타입이고, 이는 TS 29.519의 표 5.4.2.6-1에서 정의된다. 이 표는 아래에 도시된다:

UsageMonDataLimit 타입은 다른 속성들을 포함하도록 시간 경과에 따라 변경될 수 있다. 예컨대, UsageMonDataLimit 타입은 또한, "scopes"이라는 이름을 갖는 속성을 포함할 수 있다. "scopes" 속성은 타입 UsageMonDataScope이고, usageMonDataLimit 인스턴스가 적용되는 S-NSSAI와 DNN 조합을 식별하는 정보를 포함한다.

본 개시내용은 UsageMonDataLimit 타입이 "limitId"로 명명된 속성을 포함하도록 정의를 수정하는 것을 제안한다. limitId 속성은 "string"의 데이터 타입을 갖고, 필수적(M)이고, 1의 카디널리티(cardinality)를 갖는다. 이 새로운 속성에 대한 설명은: "한계를 식별한다"이다. 즉, limitId 속성은 사용량 모니터링 제어 인스턴스를 식별한다.

정의된 구조화된 데이터 타입들 중 다른 하나는 "UsageMonData" 타입이고, 이는 아래에 도시된 TS 29.519의 표 5.4.2.7-1에서 현재 정의된다:

본 개시내용은 "monKey" 속성을 "limitId"로 명명된 속성으로 대체하는 것을 제안한다. limitId 속성은 "string"의 데이터 타입을 갖고, 필수적(M)이고, 1의 카디널리티를 갖는다. 이 새로운 속성에 대한 설명은: "UsageMonDataLimit 데이터 타입(TS 29.519의 하위조항 5.4.2.6 참조)의 'limitId' 속성에서 정의되는 바와 같은 한계를 식별한다"이다.

UsageMonData 타입은 다른 속성들을 포함하도록 시간 경과에 따라 변경될 수 있다. 예컨대, UsageMonData 타입은 또한, "resetTime"이라는 이름을 갖는 속성을 포함할 수 있다. "resetTime" 속성은 타입 DateTime이고, 허용 사용량을 대응하는 UsageMonDataLimit의 usageLimit으로 다시 리셋하기 위한 시간을 표시하는 정보를 포함한다.

TS 29.519의 섹션 5.2.6은 "UsageMonitoringInformation" 리소스를 설명한다. TS 29.519의 섹션 5.2.6.1에서 설명되는 바와 같이, UsageMonitoringInformation "리소스는 UDR에서 생성되고 ueId 및 usageMonId와 연관된 개별 사용량 모니터링 리소스를 표현한다".

TS 29.519의 섹션 5.2.6.2는 "리소스 정의"를 제공한다. 구체적으로, 섹션은 리소스에 대한 리소스 식별자가: "{apiRoot}/nudr-dr/v1/policy-data/{ueId}/sm-data/{usageMonId}"인 것을 제공한다. TS 29.519의 섹션 5.2.6.2는, (TS 29.519의 표 5.2.6.2-1에 대응하는) 아래의 표에 도시된 바와 같이, 변수들 apiRoot, ueId, 및 usageMonId를 현재 정의한다.

본 개시내용은, 위에서 설명된 바와 같이, usageMonId 변수가 "개별 SM 정책 사용량 모니터링 리소스의 고유 식별자"일 뿐만 아니라 UsageMonDataLimit 데이터 타입의 "limitId" 속성에서 정의되는 바와 같은 대응하는 한계의 아이덴티티를 포함하도록, usageMonId의 정의를 더 확장한다. 본 개시내용은, UsageMonitoringInformation 리소스에 대해 GET 방법에 의해 URI 질의 파라미터들이 지원되지 않도록, 기술 규격을 변경하는 것을 추가로 제안한다.

도 2는, 예컨대, UDR(204)과 통신하는 PCF(202)를 도시하는 메시지 흐름도이다. UDR(204)은 PCF(202)가 사용자에 대한 정책 데이터, S-NSSAI, 및 DNN을 저장 및 검색하는 가입자 리포지토리이다. PCC 흐름들에서의 UDR과의 상호작용들에 대한 세부사항들은 C3-186391(www.3gpp.org/FTP/Meetings_3GPP_SYNC/CT3/Inbox/C3-186391.zip에서 현재 입수가능함)에서 동의되었다.

도 2에 도시된 이 절차는 로밍 및 비-로밍 시나리오들 둘 모두에 관한 것이다. 홈 라우팅 로밍 경우에서, PCF(202)는 H-PCF로서 기능한다. LBO 로밍 경우에서, PCF(202)는 V-PCF로서 기능하고, 단계 2 내지 4는 스킵될 수 있다.

단계 1: SMF(201)가 사용자 장비(UE)로부터 PDU 세션 확립 요청을 수신한다. 즉, SMF(201)는 SMF를 향해 UE에 의해 송신된 PDU 세션 확립 요청을 수신한다. SMF(201)는 TS 29.513의 하위조항 8.3에서 설명되는 바와 같이 PCF를 선택하고, HTTP POST 요청을 리소스 URI "{apiRoot}/npcf-smpolicycontrol/v1/sm-policies"로 전송함으로써 Npcf_SMPolicyControl_Create 서비스 동작을 인보크한다. 요청 동작은 SUPI, PDU 세션 ID, PDU 세션 타입, DNN, 및 S-NSSAI를 제공하고, GPSI, 내부 그룹 식별자, 액세스 타입, IPv4 어드레스 또는 IPv6 네트워크 프리픽스(이용가능한 경우), PEI(SMF(201)에서 수신되는 경우), 사용자 위치 정보, UE 시간대, 서빙 네트워크, RAT 타입, 과금 정보, 가입된 세션-AMBR, 및 가입된 디폴트 5QI/ARP(이용가능한 경우)를 제공할 수 있다. 요청 동작은 또한, SM 관련 정책들이 업데이트될 때 통지를 전송할 곳을 PCF에게 표시하기 위해 통지 URI를 포함한다.

단계 2: PCF(202)가 SUPI 및 DNN에 대한 가입 데이터를 갖고 있는지 여부를 PCF(202)가 결정한다. PCF(202)가 SUPI 및 DNN에 대한 가입 데이터를 갖고 있지 않은 경우, PCF(202)는 UDR(204)로 Nudr_DataRepository_Query 서비스 동작을 인보크한다(예컨대, PCF(202)는 TS 29.519에서 지정된 바와 같이 리소스 URI: {apiRoot}/nudr-dr/v1/policy-data/{ueId}/sm-data를 식별하는 HTTP GET 요청을 UDR(204)로 전송한다).

단계 3: UDR(204)이 GET 요청을 수신한 후에 HTTP "200 OK" 응답을 PCF(202)로 전송한다. 응답은 {apiRoot}/nudr-dr/v1/policy-data/{ueId}/sm-data 하의 리소스들을 포함하고, 이는 한계 정의를 갖는 UsageMonDataLimit 적용가능 인스턴스들, 및 사용량 소비 정보를 갖는 UsageMonData 적용가능 인스턴스들을 포함한다.

UsageMonDataLimit 인스턴스들은 …/sm-data 리소스에 저장되고, UsageMonData 인스턴스들은 /{usageMonId} 리소스에 저장되고, 이들 둘 모두는 …/sm-data 리소스 URI에 대한 GET 요청으로 검색된다는 점에 유의한다.

각각의 UsageMonDataLimit 인스턴스는, 정의된 usageLimit(예컨대, "usageLimit" : "500MB") 및 다른 임의적 파라미터들과 함께, 한계의 이름을 식별하는 "limitId" 속성(예컨대, "limitId" : "Facebook-limit")을 포함한다.

각각의 UsageMonData 인스턴스는, "allowedUsage" 속성에서의 남아 있는 사용량(예컨대, "allowedUsage" : "200MB")과 함께, 한계의 이름을 식별하는 "limitId" 속성(예컨대, "limitId" : "Facebook-limit")을 포함한다.

UDR(204)은 기존의 {usageMonId}에 따라 UsageMonData를 제공한다. UsageMonData는 monitoringKey 대신에 limitId를 포함한다.

단계 4: PCF(202)가 UDR(204)에 의해 송신된 응답을 수신할 때, PCF(202)는 응답이 UE에 대한 UsageMonDataLimit 인스턴스를 포함하는지 여부를 검출한다. PCF(202)가 UE에 대한 UsageMonDataLimit이 있는 것을 검출하는 경우, PCF(202)는 UsageMonDataLimit 인스턴스와 연관된 UsageMonData 인스턴스(즉, UsageMonDataLimit 인스턴스에 포함되고 UsageMonDataLimit 인스턴스를 식별하는 동일한 limitId를 포함하는 UsageMonData 인스턴스)에 변경들이 발생할 때 PCF(202)에 통지들을 제공할 것을 UDR(204)에게 요청할 수 있다. PCF(202)는 Nudr_DataRepository_Subscribe 서비스 동작을 인보크함으로써(예컨대, URI: "{apiRoot}/nudr-dr/v1/policy-data/{ueId}/sm-data/{usageMonId}"(여기서, "usageMonId"는 수신된 UsageMonDataLimit 인스턴스에 포함된 "limitId"임)를 포함하는 HTTP 메시지를 UDR(204)로 송신함으로써) UDR(204)로부터의 이러한 통지들을 요청한다. PCF(202)는 또한, sm-data 리소스에서 표현되는 데이터에 대한 변경들의 통지를 수신하는 것에 대해 가입할 수 있다는 점에 유의한다.

단계 5: UDR(204)이 PCF(202)로부터의 가입을 확인응답하기 위해 HTTP "201 Created" 응답을 전송한다.

단계 6: PCF(202)가 정책 판정이 CHF(206)에서 이용가능한 정책 카운터들의 상태에 의존한다고 결정하고, 이러한 보고가 가입자에 대해 확립되지 않은 경우, PCF(202)는 3GPP TS 29.594 V15.1.0의 하위조항 5.3.2에서 정의되는 바와 같은 초기 소비 한계 보고 검색(Initial Spending Limit Report Retrieval)을 개시한다. 정책 카운터 상태 보고가 가입자에 대해 이미 확립되어 있고, PCF(202)가 추가적인 정책 카운터들의 상태가 요구된다고 결정하는 경우, PCF(202)는 3GPP TS 29.594 V15.1.0의 하위조항 5.3.3에서 정의되는 바와 같은 중간 소비 한계 보고 검색을 개시한다.

단계 7: PCF(202)가 단계 6에서 제공된 정보를 결정하기 위해 정책 판정을 행한다.

단계 8: PCF(202)가, 3GPP TS 29.512 V15.1.0의 하위조항 4.2.2에서 설명되는 바와 같이, 결정된 정책들과 함께 HTTP "201 Created" 응답을 SMF(201)로 전송한다. 이 단계 후에, PCF(202)는 PDU 세션과 연관된 SMF(201) 이벤트들에 가입할 수 있다.

도 3은 PCF(202) 및 UDR(204)을 포함하는 다양한 기능들 사이의 통신들을 도시하는 다른 메시지 흐름도이다.

단계 1: SMF(201)가 SM 관련 정책의 컨텍스트를 삭제할 것을 PCF에게 요청하기 위해, 리소스 URI로서 "{apiRoot}/npcf-smpolicycontrol/v1/sm-policies/{smPolicyId}/delete"를 갖는 HTTP POST 요청을 전송함으로써, Npcf_SMPolicyControl_Delete 서비스 동작을 인보크한다. 요청 동작은 사용량 모니터링 정보(적용가능한 경우) 및 액세스 네트워크 정보를 포함할 수 있다.

단계 2: Npcf_SMPolicyControl_Delete 서비스 동작의 수신 시에, PCF는 AF(301)가 통지받을 것을 요구하는 PCC 규칙들을 식별하고, PDU 세션에 대한 PCC 규칙들을 제거한다.

단계 3: SMF(201)가 PDU 세션에 적용되는 모든 PCC 규칙들을 제거한다.

단계 4: PCF(202)는, AF(301)에 의해 서비스가 요청되는 경우, 서비스에 대한 송신 리소스들이 없는 것을 표시하기 위해, 리소스 URI로서 "{notifUri}/notify"를 갖는 HTTP POST 요청을 AF(301)로 전송함으로써, Npcf_PolicyAuthorization_Notify 서비스 동작을 인보크한다.

단계 5: AF(301)가 HTTP "204 No Content" 응답을 PCF(202)로 전송한다.

단계 6: AF(301)가 리소스 URI "{apiRoot}/npcf-policyauthorization/v1/app-sessions/{appSessionId}/delete"로 HTTP POST 요청을 전송함으로써, Npcf_PolicyAuthorization_Delete 서비스 동작을 인보크한다. 요청은 가입할 이벤트들을 포함할 수 있다.

단계 7: PCF(202)가 AF 애플리케이션 세션 컨텍스트를 제거하고, HTTP "204 No Content" 응답을 AF로 전송한다. PCF(202)가 사용량 데이터 또는 액세스 네트워크 정보를 보고할 필요가 있는 경우, PCF(202)는 HTTP "200 OK" 응답을 전송한다. AF에 의해 사용량 임계치들이 이전에 제공되었고, PCF(202)가 AF에 아직 보고되지 않은 사용량 데이터를 갖고 있는 경우, PCF(202)는 최종 보고 후에 사용자에 의해 소비된 리소스들에 관하여 AF(301)에게 통보한다. 단계 1에서 SMF(201)가 액세스 네트워크 정보를 보고한 경우, 그리고 AF(301)가 이전에 액세스 네트워크 정보를 보고할 것을 PCF(202)에게 요청한 경우, PCF(202)는 액세스 네트워크 정보에 관하여 AF(301)에게 통보한다. PCF(202)는 또한, 그 AF 애플리케이션 세션에 대한 PCF(202) 검출 이벤트들에 대한 가입을 삭제한다.

단계 4a: PCF(202)가 다이어미터(diameter) ASR을 AF(301)로 전송함으로써 AF(301)에게 세션 중단을 표시한다.

단계 5a: AF(301)가 다이어미터 ASA를 PCF(202)로 전송함으로써 응답한다.

단계 6a: AF(301)가 세션이 종료된 것을 표시하기 위해 다이어미터 STR을 PCF(202)로 전송한다.

단계 7a: PCF(202)가 다이어미터 STA를 AF(301)로 전송함으로써 응답한다. 단계 4a, 5a, 6a, 및 7a는 "Rx" 경우에 대한 것이고, 즉, PCF(202)가 AF(301)와의 Rx 인터페이스를 지원하는 경우에 대한 것이다. Rx 인터페이스의 세부사항들은 3GPP TS 29.214 V15.4.0에서 발견될 수 있다.

단계 8: 이 세션이 이 가입자에 대한 최종 PDU 세션인 경우, 3GPP TS 29.594 V15.1.0의 조항 5.3.4에서 정의되는 바와 같은 최종 소비 한계 보고 요청이 전송된다. 이 가입자에 대한 임의의 기존 PDU 세션들이 정책 카운터 상태 보고를 요구하는 경우, 3GPP TS 29.594 V15.1.0의 조항 5.3.3에서 정의되는 바와 같은 중간 소비 한계 보고 요청이 가입된 정책 카운터들의 리스트를 변경하기 위해 전송될 수 있다.

단계 9: PCF(202)가 종료된 PDU 세션에 대한 PCC 규칙들을 제거하고, HTTP "204 No Content" 응답을 SMF(201)로 전송한다.

단계 10: SM 정책 연관 종료 시에, PCF(202)는 적용가능한 한계들에 대해 UDR에서 남아 있는 사용량을 업데이트한다. PCF(202)는 대응하는 "UsageMonData" 인스턴스들에 포함된 "allowedUsage" 속성에서의 남아 있는 사용량의 업데이트된 값들을 포함하는 PATCH 요청을 …/sm-data 리소스 URI로 전송할 수 있고, 여기서, 각각의 "UsageMonData" 인스턴스는 그의 "limitId"(예컨대, "limitId" : "Facebook-limit" 및 "allowedUsage" : "125MB")에 의해 식별된다. 대안적으로, PCF(202)는 PCF(202)가 업데이트할 필요가 있는 각각의 "UsageMonData" 인스턴스마다 …/{usageMonId} 리소스 URI로 PUT 요청을 전송할 수 있다. "usageMonId" 값은 "limitId" 값(예컨대, 페이스북 소비에 대한 …/facebook-limit 리소스 URI, 및 넷플릭스 프리미엄 소비에 대한 …/netflix-premium 리소스 URI)이다. UDR은 (모니터링 키를 사용하는 대신에) limitId와 관련된 남아 있는 사용량을 저장한다.

단계 11: UDR(204)이 HTTP "204 No Content" 응답을 PCF(202)로 전송한다.

단계 12: PCF(202)가 limitId에 의해 식별되는 리소스 ID …/{usageMonId}와 관련된 변경들을 수신하는 것에 대해 가입해지할 수 있다. PCF(202)는 또한, sm-data 리소스에서 표현되는 데이터에 대한 변경들의 통지를 수신하는 것에 대해 가입해지할 수 있다는 점에 유의한다. …/{usageMonId}에서 표현되는 사용량 모니터링 데이터의 변경들에 대한 가입을 종료하기 위해, PCF(202)는 리소스 URI: {apiRoot}/nudr-dr/v1/policy-data/subs-to-notify로 PUT 요청을 전송할 수 있다. 이 PUT 요청의 바디는 "monitoredResourceUris"의 업데이트된 리스트를 갖는 PolicyDataSubscription 데이터 구조를 포함하고, 그 리스트는 이전에 언급된 …/{usageMonId} 리소스 URI를 포함하지 않을 것이다. 대안적으로, PCF(202)는, {apiRoot}/nudr-dr/v1/policy-data/subs-to-notify 리소스 URI로 DELETE 요청을 전송함으로써, 임의의 데이터 변경에 대한 통지에 대한 가입을 종료할 수 있다.

단계 13. UDR(204)이 HTTP "204 No Content" 응답을 PCF(202)로 전송한다.

도 4는 실시예에 따른 프로세스(400)를 예시하는 순서도이다. 프로세스(400)는 단계(s402)에서 시작될 수 있다.

단계(s402)는 정책 기능(예컨대, PCF(202))이 관리 기능(예컨대, SMF(201))으로부터 요청(251)(도 2 참조)을 수신하는 것을 포함하고, 요청은 UE와 관련된다. 즉, 관리 기능은, 정책 기능이 관리 기능으로부터 (직접적으로 또는 간접적으로) 요청을 수신하도록, 정책 기능을 향해 요청(251)을 송신하였다.

단계(s404)는 정책 기능이 디포지토리 기능(예컨대, UDR(204))으로부터 UE에 관한 정보를 인출할 필요가 있는지 여부를 정책 기능이 결정하는 것을 포함한다. 정책 기능이 정보를 인출할 필요가 있는 경우, 프로세스(400)는 단계(406)로 진행되고, 그렇지 않은 경우, 프로세스(400)는 단계(410)로 진행된다.

단계(s406)는 정책 기능이 정보에 대한 요청(252)을 디포지토리 기능으로 송신하는 것을 포함한다. 즉, 예컨대, 정책 기능이 소프트웨어로 구현되는 실시예들에서, 소프트웨어는 소프트웨어가 실행되고 있는 하드웨어에게 요청(252)을 송신할 것을 명령한다.

단계(s408)는 정책 기능이 요청에 대한 응답(254)을 수신하는 것을 포함하고, 여기서, 응답은 디포지토리 기능에 의해 송신되었고, 응답은: 한계 식별자를 포함하는 usageMonDataLimit 인스턴스, 및 usageMonDataLimit 인스턴스에 대응하는 usageMonData 인스턴스를 포함하고, 여기서, usageMonData 인스턴스는 또한 한계 식별자를 포함한다. 정책 기능이 (직접적으로 또는 간접적으로) 디포지토리 기능으로부터 응답을 수신할 때, 정책 기능은 응답이 UE에 대한 UsageMonDataLimit 인스턴스를 포함하는지 여부를 검출한다. 정책 기능이 UE에 대한 UsageMonDataLimit이 있는 것을 검출하는 경우, 정책 기능은 단계(s409)를 수행한다.

단계(s409)는 UsageMonDataLimit 인스턴스와 연관된 UsageMonData 인스턴스에 변경들이 발생할 때 통지들을 제공하라는 요청(256)을 정책 기능이 디포지토리 기능으로 송신하는 것을 포함한다.

단계(s410)는 정책 기능이 응답(260)을 관리 기능으로 전송하는 것을 포함한다.

단계(s412)는 정책 기능이 관리 기능으로부터 SM 관련 정책의 컨텍스트를 삭제하라는 요청(302)을 (직접적으로 또는 간접적으로) 수신하는 것을 포함한다.

단계(s414)는 정책 기능이 업데이트 요청(304)(예컨대, 도 3의 단계 10에 대하여 위에서 설명된 바와 같은 HTTP PATCH 또는 PUT)을 디포지토리 기능으로 송신하는 것을 포함한다.

단계(s416)는, 도 3의 단계 12에 대하여 위에서 설명된 바와 같이, 정책 기능이 가입해지 요청(306)을 디포지토리 기능으로 송신하는 것을 포함한다.

도 5는 실시예에 따른 프로세스(500)를 예시하는 순서도이다. 프로세스(500)는 단계(s502)에서 시작될 수 있다.

단계(s502)는 디포지토리 기능(예컨대, UDR(204))이 정책 기능(예컨대, PCF(202))으로부터 정보에 대한 요청(252)을 수신하는 것을 포함한다.

단계(s504)는 요청(252)에 대한 응답으로 디포지토리 기능이 응답(254)을 송신하는 것을 포함하고, 여기서, 응답은: 한계 식별자를 포함하는 usageMonDataLimit 인스턴스, 및 usageMonDataLimit 인스턴스에 대응하는 usageMonData 인스턴스를 포함하고, 여기서, usageMonData 인스턴스는 또한 한계 식별자를 포함한다.

단계(s506)는 디포지토리 기능이 정책 기능으로부터 업데이트 요청(304)(예컨대, 도 3의 단계 10에 대하여 위에서 설명된 바와 같은 HTTP PATCH 또는 PUT)을 수신하는 것을 포함한다.

단계(s508)는, 도 3의 단계 12에 대하여 위에서 설명된 바와 같이, 디포지토리 기능이 정책 기능으로부터 가입해지 요청(306)을 수신하는 것을 포함한다.

도 6은 일부 실시예들에 따른, PCF(202) 또는 UDR(204)을 구현하기 위한 장치(601)의 블록도이다. 예컨대, PCF(202) 및/또는 UDR(204)이 소프트웨어(예컨대, 스크립트들 및/또는 컴파일된 코드)로 구성되는 실시예들에서, 장치(601)는 PCF/UDR 소프트웨어를 실행할 수 있다. 따라서, 장치(601)는, 장치(601)가 PCF 소프트웨어를 실행하는 실시예들에서, 정책 기능 장치로 지칭될 수 있다. 마찬가지로, 장치(601)는, 장치(601)가 UDR 소프트웨어를 실행하는 실시예들에서, 디포지토리 기능 장치로 지칭될 수 있다. 도 6에 도시된 바와 같이, 장치(601)는: 프로세싱 회로부(PC)(602); 네트워크 인터페이스(648); 및 로컬 저장 유닛("데이터 저장 시스템"으로 또한 알려져 있음)(608)을 포함할 수 있으며, 프로세싱 회로부(PC)(602)는 하나 이상의 프로세서(P)(655)(예컨대, 하나 이상의 범용 마이크로프로세서 및/또는 하나 이상의 다른 프로세서, 이를테면, 주문형 집적 회로(ASIC), 필드-프로그래머블 게이트 어레이(FPGA)들 등)를 포함할 수 있고, 그 프로세서들은 단일 하우징 또는 단일 데이터 센터에 공동-위치될 수 있거나, 또는 지리적으로 분산될 수 있고, 네트워크 인터페이스(648)는 장치(601)로 하여금 네트워크 인터페이스(648)가 연결되어 있는 네트워크(110)(예컨대, 인터넷 프로토콜(IP) 네트워크)에 연결된 다른 노드들로 데이터를 송신하고 그 다른 노드들로부터 데이터를 수신할 수 있게 하기 위해 송신기(Tx)(645) 및 수신기(Rx)(647)를 포함하고, 로컬 저장 유닛(608)은 하나 이상의 비-휘발성 저장 디바이스 및/또는 하나 이상의 휘발성 저장 디바이스를 포함할 수 있다. PC(602)가 프로그래머블 프로세서를 포함하는 실시예들에서, 컴퓨터 프로그램 제품(computer program product)(CPP)(641)이 제공될 수 있다. CPP(641)는 컴퓨터 판독가능 명령어(computer readable instruction)(CRI)들(644)을 포함하는 컴퓨터 프로그램(computer program)(CP)(643)을 저장하는 컴퓨터 판독가능 매체(computer readable medium)(CRM)(642)를 포함한다. CRM(642)은 비-일시적 컴퓨터 판독가능 매체, 이를테면, 자기 매체들(예컨대, 하드 디스크), 광학 매체들, 메모리 디바이스들(예컨대, 랜덤 액세스 메모리, 플래시 메모리) 등일 수 있다. 일부 실시예들에서, 컴퓨터 프로그램(643)의 CRI(644)는, PC(602)에 의해 실행될 때, CRI가 장치(601)로 하여금 본원에서 설명되는 단계들(예컨대, 순서도들을 참조하여 본원에서 설명되는 단계들)을 수행하게 하도록 구성된다. 다른 실시예들에서, 장치(601)는, 코드를 필요로 하지 않으면서, 본원에서 설명되는 단계들을 수행하도록 구성될 수 있다. 즉, 예컨대, PC(602)는 단지 하나 이상의 ASIC로만 구성될 수 있다. 따라서, 본원에서 설명되는 실시예들의 피처들은 하드웨어 및/또는 소프트웨어로 구현될 수 있다.

실시예들

A1. 방법(400)은, 정책 기능(예컨대, PCF(202))이 정보에 대한 요청(252)을 디포지토리 기능(예컨대, UDR(204)으로 송신하는 단계(s406) ― 디포지토리 기능은 요청에 대한 응답으로 응답(254)을 송신하도록 구성됨 ―; 및 정책 기능이 응답을 수신하는 단계(s408)를 포함하고, 여기서, 응답은 한계 식별자를 포함하는 usageMonDataLimit 인스턴스; 및 usageMonDataLimit 인스턴스에 대응하는 usageMonData 인스턴스를 포함하고, 여기서, usageMonData 인스턴스가 또한 한계 식별자를 포함한다.

A2. 실시예 A1의 방법은, 요청(252)을 송신하기 전에, 정책 기능이 관리 기능(예컨대, SMF)에 의해 송신된 요청(251)을 수신하는 단계(s402); 및 정책 기능이 디포지토리 기능으로부터 정보를 인출할 필요가 있는지 여부를 정책 기능이 결정하는 단계(s404)를 더 포함한다.

B1. 방법은, 디포지토리 기능(예컨대 UDR(204))이 정책 기능(예컨대, PCF(202))에 의해 송신된 정보에 대한 요청을 수신하는 단계; 및 디포지토리 기능이 요청에 대한 응답으로 응답을 송신하는 단계를 포함하고, 여기서, 응답은 한계 식별자를 포함하는 usageMonDataLimit 인스턴스; 및 usageMonDataLimit 인스턴스에 대응하는 usageMonData 인스턴스를 포함하며, usageMonData 인스턴스가 또한 한계 식별자를 포함한다.

B2. 실시예 B1의 방법은, 디포지토리 기능이 정책 기능에 의해 송신된 업데이트 요청(304)을 수신하는 단계(s506)를 더 포함한다.

B3. 실시예 B2의 방법에서, 업데이트 요청은 한계 식별자를 포함하는 UsageMonData 인스턴스를 포함하는 HTTP PATCH 요청이다.

B4. 실시예 B2의 방법에서, 업데이트 요청은 한계 식별자를 포함하는 리소스 식별자(예컨대, URI)를 포함하는 HTTP PUT 요청이다.

B5. 실시예들 B1 내지 B4 중 어느 하나의 방법은 디포지토리 기능이 정책 기능에 의해 송신된 가입해지 요청(306)을 수신하는 단계(s508)를 더 포함한다.

B6. 실시예 B5의 방법에서, 가입해지 요청은 한계 식별자를 포함하는 리소스 식별자를 포함하는 바디를 포함하는 HTTP PUT 요청이다.

C1. 장치(601)는 정보에 대한 요청(252)을 디포지토리 기능(예컨대, UDR(204))으로 송신(s406)하고 ― UDR(204)은 요청에 대한 응답으로 응답(254)을 송신하도록 구성됨 ―, 응답을 수신(s408)하도록 적응되고, 여기서, 응답은 한계 식별자를 포함하는 usageMonDataLimit 인스턴스; 및 usageMonDataLimit 인스턴스에 대응하는 usageMonData 인스턴스를 포함하고, 여기서, usageMonData 인스턴스가 또한 한계 식별자를 포함한다.

C2. 실시예 A1의 장치에서, 장치는, 요청(252)을 송신하기 전에, 관리 기능에 의해 송신된 요청(251)을 수신한 후에, 디포지토리 기능으로부터 정보를 인출할지 여부를 결정(s404)하도록 추가로 적응된다.

D1. 장치(601)는 정책 기능(예컨대, PCF(202))에 의해 송신된 정보에 대한 요청을 수신하고, 요청에 대한 응답으로 응답을 송신하도록 적응되고, 여기서, 응답은 한계 식별자를 포함하는 usageMonDataLimit 인스턴스; 및 usageMonDataLimit 인스턴스에 대응하는 usageMonData 인스턴스를 포함하며, usageMonData 인스턴스가 또한 한계 식별자를 포함한다.

D2. 실시예 D1의 장치에서, 장치는 실시예들 B2 내지 B6 중 임의의 하나의 방법을 수행하도록 추가로 적응된다.

다음은 제안된 TS 29.519에 대한 변경들을 예시한다.

제1 변경

5.2.6.2 리소스 정의

리소스 URI: {apiRoot}/nudr-dr/v1/policy-data/{ueId}/sm-data/{usageMonId}

이 리소스는 아래의 표에서 정의되는 리소스 URI 변수들을 지원할 것이다.

제2 변경

5.2.6.3.3 GET

이 방법은 아래의 표에서 지정되는 URI 질의 파라미터들을 지원할 것이다.

다양한 실시예들이 본원에서 설명되지만, 이들은 제한이 아니라 단지 예로서 제시되었다는 것이 이해되어야 한다. 따라서, 본 개시내용의 폭 및 범위는 위에서 설명된 예시적인 실시예들 중 임의의 실시예에 의해 제한되지 않아야 한다. 더욱이, 위에서 설명된 요소들의 모든 가능한 변형들에서 이들의 어떠한 조합도, 본원에서 달리 표시되지 않는 한 또는 그렇지 않으면 문맥에 의해 명확히 부인되지 않는 한, 본 개시내용에 의해 포함된다.

추가적으로, 위에서 설명되고 도면들에 예시되는 프로세스들이 단계들의 시퀀스로서 도시되어 있지만, 이는 단지 예시를 위해 이루어진 것일 뿐이다. 따라서, 일부 단계들이 추가될 수 있고, 일부 단계들이 생략될 수 있고, 단계들의 순서가 재배열될 수 있고, 일부 단계들이 병렬로 수행될 수 있는 것으로 고려된다. 또한, "~로부터 수신하는"이라는 문구는 "~로부터 직접적으로 수신하는" 또는 "~로부터 간접적으로 수신하는"을 포함하는 것으로 해석되어야 한다. 즉, 제3 엔티티가 제2 엔티티에 의해 송신된 메시지를 수신한 후에 메시지를 제1 엔티티로 포워딩하는 경우에도, 제1 엔티티가 제2 엔티티로부터 메시지를 수신하는 것이다.

약어들:

AF 애플리케이션 기능(Application function)

AMBR 어그리게이트 최대 비트 레이트(Aggregate maximum bit rate)

APN 액세스 포인트 이름(Access point name)

ARP 할당 및 보유 우선순위(Allocation and retention priority)

ASA 세션-중단-회신(Abort-Session-Answer)

ASR 세션-중단-요청(Abort-Session-Request)

CHF 과금 기능(Charging Function)

DNN 데이터 네트워크 이름(Data network name)

HTTP 하이퍼텍스트 전송 프로토콜(Hypertext Transfer Protocol)

IP-CAN IP 연결 액세스 네트워크(IP connectivity access network)

GPSI 일반 공개 가입 식별자(General public subscription identifier)

H-PCF 홈 정책 제어 기능(Home policy control function)

PCC 정책 및 과금 제어(Policy and charging control)

PCF 정책 제어 기능(Policy control function)

PCRF 정책 및 변경 규칙 기능(Policy and changing rules function)

PDU 프로토콜 데이터 유닛(Protocol Data Unit)

PEI 영구 장비 식별자(Permanent equipment identifier)

PGW 패킷 데이터 네트워크 게이트웨이(Packet data network gateway)

RAT 라디오 액세스 기술(Radio access technology)

SM 단문 메시지(Short message)(?)

SMF 세션 관리 기능(Session management function)

SPR 가입 프로파일 리포지토리(Subscription profile repository)

STA 세션-종료-회신(Session-termination-answer)

STR 세션-종료-요청(Session-termination-request)

SUPI 가입 영구 식별자(Subscription permanent identifier)

S-NSSAI 단일 네트워크 슬라이스 선택 보조 정보(Single network slice selection assistance information)

UDR 통합 데이터 리포지토리(Unified data repository)

UP 사용자 평면(User plane)

UPF 사용자 평면 기능(User plane function)

V-PCF 방문 정책 제어 기능(Visited policy control function)

5QI 5G 서비스 품질(QoS) 식별자(5G Quality of service (QoS) identifier)

Claims

정책 기능(202)에 의해 수행되는 방법(400)으로서, 상기 방법은
상기 정책 기능(202)이 정보에 대한 요청(252)을 디포지토리(depository) 기능(204)으로 송신하는 단계(s406); 및
상기 정책 기능(202)이 상기 요청에 대한 응답(254)을 수신하는 단계(s408)
를 포함하고,
상기 응답(254)은,
사용량 한계를 식별하는 한계 식별자를 포함하는 usageMonDataLimit 인스턴스; 및
상기 usageMonDataLimit 인스턴스에 대응하는 usageMonData 인스턴스
를 포함하고,
상기 usageMonData 인스턴스가 또한 상기 한계 식별자를 포함하는, 방법.
제1항에 있어서,
상기 요청(252)을 송신하기 전에, 상기 정책 기능이 관리 기능(201)으로부터 요청(251)을 수신하는 단계(s402); 및
상기 요청(251)에 대한 응답으로, 상기 정책 기능(202)이 상기 디포지토리 기능으로부터 상기 정보를 인출할 필요가 있는지 여부를 상기 정책 기능(202)이 결정하는 단계(s404)
를 더 포함하는, 방법.
제1항 또는 제2항에 있어서,
상기 UsageMonDataLimit 인스턴스와 연관된 상기 UsageMonData 인스턴스에 변경들이 발생할 때 상기 정책 기능에 통지를 제공할 것을 상기 디포지토리 기능에게 요청하는 요청(256)을 상기 정책 기능(202)이 상기 디포지토리 기능으로 송신하는 단계를 더 포함하는, 방법.
제1항 또는 제2항에 있어서,
상기 정책 기능(202)이 업데이트 요청(304)을 상기 디포지토리 기능(204)으로 송신하는 단계를 더 포함하는, 방법.
제4항에 있어서,
상기 업데이트 요청(304)은 상기 한계 식별자를 포함하는 UsageMonData 인스턴스를 포함하는 HTTP PATCH 요청이거나, 또는
상기 업데이트 요청(304)은 상기 한계 식별자를 포함하는 리소스 식별자를 포함하는 HTTP PUT 요청인, 방법.
제1항 또는 제2항에 있어서,
상기 정책 기능(202)이 가입해지 요청(306)을 상기 디포지토리 기능(204)으로 송신하는 단계를 더 포함하고,
상기 가입해지 요청을 송신하는 단계는 상기 한계 식별자를 포함하는 리소스 식별자를 포함하는 바디(body)를 포함하는 HTTP PUT 요청을 송신하는 단계를 포함하는, 방법.
제1항 또는 제2항에 있어서,
상기 usageMonDataLimit 인스턴스는,
상기 usageMonDataLimit 인스턴스가 PDU 세션 레벨에서 적용되는지 또는 서비스 레벨에서 적용되는지를 표시하는 사용량 모니터링 레벨 인스턴스,
시작 일자 및 시간을 표시하는 시작 일자 정보,
종료 일자 및 시간을 표시하는 종료 일자 정보,
최대 허용 트래픽 볼륨을 표시하는 사용량 한계 임계값, 또는
허용 사용량이 리셋될 필요가 있는 시간을 표시하는 데 사용하기 위한 리셋 기간
중 적어도 하나를 더 포함하는, 방법.
제1항 또는 제2항에 있어서,
상기 usageMonDataLimit 인스턴스는 상기 usageMonDataLimit 인스턴스가 적용되는 S-NSSAI와 DNN 조합을 표시하는 데이터 스코프(scope)를 더 포함하는, 방법.
제1항 또는 제2항에 있어서,
상기 usageMonData 인스턴스는,
상기 usageMonData 인스턴스가 PDU 세션 레벨에서 적용되는지 또는 서비스 레벨에서 적용되는지를 표시하는 사용량 모니터링 레벨(umLevel) 인스턴스, 또는
허용 사용량 값
중 적어도 하나를 더 포함하고,
상기 허용 사용량 값은 남아 있는 허용 트래픽 볼륨을 표시하고/표시하거나 상기 허용 사용량 값은 남아 있는 시간 길이를 표시하는, 방법.
제7항에 있어서,
상기 usageMonData 인스턴스는 허용 사용량을 상기 사용량 한계 임계값으로 리셋하기 위한 시간을 표시하는 정보를 더 포함하는, 방법.
디포지토리 기능(204)에 의해 수행되는 방법(500)으로서, 상기 방법은,
상기 디포지토리 기능(204)이 정책 기능(202)으로부터 정보에 대한 요청(252)을 수신하는 단계(s502); 및
상기 디포지토리 기능(204)이 상기 정책 기능(202)으로부터의 상기 요청에 대한 응답으로 응답(254)을 송신하는 단계(s504)
를 포함하고,
상기 응답(254)은,
사용량 한계를 식별하는 한계 식별자를 포함하는 usageMonDataLimit 인스턴스; 및
상기 usageMonDataLimit 인스턴스에 대응하는 usageMonData 인스턴스
를 포함하고,
상기 usageMonData 인스턴스가 또한 상기 한계 식별자를 포함하는, 방법.
제11항에 있어서,
상기 디포지토리 기능이 상기 정책 기능으로부터 업데이트 요청(304)을 수신하는 단계(s506)를 더 포함하는, 방법.
제12항에 있어서,
상기 업데이트 요청(304)은 상기 한계 식별자를 포함하는 UsageMonData 인스턴스를 포함하는 HTTP PATCH 요청이거나, 또는
상기 업데이트 요청(304)은 상기 한계 식별자를 포함하는 리소스 식별자를 포함하는 HTTP PUT 요청인, 방법.
제11항 내지 제13항 중 어느 한 항에 있어서,
상기 디포지토리 기능이 상기 정책 기능으로부터 가입해지 요청(306)을 수신하는 단계(s508)를 더 포함하는, 방법.
제14항에 있어서,
상기 가입해지 요청은 상기 한계 식별자를 포함하는 리소스 식별자를 포함하는 바디를 포함하는 HTTP PUT 요청인, 방법.
제11항 내지 제13항 중 어느 한 항에 있어서,
상기 usageMonDataLimit 인스턴스는,
상기 usageMonDataLimit 인스턴스가 PDU 세션 레벨에서 적용되는지 또는 서비스 레벨에서 적용되는지를 표시하는 사용량 모니터링 레벨 인스턴스,
시작 일자 및 시간을 표시하는 시작 일자 정보,
종료 일자 및 시간을 표시하는 종료 일자 정보,
최대 허용 트래픽 볼륨을 표시하는 사용량 한계 임계값, 또는
허용 사용량이 리셋될 필요가 있는 시간을 표시하는 데 사용하기 위한 리셋 기간
중 적어도 하나를 더 포함하는, 방법.
제11항 내지 제13항 중 어느 한 항에 있어서,
상기 usageMonDataLimit 인스턴스는 상기 usageMonDataLimit 인스턴스가 적용되는 S-NSSAI와 DNN 조합을 표시하는 데이터 스코프를 더 포함하는, 방법.
제11항 내지 제13항 중 어느 한 항에 있어서,
상기 usageMonData 인스턴스는,
상기 usageMonData 인스턴스가 PDU 세션 레벨에서 적용되는지 또는 서비스 레벨에서 적용되는지를 표시하는 사용량 모니터링 레벨(umLevel) 인스턴스, 또는
허용 사용량 값
중 적어도 하나를 더 포함하고,
상기 허용 사용량 값은 남아 있는 허용 트래픽 볼륨을 표시하고/표시하거나 상기 허용 사용량 값은 남아 있는 시간 길이를 표시하는, 방법.
제17항에 있어서,
상기 usageMonData 인스턴스는 허용 사용량을 상기 사용량 한계 임계값으로 리셋하기 위한 시간을 표시하는 정보를 더 포함하는, 방법.
명령어들(644)을 포함하는, 컴퓨터 판독가능 기록 매체에 저장된 컴퓨터 프로그램(643)으로서,
상기 명령어들(644)은, 장치(600)의 프로세싱 회로부(602)에 의해 실행될 때, 상기 장치(600)로 하여금 제1항, 제2항, 및 제11항 내지 제13항 중 어느 한 항의 방법을 수행하게 하는, 컴퓨터 프로그램.
삭제
정책 기능 장치(601)로서, 상기 정책 기능 장치는
정보에 대한 요청(252)을 디포지토리 기능(204)으로 송신하고,
상기 요청에 대한 응답(254)을 수신하도록
적응되고,
상기 응답(254)은 사용량 한계를 식별하는 한계 식별자를 포함하는 usageMonDataLimit 인스턴스, 및 상기 usageMonDataLimit 인스턴스에 대응하는 usageMonData 인스턴스를 포함하고,
상기 usageMonData 인스턴스가 또한 상기 한계 식별자를 포함하는, 정책 기능 장치.
제22항에 있어서,
상기 정책 기능 장치는 제2항의 방법을 수행하도록 추가로 적응되는, 정책 기능 장치.
디포지토리 기능 장치(601)로서, 상기 디포지토리 기능 장치는
정책 기능(202)으로부터 정보에 대한 요청(252)을 수신하고,
상기 정책 기능(202)으로부터의 상기 요청에 대한 응답으로 응답(254)을 송신하도록
적응되고,
상기 응답(254)은 사용량 한계를 식별하는 한계 식별자를 포함하는 usageMonDataLimit 인스턴스, 및 상기 usageMonDataLimit 인스턴스에 대응하는 usageMonData 인스턴스를 포함하고,
상기 usageMonData 인스턴스가 또한 상기 한계 식별자를 포함하는, 디포지토리 기능 장치.
제24항에 있어서,
상기 디포지토리 기능 장치는 제12항 또는 제13항의 방법을 수행하도록 추가로 적응되는, 디포지토리 기능 장치.