사용자 경험에 기반한 EMM 시나리오와 11가지 EMM Case들 문서를 참고하시고 본 문서를 읽기 바랍니다.
LTE EMM Procedure: 1. Initial Attach for Unknown UE 1편에 이어 EMM Case 1에 대한 망 초기 접속 절차를 다룬다. 이번 글(2편)에서는 처음으로 망에 접속하는 사용자의 초기 접속 절차를 (1) Acquisition of IMSI, (2) Authentication, (3) NAS Security Setup, (4) Location Update, (5) EPS Session Establishment로 나누어 상세히 소개한다.
|
|
|
목차 4.1 IMSI 획득 (Acquisition of IMSI) 5. EPS Entity Information: Before/After Initial Attach 5.1 Before Initial Attach |
4. 초기 접속 절차 (Initial Attach Procedure)
이제부터 “EMM Case 1: Initial Attach with Unknown UE”[1] 초기 접속 절차에 대하여 상세히 기술한다. EMM Case 1은 LTE 망/서비스에 가입한 사용자가 UE의 전원을 켜고 가입 후 처음 망에 접속하는 경우로, 이 문서의 III 장에서 기술한 Attach Case 1에 해당한다[2]. 그림 4는 EMM Case 1[1] 초기 접속 절차를 III 장에서 분류한 망 접속 절차 기능 단위 별로 나타낸 것이다.
그림 4. Summary of Initial Attach Procedure
4.1 IMSI 획득 (Acquisition of IMSI)
그림 5는 첫 번째 절차로 MME가 IMSI를 얻기까지의 절차를 나타낸다. UE는 IMSI를 포함하는 Attach Request 메시지를 전송하여 망 접속 요청을 하고, MME는 Attach Request 메시지를 수신하여 IMSI를 얻는다. 이 과정을 ❶ UE가 무선 링크 동기를 맞추고 초기 상태에 있는 단계와 ❷ UE에서 MME로 Attach Request 메시지가 전달되는 ECM 연결 설정(ECM Connection Establishment) 단계로 나누어 설명하도록 한다. ECM 연결 설정 단계는 (1) RRC 연결 설정 단계와 (2) S1 시그널링 연결 설정 단계로 구분한다.
그림 5. Procedure for Acquisition of IMSI
❶ 무선 링크 동기 및 초기 상태 (Initial State after Radio Link Synchronization)
망으로 초기 접속 요청을 하기 위해서는 eNB와 통신할 수 있어야 하므로, UE는 PLMN 및 셀 탐색 과정을 거쳐 eNB(셀)를 선택하고 무선 링크 동기를 맞춘다(PLMN 및 셀 탐색 절차는 본 문서 범위 밖으로 여기서는 다루지 않는다). 사용자는 이제 eNB와 통신을 할 수 있는 상태가 된다. 이 단계에서 UE는 EMM-Deregistered, ECM-Idle, RRC-Idle 상태에 있게 된다.
❷ ECM 연결 설정 (ECM Connection Establishment)
UE의 NAS 계층에서는 망 접속을 요청하기 위하여 UE ID를 IMSI로 하고 UE가 지원하는 Network Capability를 포함하여 Attach Request (IMSI, UE Network Capability) 메시지를 발생한다. 이 메시지는 MME에 있는 NAS 계층으로 전달된다.
Attach Request 메시지를 전송하기 위해서는 UE와 MME 간에 ECM 연결이 설정되어야 하는데, 이는 UE와 eNB 간에는 RRC 연결이 eNB와 MME 간에는 S1 시그널링 연결이 설정되어야 함을 의미한다. NAS 메시지는 RRC 연결에서는 RRC 메시지(RRC Connection Setup Complete 메시지)를 통하여, S1 시그널링 연결에서는 S1AP 메시지(Initial UE Message 메시지)를 통하여 전달된다.
(1) RRC 연결 설정 (RRC Connection Establishment)
RRC 연결은 UE와 eNB의 RRC 계층 간에 설정되고, RRC 메시지나 제어 평면 상위 메시지인 NAS 메시지를 전송할 때 사용된다. RRC 연결 설정 절차는 다음과 같다.
1) [UE → eNB] RRC 연결 요청
UE는 eNB로 RRC Connection Request (Establishment Cause=“Mobile Originating Signaling”) 메시지를 전송함으로써 RRC 연결을 요청한다. 설정 이유(Establishment Cause) 중 Mobile Originating Signaling은 UE가 Attach, Detach, TAU(Tracking Area Update)를 요청할 때 사용되고, 이 메시지는 한 셀 안에 있는 UE들이 공동으로 사용하는 SRB(Signaling Radio Bearer)인 SRB 0와 논리 채널인 CCCH(Common Control Channel)를 통해 eNB에게 전달된다.
2) [UE ← eNB] RRC 연결 Setup
eNB는 UE에게 RRC Connection Setup 메시지를 전송함으로써 UE가 dedicated하게 사용할 SRB 구성(configuration) 자원을 할당한다. 이 메시지는 SRB 0와 CCCH를 통해 전달된다. UE의 상/하향 무선자원은 eNB에서 제어되므로, 이 단계를 마친 후 UE는 RRC Connection Setup 메시지를 통해 할당 받은 SRB configuration을 사용하여 무선 자원을 사용하게 되고, EMM-Deregistered, ECM-Idle, RRC-Connected 상태로 들어가게 된다.
3) [UE → eNB] RRC 연결 완료
UE는 SRB 1과 DCCH(Dedicated Control Channel)을 통해 eNB에게 RRC Connection Setup Complete 메시지를 전송함으로써 RRC 연결 완료를 알린다. NAS 계층에서 전달된 Attach Request 메시지1는 효율적인 전송을 위해 RRC Connection Setup Complete 메시지가 전달될 때 이 메시지의 Dedicated NAS Information 필드(DedicatedInfoNAS)를 통하여 eNB에게 전달된다.
(2) S1 시그널링 연결 설정 (S1 Signaling Connection Establishment)
eNB와 MME 간 제어 신호는 S1-MME 인터페이스에서 S1AP 메시지를 통해 전달된다. S1AP 메시지는 사용자 별로 S1 시그널링 연결을 통하여 전달되고, S1 시그널링 연결은 eNB와 MME가 UE를 식별하기 위하여 할당한 (eNB UE S1AP ID, MME UE S1AP ID) pair에 의해 정의된다.
지금은 S1 시그널링 연결이 설정되지 않은 상태에서 eNB에 첫 번째 NAS 메시지인 Attach Request 메시지가 온 경우로, eNB는 S1 시그널링 연결 설정을 위하여 eNB UE S1AP ID를 할당하고 Initial UE Message 메시지를 통하여 Attach Request를 MME로 전달한다. Attach Request 메시지는 Initial UE Message 메시지의 NAS-PDU 필드에 담겨서 전송된다. Initial UE Message 메시지 구성은 아래와 같다:
MME는 S1-MME를 통하여 eNB로부터 Initial UE Message 메시지를 수신하면 해당 UE에 대하여 MME S1AP UE ID를 할당함으로써 eNB와 MME 간에 S1 시그널링 연결이 설정된다(eNB UE S1AP ID, MME UE S1AP ID). MME UE S1AP ID는 MME가 향후 S1-MME 인터페이스(하향)에서 UE를 식별하는데 사용된다.
(3) ECM S1 연결 설정 (ECM S1 Connection Establishment)
앞의 (1)과 (2) 단계를 통해 UE의 NAS 계층과 MME의 NAS 계층 간에 ECM 연결이 설정되고, 이 단계를 마친 후 UE는 EMM-Registered2, ECM-Connected, RRC-Connected 상태로 들어가게 된다.
(4) IMSI 획득 (IMSI Acquisition)
MME의 NAS 계층은 UE의 NAS 계층으로부터 Attach Request 메시지를 수신하여 사용자의 IMSI를 얻고 UE Network Capability 정보로부터 UE가 사용 가능한 security 알고리즘이 무엇인지 UE의 Security Capability를 파악한다.
UE로부터 Attach Request (IMSI, UE Network Capability) 메시지를 수신하여 사용자의 IMSI와 UE Security Capability 정보를 파악한 MME는 이후 이를 이용하여 “가입자 인증(Authentication)”과 NAS 메시지를 안전하게 전송하기 위한 “NAS 보안 키 설정(NAS Security Setup)” 절차를 수행한다. 이 두 절차는 EPS-AKA(Evolved Packet System-Authentication and Key Agreement) 기반으로 수행되며, 4.2 절에서 “가입자 인증”을 4.3 절에서 “NAS Security Setup” 절차를 기술한다. 이 두 절차는 “LTE Security” 기술문서[3][4]에 상세히 기술되어 있으므로 본 문서에서는 간단히 기술한다.
4.2 가입자 인증 (Authentication)
그림 6은 사용자(UE)와 망(MME) 간에 가입자 인증 절차를 나타낸다. LTE 가입자 인증은 (1) MME가 HSS로부터 가입자에 대한 인증 벡터(Authentication Vector)를 획득하는 단계와 (2) MME와 UE 간에 상호 인증을 하는 단계로 나눌 수 있다. 단계 (1)은 MME와 HSS 간 S6a 인터페이스 상에 Diameter 프로토콜을 통해 수행되고, 단계 (2)는 UE와 MME 간 NAS 프로토콜을 통해 수행된다.
그림 6. Procedure for Authentication
(1) 인증 벡터 획득 (Acquisition of Authentication Vector)
1) [MME → HSS] 인증 벡터 요청
MME는 HSS로 Authentication Information Request 메시지를 전송하여 IMSI 값을 갖는 사용자에 대한 인증 벡터(AV; Authentication Vector)를 요청한다. MME는 IMSI와 함께 SN ID(Serving Network ID)를 전송함으로써 HSS가 인증 벡터를 생성할 때 사용자 접속망 정보(어느 사업자의 어느 망인지)를 반영하도록 한다. Authentication Information Request 메시지 주요 파라미터는 다음과 같다:
2) [HSS] 인증 벡터 생성
HSS3는 IMSI의 LTE 마스터 키(LTE K)와 사용자 접속망 ID(SN ID)를 이용하여 인증 벡터를 생성한다. 인증 벡터를 생성하는 절차는 그림 7과 같이 두 단계로 진행된다. (i) HSS는 SQN과 RAND를 발생시킨 후 암호화 함수에 {LTE K, SQN, RAND}를 입력하여 {XRES, AUTN, CK, IK} 값을 발생시킨다. (ii) 키 발생 함수에 {SQN, SN ID, CK, IK}를 입력하여 KASME를 발생시킨다.
(i) (XRES, AUTN, CK, IK) = Crypto Function(LTE K, SQN, RAND)
(ii) KASME = KDF(SQN, SN ID, CK, IK)
그림 7. 인증 벡터 생성
최종적으로 인증 벡터는 {RAND, AUTN, XRES, KASME}로 구성한다. 인증 벡터 요소들의 기능은 다음과 같다:
3) [MME ← HSS] 인증 벡터 전달
HSS는 인증 벡터를 Authentication Information Response (AV4) 메시지를 통해 MME에게 전송한다. MME는 이를 이용하여 단계 (2)에서 UE와 상호 인증을 수행한다.
(2) 상호 인증 (Mutual Authentication)
LTE 인증은 상호 인증으로 망은 사용자 인증을 사용자는 망 인증을 수행한다. HSS로부터 인증 벡터{RAND, AUTN, XRES, KASME}를 수신한 MME는 이 중 RAND와 AUTN은 UE가 인증 벡터를 생성하고 망 인증을 할 수 있도록 UE에게 전송하고, XRES와 KASME는 MME에 저장한다. XRES는 사용자 인증에 사용하고 KASME는 NAS 보안 키를 생성하는데 사용된다. KASME는 사용자에게 전달되지 않으나(UE가 인증 벡터 생성시 UE에서 생성됨) 이에 대응하는 인덱스로 KSIASME를 UE에게 전달한다. UE와 MME 간 상호 인증 절차는 다음과 같다.
4) [UE ← MME] 사용자에 인증 요청
MME는 UE가 인증 벡터를 생성하고 망 인증을 하는데 필요한 정보(RAND, AUTN)와 KASME에 대응하는 인덱스 정보(KSIASME)를 Authentication Request (RAND, AUTN, KSIASME) 메시지를 통하여 UE에게 전달한다.
5) [UE] 사용자가 망 인증: 인증 벡터 생성 및 망 인증
UE는 MME로부터 Authentication Request (RAND, AUTN, KSIASME) 메시지를 수신한 후 AUTN에서 SQN 값을 구하고 HSS에서와 같은 방법으로(그림 7과 같이) 인증 벡터를 생성한다. UE가 생성한 AUTN(AUTNUE)이 MME로부터 수신한 AUTN(AUTNHSS)과 같은지 비교하여 망을 인증하고, KASME를 KSIASME를 인덱스로 하여 저장한다.
6) [UE → MME] 사용자의 RES 전달
UE는 AUTN 값을 비교하여 망 인증을 마친 후 MME가 사용자 인증을 할 수 있도록 자신이 발생한 RES 값을 Authentication Response (RES) 메시지를 통하여 MME에게 전송한다.
7) [MME] 망이 사용자 인증
MME는 UE로부터 Authentication Response (RES) 메시지를 수신한 후, UE가 생성한 RES와 HSS로부터 받은 XRES가 같은지 비교하여 사용자를 인증한다.
이로써 UE와 망(MME) 간 상호 인증이 완료된다. 이제 사용자와 망은 NAS 메시지를 안전하게 전송하기 위하여 NAS Security Setup을 설정한다.
4.3 NAS 보안 키 설정 (NAS Security Setup)
가입자 인증을 성공적으로 마친 MME는 UE와 MME 간에 NAS 메시지를 안전하게 전송하기 위하여 NAS Security Setup 절차를 수행한다. 그림 8은 NAS Security Setup 절차의 호 흐름을 나타낸다.
그림 8. Procedure for NAS Security Setup
1) [MME] NAS Security 키 생성
MME는 UE가 전송한 Attach Request 메시지로부터 NAS 메시지에 적용할 무결성 및 암호화 알고리즘을 선택하고 KASME를 이용하여 NAS 메시지에 적용할 NAS 무결성 키(KNASint)와 NAS 암호화 키(KNASenc)를 생성한다.
2) [UE ← MME] UE가 NAS Security 키 생성할 수 있게 도와주기
MME는 선택한 security 알고리즘을 Security Mode Command (KSIASME, Security Algorithm, NAS-MAC) 메시지를 통하여 UE에게 알림으로써 UE가 NAS security 키를 생성할 수 있도록 한다. MME는 이 메시지를 무결성 보호하여(NAS-MAC을 포함하여) 전송한다.
3) [UE] NAS Security 키 생성
UE는 MME로부터 Security Mode Command 메시지를 수신하여, MME가 선택한 NAS security 알고리즘을 이용하여 NAS security 키들(KNASint와 KNASenc)을 생성하고 NAS 무결성 키(KNASint)를 이용하여 Security Mode Command 메시지에 대한 무결성 검증을 수행한다. Security Mode Command 메시지에 대한 무결성 검증이 성공하면 이제 UE와 MME 간에 NAS security 키들이 성공적으로 설정되어 동작하는 상태이다.
4) [UE → MME] NAS Security 키 생성 완료 알림
UE는 MME에게 Security Mode Complete (NAS-MAC) 메시지를 전송함으로써 NAS security 키 생성을 완료했음을 알린다. UE는 NAS security 키들을 이용하여 이 메시지를 암호화 하고 무결성 보호하여 전송한다.
이로써 UE와 망(MME) 간 NAS Security Setup이 완료되고 이 후 UE와 MME 간 NAS 메시지는 암호화되고 무결성 보호되어 안전하게 전송된다.
4.4 위치 등록 (Location Update)
가입자 인증과 NAS Security Setup을 성공적으로 마치고 나면, 이제 MME는 망에 가입자를 등록시키고 사용자가 어떤 서비스를 이용할 수 있는지 파악해야 한다. 이를 위하여 MME는 사용자가 자신에게 접속해서 자신이 관리하는 영역에 위치하고 있음을 HSS에게 알리고, HSS로부터 사용자 가입정보를 다운로드 받는다. 이러한 과정은 위치 등록 절차를 통하여 진행되며, MME와 HSS 간에 S6a 인터페이스 상에서 Diameter 프로토콜을 이용하여 수행된다. 그림 9는 위치 등록 절차의 호 흐름을 나타낸다.
그림 9. Procedure for Location Update
1) [MME → HSS] UE 위치 알림
MME는 UE가 자신에게 접속했음을 알리고 가입 정보를 요청하기 위하여 HSS로 Update Location Request (IMSI, MME ID) 메시지를 전송한다.
2) [HSS] UE 위치 등록
HSS는 UE가 어느 MME에 있는지 MME ID를 등록한다.
3) [MME ← HSS] 사용자 가입 정보 전달
HSS는 MME가 새로운 사용자에게 EPS 세션을 생성하고 default EPS 베어러를 생성할 수 있도록 사용자 가입 정보를 Update Location Answer 메시지를 통하여 MME에게 전달한다. Update Location Answer 메시지로 전달되는 사용자 가입 정보는 다음과 같다:
4) [MME] 가입 정보 저장
MME는 HSS로부터 Update Location Answer 메시지를 수신하여 가입 정보를 저장한다.
사용자 가입 정보를 다운로드 받은 MME는 사용자가 어느 서비스에 가입했으며 어느 APN으로 어떤 품질을 갖도록 자원을 할당해야 할지 알 수 있다.
4.5 EPS Session Establishment
MME는 사용자 가입 정보를 이용하여 EPS 세션 및 default EPS 베어러를 설정함으로써 사용자가 가입한 서비스 품질을 제공할 수 있도록 망/무선 자원을 할당한다. EPS 세션 및 default EPS 베어러 생성 절차를 그림 10과 그림 11로 나누어 나타내고 설명하도록 한다.
그림 10. Procedure for EPS Session Establishment (1)
1) [MME] EPS Bearer ID 할당
MME는 새로 망에 접속한 사용자에게 default EPS 베어러를 생성하기 위하여 EPS Bearer ID(EBI)를 5~15 중에 하나의 값으로 할당한다.
2) [MME] P-GW 선택
MME는 HSS로부터 수신한 APN을 확인하고 해당 APN으로 접속하기 위하여 어느 P-GW로 접속할 지를 결정한다. P-GW 결정은 HSS로부터 받은 가입 정보(P-GW ID)로 할 수도 있고, 가입 정보에 없는 경우 MME는 DNS 서버로 APN FQDN(e.g., internet.apn.epc.mnc05.mcc450. 3gppnetwork.org)에 대한 쿼리를 하고 이에 대한 응답으로 P-GW IP 주소 리스트 수신 후, MME의 P-GW 선택 정책6에 따라 P-GW를 선택한다. 해당 P-GW로 향하기 위해 어느 S-GW를 거쳐갈지도 같이 선택한다.
3) ~ 4) EPS 세션 생성 요구
MME는 2)에서 선택한 P-GW를 향해 Create Session Request 메시지를 전송함으로써 EPS Session과 default EPS 베어러 생성을 요구한다. P-GW가 PCRF로 EPS Session 설정을 요구할 때 사용할 수 있도록 HSS로부터 수신한 가입 정보를 Create Session Request 메시지에 포함하여 전달한다. UE-AMBR 값은 MME가 결정하는 값이므로 전달하지 않는다.
3) [MME → S-GW] EPS 세션 생성 요구
MME와 S-GW 간은 S11 인터페이스로 제어 평면(CP)에서 GTP 프로토콜(GTP-C)로 통신한다7. MME는 2)에서 선택한 S-GW를 향해 Create Session Request 메시지를 전송한다. 메시지 파라미터는 다음과 같다:
4) [S-GW → P-GW] EPS 세션 생성 요구
S-GW와 P-GW 간은 S5 인터페이스로 사용자 평면(UP)과 제어 평면에서 GTP 프로토콜(UP: GTP-U, CP: GTP-C)로 통신한다. S-GW는 수신한 Create Session Request 메시지에 있는 P-GW로 S5 GTP를 생성하기 위하여 하향 S5 TEID(S5 S-GW TEID)를 할당하고, 이를 다른 파라미터와 함께 Create Session Request 메시지를 통해 P-GW로 전송한다.
5) [S5 베어러: 하향]
절차 4)를 마치면 하향으로 S5 GTP-U 터널이 생성되어 P-GW는 하향 트래픽을 S-GW로 전송할 수 있는 상태가 된다. 그림 10과 11에서 GTP 터널 TEID는 값을 할당하여 송신하는 측을 “fill”(●)로 이 값을 수신하는 측을 “empty”(○)로 표시하였다.
6) [P-GW] 사용자 IP 주소 할당
Create Session Request 메시지를 수신한 P-GW는 새로 망에 접속하려는 사용자임을 알고 UE에게 APN을 이용할 때 사용할 IP 주소를 할당한다.
7) [P-GW → PCRF] EPS 세션 설정 알림
P-GW와 PCRF 간은 Gx 인터페이스로 Diameter 프로토콜로 통신한다. 사용자에게 EPS 세션을 생성할 때에는 사용자가 가입한 서비스에 따라 자원 할당 및 QoS 제어가 되어야 한다. 망에 접속한 모든 사용자에 대한 정책 제어는 PCRF에서 책임지므로, P-GW는 PCRF로 사용자의 가입 정보를 알려 사업자 정책에 맞는 자원 할당에 대한 승인(authorization)을 받는다. P-GW는 MME로부터 수신한 UE 가입정보를 기반으로 PCRF가 사업자 정책 적용 결정에 필요한 정보를 CCR(CC-Request) 메시지를 통해 PCRF로 알린다. CCR 메시지 구성 예는 다음과 같다:
8) [PCRF → SPR] 가입자 Profile 요청
PCRF는 사용자에 대한 PCC 정책 결정을 판단하기 위해 SPR에게 사용자 Access Profile을 요청한다.
9) [PCRF ← SPR] 가입자 Profile 전송
SPR은 PCRF에게 사용자 Access Profile을 전달한다. 사용자 Access Profile에는 SDF Filter, QCI, ARP, APN-AMBR(UL/DL), Charging Method(예, Offline), Changing Reporting Action(예, Start Reporting ECGI, TAI)등이 있을 수 있다.
10) [PCRF] Policy 결정
PCRF는 사용자 Access Profile을 기반으로 생성할 EPS Session에 대한 PCC 정책을 결정한다.
11) [P-GW ← PCRF] EPS 세션 설정 응답
PCRF는 10)에서 결정된 PCC 규칙을 CCA(CC-Answer) 메시지를 통하여 P-GW에게 전달한다. CCA 메시지 구성 예는 다음과 같다:
12) [P-GW] Policy Enforcement
P-GW는 PCRF로부터 수신한 PCC 규칙을 적용한다. PCC 규칙은 SDF 단위로 적용되므로, P-GW는 SDF와 EPS 베어러 mapping을 설정하고 default EPS 베어러에 적용할 QoS Profile을 준비한다(상세 내용은 “LTE QoS: SDF 및 EPS 베어러 QoS”[5] 참조).
13) ~ 15) EPS Session 생성 응답
P-GW는 MME로 Create Session Response 메시지를 전송함으로써 EPS 세션과 default EPS 베어러 에 적용된 서비스 품질을 알려준다. 이는 MME가 HSS로부터 수신하여 전달한 가입 정보 값일 수도 있고 PCRF가 결정한 다른 값일 수도 있다.
13) [S-GW ← P-GW] EPS 세션 생성 응답
P-GW는 S-GW로 S5 GTP를 생성하기 위하여 상향 S5 TEID(S5 P-GW TEID)를 할당하고, S5 P-GW TEID와 default EPS 베어러에 적용할 QoS profile을 4)에서 수신한 Create Session Request 메시지에 대한 응답으로 Create Session Response 메시지를 통해 S-GW로 전송한다.
14) [S5 베어러: 상향] S5 베어러 생성 완료
절차 13)을 마치면 상향으로 S5 GTP-U 터널이 생성되어 S-GW는 P-GW로/로부터 상/하향 트래픽을 송/수신 할 수 있는 상태가 된다.
15) [MME ← S-GW] EPS 세션 생성 응답
S-GW는 P-GW로부터 Create Session Response 메시지를 수신하여 상향 트래픽에 사용할 상향 S5 TEID(S5 P-GW TEID)를 저장하고, S1 베어러에 사용할 S1 GTP 터널의 상향 S1 TEID(S1 S-GW TEID)를 할당한다. 수신한 Create Session Response 메시지에 자신이 할당한 S1 S-GW TEID를 추가하여, 3)에서 수신한 Create Session Request 메시지에 대한 응답으로 Create Session Response 메시지를 MME로 전송한다.
16) [MME] MME가 S5 P-GW TEID를 갖는 이유
망에 접속한 UE가 향후 이동하여 TAU나 핸드오버를 수행하게 될 때 S-GW가 바뀔 수 있다. 이러한 경우 MME는 new S-GW에게 상향 S5 TEID 값을 전달하여 new S-GW가 P-GW로 상향 트래픽을 전달할 수 있도록 한다.
17) [S1 베어러: 상향]
절차 15)를 마치면 상향으로 S1 GTP-U 터널이 생성된다. eNB가 아직 이 값을 수신하지 못했으므로 eNB가 S-GW로 상향 트래픽을 전송할 수 있는 상태는 되지 못한다.
18) [MME] UE-AMBR 계산
이제 MME는 UE에게 Attach Request에 대한 응답으로 Attach Accept 메시지를 전송하고 eNB를 제어하여 E-RAB을 생성할 준비를 한다. 즉, 무선 구간과 S1 베어러에 자원을 할당할 준비를 한다. (이를 위해) MME는 eNB에게 전송할 UE-AMBR 값을 계산한다. MME는 UE-AMBR을 4.4절 절차에서 HSS로부터 사용자 가입 정보로 받은 값을 갖고 있으나 APN별 APN-AMBR의 합을 초과하지 않는 범위 안에서 UE-AMBR을 계산하여 할당할 수 있다.
그림 11. Procedure for EPS Session Establishment (2)
19) [MME] E-RAB 및 NAS 시그널링에 필요한 정보 결정
MME는 P-GW로부터 Create Session Response 메시지를 수신하여 사용자에 대한 자원 할당이 망에서 승인되고 할당되었음을 알고, eNB와 S-GW를 제어하여 E-RAB(DRB+S1 베어러) 생성을 제어한다. 이를 위하여 다음과 같이 E-RAB 생성에 필요한 자원과 NAS 시그널링에 필요한 정보를 결정한다.
20) [UE ← MME] 망 접속 허락 알림
MME는 4.1 절에서 UE가 전송했던 Attach Request 메시지에 대한 응답으로 P-GW에서 할당한 UE IP 주소와 MME에서 할당한 GUTI, TAI list, EPS Bearer ID, UE-AMBR 값, S-GW로부터 수신한 QoS 파라미터들을 Attach Accept 메시지8를 통하여 UE에게 전송한다.
이 메시지는 S1 시그널링 연결에서 Initial Context Setup Request 메시지를 통하여, RRC 연결에서 RRC Connection Reconfiguration 메시지를 통하여 전송된다.
21) [MME] KeNB 생성
MME는 eNB가 UE와 무선 구간에서 안전하게 통신할 수 있도록(AS Security Setup을 할 수 있도록) KASME로부터 AS Security 베이스 키인 KeNB를 생성한다.
22) [eNB ← MME] E-RAB 설정 요구
MME는 eNB가 S-GW와 S1 베어러를 설정하고 UE와 DRB를 설정할 수 있도록 Initial Context Setup Request 메시지를 eNB로 전송한다. Initial Context Setup Request 메시지 구성은 아래와 같다:
23) [S1 베어러: 상향]
절차 22)를 마치고 eNB가 S1 S-GW TEID 값을 알면 eNB는 S-GW로 상향 트래픽을 전송할 수 있는 상태가 된다.
MME로부터 Initial Context Setup Request 메시지를 수신 받아 E-RAB 생성을 요구 받은 eNB는 Attach Accept 메시지를 UE에게 전달하면서 DRB를 생성하고, Initial Context Setup Request 메시지에 대한 응답 메시지로 하향 S1 TEID를 Initial Context Setup Response 메시지를 통해 MME로 전송하여 MME가 S-GW로 전달하도록 함으로써 S1 베어러 설정을 마친다.
24) ~ 27) AS Security Setup
MME로부터 Initial Context Setup Request 메시지를 수신 받은 eNB는 DRB를 생성하기 위하여 UE와 통신하고자 한다. 무선 구간에서 안전하게 통신하기 위해서는 UE에게 메시지를 전송하기 전에 제어 평면(RRC 연결) 및 사용자 평면(DRB)에서 데이터 전송이 안전할 수 있도록 AS Security Setup을 수행한다(상세 내용은 “LTE Security II: NAS 및 AS Security”[3] 기술문서 참조).
24) [eNB] AS Security Key 생성
eNB는 MME로부터 수신한 KeNB로부터 UE - eNB 간 RRC 메시지 및 사용자 트래픽을 안전하게 전송하기 위하여 AS Security 키를 생성한다. eNB는 MME가 전달한 UE가 사용 가능한 Security 알고리즘에서 RRC 메시지에 적용할 무결성 및 암호화 알고리즘과 사용자 트래픽에 적용할 암호화 알고리즘을 선택하고, KeNB를 이용하여 RRC 무결성/암호화 키인 KRRCint/KRRCenc 와 사용자 트래픽 암호화에 적용할 KUPenc를 도출한다.
25) [UE ← eNB] UE가 AS Security 키 생성할 수 있게 도와주기
eNB는 선택한 AS Security 알고리즘(제어평면 RRC 무결성/암호화 알고리즘 및 사용자 평면 암호화 알고리즘)을 Security Mode Command (AS Security Algorithm, MAC-I) 메시지를 통하여 UE에게 알림으로써 UE가 AS security 키들(KRRCint, KRRCenc 및 KUPenc)을 생성할 수 있도록 한다. eNB는 이 RRC 메시지를 무결성 보호하여(MAC-I를 포함하여) 전송한다.
26) [UE] AS Security Key 생성
UE는 eNB로부터 Security Mode Command 메시지를 수신하여, eNB가 선택한 AS security 알고리즘을 이용하여 AS security 키들을 생성하고 Security Mode Command 메시지에 대한 무결성 검증을 수행한다.
27) [UE → eNB] AS Key 생성 완료 알림
Security Mode Command 메시지에 대한 무결성 검증이 성공하면 이제 UE와 eNB 간에 AS security 키들이 성공적으로 설정되어 동작이 가능한 상태이다. UE는 eNB에게 Security Mode Complete (MAC-I) 메시지를 전송함으로써 AS security 키 생성을 완료했음을 알린다. UE는 RRC 무결성 키를 이용하여 이 메시지를 무결성 보호하여 전송한다.
무선 구간에 AS Security Setup이 성공적으로 마쳤으므로, 향후 무선 구간을 통해 전달되는 RRC 메시지는 암호화되고 무결성 보호되어 전달되고 사용자 트래픽은 암호화되어 전달된다. eNB는 이제 DRB를 생성한다.
28) ~ 29) DRB Establishment
28) [UE ← eNB] RRC 연결 재구성
eNB는 무선 구간의 EPS 베어러인 DRB를 생성하기 위하여 상/하향 DRB ID를 할당하고, E-RAB QoS로부터 DRB QoS 파라미터를 구성한다. 이 후 안전한 RRC 연결을 통하여 RRC Connection Reconfiguration 메시지를 UE로 전송한다. RRC 연결은 UE가 Attach Request 메시지를 전송할 때 설정되었으나 이제 망 접속을 허락 받고 망에서 할당 받은 자원에 맞게 파라미터를 설정해야 하므로 RRC 연결을 재구성(reconfiguration)한다. UE의 RRC 계층은 RRC Connection Reconfiguration 메시지로부터 수신한 configuration 파라미터들로 무선 자원을 할당하고, Attach Accept 메시지를 추출하여 NAS 계층으로 전송한다.
UE의 NAS 계층은 이를 수신하여 UE IP 주소와 GUTI를 얻고 향후 이를 이용하여 통신한다.
29) [DRB 생성: 상향 및 하향] DRB 생성 완료
절차 28)을 마치고 나면 UE는 eNB로/로부터 상향/하향 트래픽을 송/수신 할 수 있는 상태가 된다.
30) [eNB → S-GW] E-RAB 설정 응답
eNB는 S1 베어러에 대한 하향 S1 TEID(S1 eNB TEID)를 할당하고 이를 22)에서 수신한 Initial Context Setup Request 메시지에 대한 응답으로 Initial Context Setup Response 메시지를 MME로 전송하여, MME가 S-GW로 알릴 수 있도록 한다.
상호: (주)엔앰씨컨설팅그룹 주소: 서울시 강남구 테헤란로 128, 3층 387호 대표이사: 손장우 전화: 02-3444-5747 메일: webmaster@netmanias.com 등록번호: 서울 아03722 제호: 넷매니아즈 등록일자: 2015년 5월 4일 발행/편집인: 손장우 청소년보호책임자: 이수정
주소: 본사: 서울시 강남구 테헤란로 128, 3층 387호 Netmanias USA: 5214 36th Ave. NE Seattle, WA 98105 USA
Copyright ⓒ 2002-2023 NMC Consulting Group. All rights reserved.
|
Initial Context Setup Request -> Initial Context Setup Response 로 변경해야 하는게 맞지 않나요?
오타 인 듯 싶습니다. 확인 부탁드려요~!
감사합니다. 하태호님.
문서 수정하였구요.
아울러 19페이지 그림 14의 "UP IP address"도 "UE IP address"로 수정하였습니다.
항상 좋은 자료 감사합니다! 요즘 Attach 부분을 공부하고 있는데
Initial Context Setup Request 메시지와 Security Mode Command 메시지 사이에
E-UTRAN에서 UE로 UE의 Capability 를 얻어와 MME로 전달하는 절차가 있다고 알고있는데
생략된 이유가 있나요?
MME는 Attach Request 메시지를 통해 UE로부터 얻고요.
아래에 MME가 UE로부터 UE Capability를 얻고 eNB가 MME로부터 UE Capability를 얻는 과정과 이를 기반으로 암호화 키를 도출하는 과정을 간단히 적었습니다 (자세한 내용은 LTE Security II 문서 참조).
혹시 문의하시는 내용이 다른 내용이면 다시 한번 문의해주세요..
-- 아래 --------------------------------------
■ 개요
Initial Attach시 UE와 MME의 NAS 계층은 NAS Security Setup 과정을 통해 같은 암호화 알고리즘을 공유하여 같은 NAS Security Key들을 도출하고, NAS 메시지 전송시 암호화 및 무결성 보호에 적용합니다.
그리고 UE와 eNB는 AS Security Setup 과정을 통해 같은 암호화 알고리즘을 공유하여 같은 AS Security Key들을 도출하고, RRC 메시지 전송시 암호화및 무결성 보호에 적용하며 User 패킷 전송시 암호화에 적용합니다.
■ NAS 암호화 키 도출
1. 먼저, UE는 MME로 Attach Request를 전송할 때 UE Network Capability field에 자기가 사용하는 Security 알고리즘(Encryption 알고리즘과 Integrity Protection 알고리즘)을 넣어 전송합니다.
2. MME는 Attach Request를 수신하여 UE가 사용가능한 Security 알고리즘을 알고 이 중에서 UE와 같이 사용할 알고리즘을 선택합니다.
3. 이 후 MME는 자신이 선택한 Security 알고리즘을 NAS Security Setup 과정을 통해 UE로 전달하고, 결과적으로 UE와 MME에서는 같은 NAS Security Key들이 도출되어 NAS 메시지 전송에 이용됩니다.
• NAS Security Setup 과정
i) Security Mode Command 메시지 (MME -> UE): MME는 UE로 NAS Security Algorithm을 전달. 무결성 키를 적용하여 MAC(NAS-MAC)을 구성하여 포함시킴 (MAC: Message Authentication Code)
ii) Security Mode Complete 메시지 (UE -> MME): 무결성 키를 적용하여 NAS-MAC을 구성하여 포함시키고 암호화하여 전달
■ AS 암호화 키 도출
1. MME는 UE로 Attach Accept 메시지를 전달하는 과정에서 S1AP 시그널링 메시지인 Initial Context Setup Request 메시지를 통해 UE가 사용하는 Security 알고리즘과 AS Security Key를 도출하기 위한 base key인 K_{eNB}를 eNB에게 전달합니다.
2. eNB는 MME로부터 Initial Context Setup Request 메시지를 수신하여 UE가 사용가능한 Security 알고리즘과 K_{eNB}을 얻고, UE와 같이 사용할 Security 알고리즘을 선택합니다.
3. 이 후 eNB는 선택한 Security 알고리즘을 AS Security Setup 과정을 통해 UE로 전달하고, 결과적으로 UE와 eNB에서는 같은 AS Security key들이 도출되어 RRC 메시지 및 User 패킷 전송에 이용됩니다.
• AS Security Setup 과정
i) Security Mode Command 메시지 (eNB -> UE): eNB는 UE로 AS Security Algorithm을 전달. 무결성 키를 적용하여 MAC(MAC-I)을 구성하여 포함시킴
ii) Security Mode Complete 메시지 (UE -> eNB): 무결성 키를 적용하여 MAC-I를 구성하여 포함시킴
8 page, 4) [UE MME] NAS Security 키 생성 완료 알림 에서
"Security Mode Command (NAS-MAC)"은 "Security Mode Complete (NAS-MAC)"의 오타인것 같네요
확인 부탁드려요~
정대우님, 감사합니다. ^^*
수정해서 다시 업로드 했습니다.
여기에 NAS 메시지인 "Attach Accept" 메시지가 실려갑니다.
TS 23.401, E-UTRAN Initial Attach 절차 (그림 5.3.2.1-1)에서 step. 17도 같이 참고해보세요.
감사합니다~
덕분에 많은정보들 받아가서 매번 감사드립니다.
- 0: 할당 안함
- 1 ~ 4: Reserved
- 5 ~ 15: 할당
왜 "Reserved" 하는지는... --;;;
간단한 오타가 있어서 확인 부탁드립니다.
5page 마지막에
"K_ASME=KDF(XRES,AUTN,CK,IK)" -> "K_ASME=KDF(SQN,SN ID,CK,IK)"
확인 부탁드립니다.
항상 감사합니다.
수정해서(수정일: 2013년 3월 29일) 다시 업로드 했습니다.
감사합니다.
In this particular document the part on "2. Authentication Procedure (2/3)" [page 9] has a small error.
One of the AV elements for "3) [MME -> HSS] Authentication Vector Delivery"' is listed as AUTH. It should be AUTN I believe.
The typo was corrected and the corrected version has been uploaded (April 15, 2013).
Thank you for your interest and kind comment.
Have a good week.
그 이후 E-RAB ID를 할당하여 Initial Context Setup Request를 보낼때 E-RAB ID 값을 담아서 eNB로 전송합니다.
즉, MME에서 EBI와 E-RAB ID를 할당하는것이 맞고요. eNB 입장에서는 MME에서 알려준 E-RAB ID를 사용합니다.
일반적으로 두 개의 값은 서로 동일합니다.
또...내용에는 Crypto Function이라고 되어있는데 그림7에는 Cryto Function이라고 되어있습니다.
Comment 감사합니다~ HSS generates 와 Crypto 수정하여 upload했습니다.
참고로, LTE 기술문서에서는, Security 문서때부터 AuC/HSS 기능을 합하여 HSS로 표현하고 있습니다. 본 문서에서는 그 표현이 빠져있어 page 5에 각주로 삽입하였습니다.
4.5 EPS Session Establishment 에서 5)번 과정의 S5 GTP-U 터널이 생성된 후에
P-GW에서 S-GW의 하향 트래픽이 맞는건지 S-GW에서 P-GW로의 상향 트래픽이 맞는 건지요..
그림 상으로는 S-GW에서 P-GW로 상향 트래픽이나 글귀로는 하향 트래픽이라고 되어 있어서요.
이영준님,
5)번 과정은 하향으로 S5 베어러 (베어러: 사용자 트래픽이 다니는 경로)가 생성되는 과정입니다.
지금은 초기 접속 중이라 베어러가 생성되어 있지 않아 아직 사용자 트래픽은 다닐 수 없습니다. 사용자 트래픽이 다닐 수 있는 길 (즉, 베어러)을 만드는 제어메시지 처리 단계로, 이 시그널링 과정을 통해 베어러가 만들어지고 나면 사용자 트래픽이 다닐 수 있게 됩니다.
그리고 베어러는 방향성이 있어 상향 베어러와 하향 베어러가 있습니다. 흔히 S5 베어러가 생성된다는 것은 하향 S5 베어러와 상향 S5 베어러가 생성된다는 것을 뜻합니다.
4)번에서 S-GW가 S5 S-GW TEID (즉, 하향 S5 TEID)를 할당하고 이를 Create Session Request 메시지를 통해 P-GW에게 전달합니다. 5)번에서 P-GW가 이 값을 수신하면 하향 S5 베어러가 생성되는 것으로, P-GW는 이 값을 후에 하향 사용자 트래픽 (IP 패킷)을 전송하게 될 때 사용합니다. (사용자 트래픽을 전송할 때 P-GW는 사용자 IP 패킷에 GTP header를 붙여서 GTP 터널로 전송하는데 하향 S5 TEID가 GTP header에 포함됩니다).
상향 트래픽을 전송하기 위해서는 상향 트래픽을 위한 S5 베어러가 만들어져야 하는데 P-GW가 S-GW에게 S5 P-GW TEID 즉, 상향 S5 TEID 를 알려주어야합니다. 이 과정이 13)번입니다. 그러면 14)번에서 S-GW가 상향 사용자 트래픽을 전달할 수 있는 상향 S5 베어러가 만들어집니다.
5)번에서는 하향 S5 베어러가 생성되었고 13)번에서는 상향 S5 베어러가 생성되었으므로, 13)번 단계에서 S5 베어러 생성이 완료됩니다.
넘길게쓴듯..
감사합니다~
친절한 설명 감사합니다.
제가 이해한것이 맞는 지 확인부탁드립니다. S-GW는 P-GW에게 하향 S5 베어러는 이것을 사용해라라는 의미로 "S5 S-GW TEID"를 보내고, P-GW는 S-GW에게 상향 S5 베어러는 이것을 사용해라라는 의미로 "S5 P-GW TEID"를 보내는 것이라고 이해하면 되는지요.
제가 이해한 것이 맞다면 그림 10. Procedure for EPS Session Establishment(1) 에서 14번 과정의 "Receive S5 TEID(DL)"은 "Receive S5 TEID(UL)"이 되어야하 하는 것 아닌가요?..? ^^
그리고 이 내용과 관련없지만 EPC(Evolved Packet Core)내에서 AF(Application Function)이 어떤 녀석인지 참고할수 있는 문서나 간략한 설명 부탁드립니다. "3GPP TS 23.203"을 통해서 AF에 대한 설명을 확인하였지만 여기서 의미하는 application이 무엇인지, 실제 UE에서 사용되는 application을 의미하는 것인지 궁금합니다.
감사합니다.
상향, 하향 헷갈려서 저는 이렇게 생각합니다. 상향 하향은 기지국과 UE간에는 UE기준으로 내려 받느냐. .올려주느냐로 안 헷갈리는데... 다른 NE들에 대해서는 좀 헷갈리죠.
상향(UL): PDN 방향의 트래픽
하향(DL): UE 방향의 트래픽
으로 생각하면 편할거 같아요.
그림 10.의 14번 과정에 "Receive S5 TEID(DL)"은 "Receive S5 TEID(UL)"로 되는게 맞습니다.
5.1 설명을 보면 LTE 마스터키만 commissioning 정보고, 그외는 다 provisioning 정보같은데....
영영 사전을 보면
commission: formally arranged
provision: making it available to people who need or want it
로 정의하고 있는데, LTE 규격에서 provisioning data와 commissioning data를 구분하는 기준이 LTE Identification I: UE 및 ME식별자 문서에서 기술된 바와 같이 생성 시점에 따라, 설치시 제공하면 commissioning 설치후 서비스 운영전이나 운영중에 사업자가 제공하는 data면 provisioning으로 보면 되는지요?
Commissioning/Provisioning 용어 정의는 LTE 표준과 무관한 것으로 알고 있습니다.
안녕하세요.
우선 이런 보물 같은 자료를 공유해주셔서 정말 감사드립니다.
사이트에서 여러가지 자료를 보면서 조금씩 개념을 잡아나가고 있는데요.
내용을 보다가 의문점이 생겨 설명을 좀 부탁드리고자 합니다.
ECM연결설정의 RRC connection complete가 SRB1을 통하여 전달된다고 하셨는데
아래 링크를 보면 SRB1은 Ciphering과 Integrity protection과정을 거치게 되어 있습니다.
AS Security Setup이 되지 않은 상태에서 SRB1을 통하여 메시지 전달이 될 수 있는건가요?
https://www.netmanias.com/ko/?m=view&id=oneshot&no=5687&page=8