KR20230005277A

KR20230005277A - 핸드오버 실패 시나리오에서 네트워크 최적화 관리

Info

Publication number: KR20230005277A
Application number: KR1020227041058A
Authority: KR
Inventors: 테밍 첸
Original assignee: 구글 엘엘씨
Priority date: 2020-04-30
Filing date: 2021-04-28
Publication date: 2023-01-09
Also published as: CN115918156A; WO2021222416A1; AU2021264532A1; CA3177302A1; CN115669063A; EP4136878A1; WO2021222423A1; EP4136879A1; US20230171655A1; US20230171648A1

Abstract

제1 무선 액세스 기술과 연관된 제1 셀에 연결된 사용자 장비(UE)의 프로세싱 하드웨어는 제2 RAT와 연관된 제2 셀로의 핸드오버를 지원하기 위한 방법을 구현할 수 있다. 방법은 제2 셀에 연결을 시도하는 단계(2302) 및 제2 셀과 연관된 구성의 적용 실패를 검출하는 단계(2304)를 포함한다. 방법은 무선 연결을 재설정하라는 요청을 전송함으로써 제1 셀을 통해 구성의 적용 실패의 표시를 제공하는 단계(2306)를 더 포함하며, 요청은 재구성 실패를 나타내는 실패 원인을 포함한다.

Description

핸드오버 실패 시나리오에서 네트워크 최적화 관리

본 명세서는 일반적으로 무선 통신에 관한 것이고, 보다 구체적으로, 핸드오버 실패 시나리오에서 네트워크 최적화 및 실패 보고를 관리하는 것에 관한 것이다.

이 배경 설명은 본 개시 내용의 컨텍스트를 일반적으로 제시할 목적으로 제공된다. 이 배경 섹션에 설명된 범위 내에서 현재 명명된 발명가의 작업 뿐만 아니라 출원 당시 선행 기술로 인정되지 않을 수 있는 설명의 양태는 본 개시 내용에 대해 선행 기술로 명시적으로나 묵시적으로 인정되지 않는다.

5세대(5G) 표준 및 기술로의 무선 통신의 진화는 향상된 안정성과 낮은 대기 시간과 함께 더 높은 데이터 속도와 더 큰 용량을 제공하여 모바일 광대역 서비스를 향상시킨다. 5G 기술은 또한 차량, 고정 무선 광대역 및 사물 인터넷(IoT)을 위한 새로운 차원의 서비스를 제공한다. 5G 무선 인터페이스의 기능 스펙은 5G NR(5G New Radio)로 정의된다.

RAN(Radio Access Network)과 무선으로 통신하기 위해, 사용자 장비(UE)는 5세대 코어 네트워크(5GC)를 지원하는 적어도 하나의 네트워크 노드(예를 들어, 기지국 또는 서빙 셀)를 통해 RAN에 대한 연결을 설정할 수 있다. 일부 상황에서, 기지국(BS)은 핸드오버 절차를 사용하여 UE가 다른 BS에 연결하도록 요청할 수 있다. 핸드오버 절차 동안, UE는 RAN에 대한 연결을 잃지 않고 소스 BS에서 타겟 BS 또는 셀로 전환할 수 있다. 소스 BS 및 타겟 BS 노드는 동일한 RAT(radio access technology) 또는 다른 RAT와 연관될 수 있다.

통신 시스템에서 무선 프로토콜 스택의 PDCP(Packet Data Convergence Protocol) 서브계층은 사용자 평면 데이터 전송, 암호화, 무결성 보호 등과 같은 서비스를 제공한다. 예를 들어, EUTRA(Evolved Universal Terrestrial Radio Access) 무선 인터페이스(3GPP TS 36.323 참조) 및 NR(New Radio)(TS 38.323 참조)에 대해 정의된 PDCP 계층은 업링크 방향(사용자 장비(UE)에서 기지국으로) 및 다운링크 방향(기지국에서 UE로)에서 프로토콜 데이터 단위(PDU: protocol data unit)의 시퀀싱을 제공한다. 또한, PDCP 서브계층은 RRC(Radio Resource Control) 서브계층에 시그널링 무선 베어러(SRB) 및 데이터 무선 베어러(DRB)를 제공한다. 일반적으로 UE와 기지국은 SRB를 사용하여 RRC 메시지와 NAS(Non-Access Stratum) 메시지를 교환하고 DRB를 사용하여 사용자 평면(user plane)에서 데이터를 전송할 수 있다.

UE와 RAN 사이의 무선 링크에서 그리고 UE와 RAN이 한 기지국에서 다른 기지국으로 UE를 핸드오버하기 위해 수행하는 절차 동안 다양한 오류가 발생할 수 있다. 일반적으로 UE는 서로 다른 오류 코드를 사용하여 RAN에 서로 다른 종류의 오류를 보고한다. 그러나 어떤 경우에는 기존 오류 보고 방식으로 인해 UE가 RAN에 오류를 정확하게 보고하지 않는다.

특히, 기존 기술은 DAPS(Dual Active Protocol Stack) 핸드오버 및 인터-RAT 핸드오버와 같은 핸드오버 절차에서 검출된 오류를 항상 명확하게 지정하지 않는다. 이러한 시나리오에서 차선책 오류 보고의 결과로, 네트워크는 UE가 검출한 문제를 다루지 않는 오류 완화 기술(예를 들어, MRO(Mobility Robustness Optimization))을 수행할 수 있다.

본 개시의 UE 및/또는 기지국은 네트워크 최적화를 지원하기 위해 DAPS 핸드오버 또는 인터-RAT 핸드오버를 포함하는 시나리오에서 오류를 관리할 수 있다.

예를 들어, DAPS(Dual Active Protocol Stack) 핸드오버 시 기지국에 연결된 단말은 원래 기지국과의 연결을 유지하면서 타겟 기지국으로의 연결을 시도한다. UE는 타겟 기지국과의 연결 및 원래 기지국과의 연결 모두에서 문제를 검출할 수 있다. 본 개시의 UE는 이러한 오류들의 상호작용을 완화하고 네트워크에 대한 불완전하거나 부정확한 오류 보고를 감소시키고, 이에 의해 네트워크가 DAPS 핸드오버 실패를 프로세싱하는 것을 돕는다.

다른 예로, 제1 RAT(Radio Access Technology)(예: 4세대(4G) RAT)의 셀에 연결된 UE는 인터-RAT 핸드오버를 통해 제2 RAT(예: 5세대(5G) RAT)의 셀에 연결을 시도한다. UE가 핸드오버를 완료할 수 없는 경우, UE는 핸드오버 실패를 보고할 수 있다. 기존 기술이 항상 핸드오버 실패의 이유를 명확하게 지정하지 않는 반면, 본 개시의 UE는 RAN이 실패를 적절하게 프로세싱하도록 허용하는 이유(예: 핸드오버 요청에서 구성의 적용 실패)를 보고한다.

일부 시나리오에서, 본 개시의 UE는 초기에 기지국과 연결하여 동작하고 DAPS 핸드오버 동안 타겟 기지국에 연결을 시도한다. UE가 (i) 타이머가 실행되는 동안 (소스) 기지국과의 연결과의 동기화 문제 검출에 응답하여 UE가 시작하는 DAPS 핸드오버 실패를 검출하거나 (ii) 무선 실패(장애)를 검출하기 전에 DAPS 핸드오버 실패를 검출하면, UE는 핸드오버 실패에 대응하는 실패 원인을 포함하는 RRCReestablishmentRequest를 기지국으로 전송함으로써 DAPS 핸드오버 실패를 보고할 수 있다. 또는, UE가 무선 링크 실패(RLF: radio link failure)에 대응하는 실패 원인을 포함하는 RRCReestablishmentRequest를 전송하는 경우, 본 개시의 기지국은 여전히 UE가 DAPS 핸드오버 실패를 검출했는지 여부를 결정할 수 있다. 기지국이 이전에 DAPS 핸드오버 구성을 UE에 전송하고 핸드오버가 성공하거나 실패했다는 표시를 수신하지 못한 경우, 기지국은 UE가 DAPS 핸드오버 실패를 검출했다고 결정할 수 있고, 그에 따라 네트워크 최적화를 수행할 수 있다.

다른 시나리오에서, UE는 초기에 제1 셀을 통해 기지국과 연결하여 동작하고 상이한 RAT와 연관된 제2 셀에 연결을 시도한다. 단말이 제2 셀과 연관된 구성을 적용할 수 없는 경우, 단말은 재구성 실패에 대응하는 실패 원인을 포함하는 RRCReestablishmentRequest를 기지국으로 전송한다. 대안적으로, UE가 대신 핸드오버 실패에 대응하는 실패 원인을 포함하는 RRCReestablishmentRequest를 전송하는 경우, 본 개시의 기지국은 여전히 UE가 구성을 적용할 수 없었는지 여부를 결정할 수 있다. 기지국이 나중에 UE에서 핸드오버 정보를 사용할 수 없다는 표시를 수신하면, 기지국은 UE가 구성을 적용할 수 없다고 결정하고 적절한 시정 액션를 취할 수 있다.

본 개시물의 기술의 예시적인 실시예는 RAN의 제1 기지국에 연결된 UE에서 DAPS 핸드오버를 지원하기 위한 방법이다. 이 방법은 프로세싱 하드웨어에 의해 구현되며 DAPS 핸드오버 동안 RAN의 제2 기지국에 연결을 시도하는 단계를 포함한다. 방법은 또한 제1 기지국에 대한 무선 연결과 연관된 잠재적인 실패를 검출하는 단계 및 제2 기지국에 대한 연결 실패를 검출하는 단계를 포함한다. 또한, 방법은 무선 연결을 재설정하기 위한 절차를 개시하는 단계를 포함하고, 개시하는 것은 연결 실패의 표시를 RAN에 제공하는 것을 포함한다.

이러한 기술의 다른 예시적인 실시예는 RAT와 연관된 제1 셀에 연결된 UE에서 제2 RAT와 연관된 제2 셀로의 핸드오버를 지원하기 위한 방법이다. 방법은 프로세싱 하드웨어에 의해 수행되고 제2 셀에 연결을 시도하고 제2 셀과 연관된 구성의 적용 실패를 검출하는 단계를 포함한다. 방법은 또한 제1 셀을 통해 구성의 적용 실패의 표시를 제공하는 단계를 포함한다.

이러한 기술의 또 다른 예시적인 실시예는 프로세싱 하드웨어를 포함하고 위의 방법을 실행하도록 구성된 UE이다.

이러한 기술의 또 다른 예시적인 실시예는 무선 링크를 통해 UE와 통신하는 제1 기지국에서의 방법이다. 방법은 프로세싱 하드웨어에 의해 구현되며, UE가 DAPS 핸드오버 절차 동안 제2 기지국에 연결해야 하는 구성을 전송하는 단계를 포함한다. 방법은 또한 UE가 무선 링크의 실패를 검출했다는 표시를 수신하는 단계를 포함한다. 또한, 방법은 UE가 제2 기지국에 대한 연결 실패를 검출했다고 결정하는 단계, 및 결정에 기초하여 네트워크 최적화 절차를 수행하는 단계를 포함한다.

이들 기술의 다른 예시적인 실시예는 제1 RAT의 제1 셀을 지원하는 기지국에서 인터-RAT 핸드오버를 지원하기 위한 방법이다. 이 방법은 프로세싱 하드웨어에 의해 수행되며, 제2 RAT의 제2 셀에 연결하기 위한 UE에 대한 요청을 사용자 장비(UE)에 전송하는 단계를 포함한다. 요청에는 UE가 제2 셀에 연결하는 데 사용할 구성이 포함된다. 방법은 또한 무선 연결을 재설정하라는 요청을 UE로부터 수신하는 단계를 포함하고, 요청은 핸드오버 실패를 나타내는 실패 원인을 포함한다. 또한, 방법은 UE와 무선 연결을 구성하기 위한 메시지를 전송하고 그리고 메시지에 대한 응답을 수신하는 단계를 포함하고, 응답은 핸드오버 실패 정보를 사용할 수 없음을 나타낸다. 또한, 방법은 UE가 구성을 적용할 수 없었다고 결정하는 단계 및 결정에 응답하여 시정 액션을 수행하는 단계를 포함한다.

이러한 기술의 또 다른 예시적인 실시예는 프로세싱 하드웨어를 포함하고 위의 방법을 실행하도록 구성된 기지국이다.

도 1은 무선 액세스 네트워크(RAN) 및 사용자 장비가 핸드오버 실패 시나리오에서 네트워크 최적화를 관리하기 위해 본 개시의 기술을 구현할 수 있는 예시적인 시스템의 블록도이다.
도 2는 도 1의 UE가 기지국과 통신하는 예시적인 프로토콜 스택의 블록도이다.
도 3은 UE가 RAN의 기지국에 실패 정보를 전달하는 예시적인 시나리오의 블록도이다.
도 4는 UE가 이중 활성 프로토콜 스택(DAPS: dual active protocol stack) 구성에 따라 기지국(BS)에서 타겟 기지국(T-BS)으로의 핸드오버를 성공적으로 완료하는 예시적인 시나리오의 메시징 다이어그램이다.
도 5는 UE가 BS와의 무선 링크에서 동기화 문제를 검출한 후 및 RLF를 검출하기 전에 DAPS 핸드오버 실패를 검출하는 예시적인 시나리오의 메시징 다이어그램이다.
도 6은 UE가 DAPS 핸드오버 실패를 검출한 후 RLF를 검출하는 예시적인 시나리오의 메시징 다이어그램이다.
도 7은 UE가 DAPS 핸드오버 실패를 검출한 후 RLF를 검출하는 다른 예시적인 시나리오의 메시징 다이어그램이다.
도 8은 이전에 UE에 DAPS 구성을 전송한 BS가 다른 실패(otherFailure)에 대응하는 실패 원인을 나타내는 RRC 재설정 요청(RRCReestablishmentRequest)을 UE로부터 수신하는 예시적인 시나리오의 메시징 다이어그램이다.
도 9는 이전에 UE에 DAPS 구성을 전송한 BS가 UE가 otherFailure에 대응하는 실패 원인을 나타내는 RRCReestablishmentRequest를 전송했음을 나타내는 실패 보고를 다른 BS로부터 수신하는 예시적인 시나리오의 메시징 다이어그램이다.
도 10은 본 개시의 UE에서 구현될 수 있는, RLF를 검출하기 전에 DAPS 핸드오버 실패를 검출하는 것을 포함하는 예시적인 방법의 흐름도이다.
도 11은 본 개시의 UE에서 구현될 수 있는, 동기화 문제의 검출에 응답하여 UE가 시작하는 타이머가 실행되는 동안 DAPS 핸드오버 실패를 검출하는 것을 포함하는 예시적인 방법의 흐름도이다.
도 12는 본 개시의 UE에서 구현될 수 있는, DAPS 핸드오버 실패를 나타내는 실패 정보 메시지를 성공적으로 전송하지 못한 것에 응답하여 RRC 재설정 절차를 초기화하는 것을 포함하는 예시적인 방법의 흐름도이다.
도 13은 본 개시의 기지국에서 구현될 수 있는 무선 연결을 재설정하라는 UE로부터의 요청에서 수신된 실패 원인에 기초하여 네트워크 최적화를 수행하는 것을 포함하는 예시적인 방법의 흐름도이다.
도 14는 본 개시의 기지국에서 구현될 수 있는, 다른 기지국으로부터 실패 보고에서 수신된 실패 원인에 기초하여 네트워크 최적화를 수행하는 것을 포함하는 예시적인 방법의 흐름도이다.
도 15는 UE가 인트라-RAT 핸드오버 구성을 적용하는 데 실패한 예시적인 시나리오의 메시징 다이어그램이다.
도 16은 UE가 인터-RAT 핸드오버 구성을 적용하는 데 실패한 예시적인 시나리오의 메시징 다이어그램이다.
도 17은 UE가 인터-RAT 핸드오버 구성을 적용하는 데 실패한 다른 예시적인 시나리오의 메시징 다이어그램이다.
도 18은 본 개시의 UE에서 구현될 수 있는, 인터-RAT 핸드오버 구성의 적용 실패를 검출하는 것에 기초하여 RRC 재설정 절차를 초기화하는 것을 포함하는 예시적인 방법의 흐름도이다.
도 19는 본 개시의 UE에서 구현될 수 있는, 인터-RAT 핸드오버 구성의 적용 실패를 검출하는 것에 기초하여 RRC 재설정 절차를 초기화하는 것을 포함하는 다른 예시적인 방법의 흐름도이다.
도 20은 본 개시의 기지국에서 구현될 수 있는, UE가 인터-RAT 핸드오버 구성의 적용 실패를 검출한 것을 결정하는 것을 포함하는 예시적인 방법의 흐름도이다.
도 21은 본 개시의 UE에서 구현될 수 있는 DAPS 핸드오버를 지원하기 위한 예시적인 방법의 흐름도이다.
도 22는 본 개시의 기지국에서 구현될 수 있는 DAPS 핸드오버를 포함하는 시나리오에서 네트워크 최적화를 위한 예시적인 방법의 흐름도이다.
도 23은 본 개시의 UE에서 구현될 수 있는 인터-RAT 핸드오버를 지원하기 위한 예시적인 방법의 흐름도이다.
도 24는 본 개시의 기지국에서 구현될 수 있는 인터-RAT 핸드오버를 포함하는 시나리오에서 네트워크 최적화를 위한 예시적인 방법의 흐름도이다.

일반적으로 말해서, 본 개시의 통신 장치는 이중 활성 프로토콜 스택(DAPS: dual active protocol stack) 핸드오버 절차 및 인터-RAT 핸드오버 절차와 연관된 절차를 구현한다. DAPS 핸드오버 절차에서, 아래에서 설명되는 바와 같이, 기지국(BS)은 DAPS 구성(configuration)을 사용하여 타겟 기지국(T-BS)으로 핸드오버하도록 UE를 구성할 수 있다. UE가 T-BS로의 핸드오버를 성공적으로 완료한 후, T-BS는 UE와 BS 간의 연결을 해제하도록 UE를 구성한다. UE가 T-BS에 연결할 수 없는 경우, UE는 원래 구성으로 복귀하고 원래 BS와 연결된 상태를 유지한다. 한 구현에서, 연결 해제는, MAC(Medium Access Control) 프로토콜을 재설정하고 MAC 구성을 해제하는 것, SRB/DRB 무선 링크 제어(RLC) 엔티티 및 연관된 논리 채널을 해제하는 것, DRB PDCP 엔티티를 일반 PDCP로 재구성하는 것, SRB PDCP 엔티티를 해제하는 것, 물리적 채널 구성을 해제하는 것 또는 키(KgNB, S-KgNB, S-KeNB, KRRCenc, KRRCint, KUPint 및/또는 KUPenc 키)를 폐기하는 것을 포함할 수 있다. 인터-RAT 핸드오버(inter-RAT handover)는 한 RAT(Radio Access Technology)에서 다른 RAT로의 핸드오버이다(예: 4세대(4G) RAT에서 5세대(5G) RAT로 또는 그 반대로).

도 1은 통신 디바이스(장치)들이 본 개시물의 기술들을 구현할 수 있는 예시적인 무선 통신 시스템(100)을 도시한다. 무선 통신 시스템(100)은 UE(102), 기지국(104), 기지국(106), 및 코어 네트워크(CN)(110)를 포함한다. 본 개시에서 설명된 시나리오에서, UE(102)는 초기에 기지국(104)에 연결한다.

일부 시나리오에서, 기지국(104)은 기지국(104)의 셀(124)로부터 기지국(106)(타겟 BS 또는 "T-BS")의 셀(126)로의 핸드오버를 실행하도록 UE(102)를 구성하기 위해 즉각적인 핸드오버 준비 절차를 수행할 수 있다. 즉각적인 핸드오버 동안, UE(102)는 BS(104)로부터 연결을 끊고 T-BS(106)에 연결을 시도한다.

다른 시나리오에서, 기지국(104)은 기지국(104)의 셀(124)로부터 기지국(106)(타겟 BS 또는 "T-BS")의 셀(126)로의 핸드오버를 실행하도록 UE(102)를 구성하기 위해 DAPS 핸드오버 준비 절차를 수행할 수 있다. 위에서 설명된 즉각적인 핸드오버의 경우와 대조적으로, UE(102)는 BS(104)로부터 즉시 연결해제하지 않는다. 이 시나리오에서, UE(102)는 UE(102)가 T-BS(106)에 연결한 후에 BS(104)로부터 연결을 끊는다(연결 해제). 보다 구체적으로, UE(102)가 T-BS(106)에 대한 구성을 수신할 때, UE(102)는 T-BS(106)로부터 연결해제 구성(disconnection configuration)을 수신할 때까지 BS(104)로부터 연결해제하지 않는다.

기지국(104 및 106)은 eNB(evolved node B), 차세대 eNB(ng-eNB) 또는 5G 노드 B(gNB)와 같은 기지국의 임의의 적합한 유형 또는 유형일 수 있다. UE(102)는 EUTRA 또는 NR과 같은 동일한 RAT, 또는 상이한 RAT를 통해 기지국(104) 및 기지국(106)과 통신할 수 있다. 기지국(104)은 셀(124)을 지원하고, 기지국(106)은 셀(126)을 지원한다. 셀(124)은 셀(126)과 부분적으로 중첩되어, UE(102)는 기지국(104)과 통신하기 위한 범위 내에 있는 동시에 기지국(106)과 통신하기 위한 범위 내(또는 기지국(106)으로부터의 신호를 검출하거나 측정하기 위한 범위 내)에 있을 수 있다. 중첩은 UE(102)가 셀(예를 들어, 셀(124)에서 셀(126)으로) 또는 기지국(예를 들어, 기지국(104)에서 기지국(106)으로) 사이에서 핸드오버하는 것을 가능하게 할 수 있다. 다른 예로서, UE(102)는 기지국(104)(MN으로서 동작함) 및 기지국(106)(SN으로서 동작함)과 이중 연결(DC: dual connectivity)로 통신할 수 있다.

기지국(104, 106)은 EPC(evolved packet core)(111) 또는 5세대 코어(5GC)(160)일 수 있는 동일한 코어 네트워크(CN)(110)에 연결할 수 있다. 기지국(104)은 EPC(111)와 통신하기 위한 S1 인터페이스를 지원하는 eNB로, 5GC(160)와 통신하기 위한 NG 인터페이스를 지원하는 ng-eNB로, 또는 NR 무선 인터페이스와 5GC 160과의 통신을 위한 NG 인터페이스를 지원하는 gNB로 구현될 수 있다. 기지국(106)은 EPC(111)에 대한 S1 인터페이스를 갖는 eNB로, EPC(111)에 연결되지 않은 ng-eNB로, NR 무선 인터페이스와 5GC 160에 대한 NG 인터페이스를 지원하는 gNB로, EUTRA 무선 인터페이스와 5GC 160에 대한 NG 인터페이스를 지원하는 ng-eNB로서 구현될 수 있다. 아래에서 설명되는 시나리오 동안 메시지를 직접 교환하기 위해, 기지국(104, 106)은 X2 또는 Xn 인터페이스를 지원할 수 있다.

다른 컴포넌트들 중에서, EPC(111)는 서빙 게이트웨이(S-GW: Serving Gateway)(112) 및 이동성 관리 엔티티(MME: Mobility Management Entity)(114)를 포함할 수 있다. S-GW(112)는 일반적으로 음성 통화, 화상 통화, 인터넷 트래픽 등과 연관된 사용자 평면 패킷을 전송하도록 구성되고, MME(114)는 인증, 등록, 페이징 및 기타 관련 기능을 관리하도록 구성된다. 5GC(160)는 사용자 평면 기능(UPF: User Plane Function)(162) 및 액세스 및 이동성 관리(AMF)(164), 및/또는 세션 관리 기능(SMF)(166)을 포함한다. 일반적으로 말하면, UPF(162)는 음성 통화, 영상 통화, 인터넷 트래픽 등과 연관된 사용자 평면 패킷을 전송하도록 구성되고, AMF(164)는 인증, 등록, 페이징 및 기타 관련 기능을 관리하도록 구성되며, SMF(166)는 PDU 세션을 관리하도록 구성된다.

일반적으로, 무선 통신 네트워크(100)는 NR 셀 및/또는 EUTRA 셀을 지원하는 임의의 적절한 수의 기지국을 포함할 수 있다. 보다 구체적으로, EPC(111) 또는 5GC(160)는 NR 셀 및/또는 EUTRA 셀을 지원하는 임의의 적절한 수의 기지국에 연결될 수 있다. 아래 예는 특정 CN 유형(EPC, 5GC) 및 RAT 유형(5G NR 및 EUTRA)을 구체적으로 언급하지만, 일반적으로, 본 개시물의 기술은 또한 예를 들어 6세대(6G) 무선 액세스 및/또는 6G 코어 네트워크 또는 5G NR-6G DC와 같은 다른 적절한 무선 액세스 및/또는 코어 네트워크 기술에 적용될 수 있다.

계속해서 도 1을 참조하면, 기지국(104)은 하나 이상의 범용 프로세서(예: 중앙 프로세싱 장치(CPU)) 및 하나 이상의 범용 프로세서(들) 상에서 실행가능한 기계 판독가능 명령어를 저장하는 비일시적 컴퓨터 판독가능 메모리를 포함할 수 있는 프로세싱 하드웨어(130) 및/ 또는 특수 목적 프로세싱 장치를 갖는다. 예시적인 구현에서 프로세싱 하드웨어(130)는 하나 이상의 RRC 구성 또는 RRC 절차를 관리 또는 제어하도록 구성된 기지국 RRC 제어기(132)를 포함한다. 예를 들어, 기지국 RRC 제어기(132)는 DAPS 및/또는 인터-RAT 핸드오버와 연관된 RRC 메시징(messaging)을 지원하고 아래에서 설명되는 기술을 지원하도록 구성될 수 있다.

기지국(106)은 CPU와 같은 하나 이상의 범용 프로세서, 및 하나 이상의 범용 프로세서에서 실행 가능한 기계 판독 가능 명령어를 저장하는 비일시적 컴퓨터 판독 가능 메모리를 포함할 수 있는 프로세싱 하드웨어(140) 및/또는 특수 목적 프로세싱 장치를 갖는다. 예시적인 구현에서 프로세싱 하드웨어(140)는 기지국 제어기(132)와 유사할 수 있는 기지국 RRC 제어기(142)를 포함한다.

도 1을 참조하면, UE(102)는 CPU와 같은 하나 이상의 범용 프로세서, 및 하나 이상의 범용 프로세서에서 실행 가능한 기계 판독 가능 명령어를 저장하는 비일시적 컴퓨터 판독 가능 메모리를 포함할 수 있는 프로세싱 하드웨어(150) 및/또는 특수 목적 프로세싱 장치를 갖는다. 예시적인 구현에서 프로세싱 하드웨어(150)는 하나 이상의 RRC 구성 및/또는 RRC 절차를 관리 또는 제어하도록 구성된 UE RRC 제어기(152)를 포함한다. 예를 들어, UE RRC 제어기(152)는 DAPS 및/또는 인터-RAT 핸드오버와 연관된 RRC 메시징을 지원하고 아래에서 설명되는 기술을 지원하도록 구성될 수 있다.

동작시, UE(102)는 상이한 시간에 기지국(104) 또는 기지국(106)에서 종료하는 무선 베어러(radio bearer)(예를 들어, DRB 또는 SRB)를 사용할 수 있다. UE(102)는 무선 베어러 상에서, 업링크(UE(102)에서 기지국으로) 및/또는 다운링크(기지국에서 UE(102)로) 방향으로 통신할 때 하나 이상의 보안 키를 적용할 수 있다.

다음으로, 도 2(종래 기술)는 단순화된 방식으로, UE(102)가 eNB/ng-eNB 또는 gNB(예를 들어, 기지국(104 및 106) 중 하나 이상)와 통신할 수 있는 예시적인 무선 프로토콜 스택(200)을 나타낸다. EUTRA의 물리적 계층(PHY)(202A)은 EUTRA 매체 액세스 제어(MAC) 서브계층(204A)에 전송 채널을 제공하고, 이는 차례로 EUTRA RLC(Radio Link Control) 서브계층(206A)에 논리 채널을 제공한다. EUTRA RLC 서브계층(206A)은 차례로 RLC 채널을 EUTRA PDCP 서브계층(208)에 제공하고 일부 경우에는 NR PDCP 서브계층(210)에 제공한다. 유사하게, NR PHY(202B)는 NR MAC 서브계층(204B)에 전송 채널을 제공하고, 이는 차례로 NR RLC 서브계층(206B)에 논리 채널을 제공한다. NR RLC 서브계층(206B)은 차례로 NR PDCP 서브계층(210)에 RLC 채널을 제공한다. 일부 구현들에서, UE(102)는 EUTRA와 NR 기지국들 간의 핸드오버를 지원하고/하거나 EUTRA 및 NR 인터페이스를 통한 DC를 지원하기 위해 EUTRA 및 NR 스택 모두를 지원한다. 또한, 도 2에 도시된 바와 같이, UE(102)는 EUTRA RLC 서브계층(206A)에 대한 NR PDCP 서브계층(210)의 계층화를 지원할 수 있다.

EUTRA PDCP 서브계층(208) 및 NR PDCP 서브계층(210)은 서비스 데이터 유닛(SDU)으로 지칭될 수 있는 패킷을 수신하고(예를 들어, PDCP 계층(208 또는 210) 위에 직접 또는 간접적으로 계층화된 인터넷 프로토콜(IP) 계층에서), 프로토콜 데이터 유닛(PDU)으로 지칭될 수 있는 출력 패킷을 수신한다(예를 들어, RLC 층(206A 또는 206B)으로). SDU와 PDU 간의 차이가 연관된 경우를 제외하고, 단순화를 위해 본 개시는 SDU와 PDU를 모두 "패킷"으로 지칭한다.

제어 평면에서, EUTRA PDCP 서브계층(208) 및 NR PDCP 서브계층(210)은 예를 들어 RRC 메시지를 교환하기 위해 SRB를 제공한다. 사용자 평면에서, EUTRA PDCP 서브계층(208) 및 NR PDCP 서브계층(210)은 데이터 교환을 지원하기 위해 DRB를 제공한다.

다음으로, 도 3(종래 기술)은 공지된 기술에 따라 UE(102)가 실패 정보를 RAN의 기지국(104 및 106)에 전달하는 예시적인 시나리오(300) 동안의 메시징 시퀀스를 도시한다. 기지국(104)은 소스 기지국으로 동작하고, 기지국(106)은 타겟 기지국(T-BS)으로 동작한다. 초기에, UE는 BS(104)와의 연결 모드에서 동작(302)한다. 나중에, UE(102)는 BS(104)와의 무선 연결에서 연결 실패를 검출하고 T-BS(106)에 연결하기로 결정한다(304).

검출에 응답하여, UE(102)는 연결 실패 보고(connection failure report)를 T-BS(106)에 전송한다(306). 한 예에서, 연결 실패 보고(보고서 또는 리포트)는 실패의 원인(예를 들어, UE(102)가 핸드오버 실패를 검출했음을 나타내기 위한 handoverFailure, 또는 UE(102)가 RLF를 검출하였음을 나타내기 위한 otherFailure)을 나타내는 재설정 원인을 포함하는 RRCReestablishmentRequest 메시지이다. 본 개시는 또한 이 재설정 원인을 실패 원인으로 지칭한다. 다른 예에서, 연결 실패 보고는 실패 표시(예를 들어, daps-failure로 설정된 failureType)를 포함하는 실패 정보(FailureInformation) 메시지이다.

그 다음, T-BS(106)는 연결 실패 표시를 BS(104)에 전송한다(308). 일례에서, 연결 실패 표시는 RLF INDICATION 메시지(예를 들어, T-BS(106)가 eNB인 경우) 또는 FAILURE INDICATION 메시지(예를 들어, T-BS(106)가 gNB인 경우)이다. T-BS(106)는 연결 실패 표시에 실패 원인을 포함한다(예를 들어, RRC Conn Reestab Indicator, UE RLF Report Container, 또는 핸드오버 실패, 무선 링크 실패 또는 조건부 핸드오버 실패의 다른 표시).

연결 실패 표시(예: 실패 원인이 핸드오버 실패, 무선 링크 실패 또는 기타 실패인지 기준)에 따라 기지국(104)은 MRO(Mobility Robustness Optimization)를 수행한다. 일 예에서, 실패 원인이 무선 링크 실패 또는 다른 실패라면, BS(104)는 핸드오버 시도가 너무 늦었다고 결정한다. BS(104)는 MRO에 응답하여 UE(102) 및 다른 UE에 대한 측정 구성을 조정할 수 있다. 일 구현에서, BS(104)는 "Event A2 (이벤트 A2)(서빙이 임계값보다 나빠짐)"에서 임계값을 증가시킬 수 있다. 이러한 변경의 결과로, UE(102)는 이 이벤트를 더 일찍 보고한다. 다른 구현에서, BS(104)는 "이벤트 A3"에서 오프셋을 감소시킬 수 있고(이웃이 SpCell보다 더 나은 오프셋이 됨), 그 결과 UE(102)는 이 이벤트를 더 일찍 보고한다.

다른 예에서, 실패 원인이 핸드오버 실패라면, BS(104)는 핸드오버 시도가 너무 이르다고 결정한다. BS(104)는 MRO에 응답하여 UE(102) 및 다른 UE에 대한 측정 구성을 조정할 수 있다. 한 구현에서, BS(104)는 "이벤트 A2(서빙이 임계값보다 나빠짐)"에서 임계값을 감소시킬 수 있고, 결과적으로 UE(102)는 이 이벤트를 나중에 보고한다. 다른 구현에서, BS(104)는 "이벤트 A3(이웃은 SpCell보다 더 나은 오프셋이 됨)"에서 오프셋을 증가시킬 수 있고, 결과적으로 UE(102)는 이 이벤트를 나중에 보고한다.

일 예에서, BS(104) 및 T-BS(106)는 동일한 기지국과 연관된 동일하거나 상이한 셀일 수 있으며, 이 경우 BS(104)와 T-BS(106) 사이에는 연결 실패 표시 교환이 없다.

도 4(종래 기술)는 공지된 기술에 따라 UE(102)가 BS(104)로부터 T-BS(106)로의 DAPS 핸드오버를 성공적으로 완료하는 예시적인 시나리오(400) 동안 메시징 시퀀스를 도시한다. 초기에, UE(102)는 BS(104)와의 연결 모드에서 동작(402)한다. BS(104)는 DAPS 구성을 사용하여 UE(102)를 T-BS(106)로 핸드오버하기로 결정(404)한다. 이 결정에 응답하여, BS(104)는 DAPS 구성(예를 들어, dapsConfig)을 갖는 RRC 재구성(RRCReconfiguration) 메시지를 UE(102)로 전송(406)한다. RRCReconfiguration 메시지에 응답하여, UE(102)는 타이머 T304를 시작하고(408) DAPS 구성에 따라 T-BS(106)와 랜덤 액세스 절차를 시도한다(410). 랜덤 액세스 절차 동안, UE(102)는 BS(104)와의 연결을 유지(410)한다. 타이머(T304)는 UE(102)가 T-BS(104)에 연결을 시도하는 시간을 추적하는 데 사용된다. UE(102)가 T-BS(104)로의 핸드오버를 성공적으로 완료하기 전에 타이머(T304)가 만료되면, UE(102)는 DAPS 핸드오버 실패를 검출한다. 본 개시 내용은 일반적으로 "DAPS 핸드오버 실패"를 언급하지만, 이러한 오류는 때때로 동기화 실패를 포함하는 재구성이라고도 한다. 이벤트(402, 406, 408, 410)는 집합적으로 DAPS 핸드오버 시도 절차(450)로 지칭된다.

나중에, UE(102)는 T-BS(106)와의 랜덤 액세스 절차를 성공적으로 수행한다(412). 이에 응답하여, UE(102)는 타이머 T304를 중지하고(412) RRC재구성 완료(RRCReconfigurationComplete) 메시지를 T-BS(106)에 전송한다(414). UE(102)는 T-BS(106)와 연결 모드에서 동작(416)한다. RRCReconfigurationComplete 메시지 수신에 응답하여, T-BS(106)는 핸드오버 성공(Handover Success) 메시지를 BS(104)로 전송(418) 및/또는 DAPS 해제 표시(예를 들어, daps-SourceRelease)를 포함하는 RRCReconfiguration 메시지를 UE(102)로 전송할 수 있다(420). 그 다음 UE(102)는 UE와 BS(104) 사이의 연결을 해제(422)한다.

도 5-7은 UE(102)가 네트워크 최적화를 지원하기 위해 본 개시의 기술을 사용할 수 있는 DAPS 핸드오버 실패 시나리오에 대응하는 예시적인 메시징 시퀀스를 도시한다.

도 5는 기지국(104)이 소스 기지국으로서 동작하고 기지국(106)이 타겟 기지국(T-BS)으로서 동작하는 시나리오(500)를 예시한다. 초기에, UE(102)는 DAPS 핸드오버 시도 절차(450)와 유사하게 T-BS로의 DAPS 핸드오버를 수행하기 위해 시도한다(550). UE(102)가 T-BS(106)와 랜덤 액세스 절차를 성공적으로 수행하기 전에, UE는 BS(104)와의 무선 연결에서 동기화 문제를 검출(509)하고(예: PHY 계층이 동기화되지 않은 것을 검출) BS(104)에 대한 타이머 T310을 시작(509)한다. UE(102)가 타이머 T310을 시작한 후 그리고 T310이 만료되기 전에, UE(102)는 타이머 T304가 만료되었음을 검출한다(511). 기존 표준에 따라 T304 타이머가 만료되었음을 검출한 후, UE(102)는 DAPS 핸드오버 실패를 표시하기 위해 실패 정보(FailureInformation) 메시지를 전송한다. 그러나, 시나리오 500에서, UE(102)는 FailureInformation 메시지를 전송하기 전에 타이머 T310이 실행 중인지 여부를 확인한다. 타이머 T310이 실행되는 동안 만료되는 타이머 T304에 응답하여, UE(102)는 FailureInformation 메시지 전송을 중단하기로 결정한다(513). 일 구현에서, UE(102)는 T304 만료에 응답하여 타이머 T310을 중지할 수 있다(515). 그 다음, UE(519)는 핸드오버 실패 실패 원인과 함께 RRC 재설정 요청(RRCReestablishmentRequest)를 BS(104)로 전송한다. 이에 대한 응답으로 기지국(104) 또는 T-BS(106)는 핸드오버 실패에 기초하여 MRO를 수행한다(530).

따라서, UE(102)가 타이머 T310이 실행되는 동안 타이머 T304가 만료되는 것을 검출하면, UE(102)는 FailureInformation 전송을 개시하기 보다는 연결 재설정 절차를 개시한다. 재설정 절차를 개시함으로써, UE(102)는 핸드오버 실패(예: handoverFailure에 해당하는 reestablishmentCause)를 나타내도록 실패 원인(예: reestablishmentCause(재설정 원인))을 설정할 수 있다. 이러한 방식으로, UE(102)는 DAPS 핸드오버 실패를 네트워크에 알리고, 네트워크는 이에 응답하여 네트워크 최적화 또는 다른 적절한 시정 액션(corrective action)를 수행할 수 있다.

일부 구현들(도시되지 않음)에서, UE(102)는 RRC 재설정 절차를 수행하기 위해 셀 선택을 수행한다. UE(102)는 BS(104)보다는 T-BS(106)와 같은 제2 BS와 연관된 셀을 선택할 수 있다. 두 번째 기지국과 연결된 셀을 선택한 후, UE(102)는 RRC 재설정 요청(RRCReestablishmentRequest)를 BS(104)로 전송하는 대신 RRC 재설정 요청(RRCReestablishmentRequest)을 제2 BS로 전송한다.

다음으로, 도 6은 기지국(104)이 소스 기지국으로서 동작하고 기지국(106)이 타겟 기지국(T-BS)으로서 동작하는 시나리오(600)를 예시한다. 초기에, UE(102)는 DAPS 핸드오버 시도 절차(450)와 유사하게 T-BS에 대한 DAPS 핸드오버를 수행하기 위해 시도한다(650). UE(102)가 T-BS(106)와 랜덤 액세스 절차를 성공적으로 수행하기 전에, UE(102)는 타이머 T304가 만료되었음을 검출하고(610) DAPS 실패를 표시하기 위해 BS(104)에 FailureInformation 메시지를 전송하기로 결정한다(610). 나중에,

무선 링크 실패(RLF)(614)가 FailureInformation 메시지의 전송을 중단하고 UE(102)는 BS(104)에 FailureInformation 메시지를 성공적으로 전송할 수 없다(616).

만약 FailureInformation 메시지 전송 실패를 검출한 후, UE(102)는 실패 원인을 otherFailure 또는 무선 링크 실패로 설정해야 했으며, 예를 들어 기지국(104)은 MRO를 부정확하게 수행할 수 있었다. 시나리오(600)에서, UE(102)는 핸드오버 실패에 대응하는 실패 원인을 표시함으로써 연결 재설정 절차를 개시한다. 보다 구체적으로, UE(102)는 BS(104)에 핸드오버 실패를 야기하는 RRCReestablishmentRequest 메시지를 전송한다(619). 따라서, 기지국(104) 또는 T-BS(106)는 나중에 발생하는 RLF가 아닌 핸드오버 실패를 기반으로 MRO를 수행한다(630).

따라서, UE(102)가 DAPS 실패를 나타내는 FailureInformation 메시지 전달 실패를 검출하면, 그 다음, UE(102)는 예를 들어 실패 원인 핸드오버 실패(handoverFailure)와 함께 RRC 재설정 요청(RRCReestablishmentRequest)을 전송함으로써 연결 재설정 절차를 개시한다. 이러한 방식으로, UE(102)는 DAPS 핸드오버 실패를 네트워크에 알리고, 네트워크는 이에 응답하여 네트워크 최적화 또는 다른 적절한 시정 액션를 수행할 수 있다.

UE(102)는 여러 방식으로 RLF를 검출할 수 있다(614). 예를 들어, UE(102)는 BS(104)에 대한 동기화되지 않은 타이머(T310) 또는 링크 설정 타이머(T312)가 만료되었음을 검출함으로써 RLF를 검출한다. 일부 경우에, UE(102)는 BS(104)에 대한 MAC 계층으로부터 랜덤 액세스 문제 표시(random access problem indication)를 수신함으로써, 또는 BS(104)에 대한 최대 재전송 횟수에 도달했다는 표시를 RLC 계층으로부터 수신하기 때문에 RLF를 검출할 수 있다. UE(102)가 IAB(Integrated Access and Backhaul) 노드로 연결되면, UE(102)는 BS(104)로부터 백홀 적응 프로토콜(BAP: Backhaul Adaptation Protocol) 엔티티에 대한 백홀(BH) RLF 표시를 수신할 때 RLF를 검출할 수 있다. 또한, UE(102)는 BS(104)에 대한 MAC 계층으로부터 일관된 업링크 LBT(Listen Before Talk) 실패의 표시를 수신할 때 RLF를 검출할 수 있다.

다음으로, 도 7은 기지국(104)이 소스 기지국으로서 동작하고 기지국(106)이 타겟 기지국(T-BS)으로서 동작하는 시나리오(700)를 예시한다. 초기에, UE(102)는 DAPS 핸드오버 시도 절차(450)와 유사하게 T-BS로의 DAPS 핸드오버를 수행하기 위해 시도한다(750). UE(102)가 T-BS(106)와 랜덤 액세스 절차를 성공적으로 수행하기 전에, UE(102)는 타이머 T304가 만료되었음을 검출하고(710) DAPS 실패를 나타내기 위해 BS(104)에 FailureInformation 메시지를 전송하기로 결정한다(710). 그 다음, UE(102)는 DAPS 핸드오버 실패 정보를 저장(712)한다.

일 구현에서, UE(102)는 VarRLF-Report에 핸드오버 실패 정보를 저장한다. UE(102)는 서빙 셀 측정 결과를 measResultLastServCell 필드에 저장하거나 이웃 셀 측정 결과를 VarRLF-Report의 measResultNeighCells 필드에 저장할 수 있다. UE(102)는 또한 VarRLF-Report에 BS(104) 및 T-BS(106)(예를 들어, C-RNTI 또는 PCI)의 아이덴티티(identity)를 저장할 수 있다. 핸드오버 실패를 나타내기 위해, UE(102)는 연결 실패 유형(connectionFailureType) 필드를 'hof'로 설정한다.

나중에, 무선 링크 실패(RLF)(714)는 FailureInformation 메시지의 전송을 중단하고 UE(102)는 BS(104)에 FailureInformation 메시지를 성공적으로 전송할 수 없다(716). FailureInformation 전송 중 RLF에 대한 응답으로(즉, DAPS 실패 지시 전송), UE(102)는 RLF 정보를 저장하지 않기로 결정하고(718) 네트워크와 RRC 재설정 절차를 수행한다. 일 구현에서, UE(102)는 RLF 이후의 VarRLF-Report에 RLF 정보를 저장하지만, connectionFailureType을 'rlf'로 설정하지 않는다(예: 연결 실패 유형(connectionFailureType)을 'hof'로 설정하거나 connectionFailureType을 'hof'로 유지).

그 다음, UE(102)는 BS(104)에 원인 otherFailure를 갖는 RRCReestablishmentRequest 메시지를 전송한다(720). RRCReestablishmentRequest에 대한 응답으로, BS(104)는 UE(102)에 RRCReestablishment 메시지를 전송한다(722). RRCReestablishment 메시지를 수신한 후, UE(102)는 핸드오버 실패 정보가 이용가능하다는 표시를 포함하는 RRCReestablishmentComplete 메시지를 BS(104)에 전송한다(예: rlf-InfoAvailable)(724). 일 구현에서, BS(104)는 RRCReestablishment 메시지 대신에 RRCSetup 메시지를 UE(102)에 전송한다. RRCSetup 메시지를 수신한 후, UE(102)는 핸드오버 실패 정보가 이용가능하다는 표시를 포함하는 RRCSetupComplete 메시지를 BS(104)에 전송한다(예: rlf-InfoAvailable)(724).

핸드오버 실패 정보가 이용가능하다는 표시에 응답하여, BS(104)는 핸드오버 정보를 요청하기 위해 UE 정보 요청(UEInformationRequest) 메시지를 전송할 수 있다(예: UEInformationRequest에 rlf-ReportReq 포함함으로써)(726). 그 다음, UE(102)는 핸드오버 정보를 보고하기 위해 UE 정보 응답(UEInformationResponse) 메시지를 BS(104)에 전송한다(예: UEInformationResponse에 rlf-Report 포함함으로써)(728). rlf-Report는 연결 실패가 핸드오버 실패로 인한 것임을 나타낸다(예: connectionFailureType 필드가 rlf가 아닌 hof로 설정되어 있기 때문에). 따라서, 기지국(104) 또는 T-BS(106)는 나중에 발생하는 RLF가 아닌 핸드오버 실패에 해당하는 실패 원인을 기반으로 MRO(Mobility Robustness Optimization)를 수행한다(730).

도 8-9는 기지국(104)이 네트워크 최적화를 지원하기 위해 본 개시물의 기술을 사용할 수 있는 시나리오에 대응하는 예시적인 메시징 시퀀스를 도시한다.

도 8은 기지국(104)이 소스 기지국으로서 동작하고 기지국(106)이 타겟 기지국(T-BS)으로서 동작하는 시나리오(800)를 예시한다. 초기에, BS(104)는 DAPS 핸드오버 시도 절차(450)와 유사하게 T-BS로의 DAPS 핸드오버를 수행하기 위해 시도한다(850). BS(104)가 UE(102)로부터 DAPS 실패 표시(예: FailureInformation 메시지) 또는 T-BS(106)로부터 핸드오버 성공 표시(예: 핸드오버 성공(Handover Success) 메시지)를 수신하기 전에, BS(104)는 UE(102)로부터 RRCReestablishmentRequest 메시지를 수신한다(820). BS(104)가 수신하는 RRCReestablishmentRequest 메시지(820)는 UE(102)가 RLF를 검출했음을 통상적으로 나타내는 otherFailure에 대응하는 실패 원인을 포함한다. 그러나, 시나리오(800)에서, BS(104)는 DAPS 핸드오버 성공 또는 실패 표시를 수신하기 전에 원인이 otherFailure인 RRCReestablishmentRequest 메시지를 수신(820)하기 때문에, BS(104)는 UE(102)가 핸드오버 실패를 검출했다고 결정한다. 그 결과, 기지국(104)은 RLF(예를 들어, 기존의 otherFailure)가 아닌 핸드오버 실패(예를 들어, handoverFailure)에 해당하는 실패 원인에 따라 MRO를 수행한다(830).

도 9는 기지국(104)이 소스 기지국으로서 동작하고, 기지국(106)이 타겟 기지국(T-BS)으로서 동작하는 시나리오(900)를 예시한다. 초기에, BS(104)는 DAPS 핸드오버 시도 절차(450)와 유사하게 T-BS로의 DAPS 핸드오버를 수행하기 위해 시도한다(950). UE(102)는 BS(104)와 다른 제2 기지국으로 원인 otherFailure를 포함하는 RRCReestablishmentRequest 메시지를 전송(921)한다. 도 9는 RRCReestablishmentRequest 메시지를 T-BS(106)에 전송하는(921) UE(102)를 도시하지만, 일부 시나리오에서, UE(102)는 RAN의 다른 기지국에 메시지를 전송할 수 있다. 이벤트(921)는 UE(102)가 소스 BS(104)가 아닌 제2 기지국에 RRCReestablishmentRequest 메시지를 전송(921)한다는 점을 제외하고는 이벤트 820과 유사하다. 이에 응답하여, 제2 기지국(예를 들어, 시나리오 900의 T-BS(106))은 BS(104)에 실패 원인 otherFailure를 포함하는 실패 보고(failure report)(예를 들어, RLF 표시 또는 실패 표시)를 전송(929)한다.

이벤트(830)와 유사하게, DAPS 핸드오버 성공 또는 실패 표시를 수신하기 전에 otherFailure 실패 원인을 수신하는 것에 응답하여, BS(104)는 UE(102)가 핸드오버 실패를 검출했다고 결정한다. 그 결과, 기지국(104)은 RLF(예를 들어, 기존의 otherFailure)가 아닌 핸드오버 실패(예를 들어, handoverFailure)에 해당하는 실패 원인에 따라 MRO를 수행한다(930).

더 명확하게 하기 위해, 도 10 내지 도 14는 도 1의 시스템(100)에서 동작하는 장치가 네트워크 최적화를 지원하기 위해 구현할 수 있는 몇 가지 예시적인 방법을 도시한다.

도 10은 DAPS 실패를 네트워크에 표시하기 위해 UE(예를 들어, UE(102))에서 구현되는 예시적인 방법(1000)을 도시하는 흐름도이다. 편의상, 방법(1000)은 무선 통신 시스템(100)에서 동작하는 BS(104), T-BS(106) 및 UE(102)를 참조하여 아래에서 설명된다.

블록(1002)에서, BS(104)와 연결 모드에서 동작하는 UE(102)는 RLF(예를 들어, 이벤트 614 또는 714)를 검출한다. 블록(1004)에서, UE(102)는 UE(102)가 RLF를 검출하기 전에 T-BS(106)로의 DAPS 핸드오버 실패를 검출했는지 여부를 결정한다. UE(102)가 RLF를 검출하기 전에 DAPS 핸드오버 실패를 검출하지 않았다면, 흐름은 블록(1008)으로 진행한다. 블록(1008)에서, UE(102)는 (예를 들어, 실패 원인 otherFailure를 포함하는 기지국에 RRCReestablishmentRequest 메시지를 전송함으로써) UE(102)가 RLF를 검출했음을 나타내는 네트워크와의 RRC 재설정 절차를 개시한다.

UE(102)가 RLF를 검출한 후 DAPS 핸드오버 실패를 검출했다면, 흐름은 블록(1006)으로 진행한다. 블록 1006에서, UE(102)는 UE(102)가 이미 BS(104)에 DAPS 핸드오버 실패를 보고했는지 여부를 결정한다(예: daps-failure 표시가 있는 FailureInformation 메시지 또는 원인 handoverFailure가 있는 RRCReestablishmentRequest 메시지를 이미 성공적으로 전송한 경우). UE(102)가 이미 DAPS 핸드오버 실패를 보고했다면, 흐름은 UE(102)가 RLF를 검출했음을 나타내기 위해 UE(102)가 RRC 재설정 절차를 개시하는 블록(1008)으로 진행한다. 그렇지 않으면, 흐름은 블록(1010)으로 진행하고, 여기서 UE(102)는 예를 들어 실패 원인(handoverFailure)(예: 이벤트 619)을 포함하는 기지국에 RRCReestablishmentRequest 메시지를 전송함으로써 핸드오버 실패에 대응하는 실패 원인에 기초하여 RRC 재설정 절차를 개시한다.

도 11은 DAPS 실패를 네트워크에 표시하기 위해 UE(예를 들어, UE(102))에서 구현되는 예시적인 방법(1100)을 도시하는 흐름도이다. 편의를 위해, 방법(1100)은 무선 통신 시스템(100)에서 동작하는 BS(104), T-BS(106) 및 UE(102)를 참조하여 아래에서 설명된다.

블록(1102)에서, UE(102)는 BS(104)와의 연결 모드에서 동작하고 DAPS 핸드오버 실패를 검출한다(예: DAPS 핸드오버를 위한 타이머 T304가 만료됨) (예: 이벤트 511, 610 또는 710). 블록(1104)에서, UE(102)는 UE(102)가 DAPS 핸드오버 실패를 검출하기 전에 BS(104)와의 무선 연결에서 RLF를 검출했는지 여부를 결정한다. UE(102)가 이전에 RLF를 검출했다면, 흐름은 블록(1106)으로 진행하고, 여기서 UE(102)는 핸드오버 실패에 대응하는 실패 원인에 기초하여 RRC 재설정 절차를 개시한다(예, 실패 원인(handoverFailure)을 포함하는 RRCReestablishmentRequest 메시지를 기지국으로 전송함으로써). 그렇지 않으면, 흐름은 블록(1108)으로 진행한다.

블록(1108)에서, UE(102)는 타이머 T310이 실행 중인지 여부를 결정한다. 타이머 T310이 실행 중이 아니면, 흐름은 UE(102)가 DAPS 실패를 표시하는 FailureInformation 메시지를 BS(104)에 전송하는 1110으로 진행한다. 타이머 T310이 실행 중이면 흐름은 블록 1112로 진행한다.

블록(1112)에서, UE(102)는 FailureInformation 메시지 전송(예를 들어, 이벤트 513)을 중단한다. 다음으로, 블록(1114)에서, UE(102)는 타이머 T310(예를 들어, 이벤트 515)을 중지한다. 블록(1116)에서, UE(102)는 핸드오버 실패(예를 들어, 이벤트 519)에 대응하는 실패 원인에 기초하여 RRC 재설정 절차를 개시한다.

도 12는 네트워크에 DAPS 실패를 표시하기 위해 UE(예를 들어, UE(102))에서 구현되는 예시적인 방법(1200)을 도시하는 흐름도이다. 편의상, 방법(1200)은 무선 통신 시스템(100)에서 동작하는 BS(104), T-BS(106) 및 UE(102)를 참조하여 아래에서 설명된다.

블록(1202) 이전의 어떤 시간에, UE(102)는 DAPS 핸드오버 실패를 검출한다(예를 들어, 타이머 T304가 만료되었음을 검출함으로써)(예: 이벤트 511, 610 또는 710). 블록(1202)에서, UE(102)는 DAPS 핸드오버 실패를 표시하기 위해 BS(104)에 FailureInformation 메시지를 전송하기로 결정한다(예: 이벤트 610 또는 710). 그 다음, UE(102)는 BS(104)로 FailureInformation 메시지를 전송하려고 시도한다(예를 들어, 이벤트 616 또는 716). 블록(1204)에서, UE(102)는 전송이 성공적인지 여부를 체크한다. UE(102)가 BS(104)에 FailureInformation 메시지를 성공적으로 전송하면, 흐름은 UE(102)가 RRC 재설정 절차를 개시하지 않는 블록(1208)으로 진행한다. UE(102)가 BS(104)에 FailureInformation을 성공적으로 전송하지 않으면, 흐름은 블록(1206)으로 진행한다. 일 예에서, UE(102)가 BS(104)에서 RLF를 검출하기 때문에 UE(102)는 실패 정보를 BS(104)에 성공적으로 전송하지 않는다. 블록(1206)에서, UE(102)는 핸드오버 실패에 대응하는 실패 원인에 기초하여 RRC 재설정 절차를 개시한다(예를 들어, 실패 원인(handoverFailure)을 포함하는 RRCReestablishmentRequest 메시지를 기지국으로 전송함으로써) (예를 들어, 이벤트 619).

도 13은 네트워크 최적화를 지원하기 위해 BS(예를 들어, BS(104))에서 구현되는 예시적인 방법(1300)을 도시하는 흐름도이다. 편의상, 방법(1300)은 무선 통신 시스템(100)에서 동작하는 BS(104), T-BS(106) 및 UE(102)를 참조하여 아래에서 설명된다.

블록(1302)에서, BS(104)는 UE(102)로부터 다른 실패 또는 무선 링크 실패를 나타내는 실패 원인을 갖는 RRCReestablishmentRequest 메시지를 수신한다(예를 들어, 이벤트 820). 그 다음, BS(104)는 BS(104)가 이전에 UE(102)에 DAPS 핸드오버 구성을 전송했는지 여부를 검사(1304)한다(예를 들어, DAPS 핸드오버 시도 절차(450)의 이벤트(406)에서와 같이). 그렇지 않다면, 흐름은 BS(104)가 수신된 실패 원인에 기초하여 네트워크 최적화를 수행하는 블록(1308)으로 진행한다. BS(104)가 UE(102)에 DAPS 핸드오버 구성을 전송했다면, 흐름은 블록(1306)으로 진행한다. 블록(1306)에서, BS(104)는 RRCReestablishmentRequest 메시지를 수신하기 전에 DAPS 핸드오버 성공 또는 실패의 표시를 수신했는지 여부를 체크한다. 그렇다면, 흐름은 블록(1308)으로 진행한다. 그렇지 않다면, 흐름은 수신된 실패 원인이 핸드오버 실패인 것처럼 BS(104)가 네트워크 최적화를 수행하는 블록(1310)으로 진행한다(예를 들어, 이벤트 830).

도 14는 네트워크 최적화를 지원하기 위해 BS(예를 들어, BS(104))에서 구현되는 예시적인 방법(1400)을 도시하는 흐름도이다. 편의상, 방법(1400)은 무선 통신 시스템(100)에서 동작하는 BS(104), T-BS(106) 및 UE(102)를 참조하여 아래에서 설명된다.

블록(1402)에서, BS(104)는 제2 BS(예를 들어, T-BS(106))로부터, 제2 기지국이 제2 BS와의 RRC 재설정 절차를 개시했음을 표시하는 실패 보고(예: RLF INDICATION 메시지 또는 FAILURE INDICATION 메시지)를 수신한다(예: 이벤트 929). 실패 보고(리포트)는 "기타 실패" 또는 "무선 링크 실패"의 실패 원인을 추가로 나타낸다. 블록(1404)에서, BS(104)는 BS(104)가 UE(102)에 DAPS 핸드오버 구성을 이전에 전송했는지 여부를 체크한다(예를 들어, DAPS 핸드오버 시도 절차(450)의 이벤트(406)에서와 같이). 그렇지 않다면, 흐름은 BS(104)가 수신된 실패 원인에 기초하여 네트워크 최적화를 수행하는 블록(1408)으로 진행한다. BS(104)가 UE(102)에 DAPS 핸드오버 구성을 전송했다면, 흐름은 블록(1406)으로 진행한다. 블록(1406)에서, BS(104)는 실패 보고를 수신하기 전에 DAPS 핸드오버 성공 또는 실패의 표시를 수신했는지 여부를 체크한다. 그렇다면, 흐름은 블록(1408)으로 진행한다. 그렇지 않다면, 흐름은 블록(1410)으로 진행하고, 여기서 BS(104)는 수신된 실패 원인이 핸드오버 실패(예를 들어, 이벤트(930))인 것처럼 네트워크 최적화를 수행한다.

도 3-14는 DAPS 핸드오버 시나리오에서 향상된 오류 보고 및 네트워크 최적화를 지원하기 위한 기술을 나타낸다. 도 15-20은 인터-RAT 핸드오버 시나리오에서 유사한 기술을 묘사한다(즉, 첫 번째 RAT에서 두 번째 RAT로의 핸드오버).

문맥상, 도 15(종래 기술)는 기지국(104)이 소스 기지국으로서 동작하고 기지국(106)이 타겟 기지국(T-BS)으로서 동작하는 인트라-RAT 핸드오버 시나리오(1500) 동안의 메시징 시퀀스를 도시한다. BS(104) 및 T-BS(106)는 동일한 RAT(예를 들어, NR 또는 EUTRA)를 사용하는 셀이다. 초기에, UE(102)는 BS(104)와 연결 모드에서 동작한다(1502). 나중에, BS(104)는 UE(102)를 T-BS(106)로 핸드오버하기로 결정한다(1504). 이 결정에 응답하여, BS(104)는 핸드오버 요청 메시지를 UE(102)에 전송한다(예, RRCReconfiguration 메시지 또는 RRCConnectionReconfiguration 메시지)(1506). 핸드오버 요청 메시지는 UE(102)가 T-BS(106)와 연관된 셀에 연결하기 위해 사용할 수 있는 적어도 하나의 구성을 포함한다. 본 개시물은 일반적으로 "핸드오버"를 지칭하지만 때때로 동기화를 통한 재구성으로도 지칭된다.

UE(102)는 핸드오버 요청 메시지를 수신하고(1506), 핸드오버 요청 메시지로부터 적어도 하나의 구성을 적용할 수 없다고 결정(1508)한다. 일례에서, UE(102)는 UE(102)가 핸드오버 요청 메시지에 포함된 구성의 어떤 부분에도 따를 수 없기 때문에 구성을 적용할 수 없다고 결정한다. 다른 예에서, UE(102)는 핸드오버 요청 메시지에 포함된 정보의 프로토콜 오류로 인해 구성을 적용할 수 없다. 결정(1508)에 대한 응답으로, UE(102)는 BS(104)에 재구성 실패(예: reconfigurationFailure)를 나타내는 실패 원인과 함께 RRCReestablishmentRequest (또는 RRCConnectionReestablishmentRequest) 메시지를 전송(1510)한다. BS(104)는 재구성 실패에 응답하여 대응하는 시정 액션(수정 액션)(corrective actions)을 수행하기로 결정(1512)한다. 일 예에서, BS(104)는 최신 UE 성능 정보를 요청하기 위해 UE 성능 요청(UECapabilityEnquiry) 메시지를 UE(102)에 전송할 수 있다(1514). UECapabilityEnquiry에 대한 응답으로, UE(102)는 자신의 성능(예를 들어, UE-NR-Capability, UE-MRDC-Capability, 또는 UE-EUTRA-Capability)을 업데이트하기 위해 UECapabilityInformation 메시지를 BS(104)에 전송한다(1516).

다른 예에서, BS(104)는 DL NAS TRANSPORT 메시지에 UE 파라미터 업데이트 투명 컨테이너(transparent container)를 포함하고 메시지를 UE(102)에 전송하여 최신 UE 성능을 요청할 수 있다. DL NAS TRANSPORT 메시지에 대한 응답으로, UE(102)는 등록 절차, 라우팅 영역 업데이트 절차, 또는 추적 영역 업데이트 절차를 수행할 수 있거나, UE 파라미터 업데이트 투명 컨테이너와 함께 UL NAS TRANSPORT 메시지를 BS(104)에 전송하여 자신의 성능(capability)을 업데이트할 수 있다.

도 16-17은 UE(102)가 네트워크 최적화를 지원하기 위해 본 개시물의 기술을 사용할 수 있는 인터-RAT 핸드오버 실패 시나리오에 대응하는 예시적인 메시징 시퀀스를 도시한다.

도 16은 기지국(104)이 소스 기지국으로서 동작하고, 기지국(106)이 타겟 기지국(T-BS)으로서 동작하는 인터-RAT 핸드오버 시나리오(1600)를 예시한다. BS(104) 및 T-BS(106)는 상이한 RAT(예를 들어, NR 또는 EUTRA)의 셀과 연관된다. 일부 시나리오에서, 인터-RAT 핸드오버는 제1 셀로부터 동일한 기지국과 연관된 제2 셀로의 핸드오버를 포함하지만 다른 RAT를 포함할 수 있다. 초기에, UE(102)는 BS(104)와의 연결 모드에서 동작(1602)한다. 나중에, BS(104)는 UE를 상이한 RAT와 연관된 T-BS(106)로 핸드오버하기로 결정한다(1604). 이 결정에 응답하여, BS(104)는 핸드오버 요청 메시지를 UE(102)에 전송한다(1606)(예를 들어, UE(102)를 NR에서 다른 RAT로 핸드오버하기 위한 MobilityFromNRCommand 메시지, 또는 UE(102)를 EUTRA에서 다른 RAT로 핸드오버하기 위한 MobilityFromEUTRACommand 메시지). 핸드오버 요청 메시지는 UE(102)가 상이한 RAT와 연관된 제2 셀에 연결하기 위해 사용할 수 있는 적어도 하나의 구성을 포함한다.

UE(102)는 이 핸드오버 요청 메시지를 수신하고(1606), 핸드오버 요청 메시지로부터 적어도 하나의 구성(configuration)을 적용할 수 없다고 결정(1608)한다. 일례에서, UE(102)는 UE(102)가 핸드오버 요청 메시지에 포함된 구성의 어떤 부분에도 따를 수 없기 때문에 구성을 적용할 수 없다고 결정한다. 다른 예에서, UE(102)는 핸드오버 요청 메시지에 포함된 정보의 프로토콜 오류로 인해 구성을 적용할 수 없다.

결정(1608)에 대한 응답으로, UE(102)는 재구성 실패(예: reconfigurationFailure)를 나타내는 실패 원인과 함께 RRC 재설정 요청(RRCReestablishmentRequest)(또는 RRCConnectionReestablishmentRequest) 메시지를 BS(104)에 전송한다(1610). 예를 들어, 핸드오버 실패를 보고하는 대신에, UE(102)는 네트워크에 재구성 실패를 보고한다. 보다 구체적으로, UE(102)가 MobilityFromEUTRACommand 또는 MobilityFromNRCommand와 같은 핸드오버 요청의 구성을 준수하지 않아 재설정 절차를 시작하는 경우, UE(102)는 실패 원인(예: 재설정 원인)을 재구성 실패(예: reconfigurationFailure)를 나타내는 값으로 설정한다. 이러한 방식으로, UE(102)는 재구성 실패를 네트워크에 알린다. 네트워크는 이에 대응하여 네트워크 최적화 또는 기타 적절한 시정 액션을 수행할 수 있다.

BS(104)는 재구성 실패에 응답하여 대응하는 시정 액션을 수행하기로 결정(1612)한다. 하나의 예시적인 시정 액션(도시되지 않음)에서, BS(104)는 최신 UE 성능을 요청하기 위해 UE 성능 문의(UECapabilityEnquiry) 메시지를 UE(102)에 전송할 수 있다. UECapabilityEnquiry에 응답하여, UE(102)는 자신의 성능을 업데이트하기 위해 (예를 들어, UE-NR-Capability, UE-MRDC-Capability, UE-EUTRA-Capability, 또는 INTER RAT HANDOVER INFO) UE 성능 정보(UECapabilityInformation) 메시지를 BS(104)에 전송한다.

또 다른 예시적인 시정 액션(미도시)에서, BS(104)는 DL NAS TRANSPORT 메시지에 UE 파라미터 업데이트 투명 컨테이너를 포함하고 메시지를 UE(102)에 전송하여 최신 UE 성능을 요청할 수 있다. DL NAS TRANSPORT 메시지에 대한 응답으로, UE(102)는 등록 절차, 라우팅 영역 업데이트 절차, 또는 추적 영역 업데이트 절차를 다시 수행할 수 있거나, 자신의 성능을 업데이트하기 위해 UE 파라미터 업데이트 투명 컨테이너를 포함하는 UL NAS TRANSPORT 메시지를 BS(104)에 전송할 수 있다.

도 17은 기지국(104)이 소스 기지국으로서 동작하고 기지국(106)이 타겟 기지국(T-BS)으로서 동작하는 시나리오(1700)를 예시한다. BS(104) 및 T-BS(106)는 상이한 RAT(예를 들어, NR 또는 EUTRA)의 셀과 연관된다. 일부 시나리오에서, 인터-RAT 핸드오버는 제1 셀로부터 동일한 기지국과 연관된 제2 셀로의 핸드오버를 포함하지만 다른 RAT를 포함할 수 있다. 초기에, UE(102)는 BS(104)와의 연결 모드에서 동작(1702)한다. 나중에, BS(104)는 UE를 상이한 RAT와 연관된 T-BS(106)로 핸드오버하기로 결정(1704)한다. 이 결정에 응답하여, BS(104)는 핸드오버 요청 메시지(예를 들어, MobilityFromNRCommand 메시지 또는 MobilityFromEUTRACommand 메시지)를 UE(102)에 전송(1706)한다.

UE(102)는 핸드오버 요청 메시지를 수신하고(1706), 결정(1608)과 유사하게 핸드오버 요청 메시지로부터 적어도 하나의 구성을 적용할 수 없다고 결정(1708)한다. 결정(1708)에 대한 응답으로, UE(102)는 핸드오버 실패 정보를 저장하지 않기로 결정하고(1709), 핸드오버 실패(예를 들어, handoverFailure)에 대응하는 실패 원인을 포함하는 RRCReestablishmentRequest(또는 RRCConnectionReestablishmentRequest) 메시지를 BS(104)로 전송한다(1711). UE(102)로부터 RRCReestablishmentRequest 메시지를 수신한 후, BS(104)는 RRCReestablishment 메시지를 UE(102)에 전송(1713)한다. RRCReestablishment 메시지에 응답하여, UE(102)는 BS(104)에 RRC 재설정 완료(RRCReestablishmentComplete) 메시지를 전송(1715)한다. RRCReestablishmentComplete 메시지는 UE(102)가 이벤트(1709)에서 핸드오버 실패 정보를 저장하지 않았기 때문에 핸드오버 실패 정보가 이용가능하다는 표시를 포함하지 않는다. 일 예에서, UE(102)는 RRCReestablishmentComplete 메시지에 rlf-InfoAvailable을 포함하지 않는다. 다른 예에서, UE(102)는 RRCReestablishmentComplete 메시지에 rlf-InfoAvailable을 포함하지만, connectionFailureType을 'hof'로 설정하지 않는다(예를 들어, UE(102)는 connectionFailureType을 'rlf'로 설정할 수 있음).

일부 구현들에서, BS(104)는 이벤트(1713)에서 RRCReestablishment 메시지 대신에 RRC 설정(RRCSetup) 메시지를 전송하고, 이벤트(1715)에서 RRC 설정 완료(RRCSetupComplete) 메시지를 BS(104)에 전송한다. RRCSetupComplete 메시지는 핸드오버 실패 정보를 사용할 수 있다는 표시를 포함하지 않는다.

BS(104)가 수신하는 메시지(1715)는 이용가능한 핸드오버 실패 정보가 없음을 나타내기 때문에, BS(104)는 UE(102)가 재구성 실패를 검출했다고 결정하고(1717), 결정에 기초하여 시정 액션을 수행하기로 결정한다(1717). 예를 들어, BS(104)는 최신 UE 성능을 요청하기 위해 UECapabilityEnquiry 메시지를 UE(102)에 전송할 수 있다(1719). UECapabilityEnquiry 메시지에 응답하여, UE(102)는 자신의 성능(예를 들어, UE-NR-Capability, UE-MRDC-Capability, UE-EUTRA-Capability, 또는 INTER RAT HANDOVER INFO)을 업데이트하기 위해 UECapabilityInformation 메시지를 BS(104)에 전송한다(1721).

다른 예에서, BS(104)는 DL NAS TRANSPORT 메시지에 UE 파라미터 업데이트 투명 컨테이너를 포함하고 메시지를 UE(102)에 전송하여 최신 UE 성능을 요청할 수 있다. DL NAS TRANSPORT 메시지에 대한 응답으로, UE(102)는 등록 절차, 라우팅 영역 업데이트 절차, 또는 추적 영역 업데이트 절차를 수행할 수 있거나, 자신의 성능을 업데이트하기 위해 UE 파라미터 업데이트 투명 컨테이너를 포함하는 UL NAS TRANSPORT 메시지를 BS(104)에 전송할 수 있다.

더 명확하게 하기 위해, 도 18 내지 도 20은 도 1의 시스템(100)에서 동작하는 장치가 네트워크 최적화를 지원하기 위해 구현할 수 있는 몇 가지 예시적인 방법을 도시한다.

도 18은 네트워크에 재구성 실패를 나타내기 위해 UE(예를 들어, UE(102))에서 구현될 수 있는 예시적인 방법(1800)을 도시하는 흐름도이다. 편의상, 방법(1800)은 무선 통신 시스템(100)에서 동작하는 BS(104), T-BS(106) 및 UE(102)를 참조하여 아래에서 설명된다.

블록(1802) 이전의 어떤 시간에, UE(102)는 UE(102)가 T-BS(106)(예를 들어, 이벤트 1606 또는 1706)와 연관된 셀에 연결하기 위해 사용할 구성을 포함하는 핸드오버 요청을 수신한다. 블록(1802)에서, UE(102)는 BS(104)로부터 T-BS(106)로의 인터-RAT 핸드오버를 완료할 수 없다고 결정하고 RRC 재설정 절차(예를 들어, 이벤트 1608 또는 1708)를 개시하기로 결정한다. 블록(1804)에서, UE(102)는 타이머 T304가 만료되었는지를 체크한다. UE(102)는 T-BS(106)에 연결을 시도할 때 이전에 타이머 T304를 시작했다. 타이머 T304가 만료된 경우, 흐름은 블록 1808로 진행하고, 여기서 UE(102)는 실패 원인(handoverFailure)을 포함하는 RRCReestablishmentRequest를 전송함으로써 RRC 재설정을 개시한다. 타이머 T304가 만료되지 않은 경우 흐름은 블록 1806으로 진행한다. 블록 1806에서, UE(102)는 인터-RAT 핸드오버를 완료하는 데 실패가 T-BS(106)와 연관된 구성을 적용하지 않았기 때문이라고 결정하고, 실패 원인(reconfigurationFailure)을 포함하는 RRCReestablishmentRequest를 전송함으로써 RRC 재설정 절차를 시작한다(예: 이벤트 1610).

도 19는 네트워크에 재구성 실패를 표시하기 위해 UE(예를 들어, UE(102))에서 구현되는 예시적인 방법(1900)을 도시하는 흐름도이다. 편의를 위해, 방법(1900)은 무선 통신 시스템(100)에서 동작하는 BS(104), T-BS(106) 및 UE(102)를 참조하여 아래에서 설명된다.

블록(1902) 이전의 어떤 시간에, UE(102)는 UE(102)가 T-BS(106)(예를 들어, 이벤트 1606 또는 1706)와 연관된 셀에 연결하기 위해 사용할 구성을 포함하는 핸드오버 요청을 수신한다. 블록(1902)에서, UE(102)는 BS(104)로부터 T-BS(106)로의 인터-RAT 핸드오버를 완료할 수 없다고 결정하고 RRC 재설정 절차(예를 들어, 이벤트 1608 또는 1708)를 개시하기로 결정한다. 블록(1904)에서, UE(102)는 UE(102)가 핸드오버 요청에서 구성을 적용할 수 없는지 여부를 결정한다. 그렇다면, 흐름은 블록 1906으로 진행하고, 여기서 UE(102)는 실패 원인(reconfigurationFailure)(예를 들어, 이벤트 1610)를 포함하는 RRCReestablishmentRequest를 전송함으로써 RRC 재설정 절차를 개시한다. 그렇지 않으면, 흐름은 UE(102)가 실패 원인(handoverFailure)을 포함하는 RRCReestablishmentRequest를 전송함으로써 RRC 재설정 절차를 개시하는 블록(1908)으로 진행한다.

도 20은 네트워크 최적화를 지원하기 위해 BS(예를 들어, BS(104))에서 구현되는 예시적인 방법(2000)을 도시하는 흐름도이다. 편의상, 방법(2000)은 무선 통신 시스템(100)에서 동작하는 BS(104), T-BS(106) 및 UE(102)를 참조하여 아래에서 설명된다.

블록(2002) 이전의 어떤 지점에서, BS(104)는 UE(102)로부터 RRCReestablishmentRequest를 수신하고, 응답으로 RRCReestablishment 메시지 또는 RRCSetup 메시지를 UE(102)에 전송한다(예를 들어, 이벤트 1711 및 1713). 블록(2002)에서, BS(104)는 UE(102)로부터 RRCReestablishmentComplete 또는 RRCSetupComplete를 수신한다(예를 들어, 이벤트 1715). 다음으로, 블록(2004)에서, BS(104)는 RRCReestablishmentComplete 메시지 또는 RRCSetupComplete 메시지가 핸드오버 실패 정보가 이용가능하다는 표시를 포함하는지 여부를 체크(2004)한다. 그렇다면, 흐름은 BS(104)가 핸드오버 실패(예를 들어, handoverFailure)에 대응하는 실패 원인에 기초하여 네트워크 최적화를 수행하는 블록 2006으로 진행한다. 그렇지 않으면 흐름은 블록 2008로 진행한다.

블록(2008)에서, BS(104)는 이전 RRCReestablishmentRequest에서 수신된 실패 원인이 핸드오버 실패에 대응하는지 여부를 체크한다. 실패 원인이 핸드오버 실패가 아니면, 흐름은 BS(104)가 수신된 원인에 따라 네트워크 최적화(예: 원인이 otherFailure 또는 RLF인 경우 RLF에 대한 최적화)를 수행하는 블록(2010)으로 진행한다. 원인이 핸드오버 실패인 경우 흐름은 블록 2012로 진행한다. 블록(2012)에서, BS(104)는 UE(102)가 재구성 실패(예를 들어, 이벤트 1717)를 검출했다고 결정한다. 결정에 응답하여, BS(104)는 재구성 실패(예를 들어, 이벤트 1719)를 프로세싱하기 위해 시정 액션을 수행할 수 있다.

도 21 내지 도 24는 도 1의 시스템(100)에서 동작하는 장치가 DAPS 핸드오버 실패 시나리오 또는 인터-RAT 핸드오버 실패 시나리오에서 네트워크 최적화를 지원하기 위해 구현할 수 있는 예시적인 방법의 흐름도이다.

도 21은 DAPS 핸드오버를 지원하기 위한 예시적인 방법(2100)의 흐름도이며, 이는 컴퓨터 판독가능 매체에 저장되고 프로세싱 하드웨어(예를 들어, 프로세싱 하드웨어(150))에 의해 실행가능한 명령어 세트로서 본 개시의 UE(예를 들어, UE(102))에서 구현될 수 있다. UE는 초기에 RAN의 제1 기지국(예를 들어, BS(104))에 연결된다.

블록(2102)에서, UE는 DAPS 핸드오버(예를 들어, 이벤트 550, 650, 750, 850, 950) 동안 제2 기지국(예를 들어, T-BS로서 동작하는 BS(106))에 연결을 시도한다. 블록(2104)에서, UE는 제1 기지국과의 무선 연결과 연관된 잠재적인 실패(예를 들어, 이벤트 509, 614, 또는 714)를 검출한다. 예를 들어, UE는 동기화 문제를 검출하고 타이머 T310을 시작하거나 UE가 RLF를 검출할 수 있다. 블록(2106)에서, UE는 제2 기지국에 대한 연결 실패(예를 들어, DAPS 핸드오버 실패 또는 동기화 실패로 재구성)(예를 들어, 이벤트 511, 610, 또는 710)를 검출한다. 구현 및/또는 시나리오에 따라 블록(2104 및 2106)은 다른 순서로 발생할 수 있다. 블록(2108)에서, UE는 (예., handoverFailure에 해당하는 실패 원인을 포함하는 RRCReestablishmentRequest를 전송하여 RRC 재설정 절차를 시작함으로써) 연결 실패의 표시를 RAN에 제공하는 것을 포함하는 무선 연결을 재설정하는 절차를 시작한다(예, 이벤트 519 또는 619).

도 22는 네트워크 최적화를 위한 예시적인 방법(2200)의 흐름도이며, 이는 컴퓨터 판독가능 매체에 저장되고 프로세싱 하드웨어(예를 들어, 프로세싱 하드웨어(130))에 의해 실행가능한 명령어 세트로서 본 개시의 기지국(예: BS 104)에서 구현될 수 있다.

블록 2202에서, 기지국은 UE가 DAPS 핸드오버 절차 동안 제2 기지국(예를 들어, T-BS로 동작하는 BS(106))에 연결할 구성을 전송한다(예를 들어, DAPS 핸드오버 시도 절차 450의 이벤트 406, 또는 절차 550, 650, 750, 850, 또는 950). 블록(2204)에서, 기지국은 UE가 무선 링크의 실패(예를 들어, 이벤트 820 또는 929)를 검출했다는 표시를 수신한다. 블록(2206)에서, 기지국은 UE가 제2 기지국으로의 연결 실패를 검출했다고 결정한다. 다음으로, 블록(2208)에서, 기지국은 결정(예를 들어, 이벤트 830 또는 930)에 기초하여 네트워크 최적화 절차(예를 들어, MRO)를 수행한다.

도 23은 인터-RAT 핸드오버를 지원하기 위한 예시적인 방법(2300)의 흐름도이고, 이는 컴퓨터 판독가능 매체에 저장되고 프로세싱 하드웨어(예를 들어, 프로세싱 하드웨어(150))에 의해 실행가능한 명령어 세트로서 본 개시의 UE(예를 들어, UE(102))에서 구현될 수 있다. UE는 초기에 제1 RAT와 연관된 제1 셀에 연결된다(예를 들어, BS(104)와 연관된 셀(124)).

블록(2302)에서, UE는 제2 RAT와 연관된 제2 셀에 연결을 시도한다(예를 들어, BS(106)와 연관된 셀(126)) (예를 들어, 이벤트(1606 또는 1706)에서 요청을 수신하는 것에 응답하여). 블록(2304)에서, UE는 제2 셀과 연관된 구성(예를 들어, 이벤트 1608 또는 1708)의 적용 실패를 검출한다. 블록(2306)에서, UE는 제1 셀을 통해 구성의 적용 실패의 표시를 제공한다(예를 들어, 재구성 실패에 해당하는 실패 원인과 함께 RRCReestablishmentRequest를 전송하여 RRC 재설정 절차를 시작함으로써) (예를 들어, 이벤트 1610).

도 24는 인터-RAT 핸드오버를 지원하기 위한 예시적인 방법(2400)의 흐름도이고, 이는 컴퓨터 판독가능 매체에 저장되고 프로세싱 하드웨어(예를 들어, 프로세싱 하드웨어(130))에 의해 실행가능한 명령어 세트로서 본 개시의 기지국(예를 들어, BS(104))에서 구현될 수 있다. 기지국은 제1 RAT의 제1 셀(예를 들어, 셀(124))과 연관된다.

블록 2402에서, 기지국은 제2 RAT의 제2 셀에 연결하기 위한 요청을 UE에 전송하고, 요청은 UE가 제2 셀에 연결하기 위해 사용할 구성을 포함한다(예: 이벤트 1606 또는 1706). 블록(2404)에서, 기지국은 무선 연결을 재설정하라는 요청을 UE로부터 수신하고, 요청은 핸드오버 실패를 나타내는 실패 원인을 포함한다(예: 이벤트 1711). 다음으로, 블록(2406)에서, 기지국은 UE와의 무선 연결을 구성하기 위한 메시지를 전송한다(예를 들어, 이벤트 1713). 블록(2408)에서, 기지국은 핸드오버 실패 정보가 이용가능하지 않다는 것을 나타내는 응답(예를 들어, 이벤트(1715))을 메시지에 대한 응답을 수신한다. 이에 응답하여, 블록 2410에서, 기지국은 UE가 구성(예를 들어, 이벤트 1717)을 적용할 수 없었다고 결정한다. 블록(2412)에서, 기지국은 결정(예를 들어, 이벤트(1719))에 응답하여 시정 액션을 수행한다.

구현 및/또는 시나리오에 따라, UE(예를 들어, UE(102))는 위에 개시된 기술들의 조합(예: 방법 2100 및 2300의 조합)을 수행할 수 있다. 예를 들어, 방법(2300)을 수행하는 동안, UE(102)는 제1 셀과 연관된 무선 연결의 잠재적 실패를 검출할 수 있다. 유사하게, 기지국(예를 들어, BS(104))은 위에 개시된 기술들의 조합(예를 들어, 방법들(2200 및 2400)의 조합)을 수행할 수 있다.

다음의 예시 목록은 본 개시내용에 의해 명시적으로 고려되는 다양한 실시형태를 반영한다.

예 1. RAN(Radio Access Network)의 제1 기지국에 연결된 UE(User Equipment)에서 DAPS(Dual Active Protocol Stack) 핸드오버를 지원하는 방법에 있어서, 방법은, 프로세싱 하드웨어에 의해 DAPS 핸드오버 동안 RAN의 제2 기지국에 연결을 시도하는 단계; 프로세싱 하드웨어에 의해, 제1 기지국에 대한 무선 연결과 연관된 잠재적인 실패를 검출하는 단계; 프로세싱 하드웨어에 의해, 제2 기지국에 대한 연결 실패를 검출하는 단계; 그리고 프로세싱 하드웨어에 의해 무선 연결을 재설정하는 절차를 시작(개시)하는 단계를 포함하며, 시작(개시)하는 단계는 연결 실패의 표시를 RAN에 제공하는 단계를 포함한다.

예 2. 예 1에 있어서, 잠재적 실패를 검출하는 단계는 제2 기지국에 대한 연결 실패를 검출하기 전에 잠재적 실패를 검출하는 단계를 포함한다.

예 3. 예 2에 있어서, 잠재적 실패를 검출하는 단계는 무선 연결과 연관된 동기화 오류를 검출하는 단계를 포함한다.

예 4. 예 2-3 중 어느 하나의 방법에 있어서, 방법은, 프로세싱 하드웨어에 의해, 잠재적인 실패를 검출하는 것에 응답하여 타이머를 시작하는 단계를 더 포함하며, 제2 기지국에 대한 연결 실패를 검출하는 단계는 타이머가 실행되는 동안 제2 기지국에 대한 연결 실패를 검출하는 단계를 포함한다.

예 5. 예 4에 있어서, 방법은, 프로세싱 하드웨어에 의해, 제2 기지국에 대한 연결 실패를 검출하는 것에 응답하여 타이머를 중지하는 단계를 더 포함한다.

예 6. 예 2에 있어서, 상기 잠재적 실패를 검출하는 단계는, 제2 기지국에 대한 연결 실패를 검출하기 전에 제1 기지국과의 무선 링크 실패를 검출하는 단계를 포함한다.

예 7. 예 1에 있어서, 잠재적 실패를 검출하는 단계는, 제2 기지국에 대한 연결 실패를 검출한 후 그리고 제2 기지국에 대한 연결 실패를 제1 기지국에 보고하기 전에 제1 기지국과의 무선 링크 실패를 검출하는 단계를 포함한다.

예 8. 예 7에 있어서, 무선 링크 실패를 검출하는 단계는 연결 실패를 보고하기 위한 전용 메시지의 성공적 전송 실패를 검출하는 단계를 포함한다.

예 9. 예 1 내지 예 8 중 어느 하나에 있어서, 표시를 제공하는 단계는 무선 연결을 재설정하라는 요청을 전송하는 단계를 포함하며, 이 요청은 실패 원인으로서 핸드오버 실패를 표시한다.

예 10. 예 1 내지 예 9 중 어느 하나에 있어서, 연결 실패를 검출하는 단계는 DAPS 핸드오버의 실패를 검출하는 단계를 포함한다.

예 11. 무선 링크를 통해 사용자 장비(UE)와 통신하는 제1 기지국에서 네트워크 최적화를 위한 방법으로서, 방법은, 상기 UE가 DAPS(Dual Active Protocol Stack) 핸드오버 절차 동안 제2 기지국에 연결하기 위한 구성을 프로세싱 하드웨어에 의해 전송하는 단계; 프로세싱 하드웨어에 의해, UE가 무선 링크의 실패를 검출했다는 표시를 수신하는 단계; 프로세싱 하드웨어에 의해, UE가 제2 기지국에 대한 연결 실패를 검출했음을 결정하는 단계; 그리고 프로세싱 하드웨어에 의해, 결정에 기초하여 네트워크 최적화 절차를 수행하는 단계를 포함한다.

예 12. 예 11에 있어서, 상기 표시를 수신하는 단계는, 상기 UE와의 무선 연결을 재설정하라는 요청을 수신하는 단계를 포함하며, 상기 요청은 실패 원인으로서 무선 링크 실패를 포함한다.

예 13. 예 11에 있어서, 상기 표시를 수신하는 단계는, 상기 제2 기지국이 상기 UE와의 무선 연결을 재설정하라는 요청을 수신했다는 표시를 상기 제2 기지국으로부터 수신하는 단계를 포함하며, 요청은 무선 링크 실패를 실패 원인으로 포함한다.

예 14. 예 11-13 중 어느 하나에 있어서, UE가 제2 기지국에 대한 연결(접속) 실패를 검출했다고 결정하는 단계는, UE가 DAPS 핸드오버를 완료 또는 실패했다는 표시를 수신하기 전에, UE가 무선 링크의 실패를 검출했다는 표시를 수신하는 단계를 포함한다.

예 15. 예 11 내지 예 14 중 어느 하나에 있어서, 네트워크 최적화를 수행하는 단계는 MRO(Mobility Robustness Optimization)를 수행하는 단계를 포함한다.

예 16. 예 11-15 중 어느 하나에 있어서, 구성을 전송하는 단계는 무선 자원을 제어하기 위한 프로토콜을 준수하는 메시지로 구성을 전송하는 단계를 포함한다.

예 17. 제1 무선 액세스 기술(RAT)과 연관된 제1 셀에 연결된 사용자 장비(UE)에서, 제2 RAT와 연관된 제2 셀로의 핸드오버를 지원하기 위한 방법으로서, 방법은, 프로세싱 하드웨어에 의해 제2 셀에 연결을 시도하는 단계; 프로세싱 하드웨어에 의해, 제2 셀과 연관된 구성의 적용 실패를 검출하는 단계; 그리고 프로세싱 하드웨어에 의해, 제1 셀을 통해 구성의 적용 실패의 표시를 제공하는 단계를 포함한다.

예 18. 예 17에 있어서, 상기 표시를 제공하는 단계는 무선 연결을 재설정하라는 요청을 전송하는 단계를 포함하고, 상기 요청은 재구성 실패를 나타내는 실패 원인을 포함한다.

예 19. 예 17-18 중 어느 하나에 있어서, 실패를 검출하는 단계는 UE가 구성을 적용할 수 없다고 결정하는 단계를 포함한다.

예 20. 예 17 내지 예 18 중 어느 한 예에 있어서, 상기 실패를 검출하는 단계는, 제2 셀에 대한 연결 시도에 응답하여 타이머를 시작하는 단계; 및 타이머가 만료되기 전에 UE가 제2 셀에 연결할 수 없다고 결정하는 단계를 포함한다.

예 21. 예 17 내지 예 20 중 어느 하나에 있어서, 프로세싱 하드웨어에 의해, 핸드오버 요청 메시지에서 제2 셀과 연관된 구성을 수신하는 단계를 더 포함한다.

예 22. 예 21에 있어서, 구성을 수신하는 단계는 MobilityFromNRCommand 또는 MobilityFromEUTRACommand에서 구성을 수신하는 단계를 포함한다.

예 23. 예 17 내지 예 22 중 어느 하나에 있어서, 상기 제1 셀 및 상기 제2 셀은 상이한 기지국들과 연관된다.

예 24. 예 17 내지 예 23 중 어느 하나의 방법에 있어서, 방법은, 상기 프로세싱 하드웨어에 의해, 상기 제1 셀과 연관된 무선 연결의 잠재적인 실패를 검출하는 단계를 더 포함한다.

예 25. 사용자 장비(UE)는 프로세싱 하드웨어를 포함하고 그리고 예 1-10 또는 17-24 중 어느 하나에 따른 방법을 구현하도록 구성된다.

예 26. 제1 RAT(Radio Access Technology)의 제1 셀을 지원하는 기지국에서 인터-RAT 핸드오버를 지원하는 방법으로서, 방법은, 프로세싱 하드웨어에 의해, 제2 RAT의 제2 셀에 연결하기 위한 UE에 대한 요청을 사용자 장비(UE)로 전송하는 단계 -요청은 UE가 제2 셀에 연결하기 위해 사용할 구성을 포함함-; 프로세싱 하드웨어에 의해, 무선 연결을 재설정하라는 UE로부터의 요청을 수신하는 단계 -요청은 핸드오버 실패를 나타내는 실패 원인을 포함함-; 프로세싱 하드웨어에 의해, UE와의 무선 연결을 구성하기 위한 메시지를 전송하는 단계; 프로세싱 하드웨어에 의해 메시지에 대한 응답을 수신하는 단계 -응답은 핸드오버 실패 정보가 이용 가능하지 않다는 것을 나타냄-; 프로세싱 하드웨어에 의해 그리고 응답에 기초하여, UE가 구성을 적용할 수 없다고 결정하는 단계; 그리고 프로세싱 하드웨어에 의해, 결정에 응답하여 시정 액션을 수행하는 단계를 포함한다.

예 27. 예 26에 있어서, 시정 액션을 수행하는 단계는 UE와 연관된 성능 정보에 대한 요청을 UE에 전송하는 단계를 포함한다.

예 28. 예 26-27 중 어느 하나에 있어서, 무선 연결을 구성하기 위해 메시지를 전송하는 단계는 UE와의 무선 연결을 재설정하라는 메시지를 전송하는 단계를 포함한다.

예 29. 예 26-27 중 어느 하나에 있어서, 무선 연결을 구성하기 위한 메시지를 전송하는 단계는 UE와의 새로운 무선 연결을 설정하라는 메시지를 전송하는 단계를 포함한다.

예 30. 예 26 내지 예 29 중 어느 한 예에 있어서, 상기 제1 셀 및 상기 제2 셀은 상이한 기지국들과 연관된다.

예 31. 기지국은 프로세싱 하드웨어를 포함하고 그리고 예 11-16 또는 26-30 중 어느 하나에 따른 방법을 구현하도록 구성된다.

위의 설명에 다음 설명이 적용될 수 있다.

일부 구현들에서, RRCReconfiguration 메시지는 RRC 연결 재구성(RRCConnectionReconfiguration) 메시지일 수 있고, RRC 재구성 완료(RRCReconfigurationComplete)는 RRC 연결 재구성 완료(RRCConnectionReconfigurationComplete) 메시지일 수 있다.

일부 구현들에서, RRCReconfiguration은 BS(104) 또는 T-BS(106)에 의해 생성될 수 있다. 일부 구현에서, RRCReestablishmentRequest 메시지는 RRCConnectionReestablishmentRequest 메시지일 수 있으며, RRCReestablishment 메시지는 RRCConnectionReestablishment 메시지일 수 있고, RRCReestablishmentComplete는 RRCConnectionReestablishmentComplete 메시지일 수 있다.

일부 구현들에서, UE(102)가 랜덤 액세스 절차를 수행하기 위한 하나 이상의 구성은 2-스텝(2-step) 랜덤 액세스를 구성할 수 있다. 다른 구현에서, 랜덤 액세스 구성은 4-스텝(4-step) 랜덤 액세스를 구성할 수 있다. 또 다른 구현에서, 랜덤 액세스 구성은 경쟁 기반(contention-base) 랜덤 액세스 또는 무경쟁 랜덤 액세스를 구성할 수 있다. UE(102)는 랜덤 액세스 절차에서 또는 랜덤 액세스 절차를 성공적으로 완료한 후에 RRCReconfigurationComplete 또는 RRC 재설정 요청(RRCReestablishmentRequest) 메시지를 셀로 전송할 수 있다. RRCReestablishmentRequest를 수신한 셀은 UE가 RLF를 검출한 셀과 같을 수도 있고 다를 수도 있다.

본 개시물의 기술이 구현될 수 있는 사용자 디바이스(사용자 장치)(예를 들어, UE(102))는 스마트폰, 태블릿 컴퓨터, 노트북 컴퓨터, 모바일 게임 콘솔, POS(point-of-sale) 단말기, 건강 모니터링 장치, 드론, 카메라, 미디어 스트리밍 동글 또는 기타 개인 미디어 장치, 스마트 워치, 무선 핫스팟, 펨토셀 또는 광대역 라우터와 같은 웨어러블 장치와 같은 무선 통신이 가능한 임의의 적절한 장치일 수 있다. 또한, 사용자 디바이스는 경우에 따라 차량의 헤드 유닛 또는 ADAS(Advanced Driver Assistance System)와 같은 전자 시스템에 내장될 수 있다. 또한, 사용자 디바이스는 IoT(Internet-of-things) 디바이스 또는 MID(mobile-internet device)로 동작할 수 있다. 유형에 따라, 사용자 장치는 하나 이상의 범용 프로세서, 컴퓨터 판독 가능 메모리, 사용자 인터페이스, 하나 이상의 네트워크 인터페이스, 하나 이상의 센서 등을 포함할 수 있다.

특정 실시예는 로직 또는 다수의 컴포넌트 또는 모듈을 포함하는 것으로 본 개시에서 설명된다. 모듈은 소프트웨어 모듈(예: 코드 또는 비일시적 기계 판독 가능 매체에 저장된 기계 판독 가능 명령어) 또는 하드웨어 모듈일 수 있다. 하드웨어 모듈은 특정 작업을 수행할 수 있는 유형의 단위이며 특정 방식으로 구성되거나 배열될 수 있다. 하드웨어 모듈은 특정 작업을 수행하도록 영구적으로 구성된 전용 회로 또는 로직(예: FPGA(Field Programmable Gate Array) 또는 ASIC(Application-Specific Integrated Circuit), DSP(Digital Signal Processor) 등과 같은 특수 목적 프로세서)을 포함할 수 있다. 하드웨어 모듈은 또한 특정 동작을 수행하도록 소프트웨어에 의해 일시적으로 구성되는 프로그래밍 가능한 논리 또는 회로(예: 범용 프로세서 또는 기타 프로그래밍 가능 프로세서에 포함됨)를 포함할 수 있다. 전용 및 영구적으로 구성된 회로 또는 임시로 구성된 회로(예: 소프트웨어에 의해 구성된)에서 하드웨어 모듈을 구현하기 위한 결정은 비용 및 시간 고려 사항에 따라 결정될 수 있다.

소프트웨어로 구현될 때 기술은 운영 체제의 일부, 여러 응용 프로그램에서 사용되는 라이브러리, 특정 소프트웨어 응용 프로그램(애플리케이션) 등으로 제공될 수 있다. 소프트웨어는 하나 이상의 범용 프로세서 또는 하나 이상의 특수 목적 프로세서에 의해 실행될 수 있다.

다음과 같은 추가 고려 사항도 이 공개에 의해 고려된다: TS 38.331 v16.0.0은 다음과 같이 수정할 수 있다.

5.3.5.8.3 T304 expiry (Reconfiguration with sync Failure)

The UE shall:

1> if T304 of the MCG expires:

2> release dedicated preambles provided in rach-ConfigDedicated if configured;

2> release dedicated msgA PUSCH resources provided in rach-ConfigDedicated if configured;

2> store the following handover failure information in VarRLF-Report by setting its fields as follows:

3> clear the information included in VarRLF-Report, if any;

3> set the plmn-IdentityList to include the list of EPLMNs stored by the UE (i.e. includes the RPLMN);

3> set the measResultLastServCell to include the RSRP, RSRQ and the available SINR, of the source PCell based on the available SSB and CSI-RS measurements collected up to the moment the UE detected handover failure;

3> set the ssbRLMConfigBitmap and/or csi-rsRLMConfigBitmap in measResultLastServCell to include the radio link monitoring configuration of the source PCell;

3> for each of the configured measObjectNR in which measurements are available;

4> if the SS/PBCH block-based measurement quantities are available;

5> set the measResultListNR in measResultNeighCells to include all the available measurement quantities of the best measured cells associated to the measObjectNR, other than the source PCell, ordered such that the cell with highest SS/PBCH block RSRP is listed first if SS/PBCH block RSRP measurement results are available, otherwise the cell with highest SS/PBCH block RSRQ is listed first if SS/PBCH block RSRQ measurement results are available, otherwise the cell with highest SS/PBCH block SINR is listed first, based on the available SS/PBCH block based measurements collected up to the moment the UE detected handover failure;

6> for each neighbour cell included, include the optional fields that are available;

4> if the CSI-RS based measurement quantities are available;

5> set the measResultListNR in measResultNeighCells to include all the available measurement quantities of the best measured cells, other than the source PCell, ordered such that the cell with highest CSI-RS RSRP is listed first if CSI-RS RSRP measurement results are available, otherwise the cell with highest CSI-RS RSRQ is listed first if CSI-RS RSRQ measurement results are available, otherwise the cell with highest CSI-RS SINR is listed first, based on the available CSI-RS based measurements collected up to the moment the UE detected handover failure;

3> for each of the configured EUTRA frequencies in which measurements are available;

4> set the measResultListEUTRA in measResultNeighCells to include the best measured cells ordered such that the cell with highest RSRP is listed first if RSRP measurement results are available, otherwise the cell with highest RSRQ is listed first, and based on measurements collected up to the moment the UE detected radio link failure;

5> for each neighbour cell included, include the optional fields that are available;

NOTE 0: The measured quantities are filtered by the L3 filter as configured in the mobility measurement configuration. The measurements are based on the time domain measurement resource restriction, if configured. Blacklisted cells are not required to be reported.

3> if detailed location information is available, set the content of the LocationInfo as follows:

4> if available, set the commonLocationInfo to include the detailed location information;

4> if available, set the bt-LocationInfo to include the Bluetooth measurement results, in order of decreasing RSSI for Bluetooth beacons;

4> if available, set the wlan-LocationInfo to include the WLAN measurement results, in order of decreasing RSSI for WLAN APs;

4> if available, set the sensor-LocationInfo to include the sensor measurement results;

3> set the failedPCellId to the global cell identity and tracking area code, if available, and otherwise to the physical cell identity and carrier frequency of the target PCell of the failed handover;

3> include previousPCellId and set it to the global cell identity and tracking area code of the PCell where the last RRCReconfiguration message including reconfigurationWithSync was received;

3> set the timeConnFailure to the elapsed time since reception of the last RRCReconfiguration message including the reconfigurationWithSync;

3> set the connectionFailureType to hof;

3> set the c-RNTI to the C-RNTI used in the source PCell;

3> set the absoluteFrequencyPointA to indicate the absolute frequency of the reference resource block associated to the random-access resources;

3> set the locationAndBandwidth and subcarrierSpacing associated to the UL BWP of the random-access resources;

3> set the msg1-FrequencyStart, msg1-FDM and msg1-SubcarrierSpacing associated to the random-access resources;

3> set perRAInfoList to indicate random access failure information as specified in 5.3.10.3;

2> if dapsConfig is configured for any DRB, radio link failure is not detected in the source PCell, according to subclause 5.3.10.3 and T310 is not running:

3> release target PCell configuration;

3> reset target MAC and release the target MAC configuration;

3> for each DRB with a DAPS PDCP entity:

4> release the RLC entity and the associated logical channel for the target;

4> reconfigure the PDCP entity to normal PDCP as specified in TS 38.323 [5];

3> for each SRB:

4> if the masterKeyUpdate was not received:

5> configure the PDCP entity for the source with the same state variables as the PDCP entity for the target;

4> release the PDCP entity for the target;

4> release the RLC entity and the associated logical channel for the target;

3> release the physical channel configuration for the target;

3> revert back to the SDAP configuration used in the source;

3> discard the keys used in target (the K_gNB key, the S-K_gNB key, the S-K_eNB key, the K_RRCenc key, the K_RRCint key, the K_UPint key and the K_UPenc key), if any;

3> resume suspended SRBs in the source;

3> for each DRB without a DAPS PDCP entity:

4> revert back to the UE configuration used for the DRB in the source, includes PDCP, RLC states variables, the security configuration and the data stored in transmission and reception buffers in PDCP and RLC entities ;

3> revert back to the UE RRM configuration used in the source;

3> initiate the failure information procedure as specified in subclause 5.7.5 to report DAPS handover failure.

2> else:

3> revert back to the UE configuration used in the source PCell;

3> initiate the connection re-establishment procedure as specified in subclause 5.3.7.

NOTE 1: In the context above, "the UE configuration" includes state variables and parameters of each radio bearer.

1> else if T304 of a secondary cell group expires:

2> if MCG transmission is not suspended:

3> release dedicated preambles provided in rach-ConfigDedicated, if configured;

3> initiate the SCG failure information procedure as specified in subclause 5.7.3 to report SCG reconfiguration with sync failure, upon which the RRC reconfiguration procedure ends;

2> else:

3> initiate the connection re-establishment procedure as specified in subclause 5.3.7;

1> else if T304 expires when RRCReconfiguration is received via other RAT (HO to NR failure):

2> reset MAC;

2> perform the actions defined for this failure case as defined in the specifications applicable for the other RAT.

TS 38.331 v16.0.0 further can be modified as follows:

5.7.5.x Failure to deliver FailureInformation message

The UE shall:

1> if initiated FailureInformation to provide DAPS failure information:

2> initiate the connection re-establishment procedure as specified in 5.3.7;

1> else:

2> perform the radio link failure related actions as specified in 5.3.10.

5.3.7.4 Actions related to transmission of RRCReestablishmentRequest message

The UE shall set the contents of RRCReestablishmentRequest message as follows:

...

1> set the reestablishmentCause as follows:

2> if the re-establishment procedure was initiated due to reconfiguration failure as specified in 5.3.5.8.2:

3> set the reestablishmentCause to the value reconfigurationFailure;

2> else if the re-establishment procedure was initiated due to reconfiguration with sync failure as specified in 5.3.5.8.3 (intra-NR handover failure) or 5.4.3.5 (inter-RAT mobility from NR failure) or 5.7.5.x (Failure to deliver FailureInformation):

3> set the reestablishmentCause to the value handoverFailure;

2> else:

3> set the reestablishmentCause to the value otherFailure;

TS 38.331 v16.0.0 further can be modified as follows:

...

1> set the reestablishmentCause as follows:

2> if the re-establishment procedure was initiated due to reconfiguration failure as specified in 5.3.5.8.2 or 5.4.3.5:

3> set the reestablishmentCause to the value reconfigurationFailure;

2> else if the re-establishment procedure was initiated due to reconfiguration with sync failure as specified in 5.3.5.8.3 (intra-NR handover failure) or 5.4.3.5 (inter-RAT mobility from NR failure):

3> set the reestablishmentCause to the value handoverFailure;

2> else:

3> set the reestablishmentCause to the value otherFailure;

TS 36.331 further can be modified as follows:

5.3.7.4 Actions related to transmission of RRCConnectionReestablishmentRequest message

Except for NB-IoT, if the procedure was initiated due to radio link failure or handover failure, the UE shall:

1> set the reestablishmentCellId in the VarRLF-Report to the global cell identity of the selected cell;

Editor's Note: FFS: The re-establishment cell id is also included in the RLF report for NB-IoT.

The UE shall set the contents of RRCConnectionReestablishmentRequest message as follows:

...

1> set the reestablishmentCause as follows:

2> if the re-establishment procedure was initiated due to reconfiguration failure as specified in 5.3.5.5 (the UE is unable to comply with the reconfiguration) or 5.4.3.5 (the UE is unable to comply with MobilityFromEUTRACommand ):

3> set the reestablishmentCause to the value reconfigurationFailure;

2> else if the re-establishment procedure was initiated due to handover failure as specified in 5.3.5.6 (intra-LTE handover failure) or 5.4.3.5 (inter-RAT mobility from EUTRA failure):

3> set the reestablishmentCause to the value handoverFailure;

2> else:

3> set the reestablishmentCause to the value otherFailure;

Claims

제1 무선 액세스 기술(RAT)과 연관된 제1 셀에 연결된 사용자 장비(UE)에서, 제2 RAT와 연관된 제2 셀로의 핸드오버를 지원하기 위한 방법으로서,
프로세싱 하드웨어에 의해 상기 제2 셀에 연결을 시도하는 단계;
상기 프로세싱 하드웨어에 의해, 상기 제2 셀과 연관된 구성의 적용 실패를 검출하는 단계; 그리고
상기 프로세싱 하드웨어에 의해, 무선 연결을 재설정(re-establish)하라는 요청을 전송함으로써 상기 제1 셀을 통해 상기 구성의 적용 실패의 표시를 제공하는 단계를 포함하며, 상기 요청은 재구성 실패를 나타내는 실패 원인을 포함하는 것을 특징으로 하는 방법.
제1항에 있어서, 상기 실패를 검출하는 단계는,
상기 UE가 상기 구성을 적용할 수 없다고 결정하는 단계를 포함하는 것을 특징으로 하는 방법.
제1항 또는 제2항에 있어서, 상기 실패를 검출하는 단계는,
상기 제2 셀에 대한 연결 시도에 응답하여 타이머를 시작하는 단계; 그리고
상기 타이머가 만료되기 전에 상기 UE가 상기 제2 셀에 연결할 수 없다고 결정하는 단계를 포함하는 것을 특징으로 하는 방법.
제1항 내지 제3항 중 어느 한 항에 있어서, 상기 방법은,
상기 프로세싱 하드웨어에 의해, 핸드오버 요청 메시지에서 상기 제2 셀과 연관된 상기 구성을 수신하는 단계를 더 포함하는 것을 특징으로 하는 방법.
제4항에 있어서, 상기 구성을 수신하는 단계는 MobilityFromNRCommand 또는 MobilityFromEUTRACommand에서 상기 구성을 수신하는 단계를 포함하는 것을 특징으로 하는 방법.
제1항 내지 제5항 중 어느 한 항에 있어서, 상기 제1 셀 및 상기 제2 셀은 상이한 기지국과 연관되는 것을 특징으로 하는 방법.
제1항 내지 제6항 중 어느 한 항에 있어서, 상기 방법은,
상기 프로세싱 하드웨어에 의해, 상기 제1 셀과 연관된 무선 연결의 잠재적인 실패를 검출하는 단계를 더 포함하는 것을 특징으로 하는 방법.
제1항 내지 제7항 중 어느 한 항에 있어서, 상기 요청을 전송하는 단계는,
reconfigurationFailure 실패 원인을 포함하는 무선 자원 제어(RRC) 재설정 요청 메시지를 전송하는 단계를 포함하는 것을 특징으로 하는 방법.
사용자 장비(UE)로서,
프로세싱 하드웨어를 포함하고 그리고 제1항 내지 제8항 중 어느 한 항에 따른 방법을 구현하도록 구성되는 것을 특징으로 하는 사용자 장비.
제1 RAT(Radio Access Technology)의 제1 셀을 지원하는 기지국에서 인터-RAT(inter-RAT) 핸드오버를 지원하는 방법으로서,
프로세싱 하드웨어에 의해, 제2 RAT의 제2 셀에 연결하기 위한 사용자 장비(UE)에 대한 요청을 상기 UE로 전송하는 단계 -상기 요청은 상기 UE가 상기 제2 셀에 연결하기 위해 사용할 구성을 포함함-;
상기 프로세싱 하드웨어에 의해, 무선 연결을 재설정하라는 요청을 상기 UE로부터 수신하는 단계 -상기 요청은 핸드오버 실패를 나타내는 실패 원인을 포함함-;
상기 프로세싱 하드웨어에 의해, 상기 UE와의 무선 연결을 구성하기 위한 메시지를 전송하는 단계;
상기 프로세싱 하드웨어에 의해, 상기 메시지에 대한 응답을 수신하는 단계 -상기 응답은 핸드오버 실패 정보가 이용 가능하지 않다는 것을 나타냄-;
상기 프로세싱 하드웨어에 의해 그리고 상기 응답에 기초하여, 상기 UE가 상기 구성을 적용할 수 없다고 결정하는 단계; 그리고
상기 프로세싱 하드웨어에 의해, 상기 결정에 응답하여 시정 액션(corrective action)을 수행하는 단계를 포함하는 것을 특징으로 하는 방법.
제10항에 있어서, 상기 시정 액션을 수행하는 단계는,
상기 UE와 연관된 성능 정보(capability information)에 대한 요청을 상기 UE에 전송하는 단계를 포함하는 것을 특징으로 하는 방법.
제10항 또는 제11항에 있어서, 상기 무선 연결을 구성하기 위해 상기 메시지를 전송하는 단계는,
상기 UE와의 무선 연결을 재설정하라는 메시지를 전송하는 단계를 포함하는 것을 특징으로 하는 방법.
제10항 내지 제12항 중 어느 한 항에 있어서, 상기 무선 연결을 구성하기 위해 상기 메시지를 전송하는 단계는,
상기 UE와의 새로운 무선 연결을 설정하기 위한 메시지를 전송하는 단계를 포함하는 것을 특징으로 하는 방법.
제10항 내지 제13항 중 어느 한 항에 있어서, 상기 제1 셀 및 상기 제2 셀은 상이한 기지국과 연관되는 것을 특징으로 하는 방법.
기지국으로서,
프로세싱 하드웨어를 포함하고 그리고 청구항 제10항 내지 제14항 중 어느 한 항에 따른 방법을 구현하도록 구성된 것을 특징으로 하는 기지국.