Mobile Access Edge Computing (MEC) - 3GPP

 이번 글에서 다룰 내용은 5G에서 중요한 위치를 차지하고 있는 Mobile Access Edge Computing (MEC)다. 한 마디로 쉽게 설명하면, '단말에서 Server로 서비스를 요청하는 Cloud Computing의 개념에서 Server를 User의 가까운 곳에 전지 배치시키겠다'는 내용이다. 한국의 무선의 RAN에서 아무리 ms 단위로 자원을 할당해도, 이를 미국의 Server로 보내는 유선 구간에서의 Delay가 커지면 무용지물일 것이다. 따라서, UE의 가까운 곳에도 Server를 배치할 필요가 있게 되었고, 이를 통신사업자망에 어떻게 효율적으로 붙일지에 대한 논의가 3GPP에서도 이루어지고 있다.

 앞서 소개한 바에서 볼 수 있듯이, MEC는 다른 글들에서 다뤘던 Radio Access Network (RAN) 관련 기술보다는 Application에 가까운 내용이다. 그래서 3GPP 표준에서도 RAN Working Group 보다 Service & System Aspects (SA) Working Group에서 논의가 이루어지고 있다. 5G 초기부터 논의가 시작되었고, 많은 Technical Specification (TS), Technical Report (TR)과 기고문 등이 있다. 그 중, 이번 글에서는 MEC의 전반적인 구조를 알 수 있으면서도, 따끈따끈하게 업데이트되고 있는 Release 17에 속해있는 TS 23.558에 대해 소개하려고 한다. 양이 많기 때문에, 개인적으로 중요하다고 생각하는 포인트만 간략하게 정리할 예정이며, 원문은 구글링을 하면 바로 볼 수 있다.

 

Technical Specification 23.558 [1]

 Title: Architecture for enabling Edge Computing (Release 17)

 Date: June, 2021

 Version: 17.0.0

 

MEC의 구조

 MEC의 전체적인 구조는 UE - RAN - Core - Edge Data Network (EDN)으로 이어지고 있다. 다음 그림과 같은 큰 구조를 갖고 있으며, 각 Entity마다 맡은 일이 있고, 각 Entity간의 정보 교환을 위해 Edge-x 등의 Interface가 정의되어 있다. 조금 더 깊게 각 Entity와 Interface에 대해 알아보기로 한다.

Architecture of Enabling Edge Computing - Refence Point [1]

 Application Client (AC)는 실제로 Data를 요청하는 User라고 생가하면 되고, 이와 연결되어 있는 곳이 Edge Application Server (EAS)다. 실제로 Data를 주고 받는 Entity이기에 중요한 부분이지만, 이와 연결되어 있는 Enabler에서 EAS-AC가 데이터를 주고 받을 수 있게 Control 정보들이 오고간다. 즉 AC와 연결된 Edge Enabler Client (EEC)와 EAS와 연결된 Edge Enabler Server (EES)가 Control에 필요한 정보들을 주고 받게 되는데, 이 Interface가 Edge-1이다. 이 Architecture그림을 보고 든 생각은 '왜 EAS와 AC가 Control 정보를 직접 주고 받지않고, EES나 ECS같이 정보를 주고받는 Entity를 따고 뽑아놨을까?'였다. 이 부분에 대한 확실한 대답은 내릴 수 없었지만, 각자의 최소 역할을 분리해놓은게 아닐까 싶다. EDN안에 EES와 여러 EAS가 존재할 수 있다는 점으로 볼 때, 1개 EES가 여러 EAS의 관리를 하고 EEC와의 효율적인 통신을 담당하는 Manager고, EES끼리도 Interface가 있다. ECS는 그렇게 구성된 EDN 들을 관리하고 EEC가 EES에 붙을 수 있게 도와주는 역할이다.

 기본적으로 Edge Computing에서 사용되는 Interface는 Service-based Interface이기 때문에, 정보가 필요할 때 Request하고, 이를 Provision하는 방식으로 이루어진다. 대부분의 Edge-x 라고 쓰여있는 Interface를 보면, 필요한 Configuration을 주고 받는다고 되어있고, 가끔 EEC가 EAS를 Register, Discovery할 수 있게 한다는 내용들이 쓰여있다. UE가 어떤 Edge Server에 붙으면 좋을지 Discovery하고 Register한다는 내용이기 때문에 이해하기에 어려운 점은 없어 보인다.

 그런데 Edge-2, 7, 8을 보면, Edge server단과 Core망과 Interface가 뚫려있고, 'SCEF/NEF로 Core망과 Interaction하거나 Mobile Network Operator (MNO)의 Trust Domain 내에서 Core망과 직접 통신할 수 있다'는 문구가 있다. 정리하면, MNO가 허락하는 한, Core망의 Network Function (e.g., Policy Control Function (PCF)) 등과 직접 정보를 주고 받을 수 있지만, 보안이나 Privacy 등의 이슈로 Direct Intract가 불가능 한 경우에는 Network Exposure Function (NEF)를 통해 Interact하라는 뜻이다. 해당 내용은 디테일한 설명은 TS 23.501 [2]에 있다. 이 후에도, 어떻게 Server를 Discovery하고, Register하는지에 대한 내용도 조금 더 나와있다.

 

MEC Procedure

 위에서는 MEC를 구성하는 Entity와 Interface들에 대해 알아봤다면, 해당 Interface를 통해 어떤 정보들이 오가는지를 알아본다. Cluase 8.2를 보면, Common Information Element (IE)에 대해 나와있는데 각 EAS, AC가 얼만큼의 Computing Resource를 갖고 있고, Memory는 얼마만큼 있으며, Bandwidth 필요 정도에 대한 내용이 IE에 들어가있다. 해당 정보를 Request하고, Provisioning하는 것들에 대한 순서들이 적혀있다. Entity와 Interface의 조합마다 소개가 되어있지만, 내용이 많은 관계로 필요한 부분은 [1]의 8장을 읽어보면 된다. 특히, Location과 Register에 대한 내용도 많이 들어있기 때문에 초반에 어떻게 시스템이 구성되고 UE가 이동함에 따라 어떻게 EAS가 바뀌고, 운영되는지에 대한 감을 잡을 수 있다. 이를 어떻게 실제 산업망에 사용하고, 최근 대두되고 있는 Private-5G와 연계해서 사용하는 방법들에 대한 Use case들은 넷매니아즈에 다양한 자료들[3]이 나와있다. 표준보다는 조금 더 알기쉽게 홍보물 느낌으로 쓰여있지만, 실제 통신망(RAN, Core)와 어떻게 물려서 사용되는지 한 눈에 보기 쉬우니, 감을 잡는데 도움이 될 것이라 생각한다.

 

Conclusion

 이번 글에서는 MEC의 대략적인 구조와 어떤 Entity, Interface가 있고, 어떤 내용들이 오고가는지에 대한 아주 큰 그림을 정리했다. 단순히 TS 23.558 [1]을 소개하는 글이기 때문에, 더 깊은 내용을 알고 싶은 사람에게는 부족한 내용일 수 있다. 하지만, 표준에서 어떻게 정의되고 있는지를 이해하고, AWS의 Wavelength 등 관련 기술 자료들을 읽으면 조금 더 도움이 될 것이라고 생각한다. 이와 관련된 여러 TS/TR들이 나오고 있기 때문에, 이 글에서 MEC 구조와 참고문헌을 보고 자신이 필요한 부분을 찾아갈 수 있을 것이라고 생각한다.

 

Reference

[1] "Architecture for enabling Edge Computing", v. 17.0.0, Release 17, 3GPP TS 23.558, 3GPP, June 2021.

[2] "System architecture for the 5G System", v. 16.6.0, Release 15, 3gpp TS 23.501, 3GPP, Oct. 2020.

[3] https://www.netmanias.com/ko/?m=view&id=oneshot&no=15104 

Verizon의 AWS Outpost 기반 On-Premise Private 5G MEC 출시