Large Scale Beamformer idea?..

large scale beamformer를 어떻게 더 효율을 높일지에 대해서 아이디어를 내보란다. 뭘 어떻게 해야하나?

기본적으로 beamformer의 모든 element에 대한 channel response를 다 알고 있다고 가정하자. 이런 경우에 statistically minimum error를 갖는 솔루션은 이미 알고 있다. MMSE라고 불리우는, 쉽게 말해 least square problem을 푸는 해답 중에 statistically minimum error를 내는 해 말이다.

문제는 이게 계산하기가 좀 빡시다는 거다. 왜냐면 행렬의 크기가 너무 크니까. 역행렬을 구해야 하는 단계가 있는데 역행렬의 크기가 너무 크다. 이걸 매우 빈번히 계산해야 하는데, 또 그렇게 빈빈히 계산하지 않으면 효과가 없고 또 그렇게 빈번히 한다고 하더라도 시간에 따라서 역행렬을 구성하는 내용물의 값이 계속해서 바뀌기 때문에 따라가기가 괴로울 정도로 복잡하단 거다.

또, 계속해서 추적하면 좋겠는데, 데이터를 찔끔 찔끔 간헐적으로 보내오는 경우도 많다는 거다. 원래 이런 시스템에서는 데이터가 끊임없이 날아와서 어떤 추정기의 정확도가 시간이 감에 따라 점점 향상되는 그런 모습이 되어야 하는데, 이놈의 스케줄러가 나 하나만 스케줄링 하는 게 아니라 다른 놈들도 같이 스케줄링 해야 하니까 데이터가 끊임없이 일정하게 날아가게끔 하지 않는다.

또 데이터라는 게 간헐적으로 요구되고 있기 때문에 또 들어오는 것도 한꺼번에 쫙 균일하게 들어오는 게 아니라 그렇게 된다. 따라서 한동안 데이터가 없었다가 생겨나면 또 새롭게 모든 작업이 일어나야 되는 거다. 이 모든 실질적인 조건들을 생각하다보면 도무지 이렇게 복잡한 시스템을 왜 만든 것인가 하는 생각을 하게 된다. 과연 효과라는 것이 있겠는가 하는 생각과 함께.

일단 이 수 많은 빔포머의 엘리먼트들에 대해서 입사되는 신호가 어떻게 변형되고 있는지 전부 알아내야 하는데, 이게 별로 정확하지 않다. 쎄게 들어온 놈들만 정확하게 할 수가 있다. 알았다고 하더라도 시간이 지나면 금새 변하기 때문에 참값이 아닌 값이 되는 거다. carrier frequency가 높으면 더 그렇게 된다. 추정도 정확하지 않으니 그걸로 해를 계산한다고 한들 그게 정확할리가 있나? 아무리 통계적으로 우수한 방법을 쓴다고 하더라도 말이다.

또 되묻게 된다면, ‘그러면 이거 말고 더 좋은 방법이 있어?’ 라고 하면 할 말이 없다. 그래도 이 정도 하면 잘 나오니까 하는 거다. 그러니까 통계적으로 가장 우수한 방법으로 추정을 하고, 그렇게 추정된 값을 가지고 통계적으로 가장 우수한 방법의 해를 또 추정한다. 그 값을 적용해서 빔포밍이라는 걸 한다. 이것은 사실상 maximum SINR 방법과 같은데, 간섭/측정오차 대비 원하는 신호의 비율이 최대화 되는 방법으로 빔포머를 굴리는 거다. 여기서 문제는 간섭과 오차라는 것을 어떻게 가정하느냐에 있다.

다시 말하면 이 응용분야에서는 원하는 신호를 관찰하는 시간이 대단히 짧아서 간섭 신호라는 것 역시 관찰할 여유라는 게 거의 없다. 원하는 신호와 원치 않는 신호를 대단히 짧은 시간동안 관찰하고 간섭 신호 대비 원하는 신호의 비율을 최대화하자는 거다. 만일 내가 간섭신호를 관찰할 때 간섭 신호가 있었는데, 그 이후로는 사라졌다거나 관찰할 때는 없었는데 아닐 때는 있었다고 하면 꽝이 되는 거다.

무슨 소리냐고, 이 시스템은 철저히 pilot signal assisted라서 내가 알고 있는 신호를 전송 받아서 그것이 어떻게 왜곡되었는지, 간섭은 얼마였는지를 알아내고 그걸 바탕으로 알아낸 빔포머의 해를 가지고 나머지 내가 모르는 신호를 받을 때 써먹는 거다. 따라서 동일한 조건이 계속해서 유지되는 상황이 아니면 망해버리게 되는 거다. 사실 이래야 관찰만 하는 시스템, 해만 구하는 시스템 등등이 모두 한숨 돌릴 수 있게 되는거다. 내내 돌고 있으면 너무 힘들어서 안되는 거다. 다시 말해 여유가 전혀 없는 것이지.

그러면 이런 시스템을 개선해보자면 어떻게 해야할까?

아이디어는 몇 가지 나올 수 있지만, 모두 다 실제 상황을 고려한 타협안이고 sub-optimal할 수 밖에 없다. 물론 고객은 실제 상황이 이상적인 상황이 아님에도 이상적인 환경에서의 최적화된 해를 구하는 시스템을 원한다. 그래야 뭐라도 할 말이 있으니까. 실제 상황이 이상적인 상황이 아니니 sub-optimal한 solution을 주겠다 라든가 heuristic하게 optimal한 해를 내주는 것 같다 하는 식으로 가면 ‘이게 어디서 수작을 부리고 있어?’ 하게 되는 거다. 어차피 고객한테 먹히지도 않을 거 이 따위 아이디어 왜 내느냐 할 수 있지만 별 수 없지 않은가?

어줍잖은 아이디어를 내고 이 아이디어는 특정 조건에서 최적의 해를 구하는 방법이다 라고 증명하는 방법도 있을 것이다. 하지만 generic하게 optimium solution을 주는 게 아니면 또 욕을 먹을 수 밖에 없다.

그러니까 교과서에서 나올 법한 정답을 내는 게 사실 엔지니어 입장에선 가장 쉽다. 계산하기도 쉽고 만들기도 쉽다. 그냥 딱 정답이다 라고 생각하면 가면 되는 거다. 그런데 실상에 적용하면 실상이 이상적인 환경이 아니니까 원하지 않는 결과를 내게 된다. 어차피 원하는 결과라는 것도 실제로 얻을 수 없는 것이니까 이상과 현실이 너무 떨어져있는 거다. 고객한테도 그렇게 얘기하면 거기까진 이해한다. 엔지니어가 어려운 지경에 빠지는 것은 ‘거기서 더 잘 할 수 없어?’라고 하는 질문을 받을 때다. 거기서 더 잘할 수는 있지만 이게 늘상 그렇게는 안된다는 거다. 특정 조건에 대해서 좋은 답이 될 뿐이지 늘상 좋은 답이 되진 못하니까. 또 좋아지는 게 있으면 나빠지는 게 있다라는 것을 엔지니어는 직관적으로 너무 잘 안다. 만일 모든 게 다 좋아진다라고 말하면 그것은 거짓말일 확률이 100%가 된다.

이를테면 값싸게 만들었으면서도 성능까지 좋다라고 하면 뻥이 확률이 높다. 이 때는 확 좋아지는데 다른 때도 다 좋아진다 역시 뻥이다. 만일 이게 뻥이 아니면 여태 다들 엉터리로 만들었단 말 밖엔 안된다.

그러니까 새로운 아이디어를 내라는 것은 suboptimal한 걸 해보라고 하는 것이든가 아니면 optimal한 것에 일종의 tradeoff를 해서 좀 덜 나빠지면서도 아니면 거의 안나빠지면서도 좀 더 간단하게 만들 수 있게 한다거나 전력소비를 좀 더 줄여볼 수 있다 이런 식의 논리가 성립되어야 한다. 아니면 너무 조건이 tight하게 들어가있는데 이게 실제로 이 정도로 tight하지 않기 때문에 그 조건을 완화시켜서 더 싸게 만들어 볼 수 있게 된다든가.

그러니까 싸게 만드려니까 애초에 헛점이 있는 걸 만든다고 한다든가 (그래도 값이 싸지거나 덜 어려워지니까 혹은 다른 면이 좋아지니까) 아니면 있는 것에서 헛점을 찾아서 보완한다든가 한다든가 아니면 아예 전혀 다른 분야에 적용할 수 있게 한다든가 하는 아이디어를 낼 수 밖에 없다.

또 다른 것으로는 하드웨어 아이디어를 내보는 거다. 어떻게 만드느냐에 대한 아이디어는 자유도가 높다. 그렇다보니 suboptimal한 걸 한다고 하기보다 optimal한 걸 어떻게 만들겠는가에 대한 아이디어가 더 먹힐 수 밖에 없다.

요약하면, 다음과 같은 우선 순위로 뭔가를 해볼 수 있다.

1. optimal한 solution을 어떻게 만들 수 있을까에 대한 아이디어를 내본다.
2. 위의 내용을 어떻게 확장할 수 있을지 아이디어를 내본다.
3. suboptimal한 아이디어를 내본다.
4. suboptimal한 것을 어떻게 구현할 수 있을지 아이디어를 내본다.
5. 위의 내용을 어떻게 확장할 수 있을지 아이디어를 내본다.

한 가지 아이디어를 가지고 위처럼만 해도 5가지로 분량 늘리기가 가능하다.