KR101082720B1 - 라우트 프로토콜 - Google Patents

Abstract

라우트 프로토콜이 확립되고, 그에 의해 이동 장치는 서빙 기지국을 통해 형성된 터널을 통해 다수의 (수신) 기지국들과 통신할 수 있다. 라우트 형성 헤더를 포함하는 메시지는 터널을 형성하기 위해 이동 장치에 의해 송신될 수 있다. 이동 장치가 개방-대기 상태에 있는 동안 라우트 형성 헤더는 수신 기지국에 의해 검토된다. 여러 다양한 에러들은 라우트 형성 헤더에 대하여 일어날 수 있다. 이러한 에러들은 하나 이상의 에러 코드 필드들을 설정함으로써 기지국에 의해 이동 장치로 전달될 수 있다. 일단 에러들이 해결되면, 기지국과의 터널을 형성하려는 또 다른 시도가 원하는 경우 이루어질 수 있다.

Description

라우트 프로토콜{ROUTE PROTOCOL}

본 출원은 2007년 4월 25일자로 출원된 미국 가출원 제60/913,988호, "Methods and Apparatus for Providing Route Protocol(라우트 프로토콜을 제공하기 위한 방법 및 장치)" 및 2007년 7월 12일자로 출원된 미국 가출원 제60/949,297호, "Route Protocol Design for UMB(UMB를 위한 라우트 프로토콜 설계)"에 대한 우선권을 주장하며, 상기 출원들은 모두 본원의 양수인에게 양도되었으며, 이들 출원들 전체는 참조에 의해 본 명세서에 편입된다.

이하의 설명은 일반적으로 무선 통신 시스템들에 관한 것으로, 더 상세하게는 무선 통신 시스템들에서 통신 라우트들 또는 터널들을 확립하는 것에 관한 것이다.

무선 통신 시스템들은 전 세계 대다수의 사람들이 통신하기에 이른 일반적인 수단에 되었다. 이러한 시스템들은 가용 시스템 자원들(예를 들어, 대역폭 및 송신 전력)을 공유함으로써 다수의 사용자들과의 통신을 지원할 수 있는 다중 액세스 시스템들일 수 있다. 이러한 다중 접속 시스템들의 예는 코드 분할 다중 접속(CDMA) 시스템, 시분할 다중 접속(TDMA) 시스템, 주파수 분할 다중 접속 시스템(FDMA), 직교 주파수 분할 다중 접속(OFDMA) 시스템 및 다른 시스템들을 포함한 다.

전형적인 무선 통신 시스템 또는 네트워크(예를 들어, 주파수, 시간 및/또는 코드 분할 기술들을 채택하는)는 커버리지 영역을 제공하는 하나 이상의 기지국들 및 그러한 커버리지 영역 내에서 데이터를 송수신할 수 있는 하나 이상의 이동(예를 들어, 무선) 단말들을 포함한다. 전형적인 기지국은 브로드캐스트, 멀티캐스트 및/또는 유니캐스트 서비스들을 위한 다수의 데이터 스트림들을 동시에 송신할 수 있고, 데이터 스트림은 이동 단말에게 독립적인 수신 관심대상으로 이루어질 수 있는 데이터의 스트림이다. 기지국의 커버리지 영역 내 이동 단말은 복합 스트림에 의해 운반되는 하나의, 하나 이상의 또는 모든 데이터 스트림들을 수신하는 것에 관심이 있을 수 있다. 마찬가지로, 이동 단말은 기지국 또는 또 다른 이동 단말로 데이터를 송신할 수 있다.

그러한 통신 시스템들에서, 핸드오프로서 지칭되는, 이동 단말이 인접하는 지리적 셀들 사이에서 이동할 때 중단되지 않는 서비스를 제공하는 것이 바람직하다. 그러한 이동은 중요한데, 그 이유는 중단이 품질 저하, 끊겨진 통신들, 또는 다른 바람직스럽지 못한 상황들을 야기할 수 있기 때문이다. 그리하여, 현재의 기지국으로부터 목표 기지국으로의 핸드오버들을 지원할 필요성이 있다.

이하는 하나 이상의 양상들의 기본적인 이해를 제공하기 위하여 그러한 양상들의 단순화된 요약을 제시한다. 이러한 요약은 모든 고려되는 양상들의 포괄적인 개관이 아니고, 모든 양상들의 핵심 또는 중요한 엘리먼트들을 나타내거나 임의의 또는 모든 양상들의 범위를 서술하고자 의도된 것도 아니다. 그것의 유일한 목적은 이후에 제시되는 보다 상세한 설명에 대한 서두로서 단순화된 형태로 하나 이상의 양상들의 소정 개념들을 제시하고자 함이다.

하나 이상의 양상들 및 그것의 대응하는 개시 내용에 따라, 여러 다양한 양상들이 2개 이상의 기지국들 사이의 터널들 형성과 관련하여 기술된다.

일 양상은 이동 장치와 기지국 사이의 터널 관계를 형성하기 위한 방법에 관한 것이다. 상기 방법은 터널을 통한 통신의 확립을 위하여 적어도 하나의 기지국을 선택하는 단계 및 라우트 형성 헤더(Route Creation Header)를 포함하는 메시지를 상기 적어도 하나의 기지국으로 송신하는 단계를 포함한다. 상기 라우트 형성 헤더는 터널을 정의하는 것과 연관된 하나 이상의 파라미터들을 포함한다. 상기 방법은 또한 상기 라우트 형성 헤더의 확인(confirmation)을 대기하는 단계 및 상기 확인이 수신된 경우 개방-대기(Waiting-To-Open) 상태 밖으로 전이하는 단계를 포함한다. 상기 확인은 상기 터널 관계의 형성을 표시한다.

또 다른 양상은 메모리 및 프로세서를 포함하는 무선 통신 장치에 관한 것이다. 상기 메모리는, 터널을 통한 통신의 확립을 위하여 적어도 하나의 기지국을 선택하고 라우트 형성 헤더(Route Creation Header)를 포함하는 메시지를 상기 적어도 하나의 기지국으로 송신하는 것과 관련된 명령들을 보유한다. 상기 메모리는, 상기 라우트 형성 헤더의 확인(confirmation)을 대기하고, 상기 확인이 수신된 경우 개방-대기(Waiting-To-Open) 상태 밖으로 전이하는 것과 관련된 명령들을 더 보유한다. 상기 라우트 형성 헤더는 상기 터널을 정의하는 것과 연관된 하나 이상의 파라미터들을 포함한다. 상기 프로세서는 상기 메모리에 결합되고 상기 메모리에 보유된 상기 명령들을 실행하도록 구성된다.

추가 양상은 컴퓨터-판독가능 매체를 포함하는 컴퓨터 프로그램 물건에 관한 것이다. 상기 컴퓨터-판독가능 매체는 컴퓨터로 하여금 터널을 통한 통신의 확립을 위하여 적어도 하나의 기지국을 선택하도록 하기 위한 코드들의 제 1 세트 및 상기 컴퓨터로 하여금 라우트 형성 헤더(Route Creation Header)를 포함하는 메시지를 상기 적어도 하나의 기지국으로 송신하도록 하기 위한 코드들의 제 2 세트를 포함한다. 상기 라우트 형성 헤더는 상기 터널을 정의하는 것과 연관된 하나 이상의 파라미터들을 포함한다. 상기 컴퓨터-판독가능 매체는 상기 컴퓨터로 하여금 상기 라우트 형성 헤더의 확인(confirmation)을 대기하도록 하기 위한 코드들의 제 3 세트 및 상기 컴퓨터로 하여금 상기 확인이 수신된 경우 개방-대기(Waiting-To-Open) 상태 밖으로 전이하도록 하기 위한 코드들의 제 4 세트를 포함한다. 상기 확인은 상기 적어도 하나의 기지국으로부터 패킷을 수신하는 것을 포함한다.

추가 양상은 터널을 통한 통신의 확립을 위하여 적어도 하나의 기지국을 선택하기 위한 수단 및 라우트 형성 헤더(Route Creation Header)를 포함하는 메시지를 상기 적어도 하나의 기지국으로 송신하기 위한 수단을 포함하는 장치에 관한 것이다. 상기 라우트 형성 헤더는 상기 터널을 정의하는 것과 연관된 하나 이상의 파라미터들을 포함한다. 상기 장치는 또한 상기 라우트 형성 헤더의 확인(confirmation)을 대기하기 위한 수단을 포함한다. 상기 확인은 상기 적어도 하나의 기지국으로부터 패킷을 수신하는 것을 포함한다. 상기 메시지를 송신하기 위한 수단은 상기 확인이 수신될 때까지 상기 라우트 형성 헤더를 포함하는 상기 메시지를 상기 적어도 하나의 기지국으로 재송신할 수 있다. 또한 상기 확인이 수신될 때 개방-대기(Waiting-To-Open) 상태 밖으로 전이하기 위한 수단이 포함된다.

또 다른 양상은 라우트 프로토콜을 위한 적어도 하나의 프로세서에 관한 것이다. 상기 프로세서는 터널을 통한 통신의 확립을 위하여 적어도 하나의 기지국을 선택하도록 동작가능한 제 1 모듈 및 라우트 형성 헤더(Route Creation Header)를 포함하는 메시지를 상기 적어도 하나의 기지국으로 송신하도록 동작가능한 제 2 모듈을 포함한다. 상기 라우트 형성 헤더는 상기 터널을 정의하는 것과 연관된 하나 이상의 파라미터들을 포함한다. 상기 프로세서는 상기 라우트 형성 헤더의 확인(confirmation)을 대기하도록 동작가능한 제 3 모듈을 또한 포함한다. 상기 확인은 상기 적어도 하나의 기지국으로부터 패킷을 수신하는 것을 포함한다. 또한 프로세서에는 상기 확인이 수신될 때까지 상기 라우트 형성 헤더를 포함하는 상기 메시지를 상기 적어도 하나의 기지국으로 재송신하도록 동작가능한 제 4 모듈 및 상기 확인이 수신될 때 개방-대기(Waiting-To-Open) 상태 밖으로 전이하도록 동작가능한 제 5 모듈이 포함된다.

또 다른 양상은 이동 장치와 기지국 사이의 터널 관계를 형성하기 위한 방법에 관한 것이다. 상기 방법은 이동 장치로부터 라우트 형성 헤더를 포함하는 메시지를 수신하는 단계를 포함한다. 상기 라우트 형성 헤더는 터널을 정의하는 것과 연관된 하나 이상의 파라미터들을 포함한다. 상기 방법은 또한 상기 이동 장치가 개방-대기 상태에 있는지 여부를 결정하는 단계 및 상기 이동 장치가 상기 개방-대기 상태에 있는 경우 적어도 하나의 에러에 대하여 상기 라우트 형성 헤더를 검토하는 단계를 포함한다. 부가하여, 상기 방법은 상기 수신된 메시지에 응답하여 라우트 프로토콜 메시지(Route Protocol Message)를 형성하는 단계 및 상기 형성된 라우트 프로토콜 메시지를 상기 이동 장치로 송신하는 단계를 포함한다.

또 다른 양상은 메모리 및 프로세서를 포함하는 무선 통신 장치에 관한 것이다. 상기 메모리는 이동 장치로부터 라우트 형성 헤더를 포함하는 메시지를 수신하는 것과 관련된 명령들을 보유한다. 상기 라우트 형성 헤더는 터널을 정의하는 것과 연관된 하나 이상의 파라미터들을 포함한다. 상기 메모리는 또한, 상기 이동 장치가 개방-대기 상태에 있는지 여부를 결정하며, 상기 이동 장치가 상기 개방-대기 상태에 있는 경우 적어도 하나의 에러에 대하여 상기 라우트 형성 헤더를 검토하는 것과 관련된 명령들을 보유한다. 상기 메모리는, 상기 수신된 메시지에 응답하여 라우트 프로토콜 메시지(Route Protocol Message)를 형성하며, 상기 형성된 라우트 프로토콜 메시지를 상기 이동 장치로 송신하기 위한 명령들을 더 보유한다. 상기 프로세서는 상기 메모리에 결합되고, 상기 메모리에 보유된 상기 명령들을 실행하도록 구성된다.

추가 양상은 컴퓨터-판독가능 매체를 포함하는 컴퓨터 프로그램 물건에 관한 것이다. 상기 컴퓨터-판독가능 매체는, 컴퓨터로 하여금 이동 장치로부터 라우트 형성 헤더를 포함하는 메시지를 수신하도록 하기 위한 코드들의 제 1 세트를 포함한다. 상기 라우트 형성 헤더는 터널을 정의하는 것과 연관된 하나 이상의 파라미터들을 포함한다. 상기 컴퓨터-판독가능 매체는 또한, 상기 컴퓨터로 하여금 상기 이동 장치가 개방-대기 상태에 있는지 여부를 결정하도록 하기 위한 코드들의 제 2 세트 및 상기 컴퓨터로 하여금 상기 이동 장치가 상기 개방-대기 상태에 있는 경우 적어도 하나의 에러에 대하여 상기 라우트 형성 헤더를 검토하도록 하기 위한 코드들의 제 3 세트를 포함한다. 상기 컴퓨터-판독가능 매체에는, 상기 컴퓨터로 하여금 상기 수신된 메시지에 응답하여 라우트 프로토콜 메시지(Route Protocol Message)를 형성하도록 하기 위한 코드들의 제 4 세트 및 상기 컴퓨터로 하여금 상기 형성된 라우트 프로토콜 메시지를 상기 이동 장치로 송신하도록 하기 위한 코드들의 제 5 세트가 더 포함된다.

또 다른 양상은 이동 장치로부터 라우트 형성 헤더를 포함하는 메시지를 수신하기 위한 수단을 포함하는 장치에 관한 것이다. 상기 라우트 형성 헤더는 터널을 정의하는 것과 연관된 하나 이상의 파라미터들을 포함한다. 상기 장치는 또한 이동 장치가 개방-대기 상태에 있는지 여부를 결정하기 위한 수단 및 이동 장치가 상기 개방-대기 상태에 있는 경우 적어도 하나의 에러에 대하여 상기 라우트 형성 헤더를 검토하기 위한 수단을 포함한다. 추가하여, 상기 장치는 상기 수신된 메시지에 응답하여 라우트 프로토콜 메시지(Route Protocol Message)를 형성하기 위한 수단 및 상기 형성된 라우트 프로토콜 메시지를 이동 장치로 송신하기 위한 수단을 포함한다.

또 다른 양상은 라우트 프로토콜을 위한 적어도 하나의 프로세서에 관한 것이다. 상기 프로세서는 이동 장치로부터 라우트 형성 헤더를 포함하는 메시지를 수신하도록 동작가능한 제 1 모듈을 포함한다. 상기 라우트 형성 헤더는 터널을 정의하는 것과 연관된 하나 이상의 파라미터들을 포함한다. 상기 프로세서는 또한, 상기 이동 장치가 개방-대기 상태에 있는지 여부를 결정하도록 동작가능한 제 2 모듈 및 상기 이동 장치가 상기 개방-대기 상태에 있는 경우 적어도 하나의 에러에 대하여 상기 라우트 형성 헤더를 검토하도록 동작가능한 제 3 모듈을 포함한다. 상기 라우트 형성 헤더는 상기 이동 장치가 개방-대기 상태에 있지 않는 경우 무시된다. 상기 프로세서에는, 상기 수신된 메시지에 응답하여 라우트 프로토콜 메시지(Route Protocol Message)를 형성하도록 동작가능한 제 4 모듈 및 및 상기 형성된 라우트 프로토콜 메시지를 상기 이동 장치로 송신하도록 동작가능한 제 5 모듈이 더 포함된다.

전술한 그리고 관련된 목적들을 달성하기 위하여, 상기 하나 이상의 양상들은 이하에서 완전히 기술되고 청구항들에서 특정하여 지적된 특징들을 포함한다. 이하의 설명 및 첨부된 도면들은 상기 하나 이상의 양상들의 특정 예시적인 특징들을 상세히 기술한다. 이러한 특징들은 여러 다양한 양상들의 원리들이 채택될 수 있는 여러 방식들 중 몇몇 개만을 나타낸다. 다른 이점들 및 신규한 특징들은 도면들과 연관하여 고려할 때 이하의 상세한 설명으로부터 명백해질 것이고, 개시된 양상들은 그러한 모든 양상들 및 그들의 균등물들을 포함하는 것으로 의도된다.

도 1은 본 명세서에서 제시된 여러 양상들에 다른 무선 통신 시스템을 도시한다.

도 2는 무선 통신 환경에서의 라우트 프로토콜을 촉진하는 시스템을 도시한 다.

도 3은 무선 통신 환경에서의 라우트 프로토콜을 촉진하는 시스템을 도시한다.

도 4는 라우트 프로토콜 패킷들의 2가지 예를 도시한다.

도 5는 예시적인 라우트 프로토콜 헤더들 및 이러한 여러 다양한 헤더들이 어떻게 상호작용하는지를 도시한다.

도 6은 이동 장치와 기지국 사이의 터널 관계를 형성하기 위한 방법을 도시한다.

도 7은 이동 장치와 기지국 사이에서 터널을 통해 통신을 확립하기 위한 방법을 도시한다.

도 8은 이동 장치와 기지국 사이의 터널 관계를 형성하는 예시적인 시스템을 도시한다.

도 9는 이동 장치와 기지국 사이의 터널 관계를 형성하는 예시적인 시스템을 도시한다.

다양한 실시예들이 이제 도면을 참조하여 설명된다. 이하의 설명에서, 설명의 목적을 위해 하나 이상의 양상들의 완전한 이해를 제공하기 위하여 다수의 특정 세부사항들이 기술된다. 그러나 그러한 양상들은 이러한 특정 세부사항들 없이도 실시될 수 있음이 명백하다. 다른 경우들에서, 공지된 구조 및 장치들은 이러한 양상들의 설명을 용이하게 하기 위해서 블록 다이아그램 형태로 제시된다.

본원에서 사용되는 바와 같이, 용어들 "컴포넌트", "모듈", "시스템" 등은 컴퓨터-관련 엔티티, 하드웨어, 펌웨어, 소프트웨어, 소프트웨어 및 하드웨어의 조합, 또는 실행 중 소프트웨어를 지칭하는 것으로 의도된다. 예를 들어, 컴포넌트는 프로세서상에서 실행되는 프로세스, 프로세서, 객체, 실행 스레드, 프로그램, 및/또는 컴퓨터일 수 있지만, 이들로 제한되는 것은 아니다. 예를 들어, 컴퓨팅 장치에서 실행되는 애플리케이션 및 컴퓨팅 장치 모두 컴포넌트일 수 있다. 하나 이상의 컴포넌트는 프로세서 및/또는 실행 스레드 내에 상주할 수 있고, 일 컴포넌트는 하나의 컴퓨터 내에 로컬화될 수 있거나/있고 2개 이상의 컴퓨터들 사이에 분산될 수 있다. 또한, 이러한 컴포넌트들은 그 내부에 저장된 다양한 데이터 구조들을 갖는 다양한 컴퓨터 판독가능한 매체로부터 실행될 수 있다. 컴포넌트들은 예를 들어 하나 이상의 데이터 패킷들을 갖는 신호(예를 들면, 로컬 시스템, 분산 시스템에서의 다른 컴포넌트와 상호작용하는 그리고/또는 신호에 의해 인터넷과 같은 네트워크를 가로질러 다른 시스템들과 상호작용하는 하나의 컴포넌트로부터의 데이터)에 따라 로컬 및/또는 원격 프로세스들을 통해 통신할 수 있다.

또한, 다양한 양상들이 무선 단말과 관련하여 설명된다. 무선 단말은 또한 시스템, 가입자 유닛, 가입자국, 이동국, 모바일, 이동 장치, 장치 원격국, 원격 단말, 액세스 단말, 사용자 단말, 단말, 무선 통신 장치, 사용자 에이전트, 사용자 장치, 또는 사용자 장비(UE)로 지칭될 수 있다. 무선 단말은 셀룰러 전화, PCS 전화, 코드리스 전화, 세션 개시 프로토콜(SIP) 전화, 스마트 폰, 무선 로컬 루프(WLL) 스테이션, 개인 휴대 단말기(PDA), 랩탑, 소형(handheld) 통신 장치, 소형 컴퓨팅 장치, 위성 라디오 및/또는 무선 시스템 상에서 통신하기 위한 또 다른 프로세싱 장치일 수 있다. 더욱이, 여러 다양한 양상들은 본 명세서에서 기지국과 관련하여 설명된다. 기지국은 무선 단말(들)과 통신하기 위해 이용될 수 있고, 또한 액세스 포인트, Node B 또는 소정의 다른 용어로서 지칭될 수 있다.

여러 다양한 양상들 또는 특징들은 다수의 장치들, 컴포넌트들, 모듈들 등을 포함할 수 있는 시스템들의 관점에서 제시될 것이다. 여러 다양한 시스템들이 부가적인 장치들, 컴포넌트들, 모듈들 등을 포함할 수 있거나/있고 도면들과 관련하여 논의된 모든 장치들, 컴포넌트들, 모듈들 등을 포함하지 않을 수도 있음이 이해되고 인식되어야 한다. 이러한 접근법들의 조합이 또한 사용될 수 있다.

이제 도 1을 참조하면, 본 명세서에서 제시된 여러 다양한 양상들에 따른 무선 통신 시스템(100)이 도시된다. 시스템(100)은 하나 이상의 섹터들내의 하나 이상의 기지국들을 포함할 수 있고, 하나 이상의 기지국들은 서로, 그리고/또는 하나 이상의 이동 장치들로 무선 통신 신호들을 송신, 수신, 반복 등을 할 수 있다. 각각의 기지국은 다수의 송신기 체인들 및 수신기 체인들(예를 들어, 각각의 송수신 안테나에 대하여 하나씩)을 포함할 수 있고, 다수의 송신기 체인들 및 수신기 체인들 각각은 차례로 신호 송신 및 수신과 연관된 복수의 컴포넌트들(예를 들어, 프로세서들, 변조기들, 멀티플렉서들, 복조기들, 디멀티플렉서들, 안테나들 등)을 포함할 수 있다. 각각의 이동 장치는 하나 이상의 송신기 체인들 및 수신기 체인들을 포함할 수 있고, 상기 송신기 체인들 및 수신기 체인들은 다중 입력 다중 출력(MIMO) 시스템에 이용될 수 있다. 각각의 송신기 및 수신기 체인은 당업자에 의 해 인식되는 바와 같이, 신호 송신 및 수신과 연관된 복수 개의 컴포넌트들(예를 들어, 프로세서들, 변조기들, 멀티플렉서들, 복조기들, 디멀티플렉서들, 안테나들 등)을 포함할 수 있다.

도시된 바와 같이, 이동 장치(102)는 무선 링크를 통해 기지국(104)과 패킷들을 송신 및/또는 수신할 수 있고, 상기 기지국(104)는 본 명세서에서 1차 기지국(primary base station)(104)으로 지칭된다. 무선 통신 시스템(100) 내에서, 기지국들(106 및 108)과 같이 이동 장치(102)의 범위를 벗어난 다른 기지국들이 존재할 수 있다. 그리하여, 이러한 기지국들(106, 108)과 직접적으로 접속가능성이 확립될 수 없다. 그러나, 이동 장치(102)가 1차 기지국(104)을 통해 기지국들(106 및 108)과 통신하기 위하여 터널링으로서 지칭되는 기술이 이용될 수 있다. 기지국들(106 및 108)은 본 명세서에서 2차 기지국들로서 언급된다. 인식되는 바와 같이 비록 다수의 이동 장치(들)(102) 및 기지국(들)(104, 106, 및 108)이 무선 통신 시스템(100)에 포함될 수 있지만, 단순화를 위하여 단 하나의 이동 장치(102)가 단일의 1차 기지국(104)으로 통신 데이터 신호들을 송신하고 단일의 1차 기지국(104)이 2개의 2차 기지국들(106 및 108)로 상기 신호들을 터널링하는 것으로 도시된다.

예를 들어, 이동 장치(102)는 2차 기지국들(106 및/또는 108)로부터의 무선 신호(예를 들어, 파일럿 파형)를 관찰할 수 있으나, 관찰된 신호는 2차 기지국들(106 및 108)과의 직접 통신을 가능하게 하기에 충분히 강하지 않을 수 있다(예를 들어, 약한 신호). 그러나, 이동 장치(102)는 1차 기지국(104)을 통한 터널을 확립하고 2차 기지국(106, 108)에 대한 확보된 자원들을 획득함으로써 2차 기지국 들(106, 108) 중 하나 이상과 관계를 확립하기를 원한다. 만약 2차 기지국들(106, 108) 중 하나 이상과의 신호가 더 강해지면, 이동 장치(102)는 물리적 계층을 통해 2차 기지국들(106, 108)과 직접 통신을 갖기를 원할 수 있다. 그리하여, 터널은 결국에는 2차 기지국들(106, 108) 중 하나 이상과의 직접 통신을 갖는 것을 예상하여 확립될 수 있다. 터널은 2차 기지국들(106, 108)에 대한 자원들을 확보해둘 수 있고, 이것은 이동 장치(102)가 2차 기지국들(106, 108)과의 보증된 관계를 확립하게 한다. 그러한 방식으로, 이동 장치(102)가 1차 기지국(104)으로부터 2차 기지국(106, 108)으로 핸드오프될 때, 원활한 그리고/또는 효율적인 핸드오버가 달성될 수 있다.

본 명세서에서 개시된 여러 다양한 양상들은 액세스 단말(102)과 기지국들(106, 108) 사이의 관계(예를 들어, 라우트 또는 터널)의 확립 및/또는 파기에 관한 것이다. 본 명세서에 개시된 양상들 중 하나 이상은 터널들을 확립 및/또는 제거하기 위해 이용되는 어드레싱 또는 시그널링에 관한 것이다. 부가적으로 또는 대안적으로, 이러한 소정의 양상들은 터널들을 통해 얻을 수 있는 메시지들의 타입 및 기능성(functionality)들의 타입에 관한 것이다. 이러한 양상들에 관한 세부사항들은 이하의 도면들 및 상세한 설명을 참조하여 더 상세히 기술될 것이다.

도 2는 무선 통신 환경에서의 라우트 프로토콜을 촉진하는 시스템(200)을 도시한다. 시스템(200)은 채널을 통해 데이터를 송신하고 있는 것으로 도시된 무선 통신 장치(202)를 포함한다. 비록 데이터를 송신하고 있는 것으로 도시되었지만, 무선 통신 장치(202)는 또한 채널을 통해 데이터를 수신할 수 있다(예를 들어, 무 선 통신 장치(202)는 데이터를 동시에 송수신할 수 있고, 무선 통신 장치(202)는 다른 시점들에서 데이터를 송신 및 수신할 수 있고, 이들의 조합 등일 수 있음). 무선 통신 장치(202)는 예를 들어, 이동 장치(예를 들어, 도 1의 이동 장치(102))일 수 있다. 이해의 목적으로, 무선 통신 장치(202)는 본 명세서에서 이동 장치(202)로 지칭될 것이다.

이동 장치(202)에는 터널이 1차 기지국을 통해 하나 이상의 2차 기지국들로 형성되어야 하는지 여부를 결정할 수 있는 라우트 선택 모듈(204)이 포함된다. 이러한 터널은 이동 장치(202)가 1차 기지국을 통해 하나 이상의 2차 기지국들과 통신하게 할 수 있다. 터널은 라우트 프로토콜 및 인터-라우트 터널링 프로토콜(inter-route tunneling protocol)에 의해 구현될 수 있다. 이들 프로토콜들 내의 헤더들은 여러 다양한 터널들에 대한 특정 기능성을 제공한다. 라우트 형성 헤더(Route Creation Header)는 터널을 정의하는 것과 연관된 하나 이상의 파라미터들을 포함한다. 예를 들어, 라우트 형성 헤더는 라우트에 대해 선택된 퍼스널리티(personality), 라우트의 라우트 식별, 기존의 라우트들이 소거되어야 하는지 여부, 및 라우트들(또는 터널들)을 형성 및/또는 소거하는 것과 연관된 다른 파라미터들과 관련된 정보를 운반할 수 있다.

라우트 식별자(ID) 모듈(206)은 라우트 식별자(RouteID)를 결정할 수 있고, 라우트 식별자(RouteID)는 이동 장치(202)에 의해 형성되는 각각의 터널에 대해 상이하다. RouteID는 라우트 ID 모듈(206)에 의해 라우트 형성 헤더에 포함된다. 기지국과 이동 장치 모두 RouteID를 이용함으로써 무효의 메시지(stale message) 들(현재 사용중(In-Use) 라우트 인스턴스(instance)로 지향되지 않는 메시지들)을 검출할 수 있다. 기지국들이 이동 장치들로의 라우트들을 형성 및 소거하기 때문에, 기지국에서의 라우트 인스턴스와 이동 장치 간의 잘못된 매칭의 가능성이 존재할 수 있다. 예를 들어, 이동 장치가 새로운 라우트를 형성하였을지라도, 기지국은 이동 장치에 대한 종전의(old) 라우트 인스턴스를 가질 수 있다. RouteID는 기지국 및 이동 장치로 하여금 동일한 라우트 인스턴스가 통신에 이용되고 있는지 여부를 결정할 수 있게 하고, 동일한 라우트 인스턴스가 통신에 이용되고 있는지 여부는 라우트 인스턴스가 형성된 때 결정될 수 있다. 상기 결정은 무선을 통한(over-the-air) 통신들 및/또는 MACID 및 RouteID 사이의 일 대 일 맵핑에 대해 이루어진다. 터널링된 통신을 위하여, RouteID는 인터-라우트 터널링 프로토콜(Inter-Route Tunneling Protocol; IRTP) 헤더들에 포함된다. IRTP 헤더 내 RouteID는 기지국 대 기지국 통신에(링크 계층 터널 헤더에) 포함되고 그 역으로 기지국 대 기지국 통신이 IRTP 헤더 내 RouteID에 포함된다.

소정의 양상들에 따라, 라우트 또는 터널은 이미 2차 기지국과 확립될 수 있다. 이러한 상황에서, 패킷은 라우트를 형성하라는 요청에 응답하여, 기지국으로부터 수신될 수 있다. 패킷은 이미 확립된 라우트 에러 코드 및 확립된 라우트의 라우트 식별을 포함할 수 있다. 이러한 정보에 기초하여, 이동 장치(202)는 터널 관계가 이미 확립되었고 따라서 재확립될 필요가 없음을 결정할 수 있다.

이동 장치(202)와 연관된 하나보다 많은 수의 터널이 존재할 수 있다. 예를 들어, 이동 장치(202)는 다수의 (2차) 기지국들에 대하여 다수의 터널들(예를 들 어, 도 1의 기지국(106)에 대하여 하나의 터널, 그리고 기지국(108)에 대하여 제 2 터널)을 가질 수 있다. 각각의 터널은 상이한 RouteID를 갖는다. 소정의 양상들에 따라, RouteID는 RouteCounter의 다음의 미사용 최하위 비트(Least Significant Bit; LSB)들 중 7개 비트들과 같은, 7비트 식별자이다.

예시의 목적으로 제한됨 없이, 메시지들이 이미 확립되어 있는 터널을 통해 전송될 때마다, 이동 장치(202)는 직접 접속된 1차 기지국으로 상기 메시지들을 전송한다. 1차 기지국은 터널링 포인트 기지국(예를 들어, 2차 기지국)으로 상기 메시지들을 포워딩한다. 1차 기지국이 2차 기지국으로 메시지들을 전송할 때, 상기 메시지는 RouteID 및 각각의 메시지를 포함한다. 소정의 상황들에서, 동일한 2차 기지국과 확립되도록 시도된 다수의 터널들이 존재할 수도 있다. 예를 들어, 제 1 터널이 확립되었고 그 다음 에러가 수신되어 제 2 터널이 확립되었다. 이러한 2개의 터널들은 상이한 라우트 ID들을 갖는다. 지터(jitter) 또는 네트워크 상의 불량한 전파로 인하여, 메시지들은 부정확한 순서로 2차 기지국에 도착하기 시작할 수 있다. RouteID가 각각의 메시지에 포함되기 때문에, 2차 기지국은 또 다른 터널(RouteID에 의해 식별됨)의 존재에 의해 폐기된 더 이상 존재하지 않는 터널에 대응하는 메시지들을 거부할 수 있다. 그러하여, 각각의 메시지 내의 RouteID는 더 이상 존재하지 않는 터널로 전송된 무효의 메시지들을 경감할 수 있다.

라우트 프로토콜에 포함된 또 다른 필드는 퍼스널리티 모듈(208)에 의해 결정된, 라우트에 대한 퍼스널리티를 정의하는 퍼스널리티이다. 이러한 결정은 이동 장치(202)에 의해 지원되는 터널들의 사전-협상된 타입(pre-negotiated type)들에 기초하여 이루어질 수 있다. 퍼스널리티는 프로토콜 타입들의 집합 및 특정 속성 또는 파라미터 값들의 집합이다. 각각의 프로토콜은 시간에서의 임의 시점에서 활성화되는 특징들을 나타내는 속성들을 포함한다. 퍼스널리티는 또한 프로토콜에 대한 개정 번호를 포함할 수 있다. 접속가능성이 이동 장치(202)와 목적지(예를 들어, 터널의 나머지 말단에 있는 기지국, 2차 기지국) 사이에서 동작하기 위하여, 양쪽의 엔티티들(예를 들어, 이동 장치와 2차 기지국)은 통신 언어에 대해 합의하여야 한다. 일단 상기 2개의 엔티티들(예를 들어, 이동 장치와 2차 기지국)이 어떤 퍼스널리티가 이용될 것인지에 대하여 합의한다면, 통신이 존재할 수 있다. 미리 결정된 퍼스널리티들의 리스트 및 라우트 형성 헤더는 특정 라우트에 대해 어떠한 언어가 사용될 것인지를 식별할 수 있다. 퍼스널리티는 초기 프로토콜 설정 식별(Initial Protocol Set Identification; IPSI) 및 퍼스널리티 인덱스(또는 프로토콜 설정 식별자(Protocol Set Identifier; PSI))이다. 만약 계류 중인(pending) 퍼스널리티 교환가 존재한다면, 이동 장치는 퍼스널리티를 계류 중인 퍼스널리티 값으로 설정한다.

소정의 양상들에 따라, 퍼스널리티 모듈(208)에 의해 선택된 퍼스널리티는 2차 기지국에 의해 지원되지 않을 수 있다. 이러한 상황에서, 이동 장치(202)는 퍼스널리티가 지원되지 않음을 표시하는 에러 코드를 2차 기지국으로부터 수신한다. 이동 장치(202)는 또한 지원되는 퍼스널리티들의 리스트를 수신할 수 있고, 그것으로부터 퍼스널리티 모듈(208)은 상기 리스트를 검토하여 이동 장치(202)에 의해 지원되는 퍼스널리티를 선택할 수 있다. 라우트 형성 헤더 패킷(Route Creation Header Packet)은 선택된 퍼스널리티 정보를 포함하도록 수정되어 상기 정보를 선택된 기지국으로 전달할 수 있다. 소정의 양상들에 따라, 기지국으로부터 수신된 퍼스널리티들의 리스트는 기지국에 의해 결정되는 바와 같이 선호도(preference)의 순으로 랭크된다. 이동 장치가 제 1 랭크된 퍼스널리티를 지원한다면, 그러한 퍼스널리티가 사용된다. 만약 제 1 랭크된 퍼스널리티가 지원되지 않는다면, 제 2 랭크된 퍼스널리티가 이용될 수 있는 등등이다.

소정의 양상들에 따라, 이동 장치(202)는 거의 동시에 활성인 하나보다 많은 수의 퍼스널리티를 가질 수 있다. 예를 들어, 이동 장치(202)는 하나보다 많은 수의 라우트 개방을 갖는다(예를 들어, 하나보다 많은 수의 2차 기지국과 통신한다). 각각의 라우트는 상이한 퍼스널리티를 가질 수 있고, 그것은 기지국의 능력(capability)들 및 이동 장치의 능력들의 함수이다.

2개의 엔티티들 간의 통신이 확립될 수 있도록 2차 기지국에 이동 장치의 식별을 나타내기 위해 이동 장치(202)에 의해 이용되는 액세스 단말 식별자(Access Terminal Identifier; ATI) 모듈(210)이 또한 이동 장치(202)에 포함된다. 이동 장치의 식별은 액세스 단말 식별자(ATI)를 운반하는 액세스 단말 식별자(ATI) 헤더에 포함된다. UATI(유니캐스트 ATI)가 이동 장치에 할당되는 경우 ATI 헤더는 UATI로 설정된다. 만약 UATI가 이동 장치로 할당되지 않는다면, ATI 헤더는 RATI(랜덤 ATI)로 설정된다.

2차 기지국은 ATI 헤더를 수신할 수 있고 기지국이 정확한 ATI를 정확한 이동 장치로 매칭시켰는지 여부를 확인하기 위하여 ATI 헤더를 다시 이동 장치로 전 송할 수 있다. 예를 들어, 기지국은 ATI 헤더를 이동 장치(202)로부터 수신된 ATI 값으로 설정할 수 있다. 만약 기지국으로부터 수신된 ATI 헤더가 정확한 ATI 헤더(예를 들어, 이동 장치(202)에 대응하는 ATI 헤더)라면, 이동 장치(202)는 ATI 바인딩(binding) 상태를 획득할 수 있고, ATI 바인딩 상태는 기지국과 이동 장치(202)가 서로 알고 있음을 나타낸다. 소정의 양상들에 따라, ATI 헤더는 이동 장치(202)의 128-비트 식별자일 수 있다.

접속된 상태(Connected State) 프로토콜이 BindATI 상태에 있는 경우, ATI 헤더는 이동 장치(202)에 의해 포함된다. 예를 들어, 이동 장치(202)에 의해 전송된 ATI 헤더와 동일한 ATI 헤더를 포함하는 라우트 프로토콜 헤더가 2차 기지국으로부터 수신되지 않았다면, 이동 장치(202)는 BindATI로 남아 있다. 2차 기지국으로부터 수신된 라우트 프로토콜 헤더가 이동 장치(202)에 의해 전송된 동일한 ATI 헤더를 포함한다면, 이동 장치(202)는 BindATI 상태를 벗어난다.

라우트 형성 헤더는 2차 기지국이 터널을 형성하였다는 확인(confirmation)이 수신될 때까지 그리고/또는 패킷이 상기 기지국으로부터 수신될 때까지, 이동 장치(202)와 연관된 송신기(212)에 의해 전송된다. 상기 확인은 터널 관계의 형성을 나타낸다. 이러한 확인이 수신될 때까지, 이동 장치(202)는 개방-대기(Waiting-To-Open) 상태에 있고, 이동 장치는 계속하여 라우트 형성 헤더를 송신한다. 개방-대기 상태는 이동 장치(202)가 이러한 라우트 상에서 2차 기지국으로부터 패킷들을 수신하지 않았음을 표시한다. 송신기(212)는 상기 확인이 수신될 때까지 계속하여 라우트 형성 헤더를 전송할 수 있다. 상기 확인이 수신됨과 거의 동시에, 이동 장치(202)는 개방-대기 상태를 벗어나고(또는 개방-대기 상태에서 전이되고), 라우트 형성 헤더는 더 이상 송신기(212)에 의해 전송되지 않는다.

소정의 양상들에 따라, 2차 기지국으로부터 ATI 헤더를 수신함과 거의 동시에, 이동 장치(202)는 ATIReceived(ATIType, ATI, RouteStatus) 표시(접속된 상태 프로토콜(connected state protocol; CSP)에 의해 사용됨)를 전송한다. 이러한 양상들에 따라, 만약 ATI 헤더가 존재하지 않거나 ErrorCode 헤더가 존재하면, RouteStatus가 실패(Failure)(0x1)로 설정된다. 그렇지 않으면, RouteStatus는 0x0으로 설정된다.

이동 장치(202)가 물리적 계층 상의 직접 접속가능성을 갖는 1차 기지국이 아니라, 2차 기지국과 통신할 때 ATI 헤더 정보가 이용됨을 주목하여야 한다. 부가적으로, ATI 헤더는 핸드오버 동안에 전송되지 않는다. 그러나, 제 1 접속이 제 1의 2차 기지국과 확립될 때, ATI 헤더가 한 번 전송된다. 제 1의 2차 기지국(이제 이동 장치의 아이덴티티(identity)를 앎)과의 확립 이후에, 다른 2차 기지국들과 확립된 후속의 터널들이 이동 장치(202)의 아이덴티티를 공유하도록 서로 조정된다. 그리하여, 후속의 ATI 터널 형성을 위하여, 기지국들이 ATI 헤더 정보를 전달할 수 있다면, ATI 헤더(및 ATI 모듈(210))는 후속의 기능들을 수행할 필요가 없을 수 있다.

그리하여, 소정의 상황들에서, 터널이 형성되어 있는 기지국(예를 들어, 2차 기지국)은 이동 장치의 가장 최근의 식별자를 알지 못할 수 있는데, 그 이유는 이동 장치들의 어드레스가 변화하였기 때문이다. 상기 어드레스가 변화하지 않은 경 우들에서, 서빙 기지국(예를 들어, 1차 기지국)은 2차 기지국으로 상기 어드레스를 전달할 수 있다. 그러나, 상기 어드레스가 최근에 바뀐 경우, 서빙 기지국은 그러한 어드레스의 변화를 알지 못할 수도 있는데, 그 이유는 어드레스 변화가 SRNC(중앙 제어기)와 이동 장치 사이의 프로세스이기 때문이고, 이러한 프로세스는 서빙 기지국이 알지 못한다. 예를 들어, 상기 어드레스가 마지막 X 초들에서 바뀌었다면(여기서, X는 정수이고, 예를 들어, 5임), 이동 장치는 라우트 형성 동안에 새로운 어드레스를 포함하고, 그렇지 않으면 상기 어드레스를 생략한다. 이것은 어드레스가 최근에 바뀐 경우에 2차 기지국이 이동 장치의 어드레스에 관한 가장 최근 정보를 갖도록 하고, 어드레스가 최근에 바뀌지 않은 경우들에서 상기 어드레스를 포함하는 것의 오버헤드를 경감할 수 있다.

예를 들어, 이동 장치(202)가 하나의 지리적 위치(예를 들어, 뉴욕시)에서의 여러 다양한 기지국들과의 터널들을 확립하였다면, 그러한 기지국들은 자신들 간에 ATI 헤더를 전달할 수 있어야 한다. 그러나, 만약 이동 장치가 꺼져 있다면, 예를 들어, 이동 장치의 사용자가 피닉스로 비행하고 있다면, 이동 장치는 ATI 헤더 정보를 포함하는 라우트 형성 헤더를 형성하여 피닉스 영역에 위치하는 기지국들로 송신하여야 한다.

소정의 양상들에 따라, 라우트 형성 헤더를 포함하는 메시지를 송신하기 위하여, 2 이상의 패킷 병합 프로토콜 패킷들(Packet Consolidation Protocol Packets)이 단일의 MAC 패킷에 실릴(carry) 것인지 여부에 대한 결정이 이루어진다. 각각의 패킷 병합 프로토콜 패킷은 헤더 엘리먼트 레코드(Header Element record)를 포함한다. 만약 하나보다 많은 수의 패킷 병합 프로토콜 패킷들이 전송되어야 한다면, 하나를 제외한 모든 패킷 병합 프로토콜 패킷들로부터의 헤더 엘리먼트 레코드가 생략될 수 있고, 이것은 자원들을 절약하고 시스템(200) 효율성을 개선할 수 있다.

소정의 양상들에 따라, 네트워크와의 세션은 여러 다양한 상황들(예를 들어, 이동 장치의 보증서들이 만료됨)로 인하여 종료되어야 할 수 있다. 만약 세션이 종료되어야 한다면, 이동 장치는 2차 기지국으로부터 세션 종료 에러 코드(session close error code) 및 CRCErrorDetectPattern을 포함하는 패킷을 수신할 수 있다. 만약 CRCErrorDetectPattern이 세션 종료 에러 코드가 링크 에러로 인한 것이 아님을 표시한다면, 이동 장치(202)는 네트워크(2차 기지국 포함)와 재인증할 수 있다.

라우트 소거 모듈(214)은 특정 라우트 또는 터널이 소거되어야 함을, 그리고 소정의 양상들에 따라 새로운 터널이 시작되어야 함을 결정할 수 있다. 라우트 소거 모듈(214)은 라우트 형성 헤더 내에서, 라우트가 소거되어야 함을 표시하도록 비트를 구성할 수 있다. 이러한 비트는 "종전의 라우트 소거(Delete Old Route)" 비트로서 지칭될 수 있다. 소정의 양상들에 따라, 종전의 라우트 소거 비트는 길이가 1 비트이다. 만약 라우트 소거 모듈(214)이 이러한 비트를 "1"로 설정하면, 그것은 요구되는 경우 터널이 소거되어 재시작되게 한다. 만약 종전의 라우트 소거 비트가 "0"으로 설정되면, 그것은 라우트들이 소거되지 않아야 함을 표시한다. 소정의 양상들에 따라, 이동 장치는 오작동으로 인하여, 퍼스널리티를 바꾸기 위하여 또는 다른 이유들로 터널을 리셋하기를 요구할 수 있다. 종전의 라우트들 소거 플래그(flag)가 설정되어야 하는지 여부를 특정할 수 있는 트리거들은 이동 장치가 무선 링크 프로토콜(Radio Link Protocol; RLP) 상태를 잃은 상황을 포함할 수 있다.

예를 들어, 전력 소스가 이동 장치(202)로부터 제거되거나 이동 장치(202)로 하여금 확립되어 있던 임의의 터널들을 포함하여 이전의 설정들의 추적을 잃게 하는 오작동이 존재한다. 예를 들어, 이동 장치(202)가 특정 패킷 필터들 및/또는 속성들을 협상하고 있었고 오작동으로 인하여 이동 장치(202)가 무엇이 협상되고 있었는지 잊었다면, 이동 장치(202)는 터널 및 여러 다양한 작동들의 상태의 리셋을 수행하여야 할 수 있다. 그리하여, 이동 장치는 상기 터널을 소거하고 다시 터널 확립 프로세서를 시작하여야 한다.

소정의 양상들에 따라, IRTP 헤더들에 대하여, RCP(라우트 제어 프로토콜(Route Control Protocol))가 개방-대기 상태에 있다면, 이동 장치(202)는 액세스 노드(또는 네트워크) 식별자(Access Node Identifier; ANID) 헤더를 이용한다. ANID 헤더는 RouteCreate 메시지에 대한 응답이다. 소정의 양상들에 따라, 목적지 라우트에 대한 ANID 대 RouteID 맵핑을 포함하는 RouteMap이 이러한 기지국에 전송되지 않았다면, 이동 장치(202)는 목적지 라우트에 대하여 RouteID 헤더를 사용하지 않는다. 그리하여, 이동 장치가 제 1 기지국(예를 들어, 1차 기지국)을 통해 또 다른(예를 들어, 2차) 기지국으로 터널링하고 있을 때, 여러 다양한 어드레싱 기술들이 적용된다. 예를 들어, 특정 기술들은 ANID로 지칭되는 더 긴 어드레스를 사용하고, 라우트 ID로서 지칭되는 더 짧은 어드레스가 존재한다. 더 짧은 어드레 스(예를 들어, 라우트 ID)는 이동 장치가 더 긴 어드레스와 더 짧은 어드레스 간의 맵핑이 (2차) 기지국에 이용가능하게 됨을 확립한 이후에 이용될 수 있다. 이동 장치는 어떤 짧은 어드레스가 어떤 더 긴 어드레스로 맵핑되는지를 표시하는 표(예를 들어, 라우트 맵 메시지(Route Map Message))를 공급할 수 있다. 맵핑은 기지국에서 유지될 수 있다. 만약 기지국이 인식하지 못하는 라우트 ID가 수신된다면, 기지국은 이동 장치에게 무슨 ANID가 라우트 ID에 대응하고 있는지를 보고하도록 요청하는 질의 메시지(query message)를 전송할 수 있다. 이동 장치는 ANID로 응답할 수 있다.

소정의 양상들에 따라, 만약 서빙(예를 들어, 1차) 기지국이 RouteID 헤더(짧은 어드레스)를 수신하고 RouteID를 인식하지 않는다면, 이동 장치는 현재의 라우트 맵을 요청하는 RouteMapRequest를 수신할 수 있다. 이동 장치는 상기 요청에 기초하여 라우트 맵을 송신할 수 있다. 소정의 양상들에 따라, 이러한 목적지 라우트에 대한 ANID 대 RouteID 맵핑을 포함하는 RouteMap 메시지가 이러한 기지국(예를 들어, 액세스 네트워크)로 전송되지 않았다면, 이동 장치는 목적지 라우트에 대한 RouteID 헤더를 사용하지 않는다.

도 3은 무선 통신 환경에서 라우트 프로토콜을 촉진하는 시스템(300)을 도시한다. 시스템(300)은 채널을 통해 데이터를 송신하고 있는 것으로 도시된 무선 통신 장치(302)를 포함한다. 비록 데이터를 송신하고 있는 것으로 도시되었지만, 무선 통신 장치(302)는 또한 채널을 통해 데이터를 수신할 수 있다(예를 들어, 무선 통신 장치(302)는 데이터를 동시에 송수신할 수 있고, 무선 통신 장치(302)는 상이 한 시점들에서 데이터를 송신 및 수신할 수 있고, 이들의 조합 등일 수 있음). 무선 통신 장치(302)는 예를 들어, 기지국(예를 들어, 도 1의 기지국(104, 106 또는 108))일 수 있다. 장치(302)는 이동 장치에 의해 수신된 라우트 형성 헤더에 응답하여 여러 다양한 에러 코드들을 정의할 수 있다. 이해의 목적으로, 장치(302)는 이하의 논의에서 기지국(302)로서 지칭될 것이다.

기지국(302)은 이동 장치(예를 들어, 도 1의 이동 장치(102), 도 2의 이동 장치(202))로부터 라우트 형성 헤더를 수신할 수 있다. 이러한 헤더를 수신함과 거의 동시에, 라우트 형성 프로토콜(RCP)이 개방-대기 또는 폐쇄-대기(Waiting-To-Close) 상태에 있지 않다면, 기지국(302)은 상기 헤더를 무시한다. 만약 DeleteOldRoutes가 설정되면(예를 들어, "1"과 같게), 기지국(302)은 DeleteOldRoutes 명령을 발(issue)하고, 상기 명령은 이러한 이동 장치와의 기존의 라우트들을 소거하기 위해 RCP에 의해 이용된다. 만약 RCP가 폐쇄-대기 상태에 있다면, RouteReopen 표시가 기지국(302)에 의해 전송된다. 이러한 RouteReopen은 개방 상태(Open State)에 진입하기 위하여 RCP에 의해 이용된다.

액세스 단말 식별자(ATI) 확인 모듈(304)은 이동 장치로부터 수신된 ATI가 해당 이동 장치에 대해 정확한 ATI임을 확인해주도록 구성된다. 이러한 정보를 확인해주기 위하여, ATI 확인 모듈(304)은 ATI 헤더내의 ATI 값을 이동 장치로부터 수신된 ATI 값으로 설정하고 응답을 전송할 수 있다. ATI를 포함하는 ATI 헤더를 수신할 때 이동 장치는 기지국(302)이 정확히 식별된 이동 장치를 가짐(또는 갖지 않음)을 확인할 수 있다.

지원된 퍼스널리티 모듈(supported personality module)(306)은 터널에 대해 이동 장치에 의해 선택된 퍼스널리티가 기지국(302)에 의해 지원되는지 여부를 결정할 수 있다. 만약 퍼스널리티가 지원되지 않는다면, 퍼스널리티 에러 코드가 전송될 수 있다. 소정의 양상들에 따라, 이러한 에러 코드는 "0000"에 의해 정의된다. 퍼스널리티는 프로토콜 타입들 및 속성들의 조합이다. 만약 기지국(302)이 하나 이상의 프로토콜 타입들 및 속성들의 조합을 지원하지 않는다면, 이동 장치가 새로운 퍼스널리티를 선택할 수 있도록 퍼스널리티 에러 코드가 이동 장치로 전송된다.

퍼스널리티 에러 코드(예를 들어, 에러 코드 0000)가 이동 장치로 송신됨과 거의 동시에, 이동 장치가 이용하여야 하는 제안된 퍼스널리티들의 리스트가 또한 기지국(302)에 의해 전송될 수 있다. 기지국(302)에 의해 지원된 퍼스널리티들의 리스트는 지원된 퍼스널리티 모듈(306)에 의해 유지될 수 있다. 만약 이동 장치에 의해 선택된 퍼스널리티가 이러한 리스트에 포함되지 않는다면, 지원된 퍼스널리티 모듈(306)은 그것이 선택된 퍼스널리티를 지원하지 않고 이동 장치가 기지국(302)에 의해 지원되는 것으로부터 선택할 수 있는 다른 퍼스널리티들에 대한 제안들을 제공함을 표시한다.

이동 장치로 전송된, 기지국(302)에 의해 지원되는 퍼스널리티들은 이동 장치의 아이덴티티(예를 들어, ATI 확인 모듈(304)에 의해 식별되는 것과 같은)의 함수일 수 있다. 이동 장치의 아이덴티티에 기초하여, 기지국(302)은 어떤 퍼스널리티들이 상기 이동 장치에 대해 적합할 것인지, 어떠한 것이 기지국(302)의 능력들 의 함수인지, 그리고 특정 이동 장치의 요구조건들을 결정할 수 있다. 예를 들어, 기지국(302)은 그것이 지원할 수 있는 퍼스널리티들 또는 프로토콜들(예를 들어, 기지국 소프트웨어 및 하드웨어 능력들)을 안다. 그리하여, 이동 장치의 아이덴티티가 이동 장치가 저전력 장치임을 표시하면, 기지국(302)은 이동 장치가 고전력 이동 장치인 경우에 기지국(302)이 수행하는 것과 다르게 상기 이동 장치에 대한 기능들을 수행할 수 있다. 예를 들어, 소정의 퍼스널리티들은 전력 절약 모드들을 가질 수 있는 반면, 다른 퍼스널리티들은 전력 절약 모드들을 지원하지 않는 등이다.

소정의 양상들에 따라, 기지국(302)은 세션 기준 네트워크 제어기(Session Reference Network Controller; SRNC)에 액세스하여, ATI에 기초하여 이동 장치에 관한 상세한 정보를 질의한다. 상세한 정보는 이동 장치에 의해 지원되는 애플리케이션들을 포함할 수 있다. 예를 들어, SRNC는 이동 장치가 비디오-전화 장치인지, 음성 장치인지, 데이터 전용 장치(data only device)인지 등의 여부에 관한 정보를 포함할 수 있다. SRNC는 네트워크의 중앙 엔티티이고 데이터베이스와 유사하게 기능할 수 있다. 라우트 형성 헤더에서 수신된 퍼스널리티 식별자들의 해석을 포함하는, SRNC로부터 획득된 정보에 기초하여, 기지국(302)은 이동 장치가 기지국(302)과의 터널을 확립하기 위해 이용할 수 있는 하나 이상의 퍼스널리티들을 제안할 수 있다. 퍼스널리티들은 선호도 순으로 랭크될 수 있다.

소정의 양상들에 따라, 이동 장치는 기지국(302)과의 기존 터널이 이미 존재할 때 새로운 터널을 형성하도록 시도할 수도 있다. 중복 라우트 검출 모 듈(duplicate route detection module)(308)은 라우트가 이미 존재함을 검증할 수 있고, 이동 장치와 확립된 터널이 이미 존재함을 이동 장치에게 알리기 위하여 에러 코드를 전송할 수 있고, 따라서 새로운 터널 요청이 거부된다. 이러한 상황에서, 모든 라우트 소거 플래그가 제로로 설정되고, 그리하여 이동 장치는 터널에 리셋되거나 재형성될 것을 요청하지 않고 있으나, 라우트(중복인 라우트)가 기지국(302)에 개방될 것을 요청하고 있다. 소정의 양상들에 따라, 라우트 이미 존재 에러 코드(route already exists error code)는 "0001"에 의해 정의된다.

터널을 형성하라는 요청이 거부되는 일 예는 이동 장치가 그것이 기지국(302)으로부터 수신하는 파일럿 신호들에 기초하여 터널 형성을 개시하는 경우의 상황이다. 기지국이 다수의 파일럿 신호들을 방출하고 있는 다중 섹터 기지국(302)인 경우에 같이, 기지국(302)은 다수의 파일럿 신호들을 방출하고 있을 수 있다. 이동 장치는 제 1 파일럿 신호를 검출하여 터널을 형성할 수 있다. 이동 장치가 제 2 파일럿 신호 또는 다른 파일럿 신호들을 검출할 때, 이동 장치는 터널 요청이 이루어진 때, 그것이 이미 관계가 있는 동일한 기지국(302)임을 알지 못하기 때문에 이동 장치는 제 2 또는 그 이상의 터널들을 형성하도록 시도할 수 있다. 그리하여, 제 2(또는 그 이상의) 터널들은 필요하지 않고, 기지국(302)은 이러한 터널들이 필요하지 않음을 표시하는, 라우트 이미 존재 에러 코드를 전송할 수 있다.

소정의 양상들에 따라, 세션 종료 모듈(310)이 기지국(302)에 포함된다. 세션 종료 모듈(310)은 이동 장치와 관련하여 심각한 에러를 검출할 수 있고, 자동으 로 이동 장치와의 세션을 종료할 수 있다. 소정의 양상들에 따라, 세션 종료 모듈(310)은 세션이 종료되어야 함을 표시하는 명령들을 세션 기준 네트워크 제어기로부터 수신한다. 에러 코드는 이러한 에러를 표시하면서 이동 장치로 전송될 수 있다. 소정의 양상들에 따라, 이러한 에러 코드는 "0010"에 의해 정의된다. 예를 들어, 이동 장치는 터널의 확립을 개시하도록 시도하거나 상기 터널을 통해 통신하도록 시도할 수 있다. 액세스 네트워크는 가입(예를 들어, 네트워크에 대한 액세스)이 최신이 아님을 검출할 수 있다(예를 들어, 가입을 유지하기에 상당히 현저한 미불액(balance due)이 존재함). 이러한 정보는 기지국(302)이 이동 장치의 구성(configuration)을 결정하기 위해 SRNC에 액세스할 때 획득될 수 있다. SRNC는 이동 장치의 인증서가 만료되어 이동 장치가 네트워크에 대한 액세스를 갖지 않아야 함을 표시할 수 있다. 그리하여, 이러한 에러는 세션을 종료하기 위해 전송된다. 세션이 종료된 이후에, 이동 장치는 네트워크에 대한 액세스를 얻기 위하여 네트워크와 재인증하여야 한다. 재인증은 네트워크로 하여금 이동 장치가 네트워크에 진입하도록 허용되는지 여부를 검증하게 하는 보안 키들을 제시하는 것을 포함할 수 있다. 소정의 양상들에 따라, 이동 장치는 보안 키들의 상이한 세트를 통해 또는 네트워크 액세스를 재취득하는 다른 방식들을 통해 네트워크로의 액세스를 얻도록 시도할 수 있다.

세션 종료 에러(close of session error)는 심각한 동작인데, 그 이유는 이동 장치가 그것의 보안 인증서들을 재확립할 수 있을 때까지 네트워크에 대한 액세스를 갖는 것이 허용되지 않기 때문이다. 그리하여, 세션 종료 에러를 전송할 때, 세션 종료 모듈(310)은 CRC 에러 검출 패턴을 포함할 수 있다. CRC는 다수 회 교대하는 "1"들과 "0"들의 x-비트 스트링일 수 있는데, 여기서, x는 정수이고, 소정의 양상들에 따라 x는 16이다. 그리하여, 만약 물리적 계층 패킷에 에러가 존재하면, 이러한 사전 정의된 패턴은 이동 장치가 예상하는 것과 매칭되지 않을 수 있고, 세션의 잘못된 종료들을 경감할 수 있다(예를 들어, 그 결과 세션은 링크 에러로 인하여 종료되지 않음). 이동 장치가 이러한 에러를 수신함과 거의 동시에, 만약 CRC 패턴이 매칭된다면, 이동 장치는 CloseSession으로 돌아가고, CloseSession은 세션을 종료하기 위해 세션 제어 프로토콜(Session Control Protocol; SCP)에 의해 이용된다.

라우트 존재 모듈(route existence module)(312)은 이동 장치가 기지국(302)과 기존의 라우트를 갖지 않는지 여부를 결정할 수 있다. 이러한 결정은 라우트 형성 헤더를 포함하지 않는 패킷을 수신하여 라우트가 이동 장치와 확립되어 있지 않음을 결정하는 것에 기초하여 이루어질 수 있다. 이동 장치는 이러한 에러가 발생할 때 개방-대기 상태 밖에 있다. 이러한 시나리오는 이동 장치가 파일럿 파형을 수신하고 파일럿 파형이 이미 관계가 확립되어 있는 기존의 기지국들 중 하나에 속한다고 믿을 때 발생할 수 있다. 그러나, 파일럿 파형들은 관계가 확립되어 있지 않은 기지국에 속한다. 만약 라우트가 존재하지 않는다면, 라우트 존재 모듈(312)은 라우트가 기지국(302)에 속하지 않음을 표시도록 에러 코드 비트를 설정한다. 소정의 양상들에 따라, 이러한 에러 코드는 "0011"에 의해 표시된다.

라우트는 존재하지 않고, 에러 코드는 지속성 라우트 컨셉(persistent route concept)으로 인하여 일어날 수 있다. 이동 장치가 유휴 상태(예를 들어, 아무런 데이터도 교환되고 있지 않음)에 있는 소정의 경우들에서, 이동 장치는 하나의 지속성 라우트(SRNC 라우트로서 지칭됨)를 갖는다. 이동 장치가 유휴 상태를 벗어나 접속을 확립하려고 시도할 때, 이동 장치는 특정 기지국(예를 들어, 이동 장치가 강한 신호를 수신하고 있는 기지국)에 접속하려고 시도하고 있다. 이동 장치는 이러한 기지국이 자신이 이전에 존재하는 라우트를 갖고 있는 동일한 기지국인지 아니면 새로운 기지국인지를 결정한다. 만약 기존의 라우트가 있는 것으로 믿으면, 이동 장치는 라우트 형성 헤더를 전송하지 않을 것이고 터널 또는 라우트가 이미 확립되어 있음을 가정할 것이다. 이동 장치는 상기 라우트가 이미 확립되어 있는 것처럼 패킷들을 보내기 시작할 것이다. 그러나, 소정의 경우들에, 이동 장치는 실수를 하여, 그것은 이동 장치가 확립된 라우트를 갖고 있었던 기지국과 동일한 기지국이 아니고, 그것은 새로운 기지국이다. 새로운 기지국은 새로운 기지국이 이동 장치와의 라우트도 갖지 않고 새로운 기지국이 해당 이동 장치에 대한 어떠한 지식도 갖지 않음을 이동 장치에 표시할 수 있고, 라우트 형성 헤더를 요청할 수 있다.

이러한 상황들은 이동 장치가 경계 영역에 있을 때 일어날 수 있다. 이동 장치는 처음에 소스 기지국과의 라우트를 형성했었으나 그 다음 이동 장치는 해당 기지국과의 접촉을 잃어버릴 수 있다. 그러나, 이동 장치는 유사한 주파수 및/또는 파일럿 pn을 갖는 새로운 기지국의 커버리지에 들어오고, 마치 새로운 기지국이 기존의 기지국인 것처럼 새로운 기지국에 정보를 전송하기 시작한다. 그러나 새로 운 기지국과의 어떠한 접속도 존재하지 않는다. 이러한 에러 코드를 수신함과 거의 동시에, 이동 장치는 새로운 기지국과 통신하기 위해 새로운 라우트를 형성할 수 있다.

또한, 이동 장치의 단말 식별자가 변경되었는지를 결정할 수 있고 만약 변경이 있었다면 UATI 실패 에러 코드(UATI failure error code)가 송신될 수 있는 UATI 실패 모듈(314)이 포함된다. 소정의 양상들에 따라, 이러한 에러 코드는 "0100"에 의해 정의된다. 소정의 양상들에 따라, 이동 장치의 식별은 세션 기준 네트워크 제어기로부터 수신된 정보에 기초하여 실패할 수 있다. 이러한 상황은 이동 장치의 UATI(단말 식별자)가 새로운 라우트가 형성됨과 거의 동시에 변경되고 있을 때 일어날 수 있다. 예를 들어, 이동 장치가 멀리 있는 기지국(예를 들어, 2차 기지국)과의 새로운 라우트 또는 터널을 셋업하려고 시도할 때, 이동 장치는 라우트 형성 프로세스에 자신 고유의 UATI를 포함하지 않는다. UATI는 백 홀(back haul)을 통해 기지국들 간에 공유된다. 이동 장치가 직접 접속되어 있는 기지국(예를 들어, 1차 기지국)은 이동 장치에 의해 식별된 새로운 기지국으로 정보를 전달한다. 만약 UATI가 변경되었다면, 새로이 부가된 기지국은 UATI가 더 이상 유효하지 않음을 표시하기 위하여 에러 코드를 전송할 수 있다. 에러 코드를 수신함과 거의 동시에, 이동 장치는 UATIFailed 표시(라우트를 파기하기 위하여 RCP에 의해 사용됨)를 반환(return)한다. 이동 장치는 UATI가 업데이트된 이후에 이러한 기지국에 새로운 라우트를 형성할 수 있다.

소정의 양상들에 따라, IRTP 헤더들과 관련하여, 기지국(302)은 RouteMap이 수신될 때까지 액세스 노드 식별자(ANID) 헤더를 이용하지 않는다. 만약 기지국(302)이 RouteID 헤더를 수신하고 기지국이 RouteID를 인식하지 못한다면, 이하가 일어난다. 만약 RCP가 개방-대기 상태에 있다면, 기지국은 SessionAnchor 라우트의 라우트 프로토콜에 대한 페이로드(Payload to the Route Protocol)를 전달한다. 그렇지 않으면, 기지국은 현재의 라우트 맵을 질의하기 위하여 이동 장치로 RouteMapRequest 메시지를 전송한다.

소정의 양상들에 따라, RouteID 헤더(짧은 어드레스)는 이동 장치로부터 수신될 수 있으나, 서빙 기지국은 RouteID 헤더를 인식하지 못한다. 이러한 상황에서, 서빙 기지국은 현재의 라우트 맵을 요구하는 이동 장치로 RouteMapRequest 메시지를 전송할 수 있다. 소정의 양상들에 따라, 목적지 라우트에 대한 ANID 대 RouteID 맵핑을 포함하는 RouteMap 메시지가 이러한 액세스 네트워크(예를 들어, 기지국)로 전송되지 않았다면, 이동 장치는 목적지 라우트에 대하여 RouteID 헤더를 사용하지 않는다.

개시된 양상들을 완전히 인식시키기 위하여, 도 4는 라우트 프로토콜 패킷들(400 및 402)에 대한 2가지 예들을 도시한다. 라우트 프로토콜 패킷(400)은 라우트 프로토콜 페이로드(404) 및 라우트 프로토콜 헤더(406)를 포함한다. 라우트 프로토콜 패킷(402)은 라우트 프로토콜 헤더(406)를 포함한다. 라우트 프로토콜 패킷(400, 402)은 이러한 라우트와 연관된 프로토콜 스택(Protocol Stack) 또는, 이러한 또는 또 다른 라우트의 인터-라우트 터널링 프로토콜들을 식별하기 위해 이용되는 파라미터들을 운반하기 위하여 라우트 프로토콜 헤더(406)를 부가한다. 라 우트 프로토콜 패킷(400, 402)은 또한 전송을 위한 라우트 프로토콜 패킷들이 이러한 라우트의 패킷 병합 프로토콜 또는, 이러한 또는 또 다른 라우트의 인터-라우트 터널링 프로토콜로 전달되어야 하는지 여부를 결정할 수 있다. 라우트는 액세스 네트워크와 연관된 InUse 프로토콜 스택을 포함한다.

상기 프로토콜(400, 402)은 ATIReceived(ATIType, ATI, RouteStatus), 퍼스널리티 실패(Personality Failure), RouteExists, RouteReopen, UATIFailed, RouteDoesNot Exist를 포함할 수 있는 여러 다양한 표시들을 반환할 수 있다. 소정의 양상들에 따라, 상기 프로토콜(400, 402)은 이러한 프로토콜에 대한 서브타입(subtype), 최종 송신된 ATI(이동 장치 전용), 정적 속성, 정적 비-속성 데이터 및 로컬 공통 데이터(Local Common Data)를 공개할 수 있다. 상기 프로토콜(400)은 위의 계층(예를 들어, 스트림 프로토콜 패킷(408))으로부터 패킷들을 취하고 그것을 아래의 계층(예를 들어, 패킷 병합 프로토콜(410))로 전달한다.

도 5는 예시적인 라우트 프로토콜 헤더들(500) 및 이러한 여러 헤더들이 어떻게 상호작용하는지를 도시한다. 여러 다양한 필드들에 관한 세부사항들은 이제 예시적인 라우트 프로토콜 헤더들(500)을 논의하기 이전에 논의될 것이다. 이러한 필드들의 명명 규칙(naming convention)들, 길이들 및 설정들은 예시적인 목적을 위한 것이고 다른 명명 규칙들, 길이들 및/또는 설정이 개시된 양상들과 이용될 수 있다.

라우트 프로토콜 헤더는 길이가 약 1 비트일 수 있는 ExtendedHeaderIncluded 필드를 가질 수 있다. 만약 하나 이상의 HeaderElement 레코드들이 포함되면, 전송자(sender)는 ExtendedHeaderIncluded 필드를 "1"로 설정할 수 있다. 그렇지 않으면, 전송자는 이러한 필드를 "0"으로 설정할 수 있다. 만약 ExtendedHeaderIncluded 필드가 "1"로 설정되면, 전송자는 MoreHeader 또는 HeaderType인, 다음의 HeaderElement 레코드의 하나 이상의 발생들을 포함하여야 한다. 그리하여, 라우트 프로토콜 헤더는 0 또는 그 이상의 HeaderElement의 인스턴스들을 가질 수 있고, 상기 HeaderElement는 소정의 양상들에 따라 길이가 8n 비트일 수 있다.

HeaderElement 포맷은 길이가 약 1 비트일 수 있는 MoreHeader 필드를 포함할 수 있다. 만약 이러한 HeaderElement 레코드를 뒤따르는 또 다른 HeaderElement 레코드가 존재한다면, 전송자는 MoreHeader 필드를 "1"로 설정할 수 있다. 그렇지 않으면, 전송자는 이러한 필드를 "0"으로 설정할 수 있다.

HeaderElement 포맷은 길이가 대략 3 비트인 HeaderType 필드를 포함할 수 있다. 이러한 필드는 전송자에 의해 HeaderElement 레코드의 타입을 표시하도록 설정된다. 만약 HeaderType 값이 000(이진수)이면, 역방향 링크에 대해 RouteCreation이 설정된다. 만약 HeaderType 값이 001이면, ATI HeaderElement 레코드가 설정된다. 만약 HeaderType이 010이면, 순방향 링크에 대하여 ErrorCode HeaderElement 레코드가 설정된다. 다른 값들에 대하여, 예비(Reserved) HeaderElement 레코드가 설정된다.

HeadeElement 포맷에는 또한 가변 길이를 가질 수 있는 HeaderTypeSpecific 필드들 및 예비 필드가 포함될 수 있고, 예비 필드는 필요에 따라 길이가 0부터 약 7 비트까지일 수 있다.

만약 HeaderType 필드가 "000"으로 설정되면, 이동 장치는 가변 길이 HeaderTypeSpecific 필드들을 포함할 수 있다. 이러한 필드들은 길이가 대략 1 비트인 PSIIncluded 필드를 포함할 수 있다. 만약 PSI가 이러한 헤더에 포함된다면, PSIIncluded 필드는 이동 장치에 의해 "1"로 설정된다. 만약 IPSI 및 PersonalityIndex 필드들이 이러한 헤더에 포함되면, 이동 장치는 PSIIncluded 필드를 "0"으로 설정한다.

길이가 0 또는 약 4비트인 IPSI 필드는 또 다른 HeaderTypeSpecific 필드이다. 만약 PSIIncluded 필드가 "1"로 설정되면, 이동 장치는 IPSI 필드를 생략할 수 있다. 그렇지 않으면, 이동 장치는 이러한 필드를 포함한다. 이동 장치는 ISPI 필드를 라우트에 대해 선택된 퍼스널리티에 대응하는 InitialProtocolSetIdentifier로 설정한다. 이러한 라우트에 대해 선택된 퍼스널리티가 저장된 퍼스널리티에 대응할 때, 이러한 필드는 저장된 퍼스널리티와 연관된 InitialProtocolSetIdentifier로 설정된다.

길이가 0 또는 약 4 비트일 수 있는 PersonalityIndex가 또한 포함된다. 만약 PSIIncluded 필드가 "1"로 설정되면, 이동 장치는 PersonalityIndex를 생략한다. 그렇지 않으면, 이동 장치는 이러한 필드를 포함한다. 이러한 필드가 포함된다면 이러한 필드는 이러한 라우트에 대해 선택된 퍼스널리티의 PersonalityIndex로 설정된다. 이러한 라우트에 대해 선택된 퍼스널리티가 저장된 퍼스널리티(예를 들어, IPSI)에 대응하지 않는다면, 이동 장치는 이 필드를 "1111"으로 설정한다.

PSI 필드는 길이가 0 또는 대략 16 비트이다. 만약 PSIIncluded 필드가 "0"으로 설정된다면, 이동 장치는 이 필드를 생략한다. 그렇지 않으면, 이동 장치는 이 필드를 포함한다. 이러한 필드가 포함된다면, 이동 장치는 이러한 필드를 이러한 라우트에 대해 선택된 퍼스널리티에 대응하는 ProtocolSetIdentifier로 설정한다.

부가하여, HeaderTypeSpecific 필드들은 길이가 약 7 비트인 RouteID를 포함할 수 있다. 이동 장치는 RouteID 필드를 이러한 라우트에 할당된 RouteID(라우트 제어 프로토콜의 RouteID 공용 데이터(public data))로 설정한다.

길이가 약 1 비트인 DeleteOldRoutes 필드가 또한 포함될 수 있다. 액세스 네트워크가 이러한 이동 장치로의 임의의 기존 라우트가 존재하는 경우 기존의 라우트들을 소거하여야 한다면, 이동 장치는 이러한 필드를 "1"로 설정한다.

HeaderType 필드가 "001"로 설정되면, 전송자는 길이가 약 2 비트인 ATIType 필드를 포함한다. 전송자는 이러한 필드를 이하와 같이 설정한다. 만약 ATIType이 "00" 또는 "01"이라면, ATIType 기술(Description)이 보류된다. 만약 ATIType이 "10"이라면, 유니캐스트 ATI(UATI)의 ATIType 기술은 길이가 약 128 비트이다. ATIType이 "11"이면, ATIType 기술은 랜덤 ATI(RATI)이고 길이가 대략 128 비트이다.

길이가 약 128 비트인 ATI 필드가 또한 포함된다. 만약 ATIType 필드가 "10"으로 설정되면, 전송자는 이 필드를 이러한 이동 장치에 대응하는 UATI(예를 들어, 라우트 제어 프로토콜의 CurrentATI 공용 데이터)로 설정한다. 만약 ATIType 필드가 "11"로 설정되면, 전송자는 이러한 필드를 이러한 이동 장치에 대응하는 RATI(예를 들어, 라우트 제어 프로토콜의 CurrentATI 공용 데이터)로 설정한다. 또한 길이가 약 2 비트인 SessionSignatureLSB가 포함된다. 전송자는 이러한 필드를 SessionSignature의 2개의 LSB들로 설정한다.

만약 HeaderType 필드가 "010"으로 설정되면, 액세스 네트워크는 이하의 가변-길이 레코드를 포함한다. ErrorCode 필드는 길이가 약 4비트이다. 액세스 네트워크는 에러 코드를 표시하기 위하여 이하와 같이 ErrorCode 필드를 설정한다. 만약 ErrorCode가 0000(이진수)이면, 그것은 퍼스널리티가 지원되지 않음을 표시한다. 에러 코드 0001은 라우트가 존재함을 표시한다. 에러 코드 0010은 세션 종료를 표시한다. 에러 코드 0011은 라우트가 존재하지 않음을 표시한다. 에러 코드 0100는 UATI가 실패하였음을 표시한다. 다른 에러 코드 값들은 보류된다.

길이가 0 또는 약 7 비트인 RouteID가 또한 포함될 수 있다. 만약 ErrorCode 필드가 "0001"로 설정되지 않는다면 액세스 네트워크는 RouteID 필드를 생략한다. 그렇지 않으면, 액세스 네트워크는 이 필드를 포함하고, 그것을 기존의 라우트에 대응하는 RouteID로 설정한다.

길이가 0 또는 16 비트인 CRCErrorDetectPattern이 또한 포함될 수 있다. 만약 ErrorCode 필드가 "0010"으로 설정되지 않는다면, 액세스 네트워크는 이러한 필드를 생략한다. 그렇지 않으면, 액세스 네트워크는 이 필드를 포함하고, 그것을 "1010101010101010"으로 설정한다.

전송자는 이러한 HeaderElement 레코드를 옥텟 정렬(octet-aligned)되게 하 기 위하여 0 내지 7 비트 필드를 포함한다. 전송자는 이러한 비트들을 0으로 설정한다. 수신자는 이러한 비트들을 무시한다.

도 5를 다시 참조하면, 스트림 프로토콜 패킷(504) 및 포함된 확장된 헤더(ExHeaderIncl) 필드(506)를 포함하는 라우트 프로토콜 패킷(502)이 도시된다. 이러한 패킷(502)에서, ExHeaderIncl 필드는 "0"으로 설정되고, "0"은 확장된 헤더가 포함되지 않음을 표시한다.

라우트 형성 헤더(508)를 가진 라우트 프로토콜 패킷이 또한 도시된다. 이러한 패킷(508)은 스트림 프로토콜 패킷(504) 및 ExHeaderIncl 필드(506)를 포함하고, ExHeaderIncl 필드(506)는 이러한 패킷(508)에 대하여 포함된 확장된 헤더가 있음을 표시하기 위해 "1"로 설정된다. 또한 포함된 또 다른 필드는 "0"으로 설정된 More 필드(508)이다. More 필드는 하나보다 많은 수의 헤더가 동시에 포함되는지 또는 동일한 패킷에 하나보다 많은 수의 헤더가 존재할 수 있는지 여부를 표시한다. Type 필드(510)는 헤더가 라우트 형성 헤더임을 나타내기 위하여 "라우트 형성"으로 설정되고, Value 필드(512)는 라우트 형성 필드들을 표시한다. 또한 예비 필드(514)가 포함된다.

라우트 형성 및 ATI 헤더들(516)을 갖는 라우트 프로토콜 패킷은 스트림 프로토콜 패킷(504) 및 ExHeaderIncl 필드(506)를 포함하고, ExHeaderIncl 필드(506)는 "1"로 설정된다. 또한 1로 설정된 More 필드(508) 및 라우트 형성을 표시하는 Type 필드(510)가 포함된다. 또한 라우트 형성 필드들을 표시하는 Value 필드(512)가 포함된다. 이러한 패킷(516)은 또한 2개의 예비 필드(514)를 포함한다. "0"으로 설정된 제 2 More 필드(520) 및 UATI를 표시하는 Type 필드(522)가 더 포함된다. 또한 UATI로 설정된 Value 필드(524)가 포함된다.

소정의 양상들에 따라, 하나보다 많은 수의 패킷 병합 프로토콜 패킷이 단일의 MAC 패킷에 실릴 것이라면, MAC 패킷내의 첫 번째 패킷 병합 패킷을 제외한 모든 패킷 병합 패킷들에서의 HeaderElement 레코드들이 생략될 수 있다. 이것은 다수의 패킷들이 함께 전송되고 있고 그들 모두가 동일한 헤더를 공유하는 경우 오버헤드를 경감할 수 있다. 이동 장치는 최적화를 수행할 수 있고 제 1 패킷에 헤더만을 포함한다. 그것은 효율성을 개선하거나 시스템을 최적화시키기 위해 무선 상의 자원들을 절약할 수 있다.

526에서, 에러 코드 헤더를 가진 라우트 프로토콜 패킷이 도시된다. 패딩('0000000') 필드(528), 예비 필드(514) 및 ExHeaderIncl 필드(506)가 포함되고, ExHeaderIncl 필드(506)는 "1"로 설정된다. 또한 "0"으로 설정된 More 필드(508) 및 "에러 코드"로 설정된 Type 필드(510)가 포함된다. 이러한 패킷(526)에 대하여, Value 필드(512)가 에러 코드 특정 필드(ErrorCode Specific Field)들로 설정된다.

앞서 도시되고 기술된 예시적인 시스템들의 관점에서, 개시된 본 발명에 따라 구현될 수 있는 방법들이 이하의 흐름도들을 참조하여 더 잘 이해될 것이다. 설명의 단순화를 위하여 방법들이 일련의 블록들로서 도시되고 기술되었지만, 청구된 본 발명이 블록들의 개수나 순서에 의해 제한되지 않음이 이해되고 인식되어야 하며, 소정의 블록들은 본 명세서에서 도시되고 기술된 것으로부터 다른 블록들과 다른 순서로 그리고/또는 거의 동시에 일어날 수 있다. 더욱이, 이하에서 기술된 방법들을 구현하기 위해 도시된 블록들이 모두 다 요구되지 않지 않을 수도 있다. 블록들과 연관된 기능성은 소프트웨어, 하드웨어, 이들의 조합 또는 임의의 다른 적합한 수단(예를 들어, 장치, 시스템, 프로세스, 컴포넌트)에 의해 구현될 수 있음이 이해되어야 한다. 부가적으로, 이하에서 그리고 본 명세서 전체를 통해 개시된 방법들은 그러한 방법들을 여러 다양한 장치들로 이송 및 전달하는 것을 촉진하기 위하여 제조물 상에 저장될 수 있다. 당업자들은 하나의 방법이 대안적으로 예컨대, 상태도에서 일련의 상호관련된 상태들 또는 이벤트들로서 표현될 수 있음을 이해하고 인식할 것이다.

도 6은 이동 장치와 기지국 사이의 터널 관계를 형성하기 위한 방법(600)을 도시한다. 터널 관계들은 이동 장치가 중앙 제어기 없이 독립적으로 개별적인 셀 사이트들(예를 들어, 기지국들)과 통신할 수 있게 함으로써 플랫 네트워크 아키텍처(flat network architecture)들을 가능케 할 수 있다. 멀티-라우트 접근법은 또한 이동 장치과 기지국의 통신, 및 기지국 인터페이스들 간의 통신들을 단순화할 수 있다.

방법(600)은 602에서 터널을 통해 통신을 확립할 적어도 하나의 기지국을 선택할 때 시작한다. 이러한 결정은 이동 장치가 직접 접속가능성을 갖지 않는 기지국으로부터 검출된 파일럿 파형에 기초하여 할 수 있다. 터널은 이동 장치로부터, 이동 장치가 직접 접속가능성을 갖는 기지국(예를 들어, 1차 기지국)을 통해 하나 이상의 2차 기지국들로 확립될 수 있다.

604에서, 라우트 형성 헤더를 포함하는 메시지가 하나 이상의 선택된 기지국들로 송신된다. 이러한 메시지는 1차 기지국을 통해 전송될 수 있다. 라우트 형성 헤더는 터널을 정의하는 것과 연관된 하나 이상의 파라미터들을 포함한다. 라우트 형성 헤더에는 여러 다양한 필드들이 포함되고, 이러한 여러 다양한 필드들은 액세스 단말 식별자(ATI), 퍼스널리티 선택, 라우트의 라우트 식별, 기존의 라우트들이 소거되어야 하는지 여부 등을 포함할 수 있다. 예를 들어, 상기 적어도 하나의 기지국으로의 터널에 대한 식별자가 형성될 수 있고 터널에 대한 퍼스널리티가 선택될 수 있으며, 여기서 퍼스널리티는 하나 이상의 프로토콜 타입들 및 하나 이상의 속성 값들을 포함한다. 터널 식별자 및 선택된 퍼스널리티는 라우트 형성 헤더에 포함될 수 있다. 새로운 라우트가 형성되어야 할 때, 이동 장치는 "개방-대기" 상태에 있다. 이러한 상태는 형성되고 있는 패킷 또는 터널의 확인(confirmation)이 (2차) 기지국으로부터 아직 수신되지 않았음을 표시한다.

소정의 양상들에 따라, 메시지를 송신하는 단계는 하나 이상의 패킷 병합 프로토콜 패킷들이 단일의 MAC 패킷에 실려야 하는지를 결정하는 단계를 포함한다. 각각의 패킷 병합 프로토콜 패킷은 헤더 엘리먼트 레코드를 포함한다. 그리하여, 패킷 병합 프로토콜 패킷들 중 하나를 제외한 모든 패킷 병합 프로토콜 패킷들로부터의 헤더 엘리먼트 레코드들이 생략될 수 있고, 이것은 자원들을 절약하고 효율을 개선할 수 있다.

소정의 양상들에 따라, 라우트 제어 프로토콜은 새로운 프로토콜 스택의 퍼스널리티를 기술하기 위하여 InitialProtocolSetIdentifier 또는 PersonalityIndex 를 선택한다. 이러한 파일럿에 대응하는 오버헤드 정보가 이용가능하다면, 선택된 퍼스널리티에 대응하는 InitialProtocolSetIdentifier는 이러한 파일럿에 대응하는 액세스 네트워크에 의해 광고(advertise)되는 InitialProtocolSetIdentifier 값들 중 하나와 같고; 그렇지 않으면, 액세스 단말은 실행-정의된 결정에 기초하여 InitialProtocolSetIdentifier 또는 PersonalityIndex를 선택할 수 있다.

상기 방법(600)은 라우트 형성 헤더의 확인을 대기할 수 있다. 606에서, 터널 요청의 확인이 (2차) 기지국으로부터 수신되었는지 여부에 대한 결정이 이루어진다. 확인은 이동 장치와 기지국 사이의 터널 관계의 형성을 표시한다. 확인은 상기 적어도 하나의 기지국으로부터 패킷을 수신하는 것을 포함할 수 있다. 상기 확인이 수신되지 않으면 "NO", 608에서 하나 이상의 에러 코드들이 수신되었는지 여부에 대한 결정이 이루어진다. 아무런 에러 코드도 수신되지 않았다면 "NO", 방법은 604에서 상기 메시지가 재송신되는 때 계속된다. 하나 이상의 에러 코드들이 수신되었다면, "YES", 610에서 에러 코드들이 교정되고 방법은 604에서 계속된다. 이러한 에러 코드들에 대한 추가 정보가 이하에서 제공될 것이다.

만약 606에서 확인이 수신된다고 결정하면, "YES", 612에서 확인이 라우트 형성 헤더에서 이동 장치에 의해 송신된 ATI 필드로 설정된 ATI 필드를 포함하는 (2차) 기지국으로부터 헤더를 수신하는 것을 포함하는지 여부에 대한 결정이 이루어진다. 만약 ATI 필드들이 매칭되면, "YES", 그것은 (2차) 기지국이 이러한 이동 장치를 인식함을 표시한다. 만약 상기 필드들이 매칭되지 않는다면, 기지국은 이동 장치를 인식하지 못한다. 소정의 양상들에 따라, ATI 필드들이 매칭되지 않는 다면, 라우트 형성 헤더가 604에서 재송신된다.

만약 ATI 필드들이 612에서 매칭되면("YES"), 방법(600)은 하나 이상의 에러 코드들이 2차 기지국에 의해 전송된 패킷에서 수신되는지 여부에 관한 결정이 이루어지는 614에서 계속된다. 이러한 에러 코드들은 이동 장치에 의해 제안된 퍼스널리티가 기지국에 의해 지원되지 않음 및 기지국과 이동 장치 사이의 라우트 또는 터널이 이미 존재함을 포함할 수 있다. 또 다른 에러 코드는 기지국(또는 네트워크)이 여러 원인들로 인하여 세션을 종료하기 원함을 표시할 수 있다. 다른 에러 코드들은 비록 이동 장치가 오해하여 라우트가 존재하였다고 생각할지라도 기지국과 이동 장치 사이의 라우트가 존재하지 않는다는 표시 및 UATI 실패를 포함한다. 소정의 양상들에 따라, 하나보다 많은 수의 에러 코드가 기지국에 의해 이동 장치로 운반될 수 있다.

만약 어떠한 에러 코드들로 수신되지 않는다면 "NO", 방법(600)은 "개방-대기" 상태 밖으로의 전이를 갖는 616에서 계속된다. 614에서 하나 이상의 에러 코드들이 수신된다면("YES"), 에러 코드들이 610에서 교정될 수 있고, 업데이트된 라우트 프로토콜 헤더를 갖는 메시지가 604에서 전송될 수 있다.

에러의 타입은 퍼스널리티 에러일 수 있고, 퍼스널리티 에러는 기지국으로부터의 패킷에서 수신될 수 있고, 상기 패킷은 퍼스널리티 에러 코드를 포함한다. 퍼스널리티 에러는 상기 패킷으로 수신된 랭크된 퍼스널리티들의 리스트를 검토함으로써 교정될 수 있고, 상기 리스트는 기지국에 의해 지원되는 퍼스털리티들을 포함한다. 이러한 퍼스널리티들은 이동 장치 및/또는 기지국의 기준들에 기초하여 기지국에 의해 랭크될 수 있다. 랭킹은 선호도의 순서를 포함할 수 있다. 퍼스널리티는 기지국에 의해 지원되는 퍼스널리티들의 리스트로부터 선택된다. 라우트 형성 헤더 패킷은 선택된 퍼스널리티를 포함하도록 수정될 수 있고 수정된 라우트 형성 헤더 패킷은 604에서 기지국으로 송신될 수 있다.

패킷에서 수신된 에러의 또 다른 타입은 세션 종료 에러일 수 있다. 상기 패킷은 또한 CRCErrorDetectPattern을 포함할 수 있다. 이러한 경우에, 이동 장치는 기지국을 포함하는 네트워크와 네트워크 접속을 재확립하려고 시도할 수 있다. 만약 CRCErrorDetectPattern이 세션 종료 에러 코드가 링크 에러로 인한 것이 아님을 표시하면 네트워크에 대한 재인증이 확립될 수 있다.

상기 패킷에 포함된 또 다른 에러 코드는 라우트가 기지국과 이미 확립되어 있음을 표시할 수 있다. 확립된 라우트의 라우트 식별이 상기 패킷에 포함된다. 이러한 경우, 관계가 이미 존재하기 때문에 이동 장치와 기지국과의 터널 관계가 필요하지 않음이 결정될 수 있다. 그리하여, 방법(600)은 604에서 새로운 메시지를 전송하기보다는 오히려 종료할 수 있다.

에러의 추가 타입은 에러 코드에 의해 표시되는 바와 같이, 라우트가 존재하지 않는다는 것이다. 이러한 경우에, 라우트 프로토콜 헤더는 해당 기지국으로의 라우트를 확립하기 위하여 기지국으로 전송될 수 있다. 만약 UATI 에러가 수신되면, 604에서 일단 확립된 정확한 ATI가 라우트 프로토콜 헤더에서 전송될 수 있다.

도 7은 터널을 통해 이동 장치와 기지국 사이의 통신을 확립하기 위한 방법(700)을 도시한다. 방법은 702에서 라우트 형성 프로토콜 헤더가 이동 장치로부 터 수신되는 때 시작된다. 라우트 형성 프로토콜 헤더는 터널을 정의하는 것과 연관된 하나 이상의 파라미터들을 포함할 수 있다. 이러한 헤더는 메시지에서 수신될 수 있고, 액세스 단말 식별자(ATI), 퍼스널리티 선택, 라우트의 라우트 식별, 기존의 라우트들이 소거되어야 하는지 여부 등과 같은 여러 다양한 정보를 포함할 수 있다.

소정의 양상들에 따라, RouteID 헤더(짧은 어드레스)는 이동 장치로부터 수신될 수 있으나, 기지국은 RouteID 헤더를 인식하지 못한다(예를 들어, RouteID 헤더와 ANID 사이의 어떠한 맵핑도 존재하지 않음). 이러한 상황에서, 기지국은 현재의 라우트 맵을 요청하면서 이동 장치로 RouteMapRequest 메시지를 전송할 수 있다. 소정의 양상들에 따라, 목적지 라우트에 대한 ANID 대 RouteID 맵핑을 포함하는 RouteMap 메시지가 이러한 액세스 네트워크(예를 들어, 기지국)로 전송되지 않았다면, 이동 장치는 이러한 목적지 라우트에 대한 RouteID 헤더를 사용하지 않는다.

704에서 라우트 형성 프로토콜 헤더 내의 필드에 의해 표시되는 대로 이동 장치가 폐쇄-대기 상태에 있는지 여부에 대한 결정이 이루어진다. 만약 이동 장치가 폐쇄-대기 상태에 있다면 "YES", 706에서, 개방 상태로 진입하기 위하여 라우트 재개방 표시가 이동 장치로 전송된다. 방법(700)은 메시지가 이동 장치로부터 수신되는 때 702에서 계속된다.

만약 이동 장치가 폐쇄-대기 상태에 있지 않다면("NO"), 708에서 헤더의 필드에서 표시되는 대로 이동 장치가 개방-대기 상태에 있는지 여부에 대한 결정이 이루어진다. 만약 이동 장치가 개방-대기 상태에 있지 않고 라우트 형성 헤더가 모든 라우트들 소거 플래그(Delete All Routes Flag)를 포함하지 않는다면, 710에서 헤더가 무시된다(이동 장치가 개방-대기 상태에도 있지 않고 폐쇄-대기 상태에도 있지 않기 때문). 소정의 양상들에 따라, 만약 이동 장치와의 라우트가 이미 확립되어 있다면, 헤더가 무시된다. 만약 이동 장치가 개방-대기 상태에 있다면, 712에서 모든 라우트들이 소거되어야 하는지 여부에 대한 결정이 이루어진다. 기존의 라우트들 소거 플래그가 설정되어야 하는지 여부를 특정할 수 있는 트리거들은 이동 장치가 무선 링크 프로토콜(Radio Link Protocol; RLP) 상태를 잃어버린 상황을 포함할 수 있다. 만약 모든 라우트들이 소거되어야 한다면("YES"), 714에서 기존의 라우트들 소거 명령이 발부(issue)되고 방법(700)은 새로운 라우트가 확립될 때까지 종료한다.

712에서 만약 기존의 라우트들이 소거되지 않아야 한다("NO")고 결정되면, 방법(700)은 에러 조건들이 체크되는 716에서 계속된다(만약 이동 장치가 개방-대기 상태에 있다면).

에러 조건은 이동 장치에 의해 제안된 퍼스널리티가 기지국에 의해 지원되지 않는지 여부일 수 있다. 퍼스널리티는 하나 이상의 타입들 및 하나 이상의 속성 값들을 포함한다. 만약 제안된 퍼스널리티가 지원되지 않는다면, 에러 코드는 라우트 형성 헤더에 응답하여 전송된다. 퍼스널리티는 하나 이상의 프로토콜 타입들 및 하나 이상의 속성 값들을 포함한다. 에러 코드가 전송됨과 거의 동시에, 리스팅 또는 추천된 퍼스널리티가 또한 수신된 라우트 형성 헤더에 응답하여 전송된 라 우트 프로토콜 메시지에서 전송될 수 있다. 이러한 리스팅은 선호도의 순서로 랭크될 수 있고, 여기서 더 선호되는 퍼스널리티가 먼저 열거된다. 소정의 퍼스널리티들이 더 높은 패킷 또는 데이터 레이트들을 획득할 수 있고 그러한 퍼스널리티들이 더 선호되기 때문에, 선호도는 성능에 기초하여 결정될 수 있다. 예를 들어, 소정의 퍼스널리티들은 상이한 애플리케이션들에 대해 미세-튜닝된다. 만약 이동 장치가 예를 들어, 비디오 컨퍼런스 장치라면, 그것은 상이한 퍼스널리티를 가질 수 있다. 기지국은 이동 장치가 실행하고 있는 애플리케이션들의 타입들 및 이동 장치의 능력들에 적용되는 기준에 기초하여 이러한 퍼스널리티들을 랭크할 수 있다. 랭킹은 이동 장치에 더 높은 데이터 레이트 또는 더 높은 성능을 제공할 퍼스널리티들을 표시할 수 있고, 이동 장치에 더 높은 데이터 레이트 또는 더 높은 성능을 제공할 퍼스널리티들은 먼저 열거된다. 이동 장치가 제 1 랭크된 퍼스널리티를 지원할 수 있다면, 그러한 것이 선택되고, 그렇지 않으면 이동 장치는 다음 랭크된 퍼스널리티 등을 사용하려고 시도한다. 그리하여, 선호도의 순서는 기지국(예를 들어, 기지국의 특성들)에 대해 특정되고 또한 이동 장치에 대해 특정된다. 소정의 양상들에 따라, 기지국은 제 1 이동 장치에 선호도의 특정 순서를 제공할 수 있고 또 다른 이동 장치에 선호도의 상이한 순서를 제공할 수 있다.

또 다른 에러 코드는 기지국와 이동 장치 사이의 라우트가 이미 존재하는지 여부이다. 이러한 상황에서는 또 다른 라우트를 형성할 필요가 없다. 이미 확립된 라우트의 라우트 식별은 라우트 형성 헤더에 응답하여 전송된 라우트 프로토콜 메시지에 포함될 수 있다.

또 다른 에러 코드는 이동 장치가 네트워크에 액세스하기 위해 필수적인 인증서들을 더 이상 갖는 않는 경우와 같이, 세션이 종료되어야 하는지 여부이다. 라우트가 종료되어야 함을 표시하는 명령들은 세션 기준 네트워크 제어기로부터 수신될 수 있다. 이러한 에러 코드가 전송됨과 거의 동시에, CRCErrorDetectPattern이 링크 에러로 인하여 종료되고 있는 세션의 가능성들을 경감하기 위해 전송될 수 있다.

만약 기지국과 이동 장치 사이의 라우트가 존재하지 않는다면, 또 다른 에러 코드가 전송된다. 이러한 상황은 이동 장치가 라우트가 존재한다고 믿지만 라우트가 확립되어 있지 않을 때 발생한다. 이러한 경우에, 에러 코드는 라우트가 존재하지 않음을 표시하는 라우트 프로토콜 메시지에 포함된다. 이러한 에러의 결정은 라우트 형성 헤더를 포함하지 않는 패킷을 수신하는 것 및 라우트가 이동 장치와 확립되어 있지 않음에 기초하여 이루어질 수 있다. 이동 장치는 이러한 에러가 발생할 때 개방-대기 상태를 벗어나 있다.

ATI가 매칭되지 않기 때문에 UATI가 실패하는 경우 추가 에러가 발생할 수 있다. 이것은 라우트가 확립되고 있는 동안 ATI가 변경되었다면 일어난다. 이동 장치는 이러한 에러 코드를 수신할 때 기지국과의 통신들을 확립하기 위하여 정확한 ATI를 공급할 수 있다. 이동 장치의 식별은 세션 기준 네트워크 제어기로부터 수신된 정보에 기초하여 실패할 수 있다.

소정의 상황들에서, 터널이 형성되고 있는 기지국(예를 들어, 2차 기지국)은 이동 장치의 가장 최근 식별자를 알지 못할 수도 있는데, 그 이유는 이동 장치의 어드레스가 변경되었기 때문이다. 어드레스가 변경되지 않은 경우들에, 서빙 기지국(예를 들어, 1차 기지국)은 상기 어드레스를 2차 기지국에 전달할 수 있다. 그러나 어드레스가 최근에 변경되었다면, 서빙 기지국은 어드레스의 변화를 알지 못할 수 있는데, 그 이유는 어드레스 변화가 서빙 기지국이 알지 못하는 SRNC(중앙 제어기)와 이동 장치 사이의 프로세스이기 때문이다. 예를 들어, 어드레스가 마지막 X초(여기서, X는 정수, 일 예에서 5) 내에 변경되었다면, 이동 장치는 라우트 형성 동안에 새로운 어드레스를 포함하고, 그렇지 않으면 상기 어드레스를 생략한다. 이것은 어드레스가 최근에 변경된 경우에 2차 기지국으로 하여금 이동 장치의 어드레스에 관한 가장 최근 정보를 갖게 하고, 어드레스가 최근에 변경되지 않은 경우들에는 어드레스를 포함하는 것의 오버헤드를 경감할 수 있다.

718에서, 라우트 프로토콜 메시지는 발견된 임의의 에러들 및 다른 기준들(예를 들어, ATI 필드)을 고려하여 형성된다. 라우트 프로토콜 메시지는 기지국과 이동 장치 사이의 관계(예를 들어, 터널)를 확립하기 위하여 720에서 이동 장치로 전송된다.

개시된 양상들을 보다 완전히 이해하기 위하여, 이하는 라우트 프로토콜 헤더들의 송신 및 수신에 관한 세부사항들을 제시할 것이다. 비록 이하의 설명이 개시된 양상들의 하나의 구현에 대한 특정 세부사항들을 제공할지라도, 다른 구현 기술들이 개시된 양상들과 함께 이용될 수 있다.

이하의 설명은 이동 장치의 견지에서의 송신 절차를 제시한다. 기본 라우트 프로토콜은 송신을 위한 스트림 프로토콜 패킷을 수신하거나 어떠한 페이로드도 갖 지 않는 라우트 프로토콜 패킷을 전송하기를 원한다. 이동 장치에서, MAC 계층으로 페이로드를 제공하고 어떠한 스트림 프로토콜 패킷도 이용가능하지 않을 때 라우트 프로토콜은 어떠한 페이로드도 갖지 않은 패킷을 전송한다. 이러한 상황에서, 기본 라우트 프로토콜은 이하에 기술된 절차를 수행할 수 있다. 기본 라우트 프로토콜은 하나 이상의 HeaderElement 레코드들이 부가되어야 하는지 여부를 결정함으로써 라우트 프로토콜 패킷을 형성하기 위해 라우트 프로토콜 헤더를 부가한다.

라우트 제어 프로토콜의 상태 공용 데이터가 개방-대기 상태에 있고 이동 장치가 이러한 라우트 상에서 액세스 네트워크로부터 어떠한 패킷들도 수신하지 않았다면, '000'의 HeaderType의 HeaderElement 레코드(예를 들어, RouteCreation 헤더)가 부가된다.

만약 '000'의 HeaderType(예를 들어, RouteCreation 헤더)의 HeaderElement 레코드가 부가되고 있다면, 이동 장치는 퍼스널리티를 형성할 수 있다. 만약 액세스 네트워크로부터의 계류 중인 퍼스널리티 교환 요청이 존재한다면, 이동 장치는 헤더의 PersonalityIndex 필드를 세션 제어 프로토콜의 PendingPersonalityIndex 공용 데이터의 값으로 설정한다. 만약 이동 장치가 RouteCreate 메시지에 응답하여 이러한 라우트를 형성하였다면, 이동 장치는 상기 헤더에 PSI 필드 또는 IPSI 및 PersonalityIndex 필드들을 포함할 수 있다. 그렇지 않으면, 이동 장치는 헤더에 IPSI 및 PersonalityIndex 필드들을 포함한다.

만약 접속된 상태 프로토콜의 상태 공용 데이터가 BindATI로 설정되고 이동 장치가 자신에 의해 전송된 것과 동일한 ATI 헤더를 포함하는 라우트 프로토콜 헤더를 액세스 네트워크로부터 수신하지 않았다면, '001'의 HeaderType의 HeaderElement 레코드(예를 들어, ATI 헤더)가 부가된다.

'001'의 HeaderType(예를 들어, ATI 헤더)의 HeaderElement 레코드가 부가되고 있다면, 이동 장치는 이하의 절차를 수행할 수 있다. 라우트 제어 프로토콜의 CurrentATI 공용 데이터가 UATI로 설정된다면, 이동 장치는 ATIType 필드를 '10'으로 설정하고 ATI 필드를 라우트 제어 프로토콜의 CurrentATI 공용 데이터로 설정한다. 만약 라우트 제어 프로토콜의 CurrentATI 공용 데이터가 RATI로 설정된다면, 이동 장치는 ATIType 필드를 '11'로 설정하고 ATI 필드를 라우트 제어 프로토콜의 CurrentATI 공용 데이터로 설정한다. 이동 장치는 LastTransmittedATI를 (ATIType 필드의 값|ATI 필드의 값)으로 설정한다.

하나보다 많은 수의 패킷 병합 프로토콜 패킷이 단일의 MAC 패킷에 실릴 것이라면, 기본 라우트 프로토콜은 MAC 패킷에 포함된 첫 번째 것을 제외한 모든 패킷 병합 프로토콜 패킷들에서의 HeaderElement 레코드들을 생략한다. 라우트 프로토콜은 이러한 절차를 수행하기 위하여 패킷 병합 프로토콜로부터의 정보를 사용한다.

만약에 임의의 HeaderElement 레코드들을 부가할 필요가 없다면, 기본 라우트 프로토콜은 ExtendedHeaderIncluded 필드를 '0'으로 설정한다. 그렇지 않으면, 기본 라우트 프로토콜은 ExtendedHeaderIncluded 필드를 '1'로 설정하고, 요구된 개수의 HeaderElement 레코드들을 부가한다. 소정의 양상들에 따라, 만약에 이것 이 어떠한 페이로드도 갖지 않는 라우트 프로토콜 패킷에 대응하면, 기본 라우트 프로토콜은 패딩 필드를 '0000000'로 설정할 수 있다.

만약 현재 역방향 링크 서빙 라우트(역방향 제어 채널 MAC 프로토콜의 RLSS 공용 데이터에 의해 표시되는 바와 같이)인 라우트가 존재하지 않는다면, 라우트 프로토콜은 AirlinkManagement.OpenConnection 명령을 발부한다. 그렇지 않으면, 라우트 제어 프로토콜은 이하를 수행할 수 있다. 만약 이러한 라우트가 역방향 링크 서빙 라우트(역방향 제어 채널 MAC 프로토콜의 RLSS 공용 데이터에 의해 표시되는 바와 같이)라면, 기본 라우트 프로토콜(Basic Route Protocol)은 라우트 프로토콜 패킷을 그것의 라우트의 패킷 병합 프로토콜로 전달하나, 라우트 프로토콜 패킷을 그것의 라우트의 인터-라우트 터널링 프로토콜로 전달할 수도 있다. 그렇지 않으면, 기본 라우트 프로토콜은 라우트 프로토콜 패킷을 역방향 링크 서빙 라우트(역방향 제어 채널 MAC 프로토콜의 RLSS 공용 데이터에 의해 표시되는 바와 같이)의 인터-라우트 터널링 프로토콜로 전달한다.

이하는 기지국의 견지에서의 예시적인 송신 절차를 제시할 것이다. 만약 기본 라우트 프로토콜이 송신을 위한 스트림 프로토콜 패킷을 수신하거나 어떠한 페이로드도 갖지 않는 라우트 프로토콜 패킷을 전송하기를 원한다면, 기본 라우트 프로토콜은 이하를 수행할 수 있다. 기본 라우트 프로토콜은 다음과 같이 라우트 프로토콜을 형성하기 위하여 라우트 프로토콜 헤더를 부가한다. 기본 라우트 프로토콜은 하나 이상의 HeaderElement 레코드들이 이하와 같이 부가되어야 하는지 여부를 결정한다. '010'의 HeaderType(예를 들어, ErrorCode 헤더)의 HeaderElement 레코드는 이하와 같이 포함될 수 있다.

액세스 네트워크는 하나 보다 많은 수의 '010'의 HeaderType(예를 들어, ErrorCode 헤더)의 HeaderElement 레코드를 포함하지 않는다. 만약 액세스 네트워크가 이동 장치로부터 RouteCreation 헤더를 수신하고 이동 장치에 의해 제안된 퍼스널리티가 액세스 네트워크에 의해 지원되지 않는다면, 액세스 네트워크는 ErrorCode 필드를 '0000'으로 설정한다. 만약 액세스 네트워크가 '0'으로 설정된 DeleteOldRoutes를 가진 RouteCreation 헤더를 이동 장치로부터 수신하고, 라우트가 이미 이러한 이동 장치에 대해 존재하며, 라우트 제어 프로토콜의 상태 공용 데이터가 폐쇄-대기 상태로 설정되지 않는다면, 액세스 네트워크는 ErrorCode 필드를 '0001'로 설정한다. 만약 액세스 네트워크가 세션을 종료할 것을 요청하고 있다면, ErrorCode 필드는 '0010'으로 설정된다. 만약 액세스 네트워크가 '000'의 HeaderType(예를 들어, RouteCreation 헤더)의 HeaderElement 레코드 없이 이동 장치로부터 '001'의 HeaderType(예를 들어, ATI 헤더)의 HeaderElement 레코드를 수신하고 액세스 네트워크가 SessionAnchor가 아니라면, 그리고 라우트가 이러한 이동 장치에 대해 존재하지 않는다면, 액세스 네트워크는 ErrorCode 필드를 '0011'로 설정한다.

만약 접속된 상태 프로토콜의 ProtocolState 공용 데이터가 BindATI로 설정되면, '001'의 HeaderType(예를 들어, ATI 헤더)의 HeaderElement 레코드가 포함된다. 액세스 네트워크는 ATIType 및 ATI 필드들을 이동 장치로부터 수신된 대응 값들로 설정한다.

만약 전술한 규칙들에 기초하여 임의의 HeaderElement 레코드들을 부가할 필요가 없다면, 기본 라우트 프로토콜은 ExtendedHeaderIncluded 필드를 '0'으로 설정한다. 그렇지 않으면, 기본 라우트 프로토콜은 ExtendedHeaderIncluded 필드를 '1'로 설정하고 요구된 개수의 HeaderElement 레코드들을 부가한다. 만약 이것이 어떠한 페이로드도 갖지 않는 라우트 프로토콜 패킷에 대응한다면, 기본 라우트 프로토콜은 패딩 필드를 '0000000'로 설정한다.

기본 라우트 프로토콜은 이하를 수행할 수 있다. 만약 이러한 라우트가 순방향 링크 서빙 라우트(역방향 제어 채널 MAC 프로토콜의 FLSS 공용 데이터에 의해 표시되는 바와 같이)라면, 기본 라우트 프로토콜은 라우트 프로토콜 패킷을 그것의 라우트의 패킷 병합 프로토콜로 전달할 수 있으나, 라우트 프로토콜 패킷을 그것의 라우트의 인터-라우트 터널링 프로토콜로 전달할 수도 있다. 그렇지 않으면, 기본 라우트 프로토콜은 라우트 프로토콜 패킷을 순방향 링크 서빙 라우트(역방향 제어 채널 MAC 프로토콜의 FLSS 공용 데이터에 의해 표시되는 바와 같이)의 인터-라우트 터널링 프로토콜로 전달한다.

이하의 설명은 이동 장치의 견지에서의 예시적인 수신 절차를 제시한다. 만약 기본 라우트 프로토콜이 그것의 라우트의 패킷 병합 프로토콜로부터, 또는 그것의 라우트나 또 다른 라우트의 인터-라우트 터널링 프로토콜로부터 라우트 프로토콜 패킷을 수신한다면, 기본 라우트 프로토콜은 이하를 수행할 수 있다. 기본 라우트 프로토콜은 이하와 같이 스트림 프로토콜 패킷 또는 패딩 필드를 생성하기 위하여 존재하는 라우트 프로토콜 헤더를 제거한다.

만약 '010'의 HeaderType(예를 들어, ErrorCode 헤더)의 HeaderElement 레코드가 '0000'으로 설정된 ErrorCode 필드와 함께 존재한다면, 기본 라우트 프로토콜은 PersonalityFailure 표시를 반환한다. 만약 '010'의 HeaderType(예를 들어, ErrorCode 헤더)의 HeaderElement 레코드가 '0001'로 설정된 ErrorCode 필드와 함께 존재한다면, 기본 라우트 프로토콜은 RouteExists 표시를 반환한다. 만약 '010'의 HeaderType(예를 들어, ErrorCode 헤더)의 HeaderElement 레코드가 '0010'으로 설정된 ErrorCode 필드와 함께 존재하고 CRCErrorDetectPattern 필드가 '1010101010101010'으로 설정된다면, 기본 라우트 프로토콜은 SessionControl.Deactivate 명령을 발부한다. 만약 '010'의 HeaderType(예를 들어, ErrorCode 헤더)의 HeaderElement 레코드가 '0011'로 설정된 ErrorCode 필드와 함께 존재한다면, 기본 라우트 프로토콜은 RouteDoesNotExist 표시를 반환한다. 만약 '010'의 HeaderType(예를 들어, ErrorCode 헤더)의 HeaderElement 레코드가 '0100'으로 설정된 ErrorCode 필드와 함께 존재한다면, 기본 라우트 프로토콜은 UATIFailed 표시를 반환한다.

기본 라우트 프로토콜이 ATIReceived(ATIType, ATI, RouteStatus) 표시를 반환한다. 이러한 표시는 접속 상태 프로토콜의 상태 공용 데이터가 Binding ATI와 같을 때 사용될 수 있다. 만약 이러한 표시가 이용되면, 인수(argument)들은 이하와 같이 설정될 수 있다. 만약 '001'의 HeaderType(예를 들어, ATI 헤더)의 HeaderElement 레코드가 존재하면, ATIType 및 ATI 인수들은 헤더에서 수신된 대응 값들로 설정될 수 있다. 만약 '001'의 HeaderType(예를 들어, ATI 헤더)의 HeaderElement 레코드가 존재하지 않는다면, ATIType 및 ATI 인수들은 NULL로 설정될 수 있다. 만약 '001'의 HeaderType(예를 들어, ATI 헤더)의 HeaderElement 레코드가 존재하지 않거나 '010'의 HeaderTypedml HeaderElement 레코드가 존재하였다면, RouteStatus는 0x1로 설정될 수 있다. 그렇지 않으면, RouteStatus는 0x0으로 설정될 수 있다.

만약 라우트 프로토콜 패킷이 '0000000'의 패딩 필드로 구성되고 스트림 프로토콜 페이로드로 구성되지 않는다면, 기본 라우트 프로토콜은 패딩 필드를 폐기한다. 그렇지 않으면, 기본 라우트 프로토콜은 스트림 프로토콜 패킷을 그것의 라우트의 스트림 프로토콜로 전달한다.

이하는 기지국의 견지에서의 예시적인 수신 절차를 제시한다. 만약 기본 라우트 프로토콜이 그것의 라우트의 패킷 병합 프로토콜로부터, 또는 그것의 라우트나 또 다른 라우트의 인터-라우트 터널링 프로토콜로부터 라우트 프로토콜 패킷을 수신하면, 기본 라우트 프로토콜은 이하를 수행할 수 있다. 기본 라우트 프로토콜은 이하와 같이 스트림 프로토콜 패킷 또는 패딩 필드를 생성하기 위해 존재하는 라우트 프로토콜 헤더를 제거한다.

만약 '001'의 HeaderType(예를 들어, ATI 헤더)의 HeaderElement 레코드가 존재하면, 기본 라우트 프로토콜은 ATI의 수신된 값으로 설정된 ATI와 ATIRecieved(ATIType, ATI, RouteStatus) 표시를 반환한다. 만약 '000'의 HeaderType(예를 들어, RouteCreation 헤더)의 HeaderElement 레코드가 존재하면, 액세스 네트워크는 이하를 수행할 수 있다. 만약 라우트 제어 프로토콜의 상태 공 용 데이터가 개방-대기 또는 폐쇄-대기와 같지 않다면, 액세스 네트워크는 이러한 헤더를 무시할 수 있다.

헤더가 무시되지 않는다면, 액세스 네트워크는 이하를 수행할 수 있다. 만약 DeleteOldRoutes 필드가 '1'로 설정된다면, 기본 라우트 프로토콜은 RouteControl.DeleteOldRoutes 명령을 발부한다. 만약 라우트 제어 프로토콜의 상태 공용 데이터가 폐쇄-대기로 설정되면, 라우트 프로토콜은 RouteReopen 표시를 반환한다.

만약 라우트 프로토콜 패킷이 '0000000'의 패딩 필드로 구성되고 스트림 프로토콜 페이로드로 구성되지 않는다면, 기본 라우트 프로토콜은 패딩 필드를 폐기한다. 그렇지 않으면, 기본 라우트 프로토콜은 스트림 프로토콜 패킷을 그것의 라우트의 스트림 프로토콜로 전달한다.

도 8을 참조하면, 이동 장치와 기지국 사에의 터널 관계를 형성하는 예시적인 시스템(800)이 도시된다. 시스템(800)은 이동 장치 내에 적어도 부분적으로 상주할 수 있다. 시스템(800)은 프로세서, 소프트웨어 또는 이들의 결합(예를 들어, 펌웨어)에 의해 구현되는 기능들을 나타내는 기능 블록들일 수 있는 기능 블록들을 포함하는 것으로서 표현된다.

시스템(800)은 별개로 또는 결합하여 동작할 수 있는 전기 컴포넌트들의 논리적 그룹핑(802)을 포함한다. 논리적 그룹핑(802)은 터널을 통해 통신을 확립하기 위한 적어도 하나의 기지국을 선택하기 위한 전기 컴포넌트(804)를 포함할 수 있다. 논리적 그룹핑에는 또한 라우트 형성 헤더를 포함하는 메시지를 적어도 하 나의 기지국으로 송신하기 위한 전기 컴포넌트(806)가 포함된다. 라우트 형성 헤더는 터널을 정의하는 것과 연관된 하나 이상의 파라미터들을 포함한다.

논리적 그룹핑(802)은 또한 라우트 형성 헤더(808)의 확인을 대기하기 위한 전기 컴포넌트(808)를 포함한다. 상기 확인은 적어도 하나의 기지국으로부터 패킷을 수신하는 것을 포함한다. 전기 컴포넌트(806)는 상기 확인이 수신될 때까지 라우트 형성 헤더를 포함하는 메시지를 상기 적어도 하나의 기지국으로 재송신할 수 있다. 부가하여, 논리적 그룹핑(802)은 상기 확인이 수신될 때 개방-대기 상태 밖으로 전이하기 위한 전기 컴포넌트(810)를 포함한다.

소정의 양상들에 따라, 논리적 그룹핑(802)은 2 이상의 패킷 병합 프로토콜 패킷들이 단일의 MAC 패킷에 실릴 것을 결정하기 위한 전기 컴포넌트들 포함한다. 각각의 패킷 병합 프로토콜 헤더 엘리먼트 레코드를 포함한다. 논리적 그룹핑(802)에는 또한 패킷 병합 패킷들 중 하나를 제외한 모든 것으로부터 헤더 엘리먼트 레코드를 생략하기 위한 전기 컴포넌트가 포함될 수 있다.

소정의 양상들에 따라, 논리적 그룹핑은 적어도 하나의 기지국으로부터 패킷을 수신하기 위한 전기 컴포넌트를 포함할 수 있다. 상기 패킷은 퍼스널리티 에러 코드를 포함한다. 상기 패킷으로 수신된 랭크된 퍼스널리티들의 리스트를 검토하기 위한 전기 컴포넌트 및 랭크된 퍼스널리티들의 리스트로부터 퍼스널리티를 선택하기 위한 전기 컴포넌트가 또한 포함된다. 부가하여, 논리적 그룹핑은 선택된 퍼스널리티를 포함하도록 라우트 형성 헤더 패킷을 수정하기 위한 전기 컴포넌트 및 수정된 라우트 형성 헤더 패킷을 적어도 하나의 기지국으로 송신하기 위한 전기 컴 포넌트를 포함할 수 있다.

소정의 양상들에 따라, 논리적 그룹핑(802)은 적어도 하나의 기지국으로부터 패킷을 수신하기 위한 전기 컴포넌트를 포함한다. 상기 패킷은 이미 확립된 라우트 에러 코드 및 확립된 라우트의 라우트 식별을 포함한다. 또한 터널 관계가 필요하지 않음을 결정하기 위한 전기 컴포넌트가 포함된다.

소정의 양상들에 따라, 논리적 그룹핑은 적어도 하나의 기지국으로부터 패킷을 수신하기 위한 전기 컴포넌트를 포함한다. 상기 패킷은 세션 종료 에러 및 CRCErrorDetectPattern을 포함한다. 또한 논리적 그룹핑(802)에는 CRCErrorDetectPattern이 세젼 종료 에러가 링크 에러로 인한 것이 아님을 표시한다면 상기 적어도 하나의 기지국을 포함하는 네트워크와 재인증하기 위한 전기 컴포넌트가 포함된다.

부가적으로, 시스템(800)은 전기 컴포넌트들(804, 806, 808 및 810) 또는 다른 컴포넌트들과 연관된 기능들을 실행하기 위한 명령들을 보유하는 메모리(812)를 포함할 수 있다. 메모리(812) 외부에 있는 것으로 도시되었지만, 전기 컴포넌트들(804, 806, 808 및 810) 중 하나 이상이 메모리(812) 내에 존재할 수도 있음이 이해되어야 한다.

도 9를 참조하면, 이동 장치와 기지국 사이에 터널 관계를 형성하는 예시적인 시스템(900)이 도시된다. 시스템(900)은 기지국 내에 적어도 부분적으로 상주할 수 있다. 시스템(900)은 프로세서, 소프트웨어 또는 이들의 결합(예를 들어, 펌웨어)에 의해 구현되는 기능들을 나타내는 기능 블록들일 수 있는 기능 블록들을 포함하는 것으로서 표현된다.

시스템(900)은 별개로 또는 결합하여 동작할 수 있는 전기 컴포넌트들의 논리적 그룹핑(902)을 포함한다. 논리적 그룹핑(902)은 이동 장치로부터 라우트 형성 헤더를 포함하는 메시지를 수신하기 위한 전기 컴포넌트(904)를 포함할 수 있다. 라우트 형성 헤더는 터널을 정의하는 것과 연관된 하나 이상의 파라미터들을 포함한다. 또한 논리적 그룹핑(902)에는 만약 이동 장치가 개방-대기 상태에 있는지 여부를 결정하기 위한 전기 컴포넌트(904)가 포함된다. 부가하여, 논리적 그룹핑은 이동 장치가 개방-대기 상태에 있는 경우 적어도 하나의 에러를 대하여 라우트 형성 헤더를 검토하기 위한 전기 컴포넌트(908)를 포함한다. 또한 수신된 메시지에 응답하여 라우트 프로토콜 메시지를 형성하기 위한 전기 컴포넌트(910)가 포함된다. 부가하여, 논리적 그룹핑(902)은 형성된 라우트 프로토콜 메시지를 이동 장치로 송신하기 위한 전기 컴포넌트를 포함할 수 있다. 소정의 양상들에 따라, 논리적 그룹핑(902)은 이동 장치가 개방-대기 상태에 있지 않는 경우 이동 장치로부터의 라우트 형성 헤더를 무시하기 위한 전기 컴포넌트를 포함한다.

소정의 양상들에 따라, 논리적 그룹핑은 수신된 라우트 형성 헤더에서 요청된 퍼스널리티가 지원되지 않는지 여부를 결정하기 위한 전기 컴포넌트 및 지원되는 퍼스널리티들을 결정하기 위해 세션 기준 네트워크 제어기에 액세스하기 위한 전기 컴포넌트를 포함한다. 논리적 그룹핑(902)에는 선호도의 순서대로 지원된 퍼스널리티들을 랭크하기 위한 전기 컴포넌트 및 라우트 프로토콜 메시지에 랭크된 지원된 퍼스널리티들을 포함하기 위한 전기 컴포넌트가 포함된다.

부가적으로, 시스템(900)은 전기 컴포넌트들(904, 906, 908, 910 및 912) 또는 다른 컴포넌트들과 연관된 기능들을 실행하기 위한 명령들을 보유하는 메모리(914)를 포함할 수 있다. 메모리(914) 외부에 있는 것으로 도시되었지만, 전기 컴포넌트들(904, 906, 908, 910 및 912) 중 하나 이상이 메모리(914) 내에 존재할 수도 있음이 이해되어야 한다.

본 명세서에서 기술된 양상들은 하드웨어, 소프트웨어, 펌웨어, 미들웨어, 마이크로코드 또는 이들의 조합을 통해 구현될 수 있음이 이해되어야 한다. 시스템들 및/또는 방법들이 소프트웨어, 펌웨어, 미들웨어 또는 마이크로코드, 프로그램 코드 또는 코드 세그먼트들로 구현되는 경우, 그것들은 기억 컴포넌트와 같은 기계-판독가능한 매체에 저장될 수 있다. 코드 세그먼트는 절차, 함수, 서브프로그램, 프로그램, 루틴, 서브루틴, 모듈, 소프트웨어 패키지, 클래스 또는 명령들의 임의 조합, 데이터 구조들 또는 프로그램 스테이트먼트들을 나타낼 수 있다. 코드 세그먼트는 정보, 데이터, 인수들, 파라미터들 또는 메모리 콘텐츠를 전달 및/또는 수신함으로써 또 다른 코드 세그먼트 또는 하드웨어 회로에 결합될 수 있다. 정보, 인수들, 파라미터들, 데이터 등은 메모리 공유, 메시지 전달, 토큰 전달, 네트워크 송신 등을 포함하는 임의의 적합한 수단을 사용하여 전달, 포워딩 또는 송신될 수 있다.

본 명세서에 개시된 양상들과 관련하여 기술된 다양한 예시적인 로직들, 논리 블록들, 모듈들, 및 회로들은 범용 프로세서; 디지털 신호 프로세서(DSP); 주문형 집적회로(ASIC); 필드 프로그래머블 게이트 어레이(FPGA); 또는 다른 프로그래 머블 논리 장치; 이산 게이트 또는 트랜지스터 로직; 이산 하드웨어 컴포넌트들; 또는 본 명세서에서 기술된 기능들을 수행하도록 설계된 것들의 임의 조합을 통해 구현 또는 수행될 수 있다. 범용 프로세서는 마이크로프로세서 일 수 있지만; 대안적으로, 이러한 프로세서는 기존 프로세서, 제어기, 마이크로 제어기, 또는 상태 머신일 수 있다. 프로세서는 또한 예를 들어, DSP와 마이크로프로세서, 복수의 마이크로프로세서들, DSP 코어와 결합된 하나 이상의 마이크로프로세서들, 또는 임의의 다른 상기 구성과 같이 계산 장치들의 조합으로서 구현될 수 있다. 부가적으로, 적어도 하나의 프로세서는 전술한 단계들 및/또는 동작들 중 하나 이상을 수행하도록 동작가능한 하나 이상의 모듈들을 포함할 수 있다.

소프트웨어 구현을 위하여, 본 명세서에서 기재된 기술들은 본 명세서에서 기술된 기능들을 수행하는 모듈들(예를 들어, 절차들, 기능들 등)로 구현될 수 있다. 소프트웨어 코드들은 메모리 유닛들에 저장될 수 있고 프로세서들에 의해 실행될 수 있다. 메모리 유닛은 프로세서 내부에 또는 프로세서 외부에서 구현될 수 있고, 후자의 경우에 메모리 유닛은 당업계에 공지된 여러 다양한 수당을 통해 프로세서에 통신가능하게 결합될 수 있다. 부가하여, 적어도 하나의 프로세서는 본 명세서에서 기술된 기능들을 수행하도록 동작가능한 하나 이상의 모듈들을 포함할 수 있다.

더욱이, 본 명세서에서 기술된 여러 다양한 양상들 또는 특징들은 표준 프로그래밍 및/또는 엔지니어링 기술들을 사용하여 방법, 장치 또는 제조물로서 구현될 수 있다. 본 명세서에서 사용되는 바와 같이 용어 "제조물(article of manufacture)"은 컴퓨터-판독가능 장치, 캐리어 또는 매체로부터 액세스가능한 컴퓨터 프로그램을 포괄하는 것으로 의도된다. 예를 들어, 컴퓨터-판독가능한 매체는 자기 기억 장치들(예를 들어, 하드 디스크, 플로피 디스크, 자기 스트립들 등), 광학 디스크들(예를 들어, 컴팩트 디스트(CD), DVD 등), 스마트 카드들 및 플래시 메모리 장치들(예를 들어, EPROM, 카드, 스틱, 키 드라이브 등)을 포함할 수 있으나, 이에 제한되지는 않는다. 부가적으로, 본 명세서에서 기술된 여러 다양한 저장 매체는 정보를 저장하기 위한 하나 이상의 장치들 및/또는 다른 기계-판독가능 매체를 나타낼 수 있다. 용어 "기계-판독가능 매체"는 명령(들) 및/또는 데이터를 저장, 포함 및/또는 운반할 수 있는 무선 채널들 및 여러 다양한 다른 매체를 포함할 수 있으나, 이에 제한되지는 않는다. 부가적으로, 컴퓨터 프로그램 물건(computer program product)은 컴퓨터로 하여금 본 명세서에서 기술된 기능들을 수행하게 하도록 동작가능한 하나 이상의 명령들 또는 코드들을 갖는 컴퓨터 판독가능 매체를 포함할 수 있다.

부가하여, 본 명세서에서 개시된 양상들과 관련하여 기술된 방법 또는 알고리즘의 단계들 및/또는 동작들은 하드웨어로 직접, 프로세서에 의해 실행된 소프트웨어 모듈로, 또는 2가지의 조합으로 구현될 수 있다. 소프트웨어 모듈은 RAM 메모리, 플래시 메모리, ROM 메모리, EPROM 메모리, EEPROM 메모리, 레지스터들, 하드 디스크, 탈착가능한 디스크, CD-ROM, 또는 당업계에 공지된 임의의 다른 형태의 기억 매체에 상주할 수 있다. 예시적인 기억 매체는 프로세서에 결합될 수 있고, 그 결과 프로세서는 기억 매체로부터 정보를 판독하고 기억 매체에 정보를 기록할 수 있다. 대안예에서, 기억 매체는 프로세서와 일체형일 수 있다. 부가하여, 소정의 양상들에서, 프로세서 및 기억 매체는 ASIC에 상주할 수 있다. 부가적으로, ASIC은 사용자 단말에 상주할 수 있다. 대안예에서, 프로세서 및 기억 매체는 사용자 단말에서의 이산 컴포넌트들로서 상주할 수 있다. 부가적으로, 소정의 양상들에서, 방법 또는 알고리즘의 단계들 및/또는 동작들은 컴퓨터 프로그램 물건으로 통합될 수 있는 기계-판독가능한 매체 및/또는 컴퓨터 판독가능 매체 상에 코드들 및/또는 명령들 중 하나 또는 임의 조합 또는 세트로서 상주할 수 있다.

본 명세서에서 기재된 기술들은 CDMA, TDMA, FDMA, OFDMA, SC-FDMA 및 다른 시스템들과 같은 여러 다양한 무선 통신 시스템들을 위해 사용될 수 있다. 용어 "시스템" 및 "네트워크"는 종종 상호교환적으로 사용된다. CDMA 시스템은 범용 지상 무선 액세스(Universal Terrestrial Radio Access; UTRA), CDMA2000 등과 같은 무선 기술을 구현할 수 있다. UTRA는 광대역-CDMA(W-CDMA) 및 CDMA의 다른 변형예들을 포함한다. 부가하여, cdma2000은 IS-2000, IS-95 및 IS-856 표준들을 커버한다. TDMA 시스템은 이동 통신을 위한 전역 시스템(Global System for Mobile Communications; GSM)과 같은 무선 기술을 구현할 수 있다. OFDMA 시스템은 진화된 UTRA(E-UTRA), 울트라 이동 광대역(Ultra Mobile Broadband; UMB), IEEE 802.11(Wi-Fi), IEEE 802.16(WiMAX), IEEE 802.20, 플래시-OFDM 등과 같은 무선 기술을 구현할 수 있다. UTRA 및 E-UTRA는 범용 이동 통신 시스템(UMTS)의 일부이다. 3GPP 롱 텀 에볼루션(LTE)은 다운링크 상에서 OFDMA를 채택하고 업링크 상에서 SC-FDMA를 채택하는, E-UTRA를 사용하는 UMTS의 릴리스이다. UTRA, E-UTRA, UMTS, LTE 및 GSM은 "3세대 파트너십 프로젝트(3GPP)"로 명명된 조직으로부터 나온 문서들에 기술된다. 부가적으로, cdma2000 및 UMB는 "3세대 파트너십 프로젝트 2(3GPP2)"로 명명된 조직으로부터 나온 문서들에 기술된다. 부가하여, 상기 무선 통신 시스템들은 부가적으로 종종 단면 무허가 스펙트럼(unpaired unlicensed spectrum), 802.xx 무선 LAN, BLUETOOTH 및 임의의 다른 단범위 또는 장범위 무선 통신 기술들을 사용하는 피어-투-피어(예를 들어, 모바일-대-모바일) 애드 혹 네트워크 시스템들을 포함한다.

전술한 개시내용은 예시적인 양상들 및/또는 양상들을 논의하는 반면, 여러 다양한 변경예 및 수정예들이 여기서 첨부된 청구항들에 의해 정의되는 기술된 양상들 및/또는 양상들의 범위로부터 벗어나지 않으면서 이루어질 수 있다. 따라서, 기술된 양상들은 첨부된 청구항들의 범위 내에 속하는 모든 변경예들, 수정예들 및 변형예들을 망라하는 것으로 의도된다. 부가하여, 비록 기술된 양상들 및/또는 양상들의 엘리먼트들이 단수로 기술되거나 청구될 수 있지만, 단수로의 제한이 명시적으로 서술되지 않는다면 복수 개도 고려된다. 부가적으로, 임의의 양상 및/또는 양상의 모두 또는 일부가 달리 서술되지 않는다면 임의의 다른 양상 및/또는 양상의 전부 또는 일부와 함께 이용될 수 있다.

용어 "포함하다"가 상세한 설명 또는 청구항들에서 사용되는 범위에 대하여 상기 용어는 용어 "포함하는"이 청구항의 전이 단어로서 채택될 때 해석되는 것처럼 용어 "포함하는"과 유사한 방식으로 다른 구성요소들을 더 포함할 수 있는 것으로 의도된다. 부가하여, 상세한 설명 또는 청구항들에서 사용되는 용어 "또는"은 "비배타적인 또는"인 것을 의미한다.

Claims (76)

1. 이동 장치와 기지국 사이의 터널 관계를 형성하기 위한 방법으로서,

   터널을 통한 통신의 확립을 위하여 적어도 하나의 기지국을 선택하는 단계;

   라우트 형성 헤더(Route Creation Header)를 포함하는 메시지를 상기 적어도 하나의 기지국으로 송신하는 단계 ― 상기 라우트 형성 헤더는 상기 터널을 정의하는 것과 연관된 하나 이상의 파라미터들을 포함함 ―;

   상기 라우트 형성 헤더의 확인(confirmation)을 대기하는 단계; 및

   상기 확인이 수신된 경우 개방-대기(Waiting-To-Open) 상태 밖으로 전이하는 단계

   를 포함하고,

   상기 확인은 상기 터널 관계의 형성을 표시하는, 이동 장치와 기지국 사이의 터널 관계를 형성하기 위한 방법.
2. 제1항에 있어서,

   상기 확인이 수신되지 않는 경우, 상기 라우트 형성 헤더를 포함하는 상기 메시지를 상기 적어도 하나의 기지국으로 재송신하는 단계

   를 더 포함하는, 이동 장치와 기지국 사이의 터널 관계를 형성하기 위한 방법.
3. 제1항에 있어서,

   상기 확인은 상기 적어도 하나의 기지국으로부터 패킷을 수신하는 것을 포함하는, 이동 장치와 기지국 사이의 터널 관계를 형성하기 위한 방법.
4. 제1항에 있어서,

   라우트 형성 헤더를 포함하는 메시지를 상기 적어도 하나의 기지국으로 송신하는 단계는:

   2 이상의 패킷 병합 프로토콜 패킷(Packet Consolidation Protocol Packet)들이 단일의 MAC 패킷에 실릴(carry) 것임을 결정하는 단계 ― 각각의 패킷 병합 프로토콜 패킷은 헤더 엘리먼트(Header Element) 레코드를 포함함 ―; 및

   상기 패킷 병합 패킷들 중 하나를 제외한 모든 패킷 병합 패킷들로부터 상기 헤더 엘리먼트 레코드를 생략하는 단계 ― 상기 헤더 엘리먼트 레코드들을 생략하는 단계는 자원들을 절약하고 효율성을 개선함 ―

   를 더 포함하는, 이동 장치와 기지국 사이의 터널 관계를 형성하기 위한 방법.
5. 제1항에 있어서,

   라우트 형성 헤더를 포함하는 상기 메시지를 상기 적어도 하나의 기지국으로 송신하는 단계는:

   상기 적어도 하나의 기지국으로의 상기 터널에 대한 식별자를 선택하는 단계;

   상기 터널에 대한 퍼스널리티(personality)를 선택하는 단계

   를 더 포함하는, 이동 장치와 기지국 사이의 터널 관계를 형성하기 위한 방법.
6. 제5항에 있어서,

   상기 퍼스널리티는 하나 이상의 프로토콜 타입들 및 하나 이상의 속성 값(attribute value)들을 포함하는, 이동 장치와 기지국 사이의 터널 관계를 형성하기 위한 방법.
7. 제1항에 있어서,

   상기 라우트 형성 헤더를 포함하는 상기 메시지를 상기 적어도 하나의 기지국으로 송신하는 단계는:

   기존의 라우트가 소거되어야 하는지 여부를 표시하는 단계

   를 더 포함하는, 이동 장치와 기지국 사이의 터널 관계를 형성하기 위한 방법.
8. 제1항에 있어서,

   상기 적어도 하나의 기지국으로부터 패킷을 수신하는 단계 ― 상기 패킷은 퍼스널리티 에러 코드를 포함함 ―;

   상기 패킷으로 수신된 랭크된 퍼스널리티들의 리스트를 검토하는 단계;

   상기 랭크된 퍼스널리티들의 리스트로부터 퍼스널리티를 선택하는 단계;

   상기 선택된 퍼스널리티를 포함하도록 상기 라우트 형성 헤더 패킷을 수정하는 단계; 및

   상기 수정된 라우트 형성 헤더 패킷을 상기 적어도 하나의 기지국으로 송신하는 단계

   를 더 포함하는, 이동 장치와 기지국 사이의 터널 관계를 형성하기 위한 방법.
9. 제1항에 있어서,

   상기 적어도 하나의 기지국으로부터 패킷을 수신하는 단계 ― 상기 패킷은 이미 확립된 라우트 에러 코드(route already established error code) 및 확립된 라우트의 라우트 식별을 포함함 ―; 및

   상기 터널 관계가 필요하지 않음을 결정하는 단계

   를 더 포함하는, 이동 장치와 기지국 사이의 터널 관계를 형성하기 위한 방법.
10. 제1항에 있어서,

    상기 적어도 하나의 기지국으로부터 패킷을 수신하는 단계 ― 상기 패킷은 세션 종료 에러 코드 및 CRCErrorDetectPattern을 포함함 ―; 및

    상기 CRCErrorDetectPattern이 상기 세션 종료 에러 코드가 링크 에러로 인한 것이 아님을 표시하는 경우, 상기 적어도 하나의 기지국을 포함하는 네트워크와 재인증하는 단계

    를 더 포함하는, 이동 장치와 기지국 사이의 터널 관계를 형성하기 위한 방법.
11. 제1항에 있어서,

    액세스 단말 식별자(access terminal identifier; ATI)가 최근에 변경된 경우, 상기 라우트 형성 헤더에 상기 액세스 단말 식별자(ATI)를 포함시키는 단계

    를 더 포함하는, 이동 장치와 기지국 사이의 터널 관계를 형성하기 위한 방법.
12. 제1항에 있어서,

    상기 메시지에 RouteID 헤더를 포함시키는 단계;

    상기 RouteID 헤더가 서빙 기지국에 의해 인식되지 않는 경우, 현재의 라우트 맵에 대한 요청을 수신하는 단계; 및

    상기 요청에 응답하여 상기 현재의 라우트 맵을 송신하는 단계

    를 더 포함하는, 이동 장치와 기지국 사이의 터널 관계를 형성하기 위한 방법.
13. 터널을 통한 통신의 확립을 위하여 적어도 하나의 기지국을 선택하고, 라우트 형성 헤더(Route Creation Header)를 포함하는 메시지를 상기 적어도 하나의 기지국으로 송신하며, 상기 라우트 형성 헤더의 확인(confirmation)을 대기하고, 상기 확인이 수신된 경우 개방-대기(Waiting-To-Open) 상태 밖으로 전이하는 것과 관련된 명령들을 보유하는 메모리 ― 상기 라우트 형성 헤더는 상기 터널을 정의하는 것과 연관된 하나 이상의 파라미터들을 포함함 ―; 및

    상기 메모리에 보유된 상기 명령들을 실행하도록 구성되고 상기 메모리에 결합된 프로세서

    를 포함하는, 무선 통신 장치.
14. 제13항에 있어서,

    상기 메모리는 상기 확인이 수신되지 않는 경우, 상기 라우트 형성 헤더를 포함하는 상기 메시지를 상기 적어도 하나의 기지국으로 재송신하는 것과 관련된 명령들을 더 보유하는, 무선 통신 장치.
15. 제13항에 있어서,

    상기 확인은 상기 적어도 하나의 기지국으로부터 패킷을 수신하는 것을 포함하는, 무선 통신 장치.
16. 제13항에 있어서,

    상기 메모리는 2 이상의 패킷 병합 프로토콜 패킷(Packet Consolidation Protocol Packet)들이 단일의 MAC 패킷에 실려야 함을 결정하고 ― 각각의 패킷 병합 프로토콜 패킷은 헤더 엘리먼트(Header Element) 레코드를 포함함 ―, 상기 패킷 병합 패킷들 중 하나를 제외한 모든 패킷 병합 패킷들로부터 상기 헤더 엘리먼트 레코드를 생략하는 것과 관련된 명령들을 더 보유하고, 상기 헤더 엘리먼트 레코드들을 생략하는 것은 자원들을 절약하고 효율성을 개선하는, 무선 통신 장치.
17. 제13항에 있어서,

    상기 메모리는 상기 적어도 하나의 기지국으로의 상기 터널에 대한 식별자를 선택하고 상기 터널에 대한 퍼스널리티(personality)를 선택하는 것과 관련된 명령들을 더 보유하는, 무선 통신 장치.
18. 제17항에 있어서,

    상기 퍼스널리티는 적어도 하나의 프로토콜 타입 및 적어도 하나의 속성 값을 포함하는, 무선 통신 장치.
19. 제13항에 있어서,

    상기 메모리는 기존의 라우트가 소거되어야 하는지 여부를 표시하는 것과 관련된 명령들을 더 보유하는, 무선 통신 장치.
20. 제13항에 있어서,

    상기 메모리는 상기 적어도 하나의 기지국으로부터 패킷을 수신하고 ― 상기 패킷은 퍼스널리티 에러 코드를 포함함 ―, 상기 패킷으로 수신된 랭크된 퍼스널리티들의 리스트를 검토하며, 상기 랭크된 퍼스널리티들의 리스트로부터 퍼스널리티를 선택하며, 상기 선택된 퍼스널리티를 포함하도록 상기 라우트 형성 헤더 패킷을 수정하고, 상기 수정된 라우트 형성 헤더 패킷을 상기 적어도 하나의 기지국으로 송신하는 것과 관련된 명령들을 더 보유하는, 무선 통신 장치.
21. 제13항에 있어서,

    상기 메모리는 상기 적어도 하나의 기지국으로부터 패킷을 수신하고 상기 터널 관계가 필요하지 않음을 결정하는 것과 관련된 명령들을 더 보유하고, 상기 패킷은 이미 확립된 라우트 에러 코드(route already established error code) 및 확립된 라우트의 라우트 식별을 포함하는, 무선 통신 장치.
22. 제13항에 있어서,

    상기 메모리는 상기 적어도 하나의 기지국으로부터 패킷을 수신하고 ― 상기 패킷은 세션 종료 에러 코드 및 CRCErrorDetectPattern을 포함함 ―, 상기 CRCErrorDetectPattern이 상기 세션 종료 에러 코드가 링크 에러로 인한 것이 아님을 표시하는 경우, 상기 적어도 하나의 기지국을 포함하는 네트워크와 재인증하는 것과 관련된 명령들을 더 보유하는, 무선 통신 장치.
23. 제13항에 있어서,

    상기 메모리는 액세스 단말 식별자(access terminal identifier; ATI)가 최근에 변경된 경우, 상기 라우트 형성 헤더에 상기 액세스 단말 식별자(ATI)를 포함시키는 것과 관련된 명령들을 더 보유하는, 무선 통신 장치.
24. 제13항에 있어서,

    상기 메모리는 상기 메시지에 RouteID 헤더를 포함시키고, 상기 RouteID 헤더가 서빙 기지국에 의해 인식되지 않는 경우, 현재의 라우트 맵에 대한 요청을 수신하며, 상기 요청에 응답하여 상기 현재의 라우트 맵을 송신하는 것과 관련된 명령들을 더 보유하는, 무선 통신 장치.
25. 컴퓨터-판독가능 매체로서,

    컴퓨터로 하여금 터널을 통한 통신의 확립을 위하여 적어도 하나의 기지국을 선택하도록 하기 위한 코드들의 제 1 세트;

    상기 컴퓨터로 하여금 라우트 형성 헤더(Route Creation Header)를 포함하는 메시지를 상기 적어도 하나의 기지국으로 송신하도록 하기 위한 코드들의 제 2 세트 ― 상기 라우트 형성 헤더는 상기 터널을 정의하는 것과 연관된 하나 이상의 파라미터들을 포함함 ―;

    상기 컴퓨터로 하여금 상기 라우트 형성 헤더의 확인(confirmation)을 대기하도록 하기 위한 코드들의 제 3 세트 ― 상기 확인은 상기 적어도 하나의 기지국으로부터 패킷을 수신하는 것을 포함함 ―; 및

    상기 컴퓨터로 하여금 상기 확인이 수신된 경우 개방-대기(Waiting-To-Open) 상태 밖으로 전이하도록 하기 위한 코드들의 제 4 세트

    를 포함하는, 컴퓨터-판독가능 매체.
26. 제25항에 있어서,

    상기 컴퓨터로 하여금 상기 확인이 수신되지 않는 경우, 상기 라우트 형성 헤더를 포함하는 상기 메시지를 상기 적어도 하나의 기지국으로 재송신하도록 하기 위한 코드들의 제 5 세트

    를 더 포함하는, 컴퓨터-판독가능 매체.
27. 제25항에 있어서,

    상기 컴퓨터로 하여금 2 이상의 패킷 병합 프로토콜 패킷(Packet Consolidation Protocol Packet)들이 단일의 MAC 패킷에 실릴 것임을 결정하도록 하기 위한 코드들의 제 5 세트 ― 각각의 패킷 병합 프로토콜 패킷은 헤더 엘리먼트(Header Element) 레코드를 포함함 ―; 및

    상기 컴퓨터로 하여금 상기 패킷 병합 패킷들 중 하나를 제외한 모든 패킷 병합 패킷들로부터 상기 헤더 엘리먼트 레코드를 생략하도록 하기 위한 코드들의 제 6 세트 ― 상기 헤더 엘리먼트 레코드들을 생략하는 것은 자원들을 절약하고 효율성을 개선함 ―

    를 더 포함하는, 컴퓨터-판독가능 매체.
28. 제25항에 있어서,

    상기 컴퓨터로 하여금 상기 적어도 하나의 기지국으로의 상기 터널에 대한 식별자를 선택하도록 하기 위한 코드들의 제 5 세트; 및

    상기 컴퓨터로 하여금 상기 터널에 대한 퍼스널리티(personality)를 선택하도록 하기 위한 코드들의 제 6 세트

    를 더 포함하고,

    상기 퍼스널리티는 하나 이상의 프로토콜 타입들 및 하나 이상의 속성 값(attribute value)들을 포함하는, 컴퓨터-판독가능 매체.
29. 제25항에 있어서,

    상기 컴퓨터로 하여금 기존의 라우트가 소거되어야 하는지 여부를 표시하도록 하기 위한 코드들의 제 5 세트

    를 더 포함하는, 컴퓨터-판독가능 매체.
30. 제25항에 있어서,

    상기 컴퓨터로 하여금 상기 적어도 하나의 기지국으로부터 패킷을 수신하도록 하기 위한 코드들의 제 5 세트 ― 상기 패킷은 퍼스널리티 에러 코드를 포함함 ―;

    상기 컴퓨터로 하여금 상기 패킷으로 수신된 랭크된 퍼스널리티들의 리스트를 검토하도록 하기 위한 코드들의 제 6 세트;

    상기 컴퓨터로 하여금 상기 랭크된 퍼스널리티들의 리스트로부터 퍼스널리티를 선택하도록 하기 위한 코드들의 제 7 세트;

    상기 컴퓨터로 하여금 상기 선택된 퍼스널리티를 포함하도록 상기 라우트 형성 헤더 패킷을 수정하도록 하기 위한 코드들의 제 8 세트; 및

    상기 컴퓨터로 하여금 상기 수정된 라우트 형성 헤더 패킷을 상기 적어도 하나의 기지국으로 송신하도록 하기 위한 코드들의 제 9 세트

    를 더 포함하는, 컴퓨터-판독가능 매체.
31. 제25항에 있어서,

    상기 컴퓨터로 하여금 상기 적어도 하나의 기지국으로부터 패킷을 수신하도록 하기 위한 코드들의 제 5 세트 ― 상기 패킷은 이미 확립된 라우트 에러 코드(route already established error code) 및 확립된 라우트의 라우트 식별을 포함함 ―;

    상기 컴퓨터로 하여금 상기 터널 관계가 필요하지 않음을 결정하도록 하기 위한 코드들의 제 6 세트

    를 더 포함하는, 컴퓨터-판독가능 매체.
32. 제25항에 있어서,

    상기 컴퓨터로 하여금 상기 적어도 하나의 기지국으로부터 패킷을 수신하도록 하기 위한 코드들의 제 5 세트 ― 상기 패킷은 세션 종료 에러 코드 및 CRCErrorDetectPattern을 포함함 ―; 및

    상기 컴퓨터로 하여금 상기 CRCErrorDetectPattern이 상기 세션 종료 에러 코드가 링크 에러로 인한 것이 아님을 표시하는 경우, 상기 적어도 하나의 기지국을 포함하는 네트워크와 재인증하도록 하기 위한 코드들의 제 6 세트

    를 더 포함하는, 컴퓨터-판독가능 매체.
33. 제25항에 있어서,

    상기 컴퓨터로 하여금 액세스 단말 식별자(access terminal identifier; ATI)가 최근에 변경된 경우, 상기 라우트 형성 헤더에 상기 액세스 단말 식별자(ATI)를 포함시키도록 하기 위한 코드들의 제 5 세트

    를 더 포함하는, 컴퓨터-판독가능 매체.
34. 제25항에 있어서,

    상기 컴퓨터로 하여금 상기 메시지에 RouteID 헤더를 포함시키도록 하기 위한 코드들의 제 5 세트;

    상기 컴퓨터로 하여금 상기 RouteID 헤더가 서빙 기지국에 의해 인식되지 않는 경우, 현재의 라우트 맵에 대한 요청을 수신하도록 하기 위한 코드들의 제 6 세트; 및

    상기 컴퓨터로 하여금 상기 요청에 응답하여 상기 현재의 라우트 맵을 송신하도록 하기 위한 코드들의 제 7 세트

    를 더 포함하는, 컴퓨터-판독가능 매체.
35. 터널을 통한 통신의 확립을 위하여 적어도 하나의 기지국을 선택하기 위한 수단;

    라우트 형성 헤더(Route Creation Header)를 포함하는 메시지를 상기 적어도 하나의 기지국으로 송신하기 위한 수단 ― 상기 라우트 형성 헤더는 상기 터널을 정의하는 것과 연관된 하나 이상의 파라미터들을 포함함 ―;

    상기 라우트 형성 헤더의 확인(confirmation)을 대기하기 위한 수단 ― 상기 확인은 상기 적어도 하나의 기지국으로부터 패킷을 수신하는 것을 포함하고, 상기 메시지를 송신하기 위한 수단은 상기 확인이 수신될 때까지 상기 라우트 형성 헤더를 포함하는 상기 메시지를 상기 적어도 하나의 기지국으로 재송신함 ― ; 및

    상기 확인이 수신될 때 개방-대기(Waiting-To-Open) 상태 밖으로 전이하기 위한 수단

    을 포함하는, 장치.
36. 제35항에 있어서,

    2 이상의 패킷 병합 프로토콜 패킷(Packet Consolidation Protocol Packet)들이 단일의 MAC 패킷에 실릴 것임을 결정하기 위한 수단 ― 각각의 패킷 병합 프로토콜 패킷은 헤더 엘리먼트(Header Element) 레코드를 포함함 ―; 및

    상기 패킷 병합 패킷들 중 하나를 제외한 모든 패킷 병합 패킷들로부터 상기 헤더 엘리먼트 레코드를 생략하기 위한 수단

    을 더 포함하는, 장치.
37. 제35항에 있어서,

    상기 적어도 하나의 기지국으로부터 패킷을 수신하기 위한 수단 ― 상기 패킷은 퍼스널리티 에러 코드를 포함함 ―;

    상기 패킷으로 수신된 랭크된 퍼스널리티들의 리스트를 검토하기 위한 수단;

    상기 랭크된 퍼스널리티들의 리스트로부터 퍼스널리티를 선택하기 위한 수단;

    상기 선택된 퍼스널리티를 포함하도록 상기 라우트 형성 헤더 패킷을 수정하기 위한 수단; 및

    상기 수정된 라우트 형성 헤더 패킷을 상기 적어도 하나의 기지국으로 송신하기 위한 수단

    을 더 포함하는, 장치.
38. 제35항에 있어서,

    상기 적어도 하나의 기지국으로부터 패킷을 수신하기 위한 수단 ― 상기 패킷은 이미 확립된 라우트 에러 코드(route already established error code) 및 확립된 라우트의 라우트 식별을 포함함 ―; 및

    상기 터널 관계가 필요하지 않음을 결정하기 위한 수단

    을 더 포함하는, 장치.
39. 제35항에 있어서,

    상기 적어도 하나의 기지국으로부터 패킷을 수신하기 위한 수단 ― 상기 패킷은 세션 종료 에러 코드 및 CRCErrorDetectPattern을 포함함 ―; 및

    상기 CRCErrorDetectPattern이 상기 세션 종료 에러 코드가 링크 에러로 인한 것이 아님을 표시하는 경우, 상기 적어도 하나의 기지국을 포함하는 네트워크와 재인증하기 위한 수단

    을 더 포함하는, 장치.
40. 라우트 프로토콜을 위한 적어도 하나의 프로세서로서,

    터널을 통한 통신의 확립을 위하여 적어도 하나의 기지국을 선택하도록 동작가능한 제 1 모듈;

    라우트 형성 헤더(Route Creation Header)를 포함하는 메시지를 상기 적어도 하나의 기지국으로 송신하도록 동작가능한 제 2 모듈 ― 상기 라우트 형성 헤더는 상기 터널을 정의하는 것과 연관된 하나 이상의 파라미터들을 포함함 ―;

    상기 라우트 형성 헤더의 확인(confirmation)을 대기하도록 동작가능한 제 3 모듈 ― 상기 확인은 상기 적어도 하나의 기지국으로부터 패킷을 수신하는 것을 포함함 ―;

    상기 확인이 수신될 때까지 상기 라우트 형성 헤더를 포함하는 상기 메시지를 상기 적어도 하나의 기지국으로 재송신하도록 동작가능한 제 4 모듈 ; 및

    상기 확인이 수신될 때 개방-대기(Waiting-To-Open) 상태 밖으로 전이하도록 동작가능한 제 5 모듈

    을 포함하는, 적어도 하나의 프로세서.
41. 제40항에 있어서,

    2 이상의 패킷 병합 프로토콜 패킷(Packet Consolidation Protocol Packet)들이 단일의 MAC 패킷에 실려야 함을 결정하도록 동작가능한 제 6 모듈 ― 각각의 패킷 병합 프로토콜 패킷은 헤더 엘리먼트(Header Element) 레코드를 포함함 ―; 및

    상기 패킷 병합 패킷들 중 하나를 제외한 모든 패킷 병합 패킷들로부터 상기 헤더 엘리먼트 레코드를 생략하도록 동작가능한 제 7 모듈

    을 더 포함하는, 적어도 하나의 프로세서.
42. 제40항에 있어서,

    상기 적어도 하나의 기지국으로부터 패킷을 수신하도록 동작가능한 제 6 모듈 ― 상기 패킷은 퍼스널리티 에러 코드를 포함함 ―;

    상기 패킷으로 수신된 랭크된 퍼스널리티들의 리스트를 검토하도록 동작가능한 제 7 모듈;

    상기 랭크된 퍼스널리티들의 리스트로부터 퍼스널리티를 선택하도록 동작가능한 제 8 모듈;

    상기 선택된 퍼스널리티를 포함하도록 상기 라우트 형성 헤더 패킷을 수정하도록 동작가능한 제 9 모듈; 및

    상기 수정된 라우트 형성 헤더 패킷을 상기 적어도 하나의 기지국으로 송신하도록 동작가능한 제 10 모듈

    을 더 포함하는, 적어도 하나의 프로세서.
43. 제40항에 있어서,

    상기 적어도 하나의 기지국으로부터 패킷을 수신하도록 동작가능한 제 6 모듈 ― 상기 패킷은 이미 확립된 라우트 에러 코드(route already established error code) 및 확립된 라우트의 라우트 식별을 포함함 ―; 및

    상기 터널 관계가 필요하지 않음을 결정하도록 동작가능한 제 7 모듈

    을 더 포함하는, 적어도 하나의 프로세서.
44. 제40항에 있어서,

    상기 적어도 하나의 기지국으로부터 패킷을 수신하도록 동작가능한 제 6 모듈 ― 상기 패킷은 세션 종료 에러 코드 및 CRCErrorDetectPattern을 포함함 ―; 및

    상기 CRCErrorDetectPattern이 상기 세션 종료 에러 코드가 링크 에러로 인한 것이 아님을 표시하는 경우, 상기 적어도 하나의 기지국을 포함하는 네트워크와 재인증하도록 동작가능한 제 7 모듈

    을 더 포함하는, 적어도 하나의 프로세서.
45. 이동 장치와 기지국 사이의 터널 관계를 형성하기 위한 방법으로서,

    이동 장치로부터 라우트 형성 헤더를 포함하는 메시지를 수신하는 단계 ― 상기 라우트 형성 헤더는 터널을 정의하는 것과 연관된 하나 이상의 파라미터들을 포함함 ―;

    상기 이동 장치가 개방-대기 상태에 있는지 여부를 결정하는 단계;

    상기 이동 장치가 상기 개방-대기 상태에 있는 경우 적어도 하나의 에러에 대하여 상기 라우트 형성 헤더를 검토하는 단계;

    상기 수신된 메시지에 응답하여 라우트 프로토콜 메시지(Route Protocol Message)를 형성하는 단계; 및

    상기 형성된 라우트 프로토콜 메시지를 상기 이동 장치로 송신하는 단계

    를 포함하는, 이동 장치와 기지국 사이의 터널 관계를 형성하기 위한 방법.
46. 제45항에 있어서,

    상기 이동 장치가 상기 개방-대기 상태에 있지 않고 상기 라우트 형성 헤더가 모든 라우트들 소거 플래그(delete all routes flag)를 포함하지 않는 경우, 이동 장치로부터의 상기 라우트 형성 헤더를 무시하는 단계

    를 더 포함하는, 이동 장치와 기지국 사이의 터널 관계를 형성하기 위한 방법.
47. 제45항에 있어서,

    적어도 하나의 에러에 대하여 상기 라우트 형성 헤더를 검토하는 단계는:

    상기 수신된 라우트 형성 헤더에서 요청된 퍼스널리티가 지원되지 않음을 결정하는 단계 ― 상기 퍼스널리티는 하나 이상의 프로토콜 타입들 및 하나 이상의 속성 값들을 포함하고, 상기 요청된 퍼스널리티가 지원되지 않음을 결정하는 단계는 상기 라우트 형성 헤더에서 수신된 퍼스널리티 식별자들의 해석을 결정하기 위하여 세션 기준 네트워크 제어기(Session Reference Network Controller)를 액세스하는 단계를 포함함 ―;

    선호도의 순서로 상기 지원된 퍼스널리티들을 랭크하는 단계; 및

    상기 라우트 프로토콜 메시지에 상기 랭크된 지원된 퍼스널리티들을 포함시키는 단계

    를 더 포함하는, 이동 장치와 기지국 사이의 터널 관계를 형성하기 위한 방법.
48. 제45항에 있어서,

    적어도 하나의 에러에 대하여 상기 라우트 형성 헤더를 검토하는 단계는:

    라우트가 상기 이동 장치에 대하여 이미 확립되어 있는지 여부를 결정하는 단계; 및

    라우트가 이미 확립되어 있음이 결정되는 경우, 확립된 라우트의 라우트 식별을 상기 라우트 프로토콜 메시지에 포함시키는 단계

    를 더 포함하는, 이동 장치와 기지국 사이의 터널 관계를 형성하기 위한 방법.
49. 제45항에 있어서,

    적어도 하나의 에러에 대하여 상기 라우트 형성 헤더를 검토하는 단계는:

    상기 이동 장치와의 세션이 종료되어야 한다는 명령들을 수신하는 단계 ― 상기 명령들은 세션 기준 네트워크 제어기로부터 수신됨 ―; 및

    상기 라우트 프로토콜 메시지에 CRCErrorDetectPattern을 포함시키는 단계

    를 더 포함하는, 이동 장치와 기지국 사이의 터널 관계를 형성하기 위한 방법.
50. 제45항에 있어서,

    적어도 하나의 에러에 대하여 상기 라우트 형성 헤더를 검토하는 단계는:

    상기 라우트 형성 헤더를 포함하지 않는 패킷을 수신하는 것 및 어떠한 라우트도 존재하지 않음에 기초하여 라우트가 상기 이동 장치에 대하여 확립되어 있지 않음을 결정하는 단계; 및

    상기 라우트가 확립되어 있지 않음이 결정되는 경우, 상기 라우트가 존재하지 않음을 표시하는 상기 형성된 라우트 프로토콜 메시지에 에러 코드를 포함시키는 단계

    를 더 포함하는, 이동 장치와 기지국 사이의 터널 관계를 형성하기 위한 방법.
51. 제45항에 있어서,

    적어도 하나의 에러에 대하여 상기 라우트 형성 헤더를 검토하는 단계는:

    상기 이동 장치의 식별에의 실패가 존재함을 결정하는 단계; 및

    상기 이동 장치 식별 실패를 표시하기 위하여 상기 라우트 프로토콜 메시지에 에러 코드를 포함시키는 단계

    를 더 포함하는, 이동 장치와 기지국 사이의 터널 관계를 형성하기 위한 방법.
52. 제51항에 있어서,

    상기 식별 실패는 세션 기준 네트워크 제어기로부터 수신되는, 이동 장치와 기지국 사이의 터널 관계를 형성하기 위한 방법.
53. 제45항에 있어서,

    상기 메시지에서의 RouteID 헤더를 수신하는 단계; 및

    상기 RouteID 헤더가 인식되지 않는 경우, 현재의 라우트 맵에 대한 요청을 송신하는 단계

    를 더 포함하는, 이동 장치와 기지국 사이의 터널 관계를 형성하기 위한 방법.
54. 이동 장치로부터 라우트 형성 헤더를 포함하는 메시지를 수신하고 ― 상기 라우트 형성 헤더는 터널을 정의하는 것과 연관된 하나 이상의 파라미터들을 포함함 ―, 상기 이동 장치가 개방-대기 상태에 있는지 여부를 결정하며, 상기 이동 장치가 상기 개방-대기 상태에 있는 경우 적어도 하나의 에러에 대하여 상기 라우트 형성 헤더를 검토하고, 상기 수신된 메시지에 응답하여 라우트 프로토콜 메시지(Route Protocol Message)를 형성하며, 상기 형성된 라우트 프로토콜 메시지를 상기 이동 장치로 송신하기 위한 명령들을 보유하는 메모리; 및

    상기 메모리에 보유된 상기 명령들을 실행하도록 구성되고 상기 메모리에 결합된 프로세서

    를 포함하는, 무선 통신 장치.
55. 제54항에 있어서,

    상기 메모리는, 상기 이동 장치가 상기 개방-대기 상태에 있지 않고 상기 라우트 형성 헤더가 모든 라우트들 소거 플래그(delete all routes flag)를 포함하지 않는 경우, 이동 장치로부터의 상기 라우트 형성 헤더를 무시하는 것과 관련된 명령들을 더 보유하는, 무선 통신 장치.
56. 제54항에 있어서,

    상기 메모리는, 상기 수신된 라우트 형성 헤더에서 요청된 퍼스널리티가 지원되지 않음을 결정하고, 상기 라우트 형성 헤더에서 수신된 퍼스널리티 식별자들의 해석을 결정하기 위하여 세션 기준 네트워크 제어기(Session Reference Network Controller)를 액세스하며, 선호도의 순서로 상기 지원된 퍼스널리티들을 랭크하고, 상기 라우트 프로토콜 메시지에 상기 랭크된 지원된 퍼스널리티들을 포함시키는 것과 관련된 명령들을 더 보유하며, 상기 퍼스널리티는 하나 이상의 프로토콜 타입들 및 하나 이상의 속성 값들을 포함하는, 무선 통신 장치.
57. 제54항에 있어서,

    상기 메모리는, 라우트가 상기 이동 장치에 대하여 이미 확립되어 있는지 여부를 결정하고, 라우트가 이미 확립되어 있음이 결정되는 경우, 확립된 라우트의 라우트 식별을 상기 라우트 프로토콜 메시지에 포함시키는 것과 관련된 명령들을 더 보유하는, 무선 통신 장치.
58. 제54항에 있어서,

    상기 메모리는, 상기 이동 장치와의 세션이 종료되어야 한다는 명령들을 세션 기준 네트워크 제어기로부터 수신하고 상기 라우트 프로토콜 메시지에 CRCErrorDetectPattern을 포함시키는 것과 관련된 명령들을 더 보유하는, 무선 통신 장치.
59. 제54항에 있어서,

    상기 메모리는, 상기 라우트 형성 헤더를 포함하지 않는 패킷을 수신하는 것 및 어떠한 라우트도 존재하지 않음에 기초하여 라우트가 상기 이동 장치에 대하여 확립되어 있지 않음을 결정하고, 상기 라우트가 확립되어 있지 않음이 결정되는 경우, 상기 라우트가 존재하지 않음을 표시하는 상기 형성된 라우트 프로토콜 메시지에 에러 코드를 포함시키는 것과 관련된 명령들을 더 보유하는, 무선 통신 장치.
60. 제54항에 있어서,

    상기 메모리는, 상기 이동 장치의 식별에의 실패가 존재함을 결정하고, 상기 이동 장치 식별 실패를 표시하기 위하여 상기 라우트 프로토콜 메시지에 에러 코드를 포함시키는 것과 관련된 명령들을 더 보유하는, 무선 통신 장치.
61. 제60항에 있어서,

    상기 식별 실패는 세션 기준 네트워크 제어기로부터 수신되는, 무선 통신 장치.
62. 제54항에 있어서,

    상기 메모리는, 상기 메시지에서의 RouteID 헤더를 수신하고, 상기 RouteID 헤더가 인식되지 않는 경우, 현재의 라우트 맵에 대한 요청을 송신하는 것과 관련된 명령들을 더 보유하는, 무선 통신 장치.
63. 컴퓨터-판독가능 매체로서,

    컴퓨터로 하여금 이동 장치로부터 라우트 형성 헤더를 포함하는 메시지를 수신하도록 하기 위한 코드들의 제 1 세트 ― 상기 라우트 형성 헤더는 터널을 정의하는 것과 연관된 하나 이상의 파라미터들을 포함함 ―;

    상기 컴퓨터로 하여금 상기 이동 장치가 개방-대기 상태에 있는지 여부를 결정하도록 하기 위한 코드들의 제 2 세트;

    상기 컴퓨터로 하여금 상기 이동 장치가 상기 개방-대기 상태에 있는 경우 적어도 하나의 에러에 대하여 상기 라우트 형성 헤더를 검토하도록 하기 위한 코드들의 제 3 세트;

    상기 컴퓨터로 하여금 상기 수신된 메시지에 응답하여 라우트 프로토콜 메시지(Route Protocol Message)를 형성하도록 하기 위한 코드들의 제 4 세트; 및

    상기 컴퓨터로 하여금 상기 형성된 라우트 프로토콜 메시지를 상기 이동 장치로 송신하도록 하기 위한 코드들의 제 5 세트

    를 포함하는, 컴퓨터-판독가능 매체.
64. 제63항에 있어서,

    상기 컴퓨터로 하여금 상기 이동 장치가 상기 개방-대기 상태에 있지 않고 상기 라우트 형성 헤더가 모든 라우트들 소거 플래그(delete all routes flag)를 포함하지 않는 경우, 이동 장치로부터의 상기 라우트 형성 헤더를 무시하도록 하기 위한 코드들의 제 6 세트

    를 더 포함하는, 컴퓨터-판독가능 매체.
65. 제63항에 있어서,

    상기 컴퓨터로 하여금 상기 수신된 라우트 형성 헤더에서 요청된 퍼스널리티가 지원되지 않는지 여부를 결정하도록 하기 위한 코드들의 제 6 세트 ― 상기 퍼스널리티는 적어도 하나의 프로토콜 타입 및 적어도 하나의 속성 값을 포함함 ―;

    상기 컴퓨터로 하여금 상기 라우트 형성 헤더에서 수신된 퍼스널리티 식별자들의 해석을 결정하기 위하여 세션 기준 네트워크 제어기(Session Reference Network Controller)를 액세스하도록 하기 위한 코드들의 제 7 세트;

    상기 컴퓨터로 하여금 선호도의 순서로 상기 지원된 퍼스널리티들을 랭크하도록 하기 위한 코드들의 제 8 세트; 및

    상기 컴퓨터로 하여금 상기 라우트 프로토콜 메시지에 상기 랭크된 지원된 퍼스널리티들을 포함시키도록 하기 위한 코드들의 제 9 세트

    를 더 포함하는, 컴퓨터-판독가능 매체.
66. 제63항에 있어서,

    상기 컴퓨터로 하여금 라우트가 상기 이동 장치에 대하여 이미 확립되어 있는지 여부를 결정하도록 하기 위한 코드들의 제 5 세트; 및

    상기 컴퓨터로 하여금, 라우트가 이미 확립되어 있음이 결정되는 경우, 확립된 라우트의 라우트 식별을 상기 라우트 프로토콜 메시지에 포함시키도록 하기 위한 코드들의 제 6 세트

    를 더 포함하는, 컴퓨터-판독가능 매체.
67. 제63항에 있어서,

    상기 컴퓨터로 하여금 상기 이동 장치와의 세션이 종료되어야 한다는 명령들을 세션 기준 네트워크 제어기로부터 수신하도록 하기 위한 코드들의 제 5 세트; 및

    상기 컴퓨터로 하여금 상기 라우트 프로토콜 메시지에 CRCErrorDetectPattern을 포함시키도록 하기 위한 코드들의 제 6 세트

    를 더 포함하는, 컴퓨터-판독가능 매체.
68. 제63항에 있어서,

    상기 컴퓨터로 하여금 상기 라우트 형성 헤더를 포함하지 않는 패킷을 수신하는 것 및 어떠한 라우트도 존재하지 않음에 기초하여 라우트가 상기 이동 장치에 대하여 확립되어 있지 않음을 결정하도록 하기 위한 코드들의 제 5 세트; 및

    상기 컴퓨터로 하여금, 상기 라우트가 확립되어 있지 않음이 결정되는 경우, 상기 라우트가 존재하지 않음을 표시하는 상기 형성된 라우트 프로토콜 메시지에 에러 코드를 포함시키도록 하기 위한 코드들의 제 6 세트

    를 더 포함하는, 컴퓨터-판독가능 매체.
69. 제63항에 있어서,

    상기 컴퓨터로 하여금 상기 이동 장치의 식별에의 실패가 존재함을 결정하도록 하기 위한 코드들의 제 5 세트; 및

    상기 컴퓨터로 하여금 상기 이동 장치 식별 실패를 표시하기 위하여 상기 라우트 프로토콜 메시지에 에러 코드를 포함시키도록 하기 위한 코드들의 제 6 세트

    를 더 포함하는, 컴퓨터-판독가능 매체.
70. 제69항에 있어서,

    상기 식별 실패는 세션 기준 네트워크 제어기로부터 수신되는, 컴퓨터-판독가능 매체.
71. 제63항에 있어서,

    상기 메시지에서의 RouteID 헤더를 수신하기 위한 코드들의 제 5 세트; 및

    상기 RouteID 헤더가 인식되지 않는 경우, 현재의 라우트 맵에 대한 요청을 송신하기 위한 코드들의 제 6 세트

    를 더 포함하는, 컴퓨터-판독가능 매체.
72. 이동 장치로부터 라우트 형성 헤더를 포함하는 메시지를 수신하기 위한 수단 ― 상기 라우트 형성 헤더는 터널을 정의하는 것과 연관된 하나 이상의 파라미터들을 포함함 ―;

    상기 이동 장치가 개방-대기 상태에 있는지 여부를 결정하기 위한 수단;

    상기 이동 장치가 상기 개방-대기 상태에 있는 경우 적어도 하나의 에러에 대하여 상기 라우트 형성 헤더를 검토하기 위한 수단;

    상기 수신된 메시지에 응답하여 라우트 프로토콜 메시지(Route Protocol Message)를 형성하기 위한 수단; 및

    상기 형성된 라우트 프로토콜 메시지를 상기 이동 장치로 송신하기 위한 수단

    을 포함하는, 장치.
73. 제72항에 있어서,

    상기 이동 장치가 상기 개방-대기 상태에 있지 않고 상기 라우트 형성 헤더가 모든 라우트들 소거 플래그(delete all routes flag)를 포함하지 않는 경우, 이동 장치로부터의 상기 라우트 형성 헤더를 무시하기 위한 수단

    을 더 포함하는, 장치.
74. 제72항에 있어서,

    상기 수신된 라우트 형성 헤더에서 요청된 퍼스널리티가 지원되지 않는지 여부를 결정하기 위한 수단;

    상기 라우트 형성 헤더에서 수신된 퍼스널리티 식별자들의 해석을 결정하기 위하여 세션 기준 네트워크 제어기(Session Reference Network Controller)를 액세스하기 위한 수단;

    선호도의 순서로 상기 지원된 퍼스널리티들을 랭크하기 위한 수단; 및

    상기 라우트 프로토콜 메시지에 상기 랭크된 지원된 퍼스널리티들을 포함시키기 위한 수단

    을 더 포함하는, 장치.
75. 라우트 프로토콜을 위한 적어도 하나의 프로세서로서,

    이동 장치로부터 라우트 형성 헤더를 포함하는 메시지를 수신하도록 동작가능한 제 1 모듈 ― 상기 라우트 형성 헤더는 터널을 정의하는 것과 연관된 하나 이상의 파라미터들을 포함함 ―;

    상기 이동 장치가 개방-대기 상태에 있는지 여부를 결정하도록 동작가능한 제 2 모듈;

    상기 이동 장치가 상기 개방-대기 상태에 있는 경우 적어도 하나의 에러에 대하여 상기 라우트 형성 헤더를 검토하도록 동작가능한 제 3 모듈 ― 상기 라우트 형성 헤더는 상기 이동 장치가 상기 개방-대기 상태에 있지 않은 경우 무시됨 ―;

    상기 수신된 메시지에 응답하여 라우트 프로토콜 메시지(Route Protocol Message)를 형성하도록 동작가능한 제 4 모듈; 및

    상기 형성된 라우트 프로토콜 메시지를 상기 이동 장치로 송신하도록 동작가능한 제 5 모듈

    을 포함하는, 적어도 하나의 프로세서.
76. 제75항에 있어서,

    상기 적어도 하나의 에러는 지원된 퍼스널리티 에러, 이미 확립된 라우트 에러, 세션 종료 에러, 라우트 미확립 에러, 상기 이동 장치의 식별에의 에러, 또는 이들의 조합 중 하나인, 적어도 하나의 프로세서.

Images