KR100762557B1 - 호출 트래픽 과부하 관리 방법 및 장치 - Google Patents

Abstract

동적 트래픽 관리 방법 및 장치가 지능형 네트워크(IN) 시스템에 제공된다. 본 발명은 전화 통신 시스템 기술자에 의하여 수동으로 개입될 필요없이 IN에서 SCP에 의하여 SSP에 대해 동적이며, 실시간의 트래픽 관리를 제공한다. 트래픽 관리 이슈는 교환기로부터 지능형 네트워크 노드로 옮겨졌고, 그에 의하여 지능형 네트워크가 더욱 중요해진다.

Description

호출 트래픽 과부하 관리 방법 및 장치{DYNAMIC TRAFFIC MANAGEMENT IN AN INTELLIGENT NETWORK OF A TELEPHONE SYSTEM}

도 1은 공지된 INAP 동작을 이용하는 트래픽 관리를 도시하는 도면,

도 2는 본 발명에 따르는 동작을 이용하는 트래픽 관리를 도시하는 도면,

도 3은 임계치에 근거한 트래픽 관리 시퀀스의 흐름도,

도 4는 시간 지속 트래픽 관리 시퀀스의 흐름도.

본 발명은 전화 시스템에서의 트래픽 관리에 관한 것이며 보다 구체적으로 전화 시스템의 지능형 네트워크(intelligent network : IN)에서 동적으로 트래픽을 관리하는 것에 관한 것이다.

유럽 전화통신 표준화 협회(European Telecommunication Standardization Institute : ETSI)-INAP, 또는 ITU(CS-1R 및 CS-2)와 같은 현재 운영중인 시스템에서는 서비스 또는 네트워크 관리 센터가 혼잡(congestion) 상황을 탐지하거나 또는 수동 제어를 요구하는 기타 다른 상황을 탐지하면 트래픽 관리가 수동으로 시작된다. 이러한 상황에서, 네트워크 관리 센터의 직원은 특정 경로를 통한 실패한 호출의 수가 한계를 넘는지를 결정하고 그런 다음 SCP에서 적절한 서비스 논리를 호출하여 특정 경로를 통한 호출을 필터링하도록 Call Gap 명령어 및/또는 ActiveServiceFiltering(ASF) 명령어를 전송한다.

이와 달리, 공지된 ETSI-INAP 동작에 의하면, SCP가 모든 IN 호출에 EDP-4R을 준비하고 그런 다음 SCP 끝에 카운터를 두어 CallGap 또는 ASF를 전송할 것인지 결정하기에 앞서 일정 주기의 시간동안 실패한 호출의 수를 결정하는 간접적 방법을 통하여 자동 호출 혼잡(Automated Call Congestion)을 결정할 수 있다. 호출이 TDP-TDP2, TDP3, TDP4-중 어느 하나에 도달한 후 트리거링(triggering) 기준이 만족되면 CalledAddressValue 및/또는 서비스 키(Service Key)에 근거하여 필터링 기준이 정해진다. ITU CS-1R에 있어서는, TDP4가 통지 모드에서 활성화되어 그 경로를 통한 실패한 호출을 모니터링하는데 이용될 수 있다. 그러나 이러한 방법은 불필요하게 SSP 및 SCP 간의 SS7 링크를 지나는 트래픽을 증가시킨다.

본 명세서에서 이용되는 약어는 다음과 같다.

ASF - 활성 서비스 필터링(Active Service Filtering)

ASN-1 - 추상적 구문 표기법 넘버 1(Abstract Syntax Notation Number One)

A info - 정보 분석(Analyze Information)

A'd info - 분석된 정보(Analyzed Information)

BCSM - 기본 호출 상태 모델(Basic Call State Model)

CS1 - 용량 세트1(Capability Set1)

CS2 - 용량 세트2(Capability Set2)

EDP - 이벤트 탐지점(Event Detection Point)

ERBCSM - 이벤트 보고 BCSM(Event Report BCSM)

INAP - 지능형 네트워크 애플리케이션 프로토콜(Intelligent Network Application Protocol)

IN - 지능형 네트워크(Intelligent Network)

ITU - 국제 전화 통신 연합(International Telecommunication Union)

RRBCSM - BCSM 보고 요청(Request Report BCSM)

RSF - 경로 선택 실패(Route Select Failure)

SCP - 서비스 제어점(Service Control Point)

SS7 - 신호 시스템 #7(Signaling System #7)

SSP - 서비스 교환점(Service Switching Point)

TDP - 트리거 탐지점(Trigger Detection Point)

간단히 말해서, 본 발명의 한가지 측면에 따르면, 서비스 제어점(SCP)과 같은 지능형 네트워크 노드를 이용하는 트래픽 관리 방법을 제공함으로써 당해 기술에 관한 앞서 언급한 문제점이 극복될 수 있고 당해 기술 분야에 일진보가 이루어 진다. 이러한 방법은 SCP가 특정 경로를 지나는 트래픽을 모니터링함으로써 지능형 결정을 할 수 있는 방안을 제공한다.

본 발명의 또 다른 한가지 측면에 따르면, 서비스 제어점(SCP)에 연결된 서비스 교환점(SSP)을 갖는 시스템에서 호출 트래픽을 관리하기 위한 방법 및 장치를 제공함으로써 앞서 언급된 문제점이 극복될 수 있고 당해 기술 분야에서 일진보가 이루어질 수 있으며 그 관리는 다음의 각 단계를 포함하는바 : SCP로부터 SSP로 트래픽 모니터링 시작 요청(traffic monitoring initiation request)을 전송하는 단계, 트래픽 모니터링 요청에 따라 SSP에서 호출 트래픽을 모니터링하는 단계, SCP에 대하여 모니터링의 결과를 포함하는 응답을 전송하는 단계, 그 결과에 따라 트래픽 관리가 수행될 필요가 있는지를 결정하는 단계 및 트래픽 관리가 수행될 필요가 있는 경우 트래픽 관리를 수행하는 단계를 포함한다.

도 1은 ETSI INAP 시스템(10)에서 종래 기술을 이용하는 INAP 호출 트래픽 관리 동작동안 SSP(12) 및 SCP(14) 간의 정보 통신 흐름도를 도시한다. 제 1 시스템 직원은 InitalDP 및/또는 분석된 정보 메시지를 SCP(14)로 전송한다. InitialDP 메시지는 모든 IN 호출에서 EDP-4R과 같은 이벤트 탐지점을 활성화하도록 하고, 그런 다음 SCP 측에 카운터를 두어 일정 시간 주기 동안 실패한 호출의 수를 결정하도록 하는 것이다. SCP(14)는 기본 호출 상태 모델에 관한 보고 요청, 특히 데이터 아이템 4r, 7n 및 9br에 대한 보고 요청으로 응답한다. SCP(14)는 또한 SSP(12)로 부터 다음 연결 동작을 위하여 분석된 정보를 요청한다. 이에 응답하여, SSP(12)는 기본 호출 상태 모델상에서의 경로 선택 실패에 관한 이벤트 보고(ERBCSM-RSF)를 전송한다. ERBCSM-RSF를 전송한 후에, SSP(12)는 또 다른 InitialDP 및/또는 분석된 정보 메시지를 SCP(14)에게 전송하며, SCP(14)는 후속 ERBASM-RSF를 얻고자 또 다른 처리를 시작한다. SCP(14)는 새로운 DestinationRoutingAddress(DRA)를 전송하기에 앞서 실패한 라우팅을 추적하여 더 많은 데이터를 모은 다음 Call Gap을 전송한다. 도시된 바와 같이, SSP(12) 및 SCP(14) 간에는 그러한 메시지 시퀀스가 많이 있으며, 따라서 그 사이의 SS7 연결에 과부하가 주어진다. 이는 본 발명 이전의 당해 기술 분야의 상태이다.

도 2에 도시된 바처럼, 방법(200)은 SSP(12') 및 SSP(14') 간의 SS7 연결에 과도한 부담을 주는 단점을 가지지 않는다. SSP(12') 및 SCP(14')는 도 1의 SSP(12) 및 SCP(14)와 유사하지만, 본 발명에 따르는 동작을 제공하는 소프트웨어를 갖는 점이 다르다. 시스템(10')을 위한 새로운 방법(200)은 SCP(14')가 비-호출 관련 동작 (새로운) MonitorRouteRequest(이 요청에서 SCP(14')는 MonitorRouteRequest에서 모니터링할 경로/경로 리스트를 지정함)를 전송하도록 한다. 이러한 동작은 SCP(14')에게 SSP(12')에서 실패가 상위 수위표(high watermark)에 도달되었을 때 이를 통지하거나(도 3에 도시됨), SCP(14')에게 특정 시간 사이의 지정된 간격 내에 지정된 경로를 지나는 실패한 호출의 수를 통지하도록(도 4에 도시됨) SSP(12')에게 요청할 수 있는 파라미터를 가질 것이다. 이것은 경로/경로 리스트의 특정 세트를 위해 DP4(routeSelectFailure)를 동적으로 구비하도록 SSP(12')에 요청하고, SCP(14')가 지정된 경로를 지나는 호출이 이 특정 DP에 이를 때마다 카운터를 증가시키는 것에 의해 행해진다. 이는 TDP-4를 정적으로 구비하는 것과는 다르다. SCP(14')는 SSP(12')에게 특정 경로를 지나는 호출이 실패할 때마다 routeSelectFailed 카운터를 증가시키도록 요청한다. 모니터링 기준이 만족되면, SSP(12')는 특정 간격 동안의 routeSelectFailures의 수와 함께 또는 상위 수위표에 도달되었음을 나타내는 파라미터에 기입함으로써 TC-Begin에서 MonitorRouteReport를 전송한다. SCP(14')는 이제 적절한 필터링 기준으로서 CallGap를 전송할 것인지 또는 ASF를 전송할 것인지를 결정할 수 있다. 필터링 기준은 단일 보고에 의하거나 또는 소수의 보고에 의해서 정보가 수집되기 때문에 지정된 간격에서 실패한 호출의 수에 근거를 둘 수 있다. SCP(14')는 통과되어야 하는 호출의 수 및 개핑(gapped)/필터링될 필요가 있는 호출의 수를 계산하는 서비스 논리를 가질 수 있다. 그 결과 SCP(14')는 SSP(12')에서 탐지되는 교환기의 트래픽 문제를 보다 실시간으로 제어할 수 있다. 호출의 개핑/필터링은 동적이며 인간 조작자의 개입없이 이루어질 수 있다. 이와 달리, SCP(14')는 또한 이러한 정보를 이용하여 정보 연결/분석(Connect/Analyze) 동작을 SSP(12')에게 전송한다. 실패한 경로 정보 때문에, SCP(14')는 네트워크 혼잡으로 인하여 실패할 가능성이 높은 경로를 지나게 될 DRA(DestinationRoutingAddress)를 피할 수 있다. 그러한 경우에, 정보 연결/분석(Connect/Analyze) 동작에서 DRA에 대해 또 다른 경로가 전송된다. 이는 네트워크 혼잡에 기인하는 IN 호출 실패율이 낮으며 네트워크 부하가 적당한 한계내에 유지된다는 것을 보증하여, 그에 의하여 더 큰 비율의 호출이 시스템(10')에 의하여 완료될 수 있도록 한다. 그러한 서비스는 또한 네트워크 혼잡이 일어나기 쉬운 경로에 대하여 자동 호출 분배(Automated Call Distribution : ACD)를 하는데 이용되어 네트워크 혼잡 시간동안 ACD 호출의 높은 비율을 달성할 수 있다.

MonitorRouteRequest는 클래스 1(Class 1) 동작이며, 이는 에러 및 ReturnResults 모두가 그 동작을 위하여 전송될 수 있다는 것을 의미한다. 이 동작은 비-호출 관련동작이며, 호출의 문맥에서는 전송되지 않아야 한다.

다음은 방법(200) 및 에러 메시지를 또한 제공하도록 SSP(12') 및 SCP(14')를 동작시키는 SCP 기능(SCF) 및 SSP 기능(SSF)의 기술적 정의이다. 이 기술적 정의는 CCITT X.208(1999)에서 정의된 ASN-1(Abstract Syntax Notation ^#1)에서 지정된다.

서비스 제어 기능(SCF) - 서비스 교환 기능(SSF) 동작

동작 타이머

동작 이름 타이머 값 범위

MonitorRouteRequest T 짧음(1 내지 10초)

Mrr

MonitorRouterequest 절차

이러한 동작을 수신하면, SSF는 지정된 경로에 대해 DP4 히트(hit)를 모니터링한다(RouteSelectFailure). SSF는 소정의 임계치에 도달하거나(모니터링 기준) 또는 종료 시간에 도달하면 그 동작의 결과를 전송한다.

파라미터:

1. RouteList : 이 파라미터는 모니터링할 출력 트렁크 그룹을 지정하는데 이용된다. 경로의 시퀀스가 또한 제공될 수 있다.

2. CorrelationID : 이 파라미터는 SCF에 의하여 이용되어 MonitorRouteRequest를 SSF에 의하여 전송된 MonitorRouteReport와 관련시킨다.

3. MonitoringCriteria : 이 파라미터는 모니터링 결과가 SCP로 전송될 시간을 지정한다.

A. 임계치(threshold) - 이 파라미터는 임계치가 초과될 때마다 보고가 전송되어야 함을 지정한다.

B. 간격(interval) - 이 파라미터는 간격 타이머의 만료점에서 모니터링 보고가 전송되어야함을 지시한다.

4. MonitoringTimeout : 이 파라미터는 모니터링이 활성 상태인 동안의 지속 시간을 지시한다.

A. 지속 시간(duration) - 지속 시간 타이머가 만료되면 모니터링이 제거된다.

'0' 지속 시간은 모니터링이 제거되여야 함을 나타낸다.

'-1' 지속 시간은 무한한 지속 시간을 나타낸다.

B. stopTime - 종료 시간에 이르면 경로 모니터링이 제거된다.

5. StartTime : 이 파라미터는 필터링이 시작되는 때를 정의한다. "startTime"이 제공되지 않거나 이미 시작되었다면, SSF는 즉시 모니터링을 시작한다.

호출 엔티티(SCF)

일반적 절차

SCF 사전 조건:

1) 서비스 논리 프로그램 인스턴스(SLPI)는 지정 경로를 지나는 트래픽을 모니터링하도록 결정한다.

SCF 사후 조건:

1)서비스 논리 프로그램 인스턴스(SLIP)는 경로 모니터링의 예상 종료점을 모니터링하도록 애플리케이션 타이머를 시작한다.

2)서비스 제어 기능 관리 엔티티(SCME)가 "SSF MonitoringRouteReport 대기" 상태에 있다.

응답 엔티티(SSF)

일반적 처리

SSF 사전 조건:

1. 없다.

SSF 사후 조건:

1. 서비스 교환 기능 관리 엔티티(SSME) 유한 상태 기계(FSM)는 "비-호출 관 련취급" 상태에 있다.

에러 처리

1. SSF가 임의의 정의된 에러값을 갖는 에러를 탐지하면 이 에러는 SCF에게 보고된다.

MonitorRouteReport 절차

일반적 설명

이런 동작은 이전의 MonitorRouteRequest 동작의 경로 리스트 카운터의 값을 보고하는데 이용된다.

파라미터:

1. routeCounters : 파라미터는 모니터링 주기 동안 선택된 경로를 지나는 실패한 호출의 수를 보유한다. 즉 경로 카운터의 리스트이다.

2. correlationID : 이 파라미터는 SCF에 의하여 이전에 전송된 MonitorRouteRequest에 대하여 MonitorRouteReport를 관련시키는 SCF에 의하여 이용된다.

호출 엔티티(SSF)

일반적 절차

SSF 사전 조건:

1)경로 모니터링이 현재 진행중이며 간격 타이머가 종료되었거나;

2)경로 모니터링이 진행중이며 임계치에 도달하였거나;

3)모니터링이 종료되었거나(지속 시간이 만료되었거나 종료 시간에 도달); 또는

4)MonitorRouteRequest 동작이 수신되고 활성 경로 모니터링 엔티티를 만난다.

SSF 사후 조건

1)경로 모니터링이 그 지속 시간에 따라서 진행되거나 종료된다.

에러 처리 : 에러 처리에 관련된 동작은 class 4 동작으로 인하여 적용할 수 없다.

응답 엔티티(SCF)

일반적 처리

SCF 사전 조건 :

1)경로 모니터링이 실행된다.

2)SCME는 "SSF MonitorRouteRequest 대기" 상태에 있다.

SCF 사후 조건 :

SCME는 수신된 카운터 값을 SLPI로 전송한다.

그러므로, 도시되고 설명되는 새로운 동적 트래픽 관리 시스템 및 방법이 중요할 것이다. 본 발명이 바람직한 실시예의 관점에서 설명된다고 할지라도, 당업자라면 본 발명의 청구 범위를 벗어나지 않는 범위에서 다양한 많은 다른 방안을 생각해낼 것이다.

서비스 제어점(SCP)과 같은 지능형 네트워크 노드를 이용하는 트래픽 관리 방법을 제공함으로써 당해 기술에 있어서의 과도한 트래픽 문제점이 극복될 수 있고 당해 기술 분야에 일진보가 이루어진다. 이러한 방법은 SCP가 특정 경로를 지나는 트래픽을 모니터링함으로써 지능형 결정을 할 수 있는 방안을 제공한다.

Claims (12)

1. SS7 연결에 의하여 연결된 서비스 교환점(a service switching point:SSP)을 가지며 서비스 제어점(a service control point : SCP)에 대하여 신호를 보내는 전화 시스템의 SCP에서의 호출 트래픽 과부하 관리 방법으로서,

   경로 실패 정보에 기초하여 트래픽 관리가 적용될 필요가 있는지를 상기 SCP에서 결정하는 단계와,

   만약 트래픽 관리가 적용될 필요가 있다면, 상기 SCP가, 상기 SCP로부터 상기 SSP로 트래픽 관리 명령어를 전송하는 것을 포함하는 트래픽 관리를 시작하는 단계와,

   상기 SCP로부터 전송된 트래픽 모니터링 시작 요청을 상기 SSP에서 수신하는 단계 -상기 SSP는 상기 SSP에서 호출 실패가 상위 수위표(a high watermark)에 도달했을 때 이를 상기 SCP에게 통지하거나 또는 SCP에게 특정한 시간 동안의 지정된 간격내에 지정된 경로를 지나는 실패한 호출의 수를 통지하도록 요청받음- 와,

   상기 트래픽 모니터링 요청에 따라서 상기 SSP가 호출 트래픽을 모니터링하는 단계와,

   상기 SSP에서 호출 실패의 모니터링된 상태들 중 하나가 발생했는지를 판단하는 단계와,

   상기 SCP가 상기 SSP로부터 상기 모니터링된 상태들 중 하나의 결과를 포함하는 응답을 수신하고, 상기 모니터링된 상태들 중 하나의 결과에 기초하여 트래픽 관리가 적용될 필요가 있는지를 판단하는 단계

   를 포함하는 호출 트래픽 과부하 관리 방법.
2. 제 1 항에 있어서,

   상기 트래픽 모니터링 시작 요청은 경로 모니터링 요청인

   호출 트래픽 과부하 관리 방법.
3. 제 1 항에 있어서,

   상기 트래픽 모니터링 시작 요청은 TC-Begin 요청인

   호출 트래픽 과부하 관리 방법.
4. 제 1 항에 있어서,

   상기 트래픽 모니터링 시작 요청은 경로 모니터링 요청이며 상기 SCP에 대한 상기 응답은 경로 모니터링 보고인

   호출 트래픽 과부하 관리 방법.
5. 삭제
6. 제 1 항에 있어서,

   상기 SCP는 트래픽 관리가 적용될 필요가 있는지를 판단하고, 상기 SCP는 call gap 명령어를 포함하는 트래픽 관리 명령어를 전송하는

   호출 트래픽 과부하 관리 방법.
7. 제 6 항에 있어서,

   call gap 기준이 상기 call gap 명령어와 함께 전송되는

   호출 트래픽 과부하 관리 방법.
8. 제 1 항에 있어서,

   상기 트래픽 모니터링 요청은 소정의 시간 주기 동안 모든 경로 실패를 모니터링하는 TC-Begin 요청이며 상기 SCP에 대한 상기 응답은 만료된 상기 소정의 시간 동안 호출 실패의 수에 대한 정보를 갖는 경로 모니터링 보고인

   호출 트래픽 과부하 관리 방법.
9. 제 1 항에 있어서,

   상기 트래픽 모니터링 시작 요청은 소정의 시간 주기 동안 모든 경로 실패를 모니터링하는 TC-Begin 요청이며,

   상기 SCP에 대한 응답은 상기 소정의 시간 주기 동안 모든 경로 실패에 관한 정보를 갖는 경로 모니터링 보고이며,

   상기 트래픽 관리 명령어는 call gap 명령어를 포함하는

   호출 트래픽 과부하 관리 방법.
10. 제 1 항에 있어서,

    상기 트래픽 모니터링 시작 요청은 소정의 시간 주기 동안 모든 실패를 모니터링하는 TC-Begin 요청이며,

    상기 SCP에 대한 응답은 상기 소정의 시간 주기 동안 모든 경로 실패에 관한 정보를 갖는 경로 모니터링 보고이며,

    상기 트래픽 관리 적용 단계는 또한 목적지 경로 주소(DRA) 데이터 필드에서 또 다른 경로를 갖는 정보 연결 및 분석 명령어를 상기 SSP로 전송하는 단계를 포함하는

    호출 트래픽 과부하 관리 방법.
11. 제 1 항에 있어서,

    상기 트래픽 모니터링 시작 요청은 경로 모니터링 요청이며,

    상기 SCP에 대한 응답은 경로 실패가 상위 수위표에 이르렀음을 알리는 정보를 갖는 경로 모니터링 보고이며,

    상기 트래픽 관리 적용 단계는 상기 SSP에 대하여 목적지 경로 주소(DRA) 데이터 필드에서 또 다른 경로를 갖는 정보 연결 및 분석 명령어를 전송하는 단계를 포함하는

    호출 트래픽 과부하 관리 방법.
12. SS7 연결에 의하여 연결된 서비스 교환점(SSP)을 가지며 서비스 제어점(SCP)에 대하여 신호를 보내는 전화 시스템에서 SCP에서의 호출 트래픽 과부하 관리 장치로서,

    경로 실패 정보에 기초하여 트래픽 관리가 적용될 필요가 있는지를 상기 SCP에서 결정하는 수단과,

    만약 트래픽 관리가 적용될 필요가 있다면, 상기 SCP에서, 상기 SCP로부터 상기 SSP로 트래픽 관리 명령어를 전송하는 것을 포함하는 트래픽 관리를 시작하는 수단과,

    상기 SCP로부터 전송된 트래픽 모니터링 시작 요청을 상기 SSP에서 수신하는 수단 -상기 SSP는 상기 SSP에서 호출 실패가 상위 수위표(a high watermark)에 도달했을 때 이를 상기 SCP에게 통지하거나 또는 상기 SCP에게 지정된 간격내에 지정된 경로를 지나는 실패한 호출의 수를 통지하도록 요청받음- 와,

    상기 트래픽 모니터링 요청에 따라서 상기 SSP에 의해 호출 트래픽을 모니터링하는 수단과,

    상기 SSP에서 호출 실패의 모니터링된 상태들 중 하나가 발생했는지를 판단하는 수단과,

    상기 SCP에서 상기 SSP로부터 상기 모니터링된 상태들 중 하나의 결과를 포함하는 응답을 수신하고, 상기 모니터링된 상태들 중 하나의 결과에 기초하여 트래픽 관리가 적용될 필요가 있는지를 판단하는 수단

    을 포함하는 호출 트래픽 과부하 관리 장치.

Images