KR20050115307A

KR20050115307A - 통신 시스템에서의 서비스 제공

Info

Publication number: KR20050115307A
Application number: KR1020057017968A
Authority: KR
Inventors: 일카 워스트맨; 가보르 바즈코; 세뽀 후오타리; 크리스티안 키스; 올리 엠. 풀키넨; 칼레 타미; 마르쿠 투오히노
Original assignee: 노키아 코포레이션
Priority date: 2003-03-25
Filing date: 2004-03-24
Publication date: 2005-12-07
Also published as: JP4280284B2; RU2368100C2; WO2004086789A1; KR101107948B1; EP1609322B1; JP2006521717A; KR100807863B1; EP1609322A1; KR20080003459A; RU2005132822A

Abstract

본 발명은 통신 시스템에 관한 것으로, 특히 상기 통신 시스템과 관련된 엔티티 사이에 필요한 통신을 제공하는 서비스의 개시에 관한 것이다.

본 발명에 따른 통신 시스템에서의 서비스 제공 방법은, 통신 시스템과 연관된 제1 엔티티에서 통신 시스템의 사용자에게 서비스 가능한 통신 제어 엔티티에 관한 저장 엔티티로부터 정보를 수신하는 단계와, 상기 정보에 기초하여, 상기 제1 엔티티로부터 상기 통신 제어 엔티티로 발신 요청 신호를 보내는 단계를 포함한다.

Description

통신 시스템에서의 서비스 제공{SERVICE PROVISIONING IN A COMMUNICATION SYSTEM}

통신 시스템은 사용자 장비, 통신 네트워크 요소 및 상기 통신 시스템과 관련된 다른 엔티티 등의 2개 이상의 엔티티 사이의 통신을 가능하게 하는 설비로 알려져 있다. 통신 시스템은 전형적으로 상기 통신 시스템과 관련된 여러 엔티티가 무엇을 행하도록 허용되는지와 그것이 어떻게 달성되어야 하는지를 제시하는 주어진 표준 또는 규격에 따라 동작한다. 예를 들어, 상기 표준 또는 규격은 사용자, 또는 더 정확하게 사용자 장비 또는 단말기에 회선 교환 서비스가 제공되는지 및/또는 패킷 교환 서비스가 제공되는지 여부를 정의할 수 있다. 또한, 접속을 위해 사용되는 통신 프로토콜 및/또는 파라미터도 정의될 수 있다. 다시 말해, 상기 시스템에 의한 통신을 가능하게 하도록 통신이 기초로 할 수 있는 "규칙"의 특정 세트가 정의될 필요가 있다.

사용자 장비에 대한 무선 통신을 제공하는 통신 시스템은 알려져 있다. 상기 무선 시스템의 예는 셀룰러 네트워크이다. 셀룰러 시스템에서, 송수신 기지국(BTS) 또는 유사한 액세스 엔티티는 이들 엔티티 사이의 무선 인터페이스를 통해 이동국(MS) 또는 다른 무선 사용자 장비(UE)에 서비스한다. 사용자 장비와 통신 네트워크의 요소 사이의 통신은 적절한 통신 프로토콜에 기초할 수 있다. 상기 기지국 장치와 통신에 필요한 다른 장치의 동작은 하나 또는 여러 제어 엔티티에 의해 제어될 수 있다. 여러 제어 엔티티는 상호접속될 수 있다. 또한, 상기 셀룰러 네트워크를 다른 네트워크, 예를 들어 공중 교환 전화 네트워크(PSTN) 및/또는 IP(Internet Protocol) 및/또는 다른 패킷 교환 네트워크 등의 다른 통신 네트워크에 접속하기 위해 하나 또는 그 이상의 게이트웨이 노드가 제공될 수 있다.

통신 시스템의 가입자에게 제공될 수 있는 서비스의 예는 소위 멀티미디어 서비스이다. 상기 멀티미디어 서비스를 제공할 수 있는 통신 시스템은 종종 IP 멀티미디어 네트워크라 칭해진다. IP 멀티미디어(IM) 기능은 IP 멀티미디어 코어 네트워크(CN) 서브시스템, 또는 간략하게 IP 멀티미디어 서브시스템(IMS)에 의해 제공될 수 있다. 상기 IMS는 상기 멀티미디어 서비스를 제공하기 위한 여러 엔티티를 포함한다.

통신 시스템은 네트워크의 여러 서비스 제공 기능이 서버로 알려진 네트워크 엔티티에 의해 처리되는 방향으로 개발되어 왔다. 예를 들어, 현재의 제 3 세대(3G) 무선 멀티미디어 네트워크 아키텍처에서, 여러 서로 다른 서버가 서로 다른 기능을 처리하는데 사용되는 것으로 가정된다. 이들은 호 세션 제어 기능(CSCF) 등의 기능을 포함한다. 호 세션 기능은 프록시 호 세션 제어 기능(P-CSCF), 심문 호 세션 제어 기능(I-CSCF) 및 서빙 호 세션 제어 기능(S-CSCF) 등의 여러 카테고리로 나누어질 수 있다. 이해되는 바와 같이, 때때로 CSCF는 호 상태 제어 기능 또는 호 서버 제어 기능이라 칭해질 수 있다.

서빙 호 세션 제어 기능은 통신 시스템으로부터 서비스를 요청할 수 있도록 가입자가 등록되어야 하는 엔티티를 형성한다. 상기 서빙 호 세션 제어 기능은 세션의 발신 및 착신 단(end)에서의 발신 호 세션 제어 기능(O-CSCF) 및 착신 호 세션 제어 기능(T-CSCF) 사이로 더 분할될 수 있다.

상기 서빙 제어 엔티티에 더하여, 사용자는 P-CSCF 등의 프록시 제어 엔티티와 관련되어야 할 수 있다. 상기 프록시 엔티티는 사용자가 서비스받는 영역에 할당될 수 있다.

홈 가입자 서버(HSS) 및 여러 응용(application) 서버 등의 엔티티도 통신 네트워크에 제공될 수 있다. 상술한 서버 중에, 상기 홈 가입자 서버(HSS)는 가입자 관련 정보를 저장하기 위한 것이다. 상기 가입자 정보는 인증 데이터(예를 들어, 가입자 또는 단말기의 등록 식별) 등의 정보를 포함할 수 있다. 상기 HSS는 전형적으로 가입자 프로파일 정보를 영구적으로 저장하기 위해 사용된다. 상기 홈 가입자 서버(HSS)는 예를 들어, 세션 셋업 절차 동안 다른 기능 엔티티에 의해 질문을 받을 수 있다.

응용 서버(AS)는 사용자에 대한 부가 가치 IM 서비스를 제공하도록 된 엔티티이다. 응용 서버는 사용자의 홈 네트워크에 상주할 수 있다. 상기 응용 서버는 또한, 대안적으로 사용자의 홈 네트워크의 외부에 있을 수 있고 제 3 진영(party) 서비스에 의해 제공될 수 있다. 상기 제 3 진영은 또 다른 네트워크이거나 또는 단순하게 자립형(stand-alone) 응용 서버일 수 있다. 응용 서버는 운영자의 네트워크에 의해 서비스를 지원받는 대신에 데이터 통신 세션에 영향을 줄 수 있다. 응용 서버는 서비스를 호스팅하고 실행할 수 있다. 상기 응용 서버의 예는 세션 개시 프로토콜(SIP) 응용 서버, 개방 서비스 액세스(OSA) 응용 서버 및 CAMEL IM-SSF(Customized Application for Mobile network Enhanced Logic IP Multimedia Service Switching Function)를 포함한다.

전형적으로 통신 시스템은 사용자, 일반적으로 가입자가 통신 시스템을 통해 통신을 개시해야 하도록 구성된다. 예를 들어, 사용자는 적절한 통신 네트워크 엔티티로부터 세션, 트랜잭션 또는 다른 타입의 통신을 요청할 수 있다. 그와 같은 통신은 사용자로부터 발신하는 것으로 알려질 수 있다.

따라서, 발신 세션/트랜잭션은 사용자의 사용자 장비에 의해, 또는 사용자 대신 네트워크 엔티티에 의해 통상적으로 발신되는 세션/트랜잭션으로 이해된다. 착신 세션/트랜잭션은 사용자의 사용자 장비에 의해 또는 사용자 대신 네트워크 엔티티에 의해 정상적으로 착신되는 세션/트랜잭션이다.

예를 들어, 3GPP(Third Generation Partnership Project) 릴리즈 4(Rel-5) IMS 네트워크는 사용자 장비(UE)가 세션 및 단일 트랜잭션을 발신할 수 있는 방법에 대한 규칙을 정의한다. 그러나, Rel-5에 주어진 규칙만이 소위 발신 필터링 기준이 어떻게 적용되는지에 집중한다. 릴리즈 5는 사용자 대신에 임의의 다른 진영이 세션 또는 트랜잭션을 발신하게 하지 못한다. 3GPP 표준의 릴리즈 6은 응용 서버(AS)가 사용자 장비 대신에 S-CSCF에 대한 ISC(IP 멀티미디어 서비스 제어) 인터페이스를 통해 세션 개시 프로토콜(SIP) 요청을 전송할 수 있어야 할 것을 필요로 한다. 그러나, 현재의 3GPP 표준의 릴리즈 6은 상기 응용 서버가 발신한 요청이 사용자 장비로부터 발신되는 요청에 의해 직접 트리거되는 예외적인 경우 외에는 상기 응용 서버가 상술한 바와 같이 행하도록 할 수 있는 상기 응용 서버(AS)에 대한 어떠한 메커니즘도 제공하지 않는다. 따라서, 상기 응용 서버는 여전히 사용자 대신에 SIP 요청이나 다른 요청을 발생시키는 서비스를 실행할 수 없다.

본원 발명자는 사용자가 발신 진영인 것처럼 보일 수 있도록, 응용 서버와 같은 네트워크 엔티티가 상기 사용자 대신에 통신을 요청하는 프로세스를 개시할 수 있다면 유용할 것이라는 것을 알게 되었다. 이와 같은 사항이 유용할 수 있는 서비스의 예는 메시징 리스트를 포함하고, 여기서 상기 응용 서버는 사용자 대신에 상기 리스트의 멤버에 메시지를 전송할 수 있다. 또 다른 예는 사용자의 프레젠스 상태를 전달하는 메시지를 상기 사용자 대신에 전송할 수 있는 응용 서버이다. 또 다른 예는 예를 들어, 컨퍼런스나 그룹 호출 또는 채팅 응용을 위해 사용자 대신에 세션 또는 트랜잭션을 시작할 수 있는 응용이다. 이해되는 바와 같이, 상기 리스트는 소수의 예일 뿐이며, 네트워크 엔티티가 통신을 위한 요청을 발신할 수 있다는 가능성으로부터 이점을 가질 수 있는 여러 다른 서비스가 존재한다.

그러나, 네트워크 엔티티가 발신한 요청을 처리하는 메커니즘이 없기 때문에, 그와 같은 동작은 현재의 통신 시스템에서 문제점을 발생시킬 수 있다. 예를 들어, 후속의 통신 라우팅, 충전 기능 등에 관하여 문제점이 발생할 수 있다. 이와 같은 문제는, 통신 시스템의 다른 엔티티가 예를 들어, 임의의 추가 메시지를 어디에 전달하는지 또는 상기 통신을 어떻게 제어하는지를 알 수 없기 때문에 발생한다.

예를 들어, S-CSCF가 메시지를 수신하면, 상기 메시지를 어떻게 처리할지 결정할 수 있어야 한다. 현재의 시스템에서, S-CSCF는 '발신 필터' 및 '착신 필터'로 알려진 필터 기준을 메시지에 적용할 수 있다. 용어 '필터 기준'(FC)은 특정 서비스 응용에 대한 관련 서비스 포인트 트리거(Service Point Trigger:SPT)를 정의하는 정보를 지칭한다. SIP 통신 환경에서, 상기 필터 기준은 특정 서비스 응용에 전송되거나 프록시되어야 하는 S-CSCF에 의해 수신되는 SIP 요청의 서브세트를 정의한다. 상기 S-CSCF는 홈 가입자 서버(HSS) 또는 응용 서버(AS)로부터 상기 필터 기준을 수신할 수 있다.

종래 기술에서, 착신 필터 기준은 상기 응용으로부터의 모든 메시지에 적용된다. 그러나, 상기 메시지는 응용 서버에 의해 발신되는 서비스 요청 또는 네트워크의 사용자 대신에 발신되는 그와 같은 다른 메시지일 수 있다. 따라서, 본 발명자는 착신 필터 기준 대신에 발신 필터 기준이 상기 메시지에 적용되어야 하는지를 결정하기 위한 메커니즘이 필요하다는 것을 알게 되었다. 이는 상기 발신 필터 기준이 그와 같은 메시지에 대해 더 정확한 평가 결과를 제공할 수 있기 때문이다.

잘못된 "역할", 즉 필터 기준이 상기 메시지에 대해 사용되면, 예를 들어, 라우팅 및 다른 제어 동작의 관점에서 문제점이 발생할 수 있다. 일단 이러한 관점에서 결정이 이루어지면, 상기 결정된 역할은 또한 통신 시스템의 다른 엔티티에 전달되어야 할 수 있어, 상기 다른 엔티티는 상기 메시지가 전송되는 사용자 대신 또 다른 엔티티로부터 발신하는 메시지를 평가하기 위해 적절한 필터 기준을 적용할 수 있다.

예에 의하여 첨부 도면을 참조함으로써, 본 발명을 더 잘 이해할 수 있을 것이다.

도 1은 본 발명이 구체화되는 통신 시스템을 도시한다.

도 2는 본 발명의 일 실시 예를 도시한다.

도 3 및 4는 다른 실시 예를 도시한다.

도 5는 실시 예에 의해 서비스 제공을 도시하는 흐름도이다.

본 발명의 실시 예들은 하나 또는 다수의 상기 문제를 해결하는 것이 목적이다.

본 발명의 일 측면에 따라, 통신 시스템의 서비스 제공 방법을 제공하며, 상기 방법은, 통신 시스템과 연관된 제1 엔티티에서 통신 시스템의 사용자에게 서비스 가능한 통신 제어 엔티티에 관한 저장 엔티티로부터 정보를 수신하는 단계와, 그리고 상기 정보에 기초하여, 상기 제1 엔티티로부터 상기 통신 제어 엔티티로 발신 요청 신호를 보내는 단계를 포함하는 것이 특징이다.

본 발명의 일 측면에 따라, 통신 시스템의 사용자를 위하여 서비스들을 제공하는 통신 시스템은,

통신 시스템의 사용자에게 서비스 가능한 통신 제어 엔티티와; 그리고

저장 엔티티로부터 사용자에 관한 정보를 수신하는 제1 인터페이스와, 상기 저장 엔티티로부터의 상기 정보에 기초하여 발신 요청 신호를 상기 통신 제어 엔티티로 보내는 제2 인터페이스를 제공 받는 제1 엔티티를 포함하는 것이 특징이다.

본 발명의 또 다른 일 측면에 따라, 통신 시스템용 응용 서버를 제공한다. 상기 응용 서버는, 저장 엔티티로부터 상기 통신 시스템의 사용자에 관한 정보를 수신하는 제1 인터페이스와, 상기 저장 엔티티로부터의 상기 정보에 기초하여 발신 요청 신호를 상기 통신 제어 엔티티로 보내는 제2 인터페이스를 제공 받는 제1 엔티티를 포함하는 것이 특징이다.

본 발명의 또 다른 일 측면에 따라, 인터페이스 상에 신호로 보내지는 발신 요청(orignating request)을 제공한다. 상기 발신 요청은, 통신 시스템의 제1 엔티티와 통신 시스템의 사용자에게 서비스 가능한 통신 제어 엔티티 사이에 인터페이스 상에 신호로 보내지는 발신 요청으로서, 상기 발신 요청이 사용자 정보 저장 엔티티로부터의 정보에 기초하여 생성되는 것이 특징이다.

보다 상세한 실시 예에서 상기 발신 요청은, 상기 요청과 연관된 통신들 처리에 관한 정보를 포함한다. 상기 발신 요청은, 상기 발신 요청과 연관된 향후 통신들이 상기 요청이 사용자로부터 발원되었던과 같이 유사한 방식으로 처리될 것이라는 지시자를 포함한다. 착신 서비스들 또는 발신 서비스들 중에 하나의 서비스들이 요청에 기초하여 제공된다.

상기 제1 엔티티에서 상기 통신 제어 엔티티가 상기 요청과 연관된 향후 통신들을 어떻게 처리할 것인지를 결정될 수 있다.

상기 제1 엔티티가 사용자를 대신하여 상기 발신 요청을 생성할 수 있다. 상기 착신 요청이 상기 통신 제어 엔티티의 주소에 관한 정보에 기초하여 생성될 수 있다. 상기 제1 엔티티는 상기 발신 요청을 전송하기 전에 상기 통신 제어 엔티티의 주소에 관한 상기 정보를 수정할 수 있다. 상기 제1 엔티티는 서비스 유형 지시자를 상기 발신 요청에 부가할 수 있다. 상기 서비스 유형 지시자각 상기 통신 제어 엔티티의 주소 내에 포함될 수 있다.

상기 제1 엔티티가 상기 요청을 전송할 포트를 선택할 수 있다.

소정의 조회가 상기 발신 요청을 전송하기 전에 상기 제1 엔티티로부터 데이터베이스로 전송될 수 있다. 이러한 조회는 상기 통신 제어 엔티티에 관한 정보에 기초한 것이다.

소정의 조회(enquiry)가 사용자에게 서비스 가능한 통신 제어 엔티티에 관한 상기 정보를 위하여 상기 제1 엔티티로부터 상기 저장 엔티티로 전송될 수 있다.

상기 통신 제어 엔티티 정보에 대한 주소들로서, 적어도 두개의 다른 주소들에 관한 정보가, 상기 저장 엔티티에 저장될 수 있다.

상기 발신 요청은 상기 요청에 적용될 필터 기준(filter criteria)을 지시할 수 있다.

본 발명의 실시 예들은 통신 네트워크의 엔티티들이 사용자를 대신하여 서비스가 수행되도록 한다. 이를 위한 해결은 기존 통신 시스템에서 구현하기 쉽다. 그러한 예로서, 사용자 정보를 와 같은 중앙 집중화 방식, 예를 들어 홈 가입자 서버(HSS)에 저장하는데, 이런 중앙 집중화 저장은 수정될 필요가 없다. 특정 실시 예들에서, 정상 통신 프로토콜들 및 절차들을 사용하여, 정확한 서비스 엔트리 포인트를 찾는 조회와 같이 상기 사용자 정보 저장을 조회할 수 있다.

본 발명이 구체화되는 IP 멀티미디어 네트워크를 도시하는 도 1을 참조한다. IP 멀티미디어 서비스는 IP 멀티미디어 네트워크 가입자를 위해 제공된다. IP 멀티미디어(IM) 기능은 서비스 제공을 위해 다양한 엔티티를 포함하는 코어 네트워크(CN) 서브시스템에 의해 제공된다.

본 발명에서, 통신 시스템의 일 엔티티는 통신 제어 엔티티에 의해 사용자에 제공될 서비스와 연관된 발신(originating) 요청를 송신한다. 하기의 상세한 예에서, 엔티티는 응용 서버를 포함하며, 통신 제어 엔티티에 서빙(serving) 호 세션 제어 기능이 제공된다. 실시 예를 더 상세히 설명하기 이전에, 이들 요소 및 실시 예와 연관된 다른 가능한 요소들에 대한 간단한 설명이 하기에서 도 1을 참조하여 제공된다. 도 1은 단지 이동 통신 시스템의 일부의 예임을 이해해야 한다.

도시된 구성에서, 기지국(11)은 셀룰러 통신 네트워크의 액세스 엔티티를 제공한다. 무선 액세스 네트워크(11)는 적합한 제어기(명확성을 위해 미도시)에 의해 제어된다. 제어기는 각 기지국에 제공되거나, 일 제어기가 복수의 기지국을 제어할 수 있다. 제어기가 개별 기지국에, 그리고 복수의 기지국을 제어하기 위해 무선 액세스 네트워크 레벨에 제공되는 솔루션이 이미 공지되었다. 따라서, 액세스 네트워크 제어기의 명칭, 위치 및 개수가 시스템에 의존함을 이해해야 한다. 예를 들어, UMTS 지상 무선 액세스 네트워크(UTRAN)는 무선 네트워크 제어기(RNC)로서 지칭되는 제어기 노드를 이용한다. GSM 및 CDMA에서, 대응하는 무선 네트워크 제어기 엔티티는 기지국 제어기(BSC)로서 지칭된다.

도 1의 표현은 상당히 개략적이며, 기지국 개수는 실제 구현에서 더 많을 수 있음을 이해해야 한다. 하나의 액세스 네트워크가 하나 이상의 기지국을 포함할 수 있다. 기지국 장치 또는 사이트는 또한 하나 이상의 액세스 네트워크를 제공할 수 있다. 이러한 특성은 구현 및 환경에 의존한다.

기지국(11)은 무선 인터페이스를 통해 이동 사용자, 즉 가입자의 이동 사용자 장비(10)로부터 신호를 전송하고 수신하도록 된다. 따라서, 이동 사용자 장비(10)는 무선 인터페이스를 통해 신호를 전송하고 수신할 수 있다. 이동 사용자는 인터넷 프로토콜(IP) 통신을 위해 적응된, 모든 적합한 이동 장치를 사용하여 네트워크에 연결될 수 있다. 예를 들어, 이동 사용자는 퍼스널 컴퓨터(PC), 개인 데이터 어시스턴트(PDA), 이동국(MS) 등에 의해 셀룰러 네트워크에 액세스할 수 있다. 하기의 예시는 이동국 환경에서 설명된다.

당업자는 전형적인 이동국의 특성 및 동작을 잘 알고 있다. 따라서, 이에 대한 어떠한 상세한 설명이 필요하지 않게 된다. 사용자가 전화 호 설정 및 수신, 네트워크로부터/네트워크로 데이터 수신/송신, 및 예를 들어, 멀티미디어 콘텐트의 경험(experience)과 같은 작업을 위해 이동국(10)을 사용하고 있음을 알고 있으면 충분하다. 이동국은 이동통신 네트워크의 기지국으로부터/기지국으로 신호를 무선으로 수신/전송하기 위한 안테나 요소를 포함한다. 이동국(10)에 또한 이동 사용자 장비의 사용자를 위해 이미지 및 다른 그래픽 정보를 디스플레이하기 위한 디스플레이가 제공된다. 스피커 수단이 또한 전형적으로 제공된다. 이동 사용자 장비의 동작은 제어 버튼, 음성 명령 등과 같은 적합한 사용자 인터페이스에 의해 제어된다. 더욱이, 이동 사용자 장비에 프로세서 엔티티 및 메모리 수단이 제공된다. 명확성을 위해 단지 하나의 이동국만이 도 1에 도시되었지만은, 다수의 이동국이 이동 통신 시스템의 각 기지국과 동시에 통신할 수 있음을 이해해야 한다.

코어 네트워크(CN) 엔티티는 전형적으로 다수의 무선 액세스 네트워크를 통해 통신할 수 있게 하며, 또한 일 통신 시스템을 다른 셀룰러 시스템 및/또는 고정 라인 통신 시스템과 같은 다른 통신 시스템과 인터페이스되게 하기 위한 다양한 스위칭 및 다른 제어 엔티티와 게이트웨이를 포함한다.

현재 제 3 세대(3G) 무선 IP 멀티미디어 네트워크 아키텍처에서, 여러 다른 서버 엔티티가 다른 기능을 처리하는데 사용되는 것으로 가정된다. 이는 호 세션 제어 기능(CSCF)을 처리하는 엔티티를 포함한다. 호 세션 기능은 프록시 호 세션 제어 기능(P-CSCF)(12), 심문(interrogating) 호 세션 제어 기능(I-CSCF)(24), 및 서빙 호 세션 제어 기능(S-CSCF)(14)과 같은 다양한 카테고리로 나뉜다.

서빙 호 세션 제어 기능(14)은 가입자(10)가 등록되는 엔티티를 형성한다. 통신 시스템으로부터 서비스를 요청할 수 있게 하기 위해, 등록이 요청된다. 사용자는 기지국(11)과 같은 통신 시스템의 액세스 엔티티를 통해 자신을 등록할 수 있다. 서빙 호 세션 제어 기능(14)은 세션 또는 트랜잭션의 발신 및 착신 단에서 발신 호 세션 제어 기능(O-CSCF) 및 착신(terminating) 호 세션 제어 기능(T-CSCF)을 제공하는 것으로서 보여진다.

사용자는 동시에 하나 이상의 호 세션 제어 기능에 등록될 수 있다. 서빙 제어 엔티티(14) 이외에, 사용자는 도 1의 P-CSCF(12)와 같은 프록시 제어 엔티티와 연관될 필요가 있다. 프록시 엔티티(12)는 사용자가 로밍(roaming)하는 영역 내로 배치될 수 있다. 따라서, 사용자가 임의의 종류의 액세스 네트워크를 통해 네트워크에 액세스할 때에, 액세스 네트워크는 네트워크의 시점에서(예를 들어, 대역폭 관리를 위해) 액세스된 서비스를 제어하기 위해 프록시 제어 엔티티를 배치할 수 있다. 또한, 사용자는 액세스 네트워크의 도움없이 자신의 사용자 장비와 적합한 P-CSCF를 검색하여 찾는 것이 가능하다.

또한, 홈 가입자 서버(home subscriber server;HSS)(20)가 도시된다. 상기에서 설명된 바와 같이, 홈 가입자 서버(HSS)(20)는 가입자, 즉 사용자 관련 정보를 저장하기 위한 것이다. 홈 가입자 서버(HSS)는 예를 들어, 세션 설정 절차 중에 적합한 인터페이스를 통해 다른 기능 엔티티에 의해 조회될 수 있다.

홈 가입자 서버(HSS)(20) 및 서빙 호 세션 제어 기능(S-CSCF)(14)과 인터페이싱하는 응용 서버(22)가 또한 도시된다. 일반적으로, 응용 서버는 사용자의 가입에 따라 세션/트랜잭션에서 이용가능한 서비스(들)를 호스트하는 엔티티로서 보여 진다. 응용 서버로의 라우팅은 사용자의 가입과 연관되는 필터 기준의 평가 결과로서 수행된다.

상술된 바와 같이, 두 세트의 필터 기준이 사용된다. 필터 기준 세트 중 하나는 착신 세션/트랜잭션을 위해, 다른 하나는 발신 세션/트랜잭션을 위해 사용된다.전형적인 동작에서, 필터링은 단지 최초 메시지, 즉 초기 요청에만 적용된다. 나머지 메시지는 필터링 없이 처리될 수 있는데, 이는 라우트가 초기 요청의 라우팅 동안에 기록되기 때문에 그러하다. 따라서, 필터 기준은 추가의 요청에 영향을 미치는데, 이들이 기록된 라우트를 통해 라우팅되기 때문에 그러하다. 따라서, 후속 메시지, 즉 초기 요청 이후 동일 다이얼로그의 메시지에 대해 필터 기준을 평가하지 않는 것이 가능하다. 하지만, 필터링은 또한 후속 메시지에 적용될 수 있다.

응용 서버(22)가 메시지를 S-CSCF(14)에 송신함으로써 세션 또는 트랜잭션을 발신할 때에, S-CSCF(14)는 어느 역할을 행할지를 결정할 필요가 있다. 만일 S-CSCF(14)가 발신 역할에서 행하기로 선택한다면, S-CSCF는 인입 메시지에 발신 필터 기준을 적용한다. 착신 역할에서, S-CSCF는 착신 필터 기준을 평가한다. 이 선택을 구현하는 다양한 대안 방법이 이하에서 설명될 것이다. S-CSCF는 역할에 따라 서비스의 어드레스를 구축할 것이며, 이는 등록 메시지에 응답하여 P-CSCF에 복귀된다. 이후에, P-CSCF는 메시지를 S-CSCF에 보낼 때에 이 어드레스를 사용해야 한다.

등록 중에, S-CSCF(14)는 세션 또는 트랜잭션을 착신하는데 사용되어야 하는 어드레스, HSS(20)에 통신하는 것이 바람직하다.

도 2에 도시된 바람직한 실시 예에 따르면, 응용 서버(22)는 사용자 장비(10)가 등록된, S-CSCF(14)에 관한 어드레스 정보를 HSS(20)로부터 수신한다. 어드레스 정보는 예를 들어, 엔티티 간의 Sh 인터페이스를 통해 조회에 응답하여 제공되는데, 도 2의 단계(1)를 참조하자. 어드레스 정보는 S-CSCF의 명칭 또는 S-CSCF의 URI(범용 자원 식별자)와 같은 임의의 형태의 적합한 정보일 수 있다.

본 발명의 바람직한 형태에 따르면, 어드레스 정보는 바람직한 역할에 관한 정보를 포함하도록 구성된다. 어드레스 정보는 본 발명의 원리에 따라 응용 서버(22) 내에서 또는 응용 서버 외부에서 구성될 수 있다. 후자의 경우에, 정보는 구성된 형태로 리스트, 테이블, 데이터베이스 또는 어드레스 정보가 페칭(fetching)되는 소스에 저장될 수 있다. 대안적으로, 어드레스 정보는 사용자 장비 또는 네트워크 엔티티로부터 수신된 요청로부터 얻어지거나 저장될 수 있다.

도 2에서, 응용 서버(22)는 단계 번호(2)에 의해 어드레스 정보의 구성을 책임지는 것으로서 표시된다. 특히, 응용 서버(22)는 가입자에게 적합한 서비스 종류가 제공되도록 어드레스 정보를 수정할 수 있다. 예를 들어, 응용 서버(20)는 필요한 서비스에 대한 정확한 어드레스를 구축하도록 서비스 명칭을 수정할 수 있다. S-CSCF 명칭은 예를 들어, HSS로부터 수신된 명칭에 접두사(prefix)로서 지시자 파라미터 "term" 또는 "orig"를 부가함으로써 수정될 수 있다. 예를 들어, 어드레스

scscf12.operator.net name

응용 서버가 시작하는 세션 또는 트랜잭션이 세션 또는 트랜잭션을 발신하는지 또는 착신하는지에 따라 하기사항 중 하나로 수정될 수 있다:

orig.scscf12.operator.net 또는

term.scscf12.operator.net

단계(3)에서, 어드레스는 적합한 서비스의 IP 어드레스를 얻기 위해 DNS(도메인 명칭 시스템)(26)로 결정된다.

상기 수정에 따라, 어드레스는 메시지를 발신 또는 착신 서비스로 지시하게 한다. 따라서, 단계(4)에서 응용 서버(22)가 서비스 요청 메시지를 발신 서비스나 착신 서비스에 라우팅할 수 있는 수단으로서 제공된다. 도 1에 도시된 바와 같이, 이는 ISC(IP 멀티미디어 서비스 제어) 인터페이스 상에서 발생될 수 있다.

응용 서버(22)는 대안적으로 특정 파라미터를 URI에 부가함으로써 서비스의 URI를 수정하여, 발신 서비스를 위한 정확한 어드레스를 구축할 수 있다. 이후에, 응용 서버(22)는 라우팅 어드레스로서 파라미터를 함께 갖는 URI를 이용하여 메시지를 라우팅할 수 있다.

응용 서버(22)는 반드시 착신 서비스에 대한 명칭 또는 URI를 수정할 필요가 없음을 이해해야 한다. 즉, 어떠한 수정도 이루어지지 않는 경우에, 착신 서비스가 제공된다.

또한, 어드레스는 단지 착신 서비스의 경우에만 수정되며, 발신 서비스의 경우에는 어떠한 어드레스 수정도 이루어지지 않는 것이 가능하다.

하지만, 착신 및 발신 서비스 어드레스 모두를 수정하는 것이 특정 응용에서, 예를 들어, 대칭성 이유로 바람직하다.

하기의 예는 상술된 원리에 따라 가능한 동작을 더 상세히 설명할 것이다. 응용 서버가 HSS로부터 착신 어드레스를 얻는 것으로 가정한다. 이를 하기의 형태의 예를 들어, 세션 초기화 프로토콜(SIP) 어드레스라고 가정한다(사용자 부분은 생략될 수 있음을 알아야 한다):

xx44@scscf7.operator.net

만일 응용 서버(22)가 착신 세션/트랜잭션을 시작한다면, 이는 타겟 S-CSCF(14)에 시그널링하여, S-CSCF가 착신 세션/트랜잭션 역할을 행하게 하려 할 때에 상기 어드레스를 사용한다. 전형적인 동작에서, 이는, S-CSCF(14)가 인입 메시지를 평가할 때에 착신 필터 기준을 적용할 필요가 있음을 의미한다.

만일 응용 서버(22)가 발신 세션/트랜잭션을 시작하려 한다면, 이는 어드레스를 수정한다. 이는 새로운 "role" 파라미터를 어드레스에 부가함으로써 수행될 수 있다. 따라서, 역할 파라미터 role= orig를 포함하는 수정된 어드레스는 예를 들어, 다음의 형태를 갖는다:

xx44@scscf7.operator.net;role=orig

이후에, 수정된 어드레스는 타겟 S-CSCF는 발신 세션/트랜잭션 역할을 행해야 한다는 지시로서 타겟 S-CSCF에 시그널링한다. 전형적인 동작에서, 이는, S-CSCF가 발신 필터 기준을 평가할 필요가 있음을 의미한다.

S-CSCF의 어드레스는 어드레스가 필요한 응용 서버(22)에 구성될 수 있다. 대안적으로, 어드레스는 모든 응용 서버에 구성될 수 있다. 후자의 대안은 예를 들어, 응용 서버(22)로부터 홈 가입자 서버(20)로 어떤 Sh 인터페이스도 없거나 인터페이스가 일시적으로 이용할 수 없는 경우에 유익하다.

하나의 대안에 따르면, 응용 서버(22)는 어드레스 자체를 수정하기보다는 데이터베이스, 파일, 리스트, 테이블 등으로부터 수정된 어드레스를 불러올 수 있다(fetching). 데이터베이스는 응용 서버(22)내에 위치되거나 응용 서버의 외부 데이터베이스에 위치될 수 있다.

파라미터가 S-CSCF(14)의 어드레스와 함께 HSS(20)에 저장되기에 어드레스 구축에 대한 가능성이 있다. 이후에, 응용 서버(22)는 수정 절차에 대한 입력으로서 HSS로부터의 어드레스 및 파라미터를 이용하여 정확한 어드레스를 구축할 수 있다.

도 3에 도시된 가능성에 따르면, 응용 서버(22)는 단계(1)에서 HSS로부터 복귀된 어드레스 정보에 기초하여 DNS(도메인 명칭 시스템) 조회를 한다. 복귀된 S-CSCF 명칭은 필요한 서비스(발신 또는 착신)가 이용가능한 어드레스 또는 포트를 찾기 위해 예를 들어, SRV 자원 기록을 요청하는데 사용될 수 있다. SRV는 서비스들(DNS SRV)의 위치를 특정하기 위한 DNS 자원 기록(RR)이다. SRV 자원 기록의 사용은 특정 서비스 및/또는 특정 도메인에 대한 프로토콜의 조회를 가능하게 한다. 이후에, 응답은 기준을 만족하는 모든 이용가능한 서버의 명칭을 포함할 것이다.

예를 들어, SRV 자원 기록으로부터의 하기의 DNS 조회는 발신 필터 기준이 평가될 때에 수행될 수 있다. SRV 자원 기록은 전형적으로 프로토콜과 서비스 모두를 특정한다. SRV 기록은 예를 들어 인수로서 하기의 어드레스를 사용하여 단계(2)에서 조회될 수 있다:

_orig._sip.scscf12.operator.net

단계(2)에서 응답은 포트 5060를 사용하여 특정 어드레스"orig.scscf12.operator.net"에 라우팅하게 하는 권고(advice)가 될 수 있다:

_orig._sip.scscf12.operator.net SRV 0 0 5060 orig.scscf12.operator.net.

대안적으로, 응답은 발신 어드레스 "scscf12.operator.net"를 갖는 특정 포트 55334로 라우팅할 수 있다:

_orig._sip.scscf12.operator.net SRV 0 0 55334 scscf12.operator.net.

하기의 인수는 착신 필터 기준이 평가될 때에 DNS 조회(SRV)에서 사용될 수 있다:

_term._sip.scscf12.operator.net

응답은 포트 5060를 사용하여 특정 어드레스"term.scscf12.operator.net"에 라우팅하게 하는 권고가 될 수 있다:

_term._sip.scscf12.operator.net SRV 0 0 5060 term.scscf12.operator.net.

또는 상술된 바와같이, 응답은 예를 들어, 발신 어드레스 "scscf12.operator.net"를 갖는 특정 포트 55335로 라우팅할 수 있다:

_term._sip.scscf12.operator.net SRV 0 0 55335 scscf12.operator.net.

이해해야 할 사항으로서, 상기 종류의 라우팅은 착신 서비스에 반드시 필수적이지 않는데, 즉 전형적으로 응용 서버가 요청를 발신하는 방법은 만일 어떠한 것도 지시되지 않는다면 처리되어야 하기 때문에 그러하다. 또한, 발신 서비스에 대한 어떠한 특수한 라우팅이 요청되지 않는 응용이 가능하다. 어드레스 수정의 경우와 마찬가지로, 상기 논의된 종류의 라우팅은 예를 들어, 대칭성 이유로 바람직할 수 있다.

이후에, 응용 서버는 단계(3)에서 DNS로 어드레스를 결정하며, 단계(4)에서 메시지를 지시된 어드레스 및/또는 포트로 라우팅한다.

다른 가능성에 따르면, 가입자 데이터베이스(예를 들어, HSS 20)는 단계(1)에서 S-CSCF 명칭을 복귀시킨다. 이후에, 응용 서버는 이용가능한 서비스(발신 및/또는 착신)를 찾기 위해 NAPTR(Naming Authority Pointer)를 요청하는 복귀된 S-CSCF 명칭으로 DNS 조회를 한다. 응답에 기초하여, 이후에 응용 서버는 요청 메시지를 바람직한 어드레스에 라우팅한다. 이 실시 예는 도메인 명칭 신택스(syntax)에 있지 않는 상당히 다양한 자원에 대한 검색 서비스를 위해 DNS의 사용을 허용한다. 가능한 자원 명칭은 서비스에 대한 URI를 포함한다.

하기 내용은 SRVf를 갖는 NAPTR 조회의 예시이다. DNS 조회는 S-CSCF 어드레스 예를 들어,

scscf12.operator.net

의 도메인 부분을 사용하여 NAPTR 자원 기록(RR)을 요청함으로써 수행될 수 있다.

이후에 결과는 하기와 같다:

IN NAPTR 100 10 "S" "sip+orig" ""_orig._sip.scscf12.operator.net.

IN NAPTR 100 10 "S" "sip+term" ""_term._sip.scscf12.operator.net.

순서 및 선호 필드(preference field)가 일치하기 때문에, 임의의 RR이 선택될 수 있다. 만일 세션/트랜잭션을 발신하기 위해 S-CSCF를 위한 어드레스가 필요한 경우에, 제 1 어드레스를 선택하는 것이 가능하다. 플래그 "S"는, 다음 DNS 조회는 SRV RR을 요청함으로써 수행됨을 의미한다. 이후에, DNS 조회는 도메인 명칭, 즉 상술된 어드레스

_orig._sip.scscf12.operator.net

에 의해 SRV RR을 요청함으로써 수행된다.

DNS 조회의 결과는 IP 어드레스이거나 임의의 다른 적합한 라우팅 정보일 수 있다.

또한, SRV 조회없이 NAPTR을 구현하는 것이 가능하다. 상술한 바와같이, DNS 조회는 S-CSCF 어드레스 예를 들어,

scscf12.operator.net

의 도메인 부분을 사용하여 NAPTR RR을 요청함으로써 수행될 수 있다.

결과는

IN NAPTR 100 10 "A" "sip+orig" ""_orig._sip.scscf12.operator.net.

IN NAPTR 100 10 "A" "sip+term" ""_term._sip.scscf12.operator.net.

순서와 선호 필드가 일치하기 때문에, 임의의 RR이 선택될 수 있다. 세션/트랜잭션을 발신하기 위한 S-CSCF 어드레스가 필요하기 때문에, 첫 번째가 선택된다. 플래그"A"는 다음 DNS 조회가 SRV A, AAAA 또는 A6 자원 기록을 요청함으로써 수행됨을 의미한다. 이후에, DNS 조회는 도메인 명칭 orig.scscf12.operator.net.로 A, AAAA 또는 A6를 요청함으로써 수행된다. 이후에, 조회는 IP 어드레스를 발생시킨다.

추가의 대안에 따르면, S-CSCF 어드레스(예를 들어, scscf12.operator.net)의 도메인 부분을 사용하여 NAPTR RR을 요청함으로써 수행되는 DNS 조회는 다음의 결과를 발생시킨다:

이 대안의 이점은, 모든 S-CSCF는 전형적으로 공통 NAPTR 자원 기록을 갖는다는 것이다. 순서와 선호 필드가 일치하기 때문에, 임의의 RR이 선택되며, 따라서 발신 세션/트랜잭션을 위해 첫 번째가 선택된다. 플래그"U"는 결과가 URI임을 의미한다. 이후에 결과는 다음과 같다.

sip:orig.scscf12.operator.net.

URI의 도메인 부분은 DNS 조회에 의해 IP 어드레스로 결정된다. DNS 조회는 도메인 명칭으로 A, AAAA 또는 A6 RR을 요청함으로써 수행되며, 결과는 IP 어드레스가 될 것이다.

응용 서버가 메시지를 보낼 정확한 포트를 선택하거나 수정할 가능성이 있다. 포트는 어드레스의 종단에 부가될 수 있다.

상기 예에서, 서비스 종류의 표시가 어드레스의 도메인 부분에 포함된다. 응용 서버가 어드레스의 사용자 부분을 선택하거나 수정할 가능성이 있다. 예를 들어, 응용 서버는 어드레스

scscf12.operator.net

를 수정할 수 있는데, 이는 태그, 문자, 문자열 또는 비트열을 사용자 부분으로서 부가하여, 이에 따라 발신 서비스를 위한 어드레스를 구축함으로써 된다(또는 그 역의 경우):

orig@scscf12.operator.net

상술한 실시 예에서, S-CSCF의 단 하나의 어드레스만이 HSS에 저장된다. 예시에서, 이후에 역할들은 수정된 사용자 부분, 수정된 호스트 또는 도메인 명칭, 수정된 포트 번호, 어드레스에 부가된 파라미터, 또는 임의의 이들의 조합으로 구성되는 수정된 어드레스에 의해 S-CSCF에 시그널링한다. 바람직한 형태에서, 동작은, 파라미터가 존재하거나 어드레스가 수정될 때에 S-CSCF가 발신 역할을 행하도록 된다. 만일 어떤 부가된 파라미터가 발견되지 않거나 어드레스가 수정되지 않은 경우에, S-CSCF는 착신 역할을 행한다.

하지만, HSS에 S-CSCF의 두 어드레스(즉, 발신을 위한 어드레스와 착신을 역할을 위한 어드레스)을 저장하는 것이 또한 가능하다. 따라서, 도 4에 도시된 다른 실시예에 따라, S-CSCF를 위한 하나 이상의 어드레스가 홈 가입자 서버(HSS)(20)에 저장된다.

특히, HSS(20)는 S-CSCF에 발신 필터 기준을 트리거하기 위한 주소 및 착신 필터 기준을 트리거하기 위한 다른 어드레스를 저장할 수 있다. 응용 서버(22)는 이후에 사용자 장비(10)를 대신해 행할 필요가 있을 때에 Sh 인터페이스를 통해 바람직한 어드레스를 페칭할 수 있다. 대안적으로, 응용 서버(22)는 어드레스 모두를 페칭할 수 있고, 필요한 것을 선택할 수 있다. 이는 구현 문제이다.

두 커브의 라우팅 화살(30 및 31)은 두 다른 서비스 종류를 위한 메시징(messaging)을 보여준다. 메시징 화살(30)은 착신 서비스 프로파일에 기초하여 실행되는 사용자의 착신 서비스에 대한 정보 흐름을 보여준다. 메시징 화살(31)은 발신 서비스 프로파일에 기초하여 실행되는 사용자의 발신 서비스에 대한 정보 흐름을 보여준다.

도 5는 상술된 실시예에 의해 서비스를 제공할 가능성을 도시한다. 단계(1, 2 및 4)에 대해, 도 2 및 3의 실시예의 상기 설명을 참조한다. 단계(5)에서, 서비스에 대한 요청가 사용자로부터 왔을 때에 서비스가 제공된다.

상술된 예시적 통신 환경에서, 발신 S-CSCF 어드레스를 HSS로부터 응용 서버로 풀(pull)하는데 기존 Sh 인터페이스의 확장이 요청된다. 이는 "S-CSCF 명칭" 정보 요소의 포함을 위해 Sh-풀 요청의 확장에 의해 제공될 수 있다. 유사하게는, 발신 S-CSCF 어드레스 정보를 S-CSCF(14)로부터 HSS(20)로 푸시(push)하는데 HSS(20)과 S-CSCF(14)간의 Cx 인터페이스의 확장이 요청된다.

저장 엔티티에 저장된 통신 제어 엔티티의 어드레스 또는 명칭은 사용자 부분을 포함하거나 포함하지 않을 수 있음을 이해해야 한다. 어드레스 또는 명칭은 포트를 포함하거나 포함하지 않을 수 있다.

구성은, 사용자 장비의 IP 멀티미디어 서비스에 등록 중에, S-CSCF가 Cx 인터페이스를 통해 요청를 발신하기 위해 그 어드레스를 HSS에 푸시하도록 된다. Cx:S-CSCF 등록 및/또는 등록해제 통지 요청는 발신 S-CSCF 및 착신 S-CSCF 어드레스 모두를 포함하도록 확장된다.

상기 예시에서, 사용자 장비는 적어도 하나의 서빙 호 세션 제어 기능으로 등록되도록 가정된다. 사용자를 위한 어떤 등록도 발견되지 않거나 S-CSCF의 어드레스가 HSS로부터 수신할 수 없는 경우에, 디폴트 어드레스 또는 최후 알려진 어드레스를 사용하는 것이 가능하다.

간략히 요약하면, 응용 서버가 외부 데이터베이스로부터 어드레스 정보를 페칭하는 것이 필수적이지 않다. 상술된 HSS외에, 어드레스 정보는 가입자 위치 기능(SLF) 또는 서비스 및 가입 저장소(SSR)와 같은 임의의 적합한 외부 데이터베이스로부터 얻어질 수 있다.

응용 서버 또는 임의의 다른 적합한 엔티티는 또한 초기에 사용자 장비로부터 수신된 요청로부터 S-CSCF 어드레스 정보를 수신할 수 있다. 수신 어드레스 정보는 응용 서버에 통합되어 저장 엔티티에 저장된다. 어드레스 정보가 이후 발신 요청에 필요한 경우에, 정보는 응용 서버의 통합된 저장 엔티티로부터 얻어진다.

비록 사용자는 간접적으로 발신 또는 착신 서비스 제공을 발생시킬 수 있지만은, 서비스 통신 제어 엔티티(예를 들어, S-CSCF)의 어드레스 또는 명칭의 처리에 대한 책임은 응용 서버에 있다. 따라서, 사용자는 직접적으로 서비스 통신 제어 엔티티에 어드레싱하지 않는다. 따라서, 응용 서버는 다양한 소스로부터 사용자 장비에 서비스제공할 수 있는 통신 제어 엔티티에 관한 정보를 수신한다. 가입자 데이터베이스(예를 들어, HSS) 또는 응용 서버의 내부 데이터베이스와 같은 저장 엔티티외에, 응용 서버는 또한 서비스 통신 제어 엔티티 또는 임의의 다른 네트워크 엔티티로부터 수신된 메시지로부터 서비스 통신 제어 엔티티의 명칭 또는 어드레스를 얻을 수 있다. 이와 같은 메시지는 예를 들어, 응용 서버에 의해 착신된 이전의 요청일 수 있다.

또한, 응용 서버가 HSS 또는 다른 데이터베이스로부터 서비스 통신 엔티티 어드레스 리스트를 얻는 것이 가능하다. AS는 이후 리스트로부터 정확한 것을 선택한다. 이는 예를 들어, 사용자가 전혀 등록될 수 없거나 HSS에 어떤 이용가능한 S-CSCF 어드레스가 없는 때에 유용한 선택이다. AS는 이후 디폴트 S-CSCF 리스트로부터 어드레스를 고른다. 이런 상황에서, HSS는 단지 성능(capability)만을 복귀시킬 수 있다. 이 정보에 기초하여, AS는 정확한 S-CSCF를 선택할 수 있다.

본 발명이 이동국에 관해 설명되었지만은, 본 발명의 실시예는 임의의 다른 종류의 사용자 장비에 응용가능함을 이해해야 한다.

본 발명의 실시예는 범용 이동 원격통신 시스템(UMTS), i-phone 또는 CDMA2000 및 지상 트렁크 무선(TETRA) 시스템과 같은 제 3 세대 이동통신 시스템의 환경에서 설명되었다. 더욱이, 제공된 예시는 모든 SIP 엔티티를 갖는 소위 모든 SIP 네트워크 환경에서 설명되었다. 본 발명은 또한 임의의 다른 적합한 통신 시스템, 무선 또는 고정 라인 시스템, 및 표준 및 프로토콜에 응용가능하다. 이들에 제한없이, 무선 데이터 통신 서비스를 가능하게 하는 다른 가능한 통신 시스템의 예시는 범용 패킷 무선 서비스(GPRS), GSM 에불루션의 개선된 데이터 율(EDGE) 이동 데이터 네트워크, 및 다양한 무선 근거리망(W-LAN) 응용을 포함한다. 고정 라인 시스템의 예시는 가정과 사무실과 같은 다른 위치의 사용자에게 인터넷 액세스를 제공하는 다양한 광대역 기술을 포함한다. 통신 네트워크에 사용되는 표준과 프로토콜에 관계없이, 본 발명은 네트워크 엔티티가 세션 또는 트랜잭션을 발신할 수 있게 된 모든 통신 네트워크에 응용가능하다.

본 발명의 실시 예는 응용 서버 엔티티와 서비스 호 세션 제어 기능 엔티티간의 인터페이스를 논의하였다. 하지만, 응용 서버는 단지 서버의 예시임을 이해해야 한다. 본 발명의 실시 예는 응용될 수 있는 다른 네트워크 엔티티에 응용가능하다. 따라서, 또한 응용 서버에 관해 논의된 것은 또한 게이트웨이, 임의의 다른 서버, 프록시, 클라이언트, 사용자 에이전트 또는 임의의 다른 네트워크 요소, 기능, 기능성 또는 세션 또는 트랜잭션을 발신하는 것에 대해 유효함을 이해해야 한다.

통신이란 용어는 호, 데이터(예를 들어, 웹 브라우징) 또는 멀티미디어 통신 등과 같은 임의의 세션 또는 트랜잭션을 의미함을 이해해야 한다.

또한, 상술된 역할 외에 여러 다른 역할들이 있으며, 이는 역할들을 교체하거나 이들에 부가될 수 있다. 유사 메커니즘이 다른 역할들을 처리하는데 사용된다. 만일 추가의 역할이 사용된다면, 추가의 역할은 예를 들어, 가입자 데이터베이스에 저장되거나 새로운 파라미터에 의해 지시된 자신의 어드레스로 배치된다.

상술된 실시 예는 서로를 보상하거나 서로에 대해 동시에 병렬로 사용되도록 조합될 수 있다. 통신 시스템은 다른 네트워크 엔티티에서 다른 구현을 이용할 수 있다. 예컨대, 통신 시스템의 엔티티는 도 2에 설명된 솔루션을 이용할 수 있으며, 동일한 통신 시스템의 다른 엔티티가 도 4의 실시 예를 이용할 수 있다.

또한 본원에서, 상기 내용이 본 발명의 실시 예를 예시하였지만은, 첨부된 청구범위에 한정된 바와 같이 본 발명의 범주를 벗어남이 없이 개시된 솔루션에 다양한 변화, 조합 및 변형이 가해질 수 있음을 알아야 한다.

Claims

통신 시스템과 연관된 제1 엔티티에서 통신 시스템의 사용자에게 서비스 가능한 통신 제어 엔티티에 관한 저장 엔티티로부터 정보를 수신하는 단계와; 그리고

상기 정보에 기초하여, 상기 제1 엔티티로부터 상기 통신 제어 엔티티로 발신 요청 신호를 보내는 단계를 포함하는 것을 특징으로 하는 통신 시스템에서의 서비스 제공 방법.
제1항에 있어서, 상기 발신 요청은

상기 요청과 연관된 통신들 처리에 관한 정보를 포함하는 것을 특징으로 하는 통신 시스템에서의 서비스 제공 방법.
제1항 또는 제2항에 있어서, 상기 발신 요청은

상기 발신 요청과 연관된 향후 통신들이 상기 요청이 사용자로부터 발원되었던과 같이 유사한 방식으로 처리될 것이라는 지시자를 포함하는 것을 특징으로 하는 통신 시스템에서의 서비스 제공 방법.
선행하는 모든 항에 있어서, 착신 서비스들 또는 발신 서비스들 중에 하나의 서비스들이 요청에 기초하여 제공되는 것을 특징으로 하는 통신 시스템에서의 서비스 제공 방법.
선행하는 모든 항에 있어서, 상기 제1 엔티티에서 상기 통신 제어 엔티티가

상기 요청과 연관된 향후 통신들을 어떻게 처리할 것인지를 결정하는 단계를 포함하는 것을 특징으로 하는 통신 시스템에서의 서비스 제공 방법.
선행하는 모든 항에 있어서, 상기 제1 엔티티가

사용자를 대신하여 상기 발신 요청을 생성하는 것을 특징으로 하는 통신 시스템에서의 서비스 제공 방법.
선행하는 모든 항에 있어서, 상기 착신 요청이

상기 통신 제어 엔티티의 주소에 관한 정보에 기초하여 생성되는 것을 특징으로 하는 통신 시스템에서의 서비스 제공 방법.
선행하는 모든 항에 있어서, 상기 제1 엔티티는

상기 발신 요청을 전송하기 전에 상기 통신 제어 엔티티의 주소에 관한 상기 정보를 수정하는 것을 특징으로 하는 통신 시스템에서의 서비스 제공 방법.
선행하는 모든 항에 있어서, 상기 제1 엔티티는

서비스 유형 지시자를 상기 발신 요청에 부가하는 것을 특징으로 하는 통신 시스템에서의 서비스 제공 방법.
제9항에 있어서, 상기 서비스 유형 지시자는

상기 통신 제어 엔티티의 주소 내에 포함되어 있는 것을 특징으로 하는 통신 시스템에서의 서비스 제공 방법.
제10항에 있어서, 상기 서비스 유형 지시자가

상기 주소의 사용자 부분에 포함되어 있는 것을 특징으로 하는 통신 시스템에서의 서비스 제공 방법.
제10항에 있어서, 상기 서비스 유형 지시자가

상기 주소의 도메인 부분에 포함되어 있는 것을 특징으로 하는 통신 시스템에서의 서비스 제공 방법.
선행하는 모든 항에 있어서, 상기 제1 엔티티가

상기 요청을 전송할 포트를 선택하는 것을 특징으로 하는 통신 시스템에서의 서비스 제공 방법.
선행하는 모든 항에 있어서, 상기 저장 엔티티로부터 수신한 상기 정보는

상기 통신 제어 엔티티의 범용 자원 식별자(URI)를 포함하는 것을 특징으로 하는 통신 시스템에서의 서비스 제공 방법.
선행하는 모든 항에 있어서, 상기 저장 엔티티로부터 수신한 상기 정보는

상기 통신 제어 엔티티의 이름을 포함하는 것을 특징으로 하는 통신 시스템에서의 서비스 제공 방법.
선행하는 모든 항에 있어서, 상기 저장 엔티티로부터 수신한 상기 정보는

서비스 유형 지시자 파라미터를 포함하는 것을 특징으로 하는 통신 시스템에서의 서비스 제공 방법.
선행하는 모든 항에 있어서, 상기 발신 요청을 전송하기 전에

상기 통신 제어 엔티티에 관한 정보에 기초하고 있는 조회를 상기 제1 엔티티로부터 데이터베이스로 전송하는 단계를 포함하는 것을 특징으로 하는 통신 시스템에서의 서비스 제공 방법.
제17항에 있어서, 상기 제1 엔티티는

상기 원하는 서비스에 관한 라우팅 정보를 획득하기 위하여 도메인 이름 시스템(DNS)의 SRV 기록들을 조회하는 것을 특징으로 하는 통신 시스템에서의 서비스 제공 방법.
제17항에 있어서, 상기 제1 엔티티는

이용가능한 서비스를 찾기 위하여 NAPTR의 자원 기록들을 조회하는 것을 특징으로 하는 통신 시스템에서의 서비스 제공 방법.
선행하는 모든 항에 있어서, 상기 사용자에게 서비스 가능한 통신 제어 엔티티에 관한 상기 정보를 위하여

상기 제1 엔티티로부터 조회를 전송하는 단계를 포함하는 것을 특징으로 하는 통신 시스템에서의 서비스 제공 방법.
선행하는 모든 항에 있어서, 상기 통신 제어 엔티티 정보에 대한 주소들로서, 적어도 두개의 다른 주소들에 관한 정보가

상기 저장 엔티티에 저장되는 것을 특징으로 하는 통신 시스템에서의 서비스 제공 방법.
제21항에 있어서, 상기 적어도 두개의 다른 주소들은

상기 요청을 전송하기 전에 상기 제1 엔티티에 의하여 상기 저장 엔티티로부터 불러오는 것을 특징으로 하는 통신 시스템에서의 서비스 제공 방법.
제21항에 있어서, 상기 적어도 두개의 다른 주소들 중에 한개는

상기 요청을 전송하기 전에 상기 제1 엔티티에 의하여 상기 저장 엔티티로부터 불러오는 것을 특징으로 하는 통신 시스템에서의 서비스 제공 방법.
선행하는 모든 항에 있어서, 상기 발신 요청은

상기 요청에 적용될 필터 기준을 지시하는 것을 특징으로 하는 통신 시스템에서의 서비스 제공 방법.
선행하는 모든 항에 있어서, 상기 제1 엔티티는

응용 서버를 포함하는 것을 특징으로 하는 통신 시스템에서의 서비스 제공 방법.
선행하는 모든 항에 있어서, 상기 통신 제어 엔티티는

서비스 호 세션 제어 기능을 포함하는 것을 특징으로 하는 통신 시스템에서의 서비스 제공 방법.
선행하는 모든 항에 있어서, 상기 저장 엔티티는

사용자 정보 저장 엔티티를 포함하는 것을 특징으로 하는 통신 시스템에서의 서비스 제공 방법.
제27항에 있어서, 상기 사용자 정보 저장 엔티티는

홈 가입자 서버와, 가입자 위치 기능과, 서비스 및 가입 저장소 중에 하나인 것을 특징으로 하는 통신 시스템에서의 서비스 제공 방법.
통신 시스템의 사용자를 위하여 서비스들을 제공하는 통신 시스템으로서,

통신 시스템의 사용자에게 서비스 가능한 통신 제어 엔티티와; 그리고

저장 엔티티로부터 사용자에 관한 정보를 수신하는 제1 인터페이스와, 상기 저장 엔티티로부터의 상기 정보에 기초하여 발신 요청 신호를 상기 통신 제어 엔티티로 보내는 제2 인터페이스를 제공 받는 제1 엔티티를 포함하는 것을 특징으로 하는 통신 시스템.
제29항에 있어서, 상기 발신 요청은

상기 요청과 연관된 통신들의 처리에 관한 정보를 포함하는 것을 특징으로 하는 통신 시스템.
제29항 또는 30항에 있어서, 상기 제1 엔티티와 상기 통신 사이의 인터페이스 상에서 신호로 보내진 상기 발신 요청은 서비스 유형 지시자를 포함하는 것을 특징으로 하는 통신 시스템.
제31항에 있어서, 상기 서비스 유형 지시자는

상기 통신 제어 엔티티의 주소 내에 포함되어 있는 것을 특징으로 하는 통신 시스템.
제29항 내지 32항 중 모든 한 항에 있어서, 서비스 관련 정보를 저장하는 데이터베이스를 포함하는 것을 특징으로 하는 통신 시스템.
제33항에 있어서, 상기 데이터베이스는

도메인 이름 시스템(DNS)를 포함하는 것을 특징으로 하는 통신 시스템.
제29항 내지 34항 중 모든 한 항에 있어서, 상기 저장 엔티티는

상기 통신 제어 엔티티에 대한 주소로서, 적어도 두개의 다른 주소들에 관한 정보를 저장하는 것을 특징으로 하는 통신 시스템.
제29항 내지 35항 중 모든 한 항에 있어서, 상기 발신 요청은

상기 요청에 적용될 필터 기준을 지시하는 것을 특징으로 하는 통신 시스템.
통신 시스템을 위한 응용 서버로서,

저장 엔티티로부터 상기 통신 시스템의 사용자에 관한 정보를 수신하는 제1 인터페이스와, 상기 저장 엔티티로부터의 상기 정보에 기초하여 발신 요청 신호를 상기 통신 제어 엔티티로 보내는 제2 인터페이스를 제공 받는 제1 엔티티를 포함하는 것을 특징으로 하는 통신 시스템의 응용 서버.
통신 시스템의 제1 엔티티와 통신 시스템의 사용자에게 서비스 가능한 통신 제어 엔티티 사이에 인터페이스 상에 신호로 보내지는 발신 요청으로서,

상기 발신 요청이 사용자 정보 저장 엔티티로부터의 정보에 기초하여 생성되는 것을 특징으로 하는 발신 요청.