KR100454537B1 - 프로시저의 타당성 검증 방법 - Google Patents

Abstract

프로시저의 타당성 검증 방법은 다수의 프로세스가 단일 사상의 타당성 검증에 수반되도록 한다. 본 발명은 엔티티를 기술하는 FSM 사이의 관계성을 규정하는데, 특정 기준을 만족하는 프로세스를 선택하는 단계, 및 모든 선택된 프로세스로 사상을 처리하는 단계를 포함한다.

Description

프로시저의 타당성 검증 방법{VALIDATION OF PROCEDURES}

종래 기술에서, 규칙은 각 엔티티(entity) 및 각 인터페이스에 대한 유한 상태 기계(FSM; finite state machine)를 규정함으로써 기술되는데, 인터페이스는 두 개의 엔티티 사이의 경계이다. FSM은 프로세스(process)의 동작(behavior)에 대한 모델로서 기능한다. FSM은 서로 접속될 수 있는 상태(state)로 구성된다. 프로세스는 어떤 일정 시점에서 단지 하나의 상태에 있을 수 있지만, 하나의 상태로부터 사상(event)의 결과로써 접속되는 상태로 이동될 수 있다. 한 상태에서 다른 상태로의 전이(transition)시, 액션(action)이 실행될 수 있다. 이와 같은 시스템은, 전기 통신 시스템의 특성 상호 작용 III, 제 3 회 특성 상호 작용 워크숍(FIW'9, KYOTO, JP, Oct. 11∼13, 1995)의 KAKUDA 등에 의한 "특성 상호 작용 및 그 전개를 위한 동적 해결 방법"에 기술되어 있다.

통신망 프로토콜의 프로시저를 타당성 검증(validate)하기 위해 FSM을 사용하면, 상기 FSM을 제어하는 사상은 프로토콜에 규정된 동작, 또는 콜(call) 프로세스 등의 다른 프로세스로부터 오는 다른 사상이다.

INAP CS1 등의 통신망 프로토콜에서 유효 프로시저를 규정하는 규칙은 단일 결합 제어 기능(SACF; Single Association Control Function) 및 다중 결합 제어 기능(MACF; Multiple Association Control Function) 규칙이다. SACF 규칙은 단일 결합이 있는 경우에 적용되고, MACF 규칙은 다수의 관련된 결합이 있는 경우에 적용되는데, 상기 결합은 두 개의 엔티티 사이에 통신을 가능하게 하는 특정 인터페이스를 사용하여 신호 전송(signalling)하는 채널이다.

공교롭게도, SACF 규칙 및 MACF 규칙 모두를 단일 FSM으로서 형식적으로 기술하는데는 매우 복잡한 FSM이 필요하다. 그 결과, 모든 MACF 프로시저를 포함하는 많은 프로시저는 여전히 자연어로 규정된다. 이런 유형의 프로시저, 즉 결합 당 단일 FSM으로 규정될 수 없는 프로시저에 대한 규칙을 타당성 검증하기 위한 메커니즘이 없다.

본 발명은 통신망 프로토콜의 프로시저를 타당성 검증하는 방법에 관한 것이다. 특히, 본 발명은 유럽 전기통신 표준 ETS 300 374에 규정된 자격 세트 1(CS1; Capability Set 1)을 지원하는데 필요한 지능망 응용 프로토콜(INAP; Intelligent Network Application Protocol)과 같은 통신망 프로토콜에 관한 것이다.

INAP CS1과 같은 프로토콜에는, 특정 작업을 수행하기 위해 실행되는 다수의 유효 프로시저(valid procedure), 또는 동작 순서가 있다. 그러나, 가능한 프로시저의 수가 많기 때문에, 유효 프로시저가 직접적으로 규정되지 않고, 그보다는 규칙의 세트(set)로써 규정된다. 어떤 프로시저 또는 동작 순서가 이런 규칙을 위반하지 않으면 유효 프로시저로서 간주된다.

도 1은 컨테이너(container) 인터페이스를 공유하는 두 개의 FSM을 나타내는 도면.

도 2는 A를 실행하는 프로세스(Ax)가 B를 실행하는 두 개의 프로세스(Bx, By)를 포함하는 경우의 도면.

도 3은 그 자체가 다수의 다른 FSM으로 구성되는 FSM을 나타내는 도면.

도 4는 세션-뷰(session view)에 대한 FSM을 나타내는 도면.

도 5는 콜-뷰(call view)에 대한 FSM을 나타내는 도면.

도 6은 Cp 또는 Ap에 대한 FSM을 나타내는 도면.

본 발명은 규칙을 다수의 FSM에 의해 규정되도록 함으로써 프로시저를 타당성 검증하는 방법에 관한 것이다. 특히, 특정 FSM을 제각기 실행하는 다수의 프로세스가 단일 사상의 타당성 검증(validation)에 수반되도록 허용된다.

사상의 타당성 검증은 두 단계로 수행된다. 먼저, 관련 프로세스가 특정 기준(criteria)을 만족하는지를 평가함으로써 선택된다. 두 번째 처리 단계에서, 선택된 모든 프로세스가 사상을 처리한다.

이는, 사상이 어떤 프로세스에 의해 처리되기 전에, 수반된 모든 프로세스가 안정 상태(stable state)에 있다는 이점을 갖는다.본 발명을 더 잘 이해하기 위해, 예로서 첨부된 도면이 참조된다.

본 발명에 따르면, 프로시저의 타당성 검증은 다수의 프로세스를 수반하며, 타당성 검증의 첫 번째 단계는 타당성 검증에 수반되는 프로세스를 선택하는 단계를 포함한다.

프로세스의 선택은 각각의 엔티티 및 인터페이스를 나타내는 FSM의 특성 및 상호 관계성에 따른 기준을 사용한다.

먼저, 어떤 FSM이 "컨테이너 인터페이스"를 공유하는지가 판단된다. 도 1은 컨테이너 인터페이스를 공유하는 두 개의 FSM(A,B)을 나타낸다. 두 개의 FSM이 이런 유형의 인터페이스를 공유하면, 하나는 다른 하나에 포함되어 있다고 말하며, 다른 하나는 첫 번째 FSM을 포함한다. 도 1의 예에서, FSM(A)는 FSM(B)를 포함하며, FSM(B)는 FSM(A)에 포함된다. 제 2 FSM에 포함된 제 1 FSM은 정의에 의해 제 2 FSM을 포함하는 어떤 제 3 FSM에도 포함된다. 즉, A가 B에 포함되고, B가 C에 포함되면, 정의에 의해서 A는 또한 C에도 포함된다. A는 C에 간접적으로 포함된다고 말할 수 있다. 다른 언급이 없으면, 본원에서 사용된 용어 "포함된다(included)"는 직접 및 간접적으로 포함됨을 모두 의미하며, 이는 두 개 이상의 FSM 사이의 관계를 지정할 수 있다. 컨테이너 인터페이스상의 결합을 통한 프로세스 사이의 대화 (interaction)는 다른 유형의 대화와는 상이하게 취급된다.

다음 사항이 두 FSM에 적용되면, 인터페이스는 컨테이너 인터페이스로서 분류될 수 있다:

어떤 FSM이 다른 하나의 FSM에 직접적으로만 포함되고;

어떤 FSM이 그 자체에 포함되지 않으며;

어떤 FSM을 실행하는 프로세스는 첫 번째 FSM이 직접적으로 포함되는 FSM을 실행하는 하나 이상의 프로세스와 결합되지 않는다.

따라서, 다시 도 1에서, FSM(B)을 실행하는 프로세스는 FSM(A)을 실행하는 최대 하나의 프로세스와 결합될 뿐이다. 그러나, FSM(A)을 실행하는 프로세스는 FSM(B)을 실행하는 다수의 프로세스와 결합될 수 있다(따라서, 이런 결합은 FSM(A)을 실행하는 프로세스에 수반됨). A 또는 B는 (컨테이너 인터페이스가 아닌) 다른 인터페이스를 가질 수도 있다. 도 1에서, FSM(B)이 하나의 다른 인터페이스(I1)를 갖는 것으로 도시된다.

포함-관계의 세부 사항은 이하 FSM-트리(tree)로 칭해지는 트리의 형태로 시스템에 용이하게 저장될 수 있다. FSM-트리의 루트(root)는 다른 어떤 FSM에도 포함되지 않는 FSM이다. FSM 트리의 잎(leaves)은 다른 어떤 FSM도 포함하지 않는 FSM이다.

포함의 개념은 프로세스에도 적용된다: 제 1 프로세스에 의해 실행되는 FSM이 제 2 프로세스에 의해 실행되는 FSM에 포함되면, 하나의 프로세스는 다른 프로세스에 포함된다. 또한, 두 개의 프로세스는, 프로세스 모두가 (직접적 또는 간접적으로) 결합되는 프로세스를 통해, 직접적으로 또는 간접적으로 결합되어야 한다. 예를 들면, 도 2는 A를 실행하는 프로세스(Ax)가, B를 실행하는 두 개의 프로세스 (Bx,By)를 포함하는 경우를 나타낸다.

FSM과 유사하게, 이런 포함-관계의 세부 사항은 이하 프로세스-트리로 칭해지는 트리의 형태로 시스템에 용이하게 저장될 수 있다. 프로세스-트리를 스캔하는 (scan) 경우, 개별 데이터-구조가 사용될 수 있거나, 또는 프로세스 사이의 결합이 사용될 수 있다. 하나의 동일한 프로세스-트리 내에 있는 프로세스의 세트는 선택-프로세스를 위한 하나의 베이시스(basis)를 형성한다.

프로세스에 대한 선택 기준을 규정하는데 사용되는 두 번째 특성은 "컨테이너 문맥(container context)"인데, 이는 타당성 검증될 사상의 상이한 가능한 문맥을 식별하는 미리-정해진 값의 세트이다. 따라서, 동일한 결합을 사용하는 상이한 사상은 상이한 문맥을 가질 수 있다. 예를 들면, CS1에서, 일부 동작은 콜에 수반되는 단일 당사자의 문맥 내에 있다.

또한, 프로세스에는 컨테이너 문맥이 할당될 수 있다. 이런 경우에, 이는 사상과 특정 프로세스 사이의 관계성을 식별한다.

따라서, 사상("현재의 사상")이 타당성 검증되면, 현재 사상의 컨테이너 문맥에 부합하는(match) 프로세스의 세트를 식별할 수 있다.

컨테이너 문맥의 할당은 각 FSM에 컨테이너 문맥의 세트; Fx = {CC1, CC2, ..., CCn}을 할당함으로써 수행된다. 컨테이너 문맥이 포함하거나 또는 그에 포함되는 FSM에 컨테이너 문맥이 이미 할당되었으면, 컨테이너 문맥은 FSM에 할당될 수 없다. 이는, 컨테이너 문맥이 FSM에 할당되면, 시스템에 의해 검사된다. 사상에는 단일 컨테이너 문맥이 할당될 수 있다. 이런 컨테이너 문맥은 또한 현재의 사상에도 할당되고, "현재의 컨테이너 문맥"으로 칭해진다. 특정 인터페이스를 통해 도달할 수 있는 사상의 세트가 주어지면, 상기 사상의 세트에 대한 모든 가능한 컨테이너 문맥은 인터페이스를 공유하는 FSM을 포함하거나 또는 그에 포함되는 FSM에 할당되어야 한다.

프로세스-트리의 각 프로세스에는 Fx로부터의 컨테이너 문맥이 할당되어, 동일한 FSM을 실행하는 상이한 프로세스, 및 동일한 프로세스-트리의 일부분에는 상이한 컨테이너 문맥이 할당된다.

예를 들면, 프로토콜에서, 각각이 컨테이너 문맥으로서 사용될 수 있는 30개의 레그-id(leg-id)가 있을 수 있다. 일부 동작은 전체 콜(예를 들면, 해제 콜 [ReleaseCall])에 적용되어, 컨테이너 문맥으로서의 콜을 갖는다. 레그-id를 파라미터로 갖는 동작은 30개의 개별 사상(각각의 가능한 레그-id에 대해 한 개)으로 나타난다. 이는, 동작을 30개의 가능한 사상 중 하나로 매핑하기 위해 동작의 분석을 필요로 한다(즉, 레그-id 파라미터, 또는 디폴트(default) 레그-id 값은 동작으로부터 사상으로의 매핑(mapping)을 판단함).

프로세스에 대한 선택 기준을 규정하는데 사용되는 세 번째 특성은 "컨테이너 액션(Container Actions)"인데, 이는 FSM의 상태-전이(state-transition)에 지정되는 액션의 특정 세트이다. 이런 액션은 다른 프로세스에 의해 현재의 사상의 처리에 영향을 줄 수 있다. 예를 들면, 사상을 처리하도록 지정될지라도, 이런 액션으로 인해 다른 프로세스가 사상을 처리하지 않게 할 수 있다.

각 시스템은 규정된 다수의 컨테이너 액션을 갖는다. 컨테이너 액션은 다른 프로세스에 영향을 줄 수 있기 때문에, 다수의 프로세스가 상호 영향을 주는 컨테이너 액션을 실행할 때 충돌이 발생될 수 있다. 상기 시스템은 이런 컨테이너 액션 사이에 명확한 대화를 지정해야 한다. 예를 들면, 우선 순위가 높은 컨테이너 액션은 우선 순위가 낮은 모든 컨테이너 액션(현재의 사상에 대해)을 배제한다. 이런 대화를 규정하는데 사용되는 원칙은 본원에서 더 이상 설명하지 않는다; 컨테이너 액션의 세트가 주어지면, 시스템은 허용되는 컨테이너 액션의 서브세트를 식별할 수 있다고 가정한다. 이런 서브세트는 이하 현재의 "컨테이너 액션"으로 칭한다.

시스템이 상이한 프로세스로부터의 상이한 컨테이너 액션을 조정할 수 있게 하기 위해, 사상의 처리 이전에 두 단계가 필요하다.

먼저, 사상을 처리할 수 있는 프로세스의 세트가 주어지고, 이런 프로세스가 일단 사상을 처리하면, 이런 처리가 실행하는 컨테이너 액션이 수집된다. 이는 수반되는 프로세스에 의한 사상의 사전-처리가 필요하다: 그 결과, 상태-전이가 결정되지만(이는 실행될 액션을 결정하기 때문에), 실행되지 않는다.

둘째로, 수집된 컨테이너 액션, 및 시스템의 액션 사이에 규정된 우선 순위에 따라, 상기 시스템은 현재의 컨테이너 액션을 생성한다.

사상이 프로세스의 세트에 의해 처리되면, 그 컨테이너 액션은 동일한 액션이 두 번 실행되는 것을 방지하기 위해 조정되도록 하여야 한다.

상술한 바와 같이, 타당성 검증의 첫 번째 단계는 상술한 특성에 따른 기준을 사용하여, 타당성 검증에 수반되는 프로세스를 선택하는 단계를 포함한다.

초기에 결합을 통해 사상을 수용하는 프로세스가 있지만, 상기 사상은 그 프로세스에 의해 즉시 처리되지 않는다. 이런 수용 프로세스는 항상 선택-단계의 결과에 따라 선택되지만, 이것이 선택될 경우에만, 프로세스가 사상을 처리할 수 있다.

선택 단계의 부분으로서, 현재의 컨테이너 문맥이 있는지가 판단된다. 현재의 컨테이너 문맥이 없으면, 사상을 수용하는 프로세스만이 선택된다. 현재의 컨테이너 문맥이 있으면, 다음의 두 가지 기준을 만족하는 어떤 프로세스가 선택된다. 첫째, 프로세스는 컨테이너 문맥을 유지하는 프로세스를 유지하거나 포함하던지, 또는 컨테이너 문맥을 유지하는 프로세스에 포함되어야 하며, 컨테이너 문맥은 사상을 수용했던 프로세스를 포함하거나 또는 그 프로세스 속에 포함된다. 둘째, 상기 프로세스는 현재의 컨테이너 액션의 하나 이외의 어떤 컨테이너 액션도 실행해서는 않된다.

선택-단계는 사상을 수용했던 프로세스를 검사함으로써 개시된다. 이로부터, 프로세스-트리는 루트 및 잎으로 스캔된다. 스캔되는 모든 프로세스에 대해, 컨테이너 문맥에 부합되는지가 검사된다. 각 부합 프로세스는 선택 단계에 부가된다. 다수의 최적화가 적용된다. 첫째, 부합 프로세스가 사상을 수용했던 프로세스를 포함하면, 어떤 다른 부합 프로세스도 없다. 이는, FSM이 할당된 컨테이너 문맥을 갖는 FSM을 이미 포함하고 있거나, 또는 그에 포함되어 있다면, 컨테이너 문맥은 FSM에 할당될 수 없기 때문이다. 둘째, 부합 프로세스가 검색되면, 동일한 FSM을 실행하는 어떤 다른 부합 프로세스도 없다.

이는 하나 이상의 부합 프로세스를 제공하며, 검색되는 모든 부합 프로세스에 대해, 프로세스-트리는 다시 루트 및 잎으로 스캔된다. 각 부합 프로세스는 사전에 선택되지 않았으면, 이제 선택 단계에 부가된다.

상술한 바와 같이, 사상은 선택된 모든 프로세스에 의해 사전 처리된다. 이는 현재의 컨테이너 액션을 초래하는데, 이는 또한 선택 단계에서 프로세스의 최종의 세트를 결정한다.

선택-프로세스가 적절하게 액션하는 경우에, 첫 번째 사상이 타당성 검증되기 전에 완전한 프로세스-트리가 이용 가능한 것처럼 보여져야 한다. 이는, 모든 FSM에 대해 프로세스가 그에 할당된 어떤 컨테이너 문맥을 위한 프로세스-트리에 존재해야함을 의미한다(유휴(idle) 상태에 있을지라도). 이로 인해 주어지는 오버헤드(overhead)는 어떤 시스템에서도 허용되지 않는다. 이하의 방법은 주문형(on demand) 프로세스를 생성하는데 사용될 수 있다;

선택-프로세스 동안에, 트리의 종단부가 도달되지만(이런 프로세스는 이하 최종 프로세스로 칭함), 최종 프로세스에 의해 실행되는 FSM(이하 최종 FSM으로 칭함)이 대응하는 FSM-트리의 루트 또는 잎이 아닌 경우:

- 루트로 스캔하는 경우, FSM이 현재의 사상에 대해 '무액션(no action)' 보다 액션에 의해 유휴로부터 상태-전이를 지정하는 FSM이거나 또는 그에 포함되면, 최종 FSM이 직접적으로 포함되는 FSM에 대해 하나의 프로세스가 생성된다.

- 잎으로 스캔하는 경우, 최종 FSM에 직접적으로 포함되는 각 FSM에 대해 하나 이상의 프로세스가 생성되고, 이는 현재의 사상에 대해 '무액션' 보다 액션에 의해 유휴로부터 상태-전이를 지정하는 FSM이거나 또는 그를 포함한다. FSM의 Fx가 현재의 컨테이너 문맥을 구성 요소로서 갖고 있거나, 또는 공백이라면, 하나의 프로세스가 FSM에 대해 생성된다. 그렇지 않으면, FSM의 Fx의 각 구성 요소에 대해 하나의 프로세스가 생성된다. 이런 추적을 계속한 후에 각 프로세스에 대해 결합이 확립된다.

상기 시스템은 각 FSM에 대해, 유휴 상태로 수용되면, 어떤 사상에 대해 '무액션' 보다 액션으로 지정할 것인지를 인식해야 한다.

프로세스가 유휴 상태이고, 어떤 다른 프로세스도 포함하지 않으면, 프로세스는 제거될 수 있고, 그것이 갖는 컨테이너 인터페이스상의 어떤 결합은 해제될 수 있다. 프로세스가 유휴 상태가 아니지만, 더 이상 어떤 결합도 없으며, 즉, 프로세스가 정지되는 상황이 발생할 수 있다. 그러면, 상기 시스템은 프로세스가 루트뿐만 아니라 단지 잎이기 때문에 이를 검출할 수 있다. 상기 시스템은 이런 경우 특별한 사상, 예를 들면, '고아(orphaned)'를 생성하는데, 이에 따라 유휴 상태로 진행되어야 한다(그렇지 않으면, 오류로 간주됨).

선택-단계가 종료되고, 프로세스의 그룹이 선택된 후에, 각 선택된 프로세스는 다른 선택된 프로세스와 관계없이 사상을 처리한다. 그러면, 사상은 타당성 검증될 수 있다.

사상이 상이한 결합으로 도달될 수 있고, 연이은 사상은 이전의 사상이 처리 완료될 때까지 처리될 수 없기 때문에, 대기 행렬(queuing)이 필요하다. 사상은, 이미 대기된(queued) 사상이 있거나 또는 이미 현재의 사상이 있으면, 대기된다. 사상은 사상을 수용하는 프로세스 중에서 루트-프로세스에 대해 대기된다. 상이한 대기 행렬은 얼마나 많은 상이한 우선 순위가 있는가에 따라 적용될 수 있다. 컨테이너 인터페이스를 통해 수용되는 사상은 다른 유형의 인터페이스를 통해 수용되는 사상 보다 우선 순위가 높다. 따라서, 이런 사상에 대한 대기 행렬은 다른 대기 행렬로부터 사상이 수용되기 전에 공백이어야 한다. 이는, 타당성 검증될 다음의 사상이 수용되기 전에, 모든 수반되는 프로세스가 서로 갱신하는 기회를 제공한다.

이하, 본 발명은, 다수의 FSM에 의해 기술되는 IN에 대한 에릭슨(Ericsson) CS1+ INAP 프로토콜로부터 취한 특정 예에 대한 응용을 참조로 하여 더욱 상세하게 설명된다. 이런 FSM 중의 하나는 SSF-FSM인데, 도 3에 도시된 바와 같이, 그 자체는 다수의 FSM으로 구성된다.

따라서, 세션-뷰 FSM은 콜-뷰 FSM을 포함하는데, 이는 또한 Cp 및 Ap FSM을 포함한다. Cp 및 Ap FSM은 인터페이스를 공유하지만, 이는 컨테이너 인터페이스가 아니다.

콜-뷰 FSM은 콜 및 SCF(Service Control Function)를 가진 외부 인터페이스를 갖는다. 이런 인터페이스상에서, SACF- 및 MACF-규칙에 대해 타당성 검증되어야 할 사상이 도달될 수 있다.

이하, (우선 순위대로 제공되는) 컨테이너-액션이 식별된다:

버퍼사상(bufferEvent). 사상이 버퍼링 된다(버퍼-메커니즘 자체는 여기서 설명되지 않음). 오류 프로시저는 뒤따르지 않는다.

거부사상(rejectEvent). 사상이 거부되고: 오류 프로시저가 뒤따른다.

도 4는 INAP에 대한 MACF-규칙을 지정하는 세션-뷰에 대한 FSM을 나타낸다. 하나의 MACF 규칙이 존재한다: 다수의 SCF에 대한 다수의 결합이 동시에 존재할 수 있지만, 단지 하나만이 콜을 제어할 수 있다.

컨테이너 문맥으로서 세션-뷰를 갖는 동작은 없다. 세션-뷰는 모든 다른 FSM을 포함하기 때문에, 세션-뷰는 모든 사상의 타당성 검증에 항상 수반된다.

SCF와의 새로운 결합은 세션-뷰에 대한 FSM이 유휴 상태이거나, 또는 모니터 (monitor) 관계에 있을 때에만 허용된다. 따라서, 세션-뷰에 대한 FSM이 상태 제어 관계에 있으면, (SCF와 새로운 결합을 개시하는) InitialDP 동작은 거부된다. 그러면, 상기 동작은 무시된다.

도 5는 SCF와의 결합에 대한 SACF-규칙 및 콜을 지정하는 콜-뷰 프로세스에 대한 FSM을 나타낸다. SCF와의 결합 당 하나의 콜-뷰 프로세스가 있다. FSM은 단일 SCF-프로세스에서 알려진 바와 같은 콜의 구성을 나타낸다.

컨테이너 문맥으로서 콜-뷰, 예를 들면, 해제 콜을 갖는 소수의 동작이 있다.

상태: 설정(SetUp), 보류(Pending), 활성화(Active)는 BCSM에서의 상태에 대응된다. 설정 상태에 있는 동안, SCF는 여전히 통상의 CCF-프로시저(정보 수집 동작; CollectInformation)을 사용하여 사용자로부터 디지트(digit)를 수집한다. 일단 보류되면, 이는 더 이상 가능하지 않다(정보 수집 거부). 활성화 상태에 있는 동안, SCF는 호를 루팅할 수 없다(접속 거부). 콜은 콜로부터의 특정 사상에 의해 보류 상태로 되돌려지기만 한다.

일단 대리(Surrogate) 상태가 되면, 콜을 개시하는 당사자는 콜을 중지한다. 그러면, SCF가 콜을 루팅하는 것은 더 이상 가능하지 않다(FSM을 활성화 상태로부터 보류 상태로 전이하게 하는 콜로부터의 사상은 이제 아무런 액션이 없는 동일한 상태로 상태-전이를 일으킴). 일단 모니터링 관계가 되면, SCF는 더 이상 콜을 제어할 수 없지만, 콜에서 발생하는 사상을 감시할 수 있다(모든 제어 동작은 거부됨). 모니터 관계 상태로 진입하면, 이런 FSM에 의해 사상이 생성되고, (모니터 관계로 상태 전이를 일으키기 위해) 세션-뷰로 전송됨을 주목해야 한다.

도 6은 Cp 또는 Ap에 대한 FSM을 나타낸다. Cp 및 Ap는 동일한 상태를 갖는다. 콜-뷰 내에서 Cp-뷰는 단지 하나만이 있을 수 있지만, Ap-뷰는 다수개가 있을 수 있다. Cp 또는 Ap는, Cp 또는 Ap가 수반되는 동작을 위해, SCF와의 결합에 대한 SACF-규칙 및 콜을 지정한다.

FSM은 SSF와 SCF 사이의 동기화 프로시저 및 콜 당사자와 대화하는 (통상의 CCF-프로시저를 사용하는 것 이외의) 프로시저를 나타낸다.

컨테이너 문맥으로서 Cp 또는 Ap를 갖는 동작은 없다. 어떤 뷰가 수반되는지는 Cp 및 Ap에 포함되는 FSM인 레그에 의해 판단된다.

도 3에 나타낸 바와 같이, Cp 및 Ap 사이에는 레그를 하나의 뷰로부터 다른 뷰로 이동시키는데 사용되는 인터페이스가 있다(실제로, 이는 레그에 대해 포함된 프로세스가 해제되고, 다른 프로세스가 다른 쪽에서 개시됨을 의미).

FSM에서 WFI(wait for instruction; 명령 대기) 상태일 때, 사용자가 (CLSM-프로세스로부터 오는 사상을) 중지하면, 동기가 깨질 수 있지만, Cp- 또는 Ap-프로세스는 SCF에 동기화된다. 상이한 Ap-프로세스는 결과적으로 서로 동기화되지 않으며, Cp-프로세스와 동기화되지 않는다: 동기화는 완전한 콜에 적용되지 않음을 주목해야 한다.

사용자-대화가 진행 중인 동안에(FSM이 사용자 대화 WFI, 또는 사용자 대화 처리에 있음), 모든 동작은 접속 진행 차단(DisconnectForwardConnection)을 제외하고, Cp에 의해 버퍼링 된다. FSM이 WFI 또는 처리로 재-전이되면 버퍼는 해제된다. Ap는 콜 해제를 버퍼링만 하고, 이는 국지적으로, 즉 다른 FSM에 영향을 주지 않고 버퍼링만 된다. 따라서 Ap는 이에 대해 컨테이너 액션을 사용하지 않는다.

FSM이 처리 상태이면, SSF 및 SCF는 동시에 액션되는데, 이는 동기화되지 않는다.

Cp 및 Ap의 레그에 대한 FSM은 모든 상태-전이, 액션 등을 포함해서 동일하다. 이런 FSM은 단지 유휴 및 활성화 상태만을 갖는다. 이런 FSM은 동작에 대한 컨테이너 문맥으로서 기능한다. Cp 및 Ap의 레그가 동일하기 때문에, 또한, 각 레그는 (유휴 상태 이외의) 하나의 상태만을 갖기 때문에, 레그-프로세스는 현존의 프로세스를 활성화로부터 유휴 상태로 전이하고, 새로운 프로세스(목적-뷰[target-view]에서)를 유휴로부터 활성화로 전이함으로써, Ap로부터 Cp로 및 그 반대로 이동될 수 있다.

따라서, 레그의 위치는 Cp-뷰가 수반될 것인지 또는 Ap-뷰가 수반될 것인지를 판단한다. "레그"의 개념은 콜의 단일 당사자에 할당되는 통신망-자원을 나타낸다. Ap에는 단지 하나의 레그만이 있을 수 있지만, Cp에는 다수의 레그가 있을 수 있다.

이에 따라, 타당성 검증하는 동안에 사상을 처리할 프로세스를 선택하는데 사용되는 기준을 결정할 수 있다.

컨테이너 인터페이스의 개념은 (즉 다른 시스템 또는 동일한 시스템의 부분으로부터 오는) 외부 트리거(trigger)에 대한 시스템의 동작, 또는 시스템의 부분을 기술하기 위해 일반적으로 사용될 수 있음을 주목해야 한다.

컨테이너 인터페이스의 개념은 외부 트리거(trigger)(즉 기타의 시스템 또는 동일한 시스템의 부분으로부터 오는)에 대한 시스템의 동작, 또는 시스템의 부분을 설명하기 위하여 통상적으로 사용된다는 것을 고려하여야 한다.

Claims (6)

1. 다수의 프로세스를 포함하는 지능망에서 사상을 타당성 검증하는 방법으로서,

   모든 프로세스로부터 미리 정해진 기준을 만족하는 프로세스를 선택하는 단계; 및

   상기 선택된 모든 프로세스로 상기 사상을 독립적으로 처리하는 단계를 포함하는데,

   상기 선택 단계가, 상기 프로세스 사이의 컨테이너 인터페이스를 규정하는 단계를 포함하여, 상기 프로세스를 나타내는 유한 상태 기계 사이의 관계성을 규정하는 단계를 포함하는, 사상의 타당성 검증 방법.
2. 제 1 항에 있어서,

   상기 미리 정해진 기준은,

   어떤 유한 상태 기계가 컨테이너 인터페이스를 공유하는지를 판단하는 단계; 및

   어떤 프로세스가 현재 사상의 컨테이너 문맥에 부합되는지를 판단하는 단계를 포함하는 것을 특징으로 하는 사상의 타당성 검증 방법.
3. 제 1 항 또는 제 2 항에 있어서,

   상기 사상이 제 1 프로세스에서 수용되고, 상기 방법은, 상기 선택 단계가 종료될 때까지, 상기 제 1 프로세스에서 상기 사상의 처리 단계를 지연시키는 단계를 포함하는 것을 특징으로 하는 사상의 타당성 검증 방법.
4. 제 1 항 또는 제 2 항에 있어서,

   상기 미리 정해진 기준을 만족하는 프로세스를 선택하는 단계는,

   상기 기준의 세트를 만족하는 상기 프로세스의 제 1 세트를 선택하는 단계;

   상기 프로세스의 제 1 세트로 사상을 사전-처리하는 단계; 및

   상기 사전-처리의 결과에 따라 상기 프로세스의 제 2 세트를 선택하는 단계를 포함하는 것을 특징으로 하는 사상의 타당성 검증 방법.
5. 제 4 항에 있어서,

   상기 프로세스의 제 2 세트는 현재의 컨테이너 액션을 포함하는 경우에만 선택되는 것을 특징으로 하는 사상의 타당성 검증 방법.
6. 제 1 항 또는 제 2 항에 있어서,

   상기 사상의 처리 단계는, 이전에 수용된 사상이 처리 종료될 때까지, 수용된 사상을 대기시키는 단계를 포함하는 것을 특징으로 하는 사상의 타당성 검증 방법.