KR102607571B1 - 무선 통신 시스템에서 네트워크 기반의 노스바운드 어플리케이션 프로그래밍 인터페이스를 제공하기 위한 장치 및 방법 - Google Patents

Abstract

본 개시는 LTE(Long Term Evolution)와 같은 4G(4th generation) 통신 시스템 이후 보다 높은 데이터 전송률을 지원하기 위한 5G(5th generation) 또는 pre-5G 통신 시스템에 관련된 것이다. 본 발명의 실시 예들은 네트워크 기반 노스 바운드 어플리케이션 프로그래밍 인터페이스를 제공하기 위한 방법 및 시스템을 달성한다. 이러한 방법은 적어도 하나의 API 호출자 클라이언트들로부터 적어도 하나의 서비스 API들을 호출하기 위한 요청을 API 제공자에 의해 수신하는 과정을 포함한다 이러한 방법은 적어도 하나의 서비스 API들을 제공하기 위해 제1 도메인에 상주하는 CAPIF 코어 기능을 API 제공자에 의해 이용하는 과정을 포함한다. 이러한 방법은 CAPIF 코어 기능을 통해 적어도 하나의 API 호출자 클라이언트들로 적어도 하나의 서비스 API들을 API 제공자에 의해 제공하는 과정을 포함하고, API 제공자는 적어도 하나의 서비스 API들, API 노출 기능, API 발행 기능 및 API 관리 기능을 포함한다.

Description

무선 통신 시스템에서 네트워크 기반의 노스바운드 어플리케이션 프로그래밍 인터페이스를 제공하기 위한 장치 및 방법

본 발명은 무선 통신 시스템에 관한 것이다. 보다 구체적으로, 무선 통신 시스템에서 네트워크 기반의 노스바운드(northbound) 어플리케이션 프로그래밍 인터페이스(application programming interface, 이하 API)를 제공하기 위한 장치 및 방법에 관한 것이다. 본 출원은 2017 년 5 월 2 일자로 출원된 인도 출원 번호 201741015554에 기초하여 우선권을 주장하며, 그 개시 내용은 본 출원에 참고로 포함된다.

4G(4th generation) 통신 시스템 상용화 이후 증가 추세에 있는 무선 데이터 트래픽 수요를 충족시키기 위해, 개선된 5G(5th generation) 통신 시스템 또는 pre-5G 통신 시스템을 개발하기 위한 노력이 이루어지고 있다. 이러한 이유로, 5G 통신 시스템 또는 pre-5G 통신 시스템은 4G 네트워크 이후(Beyond 4G Network) 통신 시스템 또는 LTE(Long Term Evolution) 시스템 이후(Post LTE) 시스템이라 불리어지고 있다.

높은 데이터 전송률을 달성하기 위해, 5G 통신 시스템은 초고주파(mmWave) 대역(예를 들어, 60기가(60GHz) 대역과 같은)에서의 구현이 고려되고 있다. 초고주파 대역에서의 전파의 경로손실 완화 및 전파의 전달 거리를 증가시키기 위해, 5G 통신 시스템에서는 빔포밍(beamforming), 거대 배열 다중 입출력(massive MIMO), 전차원 다중입출력(Full Dimensional MIMO, FD-MIMO), 어레이 안테나(array antenna), 아날로그 빔형성(analog beam-forming), 및 대규모 안테나(large scale antenna) 기술들이 논의되고 있다.

또한, 시스템의 네트워크 개선을 위해, 5G 통신 시스템에서는 진화된 소형 셀, 개선된 소형 셀(advanced small cell), 클라우드 무선 액세스 네트워크(cloud radio access network, cloud RAN), 초고밀도 네트워크(ultra-dense network), 기기 간 통신(Device to Device communication, D2D), 무선 백홀(wireless backhaul), 이동 네트워크(moving network), 협력 통신(cooperative communication), CoMP(Coordinated Multi-Points), 및 수신 간섭제거(interference cancellation) 등의 기술 개발이 이루어지고 있다.

이 밖에도, 5G 시스템에서는 진보된 코딩 변조(Advanced Coding Modulation, ACM) 방식인 FQAM(Hybrid Frequency Shift Keying and Quadrature Amplitude Modulation) 및 SWSC(Sliding Window Superposition Coding)과, 진보된 접속 기술인 FBMC(Filter Bank Multi Carrier), NOMA(Non Orthogonal Multiple Access), 및 SCMA(Sparse Code Multiple Access) 등이 개발되고 있다.

3GPP(third generation partnership project)에 있어서, 제3 자 서비스(3rd party service) API들(application programming interfaces)(노스바운드 API들이라고도 지칭하는)은 기능들이 정의된 특정 3GPP를 위해 사용될 수 있다. 여기에는 일반적인 노출 기능 엔티티인 SCEF(service capability exposure function)가 포함되어 네트워크 제공자들이 근본적인 3GPP 네트워크 기능을 노출할 수 있게 한다. 이러한 서비스 API의 또 다른 예는 컨텐츠 제공자들이 컨텐츠를 3GPP 네트워크들로 수집할 수 있게 하며, 이후 3GPP 네트워크들은 모바일 네트워크들(예: MBMS를 통해) 내 사용자들에게 브로드캐스트 될 수 있는 'xMB'이다. 이러한 API들은 독립적으로 개발되고, 서로 조정되지 않는다. 다양한 수집 산업의 요구에 부응하기 위해, 3GPP 네트워크들과 같은 무선 네트워크들을 보다 잘 통합하기 위한 공통 API 프레임워크가 필수적이다.

본 발명의 실시 예의 주된 목적은 네트워크 기반 노스바운드 API를 제공하는 방법 및 시스템을 제공하는 것이다.

본 발명의 실시 예의 다른 목적은 적어도 하나의 서비스 API를 제공하기 위해 제1 도메인에 상주하는 CAPIF 코어 기능을 이용하는 방법을 제공하는 것이다. 제1 도메인은 PNMN(public land mobile network) 도메인이다.

본 발명의 실시 예의 다른 목적은 제2 도메인에서 CAPIF 코어 기능을 제공하는 것이다. 제2 도메인은 제3 자 트러스트(third party trust) 도메인이다.

본 발명의 실시 예의 다른 목적은 CAPIF 코어 기능을 통해 적어도 하나의 API 호출자(invoker) 클라이언트들에 적어도 하나의 서비스 API를 제공하는 것이다. 여기서, 제2 도메인에 상주하는 API 제공자는 적어도 하나의 서비스 API, API 노출 기능, API 발행(publishing) 기능 및 API 관리 기능을 포함한다.

본 발명의 실시 예의 다른 목적은 공통 API 프레임워크 2(CAPIF-2) 인터페이스 및 CAPIF-2e 인터페이스 중 하나를 통해 적어도 하나의 서비스 API를 호출하기 위한 요청을 수신하는 것이다.

본 발명의 실시 예의 다른 목적은 제1 도메인에서 상주하는 API 제공자를 제공하는 것이다. 제1 도메인에 상주하는 API 제공자는 적어도 하나의 서비스 API, API 노출 기능, API 발행 기능 및 API 관리 기능을 포함한다.

본 발명의 실시 예는 무선 통신 시스템에서 네트워크 기반 노스바운드 API들(network based northbound application)을 제공하는 방법을 제공한다. 이 방법은 적어도 하나의 API 호출자 클라이언트들로부터 적어도 하나의 서비스 API들을 호출하기 위한 요청을 API 제공자에 의해 수신하는 과정을 포함한다. 이 방법은 적어도 하나의 서비스 API들을 제공하기 위해 제1 도메인에 상주하는 CAPIF 코어 기능을 API 제공자에 의해 이용하는 과정을 포함한다. 이 방법은 API 제공자에 의해 제공하는 과정을 포함한다. 여기서, API 제공자는 적어도 하나의 서비스 API, API 노출(exposing) 기능, API 발행(publishing) 기능 및 API 관리 기능을 포함한다.

일 실시 예에 있어서, API 제공자는 제2 도메인에 상주하며, 여기서, CAPIF 코어 기능은 CAPIF 코어 기능들을 제2 도메인 내 적어도 하나의 서비스 API들에게 제공한다.

일 실시 예에 있어서, 제1 도메인은 PNMN(public land mobile network) 도메인이고, 제2 도메인은 제3 자(third party) 도메인이다.

일 실시 예에 있어서, 적어도 하나의 서비스 API들을 호출하기 위한 요청은 공통 API 프레임 워크 2(CAPIF-2) 인터페이스 및 CAPIF-2e 인터페이스 중 하나를 통해 수신된다.

일 실시 예에 있어서, 제2 도메인과 연관된 API 발행 기능은 CAPIF-4e 메시지를 통해 제1 도메인에서 공통 API 프레임워크(common CAPIF) 코어 기능에 적어도 하나의 API들을 발행한다.

일 실시 예에 있어서, API 제공자는 적어도 하나의 API 호출자(invoker) 클라이언트들로부터 CAPIF-2 인터페이스 및 CAPIF-2e 인터페이스를 사용하여 적어도 하나의 API 호출자 클라이언트들의 인증(authentication) 및 허가(authorization) 중 적어도 하나를 수행한다.

일 실시 예에 있어서, API 제공자는 CAPIF-3e 인터페이스를 통해 서비스 API들의 액세스 제어, 데이터 로깅(logging), 과금(charging), 인증 및 허가 중 적어도 하나를 수행하기 위한 CAPIF 코어 기능과 통신한다.

일 실시 예에 있어서, API 관리 기능은 CAPIF-5e 인터페이스를 통해 액세스 모니터링(monitoring) 및 정책 구성들의 확인(checking) 및 API 호출자 클라이언트의 프로비저닝(provisioning) 중 적어도 하나를 수행하기 위해 제2 도메인에서 CAPIF 코어 기능과 통신한다.

일 실시 예에 있어서, API 호출자 클라이언트들에 대한 CAPIF 1 인터페이스 및 CAPIF-1e 인터페이스 중 하나를 통해 제1 도메인과 관련된 CAPIF 코어 기능에서 적어도 하나의 서비스 API들은 발견될 수 있다.

일 실시 예에 있어서, CAPIF 코어 기능은 제2 도메인에 상주하며, CAPIF 코어 기능은 제2 도메인과 관련된 API 제공자의 적어도 하나의 서비스 능력들(capabilities)을 호스팅한다.

일 실시 예에 있어서, CAPIF 코어 기능은 제1 도메인에 상주하며, 제1 도메인에 상주하는 API 제공자는 적어도 하나의 서비스 API들, API 노출 기능, API 발행 기능 및 API 관리 기능을 포함하고, 네트워크 엔티티는 네트워크 운영자(operator)에 상주한다.

일 실시 예에 있어서, API 제공자는 적어도 하나의 API 호출자 클라이언트들로부터 적어도 하나의 서비스 API들을 호출하기 위한 요청을 수신한다.

일 실시 예에 있어서, 적어도 하나의 서비스 API들을 호출하기 위한 요청은 공통 API 프레임워크 2 (CAPIF-2) 인터페이스 및 CAPIF-2e 인터페이스 중 하나를 통해 수신된다.

일 실시 예에 있어서, API 발행 기능은 적어도 하나의 서비스 API들을 공통 API 프레임워크 (CAPIF) 코어 기능에 발행한다.

일 실시 예에 있어서, API 제공자는 적어도 하나의 API 호출자 클라이언트들로부터 CAPIF-2 및 CAPIF-2e를 통해 수신된 요청을 사용하여 적어도 하나의 API 호출자 클라이언트들의 인증 및 허가 중 적어도 하나를 수행한다.

일 실시 예에 있어서, API 발행 기능은 적어도 하나의 서비스 API들을 CAPIF-4 인터페이스를 통해 CAPIF 코어 기능에 발행한다.

일 실시 예에 있어서, 적어도 하나의 서비스 API들은 적어도 하나의 API 호출자 클라이언트들로부터 수신된 CAPIF-1 메시지 및 CAPIF-1e 메시지 중 하나를 통해 CAPIF 코어 기능에서 발견될 수 있다.

일 실시 예에 있어서, CAPIF 코어 기능은 CAPIF-1 메시지 및 CAPIF-1e 메시지를 사용하여 적어도 하나의 API 호출자 클라이언트들의 인증 및 허가 중 적어도 하나를 수행한다.

일 실시 예에 있어서, CAPIF 코어 기능은 CAPIF-3 메시지를 통해 서비스 API들의 액세스 제어, 데이터 로깅(logging), 과금(charging), 인증 및 허가 중 적어도 하나를 수행하기 위해 API 제공자와 통신한다.

일 실시 예에 있어서, API 관리 기능은 CAPIF-5 메시지를 통해 적어도 하나의 서비스 API들의 액세스 모니터링, 정책 구성들(policy configurations) 및 API 호출자 클라이언트의 프로비저닝(provisioning) 중 적어도 하나를 수행하기 위해 CAPIF 코어 기능과 통신한다.

따라서, 본 실시 예는 무선 통신 시스템에서 네트워크 기반의 노스바운드 API들(north bound application programming interfaces)을 제공하기 위한 네트워크 엔티티를 제공한다. 네트워크 엔티티는 적어도 하나의 호출자 클라이언트들로부터 적어도 하나의 서비스 API들을 호출하기 위한 요청을 수신하도록 구성된 API 제공자를 포함한다. API 제공자는 적어도 하나의 서비스 API들을 지원하기 위해 제1 도메인에 상주하는 CAPIF 코어 기능을 이용하도록 구성된다. API 제공자는 CAPIF 코어 기능을 통해 적어도 하나의 API 호출자 클라이언트들에 적어도 하나의 서비스 API들을 제공하도록 구성됩니다. API 제공자는 적어도 하나의 서비스 API들, API 노출 기능, API 발행 기능 및 API 관리 기능을 포함한다.

본 실시 예들 및 다른 양태들은 다음의 설명 및 첨부 도면들과 함께 고려되는 경우 보다 잘 인식되고 이해될 것이다. 그러나, 이하의 설명은 바람직한 실시 예 및 그에 대한 많은 구체적인 세부 사항들을 나타내지만, 이는 예시를 위한 것이며 한정하기 위한 것은 아니라는 것을 이해해야 한다. 많은 변경사항들 및 수정사항들이 본 발명의 사상을 벗어나지 않고 본 실시 예들의 범위 내에서 이루어질 수 있으며, 본 실시 예들은 이러한 모든 수정사항들을 포함한다.

본 개시(disclosure)는 적어도 하나의 서비스 API들을 제공하기 위해 제1 도메인에 상주하는 CAPIF 코어 기능을 이용하는 방법을 제공할 수 있다. 제1 도메인은 PLMN(Public Land Mobile Network) 도메인이다.

본 개시는 제2 도메인에서 CAPIF 코어 기능을 제공할 수 있다. 제2 도메인은 제3 자 트러스트(third party trust) 도메인이다.

본 개시는 CAPIF 코어 기능을 통해 적어도 하나의 API 호출자 클라이언트들에 적어도 하나의 서비스 API들을 제공할 수 있으며, 제2 도메인에 상주하는 API 제공자는 적어도 하나의 서비스 API들, API 노출 기능, API 발행 기능 및 API 관리 기능을 포함한다.

본 발명은 첨부된 도면에 도시되어 있으며, 도면 전체에 걸쳐서 동일한 참조 부호는 다양한 도면들에 있어서 대응하는 부분들을 나타낸다. 본 발명의 실시 예는 도면을 참조한 다음의 설명으로부터 보다 잘 이해될 것이다.
도 1은 본 개시의 다양한 실시 예들에 따른 무선 통신 시스템을 도시한다.
도 2는 본 개시의 다양한 실시 예들에 따른 무선 통신 시스템에서 기지국을 도시한다.
도 3은 본 개시의 다양한 실시 예들에 따른 무선 통신 시스템에서 단말을 도시한다.
도 4는 본 개시의 다양한 실시 예들에 따른 무선 통신 시스템에서 통신 인터페이스를 도시한다.
도 5는 본 개시의 일 실시 예에 따른 CAPIF(common API framework) 코어 기능이 존재하는 동일한 도메인 내 API 제공자와는 별도의 제3 자 API 제공자들을 지원하는 공통 API 프레임워크(CAPIF) 아키텍처를 도시한다.
도 6은 본 개시의 일 실시 예에 따른 PLMN 도메인 내 서비스 능력들을 지원하는 PLMN 도메인 내에서 CAPIF가 호스팅되는 경우 다양한 상호 작용을 도시한다.
도 7은 본 개시의 일 실시 예에 따른 PLMN 도메인 및 제3 자 도메인 내 API 관리(management)에서 CAPIF가 호스팅되는 경우 다양한 상호 작용을 도시한다.
도 8은 본 개시의 일 실시 예에 따른 PLMN 도메인과 제3 자 도메인 모두에서 CAPIF가 호스팅되는 경우 다양한 상호 작용을 도시한다.
도 9는 본 개시의 일 실시 예에 따른 제3 자가 도메인이 없는 경우 PLMN 도메인에서 호스팅되는 공통 API 프레임워크(CAPIF) 아키텍처를 도시한다.
도 10은 본 개시의 일 실시 예에 따른 CAPIF와 LTE(long term evolution) 시스템의 통합을 도시한다.
도 11은 본 개시의 일 실시 예에 따른 CAPIF와 NR(new radio) 시스템의 통합을 도시한다.
도 12는 본 개시의 일 실시 예에 따른 무선 통신 시스템에서 네트워크 기반 노스바운드 API들을 제공하기 위한 방법을 나타내는 흐름도이다.
도 13은 본 개시의 다양한 실시 예들에 따른 무선 통신 시스템에 네트워크 엔티티를 도시한다.

이하에서는, 본 개시의 다양한 실시 예들에 있어서, 하드웨어적 접근 방법들이 일 예로서 설명될 것이다. 하지만, 본 개시의 다양한 실시 예들은 하드웨어 및 소프트웨어 모두를 사용하는 기술을 포함하므로, 본 개시의 다양한 실시 예들은 소프트웨어 기반의 접근 방법을 제외하는 것은 아니다.

이하에서는, 본 개시의 무선 통신 시스템에서 네트워크 기반 노스바운드 API(northbound application programming interface)를 제공하기 위한 방법 및 시스템에 대한 기술을 설명한다.

이하 설명에서 사용되는 네트워크 기반 노스바운드 API를 제공하기 위한 방법 및 시스템을 지칭하는 용어들, 신호를 지칭하는 용어들, 채널을 지칭하는 용어들, 제어 정보를 지칭하는 용어들, 네트워크 엔티티(network entity)를 지칭하는 용어들, 장치의 구성요들을 지칭하는 용어들은 설명의 편의를 위해 예시된 것이다. 따라서, 본 개시는 이하의 용어에 한정되지 않고, 동일한 기술적 의미를 가지는 다른 용어들이 사용될 수 있다.

또한, 본 개시는 일부 통신 표준(예를 들어, 3GPP(3rd generation partnership project))에서 사용되는 용어에 기초하여 다양한 실시 예들을 설명하지만, 단지 설명을 위한 예이다. 본 개시의 다양한 실시 예들은 용이하게 변경되어 다른 통신 시스템들에 적용될 수 있다.

본 실시 예들, 그 다양한 특징들 및 유리한 세부사항들은 첨부 도면들에 의해 도시되고 이하의 상세한 설명에서 구체적으로 설명되는 비제한적인 실시 예들을 참조하여 보다 완전하게 설명된다. 공지된 구성요소 및 프로세싱 기술들의 설명은 본 실시 예들을 불명료하게 하지 않기 위해 생략된다. 또한, 일부 실시 예들이 새로운 실시 예들을 형성하기 위해 적어도 하나의 다른 실시 예들과 결합될 수 있기 때문에, 여기서 설명되는 다양한 실시 예들은 필수적으로 상호 배타적이지 않다. 본 명세서에서 사용되는 용어 "또는"은 달리 명시되지 않는 한 비-배타적인(non-exclusive) 것을 나타낸다. 본 명세서에서 사용된 예는 단지 본 실시 예들이 될 수 있는 방법들에 대한 이해를 용이하게 하고 당업자가 본 실시 예들을 실시할 수 있도록 하기 위한 것이다. 따라서, 이러한 예들은 본 실시 예들의 범위를 제한하는 것으로 해석되어서는 안된다.

실시 예들을 구체적으로 설명하기 전에, 네트워크 기반 노스바운드 API들을 제공하는 것과 관련된 엔티티들의 정의가 다음에서 설명된다.

API: API 호출자가 서비스에 액세스할 수 있는 수단들.

API 호출자(invoker): 공통 API 프레임워크(CAPIF) 또는 서비스 API들을 호출하는 엔티티.

API 호출자 프로파일(profile): API 호출자가 CAPIF API들 및 서비스 API들을 사용할 수 있게 하는 API 호출자와 관련된 정보의 세트.

API 노출 기능(exposing function): 서비스 API들에 대한 서비스 통신 엔트리 포인트(entry point)를 제공하는 엔티티.

CAPIF 관리자(administrator): CAPIF 동작들을 위한 특별한 허가들(permissions)을 가진 허가된 사용자.

공통(common) API 프레임워크(framework): 서비스 API들을 지원하기 위해 필요한 공통 API 양태들(aspects)을 포함하는 프레임워크.

노스바운드(northbound) API: 상위-계층(higher layer) API 호출자들에게 노출된 서비스 API.

온보딩(onboarding): API 호출자가 CAPIF 및 서비스 API들에 연속적으로(subsequently) 액세스할 수 있게 하는 일회 등록 프로세스(one time registration process).

자원(resource): 동작이 수행되는 API의 오브젝트(object) 또는 구성요소(component).

서비스 API: 기본적인 메커니즘들(underlying mechanisms)로부터 서비스들을 추출함으로써 API 호출자에게 자신의 서비스들을 시스템의 구성요소를 통해 노출시키는 인터페이스.

PLMN 신뢰 도메인(trust domain): 적절한 보안에 의해 보호되고 PLMN 오퍼레이터(operator) 또는 PLMN의 신뢰된 제3 자에 의해 제어되는 엔티티들.

제3 자(3rd party) 신뢰 도메인: 적절한 보안에 의해 보호되고 제3 자에 의해 제어되는 엔티티들.

본 실시 예들은 네트워크 기반 노스바운드 API를 제공하는 방법 및 시스템을 제공한다. 이러한 방법은 적어도 하나의 API 호출자 클라이언트들로부터 적어도 하나의 서비스 API들을 호출하기 위한 요청을 API 제공자에 의해 수신하는 과정을 포함한다. 이러한 방법은 적어도 하나의 서비스 API들을 제공하기 위해 제1 도메인에 상주하는 CAPIF 코어 기능을 API 제공자에 의해 사용하는 과정을 포함한다. 이러한 방법은 CAPIF 코어 기능을 통해 적어도 하나의 API 호출자 클라이언트들에게 적어도 하나의 API 서비스들을 API 제공자에 의해 제공하는 과정을 포함하며, API 제공자는 적어도 하나의 서비스 API들, API 노출 기능, API 발행 기능 및 API 관리 기능을 포함한다.

일 실시 예에 있어서, CAPIF 코어 기능은 어플리케이션들이 어플리케이션 등록, 서비스 API 발견, 인증, 허가 및 API 정보를 관리하고 액세스하기 위한 API 제공자와 같은 공통 기능들을 통해 서비스 API들에 액세스할 수 있게 한다. CAPIF 코어 기능은 서비스 API들과 관련된 다양한 데이터(예를 들어, 액세스 제어 리스트, 인증 자격증명(authentication credentials), 구성된 기간(configured duration)에 대한 API 로그 이벤트들(log events), 구성된 정책들(configured policies), 어플리케이션 프로파일 정보, 수명주기 관리 보고들(lifecycle management reports), 이벤트들의 모니터링(monitoring events), 과금 정보(charging information), 어플리케이션 인증 상태(authentication status), API 레지스트리(registry))를 저장한다.

제안된 방법 및 시스템은 네트워크 기반 노스 바운드 API를 제공하기 위해 사용될 수 있다. 본 개시의 다양한 실시 예들은 아래에서 설명되는 바와 같이 공통 API 프레임워크가 호스팅되거나 구현될 수 있는 별개의 세 기능 모델들을 광범위하게 설명한다:

네트워크 제공자에 의해 호스팅된 CAPIF: 일부 실시 예들에 있어서, CAPIF의 다양한 엔티티들은 네트워크 제공자에 의해 호스팅되거나 제어되는 반면에, 어플리케이션은 네트워크 제공자 도메인 내에 존재할 수 있거나 존재하지 않을 수 있다.

제3 자 서비스 제공자에 의해 호스팅된 CAPIF: 일부 실시 예들에 있어서, CAPIF의 모든 엔티티들은 제3 자 서비스 제공자 도메인에서 호스팅되며, 제3 자 서비스 제공자 도메인은 네트워크 제공자 도메인과 다르다. 그러나, 네트워크 능력들은 네트워크 제공자에 의해 호스팅되므로, 네트워크 제공자 도메인에 네트워크 능력들이 상주한다. 이러한 경우 어플리케이션은 제3 자 서비스 제공자 도메인 또는 제3 자 서비스 제공자 도메인과 다른 네트워크 제공자 도메인의 외부에 상주한다.

네트워크 제공자에 의해 지원되는 제3 자 서비스 제공자를 위한 CAPIF: 다양한 실시 예들에 있어서, 제3 자 서비스 제공자가 자체 서비스 기능들을 네트워크 제공자 도메인 내의 프레임 워크와 통합할 수 있는 능력을 가진, 네트워크 제공자에 의해 호스팅된 프레임 워크 모델과 유사한 네트워크 제공자 도메인에서 CAPIF가 호스팅된다. 어플리케이션 서버가 네트워크 제공자에 의해 호스팅된 네트워크 기능들을 사용하는 동안 어플리케이션 서버가 제3 자 서비스 공급자 도메인에서 호스팅되는 업무상 중요한 서비스들과 같은 경우에 유용하다. 이러한 경우, API 관리 기능은 네트워크 제공자(PLMN operator) 및 제3 자 서비스 제공자에 의해 공유될 필요가 있다.

도 1은 본 개시의 다양한 실시 예들에 따른 무선 통신 시스템을 도시한다. 도 1에 있어서, 무선 통신 시스템에서 무선 채널을 사용하는 노드들의 일부로서, 기지국(BS) 110, 단말 120, 및 단말 130이 도시된다. 도 1은 하나의 기지국만을 도시하고 있지만, 기지국 110과 동일 또는 유사한 다른 기지국을 더 포함할 수 있다.

기지국 110은, 단말들 120 및 130에게 무선 접속을 제공하는 네트워크 인프라스트럭쳐(infrastructure)이다. 기지국 110은 신호가 송신될 수 있는 거리에 기반하여 미리 결정된 지리적 영역으로서 정의된 커버리지를 가진다. 기지국 (110)은 기지국(base station) 외에 '액세스 포인트(access point, AP)', '이노드비(eNodeB, eNB)', '5G 노드(5th generation node)', '5G 노드비(5G NodeB, NB)', '무선 포인트(wireless point)', '송수신 포인트(transmission/reception point, TRP)'로 지칭될 수 있다.

단말들 120 및 130 각각은 사용자에 의해 사용되는 장치이며, 무선 채널(wireless channel)을 통해 기지국 110과 통신을 수행한다. 경우에 따라, 적어도 하나의 단말들 120 및 130은 사용자의 관여없이 동작할 수 있다. 즉, 적어도 하나의 단말들 120 및 130은 기계 타입 통신(machine type communication, MTC)을 수행하는 장치이며, 사용자에 의해 휴대되지 아니할 수 있다. 단말들 120 및 130 각각은 단말(terminal) 외 '사용자 장비(user equipment, UE)', '이동국(mobile station)', '가입자국(subscriber station)', '원격 단말(remote terminal)', '무선 단말(wireless terminal)', '전자 장치(electronic device)', 또는 '사용자 장치(user device)'로 지칭될 수 있다.

기지국 110, 단말 120, 및 단말 130은 밀리미터 웨이브(mmWave) 대역들(예를 들어, 28 GHz, 30 GHz, 38 GHz, and 60 GHz)에서 무선 신호들을 송수신할 수 있다. 이때, 기지국 110, 단말 120, 및 단말 130은 채널 이득을 향상시키기 위해 빔포밍(beamforming)을 수행할 수 있다. 빔포밍은 송신 빔포밍 및 수신 빔포밍을 포함할 수 있다. 즉, 기지국 110, 단말 120, 및 단말 130은 송신 신호 및 수신 신호에 방향성(directivity)을 할당할 수 있다. 이를 위해, 기지국 110, 단말 120 및 130은 빔 검색 절차 또는 빔 관리 절차를 통해 서빙 빔들 112, 113, 121, 및 131을 선택할 수 있다. 그 후, 서빙 빔들 112, 113, 121, 및 131이 운반하는 자원들에 대해 준-동일 위치 관계(quasi co-located relationship)를 갖는 자원들을 사용하여 통신이 수행될 수 있다.

제1 안테나 포트 상의 심볼이 전달되는 채널의 대규모 특성들(large-scale properties)이 제2 안테나 포트 상의 심볼이 전달되는 채널로부터 추론될 수 있다면, 제1 안테나 포트 및 제2 안테나 포트는 준-동일 위치인 것으로 간주된다. 대규모 특성들은 지연 확산(delay spread), 도플러 확산(doppler spread), 도플러 시프트(doppler shift), 평균 이득(average gain), 평균 지연(average delay) 및 공간 수신 파라미터들(spatial Rx parameters) 중 하나 이상을 포함할 수 있다.

도 2는 본 개시의 다양한 실시 예들에 따른 무선 통신 시스템에서 기지국을 도시한다. 도 2에 예시된 구조는 기지국 110의 구조로서 이해될 수 있다. 이하에서 사용된 "모듈(module)", "??부(unit)" 또는 "??기(-er)" 등의 용어는 적어도 하나의 기능이나 동작을 처리하는 단위를 의미하며, 하드웨어, 소프트웨어 또는 하드웨어 및 소프트웨어의 결합으로 구현될 수 있다.

도 2를 참고하면, 기지국은 무선 통신 인터페이스 210, 백홀 통신 인터페이스 220, 저장부 230, 및 제어부 240를 포함할 수 있다.

무선 통신 인터페이스 210은 무선 채널을 통해 신호들을 송수신하는 기능들을 수행한다. 예를 들어, 무선 통신 인터페이스 210은 시스템의 물리 계층 표준에 따라 기저대역 신호(baseband signal)와 비트 스트림들(bitstreams) 간의 변환 기능을 수행할 수 있다. 예를 들어, 데이터 송신 시, 무선 통신 인터페이스 210은 송신 비트 스트림들을 부호화(encoding) 및 변조(modulating)함으로써 복소 심볼들을 생성한다. 또한, 데이터 수신 시, 무선 통신 인터페이스 210은 기저 대역 신호를 복호화(decoding) 및 복조(demodulating)함으로써 수신 비트 스트림들을 재구성한다.

또한, 무선 통신 인터페이스 210은 기저 대역 신호를 RF(radio frequency) 대역 신호로 상향 변환하여 안테나를 통해 송신한 후, 안테나를 통해 수신된 RF 대역 신호를 기저 대역 신호로 하향 변환한다. 이를 위해, 무선 통신 인터페이스 210은 송신 필터, 수신 필터, 증폭기(amplifier), 믹서(mixer), 오실레이터(oscillator), 디지털-아날로그 변환기(digital-to-analog convertor, DAC), 아날로그-디지털 변환기(analog-to-digital convertor, ADC) 등을 포함할 수 있다. 또한, 무선 통신 인터페이스 210은 다수의 송수신 경로들을 포함할 수 있다. 또한, 무선 통신 인터페이스 210은 다수의 안테나 소자들로 구성된 적어도 하나의 안테나 어레이를 포함할 수 있다.

하드웨어 측면에 있어서, 무선 통신 인터페이스 210은 디지털 유닛 및 아날로그 유닛을 포함할 수 있고, 아날로그 유닛은 동작 전력 및 동작 주파수 등에 따라 다수의 서브-유닛들을 포함할 수 있다. 디지털 유닛은 적어도 하나의 프로세서(예를 들어, 디지털 신호 프로세서 (digital signal processor, DSP))로서 구현될 수 있다.

무선 통신 인터페이스 210은 상술한 바와 같이 신호를 송수신한다. 따라서, 무선 통신 인터페이스 210은 "송신기(transmitter)", "수신기(receiver)" 또는 "송수신기(transceiver)"로 지칭될 수 있다. 또한, 이하의 설명에 있어서, 무선 채널을 통해 수행되는 송신 및 수신은 상술한 바와 같이 무선 통신 인터페이스 210에 의해 수행되는 처리(processing)를 포함하는 의미를 갖기 위해 사용될 수 있다.

백홀 통신 인터페이스 220은 네트워크 내의 다른 노드들과 통신을 수행하기 위한 인터페이스를 제공한다. 즉, 백홀 통신 인터페이스 220은 기지국으로부터 다른 노드, 예를 들어, 또다른 액세스 노드(access node), 다른 기지국(another BS), 상위 노드(higher node) 또는 코어 네트워크(core network)로 송신된 비트 스트림들을 물리 신호로 변환하고, 다른 노드로부터 수신한 물리 신호를 비트 스트림들로 변환한다.

저장부 230은 기본 프로그램, 어플리케이션 및 기지국 110의 동작을 위한 설정 정보와 같은 데이터를 저장한다. 저장부 230은 휘발성(volatile) 메모리, 비-휘발성(non-volatile) 메모리 또는 휘발성 메모리 및 비-휘발성 메모리의 결합을 포함할 수 있다. 또한, 저장부 230은 제어부 240로부터의 요청에 응답하여 저장된 데이터를 제공한다.

제어부 240은 기지국의 전반적인 동작을 제어한다. 예를 들어, 제어부 240은 무선 통신 인터페이스 210 또는 백홀 통신 인터페이스 220을 통해 신호를 송수신한다. 또한, 제어부 240는 저장부 230에 데이터를 기록하고, 기록된 데이터를 판독한다. 제어부 240은 통신 표준에서 요구되는 프로토콜 스택(protocol stack)의 기능을 수행할 수 있다. 다른 구현 예에 따르면, 프로토콜 스택은 무선 통신 인터페이스 210에 포함될 수 있다. 이를 위해, 제어부 240은 적어도 하나의 프로세서를 포함할 수 있다.

도 3은 본 개의 다양한 실시 예들에 따라 무선 통신 시스템에서 단말을 도시한다. 도 3에 예시된 구조는 단말 120 또는 단말 130의 구조로서 이해될 수 있다. 이하에서 사용된 "모듈(module)", "??부(unit)" 또는 "??기(-er)" 등의 용어는 적어도 하나의 기능이나 동작을 처리하는 단위를 의미하며, 하드웨어, 소프트웨어 또는 하드웨어 및 소프트웨어의 결합으로 구현될 수 있다.

도 3을 참고하면, 단말 120은 통신 인터페이스 310, 저장부 320 및 제어부 330을 포함한다.

통신 인터페이스 310은 무선 채널을 통해 신호들을 송수신하는 기능들을 수행한다. 예를 들어, 통신 인터페이스 310은 시스템의 물리 계층 표준에 따라 기저대역 신호(baseband signal)와 비트 스트림들(bitstreams) 간의 변환 기능을 수행한다. 예를 들어, 데이터 송신 시, 통신 인터페이스 310은 송신 비트 스트림들을 부호화(encoding) 및 변조(modulating)함으로써 복소 심볼들을 생성한다. 또한, 데이터 수신 시, 통신 인터페이스 310은 기저 대역 신호를 복호화(decoding) 및 복조(demodulating)함으로써 수신 비트 스트림들을 재구성한다. 또한, 통신 인터페이스 310은 기저 대역 신호를 RF(radio frequency) 대역 신호로 상향 변환하여 안테나를 통해 송신한 후, 안테나를 통해 수신된 RF 대역 신호를 기저 대역 신호로 하향 변환한다. 예를 들어, 통신 인터페이스 310은 송신 필터, 수신 필터, 증폭기(amplifier), 믹서(mixer), 오실레이터(oscillator), 디지털-아날로그 변환기(digital-to-analog convertor, DAC), 아날로그-디지털 변환기(analog-to-digital convertor, ADC)를 포함할 수 있다.

또한, 통신 인터페이스 310은 다수의 송수신 경로들을 포함할 수 있다. 또한, 통신 인터페이스 310은 다수의 안테나 소자들로 구성된 적어도 하나의 안테나 어레이를 포함할 수 있다. 하드웨어 측면에 있어서, 통신 인터페이스 310은 디지털 회로 및 아날로그 회로(예를 들어, 무선 주파수 집적 회로(radio frequency integrated circuit, RFIC))를 포함할 수 있다. 디지털 회로 및 아날로그 회로는 하나의 패키지로서 구현될 수 있다. 디지털 회로는 적어도 하나의 프로세서(예를 들어, 디지털 신호 프로세서 (digital signal processor, DSP))로서 구현될 수 있다. 통신 인터페이스 310은 다수의 RF 체인들을 포함할 수 있다. 통신 인터페이스 310은 빔포밍을 수행할 수 있다.

통신 인터페이스 310은 상술한 바와 같이 신호를 송수신한다. 따라서, 통신 인터페이스 310은 "송신기(transmitter)", "수신기(receiver)" 또는 "송수신기(transceiver)"로 지칭될 수 있다. 또한, 이하의 설명에 있어서, 무선 채널을 통해 수행되는 송신 및 수신은 상술한 바와 같이 통신 인터페이스 310에 의해 수행되는 처리(processing)를 포함하는 의미를 갖기 위해 사용될 수 있다.

저장부 320은 기본 프로그램, 어플리케이션 및 기지국 110의 동작을 위한 설정 정보와 같은 데이터를 저장한다. 저장부 320은 휘발성(volatile) 메모리, 비-휘발성(non-volatile) 메모리 또는 휘발성 메모리 및 비-휘발성 메모리의 결합을 포함할 수 있다. 또한, 저장부 320은 제어부 330로부터의 요청에 응답하여 저장된 데이터를 제공한다.

제어부 330은 단말 120의 전반적인 동작을 제어한다. 예를 들어, 제어부 330은 통신 인터페이스 310을 통해 신호를 송수신한다. 또한, 제어부 330는 저장부 320에 데이터를 기록하고, 기록된 데이터를 판독한다. 제어부 330은 통신 표준에서 요구되는 프로토콜 스택(protocol stack)의 기능을 수행할 수 있다. 다른 구현 예에 따르면, 프로토콜 스택은 통신 인터페이스 310에 포함될 수 있다. 이를 위해, 제어부 330은 적어도 하나의 프로세서 또는 마이크로프로세서를 포함할 수 있거나, 프로세서의 일부를 실행할 수 있다. 또한, 통신 인터페이스 310 또는 제어부 330의 일부는 통신 프로세서(communication processor, CP)로 지칭될 수 있다.

예를 들어, 제어부 330은 본 개시의 실시 예들에 따른 동작을 수행하도록 단말을 제어할 수 있다.

도 4는 본 개시의 다양한 실시 예들에 따른 무선 통신 시스템에서 통신 인터페이스를 도시한다. 도 4는 도 2의 무선 통신 인터페이스 210 또는 도 3의 통신 인터페이스 310의 상세한 구성에 대한 예를 도시한다. 보다 구체적으로, 도 4는 도 2의 무선 통신 인터페이스 210 또는 도 3의 통신 인터페이스 310의 일부로서 빔포밍을 수행하기 위한 요소들을 도시한다.

도 4를 참고하면, 무선 통신 인터페이스 210 또는 통신 인터페이스 310은 부호화 및 회로 402, 디지털 회로 404, 다수의 송신 경로들 406-1 내지 406-N, 및 아날로그 회로 408을 포함한다.

부호화 및 변조 회로 402는 채널 인코딩을 수행한다. 채널 인코딩을 위해, 저밀도 패리티 체크(low-density parity check, LDPC) 코드, 컨벌루션(convolution) 코드 및 폴라(polar) 코드 중 적어도 하나가 사용될 수 있다. 부호화 및 변조 회로 402는 성상도(constellation) 매핑을 수행함으로써 변조 심볼들을 생성한다.

디지털 회로 404는 디지털 신호(예를 들어, 변조 심볼들)에 대한 빔포밍을 수행한다. 이를 위해, 디지털 회로 404는 변조 심볼들에 빔포밍 가중치들(beamforming weighted values)을 곱한다. 빔포밍 가중치들은 신호의 크기 및 위상을 변경하기 위해 사용될 수 있으며, "프리코딩 행렬(precoding matrix)" 또는 "프리코더(precoder)"로 지칭될 수 있다. 디지털 회로 404는 디지털적으로 빔포밍된 변조 심볼들을 다수의 전송 경로들 406-1 내지 406-N으로 출력한다. 이때, 다중 입력 다중 출력(multiple input multiple output, MIMO) 송신 기법에 따르면, 변조 심볼들이 다중화되거나 동일한 변조 심볼들이 다수의 송신 경로들 406-1 내지 406-N에 제공될 수 있다.

다수의 송신 경로들 406-1 내지 406-N은 디지털적으로 빔포밍된 디지털 신호들을 아날로그 신호들로 변환한다. 이를 위해, 다수의 송신 경로들 406-1 내지 406-N 각각은 역 고속 푸리에 변환(inverse fast Fourier transform, IFFT) 계산 유닛, 순환 전치(cyclic prefix, CP) 삽입 유닛, DAC 및 상향 변환 유닛을 포함할 수 있다. CP 삽입 유닛은 직교 주파수 분할 다중화(Orthogonal Frequency Division Multiplexing, 이하 'OFDM'이라 칭함) 기법을 사용하며, 다른 물리 계층 기법(예를 들어, 필터 뱅크 다중-반송파(filter bank multi-carrier): FBMC)이 적용될 경우 생략될 수 있다. 즉, 다수의 송신 경로들 406-1 내지 406-N은 디지털 빔포밍을 통해 생성된 다수의 스트림들에 대해 독립적인 신호 처리 과정을 제공한다. 그러나, 구현에 따라, 다수의 송신 경로들 406-1 내지 406-N의 요소들 중 일부는 공통으로 사용될 수 있다.

아날로그 회로 408은 아날로그 신호들에 대한 빔포밍을 수행한다. 이를 위해, 디지털 회로 404는 아날로그 신호들에 빔포밍 가중치들을 곱한다. 빔포밍 가중치들은 신호의 크기와 위상을 변경하기 위해 사용된다. 보다 구체적으로, 다수의 송신 경로들 406-1 내지 406-N 및 안테나들 간의 연결 구조에 따라, 아날로그 회로 408은 다양한 방식들로 구성될 수 있다. 예를 들어, 다수의 송신 경로들 406-1 내지 406-N 각각은 하나의 안테나 어레이에 연결될 수 있다. 다른 예에 있어서, 다수의 송신 경로들 406-1 내지 406-N은 하나의 안테나 어레이에 연결될 수 있다. 또 다른 예에 있어서, 다수의 송신 경로들 406-1 내지 406-N은 하나의 안테나 어레이에 적응적으로 연결되거나, 둘 이상의 안테나 어레이들에 연결될 수 있다.

공통 API 프레임워크는, 제3 자 어플리케이션들 또는 어플리케이션 서버들에 의해, 적어도 하나의 서비스 API들에 대한 그러한 공통 능력들에 액세스하는 일관된 접근 방식을 마련하는 공통 기능들 또는 능력들(등록, 발견, 인증, 허가 등)로 구성된다.

이러한 필요성을 해결하기 위해, 3GPP는 3GPP 노스바운드 API(FS_CAPIF)에 대한 공통 API 프레임워크에 대한 새로운 연구를 개시했다. CAPIF의 기술 보고서(TR 23. 722 v0.1.1)는 상위 레벨 아키텍처의 초기 솔루션을 포착했다. 참조 포인트 A1은 프레임워크 기능들을 노출하는 API를 나타내고, 참조 포인트 A2는 서비스 기능을 호출하기 위한 서비스 API들을 노출하고, A3는 프레임워크 기능들과 서비스 API들 간의 상호 작용들을 나타낸다. API 소비자(consumer), 즉, 제3 자 어플리케이션(또는 어플리케이션 서버)은 네트워크 제공자(PLMN) 도메인 또는 PLMN 신뢰 도메인의 외부에 상주할 수 있다.

상위 레벨 아키텍처가 정의되었지만, "프레임워크 제어 기능들" 및 "공통 API 프레임워크 기능들"을 구성하는 것과 관련된 측면들과 이들 간의 상호 작용들이 어떻게 실현되는지는 현재 기술 보고서에 명시되거나 논의되지 않았다.

또한, 일련의 동작들, 예를 들어, 프레임워크의 어플리케이션 또는 API 소비자가 프레임워크의 기능들과 상호 작용하는 방식 및 프레임워크 기능들 간의 후속 상호 작용이 명확하지 않다. 또한, SCEF(예를 들어, NEF(network exposure function))이외의 기능들에 대한 프레임워크의 적용 가능성과, 운영자 도메인(operator domain) 외부에 있는 기능들(예를 들어, 재난 안전용 푸시 투 토크(mission critical push to talk, MCPTT 서버)도 고려될 필요가 있다. 또한, 서비스 제공자와 관련된 API 서비스 제공자 또는 관리(management) 엔티티가 이러한 모델들을 지원하기 위한 프레임 워크를 어떻게 구성할 수 있는지를 설명할 필요가 있다.

상술한 정보는 독자가 본 발명을 이해할 수 있도록 배경 정보로서 제공된다. 출원인들은 위의 어느 것도 본 출원과 관련하여 선행 기술로 적용될 수 있는지 여부에 대해 결정하지 않았으며 주장하지 않았습니다.

도면들을 참고하면, 특히 유사한 도면 부호가 도면들 전체에 걸쳐 일관되게 대응하는 특징들을 나타내는 도 5 내지 도 12를 참고하면, 바람직한 실시 예들이 도시된다.

도 5는 본 개시의 일 실시 예에 따른 CAPIF 코어 기능이 존재하는 동일한 도메인 내 API 제공자와는 별도의 제3 자 API 제공자들을 지원하는 공통 API 프레임워크(CAPIF) 아키텍처를 도시한다.

도 5에 도시된 바와 같이, 네트워크 엔티티 600은 제3 자 신뢰 도메인에 상주한다. 제3 자 신뢰 도메인은 PLMN과 비지니스 관계(business relationship)를 가진다. 네트워크 엔티티는, 예를 들어, 적어도 하나의 서비스 API들을 호스팅하는 서버, 네트워크 노드 또는 네트워크 요소일 수 있다.

네트워크 엔티티 600은 API 노출 기능 604, API 발행 기능 606 및 API 관리 기능 608을 포함하는 API 제공자 602를 포함한다. 네트워크 엔티티 600은 PLMN 신뢰 도메인 내의 CAPIF 코어 기능 510과 상호 작용한다.

PNMN 신뢰 도메인 내의 CAPIF 코어 기능 510은 PLMN 신뢰 도메인 및 제3 자 신뢰 도메인 양자로부터 서비스 API들을 지원한다. API 호출자들은 도 5에 도시된 바와 같이 PLMN 신뢰 도메인 내부, 제3 자 신뢰 도메인 내부 또는 PLMN 신뢰 도메인과 제3 자 신뢰 도메인 외부에 존재할 수 있다. 제3 자 신뢰 도메인 내 API 제공자 602는 PLMN 운영자로부터의 서비스 API들을 제공한다. PLMN 도메인 내 API 제공자 502는 제3 자로부터의 서비스 API들을 제공한다. 제3 자 API 제공자가 PLMN의 신뢰할 수 있는 제3 자인 경우, API 제공자 602는 또한 제3 자로부터의 서비스 API들을 제공한다.

PNMN 신뢰 도메인 내의 API 호출자 2는 CAPIF-1을 통해 CAPIF 코어 기능 510과 상호 작용하고, CAPIF-2를 통해 PLMN 신뢰 도메인 내 서비스 API들을 호출하고, CAPIF-2e를 통해 제3 자 신뢰 도메인의 서비스 API들을 호출한다. 제3 자 신뢰 도메인 내의 API 호출자 3은 CAPIF-1e를 통해 CAPIF 코어 기능 510과 상호 작용하고, CAPIF-2e를 통해 PLMN 신뢰 도메인의 서비스 API들을 호출하고 CAPIF-2를 통해 제3 자 신뢰 도메인의 서비스 API들을 호출한다.

PLMN 신뢰 도메인 및 제3 자 신뢰 메인 외부의 API 호출자 1은 CAPIF-1e를 통해 CAPIF 코어 기능 510과 상호 작용하고, CAPIF-2e를 통해 제3 자 신뢰 도메인 내 서비스 API들 및 PLMN 신뢰 도메인 내 서비스 API들을 호출한다.

일 실시 예에 있어서, PLMN 신뢰 도메인 내의 API 노출 기능 504, API 발행 기능 506 및 API 관리 기능 508은 각각 CAPIF-3, CAPIF-4 및 CAPIF-5 통해 CAPIF 코어 기능 510과 상호 작용한다.

CAPIF-3 및 CAPIF-4 인터페이스는 서비스 API들이 API 발행 기능 506을 통해 CAPIF 코어 기능 510과 상호 작용할 수 있게 한다. CAPIF-3 및 CAPIF-4 인터페이스는 다음 기능을 지원한다:

1. 서비스 API들을 어플리케이션들이 발견할 수 있도록 서비스 API 정보를 API 레지스트리에 발행하고,

2. 서비스 API 호출 시 어플리케이션 인증을 확인하고,

3. CAPIF 코어 기능 510으로부터 서비스 API에 액세스하기 위한 허가를 수신하고,

4. API 수명주기(lifecycle) 관리, 예를 들어, 서비스 API의 시작 또는 중지에 대한 CAPIF 코어 기능 510을 알린다.

5. API 이벤트들, 예를 들어, 서비스 API를 호출하는 어플리케이션의 위치 변경 또는 서비스 API의 결함(fault)에 대한 CAPIF 코어 기능 510을 보고하고,

6. API 모니터링 이벤트들, 예를 들어, 로드(load), 리소스 사용량에 대한 CAPIF 코어 기능 510을 보고하고,

7. 서비스 API 호출 이벤트들을 CAPIF, 예를 들어, 호출자 ID, IP 주소, 서비스 API 이름, 버전, 입력 파라미터들, 호출 결과, 타임 스탬프에 로그(log)하고,

8. 서비스 API 호출로부터 생성된 과금 기록들을 CAPIF 코어 기능 510에 보고하는 것과,

9. 서비스 API들에서 API 제공자가 구성된 정책들을 시행하는 것.

API 관리 기능 508과 CAPIF 코어 기능 510 간 상호 작용은 CAPIF-5 인터페이스에 의해 표현된다.

CAPIF-5 인터페이스는 API 제공자가 API 관리 기능을 위해 CAPIF 코어 기능 510과 상호 작용할 수 있게 한다. CAPIF-5 인터페이스는 다음 기능을 지원한다:

1. API 제공자가 정책들, 예를 들어, API 호출 제한, 로밍(roaming) 중에 API 호출이 허용되는지 여부에 상관없이 API 호출을 특정 기간동안 차단하는 것을 구성할 수 있게 하고,

2. 어플리케이션마다 서비스 API들의 액세스 제어 목록을 구성하고.

3. 서비스 API 호출 이벤트 로그들에 액세스하고, 로그 저장 기간을 구성하고,

4. CAPIF 코어 기능 510이 새로운 어플리케이션 등록의 승인을 요청하고, 성공적으로 등록을 확인하고,

5. API 제공자가 데이터베이스에 저장된 어플리케이션 프로파일 정보를 업데이트할 수 있게 하고,

6. API 제공자가 서비스 API의 수명주기 상태를 관리(govern), 예를 들어, 파일럿(pilot) 또는 라이브(live), 추적(trace) 및 액세스 API 버져닝(versioning), 서비스 API 가시성(visibility) 제어(서비스 API 시작 또는 중지)를 할 수 있게 하고,

7. API 제공자가 서비스 API 이벤트들, 예를 들어, 서비스 API의 결함 또는 어플리케이션 호출 API의 위치 변경, FHEM, 자원 사용량, 과금 기록들을 통지할 수 있게 함.

일 실시 예에 있어서, 제3 자 신뢰 도메인 내의 API 제공자 602의 API 노출 기능 604, API 발행 기능 606 및 API 관리 기능 608은 각각 CAPIF-3e, CAPIF-4e, CAPIF-5e을 통해 PLMN 신뢰 도메인 내의 CAPIF 코어 기능 510과 상호 작용한다. PLMN 신뢰 도메인 및 제3 자 신뢰 도메인의 API 노출 기능 604는 각각의 신뢰 도메인에 의해 제공되는 API 호출자에게 서비스 API들을 제공한다.

일 실시 예에 있어서, API 노출 기능 604는 CAPIF-3e 인터페이스를 통해 서비스 API들의 액세스 제어, 데이터 로깅, 과금, 인증 및 허가 중 적어도 하나를 수행하기 위해 CAPIF 코어 기능 510과 통신한다.

일 실시 예에 있어서, 제3 자 도메인과 관련된 API 발행 기능 606은 적어도 하나의 서비스 API들을 CAPIF-4e를 통해 PLMN 도메인에서 CAPIF 코어 기능 510으로 발행한다. API 발행 기능 606은 서비스 API들이 CAPIF 코어 기능 510과 상호 작용하도록 지원하고, 일부의 경우에는 API 관리 기능 608로부터 서비스 API 관련 관리 명령을 수신하는 논리적(logical) 엔티티이다. 논리 엔티티는 프레임워크 제어 에이전트(agent) 또는 프레임워크 제어 기능(function)이라고도 불리며, 물리적으로 서비스 API들 또는 독립형(standalone) 엔티티로 배열될 수 있다.

일 실시 예에 있어서, API 관리 기능 608은 PLMN 도메인에서 CAPIF 코어 기능 510과 통신하여 CAPIF-5e를 통한 액세스 모니터링, 정책 구성 및 API 호출자 클라이언트들의 프로비저닝 중 적어도 하나를 수행한다. 또한, API 관리 기능 608은 API 제공자 502가 CAPIF 코어 기능 510으로 API 관리 정보를 읽고 쓸 수 있게 하며, API 제공자가 API 발행 기능 606을 통해 서비스 API들에 관리 명령들을 제공할 수 있게 한다.

일 실시 예에 있어서, API 노출 기능 504/604와 CAPIF 코어 기능 510 간 통신,

API 발행 기능 506/606과 CAPIF 코어 기능 510 간 통신, API 관리 기능 508/608과 CAPIF 코어 기능 510 간 통신은 각각 CAPIF-3e, CAPIF-4e 및 CAPIF-5e를 통한 API 기반 통신이 될 수 있다. CAPIF-3, CAPIF-4 및 CAPIF-5 인터페이스에 의한 지원되는 다양한 기능들은 도 9와 관련하여 상세하게 설명된다.

도 6은 본 개시의 일 실시 예에 따른 PLMN 도메인 내 서비스 능력들을 지원하는 PLMN 도메인 내에서 CAPIF가 호스팅되는 경우 다양한 상호 작용을 도시한다.

도 6에 도시된 바와 같이, CAPIF 코어 기능 510은 PLMN 도메인 내에서 호스팅된다. CAPIF 코어 기능 510이 호스팅되는 경우, PLMN 신뢰 도메인 내의 API 노출 기능 504, API 발행 기능 506 및 API 관리 기능 508은 도 6에 도시된 바와 같이 각각 CAPIF-3, CAPIF-4 및 CAPIF-5를 통해 CAPIF 코어 기능 510과 상호 작용한다.

일 실시 예에 있어서, API 노출 기능 504는 도 6에 도시된 바와 같이 PLMN 서비스 능력들 및 PLMN 호스팅된 서비스 능력들을 호스팅한다.

PLMN 신뢰 도메인 내의 API 호출자 2는 CAPIF-1을 통해 CAPIF 코어 기능 510과 상호 작용하고, CAPIF-2를 통해 PLMN 신뢰 도메인 내의 서비스 API들을 호출한다. PLMN 신뢰 도메인 외부의 API 호출자 1은 CAPIF-1e를 통해 CAPIF 코어 기능 510과 상호 작용하고, CAPIF-2e를 통해 PLMN 신뢰 도메인의 서비스 API들을 호출한다.

도 7은 본 개시의 일 실시 예에 따른 PLMN 도메인 및 제3 자 도메인 내 API 관리(management)에서 CAPIF가 호스팅되는 경우 다양한 상호 작용을 도시한다. 도 7에 도시된 일 실 시 예에 있어서, CAPIF 코어 기능은 PLMN 신뢰 도메인에 상주하고, API 관리 기능 608은 제3 자 신뢰 도메인에 상주한다. 제3 자 신뢰 도메인 내의 API 관리 기능 608은 도 7에 도시된 바와 같이 CAPIF-5e를 통해 PLMN 신뢰 도메인 내의 CAPIF 코어 기능 510과 상호 작용한다.

도 8은 본 개시의 일 실시 예에 따른 PLMN 도메인과 제3 자 도메인 모두에서 CAPIF가 호스팅되는 경우 다양한 상호 작용을 도시한다. 도 8에 도시된 바와 같이, CAPIF 코어 기능은 PLMN 신뢰 도메인에 상주하고, API 관리 기능 608은 제3 자 신뢰 도메인에 상주한다.

일 실시 예에 있어서, PLMN 신뢰 도메인 내의 API 제공자 502의 API 노출 기능 504, API 발행 기능 506 및 API 관리 기능 508은 도 8에 도시된 바와 같이 각각 CAPIF-3, CAPIF-4 및 CAPIF-5를 통해 CAPIF 코어 기능 510과 상호 작용한다.

일 실시 예에 있어서, PLMN 신뢰 도메인 내의 API 제공자 602의 API 노출 기능 604, API 발행 기능 606 및 API 관리 기능 608은 도 8에 도시된 바와 같이 각각 CAPIF-3, CAPIF-4 및 CAPIF-5를 통해 CAPIF 코어 기능 610과 상호 작용한다.

도 9는 본 개시의 일 실시 예에 따른 제3 자가 도메인이 없는 경우 PLMN 도메인에서 호스팅되는 공통 API 프레임워크(CAPIF) 아키텍처를 도시한다. 도 9에 도시된 바와 같이, CAPIF 아키텍처는 PLMN 도메인(즉, 네트워크 운영자 도메인)에서 호스팅된다. 도 9에 도시된 바와 같이, PLMN 도메인은 네트워크 엔티티 500을 포함한다. 네트워크 엔티티는 서버, 네트워크 노드, 네트워크 요소 등일 수 있다. 네트워크 엔티티는 API 제공자 502, API 노출 기능 504, API 발행 기능 506, API 관리 기능 508을 포함한다.

일 실시 예에 있어서, PLMN 신뢰 도메인 내 API 제공자 502의 API 노출 기능 504, API 발행 기능 506 및 API 관리 기능 508은 각각 CAPIF-3, CAPIF-4 및 CAPIF-5를 통해 CAPIF 코어 기능 501과 상호 작용한다.

일 실시 예에 있어서, PLMN 신뢰 도메인 외부의 API 호출자 1은 CAPIF-1e를 통해 CAPIF 코어 기능 510과 상호 작용하고, 도 9에 도시된 바와 같이 CAPIF-2e를 통해 PLMN 신뢰 도메인 내의 서비스 API들을 호출한다.

일 실시 예에 있어서, PLMN 신뢰 도메인 내의 API 호출자 2는 CAPIF-1을 통해 CAPIF 코어 기능 510과 상호 작용하고, 도 9에 도시된 바와 같이 CAPIF-2를 통해 PLMN 신뢰 도메인 내의 서비스 API들을 호출한다.

일 실시 예에 있어서, API 호출자 1 및 API 호출자 2는 각각 CAPIF-1e 및 CAPIF-1을 통해 CAPIF 코어 기능 510에서 노스바운드 API들의 발견에 대해 인증된다.

API 노출 기능 504는 CAPIF-3e 인터페이스를 통해 서비스 API들의 액세스 제어, 데이터 로깅, 과금, 인증 및 허가 중 적어도 하나를 수행하기 위해 CAPIF 코어 기능 510과 통신한다. PLMN 신뢰 도메인과 연관된 API 발행 기능 506은 CAPIF-4를 통해 CAPIF 코어 기능 510에 적어도 하나의 서비스 API들을 발행한다. 또한, 제3 자 도메인과 관련된 API 발행 기능 606은 CAPIF-4e를 통해 적어도 하나의 서비스 API들을 PLMN 도메인의 CAPIF 코어 기능 510에 발행한다.

일 실시 예에 있어서, API 관리 기능 508은 PLMN 도메인에서 CAPIF 코어 기능 510과 통신하여 CAPIF-5를 통한 액세스 모니터링, 정책 구성 및 API 호출자 클라이언트의 프로비저닝 중 적어도 하나를 수행한다.

서비스 API들과 CAPIF 코어 기능 510 사이의 상호 작용은 2개의 기준점들, 즉 CAPIF-3 + CAPIF-4 및 CAPIF-5에 의해 표현된다.

도 10은 본 개시의 일 실시 예에 따른 CAPIF와 LTE(long term evolution) 시스템의 통합을 도시한다. 도 10에 도시된 바와 같이, CAPIF는 LTE 시스템에 있어서 SCEF(service capability exposure function)과 통합될 수 있다.

도 11은 본 개시의 일 실시 예에 따른 CAPIF와 NR(new radio) 시스템의 통합을 도시한다. 도 11에 도시된 바와 같이, CAPIF는 NR 시스템(즉, 5G 시스템)에 있어서 NEF와 통합될 수 있다.

도 12는 본 개시의 일 실시 예에 따른 무선 통신 시스템에서 네트워크 기반 노스바운드 API들을 제공하기 위한 방법을 나타내는 흐름도 1200이다. 흐름도의 다양한 단계들은 API 노출 기능 504/604, API 발행 기능 506/606 및 API 관리 기능 508/608을 사용하여 PLMN 도메인 또는 제3 자 신뢰 도메인에 상주하는 네트워크 엔티티 500/600에 의해 수행된다.

단계 1202에 있어서, 방법은 적어도 하나의 API 호출자 클라이언트들로부터 적어도 하나의 API들을 호출하기 위한 요청을 수신하는 단계를 포함한다. 네트워크 엔티티는 제1 도메인(즉, PLMN 신뢰 도메인) 또는 제2 도메인(즉, 제3 자 신뢰 도메인)에 상주한다.

단계 1204에 있어서, 방법은 적어도 하나의 서비스 API들을 제공하기 위해 제1 도메인에 상주하는 CAPIF 코어 기능 510을 이용하는 단계를 포함한다. 제1 도메인은 PLMN 신뢰 도메인일 수 있다. 일 실시 예에 있어서, CAPIF 코어 기능 510은 도 8에 도시된 바와 같이 제2 도메인에 상주한다.

단계 1206에 있어서, 방법은 CAPIF 코어 기능 510/610을 통해 적어도 하나의 API 호출자 클라이언트들에 적어도 하나의 서비스 API들을 제공하는 단계를 포함한다.

본 개시의 실시 예들은 적어도 하나의 하드웨어 장치 상에서 실행되는 적어도 하나의 소프트웨어 프로그램을 통해 구현될 수 있고, 구성 요소를 제어하기 위해 네트워크 관리 기능을 수행할 수 있다.

도 13은 본 개시의 다양한 실시 예들에 따른 무선 통신 시스템에 네트워크 엔티티를 도시한다. 예를 들어, 네트워크 엔티티는 API 제공자일 수 있다. 이하에서 사용된 "모듈(module)", "??부(unit)" 또는 "??기(-er)" 등의 용어는 적어도 하나의 기능이나 동작을 처리하는 단위를 의미하며, 하드웨어, 소프트웨어 또는 하드웨어 및 소프트웨어의 결합으로 구현될 수 있다.

도 13을 참고하면, 네트워크 엔티티는 백홀 통신 인터페이스 1310, 저장부 1320 및 제어부 1330을 포함할 수 있다.

백홀 통신 인터페이스 1310은 네트워크 내의 다른 노드와 통신을 수행하기 위한 인터페이스를 제공한다. 즉, 백홀 통신 인터페이스 1310은 기지국으로부터 다른 노드, 예를 들어, 또다른 액세스 노드(access node), 다른 기지국(another BS), 상위 노드(higher node) 또는 코어 네트워크(core network)로 송신된 비트 스트림들을 물리 신호로 변환하고, 다른 노드로부터 수신한 물리 신호를 비트 스트림들로 변환한다.

저장부 1320은 기본 프로그램, 어플리케이션 및 네트워크 엔티티의 동작을 위한 설정 정보와 같은 데이터를 저장한다. 저장부 1320은 휘발성(volatile) 메모리, 비-휘발성(non-volatile) 메모리 또는 휘발성 메모리 및 비-휘발성 메모리의 결합을 포함할 수 있다. 또한, 저장부 1320은 제어부 1330으로부터의 요청에 응답하여 저장된 데이터를 제공한다.

제어부 1330은 네트워크 엔티티의 전반적인 동작을 제어한다. 예를 들어, 제어부 1330은 백홀 통신 인터페이스 1310을 통해 신호를 송수신한다. 또한, 제어부 1330는 저장부 1320에 데이터를 기록하고, 기록된 데이터를 판독한다. 제어부 1330은 통신 표준에서 요구되는 프로토콜 스택(protocol stack)의 기능을 수행할 수 있다. 이를 위해, 제어부 1330은 적어도 하나의 프로세서를 포함할 수 있다.

본 발명의 예시적인 실시 예들에 따르면, 제어부 1330은 적어도 하나의 API 호출자 클라이언트들로부터 적어도 하나의 서비스들을 호출하기 위한 요청을 수신하고, 적어도 하나의 서비스 API들을 제공하기 위해 제1 도메인에 상주하는 CAPIF 코어 기능을 이용하고 CAPIF 코어 기능을 통해 적어도 하나의 호출자 클라이언트들에 적어도 하나의 서비스 API들을 제공할 수 있다. 여기서, API 제공자는 적어도 하나의 서비스 API들, API 노출 기능, API 발행 기능 및 API 관리 기능을 포함한다.

예를 들어, 제어부 1330은 본 개시의 실시 예들에 따른 동작들을 수행하도록 네트워크 엔티티를 제어할 수 있다.

특정 실시 예들에 대한 상술한 설명은 현재의 지식을 적용함으로써, 다른 사람들이 일반적인 개념을 벗어나지 않고 이러한 특정 실시 예들을 다양한 어플리케이션에 용이하게 변형 및/또는 적응시킬 수 있는 본 실시 예의 일반적인 성질을 완전히 밝힐 것이다. 그러므로, 그러한 적응 및 수정은 개시된 실시 예들의 등가물의 의미 및 범위 내에서 이해되도록 의도되고 이해되도록 의도된다. 여기에 사용된 표현 또는 용어는 설명을 위한 것이지 제한하려는 것이 아님을 이해해야 한다. 따라서, 본 명세서의 실시 예가 바람직한 실시 예와 관련하여 설명되었지만, 당업자는 본 명세서의 실시 예가 본 명세서에서 설명된 실시 예의 사상 및 범위 내에서 변형하여 실시될 수 있음을 인식할 것이다.

본 명세서의 청구 범위 및/또는 명세서에 언급된 실시 예에 따른 방법은 하드웨어, 소프트웨어, 또는 하드웨어와 소프트웨어의 조합으로 구현될 수 있다.

상기 방법들이 소프트웨어에 의해 구현되는 경우, 적어도 하나의 프로그램들 (소프트웨어 모듈들)을 저장하기 위한 컴퓨터 판독 가능 저장 매체가 제공될 수 있다. 컴퓨터 판독 가능 저장 매체에 저장된 적어도 하나의 프로그램은 전자 장치 내의 적어도 하나의 프로세서에 의한 실행을 위해 구성될 수 있다. 적어도 하나의 프로그램은 전자 장치로 하여금 첨부된 청구항들 및/또는 본 명세서에 개시된 바와 같이 본 개시의 다양한 실시 예들에 따른 방법들을 수행하게 하는 명령들을 포함할 수 있다.

프로그램 (소프트웨어 모듈 또는 소프트웨어)은 랜덤 액세스 메모리 및 플래시 메모리를 포함하는 비 휘발성 메모리, 판독 전용 메모리 (ROM), 전기적 소거 *?*가능 프로그래머블 판독 전용 메모리 (EEPROM), 자기 (CD-ROM), DVD (digital versatile disc) 또는 다른 유형의 광학 저장 장치 또는 자기 카세트와 같은 임의의 유형의 광학 저장 장치 일 수 있다. 대안 적으로, 프로그램의 일부 또는 전부의 임의의 조합이 프로그램이 저장된 메모리를 형성할 수 있다. 또한, 복수의 그러한 메모리가 전자 장치에 포함될 수 있다.

또한, 프로그램은 인터넷, 인트라넷, 근거리 통신망 (LAN), 광역 통신망 (WAN) 및 저장 영역 네트워크 (SAN)와 같은 통신 네트워크를 통해 액세스 가능한 부착 가능한 저장 장치에 저장될 수 있다. 또는, 이들의 조합을 포함할 수 있다. 이러한 저장 장치는 외부 포트를 통해 전자 장치에 액세스 할 수 있다. 또한, 통신 네트워크상의 개별 저장 장치는 휴대용 전자 장치에 액세스 할 수 있다.

상술한 본 발명의 상세한 설명에서는 본 발명의 바람직한 실시 예에 대하여 설명하였지만, 본 발명이 이에 한정되는 것은 아니다. 그러나, 제시된 상황에 적합한 설명의 편의를 위해 단수 형태 또는 복수 형태가 선택되며, 본 발명의 다양한 실시 예는 단일 요소 또는 복수 요소로 제한되지 않는다. 또한, 설명에서 표현된 복수의 요소 중 어느 하나가 단일 요소로 구성될 수도 있고, 설명 내의 단일 요소가 복수의 요소로 구성될 수도 있다.

본 발명은 그 특정 실시 예를 참조하여 도시되고 설명되었지만, 본 개시의 범위를 벗어나지 않으면 서 형태 및 세부 사항의 다양한 변화가 이루어질 수 있음이 당업자에 의해 이해될 것이다. 그러므로, 본 개시의 범위는 실시 예에 한정되는 것으로서 정의되어서는 안되며, 첨부된 청구 범위 및 그 등가물에 의해 정의되어야 한다.

본 발명은 예시적인 실시 예로 설명되었지만, 다양한 변경 및 수정이 당업자에게 제안될 수 있다. 본 개시는 첨부된 청구 범위의 범주 내에 속하는 그러한 변경 및 수정을 포함하는 것으로 의도된다.

Claims (36)

1. 무선 통신 시스템에서 어플리케이션 프로그래밍 인터페이스(application programming interface, API) 제공자가 수행하는 방법에 있어서,
   API 호출자(invoker)로부터 적어도 하나의 서비스 API들을 호출하기 위한 요청을 수신하는 과정과, 상기 API 호출자는, 공통 API framework(common API framework, CAPIF) 코어 기능의 도메인인 퍼블릭 랜드 모바일 네트워크(public land mobile network, PLMN) 도메인 및 상기 PLMN 도메인과 다른 도메인 중 어느 하나에 존재하고,
   상기 요청에 기반하여, 상기 적어도 하나의 서비스 API들에 관한 액세스 컨트롤을 수행하기 위하여 상기 CAPIF 코어 기능과 통신하는 과정과,
   상기 API 호출자에게 상기 적어도 하나의 서비스 API들을 제공하는 과정을 포함하고,
   상기 API 제공자는 API 관리 기능을 포함하고, 상기 API 제공자는 상기 PLMN 도메인과 다른 도메인에 존재하고,
   상기 API 관리 기능은, 상기 API 제공자가 상기 PLMN 도메인에 존재할 때 상기 CAPIF 코어 기능과 통신하기 위한 제1 인터페이스와 다른 제2 인터페이스를 통해 상기 CAPIF 코어 기능과 통신하는 방법.
   
2. 제1항에 있어서,
   상기 API 제공자는 액세스 제어를 수행하기 위해 상기 CAPIF 코어 기능과 통신하는 방법.
   
3. 제1항에 있어서,
   상기 API 제공자는 로깅(logging)을 수행하기 위해 상기 CAPIF 코어 기능과 통신하는 방법.
   
4. 제1항에 있어서,
   상기 API 제공자는 과금(charging)을 수행하기 위해 상기 CAPIF 코어 기능과 통신하는 방법.
   
5. 제1항에 있어서,
   상기 API 제공자는 인증 및 허가를 수행하기 위해 상기 CAPIF 코어 기능과 통신하는 방법.
   
6. 무선 통신 시스템에서 어플리케이션 프로그래밍 인터페이스(application programming interface, API) 제공자에 있어서,
   신호를 송신 또는 수신하기 위하여 설정된 송수신기; 및
   상기 송수신기와 연결된 적어도 하나의 프로세서를 포함하고,
   상기 적어도 하나의 프로세서는, API 호출자(invoker)로부터 적어도 하나의 서비스 API들을 호출하기 위한 요청을 수신하고, 상기 API 호출자는, 공통 API framework(common API framework, CAPIF) 코어 기능의 도메인인 퍼블릭 랜드 모바일 네트워크(public land mobile network, PLMN) 도메인 및 상기 PLMN 도메인과 다른 도메인 중 어느 하나에 존재하고,
   상기 요청에 기반하여, 상기 적어도 하나의 서비스 API들에 관한 액세스 컨트롤을 수행하기 위하여 상기 CAPIF 코어 기능과 통신하고,
   상기 API 호출자에게 상기 적어도 하나의 서비스 API들을 제공하도록 설정되고,
   상기 API 제공자는 API 관리 기능을 포함하고, 상기 API 제공자는 상기 PLMN 도메인과 다른 도메인에 존재하고,
   상기 API 관리 기능은, 상기 API 제공자가 상기 PLMN 도메인에 존재할 때 상기 CAPIF 코어 기능과 통신하기 위한 제1 인터페이스와 다른 제2 인터페이스를 통해 상기 CAPIF 코어 기능과 통신하는 API 제공자.
   
7. 제6항에 있어서,
   상기 API 제공자는 액세스 제어를 수행하기 위해 상기 CAPIF 코어 기능과 통신하는 API 제공자.
   
8. 제6항에 있어서,
   상기 API 제공자는 로깅(logging)을 수행하기 위해 상기 CAPIF 코어 기능과 통신하는 API 제공자.
   
9. 제6항에 있어서,
   상기 API 제공자는 과금(charging)을 수행하기 위해 상기 CAPIF 코어 기능과 통신하는 API 제공자.
   
10. 제6항에 있어서,
    상기 API 제공자는 인증 및 허가를 수행하기 위해 상기 CAPIF 코어 기능과 통신하는 API 제공자.
11. 삭제
12. 삭제
13. 삭제
14. 삭제
15. 삭제
16. 삭제
17. 삭제
18. 삭제
19. 삭제
20. 삭제
21. 삭제
22. 삭제
23. 삭제
24. 삭제
25. 삭제
26. 삭제
27. 삭제
28. 삭제
29. 삭제
30. 삭제
31. 삭제
32. 삭제
33. 삭제
34. 삭제
35. 삭제
36. 삭제

Images