Rex Mundi

https://dojang.io/mod/page/view.php?id=472

아니 C, C++을 몇년을 해먹었는데 이걸 몰랐다고...?

근데 정말로 쓰는걸 본 적이 없음; 내가 프론트 엔드 개발자였다니 그럴리 없어!

아마 앞으로도 볼 일이 별로 없을 것 같긴 한데 일단 알아는 둬야겠다.

1비트까지 쪼개쓰는 환경의 코딩에서는 당연하게 쓰이는 모양.

https://edykim.com/ko/post/c-operator-overloading-guidelines/

https://boycoding.tistory.com/112

https://lsea.tistory.com/247

LTE FDD, TDD 개요 / TD-LTE에 대한 오해와 진실 [출처] LTE FDD, TDD 개요 / TD-LTE에 대한 오해와 진실|작성자 초코버리

http://blog.naver.com/PostView.nhn?blogId=johnlee08&logNo=166405782

Packet Scheduling

11/11

p.21

UE1 is close

UE2 is far

Fair Throughput

Fair Time

-> Channel Condition을 고려하지 않았다 (fluctuation 하는데...)

SINR = C/I

p.23

Channel-aware 스케줄러가 있다: 채널 피드백이 필요하다

Max scheduler는 Fairness를 보장하지 않는다

p.24

PF Scheduling

p.28

CDRX

p.29

Semi Persistent Scheduling (SPS)

eNodeB는 이니셜 블럭을 준다

유저는 리소스 블럭을 priodically 하게 받는다

p.6

Inter-cell Interference (ICIC)

Cell Interior User is fine

Cell boundary User is not fine

UE3은 신호상태가 좋지만 UE1,2는 간섭 문제가 심각하다.

SINR이 쎄다

솔루션1

셀 엣지에는 exclusive 주파수를 갖게하고 중심부는 같은걸로 함

(fractional frequency reuse / selective frequency reuse)

혹은 중심부 파워를 낮추고 주위를 높임

(selective power reuse)

----

11/6

p.21 스케쥴링

fairness도 중요해

p.22

스펙트럼 효율과 공평성을 동시에 만족해야되

p.23

채널-언어웨어

FIFO, 라운드 로빈, 블라인드 이퀄 쓰루풋, 맥스-민 스케줄러

채널-어웨어 스케줄링

UE1니 UE2보다 항상 better condition일 때를 생각해야 됨 (Propotional fair sceduling)

프로젝트로 해야된다! 알고리즘은 간단하다.

p.25

LTE overview

퀄넷에서 LTE 관련된서 설치해보고...

download LTE open source

p.4

p.5

PDCP RLC MAC (L2)

RRC (L3) control plane / no user plane

p.7

Physical Downlink Shared CH: 리얼 데이터

Physical Downlink Control CH: 콘트롤 데이터

PDSCH

PDCCH

p.15

RB는 단위

----

9주차 #2

p.4

Dynamic Resource Allocator

p.5

Control Plane 5 layers

User Plane 4 layers

p.6

SDU (Service Data Unit)

PDU (Protocol Data Unit)

헤더가 붙으면 PDU 아니면 SDU (PDCP 그림에 나오는 [H]는 아마 윗단계에 보이는 헤더일 것)

p.7fine

트랜스포트 채널

1 user 만 assigned data 를 받을 수 있다.

p.8

업링크 채널

Random Access CH

Pysical Uplink

p.9

HARQ vs ARQ

보통 ARQ는 많은 통신 시스템에 쓰임

보통 ARQ 시나리오: NAK (Negative ACK)오거나 안오면 재전송(Retransmission) ACK 돌아오면 굳

Hybrid ARQ 시나리오: P1A를 보내서 NAK오거나 안오면 P1B를 보냄 P1B를 받은 쪽은 P1A랑 합성요

p.10

UE->NB->RNC 2 hop

UE->eNB 1 hop

p.10.5

user plane 이라서 RRC는 없엉 (control plane 에만 있음)

Retransmission 에는 한계치가 있음 (보통 8번 안받으면 끝)

p.11

UM: 리트랜스미션 없엉. 멀티캐스트에도 리트랜스미션은 없다

AM: 

TM

p.14

디코딩 확률이 올라갑니다 (HARQ)

p.15

무선 리소스는 프리퀀시-타임 도메인 안에 있음

1 Resource Block = 180 kHz * 0.5 ms (s 아님 타이포)

1 subframe = 2 slot

LTE frame = 10 frame or 20 slot

p.16

7 symbol = slot

14 symbol = subframe

이 그림은 2 resource block 이다.

퍼런거 PDSCH

노란서 PDCCH

p.18

Addaptive Modulation Coding

SINR에 의해 결정된다. (Signal to Interference plus Noise Ratio)

coding rate

1/5 는 5번 재전송하는거 (에러날 수 있으니까)

Broadcasting 에는 worst case가 쓰인다.

오프로드: WLAN은 스펙트럼이 무료라서 많이 쓰고싶고 비싼 대역망은 줄이고 싶으니 offload를 합니다.

핸드오버: 소스랑 타겟 eNodeB가 서로 교환. GSM에선 핸드오프 딜레이가 컸는데 (2~3초 이상; actually disconnected) LTE는 소프트 핸드오프보다 나을 정도다.

p.64

미디어 독립적 핸드오버: 좋은 컨셉인데 안써

p.9

IMS는 보이스나 비디오를 지원. 리얼타임 트래픽 패킷 스위칭 네트워크.

p.19

CSFB

p.21

VoLTE

서비스 프로바이서가 3G랑 LTE를 다 가지고 있으면 전환 가능한게 좋지

볼테를 쓰려면 IMS를 SIP 프로토콜을 통해 쓰고 QCI는 1이다.

p.22

두 시나리오를 비교하면 VoLTE는 목소리도 LTE로 감

p.23

IMS

p.42

스피치 코덱

G.729 10바이트 헤더보다 다른게 더 커...

p.45

복습

p.6~7

모든 라디오 프로토콜은 eNodeB에서 관리함

컨트롤 플레인과 유저 플레인으로 이뤄져있다.

LTE 시스템은 [플랫 아키텍처]를 씁니다. No central point like RNC

p.8~

MME는 모바일리티를 컨트롤한다.

HSS는 모든 유저 정보를 관리한다. (데이터베이스)

S-GW는 모든 패킷

P-GW는 IP어드레스

p.10~

AS는 UE, MME

NAS: 네트워크 컨트롤. 시큐리티

RRC: BS쪽. 라디오 컨트롤 메시지.

유저 플레인에는 없음.

p.14

3G에는 IP가 없지만 LTE는 전부 IP 기반이다.

p.21

HetNet과 InterRAT의 차이 정정: 서비스 프로바이더가 아니고 서비스 종류.

InterRAT은 다른 테크놀로지를 사용. (ex: 3G, Wifi)

같은 대역폭을 사용하면 인터피어런스가 문제.

작은 셀들은 프레임을 읽어야되! 큰 셀에서 빈 서브프레임을 요청.

작은 셀들끼리 인터피어런스가 일어나면? 그건 앞으로의 리서치(확정된 솔루션은 없는듯?)

p.22

릴레이

유사한 문제.

타입1 릴레이(인밴드 릴레이)

릴레이 노드는 인터넷에 다이렉트 링크가 없다.

D2D: LTE. 다이렉트 커뮤니케이션. 역시 스펙트럼이 모든 공통된 문제.

M2M: Zigbee. 비슷해보이지만 매우 달라. 센서 네트워크처럼 일반적인 머신들 간의 문제.

디바이스 투 디바이스

머신 투 머신

What about wifi direct? D2D라도 이건 그냥 와이파이고

D2D는 LTE 시스템, LTE 스펙트럼에서 일어나는 일.

M2M은 넓은 네트워크상에서 일어나지만 D2D는 항상 one cell area 안에서 일어남.

----

p.28

IP

IP 빅이슈는 어떻게 트래픽을 나눠? LTE 시스템은 엄청 트래픽이 많은데 어떻게 offload 하지?

p.29

Local IP Access

펨토셀에서 유저 이큅먼트가 UE로 데이터를 로컬 IP로 보냄

이게 왜 솔루션이 되지?

p.30

SIPTO

L-PGW가 하나 더 있네요. 어떤 데이터는 이쪽으로 가는데 기준이 뭐지?

p.31

WLAN Offloading

일부는 LTE 시스템 일부는 Wireless LAN으로 간다.

어쨌건 중요한건 트래픽을 분할한다는 것. 나눠서 보내는게 중요.

L2 모바일리티

P.33

인트라-프리퀀스 핸드오버(주파수내 넘겨주기)

핸드오버 = L2 핸드오버.

L3 핸드오버는 안써요.

이동하면 IP는 안바뀌고 L2 레이어에서 바뀌는거임.

(1) 이웃 BS에서 신호를 받음. BCH(브로드캐스팅 채널)에서 받아옴.

(2) 원래 BS에 연락을 줌.

(3) 그게 어딘데? 그 BS의 ID를 주게

(4) 여기영...

p.34

어떻게 넘겨주는가

BS들끼리 네고시에이트함.

MME가 스위칭

p.35

핸드오프 준비

p.36

핸드오버 실행

p.37

핸드오버 타이밍

[마진]이 있어야되. 안그럼 주고받고 주고받고 [핑퐁 프라블럼]

소스 셀/타겟 셀이 충분히 떨어져있을 때 핸드오버가 일어나야지.

= 타겟 셀로부터 오는 신호가 소스 셀보다 충분히 커졌다

p.40

모바일리티 in idle state

트래킹 에어리어: MME에서 업데이트됨.

아이들 모드에서는 핸드오버 안일어나요

버스타고 수원에서 서울 가는데 승객들이 한꺼번에 핸드오버하면 오버헤드가 크잖아.

p.41

Inter-RAT 핸드오버

p.42

UTRAN과 E-UTRAN의 비교

p.43

모바일리티 in ECM-IDLE

셀 셀렉션 (UE가 아이들 모드일 때)

PLMN는 유니크 네트워크 ID 같은거? 사업자의 네트워크 식별번호

L3 모바일리티

p.46

IP 어드레스는 보통 장소에 디펜드.

특정 유저를 위해 라우팅 테이블을 바꿔주지 않아...

IP 어드레스는 모바일리티를 지원하지 않습니다. 중요!

p.47

모바일 IP에서는 모바일리티가 서포트 됨.

각 노드는 두 개의 어드레스를 가진다. 퍼머넌트 IP하고 케어오브 IP.

p.52

홈 에이전트가 퍼머넌트/케어오브 어드레스 갖고있음.

근데 90년대에 이 테크닉이 개발됐는데 아무도 안씀. (!!!)

p.53~54

프록시 모바일 IP

같은 Access Network 안에서는 L2 모바일리티만 일어나. IP가 바뀔 필요가 없어.

멀리 옮기면 그냥 IP 바꿔주면 되잖아. IPv4에서는 어차피 IP 수가 적어서...

모바일리티 for wifi

p.59

와이파이는 모바일리티를 별로 케어 안한다.

다만 서비스 프로바이더들이 요즘 신경씀.

p.61

802.11k, 802.11r 에서 AP간에 핸드오프.

802.21는 이종간에 핸드오프.

p.63

미디어 독립적 핸드오버 (802.21 MIH) 그런데 이 그룹도 지금 안액티브함.

----

MME랑 GW는 네트워크 상에 있는 일종의 라우팅 장비같은건가?