Two-step RACH
on
11월 회의 때 나온 얘기인데 이 주제로 파는 것만으로도 박사 논문 하나 나올 수준이라 그럴 노력이나 열정같은 것은 없고 그냥 간단한 배경설명에 당장에 궁금한 것들에 대해서만 좀 생각하며 적어본다. 여기서 단말과 기지국이라 함은 WAN의 단말 (UE:User Equipment)과 기지국 (NodeB/eNB/gNB/basestation)을 의미한다.
배경
RACH에 대해서 아예 모르는 사람들이 있을테니 간단히 적어보면, 단말이 네트워크에 들어올 때 네트워크에 처음으로 인기척을 하기 위해 사용하는 채널이라고 말하면 될 것 같다. 시험용 단말이라든가 네트워크 모니터링을 하는 장비가 아닌 이상엔 네트워크에 들어와서 돌아가는 정황 (MIB/SIB)을 살피고 그 다음 인기척을 하게 되는데, 그 때 처음으로 날려보내는 게 RACH를 통한 메시지 되겠다.
msg1
3G까지만해도 RACH는 두 부분으로 되어있었다. 첫부분은 ‘야호!’ (이걸 preamble이라고 한다), 두번째 부분은 ‘쏴라있네~’ (msg1) 라고나 할까. 그러니까, 첫부분은 기지국한테 일단 주의를 환기시키는 용도이고 두번째는 대략 어떤 놈인지 구별을 하게 해주는 용도라고 보면된다. 이게 4G에 와서 한개가 되었다. 인기척과 동시에 대충 어떤 놈인지 구별을 하게끔 했단 얘기다. 왜 적어도 어떤 놈인지 기지국이 구별을 해야 하냐면 그에 상응한 응답을 보내줘야 하기 때문이다.
이를테면 여러명이 거의 유사한 시점에 ‘야호~’ 했다면 잘 알아 들었다고 메아리를 보낼 때 적어도 누구 목소린지 구분은 되게 해줘야 하니까. 그러니까 기지국이 알아들은 ‘야호~’에 대해서는 그에 상응한 응답을 보내줘야 그 응답을 받은 놈이 다음 절차로 진행할 수 있다. 이걸 대개 msg1이라고 한다.
four-step? two-step?
이런 식으로 단말이 네트워크에 인기척을 하는 방법은 그 단말이 네트워크로부터 ㅇㅈ받는데 까지 4단계가 소요된다.
야호! (msg1) –> 메아리 (msg2/RAR(Random Access Response)) –> RRC connection request(msg3) –> RRC connection setup(msg4)
RRC(Radio Resource Control)라고 하는 것은 흔히 Layer 3 또는 higher layer라고 부르는 것으로 3G/4G/5G 기지국의 프로토콜 스텍으로 보면 3층에 있는 프로토콜 되겠다. 그러니까 이 RRC라는 무선자원 (주파수/시간 자원)을 관리하는 것인데 해당 기지국이 어떤 단말을 받아주고 말고를 결정한다. 물론 그 조건은 3층에서도 결정할 수 있지만 그보다 더 높은 layer에서도 그만의 조건으로 결정하게 된다만, 일단 RRC까지 올라갔단 것은 적어도 무선 신호상으로는 ㅇㅈ했단 것이다.
RRC는 connection request를 받고 윗단과 연락을 취해서 해당 단말을 받을 수 있는 놈인지 아닌지 확인해본다. RRC connection request에는 단말의 고유한 아이디 (처음엔 IMSI:international mobile subscriber identifier)를 넣어서 보내기 때문에 기지국은 이걸 받고 해당 사업자의 HLR에 등록되어있는 단말인지 확인하고 받아줄지 말지를 결정해서 RRC에 알려주면 RRC가 그것을 단말에게 알려준다. 받아주는 경우에는 RRC connection setup msg에 기지국을 포함한 네트워크에 대한 정보, 그리고 기지국과 통신하기 위한 각종 정보 꾸러미가 배달되고 그렇지 않은 경우는 거부당했다는 메시지가 달랑 날아오게 되어있다.
그래서 4단계 되시겠다.
two-step RACH는 이걸 2단계로 줄이겠단 의미 되겠다. 그러니까, 한방에 RRC connection request까지 가고 기지국은 그것을 가지고 한방에 RRC connection setup을 내려보내는 것이다. 대충 이걸 msgA/msgB라고 부르는 것 같다.
how?
3G에서는 “야호!”에 내가 누군지에 대한 대략적인 정보가 생략되어있었기에 곧바로 실제적인 msg1 (나에 대한 대략적인 정보)는 그 다음에 실어보냈다. 4G/5G에 와서는 적어도 “야호!”에 내가 누군가에 대한 대략적인 정보를 날려보낼 수 있었는데, 여기에 곧바로 msgA를 붙여보내면 two-step RACH가 가능해진다고 보는 것이다. 즉, 3G처럼 단말은 preamble + msg를 날려보내지만 실상은 4 step approach의 msg1 + msg3를 한꺼번에 날려보내서 msg2를 받는 과정을 뛰어넘어 4단계를 2단계로 만들겠다는 것이다.
실제로 msg2를 수신하게 하는 과정이 나름 쉽지 않고 여기에서 참 많은 고충이 뒤따랐고, 이 과정때문에 네트워크에 붙는 시간 지연이 제법 있었으니까 말이다 (물론 3G와 비교하면 4G는 장족에 발전을 했다만).
Practial issue in physical layer
무선 통신에서 어차피 윗단은 물리계층에서 문제만 해결되면 쉽사리 흘러가는 것이니까 physical layer에서 이걸 어떻게 해결해야 하느냐가 가장 중요한 문제가 되겠다.
step 2를 건너 뛰는 것으로 인하여 일단 초기 전송과정에서 문제가 되는 것은 단말이 상향링크(단말->기지국 방향의 링크)에 대해서는 시간적으로 기지국과 완벽히 동기가 되지 않아서 메시지가 예상했던 시점보다 늦게 들어올 수 있다는 것이다. 어차피 preamble은 그것을 감안하여 시간적인 여유를 충분히 두고 있지만 메시지는 일반적인 상향링크의 데이터를 전송하는 곳으로 보내지게 되는데, 일반적인 경우 이 부분은 기지국과 시간적으로 충분히 동기가 맞았다고 가정하고 있는 부분이므로, 분명히 늦게 도달하게 될 메시지 (셀의 외곽에 있는 사용자라든가)를 수신할 수 있는 방법을 강구해야 한다.
표준 결정과정에서도 round trip time (RTT)가 cyclic prefix를 넘어서는 경우에 대한 성능 보완에 대해서도 gNB implementation으로 극복(?)할 수 있겠다는 뉘앙스의 의견이 있다. 결국, 기지국은 해당 메시지의 수신자원을 별도로 할당해서 대응해야만 한다는 결론이 나온다.
- 정상적인 시간에 수신되는 경우는 기존의 자원을 그대로 활용해서 수신함
- 정상 범위를 넘어서는 시간지연이 있는 경우에도 수신할 수 있도록 추가적인 자원을 할당해서 수신함
다시 말해서 CP에서 2xCP구간을 커버하는 별도의 수신기 자원이 요구되는 것이다. RTT가 CP를 넘어서는 경우를 보면 대략 기지국과의 거리가 700m 이상으로 벌어지게 되는 경우이다. 그런데 대략 msgA를 수신하려는 SNR target은 0 dB 아래의 구간으로 CP를 넘어서는 것으로 인해 발생할 성능 손실의 정도가 크게 민감한 정도인지 아닌지는 다소 애매한 측면이 있다. 다시 말해서 별도의 수신기 자원을 할당해서 커버를 할만큼의 이득이 있는지 여부는 애매한 측면이 있다는 것이다.
Preamble sigature가 cell마다 다르게 잡히기 때문에 인접셀 UE의 msgA를 수신할 수는 있다고 하더라도 preamble은 수신하지 못 할 것이므로 그것이 connection procedure에 영향을 줄 수는 없다.
Summary
- Two step RACH:
- RRC connection request를 preamble 바로 다음에 전송 (msgA라고 함)하고 기지국(gNB)으로 부터 RAR+RRC connection setup을 받으면 초기 setup이 완료되므로 two-step이 됨
- 기술적인 문제점:
- timing sync (흔히 TA: timing advance)가 잡히지 않은 상태에서 PUSCH로 message를 전송하므로 CP 구간을 벗어나 전송하는 경우가 발생
- 1차적인 해결 방법
- CP외 구간으로 수신되는 경우를 고려하면 추가적인 성능이득을 얻을 수 있으므로 기지국에서는 이 경우도 같이 고려해야 함. 즉, 기존 receiver + x2 CP receiver가 필요함
- payload가 작거나 혹은 할당되는 resource의 개수가 늘어나는 경우는 상대적으로 required SNR이 낮아지게 되므로 별다른 이득은 없음
- 또, 동일한 FFT로 처리되는 인접 PRB의 UE들이 SNR이 높은 경우(modulation order가 높은 경우)에는 이들과의 orthogonality 문제로 인한 간섭으로 성능 저하가 발생하므로 항상 성능개선이 이루어진다고는 볼 수 없음
- 결국, 수신과정은 두 가지 경우 (normal CP, x2 CP) 모두 try해서 CRC ok나는 것을 취하게 됨. 즉 정상적인 경우를 먼저 try해서 CRC ok가 얻어지면 나머지는 try하지 않고, 그렇지 않으면 try하는 방법을 택하게 됨