KR101626617B1

KR101626617B1 - Ｉｍｓ 망에서 ｉｐ-ｃａｎ 세션 변경 장치 및 방법

Info

Publication number: KR101626617B1
Application number: KR1020090092447A
Authority: KR
Inventors: 오종선
Original assignee: 삼성전자주식회사
Priority date: 2009-09-29
Filing date: 2009-09-29
Publication date: 2016-06-01
Anticipated expiration: 2029-09-29
Also published as: WO2011040740A3; US20120271958A1; KR20110034943A; US9497791B2; WO2011040740A2

Abstract

본 발명은 IMS(IP Multimedia Subsystem) 망에서 IP-CAN(Internet Protocol Connectivity Accss Network) 세션 변경 장치 및 방법에 관한 것으로, IMS 망의 PCEF(Policy and Charging Enforcement Function)에서 IP-CAN(Internet Protocol Connectivity Accss Network) 세션 변경 방법에 있어서, 상기 IP-CAN 세션이 싱글 베어러를 지원하는지 멀티플 베어러를 지원하는지를 나타내는 베어러 정보를 PCRF(Policy and Charging Rules Function)로 송신하는 과정과, 상기 PCRF로부터 상기 베어러 정보에 따라 생성된 PCC(Policy & Charging Control) 룰(rule)을 수신하는 과정과, 상기 수신된 PCC 룰을 적용하여 IP-CAN 세션을 변경하는 과정을 포함한다.

IP-CAN, PCC 룰, 싱글 베어러, 멀티플 베어러, single bearer, multiple bearrer

Description

ＩＭＳ 망에서 ＩＰ-ＣＡＮ 세션 변경 장치 및 방법{APPARATUS AND METHOD FOR MODIFYING INTERNET PROTOCOL CONNECTIVITY ACCESS NETWORK SESSION IN THE INTERNET PROTOCOL MULTIMEDIA SUBSYSTEM NETWORK}

본 발명은 IMS 망에서 PCEF(Policy and Charging Enforcement Function) 및 PCRF(Policy and Charging Rules Function) 간의 동작에 관한 것으로, 특히, IP-CAN 세션을 변경하기 위한 장치 및 방법에 관한 것입니다.

이동 통신과 인터넷 기술의 급격한 발전과 가입자의 다양한 요구에 부응하여 최근의 이동 통신 서비스는 기존의 음성 통화 서비스는 물론 이동 단말로 이메일이나 정지 영상 및 대용량의 디지털 데이터 전송이 가능한 고속 패킷 데이터 서비스를 제공하는 단계에 이르고 있다. 이에 따라 이동 통신 시스템은 음성 기반의 CS(Circuit Switched) 도메인에서 패킷 기반의 PS(Packet Switched) 도메인으로 진화되고 있다.

상기 인터넷을 통해 멀티미디어 서비스를 제공하는 핵심망(Core Network: 이 하, CN)은 기존 회선 기반의 CN에서 패킷 기반의 CN으로 변화되고 있으며, 더 나아가 IP 기반의 CN으로 진화되고 있다. 상기 IP 기반의 CN을 통해 가입자에게 IP 멀티미디어 서비스를 제공하는 통신 시스템을 IMS(IP Multimedia Subsystem)라 부르며, 3GPP(3rd Generation Partnership Project)/3GPP2에서는 상기 IMS를 통해 ALL IP 서비스를 원활히 제공하기 위한 다양한 연구가 진행되고 있다.

이러한 IMS 망에서 베어러 바인딩을 수행하거나 IP-CAN 세션을 변경함에 있어서, PCRF(Policy and Charging Enforcement Function)에서는 IP-CAN 세션 내의 베어러 수 속성에 따라 PCC 룰(rule)을 생성하는 각각의 동작 플로우가 상이하게 진행된다. 그러나 PCRF는 베어러에 관한 정확한 정보를 PCEF(Policy and Charging Enforcement Function)로부터 수신하는 구체적인 방법이 제안되지 않은 상태이다. 따라서 PCRF는 지원 가능한 베어러에 관한 정보를 판단하기 위한 근거가 없으므로 부족하므로, 다음 플로우를 진행하는데 어려움이 있다.

따라서 본 발명은 IP-CAN 세션 내의 베어러 수 속성에 따라 PCC 룰을 설정하는 각각의 동작 플로우를 명확히 제공할 수 있도록 한다.

또한 본 발명은 IP-CAN 내의 베어러가 싱글 베어러만을 지원할 경우, PCEF가 베어러 바인딩 절차를 진행할 수 있도록 한다.

또한 본 발명은 IP-CAN 내의 베어러가 멀티플 베어러를 지원할 경우, PCEF가 베어러를 생성하거나, 세션을 종료하여 서비스를 재시도 할 수 있도록 한다.

본 발명에 따른 IMS 망의 PCEF(Policy and Charging Enforcement Function)에서 IP-CAN(Internet Protocol Connectivity Accss Network) 세션 변경 방법에 있어서, 상기 IP-CAN 세션이 싱글 베어러를 지원하는지 멀티플 베어러를 지원하는지를 나타내는 베어러 정보를 PCRF(Policy and Charging Rules Function)로 송신하는 과정과, 상기 PCRF로부터 상기 베어러 정보에 따라 생성된 PCC(Policy & Charging Control) 룰(rule)을 수신하는 과정과, 상기 수신된 PCC 룰을 적용하여 IP-CAN 세션을 변경하는 과정을 포함한다.

본 발명에 따른 IMS 망의 PCRF(Policy and Charging Rules Function)에서 IP-CAN(Internet Protocol Connectivity Accss Network) 세션 변경 방법에 있어서, PCEF(Policy and Charging Enforcement Function)로부터 상기 IP-CAN 세션이 싱글 베어러를 지원하는지 멀티플 베어러를 지원하는지를 나타내는 베어러 정보를 수신하는 과정과, 상기 수신된 베어러 정보에 따라 PCC(Policy & Charging Control) 룰(rule)을 생성하는 과정과, 상기 생성된 PCC 룰을 상기 PCEF로 송신하는 과정을 포함한다.

본 발명에 따른 IMS 망의 PCEF(Policy and Charging Enforcement Function)의 IP-CAN(Internet Protocol Connectivity Accss Network) 세션 변경 장치에 있어서, IP-CAN 세션 변경 요청을 수신하면, 상기 IP-CAN 세션이 싱글 베어러를 지원하는지 멀티플 베어러를 지원하는지를 나타내는 베어러 정보를 PCRF(Policy and Charging Rules Function)로 송신하는 송신부와, 상기 PCRF로부터 상기 베어러 정보에 따라 생성된 PCC(Policy & Charging Control) 룰(rule)을 수신하는 수신부와, 상기 베어러 정보를 상기 PCRF로 송신하도록 제어하고, 상기 PCRF로부터 수신된 PCC 룰에 따라 IP-CAN 세션을 변경하도록 제어하는 제어부를 포함한다.

본 발명에 따른 IMS 망의 PCRF(Policy and Charging Rules Function)에서 IP-CAN(Internet Protocol Connectivity Accss Network) 세션 변경 장치에 있어서, PCEF(Policy and Charging Enforcement Function)로부터 상기 IP-CAN 세션이 싱글 베어러를 지원하는지 멀티플 베어러를 지원하는지를 나타내는 베어러 정보를 수신하는 수신부와, 상기 수신된 베어러 정보에 따라 PCC(Policy & Charging Control) 룰(rule)을 생성하도록 제어하는 제어부와, 상기 생성된 PCC 룰을 상기 PCEF로 송신하는 송신부를 포함한다.

본 발명에 의하면 IP-CAN 세션 내의 베어러 수 속성에 따라 PCC 룰을 설정하는 각각의 동작 플로우를 명확히 제공하여, IP-CAN 내의 베어러가 싱글 베어러만을 지원할 경우, PCEF가 베어러 바인딩 절차를 진행할 수 있고, IP-CAN 내의 베어러가 멀티플 베어러를 지원할 경우, PCEF가 베어러를 생성하거나, 세션을 종료하여 서비스를 재시도 할 수 있다. 즉, PCC 구조의 운용자가 서비스를 진행할 때, PCEF에게 PCC 룰이 전달되지 않아 가입자의 서비스가 진행되지 않는 시간을 감소시킬 수 있다.

이하, 본 발명에 따른 바람직한 실시 예를 첨부한 도면을 참조하여 상세히 설명한다. 또한, 하기 설명에서는 구체적인 특정 사항들이 나타나고 있는데, 이는 본 발명의 보다 전반적인 이해를 돕기 위해서 제공된 것일 뿐 이러한 특정 사항들 없이도 본 발명이 실시될 수 있음은 이 기술 분야에서 통상의 지식을 가진 자에게는 자명하다 할 것이다.

도 1은 본 발명의 기반이 되는 PCC 구조를 나타낸 도면이다. 도 1을 설명함에 있어서, 본 발명에 필요한 일부 구성요소에 대해서만 설명하고, 나머지 구성 요소에 대한 설명은 생략한다.

본 발명의 기반이 되는 IMS는 Release 6 까지는 QoS 및 정책 적용을 위해, PDF, PEP(Policy Enforcement Point)라는 기능 모듈 사이에 COPS 프로토콜을 사용 하는 Go 인터페이스를 정의하였다. 그러나 Release 7 및 Release 8에서는 Gx 인터페이스를 정의하였고, 다이어미터(Diameter)를 기반으로 한다. 아울러 PEP 및 PDF라는 용어도 과금 기능과 통합되어PCEF(Policy and Charging Enforcement Function)(103) 및 PCRF(Policy and Charging Rules Function)(101)로 변경되었다.

상기 PCRF(103)는 IMS 서비스 플로우 별로 차별화된 QoS 및 과금 정책을 다양하게 적용하기 위한 정책 결정 기능으로써, 3GPP Rel. 7 PCC(Policy & Charging Control) 구조에서 정의된 정책 제어 기능이 있다. PCRF 시스템은 3GPP release 6에서 정의한 정책 결정 기능과 과금 제어 기반 플로우 기능을 모두 수용할 수 있으며, IMS 제공 시 서비스 별로 차별화된 QoS를 보장하고, 차별화된 과금 요율을 적용할 수 있도록 한다. PCRF 시스템이 자체적으로 QoS를 적용하거나 과금 데이터를 생성하는 것이 아니라, IP 엣지가 QoS 적용 및 과금 데이터 생성을 서비스 별로 차별화 할 수 있도록 하는 PCC 룰을 생성한다. 즉, IP-CAN(IP-Connectivity Access Network)을 지원하는 IP 엣지 노드가 IMS 서비스 데이터 플로우 별로 차별화된 QoS 및 과금 정책을 IMS 서비스 데이터 플로우가 전송되는 하나 또는 그 이상의 IP-CAN 내의 베어러에 적용하는데 필요한 PCC 룰을 생성한다.

상기 PCEF(101)는 정책 실행, 과금 기능성 기반 플로우를 포함하며, IP 엣지 노드(예를 들어, GPRS인 경우 GGSN, CDMA인 경우 PDSN, ACR인 경우 ACR에 해당) 내에 위치한다. PCEF는 서비스 데이터 플로우 검출, 유저 플랜 트래픽 핸들링(user plane traffic handling), IP-CAN을 허용하는 트리거링 컨트롤 플랜 세션 매니지먼트(triggering control plane session management) (where the IP-CAN permits), QoS 핸들링, 그리고 서비스 데이터 플로우 추정 기능을 제공한다. 또한 PCEF는 온라인(online)과 오프라인(offline) 과금 서버와 연동하여 과금 정보를 제공한다.

여기에서, PCC 룰은 통신 서비스 품질(QoS)을 위한 정책과 과금을 서로 연관되게 처리하기 위한 것으로, 가입자에 대해 허가된 서비스의 종류, 허가된 서비스 품질 정보, 과금 정보, 가입자 카테고리를 포함하는 정보와, AF(Application Function)(109)로부터 제공받은 이동 단말기의 IP 주소, 미디어 타입과 대역폭, AF(109)의 어플리케이션 정보 및 기록 정보 등을 포함하는 정보 및 GGSN으로부터 요청 받은 이동 단말기의 IP 주소, 가입자 인증 정보 등을 포함하는 정보를 이용하여 생성할 수 있다.

도 2는 본 발명의 기반이 되는 GPRS의 기본 구조를 나타낸 도면이다.

상기와 같은 IMS 망에 접속하기 위해서 UE는 IP-CAN을 거쳐야 한다. IP-CAN은 단말에게 패킷 데이터 전송을 위한 억세스 망을 말한다. 그러나 예시한 IP-CAN 외에도 GPRS나 WCDMA와 같은 네트워크가 될 수 있다. 이하에서는 SGSN과 GGSN은 GPRS를 일 예로 설명한다.

일반적으로 UE(201) 또는 GGSN(205) 내에 위치한 PCEF가 IP-CAN 내에 베어러(211a 내지 211n)를 생성하여 베어러의 SDF(Service Data Flow)에 적용할 PCC 룰을 PCRF(207)로부터 수신하여 적용한다. 이때, IP-CAN 내의 베어러(211a 내지 211n) 수는 IP-CAN, PCEF 또는 UE의 종류에 따라서 싱글 또는 멀티플을 지원할 수 있게 된다. 즉, IP-CAN의 베어러 수 속성에 의해 PCRF가 PCC 룰을 설정할 때의 동작이 각각 상이하다.

도 3은 일반적인 PCRF-initiated IP-CAN 세션 변경 절차를 나타낸 도면이다.

301단계에서 PCRF(340)가 IP-CAN 세션 변경이 요구되었는지를 감지하면, 303단계에서 서비스 품질 결정(QoS decision) 및 과금 결정(Charging rules) 정보를 포함하는 PCC 룰 정보를 생성한다. 상기 PCC 룰을 생성한 후, 305단계에서 PCEF(320)의 PCC 룰 요청을 기다리는 동안 타이머를 설정한다. 이후, 307단계에서 IP-CAN 세션 내의 베어러가 싱글 베어러(single bearer)를 지원하는 것인지 멀티플 베어러(multiple bearer)를 지원하는 지에 따라 RAR(Re-Auth-Request) 커멘드(command)를 통해 PCC 룰을 적용/변경/제거할 것을 PCEF(320)로 요청한다. 상기 RAR 커멘드를 수신한 PCEF(320)가 309단계에서 UE(300)로 IP-CAN 세션 생성/변경/종료를 요청한다.

이후, 311단계에서 UE(300)는 PCEF(320)로 상기 IP-CAN 세션 생성/변경/종료에 대한 응답을 전송하고, 상기 응답을 수신한 PCEF(320)는 313단계에서 PCC 룰 적용/변경/제거 응답을 RAA(Re-Auth-Answer) 커멘드를 통해 PCRF(340)로 전송한다. 또한 PCEF(320)는 315단계에서 CCR(Credit-Control-Request) 커멘드를 통해 베어러 레벨 이벤트를 PCRF(340)으로 통지하고, PCRF(340)는 상기 315단계에서 전송된 베어러 레벨 이벤트를 수신하여 317단계에서 RAR 커멘드를 통해 AF(380)로 전송한다. 이후, AF(380)는 상기 수신된 RAR 커멘드를 통한 통지에 대한 응답으로 319단계에서 PCRF(360)으로 RAA 커멘드를 전송하고, 321단계에서 PCRF(360)는 CAA 커멘드를 통해 PCEF(320)로 통지 응답을 전송한다.

그러나 상술한 도 3에 대한 설명에서와 마찬가지로, 3GPP TS. 29.213의 기재 중 일부에 해당하는 하기 <표 1> 및 <표 2>를 살펴보면, 현재 3GPP TS. 29.213에는 IP-CAN 세션 내의 베어러 수 속성에 따라 PCC 룰을 설정하는 각각의 동작 플로우를 명확히 기재하고 있지 않다.

먼저, 첫째로, PCC 룰이 신규로 생성되어 IP-CAN 세션 내의 특정 베어러에 바인딩 할 때, 싱글 베어러만을 지원하는 IP-CAN에 대해서는 PCRF가 베어러 정보를 이미 알고 있으므로 PCEF가 특별한 정보를 알려 주지 않아도 PCC 룰과 베어러를 바인딩 할 수 있다. 그러나, 하기 <표 1>에서 베어러 바인딩 메카니즘에 명시된 PCEF가 싱글 베어러를 지원하는 경우에 대한 규격 언급 사항에 따르면, 상기한 PCRF는 IP-CAN 세션 내의 베어러가 싱글 베어러만을 지원하는 것인지, 멀티플 베어러를 지원하는 것인지 알 수 없다.

<표 1>

NOTE : For an IP-CAN, limited to a single IP-CAN bearer per IP-CAN session, the bearer is implicit, so finding the IP-CAN session is sufficient for successful bearer binding.

둘째로 또 다른 규격의 설명에서는 PCC 룰이 생성되고 나서 PCEF의 PCC 룰 요청을 기다리는 동작 타이머를 설정한다. 그러나, 하기 <표 2>에서 IP-CAN 세션 변경 시그널링 플로우에 명시된 문구에 따르면, PCC 룰을 생성한 이후 타이머가 종료된 후의 플로우는 정확하게 명시하지 않고 있다.

<표 2>

If the timer expires and the PCRF still requires additional filter information coming from the UE in order on bearer binding for new PCC rules to be installed. all subsequent steps in the present figure shall not be executed , and further reactions of the PCRF are left unspecified . As a possible option, the PCRF could abort the AF session.

따라서 PCRF는 지원 가능한 베어러에 대한 판단 근거가 부족하여 다음 플로 우로 진행하지 못한다. 따라서 본 발명에서는 PCC 구조를 기반으로 PCRF와 PCEF 간의 동작 중에 상기와 같이 베어러 바인딩(Bearer Binding) 및 IP-CAN 세션 변경 절차에서 규격 상 모호한 부분을 위해 제안된 것이다.

보다 구체적으로 설명하면, 본 발명은 RFC 4006 규격에 신규 AVP(Attribute-Value-Pair)를 생성하여 Gx-Interface(3GPP TS. 29.212)의 CCR Command에 신규 AVP를 사용할 수 있도록 하기 위해 제안된 것이다. 즉, IP-CAN 내의 베어러가 싱글 베어러(single bearer)를 지원하는 것인지 멀티플 베어러(multiple bearer)를 지원하는 것인지를 나타내는 신규 AVP를 추가하여, PCEF로부터의 PCC 룰 요청을 기다리는 동안 타이머가 종료됐을 경우의 동작을 결정하도록 하기 위해 제안된 것이다. 이를 위해 본 발명에서는 PCEF가 IP-CAN 속성을 PCRF에 전송하여 베어러 바인딩을 규격에서 제시하는 바와 같이 진행되도록 한다.

도 4는 본 발명에 따른 PCEF 및 PDEF의 구조를 나타낸 도면이다.

먼저 PCEF(400)는 송수신부(401), 커멘드 생성부(403), 저장부(405) 및 제어부(407)를 포함하여 구성될 수 있다. 상기 송수신부(401)는 UE로부터 IP-CAN 세션 생성 요청을 수신하고, PCRF로 IP-CAN 세션 생성을 지시하기 위해 베어러에 관한 정보를 포함하는 CCR 커멘드를 송신하며, PCRF(420)로부터 IP-CAN 세션 생성 ACK 즉, CCA 커멘드를 수신한다. 상기 커멘드 생성부(403)는 상기 베어러에 관한 정보를 포함하는 CCR 커멘드, PCC 룰 적용/변경/제거를 요청하기 위한 RAR 커멘드와, 상기 CCR 커멘드 및 상기 RAR 커멘드에 대한 각각의 응답 커멘드인 CCA 커멘드 및 RAA 커멘드를 생성한다. 상기 저장부(405)는 상기 CCR 커멘드에 포함되어 상기 PCRF(420)로 전송된 베어러에 관한 정보를 저장한다. 상기 제어부(407)는 UE로부터 IP-CAN 세션 생성 요청을 수신하고, IP-CAN 세션 생성을 지시하기 위해 상기 PCRF(420)으로 베어러에 관한 정보를 포함하는 CCR 커멘드를 생성하여 전송하며, 상기 CCR 커멘드에 포함된 베어러에 관한 정보를 저장한 후, PCRF(420)로부터 상기 CCA 커멘드를 수신하고, 상기 수신된 CCA 커멘드에 포함된 PCC 룰을 적용하도록 한다.

한편, PCRF(420)는 송수신부(421), PCC 룰 생성부(423), 타이머(425) 및 제어부(427)를 포함하여 구성될 수 있다. 상기 송수신부(421)는 상기 PCEF(400)로부터 상기 CCR 커멘트를 수신하고, PCC 룰을 포함하는 CCA 커멘드를 송신한다. 상기 PCC 룰 생성부(423)은 상기 수신된 CCR 커멘드의 베어러에 관한 정보에 따라 PCC 룰을 생성한다. 상기 타이머(425)는 상기 PCEF(400)로부터 PCC 룰 요청을 기다리는 동안 설정된다. 상기 제어부(427)는 IP-CAN 세션 최초 설정 시, 상기 PCEF(400)로부터 상기 CCR 커멘트를 수신하고, 상기 수신된 CCR 커멘드의 베어러에 관한 정보에 따라 PCC 룰을 생성하여 CCA 커멘드를 통해 상기 PCEF(400)로 전송한다. 또한 상기 제어부(427)는 IP-CAN 세션 변경이 요구가 감지될 시, PCC 룰을 생성하고, 타이머를 설정한 후, 타이머가 종료되었을 경우 IP-CAN 세션을 변경하는 과정에서 저장된 베어러에 관한 정보에 따라 PCC 룰에 베어러 ID를 포함할지 여부를 판단하여, 베어러 바인딩 절차를 수행하거나 베어러 생성 절차를 수행하도록 한다. 상기 베어러 생성 절차를 수행하지 않고, 세션을 종료하도록 제어할 수도 있다.

도 5는 본 발명에 따라 IP-CAN 세션을 최초 생성하는 과정을 나타낸 도면이 다.

501단계에서 UE(500)는 PCEF(520)로 IP-CAN 세션 생성을 요청하고, 상기 요청을 수신한 PCEF(520)는 503단계에서 IP-CAN 세션의 생성을 지시하는 CCR 커멘드를 PCRF(540)로 전송한다. 이때, CCR 커멘드에는 하기 <표 3>에서와 같이 신규 AVP가 추가된 것이다.

<표 3>

Single-Bearer-Support AVP (All Access Types)

The Single-Bearer-Support AVP (AVP code XXX) is of type Enumerated. The value of the AVP indicates whether the GGSN supports multiple bearers in an IP-CAN session. If the GGSN supports a Single-Bearer, the PCRF shall execute bearer-binding while provision a PCC rule in a RAR or CCA command.

If no Single-Bearer-Support AVP has been supplied for an IP CAN session, the default value SINGLE_BEARER_NOT_SUPPORTED is applicable.

The following values are defined:
SINGLE_BEARER_NOT_SUPPORTED (0)
This value indicates that the IP-CAN session supports multiple bearers. This is the default value applicable if no Single-Bearer-Support AVP has been supplied for an IP CAN session.
SINGLE_BEARER_SUPPORTED (1)
This value indicates that the IP-CAN session supports a single bearer.

상기 <표 3>은 CCR command에 추가된 AVP는 하기 <표 4>와 같다.

<표 4>

CC-Request(CCR) Command

Message Format:
<CC-Request> ::= < Diameter Header: 272, REQ, PXY >
< Session-Id >
{ Auth-Application-Id }
{ Origin-Host }
{ Origin-Realm }
{ Destination-Realm }
{ CC-Request-Type }
{ CC-Request-Number }
[ Destination-Host ]
[ Origin-State-Id ]
*[ Subscription-Id ]
*[ Supported-Features ]
[ Single-Bearer-Support ] --> 신규 추가 AVP
[ Network-Request-Support ]
*[ Packet-Filter-Information ]
[ Packet-Filter-Operation ]
[ Bearer-Identifier ]
[ Bearer-Operation ]
[ Framed-IP-Address ]
[ Framed-IPv6-Prefix ]
[ IP-CAN-Type ]
[ RAT-Type ]
[ Termination-Cause ]
[ User-Equipment-Info ]
[ QoS-Information ]
[ QoS-Negotiation ]
[ QoS-Upgrade ]
[ Default-EPS-Bearer-QoS ]
0*2[ AN-GW-Address ]
[ 3GPP-SGSN-MCC-MNC ]
[ 3GPP-SGSN-Address ]
[ 3GPP-SGSN-IPv6-Address ]
[ RAI ]
[ 3GPP-User-Location-Info]
[ 3GPP-MS-TimeZone ]
[ Called-Station-ID ]
[ Bearer-Usage ]
[ Online ]
[ Offline ]
*[ TFT-Packet-Filter-Information ]
*[ Charging-Rule-Report]
*[ Event-Trigger]
[ Event-Report-Indication]
[ Access-Network-Charging-Address ]
*[ Access-Network-Charging-Identifier-Gx ]
*[ CoA-Information ]
*[ Proxy-Info ]
*[ Route-Record ]
*[ AVP ]

상기 503단계 이후, PCEF(520)는 505단계에서 베어러 정보를 저장하고, PCRF(540)는 507단계에서 상기 수신된 CCR 커멘드에 포함된 정보를 저장한다. 509단계에서 PCRF(540)가 SPR(560)로 프로파일을 요구하고, 그에 대한 응답으로 511단계에서 SPR(560)이 PCRF(540)로 프로파일 응답을 전송한다. 이후, PCRF(540)는 상기 503단계에서 수신된 CCR 커멘드에 포함된 서비스 정보와 상기 511단계에서 수신된 프로파일 응답을 이용하여 서비스 품질 정보와 과금 결정 정보를 포함하는 PCC 룰을 생성한다. 상기 생성된 PCC 룰은 IP-CAN 내에 베어러를 생성하여 베어러의 SDF(Service Data Flow)에 적용하기 위한 것으로, 515단계에서 상기 503단계에서 전송된 CCR 커멘드의 응답 메시지인 CCA(Credit-Control-Answer) 커멘드에 포함되어 상기 PCEF(520)으로 전송된다. 517단계에서 PCEF(520)는 상기 수신된 CCA 커멘드에 포함된 PCC 룰을 적용, 즉 PCC 룰을 적용하여 IP-CAN을 생성하고, 519단계에서 UE(500)로 상기 IP-CAN 생성 응답을 전송한다.

상기한 IP-CAN 내의 베어러 수는 IP-CAN, PCEF 또는 UE의 종류에 따라서 싱글 또는 멀티플 지원이 가능하다. IP-CAN의 베어러 수 속성에 의해 PCRF가 PCC 룰을 적용할 때 동작이 상이하다. 이하에서 도 6 및 도 7을 참조하여, 상기와 같은 과정을 통해 IP-CAN을 최초로 생성한 이후에 IP-CAN 내의 베어러가 싱글 또는 멀티플 지원이 가능한지에 따라 상이하게 발생하는 IP-CAN 세션 변경 절차에 대해 구체적으로 설명한다.

도 6은 본 발명에 따라 IP-CAN 세션을 변경하기 위한 PCEF에서의 동작 과정을 나타낸 도면이다.

601단계에서 PCEF가 UE로부터 IP-CAN 세션 생성 요청을 수신하면, 603단계에서 상기 IP-CAN 세션 내의 베어러가 싱글 베어러를 지원하는지 여부를 판단한다. 상기 판단 결과, 만약 상기 IP-CAN 세션 내의 베어러가 싱글 베어러를 지원한다면, 605단계로 진행하여 신규 AVP, 즉 베어러에 관한 정보를 포함하는 CCR 커멘드를 생성한다. 이후, 609단계에서 상기 생성된 CCR 커멘드를 PCRF로 전송하고, 상기 베어러에 관한 정보를 저장한다.

한편, 상기 판단 결과, 만약 상기 IP-CAN 세션 내의 베어러가 멀티플 베어러를 지원한다면, 베어러에 관한 정보를 포함하지 않는 CCR 커멘드를 생성하고, 상기 609단계로 진행한다.

상기 609단계 이후, 611단계에서 CCA 커멘드가 수신되었는지를 계속해서 확인하고, CCA 커멘드가 수신되었다면 613단계에서 상기 수신된 CCA 커멘드에 포함되어 있는 PCC 룰을 적용한다.

도 7는 본 발명에 따라 IP-CAN 세션을 변경하기 위한 PCRF에서의 동작 과정을 나타낸 도면이다.

먼저 701단계에서 PCRF가 IP-CAN 세션 변경이 요구됨을 감지하였다면, 703단계에서 PCC 룰을 생성하고, 705단계에서 타이머를 설정한다. 이후, PCRF는 707단계에서 PCC 룰이 요청되었는지를 확인한다. 상기 확인 결과, PCC 룰이 요청되었다면, 717단계로 진행하여 PCRF는 상기 703단계에서 생성된 PCC 룰에 베어러 ID가 포함되도록 CCA 커멘드를 생성하고, 상기 생성된 CCA 커멘드를 PCEF로 전송한다.

한편, 상기 확인 결과, PCC 룰이 요청되지 않았다면, PCRF는 709단계에서 타 이머의 종료 여부를 판단한다. 상기 판단 결과, 타이머가 종료되지 않은 경우에는 808단계로 진행하고, 타이머가 종료된 경우에는 711단계로 진행하여 PCRF는 PCEF가 IP-CAN 세션 생성 시, 즉 상술한 도 5의 503단계에서 CRR 커멘드를 통해 IP-CAN 내의 베어러가 싱글 베어러를 지원하는 것이라 통보했는지 멀티플 베어러를 지원하는 것이라 통보했는지 여부를 판단한다.

만약 PCEF가 IP-CAN 내의 베어러가 싱글 베어러를 지원하는 것이라 통보했다면, PCRF가 IP-CAN 세션 내에 싱글 베어러만이 존재한다고 인식하고 있는 것이므로, PCEF가 베어러 정보를 알려주어야 PCC 룰과 베어러를 바인딩할 수 있다. 따라서 713단계로 진행하여 PCRF는 상기 703단계에서 생성된 PCC 룰에 베어러 ID가 포함되도록 RAR 커멘드를 생성하고, 상기 생성된 RAR 커멘드를 PCEF로 전송하여 적용하도록 함으로써 베어러 바인딩을 수행한다.

한편, PCEF가 IP-CAN 내의 베어러가 멀티플 베어러를 지원하는 것이라 통보했다면, PCRF가 IP-CAN 세션 내에 멀티플 베어러가 존재한다고 인식하고 있는 것이므로, PCEF가 정상 동작하지 않는 플로우가 된다. 따라서 PCRF는 715단계로 진행하여 상기 생성된 PCC 룰에 베어러 ID가 포함되지 않도록 RAR 커멘드를 생성하고, 상기 생성된 RAR 커멘드를 PCEF로 전송하여 PCEF가 베어러를 생성하도록 한다. 또한, 도 7에 도시하지는 않았지만 715단계에서 PCRF가 PCEF에게 세션을 종료하도록 할 수도 있다.

상기에서 본 발명을 설명함에 있어서, PCEF는 IP-CAN 세션이 싱글 베어러를 지원하는 경우에 베어러에 관한 정보를 포함하는 CCR 커멘드를 송신하고, IP-CAN 세션이 멀티플 베어러를 지원하는 경우에 베어러에 관한 정보를 포함하지 않는 CCR 커멘드를 송신하는 것이라 한정하여 설명하였다. 그러나 이것은 일 예에 해당하는 것으로써, 서비스 제공자의 설정에 따라 변경될 수 있다.

도 1은 본 발명의 기반이 되는 PCC 구조를 나타낸 도면,

도 2는 본 발명의 기반이 되는 GPRS의 기본 구조를 나타낸 도면,

도 3는 일반적인 PCRF-initiated IP-CAN 세션 변경 절차를 나타낸 도면,

도 4는 본 발명에 따른 PCEF 및 PDEF의 구조를 나타낸 도면,

도 5는 본 발명에 따라 IP-CAN 세션을 최초 생성하는 과정을 나타낸 도면,

도 6은 본 발명에 따라 IP-CAN 세션을 변경하기 위한 PCEF에서의 동작 과정을 나타낸 도면,

도 7는 본 발명에 따라 IP-CAN 세션을 변경하기 위한 PCRF에서의 동작 과정을 나타낸 도면.

Claims

PS(packet switched) 망의 PCEF(Policy and Charging Enforcement Function)에서 세션 설정 방법에 있어서,

상기 세션이 싱글 베어러를 지원하는지 멀티플 베어러를 지원하는지를 나타내는 베어러 정보를 PCRF(Policy and Charging Rules Function)로 송신하는 과정과,

상기 PCRF로부터 상기 베어러 정보에 근거하여 생성된 PCC(Policy & Charging Control) 룰(rule)을 수신하는 과정과,

상기 수신된 PCC 룰을 적용하여 패킷 서비스를 위한 세션을 설정하는 과정을 포함하되,

상기 세션이 싱글 베어러를 지원하는 경우, 상기 베어러 정보는 베어러의 타입을 식별하는 정보를 포함하도록 생성되고,

상기 세션이 멀티플 베어러를 지원하는 경우, 상기 베어러 정보는 베어러의 타입을 식별하는 정보를 포함하지 않도록 생성되며,

상기 베어러 정보는 Single-Bearer-Support(싱글베어러지원) AVP(Attribute-Value-Pair)로써 전송되고,

상기 Single-Bearer-Support AVP는, 상기 세션이 멀티플 베어러를 지원할 때의 ‘SINGLE_BEARER_NOT_SUPPORTED (0)’의 값과 상기 세션이 싱글 베어러를 지원할 때의 ‘SINGLE_BEARER_SUPPORTED (1)’의 값 중 어느 하나를 가짐을 특징으로 하는 방법.
제 1 항에 있어서,

상기 PCRF로부터 수신된 PCC 룰에 베어러 아이디가 포함된 경우, 베어러 바인딩 절차를 수행하는 과정을 더 포함하는 방법.
제 1 항에 있어서,

상기 PCRF로부터 수신된 PCC 룰에 베어러 아이디가 포함되지 않은 경우, 베어러를 생성하는 과정을 더 포함하는 방법.
PS(packet switched) 망의 PCRF(Policy and Charging Rules Function)에서 세션 설정 방법에 있어서,

PCEF(Policy and Charging Enforcement Function)로부터 상기 세션이 싱글 베어러를 지원하는지 멀티플 베어러를 지원하는지를 나타내는 베어러 정보를 수신하는 과정과,

상기 수신된 베어러 정보에 근거하여 PCC(Policy & Charging Control) 룰(rule)을 생성하는 과정과,

상기 세션이 싱글 베어러를 지원함을 상기 수신된 베어러 정보가 지시하면, 베어러 아이디와 함께 상기 생성된 PCC 룰을 송신하는 과정과,

상기 세션이 멀티플 베어러를 지원함을 상기 수신된 베어러 정보가 지시하면, 베어러 아이디가 없는 상기 생성된 PCC 룰을 송신하는 과정을 포함하되,

상기 베어러 정보는 Single-Bearer-Support(싱글베어러지원) AVP(Attribute-Value-Pair)로써 수신되고,

상기 Single-Bearer-Support AVP는, 상기 세션이 멀티플 베어러를 지원할 때의 ‘SINGLE_BEARER_NOT_SUPPORTED (0)’의 값과 상기 세션이 싱글 베어러를 지원할 때의 ‘SINGLE_BEARER_SUPPORTED (1)’의 값 중 어느 하나를 가짐을 특징으로 하는 방법.
제 4 항에 있어서,

상기 세션을 최초 설정할 시, 상기 PCEF로부터 수신된 베어러 정보를 저장하는 과정을 더 포함하는 방법.
제 4 항에 있어서,

상기 PCC 룰을 생성한 이후에 타이머를 설정하는 과정,

PCC 룰 요청이 상기 PCEF로부터 수신되는지 결정하는 과정, 및

상기 PCC 룰 요청이 수신되면, 베어러 아이디와 함께 상기 생성된 PCC 룰을 송신하는 과정을 더 포함함을 특징으로 하는 방법.
제 6 항에 있어서,

상기 PCC 룰 요청이 수신되지 않으면, 상기 타이머가 종료되었는지 판단하는 과정, 및

상기 타이머가 종료되었으면, 상기 수신된 베어러 정보를 체크하는 과정을 더 포함함을 특징으로 하는 방법.
PS(packet switched) 망의 PCEF(Policy and Charging Enforcement Function)의 세션 설정 장치에 있어서,

상기 세션이 싱글 베어러를 지원하는지 멀티플 베어러를 지원하는지를 나타내는 베어러 정보를 PCRF(Policy and Charging Rules Function)로 송신하는 송신부와,

상기 PCRF로부터 상기 베어러 정보에 근거하여 생성된 PCC(Policy & Charging Control) 룰(rule)을 수신하는 수신부와,

상기 베어러 정보를 상기 PCRF로 송신하도록 제어하고, 상기 PCRF로부터 수신된 PCC 룰을 적용하여 패킷 서비스를 위한 세션을 설정하도록 제어하는 제어부를 포함하되,

상기 세션이 싱글 베어러를 지원하는 경우, 상기 베어러 정보는 베어러의 타입을 식별하는 정보를 포함하도록 생성되고,

상기 세션이 멀티플 베어러를 지원하는 경우, 상기 베어러 정보는 베어러의 타입을 식별하는 정보를 포함하지 않도록 생성되며,

상기 베어러 정보는 Single-Bearer-Support(싱글베어러지원) AVP(Attribute-Value-Pair)로써 전송되고,

상기 Single-Bearer-Support AVP는, 상기 세션이 멀티플 베어러를 지원할 때의 ‘SINGLE_BEARER_NOT_SUPPORTED (0)’의 값과 상기 세션이 싱글 베어러를 지원할 때의 ‘SINGLE_BEARER_SUPPORTED (1)’의 값 중 어느 하나를 가짐을 특징으로 하는 장치.
제 8 항에 있어서,

상기 제어부는, 상기 PCRF로부터 수신된 PCC 룰에 베어러 아이디가 포함되어 있는 경우, 베어러 바인딩 절차를 수행하도록 제어하는 과정을 더 수행하는 장치.
제 8 항에 있어서,

상기 제어부는, 상기 PCRF로부터 수신된 PCC 룰에 베어러 아이디가 포함되지 않은 경우, 베어러를 생성하도록 제어하는 과정을 더 수행하는 장치.
PS(packet switched) 망의 PCRF(Policy and Charging Rules Function)에서 세션 설정 장치에 있어서,

PCEF(Policy and Charging Enforcement Function)로부터 상기 세션이 싱글 베어러를 지원하는지 멀티플 베어러를 지원하는지를 나타내는 베어러 정보를 수신하는 수신부와,

상기 수신된 베어러 정보에 따라 PCC(Policy & Charging Control) 룰(rule)을 생성하도록 제어하는 제어부와,

상기 생성된 PCC 룰을 상기 PCEF로 송신하는 송신부를 포함하되,

상기 세션이 싱글 베어러를 지원함을 상기 수신된 베어러 정보가 지시하면, 상기 제어부는 베어러 아이디와 함께 상기 생성된 PCC 룰을 송신하고,

상기 세션이 멀티플 베어러를 지원함을 상기 수신된 베어러 정보가 지시하면, 상기 제어부는 베어러 아이디가 없는 상기 생성된 PCC 룰을 송신하며,

상기 베어러 정보는 Single-Bearer-Support(싱글베어러지원) AVP(Attribute-Value-Pair)로써 수신되고,

상기 Single-Bearer-Support AVP는, 상기 세션이 멀티플 베어러를 지원할 때의 ‘SINGLE_BEARER_NOT_SUPPORTED (0)’의 값과 상기 세션이 싱글 베어러를 지원할 때의 ‘SINGLE_BEARER_SUPPORTED (1)’의 값 중 어느 하나를 가짐을 특징으로 하는 장치.
제 11 항에 있어서,

상기 세션을 최초 설정할 시, 상기 PCEF로부터 수신된 베어러 정보를 저장하는 메모리를 더 포함하는 장치.
제 11 항에 있어서,

상기 제어부는, 상기 PCC 룰을 생성한 이후에 타이머를 설정하고, PCC 룰 요청이 상기 PCEF로부터 수신되는지 결정하고, 상기 PCC 룰 요청을 수신하면 베어러 아이디와 함께 상기 생성된 PCC 룰을 송신함을 특징으로 하는 장치.
제 13 항에 있어서,

상기 제어부는, 상기 PCC 룰 요청이 수신되지 않으면 상기 타이머가 종료되었는지 판단하고, 상기 타이머가 종료되었으면 상기 수신된 베어러 정보를 체크함을 특징으로 하는 장치.