문맥 (context)
제 3 세대 파트너쉽 프로젝트(3GPP)에서 설정된 바와 같이, IP 멀티미디어 서브 시스템(IMS)은 집중된 네트워크에 대해 액세스-불가지론의 네트워크 아키텍처를 갖는 공통 코어 네트워크를 제공한다. 서비스 제공자는 다음 세대 네트워크 발전에서 이러한 아키텍처를 수용한다. IMS 아키텍처는 처음에 3GPP에 의해 정의되어 IP 네트워크에 걸쳐 모바일 가입자에게 멀티미디어 서비스를 제공한다. IP 네트워크는 비디오, 음성 및 데이터를 전송하는 데에 있어서 가장 저렴한 운반 네트워크가 되었다. IMS는 IMS 플랫폼 상에서 IMS 가입자에게 멀티미디어 서비스를 제공하는 데에 IP 네트워크의 장점을 이용한다.IMS 네트워크 내에서 사용되는 시그널링은 SIP 프로토콜이다. IMS는 애플리케이션 서버들과, IMS 코어 네트워크(CSCF), IMS 가입자들, IMS 데이터베이스(HSS) 및 IMS 빌링 소자(billing elements)들 사이에서 표준 SIP 인터페이스를 정의한다. 이러한 표준은 네트워크 집적화 비용을 감소시킬 수 있으며 가입자가 보다 안정적인 서비스를 즐길 수 있도록 한다.
IMS 플랫폼 상에서, 통화 전송, 컨퍼런싱(conferencing) 및 통화 대기와 같은 통상적인 추가 서비스가 IMS 가입자들에게 제공될 수 있다. 또한, 즉석 교신(instant messaging), 비디오 통화, 비디오 대기 및 웹 기반 서비스와 같은 새로운 데이터 서비스들이 IMS 가입자들에게 제공될 수 있다.
운영자 수익 발생을 위한 효율적인 IMS 온라인 과금을 제공하는 것은 IMS 네트워크의 성공적인 디플로이먼트(deployment)에 중요하다. 몇몇 3GPP 기술 명세서들은 IMS 네트워크용 온라인 과금을 기술한다. 예를 들어, 3GPP TS 32.200 명세서는 세션 기반 과금 기능(a session-based charging function)를 갖는 온라인 과금 시스템(OCS)을 기술한다. OCS는 IMS 서비스 제어(ISC) 인터페이스를 통해 호출 세션 제어 기능부(CSCF)로 연결된다. CSCF는 발신측 또는 수신측에 대한 호출 세션을 제어하고 호출 세션에 대한 온라인 과금을 제공하도록 ISC 인터페이스 상에서 OCS와의 통신을 필요로 한다. 그러나, ISC 인터페이스는 서비스 인터페이스이며 온라인 과금을 지원하지 않는다. 따라서, CSCF와 OCS 사이의 ISC 인터페이스를 온라인 과금에 사용하도록, 불행히도 추가적인 기능이 OCS에 추가되어야할 필요성이 존재할 수 있다.
추가적인 기능으로 OCS를 오버로딩하는 것을 방지하고 온라인 과금 아키텍처를 일관되게 유지시키기 위해, OCS에 기능을 추가하는 대신 CSCF와 OCS 사이의 인터페이스가 온라인 과금을 지원하도록 변경될 수 있다. 온라인 과금을 지원하는 인터페이스에 대한 하나의 옵션은 과금 메커니즘을 허용하도록 ISC 인터페이스를 확장하는 것이다. 이렇게 되면, ISC 인터페이스는 서비스 인터페이스 및 과금 인터페이스일 수 있다. 불행히도, ISC 인터페이스를 혼합적인 서비스/과금 인터페이스로서 사용하는 것은 3GPP에서 원하는 표준화에서 허용되지 않을 수 있다.
다른 옵션은 Ro 인터페이스가 이미 온라인 과금을 지원하기 때문에 ISC 인터페이스 대신 Ro 인터페이스를 사용하는 것이다. 3GPP TS 32.296 명세서는 CSCF와 OCS 사이에서 게이트웨이로서의 역할을 하는 IMS 게이트웨이 기능부를 삽입함으로써 Ro 인터페이스를 온라인 과금용으로 사용하는 것을 권장한다. 도 1은 IMS 게이트웨이 기능부(102)를 포함하는 3GPP 온라인 과금 아키텍처(100)를 도시한다. 3GPP TS 32.296 명세서에서 권장된 바와 같은 IMS 게이트웨이 기능부(102)는 ISC 인터페이스(105) 상의 CSCF(104)와 통신하며 Ro 인터페이스(107) 상의 OCS(106)와 통신한다.
불행히도, 3GPP TS 32.296 명세서 및 다른 3GPP 명세서들은 IMS 게이트웨이 기능부(102)를 온라인 과금에 사용하는 방법을 정의하지 않는다. 예를 들어, 명세서는 IMS 게이트웨이 기능부(102)가 온라인 과금을 제공하기 위해 어떻게 동작하는지를 정의하지 않는다. 명세서는 또한 ISC 인터페이스(105), Ro 인터페이스(107) 및 CSCF(104)가 함께 기능하는 방법을 설명하지 않는다. 예를 들어, 명세서는 CSCF(104)가 게이트웨이(IMS 게이트웨이 기능부)를 통해 OCS(106)에 직접 접속되는지 여부는 표준화의 범주를 벗어난다고 언급한다. IMS 게이트웨이 기능부(102)의 물리적인 위치는 이 명세서에서 명확하지 않다.
또한, 한 운영자의 네트워크에 복수의 OCS가 존재할 수 있다. 도 2는 복수의 201-203을 구비하는 온라인 과금 아키텍처(200)를 도시한다. 온라인 과금 아키텍처(200)는 또한 IMS 게이트웨이(206-207), 서빙-CSCF(S-CSCF)(210-213), 프록시-CSCF(P-CSCF)(216) 및 가정 가입자 서버(HSS)(217)를 포함한다. P-CSCF(216)는 IP 네트워크(222) 상에서 이동국(220)과 통신한다. OCS(201-203) 각각은 가입자 잔고관리 기능부 (ABMF:Account Balance Management Function)에 대한 가입자 데이터베이스를 구비한다. IMS 게이트웨이(206-207)는 S-CSCF(210-213)으로부터 온라인 과금 정보를 수신하고 호출하거나 호출된 상대방의 계좌를 갖는 적절한 OCS(201-203)로 온라인 과금 정보를 라우팅한다. OCS 라우팅 어드레스는 IMS 게이트웨이(206-207)로의 CSCF SIP INVITE 메시지 내에 포함된다. IMS 게이트웨이(206-207)는 온라인 과금 정보를 (다이아미터 Ro 인터페이스와 함께) OCS(201-203)로 라우팅하는 데에 OCS 라우팅 어드레스를 사용한다.
각각의 IMS 가입자에 대해 OCS 라우팅 어드레스를 공급하는 것은 HSS(217)에서 실행될 수 있다. 3GPP TS 29.228 및 29.229는 HSS(217)에서 각 가입자에게 공급될 HSS 과금 정보를 정의한다. 온라인 과금을 위해, 각 가입자는 제 1 및 제 2 OCS(201-203)에 매핑되는 제 1 이벤트 과금 기능부 네임(Primary Event Charging Function Name) 및 제 2 이벤트 과금 기능부 네임(Secondary Event Charging Function Name)으로서 공급된 두 개의 OCS 라우팅 어드레스를 가질 것이다. 제 1 및 제 2 OCS(201-203)는 이러한 가입자의 잔고를 갖는다.
일 문제점은 상기 명세서에서의 3GPP 표준 규정은, OCS 라우팅 어드레스가 온라인 과금을 위해 IMS 게이트웨이(206-207)로 전송되는 SIP 메시지에 포함된다는 것을 보장하기에 충분치 않다는 점이다. IMS 게이트웨이(206-207)가 S-CSCF(210-213)로부터 OCS 라우팅 어드레스 없는, 또는 올바르지 않은 OCS 라우팅 어드레스를 갖는 SIP INVITE 메시지를 수신하는 경우가 있을 수 있다. 만약 그들이 OCS 라우팅 어드레스를 수신하지 못하거나 올바르지 않은 OCS 라우팅 어드레스를 수신한다면, IMS 게이트웨이(206-207)는 호출을 라우팅하기 위해 IMS 가입자에 대한 OCS 매핑을 검색해야 한다. 그러나 IMS 게이트웨이가 IMS 가입자에 대한 OCS 매핑을 검색할 수 있는 방법에 대한 3GPP의 규정이나 다른 표준들은 존재하지 않는다. 또한 INVITE 메시지 내에 제공된 OCS 라우팅 어드레스를 유효화하는 방법에 대해 3GPP 내의 규정도 존재하지 않는다.
IMS 게이트웨이(206-207)로 전송된 SIP 메시지가 OCS 라우팅 어드레스를 포함하지 않거나 또는 OCS 라우팅 어드레스가 유효하지 않은 다양한 가능성이 존재한다. 첫째로, HSS(217)가 올바르지 않은 가입자 과금 정보를 가지는 경우이다. 둘째로, HSS(217)에 가입자 과금 정보가 선택적이기 때문에 공급되지 않은 경우이다. 셋째로, HSS(217)에 가입자 과금 정보가 공급되었으나 S-CSCF(210-213)에 과금 기능부 네임이 존재하지 않고 IP 어드레스 매핑이 공급되지 않는 경우이다. 넷째로, HSS(217)이 가입자 과금 정보를 공급받았으나 S-CSCF/HSS가 온라인 호출인지 또는 오프라인 호출인지 여부를 판단할 수 없는 경우이다. S-CSCF(210-213)는 이것을 온라인 호출로서 간주하고 IMS 게이트웨이(206-207)로 먼저 SIP 메시지를 라우팅할 수 있다. IMS 게이트웨이(206-207)는 호출을 어디로 라우팅할지를 반드시 알아내야 한다. 다섯째로, 리거시(legacy) 가입자는 HSS(217)에 등록 데이터를 갖지 않는다. 리거시 가입자로부터/로의 IMS 호출은 올바른 OCS(201-203)로 매핑되는 과금 정보를 갖지 않는다.
온라인 IMS 호출 세션에 대한 OCS 라우팅의 효율성을 증가시키는 것이 요구된다.
지시문 (instruction)
주어진 원문을 읽고 필요한 정보를 파악하여, 원문에 근거해 질문에 답하라.
질문 (question)
IMS 게이트웨이가 S-CSCF로부터 수신한 SIP INVITE 메시지 내에 OCS 라우팅 어드레스가 포함되어 있지 않거나 유효하지 않을 때, IMS 게이트웨이가 수행해야 하는 동작은 무엇인가?
추론 과정 (compact_reasoning)
-
1과제 해석
task_interpretationSIP INVITE 메시지에 OCS 라우팅 어드레스가 없거나 잘못된 경우 IMS 게이트웨이가 취해야 하는 조치를 확인해야 한다.
-
2정보 추출
information_extraction메시지에 OCS 라우팅 어드레스가 없는 상황에 대한 본문의 설명을 추출한다.
- 만약 그들이 OCS 라우팅 어드레스를 수신하지 못하거나 올바르지 않은 OCS 라우팅 어드레스를 수신한다면, IMS 게이트웨이(206-207)는 호출을 라우팅하기 위해 IMS 가입자에 대한 OCS 매핑을 검색해야 한다.
-
3근거 선택
evidence_selectionIMS 게이트웨이가 수행해야 할 구체적인 동작인 'OCS 매핑 검색'을 근거로 선택한다.
- IMS 게이트웨이(206-207)는 호출을 라우팅하기 위해 IMS 가입자에 대한 OCS 매핑을 검색해야 한다.
-
4논리 통합
logical_integration라우팅 어드레스 부재 시 호출 라우팅을 위해 필요한 선행 작업이 OCS 매핑 검색임을 연결한다.
-
5결론 도출
conclusion_formulationIMS 게이트웨이는 호출을 라우팅하기 위해 IMS 가입자에 대한 OCS 매핑을 검색해야 한다는 결론을 도출한다.
- IMS 게이트웨이(206-207)는 호출을 라우팅하기 위해 IMS 가입자에 대한 OCS 매핑을 검색해야 한다.
-
6답변 생성
answer_generation질문에 대해 문맥에 근거하여 명확하게 답변을 작성한다.
- IMS 게이트웨이(206-207)는 호출을 라우팅하기 위해 IMS 가입자에 대한 OCS 매핑을 검색해야 한다.
최종 답변 (final_answer)
IMS 게이트웨이는 호출을 라우팅하기 위해 IMS 가입자에 대한 OCS 매핑을 검색해야 한다.
핵심 해석 (core_interpretation)
정상적인 OCS 라우팅 정보가 결여된 상황에서 IMS 게이트웨이가 호출 라우팅을 지속하기 위해 수행해야 하는 조건부 동작이다.