IT & Mobile

S-CSCF에서 받은 호를 라우팅 하는 방법에는 3가지가 있지만

주로 1,2번 2가지가 스인다.

1. IFC (가입자 기반으로 동작)

  가입자 기반에도 2가지가 있는데

  A. 발신호: P-Asserted-Identity (없으면 From)을 기준으로 처리한다.

  B. 착신호: invite 옆에있는 R-URI (Request URI)를 기준으로 처리한다.

     기준이 바뀌면 동작이 재설정 되므로, P-A-I나 R-URI가 동일한 상태에서

     iFC가 순차적으로 처리되며, 따라서 iFC에는 우선순위(Priority)가 존재한다.

2. Prefix-Routing

  가입자랑 상관없이 특정번호 (예:1593408)의 경우

  지정한 서버로 포워딩 시킬 수 있다.

3. PSI-일반적으로는 외부에서 들어온 호를 I-CSCF에서 처리할 때 사용하지만

  S-CSCF에서도 사용 가능.

IMS에서는 PSI를 통해

외부에서 들어온 호를 I-CSCF에서 AS로 직접 포워딩 할 수 있다. (8.8장 )

3가지 방식이 있는데

1. 서브도메인 이용

2. Direct PSI trigger

3. Indiect PSI trigger

이 중 1,2번이 간단한 편인데

2번을 설명하면

I-CSCF에서 HSS로 LIR(Location info query) 및  LIA(Answer)를 통해

AS주소를 안 다음에 AS로 바로 라우팅 하는 것이다.

AS에서는 처리 후, 다시 I-CSCF로 호를 보내면

I-CSCF -> S-CSCF -> (T)AS 형태로 호가 이루어 진다. (확인 중)

그리고 WildCard(*) PSI 등록시에는

번호!.*!  형태로 느낌표 사이에 regex로 표현된다.

3. Indirect PSI trigger는

I-CSCF(HSS LIR) -> SCSCF (HSS SAR:레지확인 후 iFC 동작) -> AS로 호가 되는데

unregi된 서비스 번호에 대해서도 서비스가 가능한 장점이 있다.

단점은 PSI + iFC도 필요해서 다소 복잡하다.

ICID (IMS charging ID) :과금 ID

P-CSCF가 Regi 수신받으면 ICID 생성.  (11.12)

P-CSCF는  P-Charging-Vector헤더를 이용해 ICID를 S-CSCF로 전달.

S-CSCF는 받은 ICID를 저장. 하고 이를 이용한 과금 수행.

(12.7)

세션중에 P-CSCF는 추가적인 media-stream용 ICID생성. (PDP Context 연관부분)

IOI(Inter-Operator ID)도 과금에 사용됨.

-type2 : 주로 통신사 내부에서 이걸 사용함.

-type1:(p-cscf 와 s-cscf간 용도),   type3:로밍용.

발신쪽 S-CSCF가 P-Charging-Vector에 orig-ioi넣어놓으면,

착신쪽에서 orig-ioi를 제거하고 단말로 내려감(단말로는 과금정보 절대 안내려감)

대신 183이 단말에서 올라오면 다시 ICID,IOI등을 더해서  전달함.

SIP is protocol like HTTP. while

IMS is telco System Architecture which uses SIP.

<SIP History>

1998년에 H.323 이 나오고  -( 최초로 RTP사용.)

1999년에 SIP가 나오면서 혼용되다가,  2008년경부터 본격 사용됨.
    -SIP는 1996년에 나온 HTTP1.0을 차용하여 Text-based로 정의.

2002년 RFC3261.

2012년에 8월(skt,lgt) 12월(kt) VoLTE 최초 상용화.

<IMS>

- 3G에서부터 HLR, 통화 등을 수용하기 위한 텔코의 시스템 구조로 발전.

      UNI: user to Network Interface (단말과 망 사이)

      NBI : North Border (AS 경계)

      NNI : Network to Network ( 타이통사간 경계)

- IFC Chaining을 통해서 호가 흘러가는 구조 임.(IFC를 S-CSCF가 HSS로부터 받아오는 게 핵심.)

- PSI 는 최종 서비스 혹은 trigger의 경우 최종 서비스로 바로가는 방법.  

  즉,IFC 는 체이닝이 되어야 효과를 발생하는 과정이고 차이가 큼..

-  ISC (IMS Service Control )Reference Point 임. 여기서 IFC가 처리됨.

RAVEL기반 로밍: VoLTE로밍의 대세

 - CMCC에서 밀고 있음.

s8hr로밍: simple해서 힘을 받고 있음.

IP Layer에서만 로밍하면 국내호 처리는 완료되며,

로컬호 처리가 이슈.

USIM = SIM + UICC

참고사이트

Public User ID: 국제적으로 통용하기 위한 ID로서, 공용ID인 만큼, 명함이나 출판물에 찍어서 교환해도 되는 고유Id이다.

tel Uri 혹은 Sip Uri로 표시한다. 

- tel:+821012345678

- sip:john.doe@ims.korea.com

Private User ID: 통신사 내에서 쓰기위한 용도이다.

< Puid와 Prid의 관계 >

PuID는 폰마다 하나씩 존재해야 하지만,

PrID는 하나를 만들어 여러개의 폰에 공용으로 사용할 수 있다.

PrID는 sip:joe@mytelecom.com 형태로 쓰면 된다.

<GRUU>

폰을 위해 GRUU(Grobally Routable User agent URI)를 사용할 수 있으며

GRUU를 여러개 만들어서 폰하나에 GRUU 2개를 할당할 수도 있다.

즉 Phone1- GRUU1  - Puid1

               - GRUU2  - Puid2 

    Phone2 - GRUU3  /

와 같은 형태로   다대다 매핑이 가능하다.

IMS의 기본 Invite Flow를 보면 다음과 같다.

단말이 IMS 시스템에서 서버에 등록을 하는 절차.

(VoLTE 통화를 위해서, 단말과 서버간의 사전 절차이다.

VoLTE는 데이타망과 유사한 통화전용LTE망  위에서 통화를 하는 것이므로, VoIP라고 볼 수도 있고,

기존의 CS망에서 통화하던게 발전한 것이므로 일반통화라고 볼 수도 있을 것 같은데.. 

아무래도 기본 통화로 상용되다 보니 VoIP라고 잘 부르진 않는다. )

1. 단말이 서버로 ID를 보낸다 (First Regi,  integrity_protected필드=no)

2. 서버(CSCF)에서 401 unAuthorized 응답을 보낸다

3. 단말이 401응답속의 nonce(challenge)필드 값을 이용해서 도전과제를 풀어서 올린다. (Second Regi, integrity_protected필드=yes)

4. 서버(CSCF)에서 200OK를 보낸다.

이 중에서 3번 항목을 살펴보면

단말의 SIM에는 PUID(고유ID: From필드에 사용), PRID(인증용 ID: userName 필드에사용) 및 key, ck(암호키), ik(변조체크 키) 가 있는데

3번의 과정에서는 ck,ik,nonce+ 이것들을 이용해서 계산된 결과가 올라간다.

서버는 이 결과가 원하는 답이 맞을 경우 Regi를 해 주게 된다.  

<인증 방식>

인증 방식에는 aka인증과 md5 인증이 있는데

요즘 단말들이 aka인지 md5인지를 결정하여 올려주는 관계로,  차이만 본다면

aka: 위에 언급한 것처럼 sim을 이용해서 인증.  nonce이용

md5: 좀 더 간단한 인증으로 nonce가 아니고 n-nonce 필드를 이용.