KR20230156833A

KR20230156833A - 플랫폼 독립적인 애플리케이션 프로그래밍 인터페이스 구성

Info

Publication number: KR20230156833A
Application number: KR1020237031331A
Authority: KR
Inventors: 엠마노우일 파테로미첼라키스; 이샨 바이시나비; 라비 쿠치보틀라
Original assignee: 레노보 (싱가포르) 피티이. 엘티디.
Priority date: 2021-03-16
Filing date: 2021-03-16
Publication date: 2023-11-14
Also published as: AU2021434516A1; CN116998141A; CA3208903A1; BR112023018957A2; EP4309311A1; WO2022194359A1

Abstract

플랫폼 독립적인 애플리케이션 프로그래밍 인터페이스들을 구성하기 위한 장치들, 방법들 및 시스템들이 개시된다. 장치(700)는 무선 통신 시스템의 적어도 하나의 네트워크 서비스의 서비스 파라미터를 수신하는(805) 트랜시버(725)를 포함한다. 무선 통신 시스템은 하나 이상의 플랫폼을 포함한다. 장치(700)는 무선 통신 시스템의 적어도 하나의 네트워크 서비스의 서비스 파라미터에 기반하여 플랫폼 독립적인 애플리케이션 프로그래밍 인터페이스("API")를 결정하는(810) 프로세서(705)를 포함한다.

Description

플랫폼 독립적인 애플리케이션 프로그래밍 인터페이스 구성

본 명세서에 개시된 주제는 일반적으로 무선 통신들에 관한 것이며, 더 구체적으로는 플랫폼 독립적인 애플리케이션 프로그래밍 인터페이스들(platform independent application programming interfaces)을 구성하는 것에 관한 것이다.

버티컬(vertical) 및 슬라이스 애플리케이션 개발자들에게 노출되는 서비스 애플리케이션 프로그래밍 인터페이스들("API들")과 같은, 무선 통신 네트워크를 위한 API들은 상이한 벤더 및 기술 구현들에 걸쳐 휴대가능하지 않을 수 있다.

플랫폼 독립적인 애플리케이션 프로그래밍 인터페이스들을 구성하기 위한 절차들이 개시된다. 플랫폼 독립적인 애플리케이션 프로그래밍 인터페이스들을 구성하기 위한 신뢰 애플리케이션 엔티티(예를 들어, 미들웨어)의 제1 방법은 무선 통신 시스템의 적어도 하나의 네트워크 서비스의 서비스 파라미터를 수신하는 단계를 포함한다. 무선 통신 시스템은 하나 이상의 플랫폼을 포함한다. 제1 방법은, 일부 실시예들에서, 무선 통신 시스템의 적어도 하나의 네트워크 서비스의 서비스 파라미터에 기반하여 플랫폼 독립적인 애플리케이션 프로그래밍 인터페이스("API")를 결정하는 단계를 포함한다.

플랫폼 독립적인 애플리케이션 프로그래밍 인터페이스들을 구성하기 위한 제1 장치(예를 들어, 신뢰 애플리케이션 서버, 미들웨어 등)는 무선 통신 시스템의 적어도 하나의 네트워크 서비스의 서비스 파라미터를 수신하는 트랜시버를 포함한다. 무선 통신 시스템은 하나 이상의 플랫폼을 포함할 수 있다. 추가 실시예들에서, 제1 장치는 무선 통신 시스템의 적어도 하나의 네트워크 서비스의 서비스 파라미터에 기반하여 플랫폼 독립적인 애플리케이션 프로그래밍 인터페이스("API")를 결정하는 프로세서를 포함한다.

위에서 간략하게 설명된 실시예들의 더 구체적인 설명은 첨부 도면들에서 예시되는 특정 실시예들을 참조하여 이루어질 것이다. 이러한 도면들은 단지 일부 실시예들만을 도시할 뿐이고, 그에 따라, 범위를 제한하는 것으로 고려되지 않아야 한다는 이해 하에서, 실시예들은 첨부 도면들의 이용을 통해 추가적인 구체성 및 상세로 기술 및 설명될 것이다.
도 1은 플랫폼 독립적인 애플리케이션 프로그래밍 인터페이스들을 구성하기 위한 무선 통신 시스템의 일 실시예를 도시하는 개략적인 블록도이다.
도 2는 플랫폼 독립적인 애플리케이션 프로그래밍 인터페이스들을 구성하기 위한 네트워크 아키텍처 및 시그널링 흐름에 대한 절차의 일 실시예를 도시하는 도면이다.
도 3은 네트워크 슬라이스들에 대해 플랫폼 독립적인 애플리케이션 프로그래밍 인터페이스들을 구성하기 위한 절차의 일 실시예에 대한 시그널링 흐름을 도시하는 도면이다.
도 4는 휴대성을 위해 플랫폼 독립적인 애플리케이션 프로그래밍 인터페이스들을 구성하기 위한 절차의 일 실시예에 대한 시그널링 흐름을 도시하는 도면이다.
도 5는 O-RAN에 대해 플랫폼 독립적인 애플리케이션 프로그래밍 인터페이스들을 구성하기 위한 절차의 일 실시예에 대한 시그널링 흐름을 도시하는 도면이다.
도 6은 플랫폼 독립적인 애플리케이션 프로그래밍 인터페이스들을 구성하는데 이용될 수 있는 사용자 장비 장치의 일 실시예를 도시하는 도면이다.
도 7은 플랫폼 독립적인 애플리케이션 프로그래밍 인터페이스들을 구성하는데 이용될 수 있는 네트워크 장비 장치의 일 실시예를 도시하는 도면이다.
도 8은 플랫폼 독립적인 애플리케이션 프로그래밍 인터페이스들을 구성하는데 이용될 수 있는 방법의 일 실시예를 도시하는 흐름도이다.

본 기술분야의 통상의 기술자에 의해 인식될 바와 같이, 실시예들의 양태들은 시스템, 장치, 방법, 또는 프로그램 제품으로서 구현될 수 있다. 따라서, 실시예들은 전체적인 하드웨어 실시예, 전체적인 소프트웨어 실시예(펌웨어, 상주 소프트웨어, 마이크로-코드 등을 포함함), 또는 소프트웨어와 하드웨어 양태들을 조합한 실시예의 형태를 취할 수 있다.

예컨대, 개시되는 실시예들은 맞춤형 초고밀도 집적("VLSI") 회로들 또는 게이트 어레이들, 기성 반도체들, 이를테면, 로직 칩들, 트랜지스터들, 또는 다른 별개의 구성요소들을 포함하는 하드웨어 회로로서 구현될 수 있다. 개시되는 실시예들은 또한, 필드 프로그래밍가능한 게이트 어레이들, 프로그래밍가능한 어레이 로직, 프로그래밍가능한 로직 디바이스들 등과 같은 프로그래밍가능한 하드웨어 디바이스들로 구현될 수 있다. 다른 예로서, 개시되는 실시예들은, 예컨대, 오브젝트, 절차, 또는 함수로서 구성될 수 있는 실행가능한 코드의 하나 이상의 물리적 또는 논리적 블록을 포함할 수 있다.

게다가, 실시예들은 머신 판독가능한 코드, 컴퓨터 판독가능한 코드, 및/또는 프로그램 코드(이하에서, 코드로 지칭됨)를 저장하는 하나 이상의 컴퓨터 판독가능한 저장 디바이스에 구현되는 프로그램 제품의 형태를 취할 수 있다. 저장 디바이스들은 유형적, 비일시적, 및/또는 비전송일 수 있다. 저장 디바이스들은 신호들을 구현하지 않을 수 있다. 특정 실시예에서, 저장 디바이스들은 코드에 액세스하기 위한 신호들만을 이용한다.

하나 이상의 컴퓨터 판독가능한 매체의 임의의 조합이 활용될 수 있다. 컴퓨터 판독가능한 매체는 컴퓨터 판독가능한 저장 매체일 수 있다. 컴퓨터 판독가능한 저장 매체는 코드를 저장하는 저장 디바이스일 수 있다. 저장 디바이스는, 예컨대, 전자, 자기, 광학, 전자기, 적외선, 홀로그래픽, 마이크로기계, 또는 반도체 시스템, 장치, 또는 디바이스, 또는 전술된 것들의 임의의 적절한 조합일 수 있지만 이에 제한되지는 않는다.

저장 디바이스의 더 구체적인 예들(비포괄적인 리스트)은 다음의 것들을 포함할 것이다: 하나 이상의 와이어를 갖는 전기 접속, 휴대용 컴퓨터 디스켓, 하드 디스크, 랜덤 액세스 메모리("RAM"), 판독 전용 메모리("ROM"), 소거가능 프로그래밍가능한 판독 전용 메모리("EPROM" 또는 플래시 메모리), 휴대용 콤팩트 디스크 판독 전용 메모리("CD-ROM"), 광학 저장 디바이스, 자기 저장 디바이스, 또는 전술된 것들의 임의의 적절한 조합. 본 문서의 맥락에서, 컴퓨터 판독가능한 저장 매체는 명령어 실행 시스템, 장치, 또는 디바이스에 의해 또는 그와 관련하여 이용하기 위한 프로그램을 보유 또는 저장할 수 있는 임의의 유형적 매체일 수 있다.

실시예들에 대한 동작들을 수행하기 위한 코드는 임의의 수의 라인일 수 있고, 파이썬(Python), 루비(Ruby), 자바(Java), 스몰토크(Smalltalk), C++ 등과 같은 객체 지향 프로그래밍 언어, 및 "C" 프로그래밍 언어 등과 같은 종래의 절차적 프로그래밍 언어들을 포함하는 하나 이상의 프로그래밍 언어, 및/또는 어셈블리 언어들과 같은 머신 언어들의 임의의 조합으로 작성될 수 있다. 코드는 사용자의 컴퓨터 상에서 완전히 실행될 수 있거나, 독립형 소프트웨어 패키지로서 사용자의 컴퓨터 상에서 부분적으로 실행될 수 있거나, 사용자의 컴퓨터 상에서 부분적으로 그리고 원격 컴퓨터 상에서 부분적으로 실행될 수 있거나, 또는 원격 컴퓨터 또는 서버 상에서 완전히 실행될 수 있다. 후자의 시나리오에서, 원격 컴퓨터는 근거리 네트워크("LAN") 또는 광역 네트워크("WAN")를 포함하는 임의의 유형의 네트워크를 통해 사용자의 컴퓨터에 접속될 수 있거나, (예를 들어, 인터넷 서비스 제공자를 이용하여 인터넷을 통해) 외부 컴퓨터에 대해 접속이 이루어질 수 있다.

"일 실시예", "실시예", 또는 유사한 언어에 대한 본 명세서 전체에 걸친 언급은 실시예와 관련하여 설명되는 특정 특징, 구조, 또는 특성이 적어도 하나의 실시예에 포함된다는 것을 의미한다. 따라서, 본 명세서 전체에 걸친 "일 실시예에서", "실시예에서", 및 유사한 언어와 같은 문구들의 출현들은 모두 동일한 실시예를 지칭할 수 있지만 반드시 그런 것은 아니고, 명시적으로 달리 지정되지 않는 한 "모든 실시예들은 아닌 하나 이상의 실시예"를 의미할 수 있다. "포함하는", "갖는", 및 그 변형들과 같은 용어들은, 명시적으로 달리 지정되지 않는 한, "포함하지만 이에 제한되지는 않는"을 의미한다. 아이템들의 열거된 목록은, 명시적으로 달리 지정되지 않는 한, 아이템들 중 임의의 것 또는 전부가 상호 배타적이라는 것을 암시하지 않는다. 단수형의 용어들은 또한, 명시적으로 달리 지정되지 않는 한, "하나 이상"을 지칭한다.

본 명세서에서 사용되는 바와 같이, "및/또는"의 접속사를 갖는 리스트는 리스트 내의 임의의 단일 아이템 또는 리스트 내의 아이템들의 조합을 포함한다. 예컨대, A, B, 및/또는 C의 리스트는 A만을 포함하거나, B만을 포함하거나, C만을 포함하거나, A와 B의 조합을 포함하거나, B와 C의 조합을 포함하거나, A와 C의 조합을 포함하거나, 또는 A, B 및 C의 조합을 포함한다. 본 명세서에서 사용되는 바와 같이, "~ 중 하나 이상"이라는 용어를 사용하는 리스트는 리스트 내의 임의의 단일 아이템 또는 리스트 내의 아이템들의 조합을 포함한다. 예컨대, A, B, 및 C 중 하나 이상은 A만을 포함하거나, B만을 포함하거나, C만을 포함하거나, A와 B의 조합을 포함하거나, B와 C의 조합을 포함하거나, A와 C의 조합을 포함하거나, 또는 A, B 및 C의 조합을 포함한다. 본 명세서에서 사용되는 바와 같이, "~ 중 하나"라는 용어를 사용하는 리스트는 리스트 내의 임의의 단일 아이템 중 하나만을 포함한다. 예컨대, "A, B, 및 C 중 하나"는 A만을 포함하거나, B만을 포함하거나, 또는 C만을 포함하고, A, B, 및 C의 조합들을 배제한다. 본 명세서에서 사용되는 바와 같이, "A, B, 및 C로 구성된 그룹으로부터 선택되는 멤버"는 A, B, 또는 C 중 하나만을 포함하고, A, B, 및 C의 조합들을 배제한다. 본 명세서에서 사용되는 바와 같이, "A, B 및 C, 및 그 조합들로 구성된 그룹으로부터 선택되는 멤버"는 A만을 포함하거나, B만을 포함하거나, C만을 포함하거나, A와 B의 조합을 포함하거나, B와 C의 조합을 포함하거나, A와 C의 조합을 포함하거나, 또는 A, B, 및 C의 조합을 포함한다.

게다가, 실시예들의 설명되는 특징들, 구조들, 또는 특성들은 임의의 적절한 방식으로 조합될 수 있다. 다음의 설명에서, 실시예들의 완전한 이해를 제공하기 위해, 프로그래밍, 소프트웨어 모듈들, 사용자 선택들, 네트워크 트랜잭션들, 데이터베이스 질의들, 데이터베이스 구조들, 하드웨어 모듈들, 하드웨어 회로들, 하드웨어 칩들 등의 예들과 같은 다수의 특정 상세들이 제공된다. 그러나, 본 기술분야의 통상의 기술자는 실시예들이 특정 상세들 중 하나 이상 없이, 또는 다른 방법들, 구성요소들, 재료들 등을 이용하여 실시될 수 있다는 것을 인식할 것이다. 다른 경우들에서, 잘 알려져 있는 구조들, 재료들, 또는 동작들은 실시예의 양태들을 모호하게 하는 것을 피하기 위해 상세히 도시 또는 설명되지 않는다.

실시예들의 양태들은 실시예들에 따른 방법들, 장치들, 시스템들, 및 프로그램 제품들의 개략적인 흐름도들 및/또는 개략적인 블록도들을 참조하여 아래에서 설명된다. 개략적인 흐름도들 및/또는 개략적인 블록도들의 각각의 블록, 및 개략적인 흐름도들 및/또는 개략적인 블록도들 내의 블록들의 조합들은 코드에 의해 구현될 수 있다는 것을 이해할 것이다. 이러한 코드는 범용 컴퓨터, 특수 목적 컴퓨터, 또는 다른 프로그래밍가능한 데이터 처리 장치의 프로세서에 제공되어 머신을 생성할 수 있고, 그에 따라, 컴퓨터 또는 다른 프로그래밍가능한 데이터 처리 장치의 프로세서를 통해 실행되는 명령어들은 흐름도들 및/또는 블록도들에서 지정되는 기능들/동작들을 구현하기 위한 수단을 생성한다.

또한, 코드는 저장 디바이스에 저장될 수 있어서 컴퓨터, 다른 프로그래밍가능한 데이터 처리 장치, 또는 다른 디바이스들에게 특정 방식으로 기능할 것을 지시할 수 있고, 그에 따라, 저장 디바이스에 저장된 명령어들은 흐름도들 및/또는 블록도들에서 지정되는 기능/동작을 구현하는 명령어들을 포함하는 제조 물품을 생성한다.

또한, 코드는 컴퓨터, 다른 프로그래밍가능한 데이터 처리 장치, 또는 다른 디바이스들 상에 로딩되어, 일련의 동작 단계들이 컴퓨터, 다른 프로그래밍가능한 장치, 또는 다른 디바이스들 상에서 수행되게 하여 컴퓨터 구현 프로세스를 생성할 수 있고, 그에 따라, 컴퓨터 또는 다른 프로그래밍가능한 장치 상에서 실행되는 코드는 흐름도들 및/또는 블록도들에서 지정되는 기능들/동작들을 구현하기 위한 프로세스들을 제공한다.

도면들 내의 흐름도들 및/또는 블록도들은 다양한 실시예들에 따른 장치들, 시스템들, 방법들, 및 프로그램 제품들의 가능한 구현들의 아키텍처, 기능, 및 동작을 예시한다. 이와 관련하여, 흐름도들 및/또는 블록도들 내의 각각의 블록은 지정된 논리적 기능(들)을 구현하기 위한 코드의 하나 이상의 실행가능한 명령어를 포함하는 모듈, 세그먼트, 또는 코드의 일부분을 표현할 수 있다.

또한, 일부 대안적인 구현들에서, 블록에서 언급되는 기능들은 도면들에서 언급되는 순서와 다르게 발생할 수 있다는 점에 유의해야 한다. 예컨대, 관련된 기능에 따라, 연속적으로 도시된 2개의 블록이 실제로는 실질적으로 동시에 실행될 수 있거나, 또는 블록들은 때때로 역순으로 실행될 수 있다. 예시되는 도면들의 하나 이상의 블록 또는 그 부분들과 기능, 로직, 또는 효과에서 동등한 다른 단계들 및 방법들이 구상될 수 있다.

다양한 화살표 유형들 및 라인 유형들이 흐름도 및/또는 블록도에서 이용될 수 있지만, 그들은 대응하는 실시예들의 범위를 제한하지 않는 것으로 이해된다. 실제로, 일부 화살표들 또는 다른 커넥터들은 도시된 실시예의 논리적 흐름만을 표시하는데 이용될 수 있다. 예컨대, 화살표는 도시된 실시예의 열거된 단계들 사이의 지정되지 않은 지속기간의 대기 또는 모니터링 기간을 표시할 수 있다. 또한, 블록도들 및/또는 흐름도들의 각각의 블록, 및 블록도들 및/또는 흐름도들 내의 블록들의 조합들은 지정된 기능들 또는 동작들을 수행하는 특수 목적 하드웨어 기반 시스템들에 의해 구현될 수 있거나, 또는 특수 목적 하드웨어와 코드의 조합들에 의해 구현될 수 있다는 점에 유의해야 할 것이다.

각각의 도면 내의 요소들의 설명은 진행 도면들의 요소들을 지칭할 수 있다. 유사한 번호들은 유사한 요소들의 대안적인 실시예들을 포함하여 모든 도면들 내의 유사한 요소들을 지칭한다.

일반적으로, 본 개시내용은 플랫폼 독립적인 애플리케이션 프로그래밍 인터페이스들을 구성하기 위한 시스템들, 방법들 및 장치들을 설명한다. 관리 또는 제어 평면 API들의 플랫폼 의존적인 구현들로의 새로운 유형의 애플리케이션 프로그래밍 인터페이스("API")(예를 들어, 후술하는 플랫폼 독립적인 API, 네트워크 슬라이스 API, 및/또는 휴대성 API)의 매핑의 구성 및 프로비저닝이 본 명세서에 개시된다.

배경기술로서, 3GPP SA6에서, 노스바운드 API들(northbound APIs)을 버티컬들에 노출시키기 위한 미들웨어로서 작용하는 버티컬 애플리케이션 인에이블러 계층(TS 23.286에서의 V2X 인에이블러 서버, TR 23.745에서의 FF 인에이블러 서버, TR 23.755에서의 UAS 인에이블 서버)으로 알려진 것은 물론 접속된 디바이스들에 대한 일부 서버-클라이언트 지원 기능들을 제공하는, 버티컬 애플리케이션들에 대한 애플리케이션 지원 계층이 명시되었다. 또한, 3GPP SA6은 SEAL(TS 23.434)로 알려진 모든 버티컬 인에이블러 계층에 대한 공통점을 제공하였다.

또한, 3GPP SA6에서, 서비스 인에이블러 아키텍처 계층("SEAL")은 모든 버티컬들에 대한 지원 기능들(예를 들어, 네트워크 리소스 관리, 위치 관리, 구성 관리, 그룹 관리 등)을 제공하기 위한 공통 서비스 플랫폼으로서 정의되었다. SEAL(TS 23.434)은 서버 및 클라이언트 애플리케이션 대응물을 갖는 새로운 서비스, 즉 네트워크 슬라이스 인에이블러를 도입하였다. NSE 계층은 애플리케이션을 실행하는 모든 디바이스들에 대한 네트워크 슬라이스 적응/이전 능력을 제공한다. 이것은 (슬라이스 적응을 적용하기 위해) 디바이스 측에서 NSE 서버와 NSE 클라이언트뿐만 아니라 OAM과 NSE 서버 사이의 상호작용을 필요로 한다.

또한, 3GPP SA6은 3GPP 네트워크 기능들에 걸쳐 통합된 노스바운드 API 프레임워크를 가능하게 하기 위해, 그리고 API 개발을 위한 단일의 조화된 접근법(TS 23.222)이 있음을 보장하기 위해 공통 API 프레임워크("CAPIF")가 개발되었음을 명시하고 있다. CAPIF에서의 일부 핵심 기능들은 다음과 같다:

CAPIF 코어 기능("CCF")은 모든 PLMN 및 제3자 서비스 API들의 저장소이고;

API 노출 기능("AEF")은 API들로서의 서비스들의 제공자이고;

API 호출자는 통상적으로 서비스 제공자들로부터의 서비스를 요구하는 애플리케이션들이다.

또한, 본 명세서에서 사용되는 바와 같이, O-RAN은 액세스 도메인의 가상화를 조사하고, gNB와 함께 배치될 수 있거나 gNB들의 클러스터에 대해 배치될 수 있는 새로 정의된 RAN 지능형 제어기("RIC")에 대한 제어 기능들("RRC"/"RRM")의 가상화를 고려하는 동맹이다. 이러한 맥락에서, 슬라이스 격리 정책들뿐만 아니라 배치 및 기능적 요건들(실시간, 비실시간, 거의 실시간)이 주어지면, RRM/RRC 기능들은 CU/DU에 또는 전용 RIC 제어기들, 예를 들어, 근거리-RT RIC 및 비-RT RIC에 유연하게 배치될 수 있다.

본 명세서에서 사용되는 일부 용어들 및 정의들이 아래에 있다:

비-RT RIC: RAN 요소들 및 리소스들의 비-실시간 제어 및 최적화, 모델 훈련 및 업데이트들을 포함하는 인공 지능/머신 학습 작업흐름, 및 근거리-RT RIC에서의 애플리케이션들/특징들의 정책 기반 안내를 가능하게 하는 논리적 기능이다.

근거리-RT RIC 및 프레임워크 기능들: E2 인터페이스를 통한 미세(예를 들어, UE 기반, 셀 기반) 데이터 수집 및 액션들을 통해 RAN 요소들 및 리소스들의 거의 실시간 제어 및 최적화를 가능하게 하는 논리적 기능이다. 근거리-RT RIC는 예를 들어 가입 관리, 충돌 완화, E2 종료("E2T"), 관리 서비스들 등일 수 있는 근거리-RT RIC 기본/프레임워크 기능들을 포함한다.

관리 서비스들("MnS"): RIC 플랫폼의 관리 서비스들은 xApp의 라이프 사이클 관리("LCM") 및 근거리-RT RIC의 FCAPS 관리를 포함한다. 이러한 서비스들은 근거리-RT RIC에 의해 (개방 API를 통해) xApp에 또는 SMO(비-RT RIC)로부터 (O1을 통해) xApp들에 제공될 수 있다.

xApp: 근거리-RT RIC 상에서 실행되도록 설계된 애플리케이션이다. 이러한 애플리케이션은 하나 이상의 마이크로서비스로 구성될 가능성이 있고 온-보딩의 포인트에서 그것이 어느 데이터를 소비하는지 그리고 그것이 어느 데이터를 제공하는지를 식별할 것이다. 애플리케이션은 근거리-RT RIC와 독립적이고 임의의 제3자에 의해 제공될 수 있다. E2는 xApp와 RAN 기능 사이의 직접 연관을 가능하게 한다.

E2: 근거리-RT RIC와 하나 이상의 O-CU-CP, 하나 이상의 O-CU-UP, 및 하나 이상의 O-DU를 접속시키는 인터페이스이다.

E2 노드: E2 인터페이스를 종료시키는 논리적 노드이다.

E2SM: 근거리-RT RIC를 향한 E2 인터페이스를 통해 E2 노드 내의 특정 RAN 기능에 의해 노출된 서비스들의 설명이다.

E2AP: E2 애플리케이션 프로토콜("E2AP")은 본 문서에 정의된 시그널링 절차들에 의해 E2 인터페이스의 기능들을 지원한다.

개방 API/O-RAN API: 개방 API는 근거리-RT RIC에서의 정의 하에 있고 프레임워크 기능들과 xAPP들 사이의 인터페이스이다.

API 인에이블먼트(Enablement): API 인에이블먼트 서비스들은 RIC 플랫폼이 서비스 기반 방식으로 RIC 프레임워크 또는 xApp(들)에 의해 제공될 수 있는 O-RAN API들(O-RAN API들은 O-RAN 범위 내의 개방 API들로서 정의될 수 있음)에 대한 지원을 제공할 수 있게 한다. 특히, API 인에이블먼트 서비스들은 O-RAN API들에 대한 저장소/등록소 서비스들, 등록된 O-RAN API들의 발견을 허용하는 서비스들, O-RAN API들의 이용을 위해 xApp들을 인증하는 서비스들, 일반 가입 및 이벤트 통지를 가능하게 하는 서비스들을 포함한다. API 인에이블먼트 서비스들은 API 발견을 지원하고, 인증 및 일반 가입 및 이벤트 통지를 제공하기 위해 xApp(들)에 의해 xApp "인에이블먼트" API를 통해 액세스될 수 있다.

버티컬 및 슬라이스 애플리케이션 개발자들에게 노출된 서비스 API들은 벤더 및 기술 구현들에 걸쳐 휴대가능해야 한다. 이것은 모든 벤더 또는 기술 구현이 매핑될 수 있는 균일한 표준화된 API에 의해 달성될 수 있다. 벤더 의존적인 것으로부터 벤더 독립적인 휴대형 API로의 이 매핑은, 다양한 인자들, 주로, 특정한 버티컬의 벤더 의존적인 인터페이스를 이용하기 위한 허가에 따라 구성될 필요가 있을 것이다. 본 개시내용에 의해 해결될 상위 레벨 문제는 버티컬/슬라이스 고객들에 의해 소비될 서비스 API들을 구성하는 방법이다.

새로운 플랫폼 독립적인 API들은 버티컬 고객의 애플리케이션들과 기본 전기통신("텔코(telco)") 인프라스트럭처(예를 들어, 제어 및 관리 도메인들) 사이의 동적 상호작용들을 간소화한다. 이는 벤더 및 기술 도메인들에 걸쳐 고객과 전기통신 인프라스트럭처 사이의 균일한 상호작용들을 허용하고, 멀티-벤더 네트워크들, 전기통신 네트워크들의 복수의 인스턴스들에 걸쳐 그리고 상이한 기술 플랫폼들에 걸쳐 애플리케이션들의 휴대성의 용이함을 가능하게 한다(예를 들어, 앱 #A가 네트워크 A에 접속되는 EDN #1로부터 네트워크 B에 접속되는 EDN #2로 이동하는 경우, 이 솔루션으로, 미들웨어는 모든 재배치 양태들을 핸들링하고, 서비스 API에 대한 영향은 최소일 것이다).

본 명세서에서 이용될 때, 무선 통신 시스템은 하나 이상의 네트워크 유닛 및 원격 유닛 및 하나 이상의 플랫폼을 포함한다. 네트워크 유닛은 네트워크 요소, 라디오 액세스 네트워크, 코어 네트워크, 네트워크 제어 기능, 사용자 평면 기능, 네트워크 관리 기능, 모바일 에지 컴퓨팅 기능, 애플리케이션 인에이블먼트 기능, 또는 이들의 조합일 수 있다. 일부 실시예들에서, 네트워크 유닛들(또는 이들의 임의의 추상화)은 하나 이상의 클라우드 플랫폼에서 가상화될 수 있다. 클라우드 플랫폼은 에지 또는 지역 또는 코어 클라우드 플랫폼일 수 있다.

벤더들/멀티-벤더 시스템들에 걸친 API 구성들을 수반하는 예시적인 이용 사례로서, 5G 시스템("5GS")이 (상이한 클라우드 플랫폼들에서 가상화될 수 있는 복수의 제어 및 관리 평면들을 갖는) 멀티-벤더일 수 있고, API들이 상이한 5GS 종료 포인트들에 의해 제공될 것이라는 사실을 고려하면, API들을 표준 방식으로 제공함으로써 버티컬 고객에 대한 API 프로비저닝을 간소화하는 것이 핵심적으로 중요하다. 예를 들어, 버티컬 고객은 동일한 운영자 네트워크 내의 상이한 벤더의 시스템(예컨대, 벤더 A로부터의 E2E 관리 시스템, 벤더 B로부터의 라디오 액세스 네트워크("RAN") 관리 시스템, 벤더 C로부터의 코어 네트워크 CP, 벤더 D로부터의 코어 네트워크 UP)에 의해 제공된 복수의 네트워크 또는 서비스에 의해 제공되는 (예컨대, 제어 평면 및 관리 평면 서비스와 같은) 텔코 제공 서비스(telco-provided service)를 동시에 이용할 수 있다. 버티컬 고객이 API를 통해 이러한 멀티-벤더 시스템과 상호작용할 때, 이것은 버티컬 고객의 애플리케이션이 API 제공 및 네트워크 도메인 정보를 알고 있을 것을 필요로 할 수 있다. 이것은 복잡성을 추가할 수 있다. 고객과 텔코 제공자 사이의 상호작용을 간소화하기 위해, 예를 들어, 네트워크 내의 제어 포인트들로의 요건들의 매핑을 다루는 추상화 계층을 가능하게 함으로써, 이 복잡성을 고객에게 숨기는 것이 추천된다.

클라우드 플랫폼들에 걸친 애플리케이션 휴대성, 예컨대, 애플리케이션 서버 재배치 또는 애플리케이션 클라이언트 이동성을 수반하는 제2 예시적인 이용 사례에서, 버티컬 고객의 일부 애플리케이션들은 상이한 클라우드 플랫폼들에 배치 또는 이전될 수 있다(예컨대, 차량 대 사물("V2X") 시나리오의 경우, 자동차 회사 X의 일부 애플리케이션들은 CN-U A에 접속된 에지 클라우드에 재배치될 수 있는 반면 다른 애플리케이션들은 CN-U B에 접속된 지역 클라우드에 배치된다). 이것은, 관리 및 제어 서비스를 소비하기 위해, API가 상이한 방식으로 동일한 버티컬의 애플리케이션쪽으로 구성될 필요가 있음을 요구할 것이다. 이것은 (예를 들어, 레이턴시 요건들의 충족을 보장하기 위해) API 프로토콜들뿐만 아니라 API 정보(예를 들어, 종료 포인트들)를 포함할 수 있다. 이것은 특히 멀티-벤더 시나리오들이 수반될 때 복잡성을 제기할 수 있다.

개방 RAN("O-RAN")(O-RAN에 제한되지 않음)에 대한 예시적인 이용 사례는 클라우드 플랫폼으로부터 이 플랫폼에서 호스팅되는 애플리케이션들로의 서비스들의 노출을 지원하기 위해 휴대성 SDK를 도입하는 것을 포함한다. 이러한 애플리케이션들은, 예를 들어, 모바일 에지 컴퓨팅("MEC") 시스템들에서의 MEC 애플리케이션들, 또는 O-RAN 아키텍처에서의 xApp들일 수 있다. 이러한 소프트웨어 개발 키트("SDK")에 대한 필요성은 플랫폼 의존적인 파라미터들 및 프로그래밍 언어들에 의존하지 않으면서, 플랫폼들 사이의 애플리케이션들의 휴대성을 허용하기 위한 것이다. 이러한 SDK는 플랫폼 제공 API들 외에 간소화된 API를 포함하는 플랫폼 독립적인 SDK로서 보여질 수 있다(예를 들어, RAN 지능형 제어기("RIC") 플랫폼으로부터의 C개의 API가 간소화된 파이썬 API들로 변환된다).

서비스 API들로의 휴대성 SDK의 매핑의 구성 및 플랫폼 제공 API들에 기반한 간소화된 API들의 구성은, 고려될 필요가 있는 복수의 인자들이 존재하기 때문에, 이 이용 사례에서 해결되어야 하는 하나의 과제이다. 이러한 인자들은 1) 최종 애플리케이션이 갖는 허가들, 2) 보안 양태들(예를 들어, 제3자로부터 숨겨진 네트워크 토폴로지), 3) 노출될 필요가 있는 새로운/수정된 서비스들에 대한 동적 요건들, 및 4) API들의 상태/이용가능성일 수 있고, 매핑을 구성하거나 적응시키는 방법에 대한 일부 제어가 플랫폼에서 필요하다(매핑은 정적이 아닐 수 있다).

이 경우, 2개의 클라우드 플랫폼, 즉 클라우드 플랫폼 #1 및 클라우드 플랫폼 #2는 동일한 벤더에 속할 수 있고, 당연히 동일한 기술 도메인이다. 그러나, 클라우드 플랫폼들이 상이한 관리 엔티티들 하에 있는 경우, xAPP/MEC 앱은 클라우드 플랫폼 #2에 대한 새로운 인스턴스를 이용하기 위해 관리 서비스들에 액세스하는 위치를 업데이트할 필요가 있을 것이다. 이것은 xApp/MEC 앱이 관리 시스템들에 걸쳐 이동되는 컨텍스트 및 xApp/MEC 앱이 이제 관리 서비스들/API들의 새로운 인스턴스를 이용할 필요가 있다는 것을 아는 방식을 또한 요구하기 때문에 복잡하다.

네트워크 슬라이스 인에이블먼트를 수반하는 제3 예시적인 이용 사례에서, 네트워크 슬라이싱은 상이한 버티컬들에 대응하는 논리적 종단간 서브-네트워크들을 도입하는 하나의 핵심 5G 특징이다. 네트워크 슬라이싱은 공유 인프라스트럭처 외에 제3자 및 버티컬 맞춤화된 통신 서비스("CS")를 제공하는 네트워크 슬라이스 인스턴스("NSI")로 알려진 복수의 논리적 네트워크의 배치를 허용한다. 공용 운영자 또는 기업에 의해 운영될 수 있는 물리적 네트워크에 기반하여, 5G는 상이한 통신 목적들을 위해 복수의 슬라이스들을 실행하는 수단을 제공한다. 5G는 슬라이스들이 독립적으로 실행되게 하고, 원한다면, 서로 격리되게 한다. 이 시나리오에 기반한 사설 또는 공용 슬라이스로서 정의될 수 있는 네트워크 슬라이스 인스턴스는 RAN 부분 및 코어 네트워크("CN") 부분으로 구성될 수 있다. 네트워크 슬라이스 인스턴스의 하위 부분은 NSSI(network slice subnet instance)라고 불리며, 이는 그 후 추가의 NSSI들을 포함할 수 있다. 지금까지의 애플리케이션은 현재의 전기통신 네트워크에서 그들이 이용하는 관리되는 엔티티들을 변경하거나, 새롭게 프로비저닝하거나 대체할 가능성이 없다. 애플리케이션은 다음과 같은 관리되는 엔티티들 중 임의의 것을 이용할 수 있다: CS, NSI, NSSI, 네트워크 기능들 또는 가상화된 네트워크 기능("VNF")과 같은 전기통신 네트워크들 내의 다른 리소스들 또는 물리적 네트워크 기능("PNF")과 같은 물리적 엔티티들.

네트워크 슬라이스 인스턴스 구성 및 프로비저닝에서의 하나의 핵심 양태는 슬라이스 고객/버티컬/임차인에 대한 능력들의 노출이다:

(서비스 능력 노출 기능("SCEF")/네트워크 노출 기능("NEF")을 통한) 특정 슬라이스 또는 슬라이스 내의 세션에 대한 제어 평면에 관련된다. 이는, 예컨대, 네트워크 데이터 분석 기능("NWDAF")으로부터의 네트워크 슬라이스 분석, 또는 슬라이스 내의 사용자에 대한 애플리케이션에 의한 트래픽 조종/서비스 품질("QoS") 영향일 수 있다.

특정 슬라이스(들) 또는 슬라이스 서브넷들(예를 들어, RAN, CN)에 대한 관리 평면에 관련된다. 이는 예를 들어 시스템 레벨 시뮬레이터("SLS")에 기반한 고객에 의한 NSI/NSSI 수정 또는 모니터링에 관련될 수 있다.

슬라이스-특정 또는 슬라이스-인식일 수 있는 전술된 노출 능력들은 5GS와 네트워크 슬라이스 고객에 의해 배치된 애플리케이션들 사이의 API들의 이용을 요구한다. 제어 평면 상호작용들의 경우, 이것은 NEF/SCEF 노스바운드 API들을 통해 수행되는 반면; 관리 서비스 노출의 경우, 이것은 MEF/노출 통제 관리 기능("EGMF") API들을 통해 수행된다.

슬라이싱 이용 사례에 대해 특정 과제들이 존재할 수 있고, 슬라이스 관리가 제어 평면에 영향을 미치기 때문에 제어 및 관리 관련 서비스들은 강한 결합을 가질 수 있고, 그 반대도 마찬가지이며; 동시에, 슬라이스 고객은 제어 및 관리 평면 모두에 영향을 미치는 동적/맞춤형 요청들을 가질 수 있다. 고객은, 허가가 있는 경우, 제어 또는 관리 평면에 관련된 결정에 영향을 미치고자 할 수 있다. 슬라이싱의 경우에, 네트워크 적응을 요청하기로 결정하기 위한 입력은 관리 시스템에 대해 오는 이벤트에 의해 트리거링될 수 있다. 이것은 슬라이스 능력 노출과 관련된 API들을 구성할 때 고려될 필요가 있을 수 있다.

예 1: RAN NSSI 높은 부하/리소스 이용불가능성은 사용자 장비("UE")별 슬라이스 파라미터들에 영향을 미칠 수 있다. 슬라이스 고객은 관리 평면 이벤트에 기반하여 제어 평면 적응(예를 들어, 리소스 적응, 트래픽 조종, 앱 대 슬라이스 리매핑)을 요구할 수 있다.

예 2: 그룹 UE 이동성은 하나 이상의 셀 영역(동작 관리 및 유지보수("OAM")에 의해 구성되지만, UE 거동을 고려하지 않음)에 대한 슬라이스 라디오 리소스 관리("RRM") 정책들에 영향을 미칠 수 있다.

슬라이스 고객은 특정 모바일 네트워크 운영자("MNO")-프로비저닝된 네트워크 파라미터들(노출될 서비스와 관련됨)을 이해하기를 원하지 않을 수 있지만, 이해가능한 출력(예를 들어, MNO로부터의 경보, 더 많은 리소스들/더 많은 사용자 평면 기능들("UPF들")에 대한 지시)을 요구한다. 동시에, MNO는 슬라이스 고객에게 요구된 정보를 제공하면서 네트워크 토폴로지를 숨기고자 할 수 있다. 하나의 경우는 애플리케이션이 거동을 변경할 때, 예를 들어, 서비스에 대한 자동화 레벨의 변경, 군집에서의 차량간 거리의 변경, 속도의 변경일 때이다. 다른 경우는 이러한 요건들의 충족을 보장하기 위해 제어 또는 관리 평면 액션을 요청하는 것이다. 이것은 예상된 다운그레이드를 다루기 위해 다른 PLMN(public land mobile network) 또는 RAT(radio access technology)의 선택을 수반할 수 있다. 또한, 버티컬은 반드시 네트워크/QoS 다운그레이드일 필요는 없는 경보뿐만 아니라 버티컬이 가입한 이벤트(예를 들어, 위치 서비스가 이용된다면 드론의 위치가 벗어날 때의 경보, QoS/경험 품질("QoE") 업그레이드가 특정 영역에서 이용가능할 때의 경보)를 원할 수 있다.

이러한 이용 사례들에서의 상이한 슬라이스들은 MNO 및 애플리케이션 서비스 제공자("ASP") 협약(및 슬라이스 요건을 지원하는 네트워크 능력들)에 기반하여 모든 제공된 주파수들 또는 이들의 서브세트(예를 들어, FR1만 또는 FR2만)에서 이용가능할 수 있다. 예로서, 모바일 네트워크 운영자는 상이한 ASP들(예를 들어, 온라인 비디오 서비스들을 위한 슬라이스 #1, 게임을 위한 슬라이스 #2, eMBB(enhanced mobile broadband) 또는 IOT(internet of things) 서비스를 위한 슬라이스 #3)에 의해 이용될 수 있는 네트워크 슬라이스 세트(슬라이스 #1, 슬라이스 #2, 슬라이스 #3)를 프로비저닝하였다. 상이한 ASP들은 이들이 제공하는 상이한 서비스들에 대해 이러한 슬라이스들(또는 이들의 서브세트)을 이용할 수 있다. 또한, 애플리케이션이 액세스될 네트워크 슬라이스들을 변경할 때, 이것은 서비스에 액세스하는 UE들에 독립적이어야 하고, 자동으로 수행되어야 한다. 이러한 ASP 제공 변경들을 허용하기 위해, (세션 관련 적응들, 예를 들어, 데이터 네트워크 이름("DNN") 리매핑, 슬라이스 리매핑을 요청하기 위한) 제어 평면 및 관리 평면(RRM 정책들 또는 커버리지와 같은 NSI/NSSI 파라미터들의 적응)에 영향을 주기 위해 슬라이스 능력 노출이 요구된다. 이것은 제어 및 관리 평면 양자로부터 API들을 통해(그러나 조정되지 않은 방식으로) 수행될 것이다. 이 예에서, 버티컬 애플리케이션은 어느 엔티티가 어느 API를 제공하는지 그리고 API 소비에 대한 프로토콜 요건이 무엇인지를 알 필요가 있다.

모든 이러한 이용 사례들(예를 들어, 멀티-벤더 지원, 휴대성, 슬라이싱)에 대해, 1) 기본 텔코 인프라스트럭처에 독립적이고, 2) 텔코 인프라스트럭처의 복잡성을 숨기고, 3) 버티컬에 대한 노출의 레벨에 영향을 미치지 않고/제한하지 않으며, 4) 애플리케이션 휴대성 또는 텔코 제공 API 상태 변경들로 인해 발생할 수 있는 동적 변경들에 탄력적인 방식으로 API들을 통해 서비스들의 노출을 구성하는 방법인 공통 문제가 있다. 따라서, 해결해야 할 문제점은 전술한 문제를 다루기 위해 클라우드 플랫폼/텔코 제공 능력들(슬라이스 특정, 제어, 및 관리)을 (중앙집중형으로 배치되거나 상이한 클라우드들에 걸쳐 분산될 수 있는) 버티컬 고객의 애플리케이션들에 노출시키기 위한 API들을 구성하는 방법이다.

도 1은 본 개시내용의 실시예들에 따른, 플랫폼 독립적인 애플리케이션 프로그래밍 인터페이스들을 구성하기 위한 무선 통신 시스템(100)을 도시한다. 다양한 실시예들에서, 무선 통신 시스템(100)은 적어도 하나의 원격 유닛(105), 라디오 액세스 네트워크("RAN")(110), 및 모바일 코어 네트워크(120)를 포함한다. RAN(110) 및 모바일 코어 네트워크(120)는 모바일 통신 네트워크를 형성한다. RAN(110)은 원격 유닛(105)이 무선 통신 링크들(115)을 이용하여 통신하는 베이스 유닛(111)으로 구성될 수 있다. 특정 수의 원격 유닛들(105), 베이스 유닛들(111), 무선 통신 링크들(115), RAN들(110), 및 모바일 코어 네트워크들(120)이 도 1a 내지 도 1c에 도시되어 있지만, 본 기술분야의 통상의 기술자는 임의의 수의 원격 유닛들(105), 베이스 유닛들(111), 무선 통신 링크들(115), RAN들(110), 및 모바일 코어 네트워크들(120)이 무선 통신 시스템(100)에 포함될 수 있다는 것을 인식할 것이다.

일 구현에서, RAN(110)은 3GPP 사양들에서 지정된 5G 시스템에 따른다. 다른 구현에서, RAN(110)은 3GPP 사양들에서 지정된 LTE 시스템에 따른다. 그러나, 더 일반적으로, 무선 통신 시스템(100)은 다른 네트워크들 중에서도 일부 다른 개방 또는 독점 통신 네트워크, 예를 들어 WiMAX를 구현할 수 있다. 본 개시내용은 임의의 특정 무선 통신 시스템 아키텍처 또는 프로토콜의 구현으로 제한되도록 의도되지 않는다.

도 1에서, 무선 통신 시스템(100)은 EDN 서비스 영역(143)을 지원하는 적어도 하나의 에지 데이터 네트워크("EDN")(141)를 포함하는 에지 컴퓨팅 서비스 배치를 지원한다. EDN(141)은 애플리케이션의 인스턴스를 지원하는 적어도 하나의 에지 애플리케이션 서버("EAS")(177)를 포함한다. 원격 유닛(105)이 EDN 서비스 영역(143)에 위치할 때, 에지 애플리케이션 클라이언트(179)는 EAS(177)에 액세스할 수 있다. 그러나, 원격 유닛(105)이 임의의 EDN 서비스 영역 외부에 있을 때, EA 클라이언트(179)는 데이터 네트워크(150)(즉, 지역 데이터 네트워크)에 위치되는 애플리케이션 서버(171)를 이용하여 애플리케이션의 인스턴스에 액세스할 수 있다. EDN(141)은 또한 에지 인에이블러 서버("EES")(173), 미들웨어 애플리케이션 인에이블러 서버를 포함하는 반면, 원격 유닛(105)은 에지 인에이블러 클라이언트("EEC")(175)를 포함한다. 다른 실시예들에서, 무선 통신 시스템은 미래 공장("FF") 버티컬 및/또는 V2X 버티컬(도시되지 않음)을 지원할 수 있다.

일 실시예에서, 원격 유닛들(105)은, 데스크톱 컴퓨터들, 랩톱 컴퓨터들, PDA(personal digital assistant)들, 태블릿 컴퓨터들, 스마트폰들, 스마트 텔레비전들(예를 들어, 인터넷에 접속된 텔레비전들), 스마트 기기들(예를 들어, 인터넷에 접속된 기기들), 셋톱 박스들, 게임 콘솔들, (보안 카메라들을 포함한) 보안 시스템들, 차량 탑재 컴퓨터들, 네트워크 디바이스들(예를 들어, 라우터들, 스위치들, 모뎀들) 등의 컴퓨팅 디바이스들을 포함할 수 있다. 일부 실시예들에서, 원격 유닛들(105)은, 스마트 시계들, 피트니스 밴드들, 광학 헤드 장착형 디스플레이들 등의 웨어러블 디바이스들을 포함한다. 또한, 원격 유닛들(105)은, UE들, 가입자 유닛들, 모바일들, 이동국들, 사용자들, 단말기들, 모바일 단말기들, 고정 단말기들, 가입자국들, 사용자 단말기들, 무선 전송/수신 유닛("WTRU"), 디바이스, 또는 본 기술분야에서 사용되는 다른 용어로 지칭될 수 있다.

원격 유닛들(105)은 업링크("UL") 및 다운링크("DL") 통신 신호들을 통해 RAN(110) 내의 하나 이상의 베이스 유닛(111)과 직접 통신할 수 있다. 또한, UL 및 DL 통신 신호는 무선 통신 링크(115)를 통해 운반될 수 있다. 여기서, RAN(110)은 원격 유닛(105)에게 모바일 코어 네트워크(120)로의 액세스를 제공하는 중간 네트워크이다. 도시된 바와 같이, 원격 유닛(105)은 SEAL 클라이언트(107) 및/또는 모바일 애플리케이션 클라이언트(109)를 실행하기 위한 하드웨어 및 소프트웨어 리소스들을 포함할 수 있다.

일부 실시예들에서, 원격 유닛들(105)은 모바일 코어 네트워크(120)와의 네트워크 접속을 통해 통신 호스트(예를 들어, 에지 애플리케이션 서버(149) 및/또는 애플리케이션 서버(153))와 통신한다. 예를 들어, 원격 유닛(105) 내의 모바일 애플리케이션(예를 들어, 웹 브라우저, 미디어 클라이언트, 전화/VoIP 애플리케이션, 모바일 애플리케이션 클라이언트(109))은 RAN(110)을 통해 모바일 코어 네트워크(120)와의 PDU 세션(또는 다른 데이터 접속)을 확립하도록 원격 유닛(105)을 트리거링할 수 있다. 모바일 코어 네트워크(120)는 그 후 PDU 세션을 이용하여 원격 유닛(105)과 통신 호스트(즉, 애플리케이션 서버) 사이에서 트래픽을 중계한다. 원격 유닛(105)은 모바일 코어 네트워크(120)와 하나 이상의 PDU 세션(또는 다른 데이터 접속)을 확립할 수 있다는 점에 유의한다. 이와 같이, 원격 유닛(105)은 하나의 애플리케이션 서버와 통신하기 위한 적어도 하나의 PDU 세션 및 다른 애플리케이션 서버(도시되지 않음)와 통신하기 위한 적어도 하나의 추가적인 PDU 세션을 동시에 가질 수 있다.

베이스 유닛들(111)은 지리적 영역에 걸쳐 분산될 수 있다. 특정 실시예들에서, 베이스 유닛(111)은 또한, 액세스 단말기, 액세스 포인트, 베이스, 기지국, 노드-B, eNB, gNB, 홈 노드-B, 중계 노드, 또는 본 기술분야에서 사용되는 다른 임의의 용어로 지칭될 수 있다. 베이스 유닛들(111)은 일반적으로, 하나 이상의 대응하는 베이스 유닛(111)에 통신가능하게 결합된 하나 이상의 제어기를 포함할 수 있는 RAN(110) 등의 라디오 액세스 네트워크("RAN")의 일부이다. 라디오 액세스 네트워크의 이들 및 다른 요소들은 도시되지 않았지만, 본 기술분야의 통상의 기술자에게는 일반적으로 널리 공지되어 있다. 베이스 유닛들(111)은 RAN(110)을 통해 모바일 코어 네트워크(120)에 접속한다.

베이스 유닛들(111)은, 무선 통신 링크(115)를 통해, 서빙 영역, 예를 들어, 셀 또는 셀 섹터 내의 다수의 원격 유닛(105)을 서빙할 수 있다. 베이스 유닛들(111)은 통신 신호들을 통해 하나 이상의 원격 유닛(105)과 직접 통신할 수 있다. 일반적으로, 베이스 유닛들(111)은, 시간, 주파수, 및/또는 공간 도메인에서 원격 유닛들(105)을 서빙하기 위해 DL 통신 신호들을 전송한다. 또한, DL 통신 신호들은 무선 통신 링크들(115)을 통해 운반될 수 있다. 무선 통신 링크들(115)은 허가 또는 비허가 라디오 스펙트럼에서의 임의의 적절한 캐리어일 수 있다. 무선 통신 링크들(115)은 하나 이상의 원격 유닛(105) 및/또는 하나 이상의 베이스 유닛(111) 사이의 통신을 용이하게 한다.

일 실시예에서, 모바일 코어 네트워크(120)는 5G 코어("5GC") 또는 진화된 패킷 코어("EPC")이며, 이는 다른 데이터 네트워크들 중에서도 인터넷 및 사설 데이터 네트워크들과 같은 패킷 데이터 네트워크(150)에 결합될 수 있다. 원격 유닛(105)은 모바일 코어 네트워크(120)에 가입 또는 다른 계정을 가질 수 있다. 각각의 모바일 코어 네트워크(120)는 단일 공용 육상 모바일 네트워크("PLMN")에 속한다. 본 개시내용은 임의의 특정 무선 통신 시스템 아키텍처 또는 프로토콜의 구현으로 제한되도록 의도되지 않는다.

모바일 코어 네트워크(120)는 여러 네트워크 기능들("NF들")을 포함한다. 도시된 바와 같이, 모바일 코어 네트워크(120)는 복수의 사용자 평면 기능("UPF")(121)을 포함한다. 모바일 코어 네트워크(120)는 또한, RAN(110)을 서빙하는 액세스 및 이동성 관리 기능("AMF")(123), 세션 관리 기능("SMF")(125), 정책 제어 기능("PCF")(127), 네트워크 노출 기능("NEF")(128), 및 통합 데이터 관리 기능("UDM")(129)을 포함하지만 이것으로 제한되지 않는 복수의 제어 평면 기능을 포함한다. 특정 실시예들에서, 모바일 코어 네트워크(120)는 또한, 인증 서버 기능("AUSF"), (API들을 통해 서로 통신하고 발견하기 위해 다양한 NF들에 의해 이용되는) 네트워크 저장소 기능("NRF"), 또는 5GC에 대해 정의된 다른 NF들을 포함할 수 있다. 일부 실시예들에서, UDM(129)은 사용자 데이터 저장소("UDR")와 공동 배치된다.

다양한 실시예들에서, 모바일 코어 네트워크(120)는 네트워크 유닛에 의해 생성되는 서버 네트워크 서비스들(도시되지 않음)을 포함한다. 네트워크 유닛은 네트워크 기능에 의해 생성된 제어 평면 서비스, 관리 기능에 의해 생성된 네트워크 관리 서비스, 네트워크 기능에 의해 생성된 모바일 에지 컴퓨팅 서비스, 애플리케이션 인에이블러 기능에 의해 생성된 애플리케이션 인에이블먼트 서비스, O-RAN 유닛에 의해 생성된 RIC 서비스 등을 포함할 수 있다.

다양한 실시예들에서, 모바일 코어 네트워크(120)는 상이한 유형들의 모바일 데이터 접속들 및 상이한 유형들의 네트워크 슬라이스들을 지원하며, 각각의 모바일 데이터 접속은 특정 네트워크 슬라이스를 이용한다. 여기서, "네트워크 슬라이스"는 특정 트래픽 유형 또는 통신 서비스에 대해 최적화된 모바일 코어 네트워크(120)의 일부를 지칭한다. 네트워크 슬라이스 인스턴스는 S-NSSAI에 의해 식별될 수 있는 반면, 원격 유닛(105)이 이용하도록 허가되는 네트워크 슬라이스들의 세트는 NSSAI에 의해 식별된다. 특정 실시예들에서, 다양한 네트워크 슬라이스들은 SMF(125) 및 UPF(121)와 같은 네트워크 기능들의 별개의 인스턴스들을 포함할 수 있다. 일부 실시예들에서, 상이한 네트워크 슬라이스들은 AMF(123)와 같은 일부 공통 네트워크 기능들을 공유할 수 있다. 상이한 네트워크 슬라이스들은 예시의 용이함을 위해 도 1에 도시되지 않았지만, 그 지원이 가정된다.

무선 통신 시스템(100)은 OAM/관리 기능(130)을 포함한다. OAM/관리 기능(130)은 슬라이스 파라미터들(예를 들어, 슬라이스 능력들, 슬라이스 정책들, 슬라이스 이용가능성 정보, 버티컬 대 슬라이스 가입들 및 허가들, 슬라이스 핵심 성능 표시자들, 슬라이스 서비스 레벨 협약들("SLA") 등)을 인에이블러 서버들(예를 들어, EES(145))에 제공할 수 있다. 다양한 실시예들에서, OAM/관리 기능(130)은, 예컨대, 서비스 제공자로부터의 요청에 응답하여, 슬라이스 인스턴스화를 수행한다.

도시된 바와 같이, 데이터 네트워크(150)는 VAL 서버(151), 애플리케이션 서버(153) 및/또는 SEAL 서버(155)를 포함할 수 있다. 3GPP에서, 애플리케이션 지원 계층은, 버티컬 애플리케이션 인에이블러 계층이라고 알려진, 버티컬 애플리케이션에 대해 명시되었다. 버티컬 애플리케이션 인에이블러들의 예들은 V2X 인에이블러 서버, FF 인에이블러 서버, 및 UAS 인에이블 서버를 포함한다. 버티컬 애플리케이션 인에이블러 계층은, 노스바운드 API들을 버티컬들에 노출시키는 것은 물론 접속된 디바이스들에 대한 일부 서버-클라이언트 지원 기능들을 제공하기 위해, MNO 또는 제3자/버티컬 서비스 제공자의 도메인에 상주할 수 있는 분산형 또는 중앙집중형 미들웨어로서 작용할 수 있다.

서비스 인에이블러 아키텍처 계층("SEAL")은 모든 버티컬들에 공통인 인에이블러 계층을 제공한다. SEAL은 서버 기능들(예를 들어, 네트워크 리소스 관리, 위치 관리, 구성 관리, 그룹 관리, 아이덴티티 관리, 키 관리, 네트워크 슬라이스 인에이블먼트 등)뿐만 아니라 최종 디바이스들에서의 클라이언트 기능들을 포함한다. SEAL은 또한 5G 코어 네트워크와 상호작용할 때 AF 기능을 포함한다. VAL 서버(151)는 SEAL 서버 기능들에 의해 제공되는 서비스들을 소비하는 인에이블러 서버 또는 애플리케이션 특정 서버의 일 실시예이다. 일부 실시예들에서, SEAL 서버(155) 및/또는 인에이블러 서버는 데이터 네트워크(150) 또는 에지 데이터 네트워크(141)에 상주한다. 추가 실시예들에서, SEAL 서버(155) 및 인에이블러 서버는 공동 배치된다.

또한, 2개의 모델, 즉 온-네트워크 및 오프-네트워크 모델들이 있다. 온-네트워크 모델에서, SEAL 클라이언트(107)는 SEAL-UU 참조 포인트를 통해 SEAL 서버(155)와 통신하는 반면, 오프-네트워크의 경우 UE1의 아이덴티티 관리 클라이언트는 SEAL-PC5 참조 포인트를 통해 UE2의 SEAL 클라이언트(107)와 통신한다.

특정 수들 및 유형들의 네트워크 기능들이 도 1에 도시되지만, 본 기술분야의 통상의 기술자는 임의의 수 및 유형의 네트워크 기능들이 모바일 코어 네트워크(120)에 포함될 수 있음을 인식할 것이다. 더욱이, 모바일 코어 네트워크(120)가 EPC인 경우, 도시된 네트워크 기능들은 MME, S-GW, P-GW, HSS 등과 같은 적절한 EPC 엔티티들로 대체될 수 있다. 특정 실시예들에서, 모바일 코어 네트워크(120)는 AAA 서버를 포함할 수 있다.

도 1은 5G RAN 및 5G 코어 네트워크의 구성요소들을 도시하지만, 설명되는 솔루션들은 IEEE 802.11 변형들, GSM, GPRS, UMTS, LTE 변형들, CDMA 2000, 블루투스, 지그비, 시그폭스 등을 포함하는 다른 유형들의 통신 네트워크들 및 RAT들에 적용된다. 예를 들어, EPC를 수반하는 LTE 변형에서, AMF(123)는 MME에 매핑될 수 있고, SMF는 PGW의 제어 평면 부분 및/또는 MME에 매핑되고, UPF는 SGW 및 PGW의 사용자 평면 부분에 매핑되고, UDM/UDR은 HSS에 매핑되는 식이다.

이하의 설명들에서, eNB/gNB라는 용어는 기지국에 대해 사용되지만, 임의의 다른 라디오 액세스 노드, 예컨대, BS, eNB, gNB, AP, NR 등에 의해 대체가능하다. 또한, 동작들은 주로 5G NR의 맥락에서 설명된다. 그러나, 제안된 솔루션들/방법들은 버티컬 애플리케이션들 및/또는 에지 네트워크 배치들을 위한 미들웨어-지원 슬라이스 및/또는 DNN 리매핑을 지원하는 다른 모바일 통신 시스템들에도 동일하게 적용가능하다.

플랫폼 독립적인 애플리케이션 프로그래밍 인터페이스들을 구성하기 위한 (예를 들어, 제3자/서비스 제공자(SP) 도메인 또는 MNO 또는 클라우드 플랫폼 제공자에 상주할 수 있는 애플리케이션 인에이블러/미들웨어 기능에서의) 메커니즘이 본 명세서에서 설명된다. 새로운 플랫폼 독립적인 API는 버티컬 고객의 애플리케이션과 기본 전기통신("텔코") 인프라스트럭처(예를 들어, 제어 및 관리 도메인) 사이의 동적 상호작용을 간소화한다. 이는 벤더 및 기술 도메인들에 걸쳐 고객과 전기통신 인프라스트럭처 사이의 균일한 상호작용들을 허용하고, 멀티-벤더 네트워크들, 전기통신 네트워크들의 복수의 인스턴스들에 걸쳐 그리고 상이한 기술 플랫폼들에 걸쳐 애플리케이션들의 휴대성의 용이함을 가능하게 한다.

텔코 제공 API들 외에 플랫폼 독립적이거나 슬라이스 맞춤화될 수 있는 SDK들에 대한 API들의 결속-간소화는 추상화 계층으로부터 어떤 형태의 구성을 요구한다. 이러한 구성은 서비스/슬라이스 노출 레벨에 기반한 SDK들로의 서비스 API들의 매핑은 물론, 고객들의 애플리케이션들에 공개되는 간소화된/변환된 API들의 구성일 수 있다.

이러한 구성은, 예를 들어, SLA/SLS가 텔코 인프라스트럭처 제공자에 의해 제공될 때 초기에 제공될 수 있거나, 또는 이것은 동적으로 업데이트될 수 있다. 이러한 동적 업데이트들에 대한 하나의 이유는 API 상태/이용가능성에 관련된 이벤트들일 수 있다. 다른 이유는 특정 영역 또는 시간 또는 서비스 유형에 대한 서비스 노출 요건의 동적 적응일 수 있다. 또한, 구성의 이러한 적응은 상이한 플랫폼들로의 애플리케이션 클라이언트 또는 애플리케이션 서버 재배치의 결과일 수 있다(따라서, 텔코/클라우드 제공자에 의해 제공되는 API들은 변경될 필요가 있을 것이다).

본 명세서의 주제는, 일 실시예에서, (복수의 도메인들 및 벤더들에 의해 제공될 수 있는) 애플리케이션-친화적 텔코 서비스 노출을 가능하게 하기 위해, 슬라이스/버티컬 맞춤화된 API들로의 서비스 API들의 매핑을 구성하기 위한 추상화 계층을 제공함으로써 이 문제를 해결한다. 특정 구현들에서, 본 개시내용은 제공되는 노출된 서비스들로의 "슬라이스 API" 매핑을 결정하도록 구성되는 신뢰 애플리케이션 또는 네트워크 엔티티에서의 방법을 제안한다. 슬라이스 API들은, 본 명세서에서 사용되는 바와 같이, 제어 또는 관리 또는 제3자 제공 API들일 수 있고 특정 슬라이스 인스턴스들에 매핑될 수 있는 서비스 API들의 맞춤화된 세트들로서 정의된다. 슬라이스 API들은 슬라이스 고객에 의해 필요에 따라 제어 및 관리 서비스들을 노출시키는데 이용될 상이한 유형의 API들을 포함하는 번들링된 또는 결합된 API일 수 있다.

추가 구현들에서, 제안된 솔루션은 기본 프로토콜 지식에 의존하지 않고 클라우드 플랫폼들에 걸친 애플리케이션 휴대성을 허용하기 위해, 서비스 노출 요건들에 기반하여 플랫폼 의존적인 API들 간의 플랫폼 독립적인 간소화된 API들로의 매핑을 결정한다.

도 2는 본 개시내용의 실시예들에 따른, 플랫폼 독립적인 애플리케이션 프로그래밍 인터페이스들의 구성을 관리하기 위한 네트워크 아키텍처(200) 및 시그널링 흐름을 도시한다. 일 실시예에서, 단계 1에서, 미들웨어/인에이블러 서버(202)(예를 들어, 네트워크 슬라이스 인에이블러, 미들웨어, 애플리케이션 기능, 네트워크 기능, 관리 기능 등)는, 에지/지역/코어 네트워크/플랫폼(201c)에서, 서비스 노출 레벨, 서비스 액세스가능성 표시, 서비스 이용가능성 표시, 애플리케이션(204a-b)의 허가에 기반한 리스트 등을 포함할 수 있는 서비스 파라미터를 M&O 도메인일 수 있는 텔코 서비스 제공자(206)로부터 수신할 뿐만 아니라, 애플리케이션/서비스 유형에 대한 SLA/SLS를 수신한다. 특정 실시예들에서, 이것은 네트워크 슬라이스와 관련될 수 있다. 이 경우에, 텔코 서비스 제공자(206)는 슬라이스 제공자이고, 이 단계는 버티컬 애플리케이션 가입들에 기반한 애플리케이션 대 슬라이스 매핑, 슬라이스 제공자로부터의 슬라이스 대 서비스 노출 매핑 등을 포함한다. 슬라이스 API들을 구성하기 위한 입력은 관리 시스템에 의해 제공되는 SLS 또는 GSMA에 의해 제공되는 GST/NEST 및/또는 애플리케이션/NSE/네트워크에 의해 제공되는 애플리케이션 대 슬라이스 매핑이다.

일 실시예에서, 단계 2에서, 미들웨어/인에이블러 서버(202)는 서비스 노출 요건에 기반하여 SDK/API로의 서비스 API들의 매핑을 결정한다. 결과적인 SDK/API는 슬라이스 또는 버티컬 맞춤화된 SDK/API일 수 있다. 이것은 또한, 플랫폼 의존적인 API(208)의 구성을 포함할 수 있고, API 이름, URI, API 버전, 프로토콜 정보, API마다의 종료 포인트, 포함된 API 유형, 통신 방법(예를 들어, 요청-응답 또는 가입-통보), 및/또는 시간 유효성 등을 포함할 수 있다.

일 실시예에서, 이것은 서비스 노출 레벨(예를 들어, 서비스 #x에 대한 CP 기능 #a 및 액세스 허가들)과 슬라이스 노출 파라미터들(예를 들어, 특정 액세스 정책들을 갖는 슬라이스 #1에 대해 NEF #1에 의해, 그리고 다른 액세스 정책들을 갖는 슬라이스 #2에 대해 NEF #2에 의해 제공되는 CP 기능 #a)의 매칭 및 서비스 API 생성자들로부터 서비스 API들에 액세스하기 위한 API/프로토콜/전송 정보(뿐만 아니라 SDK 툴들)의 인클로징에 기반하여 결정될 수 있다.

특정 실시예들에서, 매핑의 결정은 플랫폼 의존적인 API들의 이용가능성에 대한 지식을 요구한다. 플랫폼 의존적인 API들의 이용가능성은 API 생성자들로부터 주기적인 하트비트/킵-얼라이브 메시지들(heartbeat/keep-alive messages)을 수신하는 것을 통해 또는 이용가능성을 체크하기 위해 API 등록소(예를 들어, CCF, API 인에이블먼트)와 상호작용함으로써 유지될 수 있다.

슬라이스/버티컬 맞춤화된 API와, 함께 번들링되는 플랫폼 의존적인 API들 사이의 매핑에 대한 예시적인 결정이 이하에 나타내어져 있다. 여기서 또한 구현 상세들이 결정될 수 있다:

<표 1>

일 실시예에서, 단계 3에서, 미들웨어/인에이블러 서버(202)는 관여된 도메인 기능들, 예를 들어, EGMF를 통해 미들웨어(202)와 상호작용하는 관리 도메인들(212a-b), NEF, MEC, 다른 서버들, 예를 들어, SEAL을 통해 미들웨어(202)와 상호작용하는 하나 이상의 네트워크의 제어 평면 도메인들(214a-b) 등에 가입하거나 등록하고, 이는 서비스/슬라이스 노출 요건들에 기반하여 플랫폼 의존적인 API들을 생성한다. 이 단계는 미들웨어(202)가 상이한 클라우드 플랫폼들(201a-b)(예를 들어, 지역, 에지 클라우드)에 애플리케이션들을 배치한 버티컬/슬라이스 고객일 수 있는 애플리케이션(204a-b)을 대신하여 이러한 API들을 호출할 수 있게 할 것이다.

일 실시예에서, 단계 4에서, 미들웨어/인에이블러 서버(202)는 플랫폼 독립적인 SDK API들(210) 및 (단계 2의) 플랫폼 의존적인 SDK/API들(208)로의 그 매핑을 결정한다. 이 단계에서, 기본 텔코 프로토콜 및 전송 양태들은 최종 애플리케이션들(204a-b)에 노출되도록 플랫폼 독립적인 API(210)로부터 분리될 것이고, 따라서 상이한 플랫폼들에 걸쳐 서비스들의 균일한 노출을 허용한다. 또한, 미들웨어(202)는 플랫폼 독립적인 API들(210), 슬라이스/버티컬 맞춤화된 API들과의 그 매핑 및 구성, 및 플랫폼 의존적인 API들(208)(예를 들어, 관리, 제어, 애플리케이션 제공)로의 매핑에 대한 저장소/등록소로서 작용할 수 있다. 예가 아래에 나타내질 수 있다:

<표 2>

일 실시예에서, 단계 5에서, 미들웨어/인에이블러 서버(202)는 버티컬/최종 애플리케이션들(204a-b)에 노출될 플랫폼 독립적인 API들(210)을 생성하고 공개한다. 이것은 또한, 프로그래밍 툴들, 라이브러리들 등을 포함할 수 있다.

일 실시예에서, 단계 6에서, 트리거 이벤트들(예를 들어, UE 이동성, 상이한 플랫폼으로의 애플리케이션 서버 재배치, 텔코 제공 API들의 이용불가능성, API 과부하 표시 등)에 기반하여, 미들웨어(202)는 동적으로 변하는 환경들에서 플랫폼 독립적인 SDK API들(210)의 연속성/이용가능성을 보장하기 위해, (단계 2의) 플랫폼 의존적인 SDK/API들(208) 및 (단계 4에서 결정된) 플랫폼 독립적인 SDK API들(210)로의 그 매핑을 모니터링하고 적응시킬 것이다.

단계 6에서, 트리거 이벤트의 하나의 추가 구현은, 예를 들어, 플랫폼에서의 API 부하 제어/모니터링 기능을 통해, 또는 HTTP/REST에서의 Retry-After 동작을 통해 체크될 수 있는, 플랫폼 의존적인 API(208)의 높은 부하일 수 있다. 이러한 트리거 이벤트는, 플랫폼 독립적인 API들(210)이 (예를 들어, 가능한 과부하/거부에 의해) 영향을 받지 않는 것을 보장하기 위해, 미들웨어(202)가 플랫폼 의존적인 API들(208)에서 자체 API 스로틀링/레이트 제한을 실행하게 할 것이다.

차량 버티컬 산업의 예는 예시일 수 있다. 자동차 회사 X는 5GS로부터의 특정 서비스들을 필요로 하고 전체 PLMN에서 V2X 애플리케이션들(예를 들어, 고급 주행, 군집주행 등)의 세트에 대해 이러한 서비스들을 소비하도록 MNO x와 협약한다. 텔코 서비스들은 관리 서비스들, 제어 서비스들, SEAL 서비스들, MEC 서비스들 등을 포함할 수 있다. 이러한 서비스들을 자동차 회사 X에 노출시키고 그 요건들을 충족시키기 위해, MNO/SDK 제공자는 SDK/API 번들, 예를 들어, 요구되는 모든 정보를 갖는 플랫폼 의존적인 SDK(208)를 형성한다. 형성된 SDK/API는 클라우드 플랫폼에서 형성될 수 있고, 이러한 서비스들에 도달하기 위한 모든 프로토콜 및 통신 정보를 포함하지만, 이러한 모든 정보를 자동차 회사 X에 전송하는 것은 최적이 아닐 수 있다. 또한, 자동차 회사 X는 상이한 텔코 인프라스트럭처(및 소프트웨어)가 이러한 서비스들을 제공하는데 이용되는 상이한 지역들에서 서비스들을 실행할 수 있다.

따라서, (MNO 또는 SDK 제공자 또는 클라우드 제공자 도메인에서의) 미들웨어(202)는 기본 프로토콜들 및 인프라스트럭처에 대한 지식을 요구하지 않고 자동차 회사 X(예를 들어, 예측 QoS API)에 공개하기 위해 추가의 플랫폼 독립적인 SDK(210)를 형성할 필요가 있다. 플랫폼 의존적인 SDK/API(208)가, 예를 들어, API들의 이용불가능성, (상이한 MEC 플랫폼들에 걸친) UE들의 이동성, 애플리케이션 재배치들 등으로 인해 변경될 필요가 있을 때, 플랫폼 독립적인 SDK(210)는 온전하게 유지될 필요가 있다(예를 들어, NWDAF x 또는 NEF y가 서비스들을 제공하는지에 관계없이, 예측 QoS API가 제공될 필요가 있다). 따라서, 이 솔루션은, 최종 애플리케이션(204a-b)에서의 최소한의 인식으로 휴대성을 허용하도록, 서비스 API를 버티컬의 요구에 기반하여 슬라이스/버티컬 맞춤화된 API에 매핑하는 것을 구성할 뿐만 아니라, 이들 API의 간소화를 수행한다.

플랫폼들에 걸친 UE 이동성에 대한 예로서, MEC 제공 API들(예를 들어, 라디오 네트워크 정보 서비스("RNIS"))은 API 생성자 및 가능하게는 다른 양태들(예를 들어, API 프로토콜, 통신 등)을 변경할 것이다. 또한, 상이한 MEC 서비스들이 상이한 MEC 플랫폼들에서 이용될 수 있다. 그 경우, 플랫폼 독립적인 SDK(210)는 동일하게 유지되지만, 플랫폼 의존적인 API(208)는 변경될 것이다. 특정 실시예들에서, 결정된 플랫폼 독립적인 API(210) 및 플랫폼 의존적인 API(208)로의 매핑을 저장하기 위해, UE, 네트워크 디바이스 등에서의 저장소, 예를 들어, 데이터베이스, 데이터 저장소 등이 이용될 수 있다.

도 3은 네트워크 슬라이스 API 구성에 관한 제안된 솔루션의 제1 실시예에 대한 메시지 시퀀스 차트(300)를 도시한다. 도시된 실시예에서, 미들웨어(202)는 SA6 정의된 인에이블러 서버(NSE 또는 임의의 다른 버티컬 인에이블러 서버)이고, 슬라이스 정보는 네트워크 슬라이스 제공자에 의해 슬라이스 고객에게 이미 광고되었다고 가정된다.

단계 0(블록(302) 참조)에서, 관련 도메인들, 예를 들어, 관리 도메인(212) 및 5GC-CP(NEF) 제어 평면 도메인(214)은 슬라이스 고객 요건들에 기반하여 서비스 파라미터, 예를 들어, NSI에 대한 서비스 노출 레벨을 결정한다.

단계 1(메시징(304) 참조)에서, 일 실시예에서, 네트워크 슬라이스 제공자("NSP")의 관련 도메인들(212, 214)은 가입된 NSI(들)에 대한 버티컬 고객에 대응하는 슬라이스 등록/정보를 미들웨어(202)에 전송한다. 이것은 OAM/MD(슬라이스 특정 파라미터들과 관련되는 경우)로부터 또는 5GC(UDM)(사용자/디바이스 관련 슬라이스 가입 정보인 경우)로부터 올 수 있다. 선택적으로, 이 단계는 또한 슬라이스/서비스 API 구성 및 노출을 핸들링하라는 미들웨어에 대한 지시/요청을 포함할 수 있다.

단계 2a(메시징(306) 참조)에서, 일 실시예에서, 미들웨어는 슬라이스 관리 서비스들과 관련된 능력들(예를 들어, NSSI/NSI 모니터링, 수정 등) 및 이용가능한 API 상태를 얻기 위한 요청을 관여된 관리 도메인(들)(212)에 전송한다. 예를 들어, 미들웨어(202)는 어느 표준의 어느 버전이 지원되는지 그리고 그 표준의 어느 부분들이 판독가능하거나 실행가능한지를 요청할 수 있다. 관여된 관리 도메인들(212)은 (예를 들어, 서비스 능력 노출에 기반하여) 단계 1로부터 미들웨어(202)에 의해 알려진다. 이 메시지(306)는 다음의 파라미터들 중 적어도 하나를 포함한다:

미들웨어 ID

API 이름/URI의 요청

API 버전의 요청

데이터 포맷(예를 들어, 직렬화 프로토콜)의 요청

슬라이스 #X 또는 서비스 #Y와 관련된 API 지원 특징들의 요청

지원되는 특징들에 대한 노출 레벨 요건

API 상태 질의

API 종료 포인트들

요청의 시간 유효성

일부 실시예들에서, 미들웨어(202)는 이 정보를 이미 알고 있을 수 있다.

단계 2b(메시징(308) 참조)에서, 일 실시예에서, 관리 도메인(212)은 API 상태 및 슬라이스 관련 관리 능력들을 제공한다. 이 메시지는 다음의 파라미터들 중 적어도 하나를 포함한다:

MD ID, MnS ID

API 이름들, 유형들, 데이터 포맷들의 리스트

슬라이스/서비스와 관련된 API 지원 특징들

지원되는 특징들의 노출 레벨

API 상태 보고

단계 3a(메시징(310) 참조)에서, 일 실시예에서, 미들웨어(202)는 노출될 수 있는 슬라이스 관련 제어 서비스들에 관련된 능력들(예를 들어, 슬라이스 가입들, 네트워크 슬라이스 분석, QoS/네트워크 모니터링 이벤트들 등) 및 이용가능한 API 상태를 얻기 위한 요청을 관여된 CN 제어 평면(214)(예를 들어, NEF/SCEF)에 전송한다. 관여된 NEF들은 (예를 들어, 서비스 능력 노출에 기반하여) 단계 1로부터 미들웨어(202)에 의해 알려진다. 이 메시지는 다음의 파라미터들 중 적어도 하나를 포함한다:

미들웨어 ID

노스바운드 API 이름/URI의 요청

노스바운드 API 버전의 요청

데이터 포맷(예를 들어, 직렬화 프로토콜)의 요청

슬라이스 #X 또는 서비스 #Y와 관련된 노스바운드 API 지원 특징들의 요청

지원되는 특징들에 대한 노출 레벨 요건

API 상태 질의

API 종료 포인트들

시간 유효성

단계 3b(메시징(312) 참조)에서, 일 실시예에서, 제어 평면(214)은 API 상태 및 슬라이스 관련 제어 노출 능력들을 제공한다. 이 메시지는 다음의 파라미터들 중 적어도 하나를 포함한다:

NEF ID

API 이름들, 유형들, 데이터 포맷들의 리스트

슬라이스/서비스와 관련된 API 지원 특징들

지원되는 특징들의 노출 레벨

API 상태 보고

단계 4(블록(314) 참조)에서, 일 실시예에서, 미들웨어(202)는 NSI에 대한 서비스 능력 노출 요건들, 외부 엔티티의 인증, 및 서비스 API들의 이용가능성에 기반하여 NSI를 서비스 API들의 리스트에 매핑한다(특정 구현에서 이것은 매핑 표일 수 있다).

단계 5a(메시징(316) 참조)에서, 일 실시예에서, 미들웨어(202)는 애플리케이션에 의해 요구되는 바와 같이 관리 서비스들("MnS")에 가입하기 위해 관리 도메인(들)(212)의 영향받은 관리 서비스들에 가입 요청을 전송한다. 가입 요청은 또한 관리 서비스들에 대한 노출 레벨(예를 들어, 허가들, 보고의 세분성 등)을 포함할 수 있다. 단계 5b(메시징(318) 참조)에서, 관리 도메인(212)의 MnS는 가입의 결과 또는 확인응답을 제공하기 위해 확인응답("ACK")을 전송한다.

단계 6a(메시징(320) 참조)에서, 일 실시예에서, 미들웨어(202)는 슬라이스와 관련된 제어/노스바운드 API들을 소비하기 위해 가입하기 위한 가입 요청을 관여된 제어 평면 도메인(들)(214)의 NEF에 전송한다. 가입 요청은 또한 제어 서비스들에 대한 노출 레벨(예를 들어, 허가들, 보고의 세분성 등)을 포함할 수 있다. 단계 6b(메시징(322) 참조)에서, 관여된 제어 평면(214)의 NEF는 가입의 확인응답을 제공하기 위해 ACK를 전송한다.

단계 7(블록(324) 참조)에서, 일 실시예에서, 미들웨어(202)는 서비스들에 가입할 때, 제공된 서비스들의 하나 이상의 슬라이스에 대한 하나 이상의 슬라이스 API로의 매핑을 구성한다. 서비스들에 대한 슬라이스 API 매핑은 슬라이스 API 이름/식별, 인클로징된 서비스 API 이름들, URI들, API 버전들, 프로토콜 정보, API마다의 종료 포인트들, 포함된 API 유형들, 통신 방법들(예를 들어, 요청-응답 또는 가입-통지), 시간 유효성 등을 포함한다. 슬라이스 API들은 부가 가치 미들웨어 제공 서비스들과 관련된 서비스 API들도 포함할 수 있다. 이 단계에서, 슬라이스 API 정보(및 인클로징된 API들)는 미들웨어(202)에 저장된다.

단계 8(블록(326) 참조)에서, 일 실시예에서, 미들웨어(202)는 슬라이스 API를 API 호출자(301)에 공개할 수 있다(이것은 플랫폼 의존적인 또는 플랫폼 독립적인 API들로 구성될 수 있다).

단계 9(메시징(330) 참조)에서, 트리거 이벤트(블록(328) 참조)에 응답하여, 트리거 이벤트는 API 생성자들(예를 들어, 제어 평면(214), 관리 평면(212), SEAL 등) 또는 애플리케이션 측(예를 들어, 상이한 EDN/DN으로의 애플리케이션 서버 재배치, 상이한 EDN에 대한 UE 이동성, 애플리케이션 거동 변경 등) 또는 API 인에이블먼트 서비스들에 의해 캡처되는 임의의 다른 API 관련 이벤트(예를 들어, 장애, 이용불가능성) 또는 미들웨어(202)에 의해 캡처된다.

미들웨어(202)는, 일 실시예에서, 트리거 이벤트(328)를 처리하고, 서비스 API들의 슬라이스 API들로의 매핑을 체크하고 업데이트한다. 그 목적은 슬라이스 API들을 변경되지 않게 유지하는 것이므로, 버티컬은 어떠한 변경도 알지 못한다. 이를 달성하기 위해, 서비스 API들이 업데이트될 필요가 있을 수 있다. 이 단계에서, 미들웨어(202)는 일부 서비스들의 소비의 이용불가능성을 다루기 위해 부가 가치 서비스들을 제공함으로써 추가로 지원할 수 있다.

단계 10(메시징(332) 참조)에서, 일 실시예에서, 슬라이스 API 정보가 변경되는 경우, 미들웨어는 슬라이스 API를 API 호출자(301)에게 재공개할 수 있다(이것은 플랫폼 의존적인 API들로 구성될 수 있다).

다른 텔코 제공 서비스들(예를 들어, 클라우드/MEC API들, SEAL API들 등)에 대해 (제어 및 관리를 위한 단계들 2, 3, 5, 6에서와 같은) 추가 상호작용들이 추가될 수 있다는 점에 유의한다.

도 4는 휴대성 SDK/API 매핑 구성(예를 들어, 플랫폼 독립적인 API/SDK)에 관한 제안된 솔루션의 제2 실시예에 대한 메시지 시퀀스 차트(400)를 도시한다. 도시된 실시예는, 이용될 그리고 휴대성(플랫폼 독립적인) SDK/API로 변환될 서비스 API들의 매핑뿐만 아니라 매핑에 기반한 간소화된 API들의 구성을 포함하는, 휴대성(플랫폼 독립적인) SDK/API 구성에 대한 솔루션을 제공한다.

단계 1a(메시징(410) 참조)에서, 일 실시예에서, 미들웨어 엔티티(202)는 xApp에 대해 서비스 관리 편성자("SMO")(402)로부터 노출 레벨을 요청한다. 상이한 노출 레벨들은 xApp의 유형(예를 들어, TS, QoE, RRM, SON 등) 및 상이한 유형들의 xApp들에 대한 허가 정책들에 기반하여 제공될 수 있다(예를 들어, xApp는 RIC 소유, 벤더 소유, ASP 소유 등일 수 있다).

단계 1b(메시징(412) 참조)에서, 일 실시예에서, SMO(402)(또는 M&O)는 사이드카, 브로커, 프록시, 인에이블먼트 서비스 등일 수 있는 미들웨어 엔티티(202)에, 서비스마다, 슬라이스마다, 애플리케이션 유형마다 등의 노출 레벨을 나타내는 메시지를 전송한다. 이것은 미들웨어 엔티티(202)가 휴대성(플랫폼 독립적인) SDK/API를 구성할 수 있게 하기 위한 요청/가입 또는 업데이트된 노출 레벨에 관한 미들웨어 엔티티(202)로의 보고의 형태일 수 있다.

단계 2(메시징(414) 참조)에서, 일 실시예에서, 미들웨어 엔티티(202)는 서비스 노출 레벨에 기반하여 API들의 이용가능성에 대해 API 인에이블먼트 서비스들(404)을 체크한다. 이 체크는 어느 API들이 이용가능하고 다른 API 정보(예를 들어, URI 이름, API 유형, API 버전, 통신 방법, 프로토콜 지원 등)를 요청하는지를 발견하기 위해 API 인에이블먼트 서비스들(404)에 대한 질의를 통해 발생할 수 있다. 여기서, 미들웨어 엔티티(202)는 API 인에이블먼트 서비스들(404)과 상호작용할 수 있다고 가정된다. 미들웨어 엔티티(202)가 플랫폼의 일부가 아닌 경우, 특정 실시예들에서, 미들웨어 엔티티(202)는 API 인에이블먼트 서비스들(404)과 상호작용하기 위해 인에이블먼트 API를 이미 발견했을 필요가 있을 수 있다(예를 들어, 미들웨어 엔티티(202)는 인에이블먼트 API에 대한 URI를 알고 있을 수 있다).

단계 3(메시징(416) 참조)에서, 일 실시예에서, 미들웨어 엔티티(202)는 단계 2에서 요청된 정보를 갖는 API 발견 응답을 수신한다. 이 응답은 API 이름, API 유형, API 버전, API 프로토콜들, 허가들 및 선택적으로 API 상태에 대한 정보 등 중 하나 이상을 포함하는 보고를 포함할 수 있다.

단계 4(블록 418 참조)에서, 일 실시예에서, 미들웨어 엔티티(202)는 단계 1에서 제공되는 바와 같은 노출 레벨, 및 서비스 유형, 애플리케이션 유형, 슬라이스 등에 기반하여 API들을 플랫폼 의존적인 API/SDK에 매핑한다. 이러한 매핑은 다음과 같은 매핑 표의 형태일 수 있지만, 이에 제한되지 않는다:

<표 3>

이 실시예에서, SDK 제공자, MNO, 전기통신 인프라스트럭처 벤더, 애플리케이션 서비스 제공자, 버티컬 서비스 제공자, 클라우드 제공자, 미들웨어 플랫폼 제공자 등은 플랫폼 의존적인 SDK/API 정보를 제공할 수 있다는 점에 유의한다. 매핑과는 별도로 다른 표현들이 가능할 수 있다는 점에 또한 유의한다.

단계 5a(메시징(420) 참조)에서, 일 실시예에서, 미들웨어 엔티티(202)는 슬라이스와 관련된 MnS 서비스 API들을 소비하기 위해 가입하기 위한 가입 요청을 관리 도메인(들)(408)의 영향받은 관리 서비스들에 전송한다. 가입 요청은 또한 관리 서비스들에 대한 노출 레벨(예를 들어, 허가들, 보고의 세분성 등)을 포함할 수 있다. 이 가입은 또한 API 인에이블먼트 서비스/인에이블먼트 API(404)를 통해 행해질 수 있다. 단계 5b(메시징(422) 참조)에서, 일 실시예에서, 관리 도메인(또는 API 인에이블먼트 서비스(404))의 MnS는 가입의 확인응답을 제공하기 위해 ACK 메시지를 전송한다.

단계 6a(메시징(424) 참조)에서, 일 실시예에서, 미들웨어 엔티티(202)는 슬라이스와 관련된 제어/E2 관련 API들을 소비하기 위해 가입하기 위한 가입 요청을 RIC(406)(또는 API 인에이블먼트 서비스들(404))의 가입 관리 기능에 전송한다. 가입 요청은 또한 제어 서비스들에 대한 노출 레벨(예를 들어, 허가들, 보고의 세분성 등)을 포함할 수 있다. 단계 6b(메시징(426) 참조)에서, 일 실시예에서, RIC(406), 예를 들어, 가입 관리 기능 또는 다른 RIC 기능은 가입의 확인응답을 제공하기 위해 ACK를 전송한다.

단계 7(블록(428) 참조)에서, 일 실시예에서, 미들웨어 엔티티(202)는 서비스들에 가입할 때 제공된 서비스들의 하나 이상의 SDK/API로의 매핑을 결정한다. 플랫폼 의존적인 SDK/API들은 부가 가치 미들웨어 제공 서비스들과 관련된 서비스 API들도 포함할 수 있다.

단계 8(블록(430) 참조)에서, 일 실시예에서, 미들웨어 엔티티(202)는 (단계 4에서와 같은) 플랫폼 의존적인 SDK들/API들, 및 다음의 기준들에 기반하여 플랫폼 독립적인 SDK/API를 구성한다:

API를 간소화하기 위한 전체 복잡성/레이턴시에 대한 영향;

프로토콜 레벨 영향들;

휴대성에 대한 애플리케이션 요건들;

노출 능력들에 대한 슬라이스 관련 요건들;

xApp의 유형에 관한 보안 양태들(예를 들어, 신뢰 또는 비신뢰)이다. 네트워크 토폴로지는 숨겨질 수 있음;

최종 애플리케이션의 능력들;

서비스들 간의 의존성들(이것은 새로운 API에서 서비스들을 결합하는 것을 요구할 수 있다. 예는 MnS, 및 RAN 슬라이스 보장과 관련된 제어 서비스일 수 있다. 그 경우에, xApp는 양쪽 서비스들을 결합하는 간소화된 API를 소비할 수 있음);

SLA/SLS;

(UE 또는 UE들의 그룹 또는 토폴로지/지리적/서비스 영역마다의) 애플리케이션 세션들에 대한 QoS 또는 QoE 요건들

미들웨어 엔티티(202)에서의 이러한 처리의 출력은 모든 필요한 정보 및 플랫폼 의존적인 API들로의 매핑을 갖는 플랫폼 독립적인 SDK/API일 것이다. 이것은 표의 형태일 수 있다:

<표 4>

단계 9(메시징(432) 참조)에서, 일 실시예에서, 미들웨어 엔티티(202)는 최종 애플리케이션들에 의한 이용을 위해 플랫폼 독립적인 API를 공개한다.

단계 10(메시징(410) 참조)에서, 일 실시예에서, 트리거 이벤트(블록(434) 참조)에 응답하여, 트리거 이벤트는 API 생성자들(예를 들어, 제어 평면, 관리 평면, SEAL 등) 또는 애플리케이션 측(상이한 EDN/DN으로의 애플리케이션 서버 재배치, 상이한 EDN에 대한 UE 이동성, 애플리케이션 거동 변경 등) 또는 API 인에이블먼트 서비스들(404)에 의해 캡처되는 임의의 다른 API 관련 이벤트(예를 들어, 장애, 이용불가능성 등)에 의해 캡처된다.

미들웨어 엔티티(202)는 트리거 이벤트를 처리하고, 플랫폼 의존적인 SDK/API로 구성되는 서비스 API들의 휴대성(플랫폼 독립적인) SDK/API들로의 매핑을 체크하고 업데이트한다. 그 목적은 휴대성(플랫폼 독립적인) API를 변경되지 않은 채로 유지하는 것이며, 따라서 버티컬은 어떠한 변경도 알지 못한다. 이를 달성하기 위해, 서비스 API들이 업데이트될 필요가 있을 수 있다. 이 단계에서, 미들웨어 엔티티(202)는 일부 서비스들의 소비의 이용불가능성을 다루기 위해 부가 가치 서비스들을 제공함으로써 추가로 지원할 수 있다.

도 5는 O-RAN에 대한 관리 또는 제어 평면 API들의 플랫폼 의존적인 구현들로의 새로운 유형의 애플리케이션 프로그래밍 인터페이스("API")(예를 들어, 후술하는 플랫폼 독립적인 API, 네트워크 슬라이스 API, 및/또는 휴대성 API)의 매핑의 구성 및 프로비저닝에 관한 제안된 솔루션의 제3 실시예에 대한 메시지 시퀀스 차트(500)를 도시한다.

단계 0(블록(508) 참조)에서, SMO(402)는 슬라이스 고객 요건들에 기반하여 서비스 파라미터, 예를 들어, NSI에 대한 서비스 노출 레벨을 결정한다.

단계 1(메시징(510) 참조)에서, 일 실시예에서, SMO(402)(예를 들어, NSP 관련 MD)는 xApp, rApp 또는 RIC 기능과 같은 슬라이스-인에이블링 기능일 수 있는 미들웨어 엔티티(202)에 애플리케이션 대 슬라이스 가입 정보뿐만 아니라 가입된 NSI(들)에 대한 협약된 서비스 능력 노출을 전송한다. 이 단계는 또한 미들웨어 엔티티(502)가 슬라이스/서비스 API 구성 및 노출을 핸들링하라는 지시/요청을 포함할 수 있다.

단계 2a(메시징(512) 참조)에서, 일 실시예에서, 미들웨어 엔티티(202)는 슬라이스 관리 서비스들과 관련된 능력들(예를 들어, NSSI/NSI 모니터링, 수정 등) 및 이용가능한 API 상태를 얻기 위한 요청을 관여된 관리 도메인(들)에 전송한다. 관여된 관리 도메인들은 (서비스 능력 노출에 기반하여) 단계 1로부터 미들웨어 엔티티(202)에 의해 알려진다. 이 메시지는 다음의 파라미터들 중 적어도 하나를 포함한다:

미들웨어 ID(xApp/rApp ID)

API 이름/URI의 요청

API 버전의 요청

데이터 포맷(예를 들어, 직렬화 프로토콜)의 요청

슬라이스 #X 또는 서비스 #Y와 관련된 API 지원 특징들의 요청

지원되는 특징들에 대한 노출 레벨 요건

API 상태 질의

API 종료 포인트들

시간 유효성

단계 2b(메시징(514) 참조)에서, 일 실시예에서, 관리 도메인은 API 상태 및 슬라이스 관련 관리 능력들을 제공한다. 이 메시지는 다음의 파라미터들 중 적어도 하나를 포함한다:

MD ID, MnS ID

API 이름들, 유형들, 데이터 포맷들의 리스트

슬라이스/서비스와 관련된 API 지원 특징들

지원되는 특징들의 노출 레벨

API 상태 보고

단계 3a(메시징(516) 참조)에서, 일 실시예에서, 미들웨어 엔티티(202)는 노출될 수 있는 슬라이스 관련 제어 서비스들에 관련된 능력들(예를 들어, 슬라이스 가입들, 네트워크 슬라이스 분석, QoS/네트워크 모니터링 이벤트들 등) 및 이용가능한 API 상태를 얻기 위한 요청을 API 인에이블먼트 서비스들(404) 또는 영향받은 제어/E2 관련 기능(504)에 전송한다. API 인에이블먼트 서비스들(404)뿐만 아니라 인에이블먼트 API는 (서비스 능력 노출에 기반하여) 단계 1로부터 미들웨어 엔티티(202)에 의해 알려진다. 이 메시지는 다음의 파라미터들 중 적어도 하나를 포함한다:

미들웨어 ID/xApp 또는 rApp ID

E2 관련 또는 제어 API 이름/URI의 요청

E2 관련 또는 제어 API 버전의 요청

데이터 포맷(예를 들어, 직렬화 프로토콜)의 요청

슬라이스 #X 또는 서비스 #Y와 관련된 E2 관련 또는 제어 API 지원 특징들의 요청

지원되는 특징들에 대한 노출 레벨 요건

E2 관련 또는 제어 상태 질의

E2 관련 또는 제어 종료 포인트들

시간 유효성

단계 3b(메시징(518) 참조)에서, 일 실시예에서, API 인에이블먼트 서비스들(404)(또는 관련 제어/E2 관련 기능(504))은 API 상태 및 슬라이스 관련 제어 노출 능력들을 제공한다. 이 메시지는 다음의 파라미터들 중 적어도 하나를 포함한다:

RIC 기능 ID

API 이름들, 유형들, 데이터 포맷들의 리스트

슬라이스/서비스와 관련된 API 지원 특징들

지원되는 특징들의 노출 레벨

API 상태 보고

단계 4(블록(520) 참조)에서, 일 실시예에서, 미들웨어 엔티티(202)는 NSI에 대한 서비스 능력 노출 요건들 및 서비스 API들의 이용가능성에 기반하여 NSI를 서비스 API들의 리스트에 매핑한다. 특정 구현들에서, 이것은 매핑 표일 수 있다.

단계 5a(메시징(522) 참조)에서, 일 실시예에서, 미들웨어 엔티티(202)는 슬라이스와 관련된 MnS 서비스 API를 소비하기 위해 가입하기 위한 가입 요청을 관리 도메인(들)의 영향받은 관리 서비스(504)에 전송한다. 가입 요청은 또한 관리 서비스들에 대한 노출 레벨(예를 들어, 허가들, 보고의 세분성 등)을 포함할 수 있다. 이 가입은 또한 API 인에이블먼트 서비스들(404)/인에이블먼트 API를 통해 행해질 수 있다. 단계 5b(메시징(524) 참조)에서, 일 실시예에서, 관리 도메인(또는 API 인에이블먼트 서비스(404))의 MnS는 가입의 확인응답을 제공하기 위해 ACK를 전송한다.

단계 6a(메시징(526) 참조)에서, 일 실시예에서, 미들웨어 엔티티(202)는 슬라이스와 관련된 제어/E2 관련 API들을 소비하기 위해 가입하기 위한 가입 요청을 관리 기능(504), 예를 들어, RIC(또는 API 인에이블먼트 서비스들(404))의 가입 관리 기능에 전송한다. 가입 요청은 또한 제어 서비스들에 대한 노출 레벨(예를 들어, 허가들, 보고의 세분성 등)을 포함할 수 있다. 단계 6b(메시징(528) 참조)에서, 일 실시예에서, 관리 기능(504), 예컨대, 가입 관리 기능, 또는 임의의 다른 RIC 기능은 가입의 확인응답을 제공하기 위해 ACK를 전송한다.

단계 7(블록(530) 참조)에서, 일 실시예에서, 미들웨어 엔티티(202)는 서비스들에 가입할 때, 제공된 서비스들의 하나 이상의 슬라이스에 대한 하나 이상의 슬라이스 API로의 매핑을 구성한다. 서비스들에 대한 슬라이스 API 매핑은 슬라이스 API 이름/식별, 인클로징된 서비스 API 이름들, URI들, API 버전들, 프로토콜 정보, API마다의 종료 포인트들, 포함된 API 유형들, 통신 방법들(예를 들어, 요청-응답 또는 가입-통지), 시간 유효성 등을 포함한다. 슬라이스 API들은 부가 가치 미들웨어 제공 서비스들과 관련된 서비스 API들도 포함할 수 있다. 이 단계에서, 슬라이스 API 정보, 및 인클로징된 API들은 미들웨어 엔티티(202)에 저장된다.

단계 8(메시징(532) 참조)에서, 일 실시예에서, 미들웨어 엔티티(202)는 최종 애플리케이션들에 의한 이용을 위해 슬라이스 API들을 공개한다.

단계 9(메시징(536) 참조)에서, 일 실시예에서, 트리거 이벤트(블록(534) 참조)는 O-RAN API 생성자들(504, 506) 또는 API 인에이블먼트 기능(404) 또는 애플리케이션 측(예를 들어, 상이한 RIC 플랫폼으로의 애플리케이션 서버 재배치, UE 이동성, 애플리케이션 거동 변경 등) 또는 API 인에이블먼트 서비스들(404)에 의해 캡처되는 임의의 다른 API 관련 이벤트(예를 들어, 장애, 이용불가능성)에 의해 검출되고 캡처된다.

미들웨어 엔티티(202)는, 일 실시예에서, 트리거 이벤트를 처리하고 O-RAN RIC API들의 슬라이스 API들로의 매핑을 체크하고 업데이트한다. 그 목적은 슬라이스 API들을 변경되지 않게 유지하는 것이므로, 버티컬은 어떠한 변경도 알지 못한다. 이를 달성하기 위해, O-RAN RIC API들이 업데이트될 필요가 있을 수 있다. 이 단계에서, 미들웨어 엔티티(202)는 일부 서비스들의 소비의 이용불가능성을 다루기 위해 부가 가치 서비스들을 제공함으로써 추가로 지원할 수 있다.

단계 10(메시징(538) 참조)에서, 일 실시예에서, 미들웨어 엔티티(202)는, 필요하다면, 슬라이스 API들을 재공개한다.

도 6은, 본 개시내용의 실시예들에 따라, 플랫폼 독립적인 애플리케이션 프로그래밍 인터페이스들을 구성하는데 이용될 수 있는 사용자 장비 장치(600)를 도시한다. 다양한 실시예들에서, 사용자 장비 장치(600)는 전술한 솔루션들 중 하나 이상을 구현하는데 이용된다. 사용자 장비 장치(600)는 전술한 원격 유닛(105), 클라이언트 디바이스(201), 및/또는 버티컬 디바이스(301) 등의 버티컬 디바이스에서 구현될 수 있다. 또한, 사용자 장비 장치(600)는 프로세서(605), 메모리(610), 입력 디바이스(615), 출력 디바이스(620), 및 트랜시버(625)를 포함할 수 있다. 일부 실시예들에서, 입력 디바이스(615) 및 출력 디바이스(620)는 터치스크린과 같은 단일 디바이스로 결합된다. 특정 실시예들에서, 사용자 장비 장치(600)는 임의의 입력 디바이스(615) 및/또는 출력 디바이스(620)를 포함하지 않을 수 있다. 다양한 실시예들에서, 사용자 장비 장치(600)는, 프로세서(605), 메모리(610), 및 트랜시버(625) 중 하나 이상을 포함할 수 있고, 입력 디바이스(615) 및/또는 출력 디바이스(620)를 포함하지 않을 수 있다.

도시된 바와 같이, 트랜시버(625)는 적어도 하나의 전송기(630) 및 적어도 하나의 수신기(635)를 포함한다. 여기서, 트랜시버(625)는 하나 이상의 원격 유닛(105)과 통신한다. 또한, 트랜시버(625)는 적어도 하나의 네트워크 인터페이스(640)를 지원할 수 있다. 일부 실시예들에서, 트랜시버(625)는 RAN 내의 하나 이상의 베이스 유닛과 통신하기 위한 제1 인터페이스(예를 들어, Uu 인터페이스), AMF와 통신하기 위한 제2 인터페이스(예를 들어, N1 인터페이스), 및 TSN 시스템과 통신하기 위한 제3 인터페이스를 지원한다.

프로세서(605)는, 일 실시예에서, 컴퓨터 판독가능한 명령어들을 실행할 수 있고/있거나 논리적 연산들을 수행할 수 있는 임의의 공지된 제어기를 포함할 수 있다. 예를 들어, 프로세서(605)는, 마이크로제어기, 마이크로프로세서, 중앙 처리 유닛("CPU"), 그래픽 처리 유닛("GPU"), 보조 처리 유닛, FPGA, 또는 유사한 프로그래밍가능한 제어기일 수 있다. 일부 실시예들에서, 프로세서(605)는 메모리(610)에 저장된 명령어들을 실행하여 본 명세서에 설명된 방법들 및 루틴들을 수행한다. 프로세서(605)는, 메모리(610), 입력 디바이스(615), 출력 디바이스(620), 및 트랜시버(625)에 통신가능하게 결합된다. 다양한 실시예들에서, 프로세서(605)는 사용자 장비 장치(600)를 제어하여 전술한 UE 거동들, 클라이언트 디바이스 거동들, 및/또는 버티컬 디바이스 거동들을 구현한다.

사용자 장비 장치(600)는 하나 이상의 애플리케이션 인터페이스(645)를 지원한다. 각각의 애플리케이션 인터페이스(645)는 사용자 장비 장치(600) 상에서 실행되는 애플리케이션 인스턴스들 사이의 통신을 지원하고/하거나, 예를 들어, 네트워크 디바이스 또는 UE 상에서 실행되는 외부 애플리케이션 인스턴스와의 통신을 지원한다. 일부 실시예들에서, 애플리케이션 인터페이스(들)(645)는 사용자 장비 장치(600) 상에서 실행되는 애플리케이션들이 다른 애플리케이션들, 서비스들 또는 운영 체제들의 데이터 및 특징들에 액세스하는 것을 허용하는 기능들 및 절차들의 세트를 포함한다. 예를 들어, 사용자 장비 장치(600) 상에서 실행되는 SEAL 클라이언트는 애플리케이션 인터페이스(645)를 이용하여 SEAL 서버와 통신할 수 있다. 다른 예로서, 사용자 장비 장치(600) 상에서 실행되는 V2X 애플리케이션은 애플리케이션 인터페이스(645)를 이용하여 V2X 애플리케이션 서버와 통신할 수 있다.

일 실시예에서, 메모리(610)는 컴퓨터 판독가능한 저장 매체이다. 일부 실시예들에서, 메모리(610)는 휘발성 컴퓨터 저장 매체를 포함한다. 예를 들어, 메모리(610)는 동적 RAM("DRAM"), 동기식 동적 RAM("SDRAM"), 및/또는 정적 RAM("SRAM")을 포함하는 RAM을 포함할 수 있다. 일부 실시예들에서, 메모리(610)는 비휘발성 컴퓨터 저장 매체를 포함한다. 예를 들어, 메모리(610)는 하드 디스크 드라이브, 플래시 메모리, 또는 임의의 다른 적절한 비휘발성 컴퓨터 저장 디바이스를 포함할 수 있다. 일부 실시예들에서, 메모리(610)는 휘발성 및 비휘발성 컴퓨터 저장 매체 둘 다를 포함한다.

일부 실시예들에서, 메모리(610)는 플랫폼 독립적인 애플리케이션 프로그래밍 인터페이스들을 구성하는 것에 관련된 데이터를 저장한다. 예를 들어, 메모리(610)는 서비스 요건들, API 매핑들, 애플리케이션 요건들, 관련 파라미터들 등을 저장할 수 있다. 특정 실시예들에서, 메모리(610)는 또한 원격 유닛(105) 상에서 동작하는 운영 체제 또는 다른 제어기 알고리즘들과 같은 프로그램 코드 및 관련 데이터를 저장한다.

입력 디바이스(615)는, 일 실시예에서, 터치 패널, 버튼, 키보드, 스타일러스, 마이크로폰 등을 포함하는 임의의 공지된 컴퓨터 입력 디바이스를 포함할 수 있다. 일부 실시예들에서, 입력 디바이스(615)는, 예를 들어, 터치스크린 또는 유사한 터치 감응 디스플레이로서 출력 디바이스(620)와 통합될 수 있다. 일부 실시예들에서, 입력 디바이스(615)는, 텍스트가 터치스크린 상에 표시된 가상 키보드를 이용하여 그리고/또는 터치스크린 상에 필기함으로써 입력될 수 있도록 터치스크린을 포함한다. 일부 실시예들에서, 입력 디바이스(615)는 키보드 및 터치 패널과 같은 2개 이상의 상이한 디바이스를 포함한다.

출력 디바이스(620)는, 일 실시예에서, 시각적, 청각적, 및/또는 촉각적 신호들을 출력하도록 설계된다. 일부 실시예들에서, 출력 디바이스(620)는 시각적 데이터를 사용자에게 출력할 수 있는 전자적으로 제어가능한 디스플레이 또는 디스플레이 디바이스를 포함한다. 예를 들어, 출력 디바이스(620)는, LCD 디스플레이, LED 디스플레이, OLED 디스플레이, 프로젝터, 또는 이미지들, 텍스트 등을 사용자에게 출력할 수 있는 유사한 디스플레이 디바이스를 포함할 수 있지만, 이것으로 제한되는 것은 아니다. 다른 비제한적인 예로서, 출력 디바이스(620)는, 스마트 시계, 스마트 안경, 헤드-업 디스플레이 등과 같은, 사용자 장비 장치(600)의 나머지와 별개이지만 이에 통신가능하게 결합된 웨어러블 디스플레이를 포함할 수 있다. 또한, 출력 디바이스(620)는 스마트폰, 개인 휴대 정보 단말기, 텔레비전, 테이블 컴퓨터, 노트북(랩톱) 컴퓨터, 개인용 컴퓨터, 차량 대시보드 등의 구성요소일 수 있다.

특정 실시예들에서, 출력 디바이스(620)는 사운드를 생성하기 위한 하나 이상의 스피커를 포함한다. 예를 들어, 출력 디바이스(620)는 가청 경보 또는 통지(예컨대, 비프음 또는 차임음)를 생성할 수 있다. 일부 실시예들에서, 출력 디바이스(620)는 진동들, 모션, 또는 다른 촉각적 피드백을 생성하기 위한 하나 이상의 촉각적 디바이스를 포함한다. 일부 실시예들에서, 출력 디바이스(620)의 전부 또는 일부는 입력 디바이스(615)와 통합될 수 있다. 예를 들어, 입력 디바이스(615) 및 출력 디바이스(620)는 터치스크린 또는 유사한 터치 감응 디스플레이를 형성할 수 있다. 다른 실시예들에서, 출력 디바이스(620)는 입력 디바이스(615) 근처에 위치할 수 있다.

트랜시버(625)는 메시지들, 데이터, 및 다른 신호들을 전송하고 또한 메시지들, 데이터, 및 다른 신호들을 수신하기 위해 프로세서(605)의 제어 하에서 동작한다. 예를 들어, 프로세서(605)는 메시지들을 전송 및 수신하기 위해 특정 시간들에서 트랜시버(또는 그 부분들)를 선택적으로 활성화시킬 수 있다.

다양한 실시예들에서, 트랜시버(625)는 3GPP 액세스 네트워크(들) 및/또는 비-3GPP 액세스 네트워크(들)와 통신하도록 구성된다. 일부 실시예들에서, 트랜시버(625)는 3GPP 액세스 네트워크(들) 및/또는 비-3GPP 액세스 네트워크(들)에 대한 모뎀 기능을 구현한다. 일 실시예에서, 트랜시버(625)는 공통 물리적 하드웨어를 이용하면서, 상이한 통신 프로토콜들 또는 프로토콜 스택들을 이용하여 복수의 논리적 트랜시버들을 구현한다.

일 실시예에서, 트랜시버(625)는 허가 라디오 스펙트럼을 통해 모바일 통신 네트워크와 통신하는데 이용되는 제1 전송기/수신기 쌍 및 비허가 라디오 스펙트럼을 통해 모바일 통신 네트워크와 통신하는데 이용되는 제2 전송기/수신기 쌍을 포함한다. 특정 실시예들에서, 허가 라디오 스펙트럼을 통해 모바일 통신 네트워크와 통신하는데 이용되는 제1 전송기/수신기 쌍 및 비허가 라디오 스펙트럼을 통해 모바일 통신 네트워크와 통신하는데 이용되는 제2 전송기/수신기 쌍은 단일 트랜시버 유닛, 예를 들어, 허가 및 비허가 라디오 스펙트럼 모두와 함께 이용하기 위한 기능들을 수행하는 단일 칩으로 결합될 수 있다. 일부 실시예들에서, 제1 전송기/수신기 쌍 및 제2 전송기/수신기 쌍은 하나 이상의 하드웨어 구성요소를 공유할 수 있다. 예를 들어, 특정 트랜시버들(625), 전송기들(630), 및 수신기들(635)은, 예를 들어, 네트워크 인터페이스(640)와 같은, 공유 하드웨어 리소스 및/또는 소프트웨어 리소스에 액세스하는 물리적으로 별개의 구성요소들로서 구현될 수 있다.

트랜시버(625)는 하나 이상의 전송기(630) 및 하나 이상의 수신기(635)를 포함할 수 있다. 특정 수의 전송기들(630) 및 수신기들(635)이 예시되지만, 사용자 장비 장치(600)는 임의의 적절한 수의 전송기들(630) 및 수신기들(635)을 가질 수 있다. 또한, 전송기(들)(630) 및 수신기(들)(635)는 임의의 적절한 유형의 전송기들 및 수신기들일 수 있다. 특정 실시예들에서, 하나 이상의 전송기(630) 및/또는 하나 이상의 수신기(635)는 트랜시버 하드웨어 및/또는 회로를 공유할 수 있다. 예를 들어, 하나 이상의 전송기(630) 및/또는 하나 이상의 수신기(635)는 안테나(들), 안테나 튜너(들), 증폭기(들), 필터(들), 발진기(들), 믹서(들), 변조기/복조기(들), 전원 등을 공유할 수 있다.

다양한 실시예들에서, 하나 이상의 전송기(630) 및/또는 하나 이상의 수신기(635)는 멀티-트랜시버 칩, 시스템-온-칩, 주문형 집적 회로("ASIC"), 또는 다른 유형의 하드웨어 구성요소와 같은 단일 하드웨어 구성요소로 구현 및/또는 통합될 수 있다. 특정 실시예들에서, 하나 이상의 전송기(630) 및/또는 하나 이상의 수신기(635)는 멀티-칩 모듈로 구현 및/또는 통합될 수 있다. 일부 실시예들에서, 네트워크 인터페이스(640) 또는 다른 하드웨어 구성요소들/회로들과 같은 다른 구성요소들은 임의의 수의 전송기들(630) 및/또는 수신기들(635)과 함께 단일 칩으로 통합될 수 있다. 이러한 실시예에서, 전송기들(630) 및 수신기들(635)은 하나 이상의 공통 제어 신호를 이용하는 트랜시버(625)로서, 또는 동일한 하드웨어 칩 또는 멀티-칩 모듈에서 구현된 모듈식 전송기들(630) 및 수신기들(635)로서 논리적으로 구성될 수 있다. 특정 실시예들에서, 트랜시버(625)는 (예를 들어, NR 또는 LTE 액세스 네트워크들을 통해 통신하기 위한) 3GPP 모뎀 및 (예를 들어, Wi-Fi 또는 다른 비-3GPP 액세스 네트워크들을 통해 통신하기 위한) 비-3GPP 모뎀을 구현할 수 있다.

도 7은, 본 개시내용의 실시예들에 따라, 플랫폼 독립적인 애플리케이션 프로그래밍 인터페이스들을 구성하는데 이용될 수 있는 네트워크 장비 장치(700)의 일 실시예를 도시한다. 일부 실시예들에서, 네트워크 장비 장치(700)는 VAL 서버(151), SEAL 서버(155), 에지 인에이블러 서버(145), 인에이블러 서버(213), SEAL/NSE 서버(307), 및/또는 VAL 서버(309)와 같은 신뢰 애플리케이션 엔티티(예를 들어, 미들웨어)의 일 실시예일 수 있다. 또한, 네트워크 장비 장치(700)는 프로세서(705), 메모리(710), 입력 디바이스(715), 출력 디바이스(720), 트랜시버(725)를 포함할 수 있다. 일부 실시예들에서, 입력 디바이스(715) 및 출력 디바이스(720)는 터치스크린과 같은 단일 디바이스로 결합된다. 특정 실시예들에서, 네트워크 장비 장치(700)는 어떠한 입력 디바이스(715) 및/또는 출력 디바이스(720)도 포함하지 않는다.

도시된 바와 같이, 트랜시버(725)는 적어도 하나의 전송기(730) 및 적어도 하나의 수신기(735)를 포함한다. 여기서, 트랜시버(725)는 하나 이상의 원격 유닛(105)과 통신한다. 또한, 트랜시버(725)는 N1, N2 및 N3 인터페이스와 같은 적어도 하나의 네트워크 인터페이스(740)를 지원할 수 있다. 일부 실시예들에서, 트랜시버(725)는 모바일 코어 네트워크(예를 들어, 5GC 및/또는 EPC) 내의 하나 이상의 네트워크 기능과 통신하기 위한 제1 인터페이스, TSN 시스템과 통신하기 위한 제2 인터페이스, 및 원격 유닛(예를 들어, UE)과 통신하기 위한 제3 인터페이스를 지원한다.

프로세서(705)는, 일 실시예에서, 컴퓨터 판독가능한 명령어들을 실행할 수 있고/있거나 논리적 연산들을 수행할 수 있는 임의의 공지된 제어기를 포함할 수 있다. 예를 들어, 프로세서(705)는 마이크로제어기, 마이크로프로세서, 중앙 처리 유닛("CPU"), 그래픽 처리 유닛("GPU"), 보조 처리 유닛, 필드 프로그래밍가능한 게이트 어레이("FPGA"), 또는 유사한 프로그래밍가능한 제어기일 수 있다. 일부 실시예들에서, 프로세서(705)는 메모리(710)에 저장된 명령어들을 실행하여 본 명세서에 설명된 방법들 및 루틴들을 수행한다. 프로세서(705)는 메모리(710), 입력 디바이스(715), 출력 디바이스(720), 및 트랜시버(725)에 통신가능하게 결합된다. 다양한 실시예들에서, 프로세서(705)는 전술한 네트워크 거동들을 구현하도록 사용자 장비 장치(700)를 제어한다.

트랜시버(725)를 통해, 일 실시예에서, 프로세서(705)는 무선 통신 시스템의 적어도 하나의 네트워크 서비스의 서비스 파라미터를 수신하고, 무선 통신 시스템은 하나 이상의 플랫폼을 포함한다. 프로세서(705)는, 특정 실시예들에서, 무선 통신 시스템의 적어도 하나의 네트워크 서비스의 서비스 파라미터에 기반하여 플랫폼 독립적인 애플리케이션 프로그래밍 인터페이스("API")를 결정한다.

일 실시예에서, 프로세서(705)는 상이한 무선 통신 시스템들에 걸친 최종 애플리케이션들에 의한 이용을 위해 API 호출자에게 플랫폼 독립적인 API를 공개한다. 추가 실시예들에서, 프로세서(705)는 적어도 하나의 서비스 API를 호출하기 위한 액세스를 얻기 위해 적어도 하나의 네트워크 서비스에 등록한다. 일부 실시예들에서, 프로세서(705)는 적어도 하나의 플랫폼 의존적인 API로의 매핑에 기반하여 플랫폼 독립적인 API를 결정한다.

일 실시예에서, 프로세서(705)는 플랫폼 의존적인 API와 연관된 트리거 이벤트를 검출하고, 플랫폼 독립적인 API와의 호환성을 보장하면서 트리거 이벤트에 응답하여 플랫폼 의존적인 API를 업데이트한다. 일부 실시예들에서, 트리거 이벤트는 사용자 장비("UE")의 이동성, 상이한 무선 통신 시스템으로의 애플리케이션 서버의 재배치, 무선 통신 시스템의 적어도 하나의 네트워크 서비스의 서비스 API의 이용불가능성, 실제 또는 예상된 API의 높은 부하 및/또는 정체의 표시, 상이한 무선 통신 플랫폼으로의 UE의 애플리케이션 클라이언트의 재배치, 네트워크 서비스 품질 변경 표시, UE 서비스 품질 및/또는 경험 품질 변경 표시, UE 컨텍스트 변경 표시, 및 네트워크 유닛 장애 표시를 포함한다.

일 실시예에서, 적어도 하나의 플랫폼 의존적인 API로의 적어도 하나의 네트워크 서비스에 대한 적어도 하나의 서비스 API의 매핑은, 트랜시버(725)를 통해 프로세서(705)에 의해, 적어도 하나의 서비스 API와 연관된 적어도 하나의 네트워크 서비스로부터 주기적 하트비트 메시지를 수신하는 것 및 프로세서(705)에 의해, 적어도 하나의 네트워크 서비스에 대한 API 인에이블먼트 서비스를 체크하는 것 중 적어도 하나에 의해 서비스 API들의 이용가능성을 결정하는 것에 기반한다.

일 실시예에서, 적어도 하나의 네트워크 서비스의 서비스 파라미터는 무선 통신 시스템의 버티컬 고객의 네트워크 슬라이스 인스턴스("NSI")에 대한 것이고, 플랫폼 의존적인 API는 버티컬 고객에 대해 맞춤화되는 소프트웨어 개발 키트 API를 포함한다.

특정 실시예들에서, 프로세서(705)는, 트랜시버(725)를 통해, 관리 API의 이용가능성 상태 및 NSI에 대한 슬라이스 관리 서비스들과 관련된 능력들에 대한 요청을 관리 도메인에 전송한다. 이 요청은 미들웨어 ID, API 이름의 요청, API URI의 요청, API 버전의 요청, 데이터 포맷의 요청, 슬라이스 및 서비스 중 적어도 하나와 관련된 API 지원 특징들의 요청, 지원되는 특징들에 대한 노출 레벨 요건, API 상태 질의, API 종료 포인트들, 및 요청의 시간 유효성 중 적어도 하나를 포함한다.

일 실시예에서, 프로세서(705)는, 트랜시버(725)를 통해, 다음의 파라미터들, 즉 MD ID, MnS ID, API 이름들, 유형들, 및 데이터 포맷들의 리스트, 슬라이스 및 서비스 중 적어도 하나와 관련된 API 지원 특징들, 지원되는 특징들의 노출 레벨, 및 API 상태 보고 중 적어도 하나를 포함하는 응답 메시지를 수신한다. 일 실시예에서, 프로세서(705)는, 트랜시버(725)를 통해, 제어 평면 API의 이용가능성 상태 및 NSI에 대한 슬라이스 관련 제어 서비스들과 관련된 능력들에 대한 요청을 제어 평면에 전송한다. 이 요청은 미들웨어 ID, 노스바운드 API 이름의 요청, 노스바운드 URI의 요청, 노스바운드 API 버전의 요청, 데이터 포맷의 요청, 슬라이스 및 서비스 중 적어도 하나와 관련된 노스바운드 API 지원 특징들의 요청, 지원되는 특징들에 대한 노출 레벨 요건, API 상태 질의, API 종료 포인트들, 및 시간 유효성 중 적어도 하나를 포함한다.

일 실시예에서, 프로세서(705)는, 트랜시버(725)를 통해, 다음의 파라미터들, 즉 NEF ID, API 이름들, 유형들, 및 데이터 포맷들의 리스트, 슬라이스 및 서비스 중 적어도 하나와 관련된 API 지원 특징들, 지원되는 특징들의 노출 레벨, 및 API 상태 보고 중 적어도 하나를 포함하는 응답 메시지를 수신한다.

일 실시예에서, 프로세서(705)는, 트랜시버(725)를 통해, E2 관련 기능 API의 이용가능성 상태 및 NSI에 대한 슬라이스 관련 제어 서비스들과 관련된 능력들에 대한 요청을 E2 관련 기능에 전송한다. 이 요청은 미들웨어 ID, xApp ID 및 rApp ID 중 하나, E2 관련 API 이름의 요청, E2 관련 URI의 요청, E2 관련 버전의 요청, 데이터 포맷의 요청, 슬라이스 및 서비스 중 적어도 하나와 관련된 E2 관련 지원 특징들의 요청, 지원되는 특징들에 대한 노출 레벨 요건, E2 관련 상태 질의, E2 관련 종료 포인트들, 및 시간 유효성을 포함한다.

일 실시예에서, 프로세서(705)는, 트랜시버(725)를 통해, 다음의 파라미터들, 즉 RIC 기능 ID, API 이름들, 유형들, 및 데이터 포맷들의 리스트, 슬라이스 및 서비스 중 적어도 하나와 관련된 API 지원 특징들, 지원되는 특징들의 노출 레벨, 및 API 상태 보고 중 적어도 하나를 포함하는 응답 메시지를 수신한다.

일 실시예에서, 적어도 하나의 플랫폼 의존적인 API로의 적어도 하나의 NSI에 대한 적어도 하나의 서비스 API의 매핑은 적어도 하나의 네트워크 서비스의 서비스 파라미터를 NSI에 대한 적어도 하나의 능력 파라미터와 매칭시킴으로써 행해진다. 특정 실시예들에서, NSI에 대한 플랫폼 독립적인 API로의 플랫폼 의존적인 API의 매핑은 플랫폼 독립적인 API 이름/식별, 인클로징된 서비스 API 이름들, URI들, API 버전들, 프로토콜 정보, API마다의 종료 포인트들, API 유형들, 통신 방법들, 및 시간 유효성 중 적어도 하나를 포함한다.

일 실시예에서, 프로세서(705)는, 트랜시버(725)를 통해, 적어도 하나의 네트워크 서비스에 대해 서비스 관리 편성자("SMO")로부터 서비스 파라미터를 요청한다. 서비스 파라미터는 적어도 하나의 네트워크 서비스의 유형 및 적어도 하나의 네트워크 서비스에 액세스하기 위한 허가 중 적어도 하나에 기반할 수 있다. 일부 실시예들에서, 프로세서(705)는, 트랜시버(725)를 통해, 서비스, 슬라이스, 및 애플리케이션 유형 중 적어도 하나에 대한 적어도 하나의 네트워크 서비스의 서비스 파라미터를 포함하는 메시지를 SMO로부터 수신한다.

일 실시예에서, 적어도 하나의 네트워크 서비스는 외부 애플리케이션("xApp")을 포함한다. 일부 실시예들에서, 적어도 하나의 네트워크 서비스에 대한 플랫폼 독립적인 API로의 플랫폼 의존적인 API의 매핑은 API를 간소화하기 위한 전체 복잡성/레이턴시에 대한 영향, 프로토콜 레벨 영향들, 휴대성에 대한 애플리케이션 요건들, 노출 능력들에 대한 슬라이스 관련 요건들, 네트워크 기능의 유형에 관련된 보안 양태들, 최종 애플리케이션의 능력들, 서비스들 간의 의존성들, 및 서비스 레벨 협약("SLA") 중 적어도 하나를 포함한다.

네트워크 장비 장치(700)는 하나 이상의 애플리케이션 인터페이스(745)를 지원한다. 각각의 애플리케이션 인터페이스(745)는 사용자 장비 장치(700) 상에서 실행되는 애플리케이션 인스턴스들 사이의 통신을 지원하고/하거나, 예를 들어, 네트워크 디바이스 또는 UE 상에서 실행되는 외부 애플리케이션 인스턴스와의 통신을 지원한다. 일부 실시예들에서, 애플리케이션 인터페이스(들)(745)는 네트워크 장비 장치(700) 상에서 실행되는 애플리케이션들이 다른 애플리케이션들, 서비스들 또는 운영 체제들의 데이터 및 특징들에 액세스하는 것을 허용하는 기능들 및 절차들의 세트를 포함한다. 아래에 더 상세히 설명되는 바와 같이, 네트워크 장비 장치(700) 상에서 실행되는 SEAL 클라이언트(107)는 애플리케이션 인터페이스(745)를 이용하여 SEAL 서버(155)와 통신할 수 있다. 다른 예로서, 네트워크 장비 장치(700) 상에서 실행되는 VAL 애플리케이션은 애플리케이션 인터페이스(745)를 이용하여 VAL 애플리케이션 서버(151)와 통신할 수 있다.

일 실시예에서, 메모리(710)는 컴퓨터 판독가능한 저장 매체이다. 일부 실시예들에서, 메모리(710)는 휘발성 컴퓨터 저장 매체를 포함한다. 예를 들어, 메모리(710)는 동적 RAM("DRAM"), 동기식 동적 RAM("SDRAM"), 및/또는 정적 RAM("SRAM")을 포함하는 RAM을 포함할 수 있다. 일부 실시예들에서, 메모리(710)는 비휘발성 컴퓨터 저장 매체를 포함한다. 예를 들어, 메모리(710)는 하드 디스크 드라이브, 플래시 메모리, 또는 임의의 다른 적절한 비휘발성 컴퓨터 저장 디바이스를 포함할 수 있다. 일부 실시예들에서, 메모리(710)는 휘발성 및 비휘발성 컴퓨터 저장 매체 둘 다를 포함한다.

일부 실시예들에서, 메모리(710)는 플랫폼 독립적인 애플리케이션 프로그래밍 인터페이스들을 구성하기 위한 데이터를 저장하며, 예를 들어 서비스 요건들, QoS 요건들, QoE 요건들, 매핑들, 애플리케이션 요건들, 관련 파라미터들 등을 저장한다. 특정 실시예들에서, 메모리(710)는 또한 네트워크 장비 장치(700) 및 하나 이상의 소프트웨어 애플리케이션 상에서 동작하는 운영 체제("OS") 또는 다른 제어기 알고리즘들과 같은 프로그램 코드 및 관련 데이터를 저장한다.

입력 디바이스(715)는, 일 실시예에서, 터치 패널, 버튼, 키보드, 스타일러스, 마이크로폰 등을 포함하는 임의의 공지된 컴퓨터 입력 디바이스를 포함할 수 있다. 일부 실시예들에서, 입력 디바이스(715)는, 예를 들어, 터치스크린 또는 유사한 터치 감응 디스플레이로서 출력 디바이스(720)와 통합될 수 있다. 일부 실시예들에서, 입력 디바이스(715)는, 텍스트가 터치스크린 상에 표시된 가상 키보드를 이용하여 그리고/또는 터치스크린 상에 필기함으로써 입력될 수 있도록 터치스크린을 포함한다. 일부 실시예들에서, 입력 디바이스(715)는 키보드 및 터치 패널과 같은 2개 이상의 상이한 디바이스를 포함한다.

출력 디바이스(720)는, 일 실시예에서, 임의의 공지된 전자적으로 제어가능한 디스플레이 또는 디스플레이 디바이스를 포함할 수 있다. 출력 디바이스(720)는 시각적, 청각적, 및/또는 촉각적 신호들을 출력하도록 설계될 수 있다. 일부 실시예들에서, 출력 디바이스(720)는 시각적 데이터를 사용자에게 출력할 수 있는 전자 디스플레이를 포함한다. 예를 들어, 출력 디바이스(720)는 LCD 디스플레이, LED 디스플레이, OLED 디스플레이, 프로젝터, 또는 이미지들, 텍스트 등을 사용자에게 출력할 수 있는 유사한 디스플레이 디바이스를 포함할 수 있지만, 이것으로 제한되는 것은 아니다. 다른 비제한적인 예로서, 출력 디바이스(720)는 스마트 시계, 스마트 안경, 헤드-업 디스플레이 등과 같은 웨어러블 디스플레이를 포함할 수 있다. 또한, 출력 디바이스(720)는 스마트폰, 개인 휴대 정보 단말기, 텔레비전, 테이블 컴퓨터, 노트북(랩톱) 컴퓨터, 개인용 컴퓨터, 차량 대시보드 등의 구성요소일 수 있다.

특정 실시예들에서, 출력 디바이스(720)는 사운드를 생성하기 위한 하나 이상의 스피커를 포함한다. 예를 들어, 출력 디바이스(720)는 가청 경보 또는 통지(예컨대, 비프음 또는 차임음)를 생성할 수 있다. 일부 실시예들에서, 출력 디바이스(720)는 진동들, 모션, 또는 다른 촉각적 피드백을 생성하기 위한 하나 이상의 촉각적 디바이스를 포함한다. 일부 실시예들에서, 출력 디바이스(720)의 전부 또는 일부는 입력 디바이스(715)와 통합될 수 있다. 예를 들어, 입력 디바이스(715) 및 출력 디바이스(720)는 터치스크린 또는 유사한 터치 감응 디스플레이를 형성할 수 있다. 다른 실시예들에서, 출력 디바이스(720)의 전부 또는 일부는 입력 디바이스(715) 근처에 위치될 수 있다.

전술한 바와 같이, 트랜시버(725)는 하나 이상의 원격 유닛 및/또는 하나 이상의 PLMN에 대한 액세스를 제공하는 하나 이상의 네트워크 기능과 통신할 수 있다. 트랜시버(725)는 또한 (예를 들어, 모바일 코어 네트워크(120) 내의) 하나 이상의 네트워크 기능과 통신할 수 있다. 트랜시버(725)는 메시지들, 데이터, 및 다른 신호들을 전송하고 또한 메시지들, 데이터, 및 다른 신호들을 수신하기 위해 프로세서(705)의 제어 하에서 동작한다. 예를 들어, 프로세서(705)는 메시지들을 전송 및 수신하기 위해 특정 시간들에서 트랜시버(또는 그 부분들)를 선택적으로 활성화시킬 수 있다.

트랜시버(725)는 하나 이상의 전송기(730) 및 하나 이상의 수신기(735)를 포함할 수 있다. 특정 실시예들에서, 하나 이상의 전송기(730) 및/또는 하나 이상의 수신기(735)는 트랜시버 하드웨어 및/또는 회로를 공유할 수 있다. 예를 들어, 하나 이상의 전송기(730) 및/또는 하나 이상의 수신기(735)는 안테나(들), 안테나 튜너(들), 증폭기(들), 필터(들), 발진기(들), 믹서(들), 변조기/복조기(들), 전원 등을 공유할 수 있다. 일 실시예에서, 트랜시버(725)는 공통 물리적 하드웨어를 이용하면서, 상이한 통신 프로토콜들 또는 프로토콜 스택들을 이용하여 복수의 논리적 트랜시버들을 구현한다.

도 8은 본 개시내용의 실시예들에 따라, 플랫폼 독립적인 애플리케이션 프로그래밍 인터페이스들을 구성하기 위한 방법(800)의 일 실시예를 도시한다. 다양한 실시예들에서, 방법(800)은 전술한 VAL 서버(151), SEAL 서버(155), 에지 인에이블러 서버(145), 인에이블러 서버(202) 등과 같은 신뢰 애플리케이션 엔티티(예를 들어, 미들웨어)에 의해 수행된다. 일부 실시예들에서, 방법(800)은 마이크로제어기, 마이크로프로세서, CPU, GPU, 보조 처리 유닛, FPGA 등과 같은 프로세서에 의해 수행된다.

방법(800)이 시작되고, 일 실시예에서, 무선 통신 시스템의 적어도 하나의 네트워크 서비스의 서비스 파라미터를 수신한다(805). 무선 통신 시스템은 하나 이상의 플랫폼을 포함할 수 있다. 일 실시예에서, 방법(800)은 무선 통신 시스템의 적어도 하나의 네트워크 서비스의 서비스 파라미터에 기반하여 플랫폼 독립적인 애플리케이션 프로그래밍 인터페이스("API")를 결정한다. 방법(800)이 종료한다.

본 개시내용의 실시예들에 따라, 플랫폼 독립적인 애플리케이션 프로그래밍 인터페이스들을 구성하기 위한 제1 장치가 본 명세서에 개시된다. 제1 장치는 VAL 서버(151), SEAL 서버(155), 에지 인에이블러 서버(145), 신뢰 애플리케이션 서버(202), 및/또는 네트워크 장치(700)와 같은 신뢰 애플리케이션 엔티티(예를 들어, 미들웨어)에 의해 구현될 수 있다. 제1 장치는, 일 실시예에서, 무선 통신 시스템의 적어도 하나의 네트워크 서비스의 서비스 파라미터를 수신하는 트랜시버를 포함하고, 여기서, 무선 통신 시스템은 하나 이상의 플랫폼을 포함한다. 제1 장치는, 추가 실시예들에서, 무선 통신 시스템의 적어도 하나의 네트워크 서비스의 서비스 파라미터에 기반하여 플랫폼 독립적인 애플리케이션 프로그래밍 인터페이스("API")를 결정하는 프로세서를 포함한다. 추가 실시예들에서, 제1 장치는 메모리 또는 다른 저장소를 포함하고, 결정된 플랫폼 독립적인 API 및 플랫폼 의존적인 API들로의 매핑을 저장하는 저장소를 포함할 수 있다.

일 실시예에서, 프로세서는 상이한 무선 통신 시스템들에 걸친 최종 애플리케이션들에 의한 이용을 위해 API 호출자에게 플랫폼 독립적인 API를 공개한다. 추가 실시예들에서, 프로세서는 적어도 하나의 서비스 API를 호출하기 위한 액세스를 얻기 위해 적어도 하나의 네트워크 서비스에 등록한다. 일부 실시예들에서, 프로세서는 적어도 하나의 플랫폼 의존적인 API로의 매핑에 기반하여 플랫폼 독립적인 API를 결정한다.

일 실시예에서, 프로세서는 플랫폼 의존적인 API와 연관된 트리거 이벤트를 검출하고, 플랫폼 독립적인 API와의 호환성을 보장하면서 트리거 이벤트에 응답하여 플랫폼 의존적인 API를 업데이트한다. 일부 실시예들에서, 트리거 이벤트는 사용자 장비("UE")의 이동성, 상이한 무선 통신 시스템으로의 애플리케이션 서버의 재배치, 무선 통신 시스템의 적어도 하나의 네트워크 서비스의 서비스 API의 이용불가능성, 실제 또는 예상된 API의 높은 부하 및/또는 정체의 표시, 상이한 무선 통신 플랫폼으로의 UE의 애플리케이션 클라이언트의 재배치, 네트워크 서비스 품질 변경 표시, UE 서비스 품질 및/또는 경험 품질 변경 표시, UE 컨텍스트 변경 표시, 및 네트워크 유닛 장애 표시를 포함한다.

일 실시예에서, 적어도 하나의 플랫폼 의존적인 API로의 적어도 하나의 네트워크 서비스에 대한 적어도 하나의 서비스 API의 매핑은, 트랜시버에 의해, 적어도 하나의 서비스 API와 연관된 적어도 하나의 네트워크 서비스로부터 주기적 하트비트 메시지를 수신하는 것 및 프로세서에 의해, 적어도 하나의 네트워크 서비스에 대한 API 인에이블먼트 서비스를 체크하는 것 중 적어도 하나에 의해 서비스 API들의 이용가능성을 결정하는 것에 기반한다.

특정 실시예들에서, 트랜시버는 관리 API의 이용가능성 상태 및 NSI에 대한 슬라이스 관리 서비스들과 관련된 능력들에 대한 요청을 관리 도메인에 전송한다. 이 요청은 미들웨어 ID, API 이름의 요청, API URI의 요청, API 버전의 요청, 데이터 포맷의 요청, 슬라이스 및 서비스 중 적어도 하나와 관련된 API 지원 특징들의 요청, 지원되는 특징들에 대한 노출 레벨 요건, API 상태 질의, API 종료 포인트들, 및 요청의 시간 유효성 중 적어도 하나를 포함한다.

일 실시예에서, 트랜시버는 다음의 파라미터들, 즉 MD ID, MnS ID, API 이름들, 유형들, 및 데이터 포맷들의 리스트, 슬라이스 및 서비스 중 적어도 하나와 관련된 API 지원 특징들, 지원되는 특징들의 노출 레벨, 및 API 상태 보고 중 적어도 하나를 포함하는 응답 메시지를 수신한다. 일 실시예에서, 트랜시버는 제어 평면 API의 이용가능성 상태 및 NSI에 대한 슬라이스 관련 제어 서비스들과 관련된 능력들에 대한 요청을 제어 평면에 전송한다. 이 요청은 미들웨어 ID, 노스바운드 API 이름의 요청, 노스바운드 URI의 요청, 노스바운드 API 버전의 요청, 데이터 포맷의 요청, 슬라이스 및 서비스 중 적어도 하나와 관련된 노스바운드 API 지원 특징들의 요청, 지원되는 특징들에 대한 노출 레벨 요건, API 상태 질의, API 종료 포인트들, 및 시간 유효성 중 적어도 하나를 포함한다.

일 실시예에서, 트랜시버는 다음의 파라미터들, 즉 NEF ID, API 이름들, 유형들, 및 데이터 포맷들의 리스트, 슬라이스 및 서비스 중 적어도 하나와 관련된 API 지원 특징들, 지원되는 특징들의 노출 레벨, 및 API 상태 보고 중 적어도 하나를 포함하는 응답 메시지를 수신한다.

일 실시예에서, 트랜시버는 E2 관련 기능 API의 이용가능성 상태 및 NSI에 대한 슬라이스 관련 제어 서비스들과 관련된 능력들에 대한 요청을 E2 관련 기능에 전송한다. 이 요청은 미들웨어 ID, xApp ID 및 rApp ID 중 하나, E2 관련 API 이름의 요청, E2 관련 URI의 요청, E2 관련 버전의 요청, 데이터 포맷의 요청, 슬라이스 및 서비스 중 적어도 하나와 관련된 E2 관련 지원 특징들의 요청, 지원되는 특징들에 대한 노출 레벨 요건, E2 관련 상태 질의, E2 관련 종료 포인트들, 및 시간 유효성을 포함한다.

일 실시예에서, 트랜시버는 다음의 파라미터들, 즉 RIC 기능 ID, API 이름들, 유형들, 및 데이터 포맷들의 리스트, 슬라이스 및 서비스 중 적어도 하나와 관련된 API 지원 특징들, 지원되는 특징들의 노출 레벨, 및 API 상태 보고 중 적어도 하나를 포함하는 응답 메시지를 수신한다.

일 실시예에서, 트랜시버는 적어도 하나의 네트워크 서비스에 대해 서비스 관리 편성자("SMO")로부터 서비스 파라미터를 요청한다. 서비스 파라미터는 적어도 하나의 네트워크 서비스의 유형 및 적어도 하나의 네트워크 서비스에 액세스하기 위한 허가 중 적어도 하나에 기반할 수 있다. 일부 실시예들에서, 트랜시버는 서비스, 슬라이스, 및 애플리케이션 유형 중 적어도 하나에 대한 적어도 하나의 네트워크 서비스의 서비스 파라미터를 포함하는 메시지를 SMO로부터 수신한다.

본 개시내용의 실시예들에 따라, 플랫폼 독립적인 애플리케이션 프로그래밍 인터페이스들을 구성하기 위한 제1 방법이 본 명세서에 개시된다. 제1 방법은 VAL 서버(151), IM 서버(153), 에지 인에이블러 서버(145), 신뢰 애플리케이션 서버(202) 및/또는 네트워크 장치(700)와 같은 신뢰 애플리케이션 엔티티(예를 들어, 미들웨어)에 의해 수행될 수 있다. 제1 방법은, 일 실시예에서, 무선 통신 시스템의 적어도 하나의 네트워크 서비스의 서비스 파라미터를 수신하는 단계를 포함한다. 무선 통신 시스템은 하나 이상의 플랫폼을 포함한다. 제1 방법은, 추가 실시예들에서, 무선 통신 시스템의 적어도 하나의 네트워크 서비스의 서비스 파라미터에 기반하여 플랫폼 독립적인 애플리케이션 프로그래밍 인터페이스("API")를 결정하는 단계를 포함한다.

일 실시예에서, 제1 방법은 상이한 무선 통신 시스템들에 걸친 최종 애플리케이션들에 의한 이용을 위해 API 호출자에게 플랫폼 독립적인 API를 공개한다. 추가 실시예들에서, 제1 방법은 적어도 하나의 서비스 API를 호출하기 위한 액세스를 얻기 위해 적어도 하나의 네트워크 서비스에 등록한다. 일부 실시예들에서, 제1 방법은 적어도 하나의 플랫폼 의존적인 API로의 매핑에 기반하여 플랫폼 독립적인 API를 결정한다.

일 실시예에서, 제1 방법은 플랫폼 의존적인 API와 연관된 트리거 이벤트를 검출하고, 플랫폼 독립적인 API와의 호환성을 보장하면서 트리거 이벤트에 응답하여 플랫폼 의존적인 API를 업데이트한다. 일부 실시예들에서, 트리거 이벤트는 사용자 장비("UE")의 이동성, 상이한 무선 통신 시스템으로의 애플리케이션 서버의 재배치, 무선 통신 시스템의 적어도 하나의 네트워크 서비스의 서비스 API의 이용불가능성, 실제 또는 예상된 API의 높은 부하 및/또는 정체의 표시, 상이한 무선 통신 플랫폼으로의 UE의 애플리케이션 클라이언트의 재배치, 네트워크 서비스 품질 변경 표시, UE 서비스 품질 및/또는 경험 품질 변경 표시, UE 컨텍스트 변경 표시, 및 네트워크 유닛 장애 표시를 포함한다.

일 실시예에서, 적어도 하나의 플랫폼 의존적인 API로의 적어도 하나의 네트워크 서비스에 대한 적어도 하나의 서비스 API의 매핑은, 제1 방법에 의해, 적어도 하나의 서비스 API와 연관된 적어도 하나의 네트워크 서비스로부터 주기적 하트비트 메시지를 수신하는 것 및 제1 방법에 의해, 적어도 하나의 네트워크 서비스에 대한 API 인에이블먼트 서비스를 체크하는 것 중 적어도 하나에 의해 서비스 API들의 이용가능성을 결정하는 것에 기반한다.

특정 실시예들에서, 제1 방법은 관리 API의 이용가능성 상태 및 NSI에 대한 슬라이스 관리 서비스들과 관련된 능력들에 대한 요청을 관리 도메인에 전송한다. 이 요청은 미들웨어 ID, API 이름의 요청, API URI의 요청, API 버전의 요청, 데이터 포맷의 요청, 슬라이스 및 서비스 중 적어도 하나와 관련된 API 지원 특징들의 요청, 지원되는 특징들에 대한 노출 레벨 요건, API 상태 질의, API 종료 포인트들, 및 요청의 시간 유효성 중 적어도 하나를 포함한다.

일 실시예에서, 제1 방법은 다음의 파라미터들, 즉 MD ID, MnS ID, API 이름들, 유형들, 및 데이터 포맷들의 리스트, 슬라이스 및 서비스 중 적어도 하나와 관련된 API 지원 특징들, 지원되는 특징들의 노출 레벨, 및 API 상태 보고 중 적어도 하나를 포함하는 응답 메시지를 수신한다. 일 실시예에서, 제1 방법은 제어 평면 API의 이용가능성 상태 및 NSI에 대한 슬라이스 관련 제어 서비스들과 관련된 능력들에 대한 요청을 제어 평면에 전송한다. 이 요청은 미들웨어 ID, 노스바운드 API 이름의 요청, 노스바운드 URI의 요청, 노스바운드 API 버전의 요청, 데이터 포맷의 요청, 슬라이스 및 서비스 중 적어도 하나와 관련된 노스바운드 API 지원 특징들의 요청, 지원되는 특징들에 대한 노출 레벨 요건, API 상태 질의, API 종료 포인트들, 및 시간 유효성 중 적어도 하나를 포함한다.

일 실시예에서, 제1 방법은 다음의 파라미터들, 즉 NEF ID, API 이름들, 유형들, 및 데이터 포맷들의 리스트, 슬라이스 및 서비스 중 적어도 하나와 관련된 API 지원 특징들, 지원되는 특징들의 노출 레벨, 및 API 상태 보고 중 적어도 하나를 포함하는 응답 메시지를 수신한다.

일 실시예에서, 제1 방법은 E2 관련 기능 API의 이용가능성 상태 및 NSI에 대한 슬라이스 관련 제어 서비스들과 관련된 능력들에 대한 요청을 E2 관련 기능에 전송한다. 이 요청은 미들웨어 ID, xApp ID 및 rApp ID 중 하나, E2 관련 API 이름의 요청, E2 관련 URI의 요청, E2 관련 버전의 요청, 데이터 포맷의 요청, 슬라이스 및 서비스 중 적어도 하나와 관련된 E2 관련 지원 특징들의 요청, 지원되는 특징들에 대한 노출 레벨 요건, E2 관련 상태 질의, E2 관련 종료 포인트들, 및 시간 유효성을 포함한다.

일 실시예에서, 제1 방법은 다음의 파라미터들, 즉 RIC 기능 ID, API 이름들, 유형들, 및 데이터 포맷들의 리스트, 슬라이스 및 서비스 중 적어도 하나와 관련된 API 지원 특징들, 지원되는 특징들의 노출 레벨, 및 API 상태 보고 중 적어도 하나를 포함하는 응답 메시지를 수신한다.

일 실시예에서, 제1 방법은 적어도 하나의 네트워크 서비스에 대해 서비스 관리 편성자("SMO")로부터 서비스 파라미터를 요청한다. 서비스 파라미터는 적어도 하나의 네트워크 서비스의 유형 및 적어도 하나의 네트워크 서비스에 액세스하기 위한 허가 중 적어도 하나에 기반할 수 있다. 일부 실시예들에서, 제1 방법은 서비스, 슬라이스, 및 애플리케이션 유형 중 적어도 하나에 대한 적어도 하나의 네트워크 서비스의 서비스 파라미터를 포함하는 메시지를 SMO로부터 수신한다.

실시예들은 다른 특정 형태들로 실시될 수 있다. 설명되는 실시예들은 모든 면들에서 제한적인 것이 아니라 단지 예시적인 것으로만 고려되어야 한다. 따라서, 본 발명의 범위는 전술한 설명에 의해 표시되는 것이 아니라 첨부된 청구항들에 의해 표시된다. 청구항들의 등가의 의미 및 범위 내에 속하는 모든 변경들은 그 범위 내에 포함되어야 한다.

Claims

방법으로서,
무선 통신 시스템의 적어도 하나의 네트워크 서비스의 서비스 파라미터를 수신하는 단계 - 상기 무선 통신 시스템은 하나 이상의 플랫폼을 포함함 -; 및
상기 무선 통신 시스템의 상기 적어도 하나의 네트워크 서비스의 상기 서비스 파라미터에 기반하여 플랫폼 독립적인 애플리케이션 프로그래밍 인터페이스(platform-independent application programming interface)("API")를 결정하는 단계
를 포함하는, 방법.
제1항에 있어서,
상이한 무선 통신 시스템들에 걸친 최종 애플리케이션들에 의한 이용을 위해 상기 플랫폼 독립적인 API를 API 호출자에게 공개하는 단계를 더 포함하는, 방법.
제1항에 있어서,
적어도 하나의 서비스 API를 호출하기 위한 액세스를 얻기 위해 상기 적어도 하나의 네트워크 서비스에 등록하는 단계를 더 포함하는, 방법.
제1항에 있어서,
적어도 하나의 플랫폼 의존적인 API로의 매핑에 기반하여 상기 플랫폼 독립적인 API를 결정하는 단계를 더 포함하는, 방법.
제4항에 있어서,
상기 플랫폼 의존적인 API와 연관된 트리거 이벤트를 검출하는 단계; 및
상기 플랫폼 독립적인 API와의 호환성을 보장하면서 상기 트리거 이벤트에 응답하여 상기 플랫폼 의존적인 API를 업데이트하는 단계
를 더 포함하는, 방법.
제5항에 있어서,
상기 트리거 이벤트는,
사용자 장비("UE")의 이동성;
상이한 무선 통신 시스템으로의 애플리케이션 서버의 재배치;
상기 무선 통신 시스템의 상기 적어도 하나의 네트워크 서비스의 서비스 API의 이용불가능성;
실제 또는 예상된 API의 높은 부하 및/또는 정체의 표시;
상이한 무선 통신 플랫폼으로의 상기 UE의 애플리케이션 클라이언트의 재배치;
네트워크 서비스 품질 변경 표시;
UE 서비스 품질 및/또는 경험 품질 변경 표시;
UE 컨텍스트 변경 표시; 및
네트워크 유닛 장애 표시
를 포함하는 그룹으로부터 선택되는, 방법.
제4항에 있어서,
상기 적어도 하나의 플랫폼 의존적인 API로의 상기 적어도 하나의 네트워크 서비스에 대한 적어도 하나의 서비스 API의 매핑은,
상기 적어도 하나의 서비스 API와 연관된 상기 적어도 하나의 네트워크 서비스로부터 주기적 하트비트 메시지(periodic heartbeat message)를 수신하는 단계; 및
상기 적어도 하나의 네트워크 서비스에 대한 API 인에이블먼트 서비스를 체크하는 단계
중 적어도 하나에 의해 상기 서비스 API들의 이용가능성을 결정하는 것에 기반하는, 방법.
제4항에 있어서,
상기 적어도 하나의 네트워크 서비스의 상기 서비스 파라미터는 상기 무선 통신 시스템의 버티컬 고객(vertical customer)의 네트워크 슬라이스 인스턴스("NSI")에 대한 것이고;
상기 플랫폼 의존적인 API는 상기 버티컬 고객에 대해 맞춤화되는 소프트웨어 개발 키트 API를 포함하는, 방법.
제10항에 있어서,
관리 API의 이용가능성 상태 및 NSI에 대한 슬라이스 관리 서비스들과 관련된 능력들에 대한 요청을 관리 도메인에 전송하는 단계를 더 포함하고, 상기 요청은,
미들웨어 ID;
API 이름의 요청;
API URI의 요청;
API 버전의 요청;
데이터 포맷의 요청;
슬라이스 및 서비스 중 적어도 하나와 관련된 API 지원 특징들의 요청;
지원되는 특징들에 대한 노출 레벨 요건;
API 상태 질의;
API 종료 포인트들; 및
요청의 시간 유효성
중 적어도 하나를 포함하는, 방법.
제11항에 있어서,
다음의 파라미터들, 즉
MD ID;
MnS ID;
API 이름들, 유형들, 및 데이터 포맷들의 리스트;
슬라이스 및 서비스 중 적어도 하나와 관련된 API 지원 특징들;
지원되는 특징들의 노출 레벨; 및
API 상태 보고
중 적어도 하나를 포함하는 응답 메시지를 수신하는 단계를 더 포함하는, 방법.
제10항에 있어서,
제어 평면 API의 이용가능성 상태 및 NSI에 대한 슬라이스 관련 제어 서비스들과 관련된 능력들에 대한 요청을 제어 평면에 전송하는 단계를 더 포함하고, 상기 요청은,
미들웨어 ID;
노스바운드(Northbound) API 이름의 요청;
노스바운드 URI의 요청;
노스바운드 API 버전의 요청;
데이터 포맷의 요청;
슬라이스 및 서비스 중 적어도 하나와 관련된 노스바운드 API 지원 특징들의 요청;
지원되는 특징들에 대한 노출 레벨 요건;
API 상태 질의;
API 종료 포인트들; 및
시간 유효성
중 적어도 하나를 포함하는, 방법.
제13항에 있어서,
다음의 파라미터들, 즉
NEF ID;
API 이름들, 유형들, 및 데이터 포맷들의 리스트;
슬라이스 및 서비스 중 적어도 하나와 관련된 API 지원 특징들;
지원되는 특징들의 노출 레벨; 및
API 상태 보고
중 적어도 하나를 포함하는 응답 메시지를 수신하는 단계를 더 포함하는, 방법.
제10항에 있어서,
E2 관련 기능 API의 이용가능성 상태 및 NSI에 대한 슬라이스 관련 제어 서비스들과 관련된 능력들에 대한 요청을 E2 관련 기능에 전송하는 단계를 더 포함하고, 상기 요청은,
미들웨어 ID, xApp ID, 및 rApp ID 중 하나;
E2 관련 API 이름의 요청;
E2 관련 URI의 요청;
E2 관련 버전의 요청;
데이터 포맷의 요청;
슬라이스 및 서비스 중 적어도 하나와 관련된 E2 관련 지원 특징들의 요청;
지원되는 특징들에 대한 노출 레벨 요건;
E2 관련 상태 질의;
E2 관련 종료 포인트들; 및
시간 유효성
중 적어도 하나를 포함하는, 방법.
제15항에 있어서,
다음의 파라미터들, 즉
RIC 기능 ID;
API 이름들, 유형들, 및 데이터 포맷들의 리스트;
슬라이스 및 서비스 중 적어도 하나와 관련된 API 지원 특징들;
지원되는 특징들의 노출 레벨; 및
API 상태 보고
중 적어도 하나를 포함하는 응답 메시지를 수신하는 단계를 더 포함하는, 방법.
제10항에 있어서,
상기 적어도 하나의 플랫폼 의존적인 API로의 적어도 하나의 NSI에 대한 적어도 하나의 서비스 API의 매핑은 상기 적어도 하나의 네트워크 서비스의 상기 서비스 파라미터를 상기 NSI에 대한 적어도 하나의 능력 파라미터와 매칭시킴으로써 행해지는, 방법.
제10항에 있어서,
NSI에 대한 플랫폼 독립적인 API로의 상기 플랫폼 의존적인 API의 매핑은 플랫폼 독립적인 API 이름/식별, 인클로징된 서비스 API 이름들, URI들, API 버전들, 프로토콜 정보, API마다의 종료 포인트들, API 유형들, 통신 방법들, 및 시간 유효성 중 적어도 하나를 포함하는, 방법.
제4항에 있어서,
상기 적어도 하나의 네트워크 서비스에 대해 서비스 관리 편성자("SMO")로부터 상기 서비스 파라미터를 요청하는 단계 - 상기 서비스 파라미터는 상기 적어도 하나의 네트워크 서비스의 유형 및 상기 적어도 하나의 네트워크 서비스에 액세스하기 위한 허가 중 적어도 하나에 기반함 -; 및
서비스, 슬라이스 및 애플리케이션 유형 중 적어도 하나에 대한 상기 적어도 하나의 네트워크 서비스의 상기 서비스 파라미터를 포함하는 메시지를 상기 SMO로부터 수신하는 단계
를 더 포함하는, 방법.
제17항에 있어서,
상기 적어도 하나의 네트워크 서비스에 대한 플랫폼 독립적인 API로의 상기 플랫폼 의존적인 API의 매핑은 상기 API를 간소화하기 위한 전체 복잡성/레이턴시에 대한 영향, 프로토콜 레벨 영향들, 휴대성에 대한 애플리케이션 요건들, 노출 능력들에 대한 슬라이스 관련 요건들, 네트워크 기능의 유형에 관련된 보안 양태들, 최종 애플리케이션의 능력들, 서비스들 간의 의존성들, 및 서비스 레벨 협약("SLA") 중 적어도 하나를 포함하는, 방법.
제1항에 있어서,
상기 서비스 파라미터는 상기 네트워크 서비스에 대한 노출 레벨, 상기 네트워크 서비스의 액세스가능성, 및 상기 네트워크 서비스의 이용가능성 중 적어도 하나를 포함하는, 방법.
장치로서,
트랜시버; 및
프로세서
를 포함하며, 상기 트랜시버는 무선 통신 시스템의 적어도 하나의 네트워크 서비스의 서비스 파라미터를 수신하고, 상기 무선 통신 시스템은 하나 이상의 플랫폼을 포함하고;
상기 프로세서는 상기 무선 통신 시스템의 상기 적어도 하나의 네트워크 서비스의 상기 서비스 파라미터에 기반하여 플랫폼 독립적인 애플리케이션 프로그래밍 인터페이스("API")를 결정하는, 장치.