요약
- RFC 3753는 '핸드오버'를 하나의 자명한 동작이 아니라 일련의 이벤트 계열로 다루었다. 문서는 제어와 타이밍을 분류하는 대체로 독립적인 다섯 가지 축을 제시하고, 별도로 이동의 범위를 정의했다.
- '빠름', '부드러움', '원활함'은 동일한 결과를 약속하지 않았다. 첫 번째는 지연을, 두 번째는 패킷 손실을, 세 번째는 특정 애플리케이션이나 사용자가 인지할 수 있는 서비스 변화를 강조했다.
핸드오버에는 형용사 하나로는 부족했다
한 전화기가 액세스 포인트에서 다른 액세스 포인트로 이동한다. 무선 링크가 바뀐다. 라우터는 바뀔 수도, 바뀌지 않을 수도 있다. 네트워크는 이동 전에 경로를 준비할 수도, 이동 후에 대응할 수도 있다. 단말은 시점을 스스로 정하거나 측정값을 제공하거나, 단순히 네트워크의 결정을 따를 수도 있다. 패킷은 잠시 멈추거나 사라지거나, 기존 경로와 보안 특성이 다른 경로로 도착할 수 있다.
이 모든 것을 통틀어 '핸드오버'라고 부르는 것은 두 설계를 비교하기 전까지는 편리하다. 어떤 엔지니어는 액세스 포인트 간 레이어 2 전환을 뜻하고, 다른 엔지니어는 새로운 IP 접속을 뜻할 수 있다. 제품 팀은 트래픽이 빨리 재개된다는 이유로 전환을 '빠르다'고 부르는 반면, 애플리케이션은 패킷을 잃을 수 있다. 대시보드는 보안 강등이 사용자에게 중요한 의미를 가질 수 있음에도 '원활한(seamless)' 전환으로 표시할 수 있다.
RFC 3753,Mobility Related Terminology는 이런 대화를 더 정확하게 만들려 했다. 2004년 6월에 Informational RFC로 발표된 이 문서는 컨텍스트 전송, 핸드오프 후보 발견, 휴면 모드 호스트 알림을 함께 다루던 IETF Seamoby 워킹 그룹에서 나왔다. 저자들은 다른 모빌리티 그룹들도 이 용어 체계를 활용할 수 있기를 바랐다. 또한 이 문서가 새 용어를 만들거나 모든 정의를 확정하려는 것이 아니라고 명확히 밝혔다. 이는 수정에 열려 있는 협력적 첫 걸음이었다.RFC 3753, 초록 및 §1
그 겸손한 지위 자체가 역사의 일부다. 이 RFC는 공유 좌표계를 제공했을 뿐, 핸드오프 절차를 표준화하지 않았고, 구현이 모든 라벨을 사용하도록 요구하지도 않았으며, 워킹 그룹들이 용어집을 일관되게 채택했다는 증거도 제시하지 않았다.
하나의 '핸드오버 유형'이 아니라 다섯 가지 제어 질문
RFC 3753는 다섯 가지 핸드오버 분류가 '대체로 독립적'이며 각 핸드오버는 이 모든 축을 따라 분류될 수 있어야 한다고 설명했다. 이 표현이 중요하다. 이들은 경쟁하는 다섯 가지 프로토콜 설계가 아니라 사례를 서술하기 위한 차원이다.
| 질문 | RFC 3753의 구분 |
|---|---|
| 누가 첫 결정을 내리는가? | Mobile-initiated 또는 network-initiated |
| 누가 주도 제어 권한을 가지는가? | Mobile-controlled 또는 network-controlled |
| 누가 유용한 측정값을 제공하는가? | Mobile-assisted, network-assisted 또는 unassisted |
| 준비와 개시는 어느 쪽에서 이루어지는가? | 기존 액세스 라우터를 통한 push, 또는 새 액세스 라우터를 통한 pull |
| 사전 신호 교환이 가능했는가? | Planned 또는 unplanned |
첫 두 질문은 쉽게 섞이지만 섞으면 안 된다. 단말이 최초 결정을 내리면서도 실행에 대한 주도 제어 권한은 네트워크에 남아 있을 수 있다. RFC의 세 번째 구분은 지원(assistance)에 관한 것이다. 단말의 측정값이 액세스 라우터의 결정에 반영될 수도 있고, 액세스 네트워크가 단말을 위해 정보를 수집할 수도 있으며, 어느 쪽도 상대를 지원하지 않을 수도 있다. 문서는 단말과 라우터가 모두 측정하고 결정하는 경우도 허용한다.
push와 pull은 또 다른 관계를 서술한다. 준비가 기존 액세스 라우터(PAR)에 의해 시작되거나 그를 거쳐 이루어지는지, 아니면 새 액세스 라우터(NAR)를 거치는지를 나타낸다. planned와 unplanned는 단말이 새 라우터에 접속하기 전에 신호 교환이 가능했는지를 나타낸다. planned된 이동은 사전 임시 터널을 허용할 수 있지만, 예기치 않은 이동에는 그런 사전 교환이 없다.
이 라벨들은 서로 다른 질문에 답한다. 'network-initiated'는 단말과 네트워크 중 누가 절차를 제어하는지 알려 주지 않는다. 'mobile-assisted'는 어느 라우터가 준비를 시작하는지 알려 주지 않는다. 'planned'는 이동이 성공한다는 뜻이 아니다. 이 다섯 부분으로 이루어진 서술은 결정자, 제어자, 정보 출처, 신호 방향, 시점을 한 단어로 압축하려는 유혹을 막는다.RFC 3753, §4.2
RFC는 별도로 이동의범위를 분류했다. 레이어 2, 하나의 액세스 라우터 내부, 하나의 액세스 네트워크 내부, 액세스 네트워크 간, 기술 간이 그것이다. 또한 수평 핸드오버와 수직 핸드오버를 구분하면서도 이 경계가 모호할 수 있다고 경고했다. 두 WLAN 유형 사이의 변경은 관찰자의 관점에 따라 수평일 수도 수직일 수도 있으며, 하나의 라우터가 IP 주소나 인터페이스를 바꾸지 않고 서로 다른 액세스 기술을 관리할 수도 있다. 이 분류 체계는 무선 지도와 IP 지도의 경계를 강제로 일치시키지 않았다.RFC 3753, §4.1
빠름, 부드러움, 원활함은 서로 다른 질문에 답한다
가장 오래 지속된 구분은 성능 용어에 나타난다. RFC 3753는 핸드오버 지연 시간을 구간으로 정의했다. 단말이 기존 액세스 라우터를 통해 IP 패킷을 마지막으로 송수신할 수 있던 시점부터, 새 라우터를 통해 처음으로 송수신할 수 있게 된 시점까지다. 이는 네트워크 계층의 타이밍 경계이지 애플리케이션 경험을 전부 재는 척도가 아니다.
'부드러운(smooth)' 핸드오버는 주로 패킷 손실을 최소화하는 것을 목표로 하며, 추가 전달 지연은 명시적으로 다루지 않는다. '빠른(fast)' 핸드오버는 주로 지연을 최소화하는 것을 목표로 하며, 패킷 손실은 명시적으로 다루지 않는다. 이 정의들이 빠른 핸드오버가 반드시 패킷을 잃거나 부드러운 핸드오버가 반드시 느리다는 뜻은 아니다. 두 단어가 서로 다른 주요 목표를 가리킨다는 뜻이다. 결과를 비교하려면 측정은 여전히 지연과 손실을 모두 보고해야 한다.
'원활한(seamless)'은 더 나아가지만 더 문맥 의존적이 되었다. RFC는 이를 서비스 능력, 보안, 품질의 변화가 없음으로 서술했다. 실질적 판단을 위해 다른 프로토콜, 애플리케이션 또는 최종 사용자가 정상 동작과 관련된 변화를 감지할 수 있는지 묻는 방식을 제안했다. 이메일 클라이언트에게 투명한 핸드오프가 지연에 민감한 통화에도 원활하지 않을 수 있다. 패킷이 계속 흐른다는 이유만으로, 보안이 저하된 세션이 RFC의 서술 전체를 충족하지는 않는다.
문서는 make-before-break와 break-before-make도 구분했다. 단말이 기존 액세스 라우터와 새 액세스 라우터에 동시에 통신할 수 있는지, 아니면 기존 연결이 먼저 끝나는지가 그 차이다. 또한 make-before-break를 매크로 다이버시티에 의존하는 '소프트 핸드오버'와 혼동하지 말라고 경고했다. 중첩, 손실, 지연, 사용자가 인지하는 연속성은 서로 관련 있지만 상호 교환 가능한 측정값은 아니다.RFC 3753, §§4.3–4.5
용어집은 성능 증명서가 아니다
RFC 3753는 실용적인 모빌리티 작업과 나란히 등장했다. 참고문헌에는 Mobile IPv4와 당시 최신 Mobile IPv6 명세, 그리고 빠른 핸드오버와 후보 액세스 라우터 발견에 관한 작업 문서가 포함되었다. 이후 standards-track 문서인 RFC 5568은 Mobile IPv6 빠른 핸드오버를 명세했다. RFC 6275는 뒤이어 RFC 3775를 대체하며 RFC 3753을 informative 참고문헌으로 인용했다. 이 연결들은 문서적 대화가 이어졌음을 보여줄 뿐, 이후 프로토콜이 이 용어집을 적합성 테스트로 채택했거나 운영자가 배포했다는 증거는 아니다.RFC 5568·RFC 6275
이 경계는 특히 중요하다. RFC 3753는 용어만 제시한다고 밝히고, 문서 자체에는 보안 문제가 없다고 말하기 때문이다. 이는 모빌리티 시스템에 대한 보안 평가가 아니다. 또한 이 RFC는 특정 핸드오버가 빠르고, 부드럽고, 안전하고, 원활했다는 증거가 아니다. 분석가가 더 좋은 질문을 던지기 위해 활용할 수 있는 구분을 제공할 뿐이며, 근거는 구현, 측정값, 영향받은 서비스에서 나와야 한다.
따라서 2004년의 기여는 새로운 프로토콜이라기보다, 여러 층위의 의미가 서로 혼동되는 일을 막으려는 시도였다. 핸드오버는 범위, 누가 개시했는지, 누가 제어했는지, 누구의 측정값이 작용했는지, 어느 라우터가 준비했는지, 사전 신호 교환이 가능했는지로 분류될 수 있었다. 그런 다음 성능은 지연과 손실로 서술되고, 실질적 원활성은 서비스와 사용자에 상대적으로 남겨졌다.
표준화 작업에서 얻을 수 있는 유용한 역사적 교훈이다. 공통된 단어는 협업을 쉽게 만들지만, 제어·측정·결과의 차이를 지워 주지는 않는다. 녹색 '핸드오버 완료' 라벨은 그것이 드러내는 질문만큼만 정보를 담고 있다.
출처
1차 기록과 연표:RFC 3753 본문,RFC Editor 기록,IETF Datatracker 기록.
범위와 비교를 위해 참조한 인접 및 이후 명세:RFC 3132,RFC 3154,RFC 3374,RFC 3344,RFC 3775,RFC 5568,RFC 5213,RFC 5944,RFC 6275. 이 참고문헌은 맥락을 제공할 뿐, RFC 3753 용어의 채택을 입증하지 않는다.
회원 브리핑
프로필 심층 컨텍스트
올바른 멤버십 등급으로 로그인하면 전체 브리핑과 출처 노트를 볼 수 있습니다.
Strategic Circle 전용
Strategic Circle
모든 독자에게 공개됩니다. 가입 후 로그인하면 프로필 브리핑를 열람할 수 있습니다.
Strategic Circle 가입하기Leadership Alliance 전용
Leadership Alliance
자격을 갖춘 IP 자산 소유자 및 운영진을 위한 콘텐츠입니다. 로그인하면 Leadership Alliance 브리핑을 열람할 수 있습니다.
Leadership Alliance 가입하기





