KR102377791B1 - 네트워크 내 복수의 네트워크 구간 별로 양방향의 진단을 수행하는 진단 시스템 - Google Patents

Abstract

사용자 단말, 기지국, 엣지 클라우드(Edge Cloud), 및 센터 클라우드(Center Cloud)를 포함하는 네트워크를 진단하는 진단 시스템이 개시된다. 본 진단 시스템은, 사용자 단말, 기지국, 엣지 클라우드, 및 센터 클라우드 각각에 구비되고, 하나 이상의 소프트웨어 진단 에이전트와 연동된, 컨트롤 클라이언트, 소프트웨어 진단 에이전트의 진단 시나리오를 설정하는, 분석 서버를 포함한다. 소프트웨어 진단 에이전트는, 사용자 단말, 기지국, 엣지 클라우드, 및 센터 클라우드 간의 연결 관계에 따라 구분된 복수의 네트워크 구간 별로, 진단 정보를 생성한다.

Description

네트워크 내 복수의 네트워크 구간 별로 양방향의 진단을 수행하는 진단 시스템 { DIAGNOSTIC SYSTEM FOR PERFORMING BI-DIRECTIONAL DIAGNOSTICS FOR EACH OF PLURALITY OF NETWORK SECTIONS WITHIN NETWORK }

본 개시는 5G 및/또는 LTE 네트워크의 진단 시스템에 관한 것으로, 보다 상세하게는, 네트워크 환경을 복수의 네트워크 구간으로 구분하여 양방향의 진단을 수행하는 네트워크 진단 시스템에 관한 것이다.

5G 네트워크에서 통신 단말을 이용한 서비스는 통신 단말 간의 서비스와 통신 단말과 서비스 서버 간의 연동을 통하여 사용자에게 제공된다. 5G 네트워크에서 통신 단말 간의 서비스(음성통화/영상통화/메시지 등) 패킷은 통신 단말-5G 기지국-UPF-5G 기지국-통신 단말을 통하여 구성된 링크 패스를 통하여 전달되며, MEC(Mobile Edge Computing) 내에 구성된 서비스 서버로부터 제공되는 서비스(게임/영상스트리밍/IoT 데이터/5G 특화서비스) 패킷은 통신 단말기 또는 엔드노드-5G 기지국-Edge Cloud-MEC-타킷 서비스 서버를 통하여 구성된 링크 패스를 통하여 전달된다. 또한 5G네트워크와 LTE네트워크가 연계된 서비스 패킷은 5G 네트워크와 LTE 네트워크가 연동된 링크 패스를 통하여 전달된다.

5G 네트워크가 본격화되면서, 서비스는, 높은 쓰루풋(High-Data Rate, Throughput)을 기준으로 품질을 판단할 수 있는 모바일 브로드 밴드, AR/VR(Augmented Reality/Virtual reality)와 초저지연(Ultra-High Low Latency)을 기반으로 품질을 판단하는 무인 자동차, 로봇수술, 공장자동화 등의 서비스, 그리고 다량의 단말이 네트워크에 연동을 기준으로 품질을 판단할 수 있는 5G IoT(Broadcasting, Massive Internet of Things) 서비스 등으로 구분된다.

5G 네트워크의 등장과 서비스 특성의 변화로 인해, 서비스 이용자가 느끼는 체감 품질 또한 그 특성에 맞게 서비스 품질이 예측되도록 구분 측정되어야 하고, 문제(ex. Low QoS)가 발생할 경우 어느 구간에서 문제의 원인이 무엇인지 분석되어야 한다.

다만, 아직까지 LTE(Long Term Evolution) 무선 네트워크에서는 코어망의 데이터처리 노드(SAEGW)와 연동된 FTP서버를 이용하여 통신 단말-기지국-SAEGW-FTP서버간 링크 패스를 통하여 쓰루풋(Throughput), 패킷 소실(Packet Loss), 서비스지연시간(Delay Time), 지터(Jitter) 정도만을 측정하여 서비스품질의 수준이 아닌 네트워크의 상태가 점검되고 있고, 문제가 발생할 경우에도 정확한 문제의 구간과 문제의 원인이 분석되지 못하고 있다.

국외 상용 솔루션의 경우, IP 네트워크 상태를 측정하기 위하여 전용의 측정 서버를 구성해야 하며, 진단장치가 고가이고, 네트워크의 형상이 변경될 경우 측정을 위한 환경 역시 모두 변경되어야 하는 번거로움 때문에, 적용의 대상을 자유롭게 변경 또는 확장하기 어렵다는 문제점이 있다.

특히, 5G 네트워크의 본격적인 등장으로 액세스 네트워크의 조밀화, 코어 네트워크의 클라우드 및 분산화(Central Cloud/Edge Cloud), 통신 단말기의 고성능화를 기반으로 초 고화질 화상제공서비스(VR/AR: Virtual Reality/Augmented Reality), 차량ㆍ사물 통신(V2X: Vehicle to Everything communication), 다량접속(Massive IoT(Internet of Things) 등이 본격적으로 제공될 경우, 이로 인하여 발생하는 트래픽 폭증은 결국 서비스 품질 저하를 유발할 수 있다. 즉, 적절한 진단 수단의 부재로 인해 서비스에 대한 사용자의 체감 품질이 심각하게 저해될 수 있다는 문제점이 있다.

공개특허공보 제10-2017-0092878호(백홀 망의 쓰루풋 측정 방법 및 장치)

본 개시는, 5G 네트워크 또는 5G와 LTE(Long Term Evolution)를 연계한 네트워크를 기반으로 제공되는 서비스의 품질에 영향을 주는 네트워크 문제점을 자동으로 진단하고, 네트워크의 품질 수준을 분석하는 진단 시스템을 제공한다.

구체적으로, 본 개시는, 전용의 프로토콜 분석기나 네트워크상의 패킷을 카피(패킷 미러링 또는 패킷 덤프)하지 않고도 5G 등의 네트워크를 구성하는 Center Cloud - Edge Cloud - 기지국간 또는 5G 네트워크 - LTE 네트워크를 연계하여 제공되는 서비스들에 대한 품질 수준을 자동으로 진단하고 분석하는 진단 시스템을 제공한다.

특히, 본 개시는, All-IP의 5G를 기반으로 제공되는 서비스의 품질 수준을 진단하기 위해, 각 엔드 노드(단말기, 기지국, Center Cloud)에 설치된 소프트웨어 및 네트워크 운영자(ex. 분석 서버)를 통해 네트워크 구간 별로 네트워크 품질을 진단하는 네트워크 진단 시스템의 운영 방법을 제공한다.

본 개시의 목적들은 이상에서 언급한 목적으로 제한되지 않으며, 언급되지 않은 본 개시의 다른 목적 및 장점들은 하기의 설명에 의해서 이해될 수 있고, 본 개시의 실시 예에 의해 보다 분명하게 이해될 것이다. 또한, 본 개시의 목적 및 장점들은 특허 청구 범위에 나타낸 수단 및 그 조합에 의해 실현될 수 있음을 쉽게 알 수 있을 것이다.

본 개시의 일 실시 예에 따라, 사용자 단말, 기지국, 엣지 클라우드(Edge Cloud), 및 센터 클라우드(Center Cloud)를 포함하는 네트워크를 진단하는 진단 시스템은 상기 사용자 단말, 상기 기지국, 상기 엣지 클라우드, 및 상기 센터 클라우드 각각에 구비되고, 하나 이상의 소프트웨어 진단 에이전트와 연동된, 컨트롤 클라이언트, 상기 소프트웨어 진단 에이전트의 진단 시나리오를 설정하는, 분석 서버를 포함한다. 상기 소프트웨어 진단 에이전트는, 상기 사용자 단말, 상기 기지국, 상기 엣지 클라우드, 및 상기 센터 클라우드 간의 연결 관계에 따라 구분된 복수의 네트워크 구간 별로, 진단 정보를 생성한다.

상기 소프트웨어 진단 에이전트는, 상기 복수의 네트워크 구간 중 적어도 하나의 네트워크 구간 내에서 일 방향으로 진단 패킷을 전달하고, 상기 진단 패킷이 전달됨에 따라 반송된 반송 패킷을 기반으로, 상기 진단 정보를 생성할 수 있다.

이 경우, 상기 소프트웨어 진단 에이전트는, 적어도 하나의 네트워크 구간 내에서 상방향으로 진단 패킷을 전달함에 따라 반송된 반송 패킷을 기반으로, 제1 진단 정보를 생성하고, 적어도 하나의 네트워크 구간 내에서 하방향으로 진단 패킷을 전달함에 따라 반송된 반송 패킷을 기반으로, 제2 진단 정보를 생성할 수 있다.

여기서, 상기 소프트웨어 진단 에이전트는, 상기 사용자 단말로부터 상기 기지국, 상기 엣지 클라우드, 및 상기 센터 클라우드 중 적어도 하나로 진단 패킷을 전달하고, 상기 사용자 단말로부터 상기 진단 패킷이 전달된 이후 상기 사용자 단말로 반송된 반송 패킷에 따라 상기 제1 진단 정보를 생성할 수도 있다.

한편, 상기 소프트웨어 진단 에이전트는, 상기 반송된 반송 패킷에 따라 특정 네트워크 구간 내에서 패킷 소실이 발생한 것으로 식별된 경우, 진단 중 발생한 이벤트에 대한 정보 및 상기 네트워크 구간에 포함되는 통신 기기에 대한 정보를 상기 분석 서버로 전송할 수 있다.

그리고, 상기 진단 패킷은, 타겟 통신 기기에 대한 정보 및 상기 타겟 통신 기기까지 전달되는 과정에서의 Routing Path에 따른 Hop count에 대한 정보를 각각 포함할 수 있다. 이 경우, 상기 소프트웨어 진단 에이전트는, 상기 진단 패킷이 상기 타겟 통신 기기로 전달될 수 없는 경우, Routing Path에 따라 타겟 통신 기기를 변경하고, 상기 변경된 타겟 통신 기기에 대한 진단 정보를 생성할 수 있다.

한편, 상기 소프트웨어 진단 에이전트는, 서비스 유형에 매칭되는 진단 시나리오에 따라 적어도 하나의 진단 패킷을 선택하고, 적어도 하나의 네트워크 구간 내에서 상기 선택된 진단 패킷을 전달하여 상기 진단 정보를 생성할 수 있다.

기존의 네트워크 품질 진단 기술은, 전용의 HW박스(FPGA기반), 측정을 위한 용량확장의 어려움, 진단환경 설정의 복잡성, 서비스 유형별로 그 특징에 맞는 진단 측정의 어려움 그리고 높은 라이선스 비용이라는 한계를 가지고 있다. 특히, 서비스 특성을 반영한 진단조건을 설정하거나 정보 분석을 위한 패킷의 구성 및 구조를 자동으로 설정하지 못하는 한계를 가지고 있다.

본 개시에 따른 네트워크 진단 시스템은, 전용의 HW박스(ex. FPGA기반) 없이도 소프트웨어 진단 에이전트(SW Agent)를 이용할 수 있고, 진단을 위한 설정은 네트워크 운영자가 서비스 유형만 선택함으로써 기 정의된 진단조건 및 진단 패킷 구성을 자동으로 설정할 수 있으며, 서비스의 유형에 따라서 진단 패킷의 성격(QoS, 단위시간내 전달할 패킷 수, 패킷에 대한 injection count, 패킷 간 interval time, injection을 위한 Gap time, payload size 등)이 자동으로 설정된다.

또한, 본 개시에 따른 네트워크 진단 시스템은, 5G 네트워크의 특성(액세스 네트워크의 조밀화, 코어네트워크의 클라우드 및 분산화(Central Cloud/Edge Cloud), 통신단말기의 고성능화를 기반으로 초 고화질 화상제공서비스(VR/AR: Virtual Reality/Augmented Reality), 차량ㆍ사물 통신(V2X: Vehicle to Everything communication), 다량접속(Massive IoT(Internet of Things))이 반영되어 서비스 유형 별 특성에 맞는 진단이 가능하다.

또한, 본 개시에 따른 네트워크 진단 시스템에 따르면, 타겟 기기/시스템의 진단을 위한 시스템 구성 측면에서, 진단 클라이언트를 전용의 하드웨어(FPGA 등)가 아닌 소프트웨어 모듈(소프트웨어 진단 에이전트)로 대체하였으며, 컨트롤 클라이언트의 운영 체제에 관계없이 포팅될 수 있도록 구성되어 네트워크 운영자가 손쉽게 진단대상 확장, 진단을 위한 조건변경 및 진단환경 구성이 상대적으로 쉬우며, 확대적용 또한 자유롭다.

또한, 본 개시에 따른 네트워크 진단 시스템은, 진단된 대용량 패킷 정보를 활용하여 장애 등 네트워크상태 판단정보(Target NE별 Link Reachability, Link Fluctuation, Congestion 등), 서비스 영향 요소판단정보(Service Type별, QoS별, Segmentation에 따른 패킷 지연, 패킷 소실, 패킷 순서 역전 현상 등)를 상호 연계분석 하고, 서비스를 관리하는 SLA(Service Level Agreement)의 기준 변화에 능동적으로 대응할 수 있다.

도 1은 본 개시의 일 실시예에 따른 진단 대상 네트워크 및 네트워크 진단 시스템의 구성을 개략적으로 도시한 도면,
도 2는 도 1의 분석 서버(Analysis Manager)의 기능적 구성들을 도시한 블록도,
도 3은 도 1의 컨트롤 클라이언트(컨트롤 클라이언트) 및 소프트웨어 진단 에이전트(SW Agent)의 기능적 구성을 도시한 블록도로서, 분석 서버로부터 수신된 진단 시나리오를 바탕으로 서비스 별 진단 조건을 설정하는 파트, 진단 조건을 바탕으로 진단 로직을 생성하는 파트, 진단 로직에 따라서 진단 패킷을 타깃 시스템에 전달하는 파트, 진단 결과를 수신하여 필요한 정보를 파싱하는 파트 등을 도시한 도면,
도 4는 본 개시의 일 실시 예에 따른 네트워크 진단 시스템의 동작을 설명하기 위한 흐름도,
도 5는 본 개시의 일 실시 예에 따라 5G 네트워크 구성을 진단하는 네트워크 진단 시스템이 서비스 유형에 따른 진단 구간(네트워크 구간)을 구분하는 동작을 설명하기 위한 도면,
도 6은 진단하고자 하는 구간(Hop으로 구분)을 선택적으로 진단하기 위한 진단 패킷의 전송 개념 및 로직의 예를 나타낸 도면,
도 7은 진단하고자 하는 구간이 정해진 상태에서 서비스 유형에 따른 하 방향 및 상 방향으로 진단 패킷을 전송하기 위한 패킷의 성격과 패킷 전송 밀집도를 설정하기 위한 로직의 예를 나타낸 도면,
도 8은 소프트웨어 진단 에이전트(SW Agent)을 통한 서비스 특성 기반의 진단을 위한 진단 로직의 예를 나타낸 블록도,
도 9는 본 개시의 일 실시 예에 따라 진단에 이용되는 서비스 유형에 따른 진단 패킷 설정 또는 운영자에 의하여 설정된 값이 변경 가능한 패킷의 구조를 설명하기 위한 도면,
도 10은 본 개시의 일 실시 예에 다른 진단 시스템이 진단 대상의 네트워크 구간에서 서비스 제공 시 문제가 발생할 수 있는 위치의 대역폭 및 버퍼(또는 Queue)의 크기를 하향 방향으로 진단하여 예측하기 위한 로직을 나타낸 알고리즘,
도 11은 본 개시의 일 실시 예에 따른 진단 시스템이 사용자 단말을 이용하여 상방향으로 서비스 품질 및 네트워크 상태를 진단하여 예측하기 위한 로직을 나타낸 도면, 그리고
도 12는 본 개시의 일 실시 예에 따른 진단 시스템이, 상 방향 또는 하 방향 진단 과정에서 패킷 소실이 발생했을 경우, 네트워크 및 스위치의 점검 및 문제가 예측되는 지점에서의 버퍼(또는 Queue)의 크기를 진단하는 로직을 나타낸 알고리즘이다.

본 개시에 대하여 구체적으로 설명하기에 앞서, 본 명세서 및 도면의 기재 방법에 대하여 설명한다.

먼저, 본 명세서 및 청구범위에서 사용되는 용어는 본 개시의 다양한 실시 예들에서의 기능을 고려하여 일반적인 용어들을 선택하였다. 하지만, 이러한 용어들은 당해 기술 분야에 종사하는 기술자의 의도나 법률적 또는 기술적 해석 및 새로운 기술의 출현 등에 따라 달라질 수 있다. 또한, 일부 용어는 출원인이 임의로 선정한 용어도 있다. 이러한 용어에 대해서는 본 명세서에서 정의된 의미로 해석될 수 있으며, 구체적인 용어 정의가 없으면 본 명세서의 전반적인 내용 및 당해 기술 분야의 통상적인 기술 상식을 토대로 해석될 수도 있다.

또한, 본 명세서에 첨부된 각 도면에 기재된 동일한 참조번호 또는 부호는 실질적으로 동일한 기능을 수행하는 부품 또는 구성요소를 나타낸다. 설명 및 이해의 편의를 위해서 서로 다른 실시 예들에서도 동일한 참조번호 또는 부호를 사용하여 설명한다. 즉, 복수의 도면에서 동일한 참조 번호를 가지는 구성요소를 모두 도시되어 있다고 하더라도, 복수의 도면들이 하나의 실시 예를 의미하는 것은 아니다.

또한, 본 명세서 및 청구범위에서는 구성요소들 간의 구별을 위하여 "제1", "제2" 등과 같이 서수를 포함하는 용어가 사용될 수 있다. 이러한 서수는 동일 또는 유사한 구성요소들을 서로 구별하기 위하여 사용하는 것이며 이러한 서수 사용으로 인하여 용어의 의미가 한정 해석되어서는 안 된다. 일 예로, 이러한 서수와 결합된 구성요소는 그 숫자에 의해 사용 순서나 배치 순서 등이 제한되어서는 안 된다. 필요에 따라서는, 각 서수들은 서로 교체되어 사용될 수도 있다.

본 명세서에서 단수의 표현은 문맥상 명백하게 다르게 뜻하지 않는 한, 복수의 표현을 포함한다. 본 출원에서, "포함하다" 또는 "구성되다" 등의 용어는 명세서상에 기재된 특징, 숫자, 단계, 동작, 구성요소, 부품 또는 이들을 조합한 것이 존재함을 지정하려는 것이지, 하나 또는 그 이상의 다른 특징들이나 숫자, 단계, 동작, 구성요소, 부품 또는 이들을 조합한 것들의 존재 또는 부가 가능성을 미리 배제하지 않는 것으로 이해되어야 한다.

본 개시의 실시 예에서 "모듈", "유닛", "부(part)" 등과 같은 용어는 적어도 하나의 기능이나 동작을 수행하는 구성요소를 지칭하기 위한 용어이며, 이러한 구성요소는 하드웨어 또는 소프트웨어로 구현되거나 하드웨어 및 소프트웨어의 결합으로 구현될 수 있다. 또한, 복수의 "모듈", "유닛", "부(part)" 등은 각각이 개별적인 특정한 하드웨어로 구현될 필요가 있는 경우를 제외하고는, 적어도 하나의 모듈이나 칩으로 일체화되어 적어도 하나의 프로세서로 구현될 수 있다.

또한, 본 개시의 실시 예에서, 어떤 부분이 다른 부분과 연결되어 있다고 할 때, 이는 직접적인 연결뿐만 아니라, 다른 매체를 통한 간접적인 연결의 경우도 포함한다. 또한, 어떤 부분이 어떤 구성요소를 포함한다는 의미는, 특별히 반대되는 기재가 없는 한 다른 구성요소를 제외하는 것이 아니라 다른 구성요소를 더 포함할 수 있는 것을 의미한다.

본 개시에 따른 네트워크 진단 시스템은, 사용자 단말, 기지국, 엣지 클라우드(Edge Cloud), 및 센터 클라우드(Center Cloud) 등을 포함하는 네트워크를 진단 대상으로 할 수 있다.

본 개시의 일 실시 예에 따른 네트워크 진단 시스템은, 하나 이상의 소프트웨어 진단 에이전트와 연동된 컨트롤 클라이언트, 분석 서버 등을 포함할 수 있다.

컨트롤 클라이언트(컨트롤 클라이언트)는, 각 통신 기기 간의 통신에 따라 진단 과정을 수행하기 위한 모듈(하드웨어 및/또는 소프트웨어로 구성된 모듈)에 해당할 수 있다.

컨트롤 클라이언트는 사용자 단말, 기지국, 엣지 클라우드(서버), 센터 클라우드(서버) 중 적어도 하나에 각각 설치/구비되어 하나 이상의 소프트웨어 진단 에이전트를 운용할 수 있다.

소프트웨어 진단 에이전트(SW Agent)는, 사용자 단말, 기지국, 엣지 클라우드, 및 센터 클라우드 간의 연결 관계에 따라 구분된 복수의 네트워크 구간 별로, 진단 정보를 생성할 수 있다.

구체적으로, 소프트웨어 진단 에이전트는, 서비스의 유형(회선기반-음성 서비스, 데이터기반-고화질 HD영상/VoLTE/Real-Time Gaming 서비스, 컨버전스-AR/VR/초고속 데이터/IoT/양방향 초실시간{Real-TimeControl} 서비스)에 따라서 진단 조건과 방법을 달리하여 진단을 수행할 수 있다.

본 개시에 따른 네트워크 진단 시스템에 있어서, 네트워크의 진단 내지는 측정은 상향(Up Link) 측정과 하향(Down Link) 측정으로 구분된다.

분석 서버(Analysis Manager)는 소프트웨어 진단 에이전트(컨트롤 클라이언트)의 진단 시나리오를 설정하고 진단 결과를 분석하기 위한 구성이다. 분석 서버는 하나 이상의 컴퓨터 내지는 시스템을 포함할 수 있으며, 진단의 대상인 네트워크의 환경과 연동된 빅데이터를 포함할 수 있다.

분석 서버는, 서비스 유형과 네트워크를 구성하는 구성요소 그리고 컨트롤 클라이언트로부터 수집된 정보를 상호 연계분석(Co-Relator)할 수 있다.

소프트웨어 진단 에이전트(SW Agent)는 사용자단(단말기), 네트워크 엔드 노드(기지국), 엣지 클라우드(Edge Cloud), 센터 클라우드(Center Cloud)내 설치된 컨트롤 클라이언트에 포팅되어 서비스 유형에 따라서 진단 시나리오를 기반으로 자동 또는 네트워크 운영자가 수동으로 진단동작을 수행할 수 있다. 진단은 각 컨트롤 클라이언트에 포팅 된 소프트웨어 진단 에이전트(SW Agent)가 상향측정 및 하향측정을 진행할 수 있다.

컨트롤 클라이언트는, 전용의 HW 박스로 시스템실(Center Cloud)에 설치하여 하향 측정하던 기존의 방식이 아닌, 사용자단(단말기), 네트워크 엔드 노드(기지국), 엣지 클라우드(Edge Cloud), 센터 클라우드(Center Cloud)에 설치된 Android, Window 또는 Unix나 Linux OS기반의 시스템을 이용하여 구성할 수 있으며, 소프트웨어 진단 에이전트(SW Agent)가 포팅되어 동작된다.

사용자단(단말기)의 컨트롤 클라이언트에 포팅된 소프트웨어 진단 에이전트(SW Agent)는 네트워크의 상태를 진단하기 위하여 상방향으로 진단 패킷(TWAMP, Echo Request, Tracker)을 생성하여 전달하고 네트워크상에 있는 엔드 노드(기지국), 엣지 클라우드(Edge Cloud), 센터 클라우드(Center Cloud)로부터 반송된 결과(ex. 반송 패킷)를 수신할 수 있다.

이를 통하여 분석된 결과는 별도의 데이터 세선(사용자 단말 - 엣지 클라우드 또는 센터 클라우드)을 생성하여 해당 세션을 통하여 측정된 결과가 자동으로 전송된다.

중앙 클라이언트(센터 클라우드)에 포팅된 소프트웨어 진단 에이전트는, 분석 서버로부터 진단 시나리오(Service 타입에 따라서 구분)와 진단대상인 타겟 시스템/기기 정보(IP, ID, Name, Service 타입)를 수신하여 진단을 위한 환경을 설정할 수 있다. 소프트웨어 진단 에이전트는, 설정된 진단 시나리오를 기반으로 진단 패킷을 타겟 시스템/기기(사용자 단말, 엔드노드 기지국, 엣지 클라우드 및 L3 스위치 등)에 전송하며 Step 1 진단을 수행할 수 있다.

진단 패킷을 수신한 타겟 시스템은 수신된 진단 패킷의 상태와 자신의 정보를 추가하여 반송하며, 반송된 진단 패킷(반송 패킷)을 수신한 클라이언트는 양방향(하방향-상방향)의 진단결과 데이터를 이용하여 시나리오 기반의 Step 2 진단을 수행할 수 있다.

본 진단의 절차는 서비스 유형에 따라서 Step1에서 Step 4까지 자동으로 또는 운영자에 의해 수동으로 진행될 수 있다. 진단의 결과는 해당 클라이언트에서 정보 추출과정을 통하여 그 결과 정보가 분석 서버로 전달되도록 구성된다.

분석 서버는 컨트롤 클라이언트에서 진단을 수행하는 진단 시나리오를 네트워크 운영자에 의해서 생성/변경/삭제할 수 있으며, 생성/변경된 시나리오를 컨트롤 클라이언트에 로딩하고, 소프트웨어 진단 에이전트(SW Agent)의 동작상태를 원격으로 제어(Start/Stop/Hold), 원격 모니터링(동작상태) 및 진단된 결과 정보를 수집할 수 있다.

분서 서버는 수집된 정보를 빅데이터 환경에서 변형 및/또는 분석 대상에 대한 모델 정보를 생성한 후, 네트워크 장비(5G 네트워크 장비: gNB, CU, UPF, Service Server 등)의 장애 및 트래픽 통계 정보와 연계한 연계분석(Co-Relator)을 수행할 수 있다. 또한, 분석 서버는, 분석된 결과를 바탕으로 알람 생성(Alarm Generation), 상황전파(Alarm Notification), 정보의 통계화 및 보고서 생성 등을 수행할 수 있다.

도 1은 본 발명의 실시예에 따른 5G 및 LTE 네트워크를 기반으로 제공되는 서비스의 품질상태 예측 및 품질분석 시스템을 개략적으로 도시한 도면이며, 도 2 및 도 3은 도 1에 나타낸 분석서버(Analysis Manager)와 컨트롤 클라이언트(컨트롤 클라이언트), 소프트웨어 진단 에이전트(SW Agent)에 대한 기능을 블록도 형태로 설명하기 위하여 도시한 도면이다.

도 1에 도시된 바와 같이, 제공되는 서비스의 품질상태 예측 및 품질분석 시스템은 분석서버(110), 소프트웨어 진단 에이전트에 포함되는 컨트롤 클라이언트(120), 소프트웨어 진단 에이전트(130), 빅데이터 저장을 위한 데이터베이스(140), 진단을 위한 구간별 점검대상(150) 및 5G 및 LTE 네트워크부터 수집한 정보(160)를 바탕으로 구현될 수 있다. 일 실시예에 따라, 5G 및 LTE 네트워크부터 수집한 정보(160)는, Network Configuration, Alarm, Statistics, CSL, GTP Status 중 적어도 하나를 포함하는 정보일 수 있다.

한편, 도 2에 도시된 바와 같이, 분석 서버(110)는, 진단 시나리오 관리 모듈(10), 진단 실행 관리 모듈(20), 분석 모듈(30), QoS 판단 모듈(40), 정보 관리 모듈(50), 사용자 계위 모듈(55) 및 빅데이터 저장을 위한 데이터베이스(140)를 포함할 수 있다.

이때, 분석 서버(110)는 1) DU기반의 IPv4/IPv6 정보 수집 및 백홀 기반의 중요 위치 Router 정보 수집을 포함하는 본 진단 시스템의 구성 정보와 연동 협의, 2) Core Cloud를 중심으로 한 위치, Edge Cloud를 중심으로 한 위치 및 Service Network내 위치를 고려한 BHA+의 Client 위치 선정 3) Iperf pumping을 위한 DU의 접근 권한 및 4) Access Network의 GTP, Ping 및 SAEGW의 ER, MME의 Communication 등을 고려한연계 분석을 위한 EPC/Access에 대한 운용정보 연동 협의 및 5) Throughput에 영향을 주는 관리정보를 정의하는 방식으로 구현될 수 있다. 한편, 도 3에 도시된 바와 같이, 소프트웨어 진단 에이전트(130)는 SW Agent(60), 진단조건 모듈(70), 최초 진단 로직 선택 모듈(80), Data loader(90) 및 컨트롤 클라이언트(120)를 포함할 수 있다.

일 실시예에 따라, 진단 서버는, 테스트 시나리오 생성 및 전달, 클라이언트의 프로세스 상태 관리, 클라이언트에서 파싱된 결과(One Record)를 이용하여 분석을 위한 마트 생성 및 현재 상태를 위한 정보 관리, 2차 또는 3차 DB 구성 및 UI처리를 위한 WEB/WAS 동작 관리를 수행할 수 있다

또 다른 실시예로, 진단 클라이언트는 시나리오 생성기(Scenario Maker)에 의해서 생성된 테스트 시나리오 및 타겟 NE를 수신 및 관리하고, 진단 클라이언트에 포함된 클라이언트 매니저는 테스트 시나리오를 바탕으로 해당 프로세스를 생성 및 관리할 수 있다. 이때, 진단 클라이언트의 동작 모드는 Non-TWAMP, TWAMP, iperf 중 적어도 하나일 수 있으며, 진단 클라이언트는 진단 결과의 파싱 및 특이 결과 처리,삽입(Injection)의 수와 관계 없이 복수의 레코드를 하나의 레코드로 생성할 수 있으며, Data Loader(90)를 이용한 결과(One Record)를 데이터베이스에 전달할 수 있다.

구체적으로, 본 발명의 일 실시예에 따른 네트워크 진단 시스템은 상술한 바와 같이, 네트워크 서비스의 품질 상태를 진단하는 컨트롤 클라이언트(120), 소프트웨어 진단 에이전트(130) 및 진단된 정보를 빅데이터 저장을 위한 데이터베이스(140)을 이용하여 품질분석을 수행하는 분석 서버(110)를 포함할 수 있다.

특히, 네트워크 진단 시스템은, 상 방향의 진단을 위한 사용자 체감의 서비스품질을 측정할 수 있는 사용자 단말 단의 소프트웨어 진단 에이전트(130)를 포함할 수 있다.

분석 서버(110)는 네트워크로부터 시설, 네트워크 형상 및 서비스 관련 통계 정보를 네트워크 명령을 이용하여 수집하고 DB화를 수행할 수 있다. 네트워크 운영자는 수집되고 DB화된 정보를 바탕으로 진단하고자 하는 서비스 유형과 타겟 NE(Network Element)를 대상으로 Scenario Maker 블록을 이용하여 진단 시나리오를 생성할 수 있다.

또한, 분석 서버(110)는 생성된 시나리오의 변경 또는 삭제를 수행할 수 있다. 생성되거나 변경된 진단 시나리오는 Client Manager에 의해서 선택된 컨트롤 클라이언트(120)에 로딩되며, 로딩된 시나리오에 따라 동작 제어와 동작 상태가 모니터링된다.

또한, 분석 서버(110)는 진단된 결과를 빅데이터 저장을 위한 데이터베이스(140)으로 수집하고 정보화 하여 진단 대상 서비스 유형에 따른 네트워크 상태와 서비스 품질 수준을 분석하고 문제점이 있는 것의 구체적인 정보(문제점 유형, 문제의 위치, 나타나는 현상 및 문제의 원인)를 분석하여 사용자 계위에 표현하거나 보고서를 생성할 수 있다.

컨트롤 클라이언트(120)와 소프트웨어 진단 에이전트(130)는 진단을 위한 동작을 같은 동일한 시스템 내에서 수행하게 된다. 컨트롤 클라이언트는(120) 확장성을 고려하여 OS 환경(ex. Window, Linux, Unix 등)과 무관하게 소프트웨어 진단 에이전트(130)가 포팅되고 동작될 수 있도록 구성될 수 있다.

컨트롤 클라이언트(120)는 진단을 위한 데이터 용량성을 확보하기 위하여 1Gbps이상을 지원하고 4Port 이상으로 구성된 NIC 카드 내에서 TCP 포트 단위로 설정할 수 있도록 구성될 수 있다.

컨트롤 클라이언트에 포팅 되는 소프트웨어 진단 에이전트(130)내의 Agent Controller는 분석 서버(110)로부터 진단 시나리오를 로딩 받아 파일 형태로 관리하고, 진단하고자 하는 타킷 NE와 서비스의 유형에 따라서 진단 프로세스(SW Agent)를 관리할 수 있다.

하나의 컨트롤 클라이언트는 복수의 SW Agent를 이용할 수 있으며, SW Agent들은 Client Manager에 의해서 제어를 받는다. SW Agent들은 자신이 진단해야 할 타깃 NE와 진단 대상의 서비스 유형(회선기반-음성, VoLTE, 영상 서비스, 데이터기반-고화질HD영상/Real Time Gaming 서비스, 컨버전스-AR/VR/초고속 데이터/IoT/양방향 초실시간{Real-Time Control} 등)에 따라서 진단 정보와 상태 점검을 위한 진단 로직을 선택하여 진단을 수행할 수 있다. 진단 수행을 위한 기본적인 절차는 도 4에 도시되었으며, 진단하고자 하는 타겟의 구분 및 진단 패킷을 전달하기 위한 네트워크 영역 구분은 도 5에 도시되었다.

구체적으로, 도 4에 도시된 바와 같이, 품질 분석 프로세스는 5G 및 LTE 네트워크 중 적어도 하나의 네트워크에 대한 형상 정보 수집 후 진단 시나리오를 생성, 변경 및 로딩할 수 있다. 이러한 프로세스는 분석 서버(110)에 의해 수행될 수 있다.

이후, 컨트롤 클라이언트(120)는, 진단 시나리오를 분석 서버(110)로부터 수신하고, 서비스의 유형을 결정할 수 있다. 컨트롤 클라이언트(120)는, 진단 환경에 따른 진단 패킷을 소프트웨어 진단 에이전트(130)으로 전송할 수 있다. 이후, 소프트웨어 진단 에이전트(130)는 진단 결과를 수집하고 상태를 확인한 후, 진단 결과를 획득할 수 있다.

소프트웨어 진단 에이전트(130)는, 진단 결과를 분석 서버(110)의 데이터베이스(140)로 전송할 수 있다. 분석 서버(110)는 데이터베이스(140)에 정보화된 진단 결과를 바탕으로 진단 결과를 분석하고, 품질 수준을 결정할 수 있다. 이후, 분석 서버(110)는, 분석 보고서 및 품질 보고서를 생성하고, 사용자 편의를 위한 다양한 UI를 표시하기 위한 데이터를 획득할 수 있다.

구체적으로, 일 실시예에 따라, 서비스 타입(도 4 참조)의 구분은 5G 및 LTE 네트워크를 기반으로 정의될 수 있다.

예를 들어, Packet Delay Budget이 100 ~ 150ms이고 LTE 백홀 네트워크가 10ms를 5G 백홀 네트워크는 10ms 이하를 요구하고 있는 회선 기반-음성/VoLTE/영상 서비스는 A 타입 서비스로 구분될 수 있다. Packet Delay Budget이 50 ~ 100ms이고 LTE 백홀 네트워크가 10ms를 5G 백홀 네트워크는 3~5ms 이하를 요구하는 고화질 HD 영상/Real Time Gaming 서비스는 B 타입 서비스로 구분될 수 있다. Packet Delay Budget이 백홀을 구분하지 않고 5~15ms 이하를 요구하는 컨버전스-AR/VR/초고속데이터/초고속IoT의 5G 네트워크 서비스는 C 타입 서비스로 구분될 수 있다. Packet Delay Budget이 백홀을 구분하지 않고 1~5ms 이하를 요구하는 5G 네트워크에서 양방향 초실시간(Real Time Control) 서비스는 D 타입 서비스로 구분될 수 있다. A/B/C/D로 구분된 서비스 유형은 진단을 위한 환경 구성, 로직 선택을 위한 기본 정보로 활용된다.

서비스의 유형에 따라서 진단 패킷의 성격(QoS, 단위시간내 전달할 패킷 수, 패킷에 대한 injection count, 패킷간 interval time, injection을 위한 Gap time, payload size 등)이 자동으로 설정될 수 있다.

5G 및 LTE와 연계된 네트워크에서 네트워크의 상태와 서비스 품질 수준에 대한 진단을 위한 전체적인 개념은 도 1에서 표현하였으며, 진단을 위한 구간 별 점검대상(150) 구분은 도 5에 표현하였다. 일반적으로 서비스에 영향을 주는 문제의 요인은 네트워크를 구성하는 링크 상태, 네트워크 구성 스위치/라우터, IDC센터 또는 클라우드센터 환경과 프로세스들이 수행되는 서버류 그리고 어플리케이션 프로세스 상태로 구분된다.

본 개시에 따른 진단 과정 중 네트워크를 구성하는 링크상태, 네트워크 구성 스위치/라우터 및 프로세스들이 수행되는 서버류의 Layer4까지를 진단하고 분석하여 품질영향요인을 찾고 품질의 수준을 예측함에 있어, 상방향의 진단은 도 5의 사용자 단말의 컨트롤 클라이언트(120)에서 Edge Cloud 또는 Center Cloud에 위치한 컨트롤 클라이언트(120) 방향으로 진단을 수행하며, 하방향의 진단은 도 5의 Edge Cloud 또는 Center Cloud에 위치한 컨트롤 클라이언트(120)에서 타깃 NE(150) 또는 사용자 단말의 컨트롤 클라이언트(120)까지 진단을 수행할 수 있다.

한편, 도 6은 진단하고자 하는 구간(Hop으로 구분)을 선택적으로 진단하기 위한 진단 패킷의 전송 개념 및 로직의 예를 나타낸 도면, 도 7은 진단하고자 하는 구간이 정해진 상태에서 서비스 유형에 따른 하 방향 및 상 방향으로 진단 패킷을 전송하기 위한 패킷의 성격과 패킷 전송 밀집도를 설정하기 위한 로직의 예를 나타낸 도면, 도 8은 소프트웨어 진단 에이전트(SW Agent)을 통한 서비스 특성 기반의 진단을 위한 진단 로직의 예를 나타낸 블록도이다.

도 6을 참조하면, 진단 패킷(ICMP, OWAMP, TWAMP, TCP Packet을 포함)이 네트워크 상에서 타깃 NE까지 전달되는 과정에서, Routing Path에 따른 Hop Count와 NE 정보가 함께 측정되고 관리될 수 있다.

만약, 타겟 NE에 진단 패킷이 Unreachable 상태가 발생하면 Routing Path 별 진단대상이 변경(타깃 NE의 Hop Count - 1Hop)되어 진단될 수 있으며, 네트워크 운영자에 의해서 Routing Path 내 구간이 지정되어 진단될 수도 있다. 진단 패킷은 상방향 및 하방향 모두 가능하며, 사용자 단말(사용자 단말의 소프트웨어 진단 에이전트(130))을 통해 필드(예를 들어, 길거리)에서 측정되는 경우 무선환경에 의한 영향을 배제하기 위하여 RSRP, RSRQ, SINR, CQI 값(도 1 및 도5 참조)을 참조하여 무선환경의 영향 여부를 확인될 수 있다.

구체적으로, 도 6에 도시된 바와 같이, Hop간 통신의 TTL은 예를들어 1초로 설정되고, Hop과 송신단/수신단간 통신의 TTL은 예를 들어 5초로 설정될 수 있다.

이때, 일 실시 예에 따르면, 도 6 내지 도 8에 도시된 바와 같이, 소프트웨어 진단 에이전트는 TTL(Time To Live) test를 수행할 수 있다. 소프트웨어 진단 에이전트는 TTL의 수가 임계치에 다다르기 전까지의 패킷 소실 비율(Packet Loss Ratio)를 식별할 수 있으며, 결과 Log를 이용하여 처리할 수 있다.

또 다른 실시예로, 소프트웨어 진단 에이전트는 TTL test를 야간에 수행할 수 있다(ex. 오전 1시~6시 등). 이 경우, Normal Traffic에 의한 영향이 최소화될 수 있다. 다만, TTL test가 야간이 아닌 주간(day time)에 수행되는 것도 물론 가능하다. 마지막 Hop의 직전 Hop에서 패킷 소실이 발생할 가능성이 비교적 높은 편이다.

한편, Problematic Point of Router에 대한 정밀 진단은 Router에 대한 구성, 파라메터 및 Tx/Rx Packet 처리 상태로 확인이 필요하다. 이때, 특정 Router에서 Packet Loss가 DSCP(Differentiated Services Code Point)에 의해 영향을 받는지 여부의 확인은 별도의 Test가 필요하다.

이렇듯, 서비스 유형(A/B/C/D 타입)에 따라 진단 패킷의 조건을 달리하고, 네트워크의 타깃을 자동으로 변경하며, 자체의 진단 로직을 동적으로 적용하는 개념(도 8 내지 도 11)은 기존의 진단 툴에서 수행하지 못했던 개념이다.

특히 종래 5G와 LTE네트워크를 대상으로 한 진단은 단순히 FTP 서버에 파일을 다운로드/업로드하는 수준이고 네트워크 상태도 단순한 수준의 측정(고정형태의 ICMP or TWAMP 패킷 전달)으로 진행되고 있었기 때문에 본 개시의 네트워크 진단 시스템이 활용하는 진단 방식은 새로운 형태의 진화된 진단 개념이다.

한편, 본 개시에 따른 진단 시스템은, 도 9의 구조를 가지는 진단 패킷 외에도 ICMP(Internet Control Message Protocol), OWAMP/TWAMP(One-Way Active Measurement Protocol/Two-Way Active Measurement protocol) 등의 구조를 이용할 수 있는 바, 다양한 형태의 진단을 위한 패킷 및 데이터 그램이 가능하다. 본 발명의 일 실시예에 따른 진단 패킷은 후술하는 도 9에서 후술할 수 있다.

진단 패킷의 사이즈(Payload), 진단 패킷간 시간(Gap Time), 진단을 위하여 한번에 주사한 후(Injection) 다음 주사까지의 시간(Interval Time), 및 한번 주사할 때 전송하는 패킷의 수(Packet Count)는 모두 분석서버(110)에서 진단 시나리오를 생성할 때 결정될 수 있다.

결정된 패킷에 대한 조건은 도 7에서와 같이 SW Agent에서 동작하여 타깃 NE에 전달되고, 진단 패킷을 전송한 통신 기기의 SW Agent는 반송된 패킷(반송 패킷)을 수신하여 그 결과를 분석할 수 있다.

도 6과 도 7을 기반으로 전송되는 진단 패킷은 도 8의 과정을 기반으로 동작하면서 타깃 NE로부터 수신한 반송된 패킷을 통해 3가지 형태로 분석될 수 있다.

첫째로, 소프트웨어 진단 에이전트는, 정상적으로 수신된 반송 패킷을 통하여 네트워크 구간별, 컨트롤 클라이언트(120)에서 타깃 NE까지, 서비스(A/B/C/D 타입)가 실행되고 있는 서버에서의 네트워크 지연시간(One-Way Delay Time, Two-Way Delay Time(RTT: Round Trip Time)), 프로세싱 지연시간, Jitter, 서비스와 유사한 형태의 패킷을 전달함으로써 상향 및 하향의 쓰루풋(UL-Throughput, DL-Throughput) 그리고 사용자 단말을 이용할 경우는 무선환경(RSRP, SRRQ, SINR, CQI)을 같이 분석할 수 있다.

둘째로, 소프트웨어 진단 에이전트는, 네트워크의 상태를 분석하며 Route Path, Hop Count, TCP Parameter, 네트워크를 구성하는 NE들의 IP정보, L3 스위치나 라우터의 Buffer(Queue) Size, MTU Size, 마이크로웨이브내 링크 Queue Size, Problematic Point의 Bandwidth를 분석할 수 있다.

세번째로, 소프트웨어 진단 에이전트는, 진단 패킷이 비정상적으로 처리된 상태를 바탕으로 Link 상태(Unreachable, Link Fluctuation), Packet Loss(Random Loss, Physical Loss), Fragmentation발생, SFP Power, UL/DL Throughput, High-RTT, Problematic Point, 서비스가 실행되는 서버에서의 Processing Delay Time Trend, Average Time Trend, 사용자 단말을 이용할 경우 무선구간의 영향인지 백홀 구간의 영향인지 판단을 수행할 수 있다.

분석 서버(110)는 컨트롤 클라이언트(120)로부터 측정 및 분석된 정보(전술한 3가지 종류의 분석정보)와 진단 로그를 빅데이터 저장을 위한 데이터베이스(140)로 수집하여 네트워크 상태, 서비스의 품질수준 및 문제점들을 종합적으로 분석할 수 있다.

또한, 분석 서버(110)는 5G 및/또는 LTE 네트워크부터 수집된(160, 50) 정보(Network Configuration, Alarm, Statistics, CSL, GTP Status)를 빅데이터 저장을 위한 데이터베이스(140) 환경으로 수집한 정보와 연계분석(Correlation, 30)하여 서비스(A/B/C/D 타입)의 품질에 영향을 미치는 위치를 구체적으로 찾거나, 다수의 사용자 단말이 접속하는 기지국의 영향 여부(RLC/MAC/PDCP 계층의 처리상태와 연계) 및 서비스(A/B/C/D 타입)품질이 저하되는 원인이 사용자 단말이 늘어나서(또는 밀집되어) 발생하는 현상인지 분석할 수 있다. 만약 사용자 단말이 늘어나서 발생한 서비스품질 저하라 할 수 있다.면 통신망을 운영하는 사업자는 통신망에 대한 용량확대 또는 서비스에 양향을 미치는 통신자원의 확장을 진행해야 할 것이다.

분석 서버(110)의 Client Manager(20)는 Scenario Maker(10)에서 생성한 진단 시나리오를 진단을 수행하는 타겟 통신 기기의 컨트롤 클라이언트(120)에 로딩할 수 있다. 로딩된 진단 시나리오는 해당 컨트롤 클라이언트(120)의 소프트웨어 진단 에이전트(130)의 동작에 적용된다.

또한, 분석 서버(110)는 소프트웨어 진단 에이전트의 동작 상태를 원격으로 모니터링하고, 현재의 진행 상태, 과거의 진단 수행 정보 및 진단 과정에서 문제점이 있었다면 그 이력을 사용자 계위(55)에 실시간으로 제공할 수 있다.

전술한 서비스유형(A/B/C/D 타입)은 서비스 유형 별 QoS기준(40) DB에 정의 및 관리될 수 있으며, 본 정보는 네트워크 운영자의 명령/입력에 의해서 수정 및 관리될 수 있다.

만약, 서비스 유형 별 QoS 기준이 변경되면, 컨트롤 클라이언트(120)에 로딩되어 소프트웨어 진단 에이전트(130)에 의해 기 수행되고 있는 진단 시나리오는 분석 서버 단에서 새로운 QoS기준을 적용하도록 업데이트 될 수 있다. 분석 서버(110) 내의 빅데이터 저장을 위한 데이터베이스(140) 환경은 특정 환경으로 국한되지 않고 다양한 형태의 빅데이터 환경을 활용할 수 있도록 지원된다.

도 8은 본 개시의 일 실시 예에 따라 5G 및/또는 LTE 네트워크에 대한 진단 로직이 정의된 것이며, 본 로직에 의해서 전술한 3가지 정보들이 측정될 수 있다.

도 8에 표현된 측정 로직은 소프트웨어 진단 에이전트(130)가 분석 서버(110)의 Client Manager(20)로부터 수신한 시나리오를 바탕으로 진단 로직을 수행하는 절차이며, 본 절차는 시나리오 또는 진단 결과에 의한 네트워크의 상태에 따라서 진단 로직의 단계를 정해진 순서가 아닌 임의의 순서로 진행할 수 있다.

한편, 도 3에서 Agent Controller는 진단하고자 하는 서비스 유형 별로 SW Agent(60) 프로세스를 생성하며, SW Agent는 진단하고자 하는 서비스 유형별 진단조건 모듈(70)과 Client Manager(20)로부터 수신한 진단 시나리오를 기반으로 최초 진단 로직 선택 모듈(80)을 생성할 수 있다. 최초 생성된 진단 로직은 도 8에 표현된 로직에 따라서 진단을 수행하며, Diagnosis Result(200)의 피드백 상태에 따라서 임의의 수서로 진단순서를 바꿀 수 있다. Data loader(90)는 컨트롤 클라이언트(120)에 실장 된 NIC를 통하여 진단 패킷을 타깃 NE에 전송하는 역할을 담당할 수 있다. 본 Data Loader는 부하 분산을 위하여 SW Agent(60) 프로세스 당 하나의 Data Loader로 구성된다.

도 9는 본 개시의 일 실시 예에 따라 사용되는 진단 패킷의 구성이 도시된 것이다. 본 진단 패킷은 전술한 것과 같이 자체 설계된 진단 패킷(도 9), ICMP(Internet Control Message Protocol), OWAMP/TWAMP(One-Way Active Measurement Protocol/Two-Way Active Measurement protocol) 등에 해당할 수 있는데, 이러한 패킷들은 서비스의 유형 및 진단하고자 하는 대상에 따라서 선택적으로 사용할 수 있고, 어떤 패킷을 사용할지에 대한 결정은 소프트웨어 진단 에이전트(130)내 SW Agent(60)에서 최초 진단 로직의 선택 까지의 과정에서 결정될 수 있다.

도 9에 도시된 바와 같이, 진단 패킷은 16비트의 컨트롤 클라이언트 ID, 2비트의 SW Agent ID, 16비트의 Target NE ID, 5비트의 Segment Indicator, 4비트의 Length, 2비트의 Diagnosis Type, 1비트의 Operation Type, Service Type, QoS 및 Payload를 포함할 수 있다.

컨트롤 클라이언트 ID는 진단을 수행하는 클라이언트를 구분하는 IP 구분자에 해당할 수 있다.(IPv4-IP주소+Option을 사용, IPv6-IP주소를 사용). SW Agent ID는 컨트롤 클라이언트에서 실행하는 복수의 Application Process들을 구분하는 구분자에 해당할 수 있다. Target NE ID는 진단의 대상인 Target NE를 구분하는 IP 구분자에 해당할 수 있다.(IPv4-IP주소+Option을 사용, IPv6-IP주소를 사용).

Segment Indicator는 진단 결과 패킷(반송 패킷)의 사이즈가 할당된 Payload 이상으로 클 경우, 분할(Segmentation)을 수행하여 각 정보를 정의하기 위한 구성이다.

Segment Flag는, 전문의 Segmentation 여부를 구분하는 식별자에 해당할 수 있다.(2: 0x0000-NoSegmnt, 0x0001-Segment). Sequence Number는 전문이 Segmentation되었을 경우, 조각된 패킷의 순번을 구분하기 위한 번호에 해당할 수 있다.(3: 0-조각되지 않음, ≥1-조각된 패킷의 전달순서번호).

Length는 전문 패킷의 크기를 기술하며, 단위는 Bytes일 수 있다.

Diagnosis 타입은 반송되는 패킷을 수신하여 분석하기 위해서 그 진단 유형(네트워크 NE상태 진단, 네트워크 Link상태진단, 서비스 상태진단, 문제점 분석진단)을 구분할 수 있다.

Operation 타입은 진단을 위한 동작 시나리오를 정의하는 구간으로 본 진단을 통하여 진단하고자 하는 도 8의 내용을 정의할 수 있다.

Service 타입은 서비스 유형을 정의할 수 있다. 서비스의 유형은, 음성 콜/VoIP 콜(1), 영상 콜/Video 콜(2), 실시간 게이밍(3), 비디오 스트리밍(4), 시그널링(5), Email/Chat/FTP 등 일반데이터(7, 300ms 지연가능), Interactive Gaming(8, 100ms 지연가능), Mission Critical Data와 같이 구분될 수 있으나, 이에 한정되지 않는다.

QoS는 진단 패킷의 QoS를 기술하며, Service 타입 및/또는 Diagnosis 타입에 따라서 패킷의 우선순위를 할당할 수 있다.

그리고, Payload는 설정된 진단 패킷의 데이터 영역을 정의하는 구간이다. Payload는 TCP 패킷에서 할당된 Window Size와 관련된 Segment 사이즈에서 진단 패킷의 구분 식별자 및 서비스 정보를 위해 할당된 영역을 제외한 크기와 동일하다.

만약 특정 서비스 유형(A/B/C/D 타입)을 진단하고자 할 경우, 도 9의 TCP Segment내 Service 타입과 QoS 필드에 내용이 반영될 수 있다.

본 개시의 일 실시 예에 따라 제안된 진단 패킷 크기(Segment Size)는 최소 64bytes이상이어야 할 수 있다. 그리고 ICMP(Internet Control Message protocol) 메시지를 이용할 경우 규격에 정의된 Echo Request, Echo Reply에 의한 Error Message등을 이용하여 정보를 분석할 수 있다. 또한 OWAMP(RFP 4656)와 TWAMP(RFC 5357)에 정의된 패킷과 정보를 통해 진단 내지는 분석이 수행될 수 있다.

도 10, 도 11, 도 12는 진단하고자 하는 네트워크 상태 및 서비스 유형에 따른 진단 방법을 바탕으로 어떻게 진단을 수행해야 하는지에 대한 진단 방법을 표현한 것이다. 네트워크 상에서 문제가 발생할 수 있는 Problematic Point에서의 대역폭(Bandwidths)과 버퍼(Buffer 또는 Queue)를 대상으로 그 크기(Size)를 측정하고자 할 때 진단하는 방법은 도 10을 이용할 수 있다. 이때 패킷 소실(Packet Loss)의 조건을 미리 정의하여 정확한 크기가 예측될 수 있도록 환경을 설정하고 조건대로 동작하도록 로직을 정립하는 것이 중요하다.

도 10의 로직을 이용한 진단은 ICMP 메시지와 본 개시에서 제안한 진단 패킷을 이용하여 측정이 진행될 수 있다.

도 10을 참조하면, 소프트웨어 진단 에이전트는, 타겟 대상인 통신 기기(NE)와의 연결 여부에 따라 딜레이를 체크할 수 있다.

딜레이가 정상인 경우, 소프트웨어 진단 에이전트는, 테스트 환경을 설정하는 한편 진단 패킷을 전송할 수 있다. 그리고, 소프트웨어 진단 에이전트는, 반송되는 패킷을 토대로 진단 정보(진단 결과)를 획득할 수 있다.

구체적인 예로, 소프트웨어 진단 에이전트의 RateLimit 진단 방법을 설명할 수 있다.

다양한 실시예레 따라, 진단 방법은, 1) 5초 이내(5회전송) PLR 발생을 기준으로, 1회에서의 PLR 무시, 4회중 3회이상 PLR 발생하는 경우, 2)20~25초 이내(20~25회전송) PLR 미발생을 기준으로, 1회에서의 PLR 무시, 3회 이하 PLR 발생은 무시하는 경우, 3)15~20초 이내(15~20회전송) PLR 발생을 기준으로, 1회에서 PLR 무시, ER의 최초 RTT_max 대비, RTT(Round Trip Time)가 증가하여 수렴 시점(4회 평균) 도달하는 경우, 4) 15~20초 이내(15~20회전송) PLR 발생을 기준으로, ER의 최초 RTT_max 대비, RTT가 증가하여 수렴 시점(4회 평균) 미 도달하는 경우 및 5)5~10초 이내(5~10회전송)PRL 발생을 기준으로, 1회에서의 PLR무시, ER의 최초 RTT_max 대비, RTT가 증가하여 수렴 시점(4회 평균) 도달하는 경우를 판단할 수 있다.

이때, 패킷 손실의 임계치는, 일 예로, PLR은 3회 연속 발생해야 유효(QoS처리)로 인식될 수 있으며, PLR 기준 = 5% 이상 발생인 경우 유효(QoS처리)로 인식될 수도 있다.

도 11은 서비스 유형(A/B/C/D 타입)에 따른 네트워크, 링크, 서비스 지연 및 패킷 소실의 현상이 발생하는지에 대한 진단 로직을 표현하였으며, 도 11의 진단 로직을 통해 패킷 소실, 서비스 지연, 링크 커넥션 상태 및 이상 동작에 따른 분석 정보가 확인될 수 있다.

도 11과 같은 진단 과정에서 패킷 소실이 발견될 경우, 소프트웨어 진단 에이전트는 도 12의 진단 로직을 이용하여 추가적인 진단을 진행하며, 서비스 유형에 맞추어 QoS를 설정한 진단에서 Delay 또는 속도저하(Low Throughput)가 발생할 경우 도 10의 방법을 이용하여 대역폭과 버퍼의 크기를 진단할 수 있다. 또한, 소프트웨어 진단 에이전트는, 진단결과의 누적을 통하여 혼잡시간(Busy Hour)대의 품질과 비교할 수 있도록 진단 정보를 분석 서버(110)로 전달할 수 있다.

도 12를 참조하면, 진단 과정에서 패킷 소실(Packet Loss)이 발생한 경우, 소프트웨어 진단 에이전트는, 패킷 소실의 유형(Random Loss or Physical Loss)을 구분하고, 해당 유형에 맞는 진단을 수행할 수 있다. 또한, 소프트웨어 진단 에이전트는, 진단의 결과를 이용하여 문제점을 분석할 수 있는 정보를 취합하고, 만약 문제점이 없는 것으로 예측되면 도 10의 로직을 이용하여 대역폭과 버퍼의 크기를 진단할 수 있다.

구체적으로, 패킷 소실의 유형이 Random Loss인 경우, 소프트웨어 진단 네트워크는 Long Term Test를 통해 패킷 손실의 테스트 카운트를 판단할 수 있다. 이때, 테스트 카운트가 3 초과인 경우, 소프트웨어 진단 에이전트는 스위치/라우터 및 네트워크의 상태가 정상인지 판단할 수 있다. 스위치/라우터 및 네트워크의 상태가 정상인 경우, 또는 테스트 카운트가 3 이하인 경우, 소프트웨어 진단 네트워크는 문제점이 없는 것으로 판단하여 도 10의 로직을 이용하여 대역폭과 버퍼의 크기를 진단할 수 있다.

또 다른 예로, 패킷 소실의 유형이 Physical Loss인 경우, 소프트웨어 진단 네트워크는 Short Term Test를 통해 패킷 손실의 테스트 카운트를 판단할 수 있다. 이때, 테스트 카운트가 3 초과인 경우, 소프트웨어 진단 에이전트는 스위치/라우터 및 네트워크의 상태가 정상인지 판단할 수 있다. 스위치/라우터 및 네트워크의 상태가 정상인 경우, 또는 테스트 카운트가 3 이하인 경우, 소프트웨어 진단 네트워크는 문제점이 없는 것으로 판단하여 도 10의 로직을 이용하여 대역폭과 버퍼의 크기를 진단할 수 있다.

일 실시예에 따라, 패킷 소실이 일반적인 소실일 경우, ER 및 iperf 중 적어도 하나를 수행하고, 혼잡시간 소실일 경우, Buffer Size 및 Rate Limit를 예측한 후 ER 및 iperf 중 적어도 하나를 수행할 수 있다. 또 다른 실시예로, Hop별 패킷 소실 테스트는 TTL 또는 mtr 중 적어도 하나를 수행하여 이뤄질 수 있다.

컨트롤 클라이언트(120)에서 동작한 소프트웨어 진단 에이전트(130)는 진단을 수행할 또는 수행하고 있는 진단 시나리오에 대한 진단 시작, 진단 진행 중(지행사항포함), 진단 완료, 진단 중 발생한 이벤트, 진단 대상 타깃 NE 등에 대한 정보를 로그 형태로 분석 서버(110) 내 Client Manager(20)에게 실시간으로 보고할 수 있다.

이렇듯, 본 개시에 따른 5G 및/또는 LTE 네트워크의 네트워크 진단 시스템은, 기존의 전용 프로토콜 분석기나 전용의 측정기와 같은 별도의 장치를 필요로 하지 않으며, OS(Operating System)에 관계없이 동작하는 소프트웨어 진단 에이전트(130)를 이용함으로써 네트워크 운영자의 진단 업무를 매우 간단하고 편리하게 할 수 있다는 장점이 있다. 특히, 본 개시에 따른 네트워크 진단 시스템이 이용되는 경우, 네트워크 운영자는 네트워크에 대한 깊은 이해도가 없어도 진단과 문제의 원인을 확인하고 대처할 수 있으며, 비용 면에서 높은 효과가 있다.

한편, 이상에서 설명된 다양한 실시 예들은 서로 양립될 수 없는 것이 아닌 한 둘 이상이 함께/동시에 구현될 수 있다.

한편, 이상에서 설명된 다양한 실시 예들은 소프트웨어(software), 하드웨어(hardware) 또는 이들의 조합된 것을 이용하여 컴퓨터(computer) 또는 이와 유사한 장치로 읽을 수 있는 기록 매체 내에서 구현될 수 있다.

하드웨어적인 구현에 의하면, 본 개시에서 설명되는 실시 예들은 ASICs(Application Specific Integrated Circuits), DSPs(digital signal processors), DSPDs(digital signal processing devices), PLDs(programmable logic devices), FPGAs(field programmable gate arrays), 프로세서(processors), 제어기(controllers), 마이크로 컨트롤러(micro-controllers), 마이크로 프로세서(microprocessors), 기타 기능 수행을 위한 전기적인 유닛(unit) 중 적어도 하나를 이용하여 구현될 수 있다.

일부의 경우에 본 명세서에서 설명되는 실시 예들이 프로세서 자체로 구현될 수 있다. 소프트웨어적인 구현에 의하면, 본 명세서에서 설명되는 절차 및 기능과 같은 실시 예들은 별도의 소프트웨어 모듈들로 구현될 수 있다. 상술한 소프트웨어 모듈들 각각은 본 명세서에서 설명되는 하나 이상의 기능 및 작동을 수행할 수 있다.

한편, 상술한 본 개시의 다양한 실시 예들에 따른 다양한 기기에서의 처리동작을 수행하기 위한 컴퓨터 명령어(computer instructions) 또는 컴퓨터 프로그램은 비일시적 컴퓨터 판독 가능 매체(non-transitory computer-readable medium)에 저장될 수 있다. 이러한 비일시적 컴퓨터 판독 가능 매체에 저장된 컴퓨터 명령어 또는 컴퓨터 프로그램은 특정 기기의 프로세서에 의해 실행되었을 때 상술한 다양한 실시 예에 따른 통신 기기/시스템에서의 처리 동작을 상술한 특정 기기가 수행하도록 할 수 있다.

비일시적 컴퓨터 판독 가능 매체란 레지스터, 캐쉬, 메모리 등과 같이 짧은 순간 동안 데이터를 저장하는 매체가 아니라 반영구적으로 데이터를 저장하며, 기기에 의해 판독(reading)이 가능한 매체를 의미할 수 있다. 비일시적 컴퓨터 판독 가능 매체의 구체적인 예로는, CD, DVD, 하드 디스크, 블루레이 디스크, USB, 메모리카드, ROM 등이 있을 수 있다.

이상에서는 본 개시의 바람직한 실시 예에 대하여 도시하고 설명하였지만, 본 개시는 상술한 특정의 실시 예에 한정되지 아니하며, 청구범위에서 청구하는 본 개시의 요지를 벗어남이 없이 당해 개시에 속하는 기술분야에서 통상의 지식을 가진 자에 의해 다양한 변형실시가 가능한 것은 물론이고, 이러한 변형실시들은 본 개시의 기술적 사상이나 전망으로부터 개별적으로 이해되어서는 안될 것이다.

110: 분석서버
120: 컨트롤 클라이언트
130: 소프트웨어 진단 에이전트
140: 데이터베이스

Claims (7)

1. 사용자 단말, 기지국, 엣지 클라우드(Edge Cloud), 및 센터 클라우드(Center Cloud)를 포함하는 네트워크의 진단 시스템에 있어서,
   상기 사용자 단말, 상기 기지국, 상기 엣지 클라우드, 및 상기 센터 클라우드 각각에 구비되고, 하나 이상의 소프트웨어 진단 에이전트와 연동된, 컨트롤 클라이언트; 및
   상기 소프트웨어 진단 에이전트의 진단 시나리오를 설정하는, 분석 서버;를 포함하고,
   상기 소프트웨어 진단 에이전트는,
   상기 사용자 단말, 상기 기지국, 상기 엣지 클라우드, 및 상기 센터 클라우드 간의 연결 관계에 따라 구분된 복수의 네트워크 구간 별로, 진단 정보를 생성하고,
   상기 소프트웨어 진단 에이전트는,
   상기 복수의 네트워크 구간 중 적어도 하나의 네트워크 구간 내에서 일 방향으로 진단 패킷을 전달하고,
   상기 진단 패킷이 전달됨에 따라 반송된 반송 패킷을 기반으로, 상기 진단 정보를 생성하고,
   상기 소프트웨어 진단 에이전트는,
   상기 반송된 반송 패킷에 따라 특정 네트워크 구간 내에서 패킷 소실이 발생한 것으로 식별된 경우, 진단 중 발생한 이벤트에 대한 정보 및 상기 네트워크 구간에 포함되는 통신 기기에 대한 정보를 상기 분석 서버로 전송하고,
   상기 소프트웨어 진단 에이전트는,
   진단 과정에서 패킷 소실(Packet Loss)이 발생한 경우, 패킷 소실의 유형(Random Loss or Physical Loss)을 구분하고, 해당 유형에 맞는 진단을 수행하고,
   상기 소프트웨어 진단 에이전트는,
   패킷 소실의 유형이 Random Loss인 경우, Long Term Test를 통해 패킷 손실의 테스트 카운트를 판단하고, 테스트 카운트가 3 초과인 경우 스위치/라우터 및 네트워크의 상태가 정상인지 판단하고, 테스트 카운트가 3이하이거나 스위치/라우터 및 네트워크의 상태가 정상이면 대역폭과 버퍼의 크기를 진단하고,
   상기 소프트웨어 진단 에이전트는,
   패킷 소실의 유형이 Physical Loss인 경우, Short Term Test를 통해 패킷 손실의 테스트 카운트를 판단하고, 테스트 카운트가 3 초과인 경우 스위치/라우터 및 네트워크의 상태가 정상인지 판단하고, 테스트 카운트가 3이하이거나 스위치/라우터 및 네트워크의 상태가 정상이면 대역폭과 버퍼의 크기를 진단하고,
   상기 진단 패킷은,
   타겟 통신 기기에 대한 정보 및 상기 타겟 통신 기기까지 전달되는 과정에서의 Routing Path에 따른 Hop count에 대한 정보를 각각 포함하고,
   상기 진단 패킷은
   진단을 수행하는 클라이언트를 구분하는 IP 구분자에 해당 컨트롤 클라이언트 ID, 컨트롤 클라이언트에서 실행하는 복수의 Application Process들을 구분하는 구분자에 해당하는 SW Agent ID, 진단의 대상인 Target NE를 구분하는 IP 구분자에 해당하는 Target NE ID, 진단 결과 패킷(반송 패킷)의 사이즈가 할당된 Payload 이상으로 클 경우 분할(Segmentation)을 수행하여 각 정보를 정의하기 위한 Segment Indicator, 전문의 분할(Segmentation) 여부를 구분하는 식별자에 해당하는 Segment Flag, 전문 패킷의 크기를 기술하는 Length, 진단 유형을 네트워크 NE 상태 진단, 네트워크 Link 상태 진단, 서비스 상태 진단 및 문제점 분석 진단 중 어느 하나로 구분하는 Diagnosis 타입, 진단을 위한 동작 시나리오를 정의하는 Operation 타입, 음성 콜/VoIP 콜, 영상 콜/Video 콜, 실시간 게이밍, 비디오 스트리밍, 시그널링, 일반데이터, Interactive Gaming 및 Mission Critical Data로 구분되는 서비스 유형을 정의하는 Service 타입, 상기 Service 타입 및 상기 Diagnosis 타입 중 하나 이상에 따라서 우선순위가 할당되는 QoS을 포함하는, 네트워크의 진단 시스템.
   
2. 삭제
3. ◈청구항 3은(는) 설정등록료 납부시 포기되었습니다.◈

   제1항에 있어서,
   상기 소프트웨어 진단 에이전트는,
   적어도 하나의 네트워크 구간 내에서 상방향으로 진단 패킷을 전달함에 따라 반송된 반송 패킷을 기반으로, 제1 진단 정보를 생성하고,
   적어도 하나의 네트워크 구간 내에서 하방향으로 진단 패킷을 전달함에 따라 반송된 반송 패킷을 기반으로, 제2 진단 정보를 생성하는, 네트워크의 진단 시스템.
4. ◈청구항 4은(는) 설정등록료 납부시 포기되었습니다.◈

   제3항에 있어서,
   상기 소프트웨어 진단 에이전트는,
   상기 사용자 단말로부터 상기 기지국, 상기 엣지 클라우드, 및 상기 센터 클라우드 중 적어도 하나로 진단 패킷을 전달하고, 상기 사용자 단말로부터 상기 진단 패킷이 전달된 이후 상기 사용자 단말로 반송된 반송 패킷에 따라 상기 제1 진단 정보를 생성하는, 네트워크의 진단 시스템.
5. 삭제
6. 제1항에 있어서,
   상기 소프트웨어 진단 에이전트는,
   상기 진단 패킷이 타겟 통신 기기로 전달될 수 없는 경우, Routing Path에 따라 상기 타겟 통신 기기를 변경하고,
   상기 변경된 타겟 통신 기기에 대한 진단 정보를 생성하는, 네트워크의 진단 시스템.
7. 제1항에 있어서,
   상기 소프트웨어 진단 에이전트는,
   서비스 유형에 매칭되는 진단 시나리오에 따라 적어도 하나의 진단 패킷을 선택하고,
   적어도 하나의 네트워크 구간 내에서 상기 선택된 진단 패킷을 전달하여 상기 진단 정보를 생성하는, 네트워크의 진단 시스템.
   

Images