KR102408248B1 - 서비스 유형에 매칭되는 진단 패킷을 통해 네트워크에 대한 진단을 수행하는 진단 시스템 - Google Patents

서비스 유형에 매칭되는 진단 패킷을 통해 네트워크에 대한 진단을 수행하는 진단 시스템 Download PDF

Info

Publication number
KR102408248B1
KR102408248B1 KR1020210099931A KR20210099931A KR102408248B1 KR 102408248 B1 KR102408248 B1 KR 102408248B1 KR 1020210099931 A KR1020210099931 A KR 1020210099931A KR 20210099931 A KR20210099931 A KR 20210099931A KR 102408248 B1 KR102408248 B1 KR 102408248B1
Authority
KR
South Korea
Prior art keywords
diagnostic
packet
network
diagnosis
software
Prior art date
Application number
KR1020210099931A
Other languages
English (en)
Inventor
서원복
이재현
홍봉기
이윤
Original Assignee
엔에스원소프트 주식회사
Priority date (The priority date is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the date listed.)
Filing date
Publication date
Application filed by 엔에스원소프트 주식회사 filed Critical 엔에스원소프트 주식회사
Priority to KR1020210099931A priority Critical patent/KR102408248B1/ko
Priority to KR1020220069341A priority patent/KR102443588B1/ko
Application granted granted Critical
Publication of KR102408248B1 publication Critical patent/KR102408248B1/ko

Links

Images

Classifications

    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L43/00—Arrangements for monitoring or testing data switching networks
    • H04L43/50—Testing arrangements
    • H04L43/55—Testing of service level quality, e.g. simulating service usage
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L41/00—Arrangements for maintenance, administration or management of data switching networks, e.g. of packet switching networks
    • H04L41/14—Network analysis or design
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L41/00—Arrangements for maintenance, administration or management of data switching networks, e.g. of packet switching networks
    • H04L41/50—Network service management, e.g. ensuring proper service fulfilment according to agreements
    • H04L41/5032—Generating service level reports
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L43/00—Arrangements for monitoring or testing data switching networks
    • H04L43/08—Monitoring or testing based on specific metrics, e.g. QoS, energy consumption or environmental parameters
    • H04L43/091—Measuring contribution of individual network components to actual service level
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L43/00—Arrangements for monitoring or testing data switching networks
    • H04L43/10—Active monitoring, e.g. heartbeat, ping or trace-route

Landscapes

  • Engineering & Computer Science (AREA)
  • Computer Networks & Wireless Communication (AREA)
  • Signal Processing (AREA)
  • Quality & Reliability (AREA)
  • Data Exchanges In Wide-Area Networks (AREA)
  • Health & Medical Sciences (AREA)
  • Cardiology (AREA)
  • General Health & Medical Sciences (AREA)
  • Environmental & Geological Engineering (AREA)
  • Computer Security & Cryptography (AREA)

Abstract

본 개시는 사용자 단말, 기지국, 엣지 클라우드(Edge Cloud), 및 센터 클라우드(Center Cloud)를 포함하는 네트워크를 진단하는 진단 시스템을 개시할 수 있다. 본 진단 시스템은, 사용자 단말, 기지국, 엣지 클라우드, 및 센터 클라우드 각각에 구비되고, 하나 이상의 소프트웨어 진단 에이전트와 연동된, 컨트롤 클라이언트, 소프트웨어 진단 에이전트의 진단 시나리오를 설정하는, 분석 서버를 포함할 수 있다. 소프트웨어 진단 에이전트는, 서비스의 유형 별로 정의된 복수의 진단 패킷을 포함하고, 복수의 진단 패킷 중 네트워크를 통해 제공되는 서비스의 유형에 매칭되는 진단 패킷을 선택하고, 네트워크에 포함된 적어도 하나의 네트워크 구간 내 선택된 진단 패킷의 전달을 제어하여, 진단 정보를 생성할 수 있다.

Description

서비스 유형에 매칭되는 진단 패킷을 통해 네트워크에 대한 진단을 수행하는 진단 시스템 { DIAGNOSTIC SYSTEM FOR PERFORMING DIAGNOSTICS OF NETWORK THROUGH DIAGNOSTIC PACKET MATCHING TO SERVICE TYPE }
본 개시는 5G 및/또는 LTE 네트워크의 진단 시스템에 관한 것으로, 보다 상세하게는, 서비스 유형에 맞는 진단 패킷을 통해 네트워크의 구간 별로 진단을 수행하는 진단 시스템에 관한 것이다.
5G 통신 시스템은 초저지연, 초고용량, 초다연결을 제공하는 새로운 이동통신 네트워크이다. 5G 통신 시스템은 무선 액세스 네트워크(RAN: Radio Access Network)와 코어 네트워크(Core Network)으로 구분된다.
무선 액세스 네트워크는 가입자의 무선 접속 기능을 제공한다. 그리고 코어 네트워크는 단말의 세션 관리, 가입자 인증, 이동성 관리 등의 다양한 제어 기능과 단말과 서비스 어플리케이션 간 사용자 트래픽 전달 기능을 수행한다.
5G 통신 시스템에서는 LTE 등 기존 망의 중앙 집중식 구조와는 달리 지역별로 분산된 엣지 클라우드를 기반으로, UPF(User Plane Function) 및 MEC(Mobile Edge Computing) 내 서비스 서버가 분리 구축되어 있는 구조를 가진다.
이러한 5G 통신 시스템은 지역적으로 분산 구축되어 있는 엣지 클라우드(Edge Cloud)를 기반으로 고용량, 초저지연 실시간 스트리밍 서비스를 고객 단말에 제공한다. 5G 통신 시스템를 통해 실시간 스트리밍 서비스를 고객의 단말에 제공할 때, 실제 고객 단말에서 체감하는 고객 경험(User Experience)을 향상시키는 것이 중요하다.
5G 통신 시스템에서 제공하는 서비스는 AR/VR 서비스, 무인 자동차, 스마트 팩토리 및 수술 로봇 장치 등에 적용되는 초저지연 통신 서비스 및 IoT 서비스 등으로써, 이러한 서비스들에 의해 네트워크의 트래픽이 폭증하여 서비스 품질의 저하가 발생되고 있다.
통상적으로 네트워크 기반의 품질 관리는, 송수신되는 패킷들에 대한 패킷 손실(loss)이나 지연(delay) 등의 감지를 통하여 이루어졌었는데, 종래의 품질 관리는 제공되는 서비스의 종류와 관계없이 동일한 패킷을 이용함으로써, 네트워크에 의해 제공되는 서비스에 최적화된 네트워크 품질 관리를 달성하지 못하는 문제점이 있다.
공개특허공보 제10-2017-0092878호(백홀 망의 쓰루풋 측정 방법 및 장치)
본 개시는, 5G 네트워크 또는 5G와 LTE(Long Term Evolution)를 연계한 네트워크를 기반으로 제공되는 서비스의 품질에 영향을 주는 네트워크 문제점을 자동으로 진단하고, 네트워크의 품질 수준을 분석하는 진단 시스템을 제공한다.
특히, 본 개시는, 서비스의 유형에 따라 진단 패킷을 선택하고, 선택된 진단 패킷을 다양한 네트워크 구간 상에서 상 방향 또는 하 방향으로 전달한 뒤 반송되는 패킷을 통해 진단을 수행하는 진단 시스템을 제공한다.
본 개시의 목적들은 이상에서 언급한 목적으로 제한되지 않으며, 언급되지 않은 본 개시의 다른 목적 및 장점들은 하기의 설명에 의해서 이해될 수 있고, 본 개시의 실시 예에 의해 보다 분명하게 이해될 것이다. 또한, 본 개시의 목적 및 장점들은 특허 청구 범위에 나타낸 수단 및 그 조합에 의해 실현될 수 있음을 쉽게 알 수 있을 것이다.
본 개시의 일 실시 예에 따라, 사용자 단말, 기지국, 엣지 클라우드(Edge Cloud), 및 센터 클라우드(Center Cloud)를 포함하는 네트워크를 진단하는, 진단 시스템은, 상기 사용자 단말, 상기 기지국, 상기 엣지 클라우드, 및 상기 센터 클라우드 각각에 구비되고, 하나 이상의 소프트웨어 진단 에이전트와 연동된, 컨트롤 클라이언트, 상기 소프트웨어 진단 에이전트의 진단 시나리오를 설정하는, 분석 서버를 포함한다. 상기 소프트웨어 진단 에이전트는, 서비스의 유형 별로 정의된 복수의 진단 패킷을 포함하고, 상기 복수의 진단 패킷 중 상기 네트워크를 통해 제공되는 서비스의 유형에 매칭되는 진단 패킷을 선택하고, 상기 네트워크에 포함된 적어도 하나의 네트워크 구간 내 상기 선택된 진단 패킷의 전달을 제어하여, 진단 정보를 생성한다.
상기 진단 패킷은, 컨트롤 클라이언트의 ID, 소프트웨어 진단 에이전트의 ID, 타겟 통신 기기의 ID, 진단 유형에 대한 정보, 및 서비스 유형에 대한 정보를 포함할 수 있다.
또한, 상기 진단 패킷은, 타겟 통신 기기에 대한 정보 및 상기 타겟 통신 기기까지 전달되는 과정에서의 Routing Path에 따른 Hop count에 대한 정보를 각각 포함할 수 있다. 이 경우, 상기 소프트웨어 진단 에이전트는, 상기 진단 패킷이 상기 타겟 통신 기기로 전달될 수 없는 경우, Routing Path에 따라 타겟 통신 기기를 변경하고, 상기 변경된 타겟 통신 기기에 대한 진단 정보를 생성할 수 있다.
상기 복수의 진단 패킷은, 서비스의 유형에 따라 진단 패킷의 QoS, 단위 시간 내 전달되는 패킷 수, 패킷에 대한 injection count, 패킷 간 interval time, injection을 위한 Gap time, 및 payload size 중 적어도 하나가 다르게 설정될 수 있다.
한편, 상기 소프트웨어 진단 에이전트는, 상기 복수의 네트워크 구간 중 적어도 하나의 네트워크 구간 내에서 일 방향으로 진단 패킷을 전달하고, 상기 진단 패킷이 전달됨에 따라 반송된 반송 패킷을 기반으로, 상기 진단 정보를 생성할 수 있다.
이 경우, 상기 소프트웨어 진단 에이전트는, 적어도 하나의 네트워크 구간 내에서 상방향으로 진단 패킷을 전달함에 따라 반송된 반송 패킷을 기반으로, 제1 진단 정보를 생성하고, 적어도 하나의 네트워크 구간 내에서 하방향으로 진단 패킷을 전달함에 따라 반송된 반송 패킷을 기반으로, 제2 진단 정보를 생성할 수 있다.
구체적으로, 상기 소프트웨어 진단 에이전트는, 상기 사용자 단말로부터 상기 기지국, 상기 엣지 클라우드, 및 상기 센터 클라우드 중 적어도 하나로 진단 패킷을 전달하고, 상기 사용자 단말로부터 상기 진단 패킷이 전달된 이후 상기 사용자 단말로 반송된 반송 패킷에 따라 상기 제1 진단 정보를 생성할 수 있다.
상기 소프트웨어 진단 에이전트는, 상기 사용자 단말, 상기 기지국, 상기 엣지 클라우드, 및 상기 센터 클라우드 간의 연결 관계에 따라 구분된 복수의 네트워크 구간 별로, 상기 진단 패킷의 전달을 제어하여 진단 정보를 생성할 수 있다.
기존의 네트워크 품질 진단 기술은, 전용의 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 (8)

  1. 사용자 단말, 기지국, 엣지 클라우드(Edge Cloud), 및 센터 클라우드(Center Cloud)를 포함하는 네트워크의 진단 시스템에 있어서,
    상기 사용자 단말, 상기 기지국, 상기 엣지 클라우드, 및 상기 센터 클라우드 각각에 구비되고, 하나 이상의 소프트웨어 진단 에이전트와 연동된, 컨트롤 클라이언트; 및
    상기 소프트웨어 진단 에이전트의 진단 시나리오를 설정하는, 분석 서버;를 포함하고,
    상기 소프트웨어 진단 에이전트는,
    서비스의 유형 별로 정의된 복수의 진단 패킷을 포함하고,
    상기 복수의 진단 패킷 중 상기 네트워크를 통해 제공되는 서비스의 유형에 매칭되는 진단 패킷을 선택하고,
    상기 네트워크에 포함된 적어도 하나의 네트워크 구간 내 상기 선택된 진단 패킷의 전달을 제어하여, 진단 정보를 생성하고,
    상기 진단 패킷은
    진단을 수행하는 클라이언트를 구분하는 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를 포함하고,
    상기 진단 패킷은,
    타겟 통신 기기에 대한 정보 및 상기 타겟 통신 기기까지 전달되는 과정에서의 Routing Path에 따른 Hop count에 대한 정보를 더 포함하고,
    상기 진단 패킷은,
    서비스의 유형에 따라 진단 패킷의 QoS, 단위 시간 내 전달되는 패킷 수, 패킷에 대한 injection count, 패킷 간 interval time, injection을 위한 Gap time, 및 payload size 중 적어도 하나가 다른 진단 패킷과 다르게 설정되고,
    상기 소프트웨어 진단 에이전트는,
    상기 반송된 반송 패킷에 따라 특정 네트워크 구간 내에서 패킷 소실이 발생한 것으로 식별된 경우, 진단 중 발생한 이벤트에 대한 정보 및 상기 네트워크 구간에 포함되는 통신 기기에 대한 정보를 상기 분석 서버로 전송하고,
    상기 소프트웨어 진단 에이전트는,
    진단 과정에서 패킷 소실(Packet Loss)이 발생한 경우, 패킷 소실의 유형(Random Loss or Physical Loss)을 구분하고, 해당 유형에 맞는 진단을 수행하고,
    상기 소프트웨어 진단 에이전트는,
    패킷 소실의 유형이 Random Loss인 경우, Long Term Test를 통해 패킷 손실의 테스트 카운트를 판단하고, 테스트 카운트가 3 초과인 경우 스위치/라우터 및 네트워크의 상태가 정상인지 판단하고, 테스트 카운트가 3이하이거나 스위치/라우터 및 네트워크의 상태가 정상이면 대역폭과 버퍼의 크기를 진단하고,
    상기 소프트웨어 진단 에이전트는,
    패킷 소실의 유형이 Physical Loss인 경우, Short Term Test를 통해 패킷 손실의 테스트 카운트를 판단하고, 테스트 카운트가 3 초과인 경우 스위치/라우터 및 네트워크의 상태가 정상인지 판단하고, 테스트 카운트가 3이하이거나 스위치/라우터 및 네트워크의 상태가 정상이면 대역폭과 버퍼의 크기를 진단하는, 네트워크의 진단 시스템.
  2. 삭제
  3. ◈청구항 3은(는) 설정등록료 납부시 포기되었습니다.◈
    제1항에 있어서,
    상기 소프트웨어 진단 에이전트는,
    상기 진단 패킷이 상기 타겟 통신 기기로 전달될 수 없는 경우, Routing Path에 따라 타겟 통신 기기를 변경하고,
    상기 변경된 타겟 통신 기기에 대한 진단 정보를 생성하는, 네트워크의 진단 시스템.
  4. 삭제
  5. 제1항에 있어서,
    상기 소프트웨어 진단 에이전트는,
    상기 복수의 네트워크 구간 중 적어도 하나의 네트워크 구간 내에서 일 방향으로 진단 패킷을 전달하고,
    상기 진단 패킷이 전달됨에 따라 반송된 반송 패킷을 기반으로, 상기 진단 정보를 생성하는, 네트워크의 진단 시스템.
  6. 제5항에 있어서,
    상기 소프트웨어 진단 에이전트는,
    적어도 하나의 네트워크 구간 내에서 상방향으로 진단 패킷을 전달함에 따라 반송된 반송 패킷을 기반으로, 제1 진단 정보를 생성하고,
    적어도 하나의 네트워크 구간 내에서 하방향으로 진단 패킷을 전달함에 따라 반송된 반송 패킷을 기반으로, 제2 진단 정보를 생성하는, 네트워크의 진단 시스템.
  7. 제6항에 있어서,
    상기 소프트웨어 진단 에이전트는,
    상기 사용자 단말로부터 상기 기지국, 상기 엣지 클라우드, 및 상기 센터 클라우드 중 적어도 하나로 진단 패킷을 전달하고, 상기 사용자 단말로부터 상기 진단 패킷이 전달된 이후 상기 사용자 단말로 반송된 반송 패킷에 따라 상기 제1 진단 정보를 생성하는, 네트워크의 진단 시스템.
  8. ◈청구항 8은(는) 설정등록료 납부시 포기되었습니다.◈
    제1항에 있어서,
    상기 소프트웨어 진단 에이전트는,
    상기 사용자 단말, 상기 기지국, 상기 엣지 클라우드, 및 상기 센터 클라우드 간의 연결 관계에 따라 구분된 복수의 네트워크 구간 별로, 상기 진단 패킷의 전달을 제어하여 진단 정보를 생성하는, 네트워크의 진단 시스템.
KR1020210099931A 2021-07-29 2021-07-29 서비스 유형에 매칭되는 진단 패킷을 통해 네트워크에 대한 진단을 수행하는 진단 시스템 KR102408248B1 (ko)

Priority Applications (2)

Application Number Priority Date Filing Date Title
KR1020210099931A KR102408248B1 (ko) 2021-07-29 2021-07-29 서비스 유형에 매칭되는 진단 패킷을 통해 네트워크에 대한 진단을 수행하는 진단 시스템
KR1020220069341A KR102443588B1 (ko) 2021-07-29 2022-06-08 진단 과정에서 발생하는 패킷 소실의 유형에 따른 네트워크에 대한 진단을 수행하는 진단 시스템

Applications Claiming Priority (1)

Application Number Priority Date Filing Date Title
KR1020210099931A KR102408248B1 (ko) 2021-07-29 2021-07-29 서비스 유형에 매칭되는 진단 패킷을 통해 네트워크에 대한 진단을 수행하는 진단 시스템

Related Child Applications (1)

Application Number Title Priority Date Filing Date
KR1020220069341A Division KR102443588B1 (ko) 2021-07-29 2022-06-08 진단 과정에서 발생하는 패킷 소실의 유형에 따른 네트워크에 대한 진단을 수행하는 진단 시스템

Publications (1)

Publication Number Publication Date
KR102408248B1 true KR102408248B1 (ko) 2022-06-13

Family

ID=81983959

Family Applications (2)

Application Number Title Priority Date Filing Date
KR1020210099931A KR102408248B1 (ko) 2021-07-29 2021-07-29 서비스 유형에 매칭되는 진단 패킷을 통해 네트워크에 대한 진단을 수행하는 진단 시스템
KR1020220069341A KR102443588B1 (ko) 2021-07-29 2022-06-08 진단 과정에서 발생하는 패킷 소실의 유형에 따른 네트워크에 대한 진단을 수행하는 진단 시스템

Family Applications After (1)

Application Number Title Priority Date Filing Date
KR1020220069341A KR102443588B1 (ko) 2021-07-29 2022-06-08 진단 과정에서 발생하는 패킷 소실의 유형에 따른 네트워크에 대한 진단을 수행하는 진단 시스템

Country Status (1)

Country Link
KR (2) KR102408248B1 (ko)

Citations (3)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
KR20070049445A (ko) * 2005-11-08 2007-05-11 포스데이타 주식회사 휴대 인터넷 시스템의 무선 네트워크 서비스 품질 진단 시스템 및 그 진단 방법
KR20170092878A (ko) 2016-02-04 2017-08-14 주식회사 큐셀네트웍스 백홀 망의 쓰루풋 측정 방법 및 장치
KR20180127816A (ko) * 2017-05-22 2018-11-30 삼성전자주식회사 통신 시스템에서 네트워크 품질 관리를 위한 방법 및 장치

Patent Citations (3)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
KR20070049445A (ko) * 2005-11-08 2007-05-11 포스데이타 주식회사 휴대 인터넷 시스템의 무선 네트워크 서비스 품질 진단 시스템 및 그 진단 방법
KR20170092878A (ko) 2016-02-04 2017-08-14 주식회사 큐셀네트웍스 백홀 망의 쓰루풋 측정 방법 및 장치
KR20180127816A (ko) * 2017-05-22 2018-11-30 삼성전자주식회사 통신 시스템에서 네트워크 품질 관리를 위한 방법 및 장치

Also Published As

Publication number Publication date
KR102443588B1 (ko) 2022-09-15

Similar Documents

Publication Publication Date Title
US10965558B2 (en) Method and system for effective data collection, aggregation, and analysis in distributed heterogeneous communication network
US11438781B2 (en) Contextual quality of user experience analysis using equipment dynamics
CN106850337B (zh) 一种网络质量检测方法及装置
US20030225549A1 (en) Systems and methods for end-to-end quality of service measurements in a distributed network environment
US9712400B1 (en) System, method, and computer program for selecting from among available network access points based on an associated quality of experience for use by a client device to access a network
US11336545B2 (en) Network device measurements employing white boxes
EP3756413B1 (en) Method and system for controlling an operation of a communication network to reduce latency
US11665531B2 (en) End to end troubleshooting of mobility services
US20220286402A1 (en) Method and apparatus for controlling data packet sending, model training method and apparatus, and system
US10841193B2 (en) Monitoring quality of service
US8976689B2 (en) Methods, systems, and computer program products for monitoring network performance
EP3398368A1 (en) Contextual quality of user experience analysis using equipment dynamics
US20220247651A1 (en) System and method for network and computation performance probing for edge computing
CN112671662B (zh) 数据流加速方法、电子设备和存储介质
KR102408248B1 (ko) 서비스 유형에 매칭되는 진단 패킷을 통해 네트워크에 대한 진단을 수행하는 진단 시스템
CN111200520A (zh) 网络监控方法、服务器和计算机可读存储介质
KR102377791B1 (ko) 네트워크 내 복수의 네트워크 구간 별로 양방향의 진단을 수행하는 진단 시스템
US7917611B2 (en) Method and system for monitoring the quality of service in telecommunication networks, components and compute products thereof
KR102370114B1 (ko) 지능형 네트워크 관리 시스템의 정보묶음 생성관리 장치 및 그 방법
US20230100981A1 (en) Method for determining a quality of service parameter, computer-readable storage medium, computer program, and communication device
US20220224615A1 (en) Latency Assurance Method, System, and Apparatus, Computing Device, and Storage Medium
CN110324163B (zh) 一种数据传输的方法及相关装置
Mj et al. Mechanism of context-aware and adaptive data collection, aggregation and analysis

Legal Events

Date Code Title Description
A107 Divisional application of patent
GRNT Written decision to grant