ettrends banner

박용직 (Bahg Y.J.) 기지국SW연구실 책임연구원
나지현 (Na J.H.) 기지국SW연구실 책임연구원/실장

Ⅰ. 서론

최근 이동통신 분야에서 시스템의 기능과 서비스 환경을 개방하는 기술적 동향이 활발하게 전개되고 있다. 이와 같은 경향은 인터넷 환경에서 진행되고 있는 개방형 플랫폼 구성과 유사한 접근으로 이동통신 시스템이 제공 가능한 다양한 형태의 내부 정보 또는 제어 기능들을 외부에 공개적으로 제공하는 것을 의미한다. 개방형 정합(API: application programming interface) 기술 개발이 이에 해당한다. 개방된 시스템 내부 정보와 각종 기능을 기반으로 독립적인 서비스 사업자는 기존 이동통신 사업자가 기본적으로 제공하는 서비스 이외에 새로운 서비스 또는 응용(application)들을 별도로 개발할 수 있고 이를 이동통신 가입자에게 제공하여 새로운 서비스 수요를 창출하게 된다. 이동통신 액세스 네트워크가 제공하는 정보들을 가공하여 새로운 서비스를 제공하는 MEC(multi-access edge computing) 기술이 대표적인 경우에 해당한다. 특히 가입자와 가장 인접한 액세스 네트워크가 제공하는 개방형 정합 기능을 기반으로 독립적인 서비스나 응용을 제공할 경우 5G 이동통신 기술이 추구하는 저 지연 서비스 환경 구성이 가능하여 차세대 이동통신 서비스 개발이 용이할 수 있다.

이와 같이 시스템의 서비스 환경(capability)을 개방형 정합 기능 형태로 공개하는 기술적 시도는, 과거 공중 교환 망(PSTN: public switched telephone network) 환경에서 신규 서비스 개발을 용이하게 진행하기 위한 지능 망(IN: intelligent network) 개념으로부터 시작되었다. 그리고 JAIN, TINA, CAMEL, AIN(java API integrated network, telecommunications information networking architecture, customized applications for mobile networks enhanced logic, advanced intelligent network) 등과 같이 유선 및 무선 시스템에서 서비스 개방을 지원하기 위한 발전이 수반되었다. 이러한 시도는 2세대 GSM(global system for mobile communications) 이동통신 분야에서 Parlay/OSA(open service access) 형태로 확대 적용되어 기술적 검증이 이루어졌고 최근 4세대 LTE(long term evolution) 시스템에서 점차 상업적으로 유의미한 수준의 결과를 도출하고 있다.

이와 같은 배경과 동향을 기반으로, 5G 이동통신 서비스에서 요구하는 저 지연 환경 그리고 이동통신 시스템 정보 이용의 부가 가치를 극대화할 수 있는 기술로써 차세대 이동통신 시스템의 연구 개발 과정에 나타나는 개방형 서비스 플랫폼 환경에 대한 연구 개발 진행 상황을 살펴본다.

Ⅱ. 이동통신 서비스 개방 현황

전통적으로 통신 시스템은 기본적인 서비스를 포함하고 있다. 대표적으로 과거의 PSTN, ISDN(integrated service digital network) 등과 같은 시스템이 이에 해당한다. 통신 사업자는 연결(connectivity) 기능을 제공하면서 동시에 음성 또는 데이터 서비스를 제공했다.

그러나 통신 시스템이 이동통신 또는 인터넷 등의 형태로 발전하면서 서비스의 운용과 관리 및 신규 서비스 구성의 용이성 등을 위해서 연결 기능과 독립적인 형태로 다양한 서비스들을 제공하기 위한 기술들을 개발하여 적용하고 있다. 확장된 개념으로 시스템은 연결 기능만 제공하고 이를 기반으로 가입자는 서비스 제공 사업자에 접속하여 다양한 서비스를 이용하는 단계까지도 연구 개발 및 상용화가 진행되고 있다.

이러한 형태의 서비스 제공을 위해서 시스템은 외부에서 연결 기능을 제어할 수 있는 내부 기능을 개방하고 시스템 내부 정보에 접근할 수 있도록 공개된 정합 기능을 구비해야 한다. 최근 서비스와 시스템 분야에 개방형 정합 기능을 활발하게 적용하고 있는 대표적인 사례에 MEC 및 OMA(open mobile alliance) 기반의 서비스 등이 이에 해당된다.

1. MEC

차세대 이동통신에 대한 여러 가지 요구 중에서 저 지연 서비스 특성에 대한 필요성이 강조되고 있다. 배경에는 실시간 제어 또는 모니터링 등과 같이 지연에 민감한 서비스 환경 구축의 필요성에 대한 요구로 해석된다. 이러한 실시간 기반의 서비스를 제공하기 위해서 대표적으로 이동통신 네트워크의 종단에 특정 서비스 환경을 구축하여 저 지연 서비스 특성을 제공하려는 기술적 시도가 MEC 형태로 진행되고 있다.

가입자와 가장 인접한 액세스 네트워크(RAN: radio access network)에 서비스 플랫폼을 구성하여 실시간 특성을 개선하고 트래픽의 집중을 해소하는 효과를 기대할 수 있다. MEC 플랫폼 기반의 개방형 서비스 환경에서는 MEC 기반의 서비스가 트래픽 흐름을 제어할 수 있는 API 그리고 RAN 정보 접근과 활용을 위한 API 규격을 제공하고 있다. (그림 1)에서 MEC 플랫폼과 API 그리고 RAN 연동 구조를 나타냈다[1]. MEC 플랫폼 환경 측면에서 RAN 연동을 위한 API 내용은 3GPP 시스템 개방 현황에서 기술되며 MEC 기반의 서비스와 MEC 제공 API 연동 환경은 아래와 같다.

가. RNI API

(그림 1)
MEC 플랫폼 구조

MEC 환경을 이용한 가입자 서비스와 MEC 플랫폼 사이의 개방형 API 방식에는 http 기반의 RESTful 또는 REST(representational state transfer) 형식을 적용한다. http method 절차들을 이용하여 CRUD(create, read, update, delete) 동작(operation)을 수행하고 서비스와 MEC 플랫폼 사이에서 서비스 제어가 진행된다.

REST 형식에서는 CRUD 동작과 관련된 resource name 그리고 resource URI 정보를 정의하고 있으며 현재 MEC 규격에서는 이를 반영하여 MEC 서비스용 northbound 정합을 위한 아래와 같은 resource name 기반의 API 즉, MEC 기반 서비스와 MEC 플랫폼 사이의 개방형 서비스 규격을 정의하고 있다[2].

• RAB information

• PLMN information

• S1 Bearer information

• All subscription for a subscriber

• Existing subscription

• Notification callback

각각의 서비스는 RESTful 형태로 필요한 http GET, PUT, PATCH, POST, DELETE method 절차를 수행하여 관련 정보에 접근하고 서비스를 제어한다. 예를 들면 RAB information, PLMN information 등의 서비스 관련 정보는 http GET method 절차를 이용하여 상호 교환되며 (그림 2)와 같이 처리된다.

(그림 2)
MEC RNIS 연동 절차 예제

(그림 2)에서는 MEC 플랫폼의 northbound 즉, 가입자(user) 또는 MEC 기반 서비스를 service consumer 형태로 표시하고 있다. REST/RESTful 개념과 형식 및 처리 방식에 대한 내용은 별도의 관련된 문서를 참고한다.

나. TOF API

RNI API 형태와 유사하게 RAN 트래픽을 제어하기 위한 TOF 서비스들을 아래와 같이 정의하고 있다.

• Register to Bandwidth management

• Unregister from BW management

• Update requested BW requirement on BW management

• Get configured BW allocation from BW management

그리고 필요한 http method 기반으로 RAN 트래픽 제어를 위한 서비스 관련 CRUD 절차를 수행한다.

2. OMA

개념적으로 이동통신 환경에서는 다양한 방식의 이동통신 시스템 또는 네트워크를 운용하는 사업자들이 존재할 수 있고 단말(device) 또한 복수에 제조사 제품이 사용된다. 이러한 환경에서 서비스 상호 운용 호환성을 보장하기 위한 OMA 규격이 적용되는 이동통신 서비스의 개발과 운용이 진행되고 있다. OMA 규격에서 정의하고 있는 다양한 개방형 서비스 API 형태 중에서 http 기반 RESTful 형태 API 종류들을 <표 1>에 나타냈다.

<표 1>
OMA RESTful API 기반 서비스

• RESTful client in service provider

• RESTful client in mobile & fixed device

• RESTful client in browser

그리고 API 기반 서비스를 이용하는 가입자(client) 환경을 다양하게 정의하고 있으며 이동통신 시스템 또는 네트워크 사업자가 제공하는 개방형 서비스 API 이용 주체(client)를 위와 같이 구분한다[3].

독립적인 서비스 사업자는 이동통신 시스템이 제공하는 API 또는 OMA 규격 기반의 API 연동 환경을 이용하여 다양한 정보와 제어 기능에 접근하고 필요한 내용에 대해서 OAM 규격 기반 API 환경으로 가공하여 client-server 형태로 가입자에게 부가 서비스를 제공한다. 그리고 가입자는 OMA API 방식을 이용하여 직접 시스템과 연동하여 서비스를 이용할 수 있다.

OMA RESTful API 기반의 개방형 서비스 처리 절차 중에서 단말기 위치 정보를 주기적으로 확인하기 위해 특정 단말의 위치 정보 통보 서비스를 신청한 가입자에게 관련 정보를 제공하는 경우를 (그림 3)에 나타냈다[4]. 여기서 이동통신 네트워크 및 시스템 환경을 NWSL(network operator server layer) 형태로 표현한다.

(그림 3)
OMA Terminal Location service

Ⅲ. 3GPP 5G시스템 개방 동향

이동통신 서비스를 포함하여 전반적으로 통신 서비스 시장이 음성 중심에서 데이터 즉, 인터넷 환경을 이용하는 서비스로 급격하게 변화하고 있다. 기존 단순한 통신 경로의 연결(connectivity) 기능을 이용하는 서비스 시장은 성장의 한계를 나타내고 있어 새로운 서비스 시장 또는 부가 가치를 창출할 수 있는 서비스 및 서비스 플랫폼 환경의 도입이 필요한 시점이다. 실질적으로 전 세계 대부분의 이동통신 시장을 점유하고 있는 3GPP LTE 및 5G 표준에서는 이와 같은 서비스 시장의 동향을 인지하고 새로운 서비스 환경을 제공하기 위한 표준화 작업을 진행하고 있다.

이동통신 시스템의 서비스 제어 기능 및 다양한 정보들이 외부에 공개되는 형태를 (그림 4)와 같이 OMA 표준에서 정의하고 있다[3]. 앞의 내용에서 서비스 개방과 관련하여 가장 많이 적용되고 있는 (그림 4)의 1영역에 해당된 대표적인 경우로, 가입자 및 서비스 사업자에게 서비스를 개방하기 위한 OMA 및 MEC API 표준 규격을 http 기반 RESTful 형식 중심으로 살펴보았다. 아래에서는 (그림 4)의 2영역에 해당하여 이동통신 시스템 또는 네트워크에서 서비스 사업자 또는 가입자에게 개방형 서비스 플랫폼 환경을 제공하기 위한 3GPP LTE 및 5G 중심의 표준과 기술 동향을 살펴본다.

(그림 4)
서비스 개방 방식

현재 LTE 기반의 시스템에서는 서비스 특성을 고려하여 개방형 서비스 환경이 필요한 서비스들이 각각의 기능과 정보를 개별적으로 공개하는 형태로 관련 규격들을 정의하고 있다. 즉 공통의 구조(framework)를 구축하기 이전에 독립적인 개방형 서비스 플랫폼 구조를 채택하고 있다. 그리고 최근 차세대 5G 규격에 관한 논의를 시작하면서 다양한 서비스들이 개별적으로 서비스 환경을 개방하는 방식에 대한 문제점을 검토하여 이를 보완하기 위해서 공통(common) 개방형 서비스 플랫폼과 API 방식에 대한 연구를 시작했다[5].

1. IoT Related Exposure Functions

3GPP 표준에서는 다양한 서비스 제어 기능 및 관련 정보들을 외부에 공개하기 위한 작업을 개별적으로 진행하여 IoT 서비스를 위한 독립적인 서비스 플랫폼 구조를 정의했다. 현재 LTE 차원의 IoT 서비스 개방을 위해서 통합 플랫폼 환경을 정의하는 SCEF(service capability exposure function) 방식에 대한 연구 개발을 진행하고 있다[6].

SCEF 환경은 주로 non IP 형태의 IoT 정보를 처리하기 위한 다양한 연동 환경을 제공하고 있다. 대표적 서비스 개방 환경은 MTC-IWF(interworking function), MBMS(multimedia broadcast multicasting service), PCRF(policy and charging rules function) 제어용 SCEF & AF(service capability exposure function & application function), PFDF(packet flow description function) 관련 SCEF, 그리고 RCAF(RAN congestion awareness function), SCEF 기반 MTC 서비스 SCA & AS(service capability server & application server) 등이 이에 해당한다.

LTE 기반의 IoT 서비스 제공을 주된 목표로 관련 기능들의 개방형 API 방식과 이들을 통합 관리하기 위한 SCEF 기능의 API 방식을 (그림 5)에 나타냈다. IoT 서비스를 위한 몇 가지 네트워크 기능들의 SCEF 연동 방식은 아래와 같다.

가. PCRF Interface

(그림 5)
3GPP SCEF

이동통신 시스템 운용 관련 제어가 수행되는 PCRF 기능을 공개하는 정합 규격으로 SCEF 기능을 경유하여 외부의 서비스 플랫폼 환경 또는 직접적으로 외부 응용 프로그램(AF: application function)과 연동한다. 3GPP 규격에서는 Nt 정합으로 정의하고 있으며 현재는 Diameter 프로토콜을 적용한다[7].

SCEF 기능을 경유하는 방식 이외에 직접 응용 프로그램과 연동하기 위해서 PC(protocol converter) 기능을 이용하여 AF 기능과 연동하는 경우는 http RESTful 기반의 REST-Rx 형식으로 정의하고 있다[8]. SCEF 및 PC 외부 즉, 3GPP 시스템 외부와의 정합은 http 기반 RESTful 형식을 적용한다.

나. PFDF Interface

PFDF(packet flow description function) 기능은 3GPP LTE 네트워크의 트래픽 처리 및 운용과 관련된 데이터 패킷의 흐름 제어 기능에 해당한다. PFDF 기능은 PCEF(policy & charging enforcement function) 그리고 TDF(traffic detection function) 기능과 연동하여 가입자 트래픽 처리와 관련된 제어 기능을 수행한다.

3GPP 규격에서는 Nu 정합 형태로 정의하며 http method 기반 JSON(java script object notation) 방식으로 SCEF 기능을 경유하여 시스템에 접근하고 필요한 정보를 교환한다[10].

다. RACF Interface

액세스 네트워크(RAN: radio access network)의 정보를 수집하여 SCEF 기능으로 제공하는 RCAF 정합 규격에서 Diameter 기반의 Ns 형태로 정의하고 있다[9]. 일반적으로 UP(user plane) 부하 상태(level) 및 이와 관련된 ECGI(E-UTRAN Cell Global Identifier), eNB-ID, SAI(service area identification) 정보에 대한 접근을 허용한다.

라. SCS/AS Interface

IoT 서비스를 위해서 backward comparability 지원 차원에서 진행된 내용에 해당한다. AS/SCS 환경에서 직접 LTE 시스템의 정보 또는 서비스에 접근할 수 있는 환경을 제공하는 것으로 2세대 이동통신이 도입한 서비스 개방 방식 OSA/Parlay 플랫폼을 경유하여 3GPP 시스템 접근이 가능하도록 SCEF 기능과 연동하는 규격들을 정의한다[11]. OSA 기반 AS(application server) 기능이 기존 OSA API 규격을 이용하여 개방형 서비스 플랫폼 SCS 기능에 접근하고 SCS 기능은 다시 T8 정합 형태로 SCEF 기능과 연동하여 3GPP 네트워크의 개방형 서비스 환경과 필요한 정보 또는 제어 기능에 접근한다. OSA API 방식은 관련된 규격들을 참고한다[12].

AS/SCS 플랫폼은 3GPP T8 규격을 이용해서 연동하는 경우와 독립적인 별도의 non-3GPP 정합 규격(tbd)을 이용할 수 있다.

마. MTC-IWF Interface

MTC 서비스 제공을 위한 규격으로 MTC-IWF 기능과 기존 SCS 기능 사이에 Tsp 규격을 적용하여 외부 AS 기능이 MTC-IWF 기능과 연동한다. 이러한 연동 방식은 LTE 시스템 내부 관점에서 non IP 형태 MTC 정보들을 CP(control plane) 경로를 이용하여 전달하기 위한 구조를 의미한다.

참고로 IP 패킷 형태로 구성되는 MTC 관련 정보는 P-GW/GGSN(PDN gateway/gateway GPRS support node), S-GW/SGSN(serving gateway/serving GPRS support node), MME(mobility management entity) 기능이 통합된 C-SGN(CIoT Serving Gateway Node) 기능을 이용하여 UP(user plane) 경로로 네트워크와 연동한다. 현재 Tsp API 방식은 Diameter 프로토콜 규격을 적용한다.

개념적으로 MTC-IWF 기능이 SCEF 기능과 유사하게 MTC 연동을 위한 환경을 AS/SCS 기능에 개방하기 때문에 통합 플랫폼 SCEF 기능과 같은 물리적 환경을 공유할 수 있다[13].

바. MBMS Interface

IoT 서비스와 직접적인 연관성은 부족하지만, IoT 서비스에서 이용하는 개방형 API 환경 SCEF 기능을 적용한 콘텐츠 사업자와 LTE 네트워크의 방송 서비스 기능 사이의 연동과 관련되어 있다. MBMS 서비스 환경에서 BM-SC(broadcast multicast service center) 기능은 서비스 콘텐츠를 이용하기 위해서 콘텐츠 사업자의 플랫폼 환경에 접근이 필요하고 이 경우에 콘텐츠 플랫폼 내부의 SCEF 기능과 공개된 API 방식으로 연동한다[14]. API 프로토콜은 SOAP, HTTP, Diameter 등등 여러 가지 방식을 검토한 결과 http 기반 RESTful 형태의 프로토콜을 적용했다.

앞에서 살펴본 바와 같이 3GPP LTE 시스템은 IoT 서비스 제공을 위해서 관련된 네트워크 기능들이 각각 다양한 형태의 정합 방식을 적용하여 상호 연동한다. IoT 서비스 환경의 SCEF 기능을 포함한 주요한 일부 기능 및 정합 규격 그리고 외부의 서비스 플랫폼 사이의 연동 관계를 <표 2>에 간단하게 나타냈다.

<표 2>
SCEF 연동 주요 기능 및 API

사. Other Interfaces

SCEF 기능과 직접 연동되는 LTE 네트워크 기능 이외에 HSS, MME, SGSN/S-GW, GGSN/P-GW, C-SGN, MTC-AAA, IWK-SCEF 등의 기능들이 IoT 서비스를 제공하기 위해서 다른 네트워크 기능과 연동한다. 이와 관련된 세부적인 정합 방식은 현재 3GPP 표준화 과정에서 진행되고 있는 규격을 참고한다[15],[16].

AS/SCS API 방식을 제외하고 앞에서 살펴본 내용은 LTE 네트워크의 내부 기능들이 SCEF 기능과 연동하기 위한 정합 방식과 관련 규격들을 포함한다. 한편, SCEF 외부 northbound API 방식은 현재 3GPP 표준의 범위 이외로 정의하여 OMA 서비스 연동 관련 규격이 적용되는 부분에 해당한다.

2. CAPIF & NEF

최근 중요하게 대두되고 있는 IoT 서비스를 위해서 도입한 SCEF 기능은 제한적이지만 공통의 개방형 API 플랫폼 환경을 제공하기 위해서 LTE 네트워크 기능으로 채택되었다.

이러한 시도는 현재 논의되고 있는 3GPP 5G 이동통신 표준 관련하여 시스템 차원의 공통 개방형 API 환경을 시스템 구조 차원에서 반영하는 결과를 유도하게 되었고 최종적으로 LTE SCEF 기능에 대응하는 5G 시스템을 위한 service based NEF(network exposure function) 기능을 하나의 독립적인 네트워크 기능으로 구성했다. 그리고 NEF 기능이 외부의 서비스 사업자 또는 가입자와 연동하여 시스템 정보를 이용하거나 트래픽을 제어하는 공통의 개방 플랫폼 환경(framework)에 대한 연구를 진행하게 되었다. 그 결과 최근 3GPP 표준에서는 5G 시스템 구조가 채택한 NEF 기능을 기반으로 공통의 개방형 서비스 플랫폼을 구성하는 환경으로써 CAPIF(common API framework) 관련된 표준화를 추진하여 상위 규격을 정의했다[5].

(그림 6)에서 세부적인 CAPIF 구조를 나타냈다. 5G 네트워크 내부에서 API provider function 즉, service based NEF 기능은 다양한 기능들과 연동하여 필요한 정보 또는 트래픽 제어에 접근하는 southbound 경로를 구성한다. 그리고 NEF northbound API 경로를 이용하여 외부 서비스 사업자 또는 가입자에게 시스템의 정보 및 트래픽 제어 기능을 개방한다. CAPIF-1 또는 CAPIF-1e 방식 API 연동을 이용하는 API invoker 형태의 서비스는 service based NEF 기능의 제공 가능한 서비스 범위를 파악하고 CAPIF-2 또는 CAPIF-2e 방식의 API 연동을 이용하여 서비스가 요구하는 트래픽 제어 또는 시스템 정보 접근 관련 절차를 수행하거나 시스템으로부터 제공받는다. 이를 위해서 CAPIF 환경은 API provider function 형태의 NEF 기능과 연동하는 CAPIF 제어 기능(core function)을 구성한다.

가. CAPIF

3GPP 5G 네트워크의 service based NEF 기반 공통 개방형 서비스 플랫폼 CAPIF 환경(framework)에서는 외부의 서비스 또는 서비스 사업자 그리고 시스템 내부 서비스 형태 API invoker 기능과 연동하는 northbound API 규격을 개발하고 있다[17]. 이를 위해서 CAPIF core function 그리고 API provider function 등을 정의하고 있다.

CAPIF core function 기능은 내부 기능들과 연동하는 CAPIF-3/4/5 정합 방식을 기반으로 API provider function 기능이 제공하는 CAPIF 환경 관련 정보들을 API invoker 형태의 서비스 또는 서비스 사업자에게 제공한다. 세부적인 기능은 아래와 같다.

• API invoker authentication & authorization

• service API information publishing, storing, discovering

• service API access controlling

• service API log providing & storing

• service API charging, monitoring, auditing

• API invoker onboarding

CAPIF 환경과 서비스 사업자 또는 가입자 사이의 연동을 지원하는 northbound API 정합은 아래와 같은 API provider function 및 세부 기능들이 지원한다.

• API publishing function

• service API information publishing

• API exposing function

• API invoker authorization & authentication validation, API invocation logging, service API provisioning

• API maintenance function : service API invocation log auditing, API event monitoring, API policy configuration, API lifecycle management, API invoker onboarding

CAPIF 구조는 주요한 API exposing function 구성 형태에 따라서 중앙 집중 또는 분산 형태로 구분된다. CAPIF 제어 기능(core function)이 독립적으로 동작하거나 API provider function 기능에 포함된 API exposing function 기능과 동일한 환경에서 동작하는 경우에 따라서 상이한 구조를 가지게 된다. 이와 같은 방식을 (그림 7)에 나타냈다.

(그림 7)
CAPIF deployment

API exposing function 구축 방식에 따라서 CAPIF 분산 구조의 경우에는 종속적 구성(cascading) 형태가 가능하다.

나. NEF & Use Case

3GPP 5G 시스템의 service based 구조에서 정의된 기능이다. 또한, CAPIF 환경 관점에서는 API provider function 대응 기능에 해당한다. 5G 네트워크의 서비스 및 서비스 능력을 안전하게 시스템 내부 또는 외부로 공개하는 service based NEF 기능으로써 대표적으로 서비스 이용 또는 이동성 등과 관련된 정보들을 제공하거나 접근을 제공할 수 있다[18]. 그리고 시스템 외부 또는 내부의 다른 기능들이 설정한 정보에 접근하고 필요한 경우 다른 내부 또는 외부 기능으로 제공한다.

CAPIF 환경에서 API provider function 즉, service based NEF 기능과 northbound API 기능을 이용한 개념적인 5G 시스템의 서비스 관련 정보 개방 형태를 (그림 8) 예제에서 기술했다. 3GPP 5G 네트워크에서 가입자 트래픽을 처리하는 SMF 기능이 트래픽을 처리하는 PDU session 처리 과정 중에 발생하는 다양한 event 정보들을 northbound CAPIF-2/2e 정합을 이용하여 서비스 형태로 제공하는 경우에 대한 논리적인 절차를 (그림 8)에 나타냈다[19].

(그림 8)
SMF session event exposure

API invoker 형태의 외부 서비스 또는 서비스 사업자 그리고 시스템 내부의 서비스가 요청한 session event 정보에서 상태 변화가 발생하는 경우 NEF 기능을 경유하여 요청한 내부 기능 또는 외부 서비스에 관련 정보를 전달한다.

Ⅳ. 결론

IT 산업은 가까운 과거에 회선 교환 서비스 시장이 급격하게 축소되는 상황을 경험했다. 배경은 통신 시스템 및 서비스가 부가 가치와 신규 시장을 창출하지 못하고 ‘dumb pipe’ 역할을 수행한 것에 기인했기 때문이다. 이러한 상황은 유선 통신 서비스 시장에서도 전개되었지만, 대표적인 계기는 애플의 생태계가 서비스 시장에서 영향력을 극대화하면서 더욱더 부각되기 시작했다. 결과적으로 경제적 효과가 네트워크 또는 시스템 사업자에게 나타나는 것이 아니고 가입자와 서비스 사업자 즉, E2E 영역에서 급속하게 증가하게 되었다.

최근 3GPP LTE 시스템에서는 IoT 서비스를 제공하는 서비스 플랫폼을 OSA 개념의 SCS 환경에 개방하는 규격을 제정했다. 유사하게 5G 이동통신에서 서비스 사업자 또는 가입자가 시스템에 접근하는 API 환경을 복수 서비스가 공통으로 이용하기 위한 환경(framework) 개발이 진행되고 있다. 기존 LTE SCEF 개념을 확장하여 5G CAPIF 환경에서는 northbound 부분에 대한 표준 방식을 적용하고 있다. 따라서 다양한 서비스 개방 환경이 공통으로 관리되는 장점과 외부로부터의 접근이 용이한 환경 구축이 가능하다.

개방형 서비스 플랫폼 환경은 단순하게 경로 연결(connectivity) 서비스가 제공되는 네트워크를 다양한 신규 서비스 시장 또는 부가 가치를 창출할 수 있는 서비스 환경으로 변화시키는 중요한 역할을 수행할 것으로 예상한다. 이동통신 네트워크나 시스템이 보유하는 방대한 수준의 정보를 적극적으로 그리고 효과적으로 활용하기 위한 시도가 시작된 것이다. 이러한 상황을 일부에서는 빅 데이터(big data) 시장으로 표현하고 또 다른 측면에서 액세스 네트워크와 연동하는 MEC 또는 fog computing 서비스로도 정의한다.

즉, 5G 이동통신 네트워크의 정보 또는 제어 과정에 서비스 사업자 또는 이동통신 사업자가 접근하여 필요한 새로운 개념의 서비스를 개발할 수 있는 서비스 플랫폼 환경을 구성하고 이를 개방하는 새로운 패러다임으로 이동통신 서비스 환경이 이동하고 있다. 이와 같은 변화는 궁극적으로 기존 가입자 경험(UX, user experience) 중심 서비스에서 가입자 행동(UB, user behavior) 기반의 서비스로 확대되어 새로운 경제적 이득을 창출하는 플랫폼 비즈니스를 지향하게 된다.

4G LTE SCEF 개방형 서비스 플랫폼에서 시작하여 northbound API 부분에 대한 표준을 채택한 5G NEF 기반의 CAPIF 환경은 발전된 차세대 서비스 플랫폼 비즈니스 측면에서 주요한 역할을 수행할 것으로 기대된다.

용어해설

Internet of things (IoT)다양한 정보를 수집하는 장치 사이의 연결이 인터넷을 이용하여 실시간으로 제공하는 서비스 또는 네트워크

Long Term Evolution (LTE)초고속 대용량 무선 인터넷 서비스를 제공하는 4세대 이동통신 시스템 또는 네트워크

5th Generation (5G)대규모 장치 연결(mMTC), 초고속 대용량(eMBB), 저지연 실시간(URLLC), 서비스 특성을 지원하는 차세대 이동통신

약어 정리

API

Application Programming Interface

BM-SC

Broadcast Multicast Service Center

CAPIF

Common API Framework

CIoT

Cellular Internet of Things

CRUD

Create, Read, Update, Delete

C-SGN

CIoT Serving Gateway Node

ECGI

E-UTRAN Cell Global Identifier

EMBB

Enhanced Mobile Broad Band

HTTP

Hyper Text Transfer Protocol

IoT

Internet of Things

JSON

Java Script Object Notation

LTE

Long Term Evolution

MEC

Multi-access Edge Computing

MMTC

Massive Machine Type Communications

NEF

Network Exposure Function

OMA

Open Mobile Alliance

OSA

Open Service Access

PCRF

Policy and Charging Rules Function

PFDF

Packet Flow Description Function

RAN

Radio Access Network

RCAF

RAN Congestion Awareness Function

REST

REpresentational Sate Transfer

RNI

Radio Network Information

SAI

Service Area Identification

SCEF

Service Capability Exposure Function

SCS

Service Capability Server

SOAP

Simple Object Access Protocol

URLLC

Ultra-Reliable Low Latency Communications

References

[1] ETSI, “Mobile-Edge Computing,” ETSI Mobile-Edge Computing-Introductory Technical White Paper Issue 1, Sept. 2014.
[2] ETSI, “MEC; Radio Network Information API,” ETSI GS MEC 012 V1.1.1, July 2017.
[3] OMA, “Common Definitions for RESTful Network APIs,” OMA Candidate Version 1.0, Apr. 17, 2012.
[4] OMA, “RESTful Network API for Terminal Location,” OMA Approved Version 1.0.1, Oct. 29, 2015.
[5] 3GPP, “Study on Common API Framework for 3GPP Northbound APIs,” 3GPP TR 23.722 V1.1.0, Oct. 2017.
[6] 3GPP, “Architecture Enhancement for Service Capability Exposure,” 3GPP TR 23.708 V13.0.0, June 2015.
[7] 3GPP, “Service capability Exposure Functionality over Nt Reference Point,” 3GPP TS 29.154 V14.1.0, Mar. 2017.
[8] 3GPP, “Representational State Transfer (REST) Reference Point between Application Function (AF) and Protocol Con-verter (PC),” 3GPP TS 29.201 V15.0.0, Sept. 2017.
[9] 3GPP, “Nu Reference Point between SCEF and PFDF for Sponsored Data Connectivity,” 3GPP TS 29.250 V14.1, Sept. 2017.
[10] 3GPP, “Service Capability Exposure Functionality Over Ns Reference Point,” 3GPP TS 29.153 V15.0, June 2017.
[11] 3GPP, “T8 Reference Point for Northbound APIs,” 3GPP TS 29.122 V9.0.0, Oct. 2017.
[12] 3GPP, “Open Service Access (OSA) Application Programming Interface (API); Part 1: overview,” 3GPP TS 29.198-1 V0.3.0, Dec. 2009.
[13] 3GPP, “Architecture Enhancement to Facilitate Communica-tions with Packet Data Networks and Applications,” 3GPP TS 23.682 V15.2.0, Sept. 2017.
[14] 3GPP, “MBMS Extensions for Provisioning and Content Ingestion,” 3GPP TS 26.981 V14.0.0, Mar. 2017.
[15] 3GPP, “Home Subscriber Server (HSS) Diameter Interface for Interworking with Packet Data Networks and Applications,” 3GPP TS 29.336 V15.0.0, Sept. 2017.
[16] 3GPP, “Mobility Management Entity (MME) and Serving GPRS Support Node (SGSN) Interfaces for Interworking with Packet Data Networks and Applications,” 3GPP TS 29.128 V15.0.0, Sept. 2017.
[17] 3GPP, “Common API Framework for 3GPP Northbound APIs,” 3GPP TS 23.222 V0.1.0, Oct. 2017.
[18] 3GPP, “System Architecture for the 5G System,” 3GPP TS 23.501 V0.1.0, Nov. 2017.
[19] 3GPP, “5G System; Session Management Event Exposure Service,” 3GPP TS 29.508 V0.1.0, Sept. 2017.

(그림 1)

f001

MEC 플랫폼 구조

(그림 2)

f002

MEC RNIS 연동 절차 예제

<표 1>

t001

OMA RESTful API 기반 서비스

(그림 3)

f003

OMA Terminal Location service

(그림 4)

f004

서비스 개방 방식

(그림 5)

f005

3GPP SCEF

<표 2>

t002

SCEF 연동 주요 기능 및 API

(그림 6)

f006

CAPIF

(그림 7)

f007

CAPIF deployment

(그림 8)

f008

SMF session event exposure