프로세스 는 UE ( 400 ) 가 채널 조건 들 의 표시 를 포함 하 는 측정 보고 ( 410 ) 를 소스 gNB ( 402 ) 에 송신 하 는 것 으로 시작 된다 . 그러 한 조건 들 의 잠재 적 악화 , 또는 소스 gNB ( 402 ) 에서 떨어진 방향 으로 의 UE ( 400 ) 의 이동 으로 인해 , 소스 gNB ( 402 ) 는 핸드 오버 를 수행 할 필요 가 있 다고 생각 할 수 있 다 . 그러 한 사례 에서 , 소스 gNB ( 402 ) 는 메시지 들 ( 410 412 , 414 , 416 ) 을 타 겟 gNB 들 ( 404 , 406 , 408 , 409 ) 에 송신 한다 . 제 1 타 겟 gNB ( 404 ) 는 핸드 오버 를 거절 하 며 ( 411 ) , 제 2 gNB ( 406 ) 에 의해 그것 이 부분 핸드 오버 를 수락 할 수 있 는 것 을 표시 한다 ( 413 ) . 이러 한 표시 ( 413 ) 는 소스 gNB ( 402 ) 에 시그널 링 되 는 이용 가능 서비스 레벨 을 포함 할 수 있 다 . 이 시점 에 , 소스 gNB ( 402 ) 는 타 겟 gNB 들 이 전체 핸드 오버 를 수락 하 거나 , 제 2 타 겟 gNB ( 406 ) 로 의 부분 핸드 오버 로 진행 할 수 있 는지 를 계속 ( 420 ) 체크 하 는지 를 결정 할 수 있 다 . 새로운 로직 은 많 은 타 겟 gNB 들 을 계속 체크 하 는 것 을 평가 하 기 위해 소스 gNB ( 402 ) 에서 요구 된다 . 도 4 의 예 에서 , 소스 gNB ( 402 ) 는 제 3 gNB ( 408 ) 가 부분 핸드 오버 를 수락 할 수 있 는 다른 표시 ( 415 ) 및 다른 거절 ( 417 ) 을 계속 결정 하 고 , 제 4 gNB ( 409 ) 로부터 수신 한다 . 그 다음 , 소스 gNB ( 402 ) 는 제 2 타 겟 gNB ( 406 ) 를 선택 하 고 ( 430 ) , 그것 에 핸드 오버 를 준비 하 도록 ( 440 ) 명령 하 며 , 이 를 위해 그것 은 확인 응답 ( 442 ) 을 수신 한다 . UE ( 400 ) 는 RRC _ 연결 된 상태 ( 450 ) 에 진입 하 고 , 핸드 오버 커맨드 및 명령어 를 수신 해서 그것 이 확인 응답 ( 454 ) 을 송신 하 는 것 에 응답 하 여 , 소스 gNB ( 402 ) 로부터 그것 의 RRC 세팅 들 ( 452 ) 을 재 구성 한다 . RRC 재 구성 이 완료 되 었 다면 , UE ( 400 ) 는 이것 ( 456 ) 을 제 2 타 겟 gNB ( 406 ) 에 시그널 링 하 며 , 이 제 2 타 겟 gNB 는 UE ( 400 ) 에 대한 서빙 gNB 가 된다 . UE 는 그것 의 이전 PAQ 흐름 들 을 유지 하 지만 , 제 2 타 겟 gNB ( 406 ) 가 ( 혼잡 으로 인해 ) 부분 핸드 오버 만 을 수락 할 수 있 기 때문 에 , 이러 한 PAQ 흐름 들 은 더 낮 은 QoS 레벨 에서 유지 된다 ( 460 ) . 따라서 , 여기 서 , 소스 gNB ( 402 ) 로부터 의 새로운 핸드 오버 커맨드 는 높 은 QoS 흐름 들 의 스타 빙 ( starving ) 을 가능 하 게 하 기 위해 , 특정 흐름 들 에 대한 QoS 의 변경 을 위한 명령어 로 확장 된다 . 나중 의 시점 에 , 제 2 타 겟 gNB ( 406 ) 에서 의 혼잡 이 떨어지 고 ( 470 ) , 그것 이 원래 의 레벨 들 에서 UE ( 400 ) 로부터 모든 PAQ 흐름 들 을 수락 할 수 있 는 것 을 결정 하 면 , 그것 은 다른 RRC 재 구성 메시지 ( 472 ) 를 UE ( 400 ) 에 송신 하 고 , UE ( 400 ) 가 적절히 작동 되 었 으면 , RRC 재 구성 이 완료 된 표시 ( 474 ) 를 UE ( 400 ) 로부터 수신 한다 .