본 개시는 모바일 타깃 디바이스의 로케이션이 이 디바이스 자체에 의해 또는 타깃 디바이스 외부의 일부 클라이언트 또는 애플리케이션에 의해 주기적 간격으로 요구되는 로케이션 서비스들의 지원에 관한 것이다.
본 개시의 일 양태는 어시스턴스 데이터 또는 로케이션 정보의 진행중인 이송의 수정을 허용한다. 특히, 어시스턴스 데이터 또는 로케이션 정보의 초기 이송은 새로운 이송을 위하여 필요한 자원들 및 정보가 릴리스되지 않는다는 것을 보장하기 위하여 이송 세션을 중지 또는 중단하는 일 없이도 타깃 디바이스 또는 로케이션 서버에 의해 수정될 수도 있다. 또한, 수정은 다른 단 (end) 에 의해 합의 또는 변경되어 변경을 요청한 단 쪽에게 다시 확인될 수 있으며, 수정은 포지셔닝 프로토콜의 동작에 관한 기존의 규칙들을 준수할 수 있다. LPPe 에서의 수정을 지원함에 있어서, (로케이션 서버로부터의) 어시스턴스 데이터 또는 (타깃 디바이스로부터의) 로케이션 정보 중 어느 하나를 요청 및 획득하기 위한 기존의 LPP 절차들은 유지된다. LPP 절차들은 또한 LPP 트랜잭션들이라고도 지칭될 수도 있으며 양측 모두의 용어들은 이후에 동의어로 사용된다. LPP 절차들은 또한, 제어 절차 또는 트랜잭션 (A) 이 어시스턴스 데이터 또는 로케이션 정보를 초기에 요청하기 위하여 사용되고 제 2 데이터 절차 또는 데이터 트랜잭션 (B) 이 어시스턴스 데이터 또는 로케이션 정보를 이송하기 위하여 사용되도록 확장된다. 이전의 2 개의 절차들과는 분리된 제 3 제어 절차 및 제 4 제어 절차는 또한, 어시스턴스 데이터 또는 로케이션 정보의 진행중인 이송의 수정을 위한 요청이 이송을 위한 수신기에 의해 전송되거나 (C) 또는 이송을 위한 전송기에 의해 전송되는 (D) 것을 가능하게 하도록 부가된다. 이 4 개의 절차들의 각각은 LPP 에 대해 3GPP TS 36.355 에서 정의된 어시스턴스 데이터 또는 로케이션 정보에 대한 이송 절차를 준수한다. 특히, 절차들 (A), (C) 및 (D) 는, 절차의 종단을 나타내는 트랜잭션 표시의 종단을 반송하는 수신자로부터의 응답이 뒤따르는, 개시 단으로부터의 요청을 포함한다. 절차 (B) 는 트랜잭션의 종단 그리고 그에 따라 절차의 종단을 나타내는 (어시스턴스 데이터 또는 로케이션 정보의 마지막 부분을 반송하는) 최종 메시지를 가지는 어시스턴스 데이터 또는 로케이션 정보를 반송하는 LPP/LPPe 메시지들의 시퀀스를 포함한다. 이 절차들은 여기에서 앞으로 계속 더욱 상세히 설명된다.
도 1 은 진행중인 데이터 이송 세션 동안 로케이션 관련 데이터의 수정을 제공하는 시스템 (10) 을 도시한다. 도 1 은 모바일 디바이스 (16) 및 로케이션 서버 (26) 를 포함한다. 모바일 디바이스 (16) 는 무선 단말, 와이어라인 단말, 셀 전화기, 스마트폰, 랩톱, 태블릿 등일 수도 있고, 사용자 장비 (UE), 이동국 (MS), 모바일 타깃 디바이스, 타깃 디바이스 또는 타깃이라고 지칭될 수도 있다. 로케이션 서버 (26) 는 3GPP 서빙 모바일 로케이션 센터 (SMLC), 자립형 SMLC (SAS) 또는 3 세대 파트너십 프로젝트 2 (3GPP2) 포지션 결정 엔티티 (PDE) 또는 OMA 보안성 사용자 플레인 로케이션 (SUPL) 솔루션 또는 일부 다른 로케이션 서버를 지원하는 OMA SUPL 로케이션 플랫폼 (SLP) 일 수도 있다.
모바일 디바이스 (16) 는 네트워크 (21) 로의 액세스를 포함한다. 네트워크 (21) 는 무선 네트워크, 고정된 네트워크, 또는 무선 네트워크 및/또는 고정된 네트워크들의 조합일 수도 있다. 로케이션 서버 (26) 는 또한 네트워크 (21) 와 연결된다. 타깃 디바이스의 로케이션을 요청 및 수신할 수도 있는 일부 로케이션 클라이언트 (도 1 에서 미도시) 는 로케이션 서버 (26) 와 결합될 것이다. 실제로는, 로케이션 서버 (26) 는 네트워크 (21) 의 내부에 상주할 수도 있고, 외부에 있어 네트워크 (21) 로의 통신 액세스를 가질 수도 있거나 또는 네트워크 (21) 를 통하여 도달가능한 다른 네트워크 (미도시) 내부에 있거나 그에 부착될 수도 있다. GPS 또는 GNSS 위성들 (20a 내지 20n) 은 모바일 디바이스 (16) 에 의해 검출될 수도 있다.
포지션 로케이션 신호들은 하나 이상의 위성들 (20a 내지 20n) 로부터 송신될 수도 있다. 하나 이상의 위성들 (20a 내지 20n) 로부터 송신된 포지션 로케이션 신호들은 네트워크 (21) 에 의해 수신될 수도 있다. 네트워크 (21) 는 위성 정보를 로케이션 서버 (26) 에 포워딩할 수도 있으며, 로케이션 서버 (26) 는 사용자가 모바일 디바이스 (16) 에 포함된 위성 포지션 시스템 (SPS) 기술을 이용하여 포지션 로케이션을 확립하고자 시도할 수도 있는 모바일 디바이스 (16) 를 포함하여, 많은 수신기들, 송수신기들, 서버들, 및/또는 단말들로 위성 정보의 일부 또는 모두를 어시스턴스 데이터로서 송신할 수도 있다. 어시스턴스 데이터 및 로케이션측정 데이터와 같은 로케이션 관련 데이터가 또한 모바일 디바이스 (16) 와 로케이션 서버 (26) 사이에서 송신될 수도 있다. 모바일 디바이스 (16) 와 로케이션 서버 (26) 사이의 어시스턴스 데이터 (예를 들면, 위성 정보) 및/또는 로케이션 정보의 이송은 네트워크 (21) 를 통한 (그리고 로케이션 서버 (26) 가 다른 네트워크에 연결되어 있고 네트워크 (21) 에는 연결되어 있지 않으면 부가적 네트워크들을 통한) 통신 능력 (24) (예를 들면, 접속 또는 세션) 을 채용할 수도 있다. 통신 능력 (24) 은 전송 제어 프로토콜 (TCP) 및 인터넷 프로토콜 (IP) 과 같은 수송 프로토콜들 또는 네트워크 (21) 의 특정 유형 (예를 들면, GSM, CDMA, WCDMA, LTE) 과 연관되고 그 특정 유형에 대해 정의된 프로토콜들을 이용할 수도 있고, 로케이션 서버 (26) 및 모바일 디바이스 (16) 에 의해 지원되지만 네트워크 (21) 에 의해서 반드시 지원되지는 않는 LPP 및 LPPe 와 같은 포지셔닝 프로토콜을 채용할 수도 있다.
도 2a 는, 도 1 과 교차 참조하여, 모바일 디바이스 (16) 가 적어도 하나의 컴퓨터 프로세싱 시스템 (28) 을 포함하는 것을 도시한다. 도시한 바와 같이, 컴퓨터 프로세싱 시스템 (28) 은 모바일 디바이스 (16) 에 작용적으로 연결된다. 일 양태에서, 컴퓨터 프로세싱 시스템 (28) 은 모바일 디바이스 (16) 에 하우징된다. 컴퓨터 프로세싱 시스템 (28) 은 로케이션 포지션 데이터와 적어도 연계하여 명령들을 수신하고, 저장하고, 프로세스하고, 실행하도록 구성된다.
모바일 디바이스 (16) 의 컴퓨터 프로세싱 시스템 (28) 은 도 2a 의 블록도에 도시된다. 도시한 바와 같이, 컴퓨터 프로세싱 시스템 (28) 은, 모바일 디바이스 (16) 로 하여금 포지션 신호들 (도 1) 및 포지션 로케이션 데이터를 포함하는 기지국 포지션 로케이션 신호 (도 1) 를 포함하는, 포지션 로케이션 데이터에 대한 데이터 및 정보와 연계하여, 명령들을 수신하고, 프로세스하고, 저장하고, 실행하도록 하는 다양한 컴포넌트들을 포함할 수도 있다. 이 컴포넌트들은 데이터 프로세서 (30), 포지션 로케이션 수신기 (예를 들면, GPS 수신기) (31), 저장 매체 (32), 무선 모뎀 (33), 및 셀룰러 송수신기 (35) 를 포함할 수도 있으며, 이 모두는 버스 (34) 에 의해 결합된다. 저장 매체 (32) 는 기계 판독가능 매체 또는 컴퓨터 판독가능 매체이며, ROM, 플래시, EPROM, EEPROM, 및 버블 메모리 (bubble memory) 와 같은 비휘발성 메모리들뿐만 아니라 DRAM 및 SRAM 과 같은 휘발성 메모리들을 포함할 수도 있지만 그에 제한되지는 않는다.
또한, 옵션적 2차 스토리지 (36), 외부 스토리지 (38), 모바일 디바이스 (16) 에 포함될 수도 있는 모니터 (40) 와 같은 출력 디바이스들, 및 옵션적 구성들에 있어서, 입력 디바이스, 이를테면, 키보드 (42), 마우스 (44), 및 프린터 (46) 는 버스에 연결될 수 있다. 2차 스토리지 (36) 는 하드 디스크 드라이브, 자기 드럼, 및 버블 메모리와 같은 기계 판독가능 미디어를 포함할 수도 있지만 그에 제한되지는 않는다. 외부 스토리지 (38) 는 플로피 디스크, 착탈식 하드 드라이브, 자기 테이프, CD-ROM, 착탈식 메모리 카드들, 및 심지어는 통신 라인을 통하여 연결된 다른 컴퓨터들과 같은 기계 판독가능 미디어를 포함할 수도 있다. 2차 스토리지 (36) 와 외부 스토리지 (38) 사이의 구분은 주로 기계 판독가능 메모리의 사용을 설명함에 있어서의 편의를 위함이다. 그와 같이, 이 기술분야의 숙련된 자는 컴포넌트들 사이에 그리고 컴포넌트들 중에서 실질적인 기능적 오버랩이 있다는 것을 이해할 것이다. 컴퓨터 소프트웨어 및 사용자 프로그램들은 저장 매체 (32) 및 외부 스토리지 (38) 에 저장될 수 있다. 컴퓨터 소프트웨어의 실행가능한 버전들은 저장 매체 (32) 또는 다른 비휘발성 저장 매체로부터 판독될 수 있거나, 실행을 위해 휘발성 저장 매체로 직접적으로 로딩될 수 있거나, 비휘발성 저장 매체로부터 직접적으로 실행될 수 있거나, 또는 실행을 위해 휘발성 저장 매체내로 로딩되기 전에 2차 스토리지 상에 저장될 수 있다.
모바일 디바이스 (16) 의 도 2a 에 도시된 컴퓨터 프로세싱 시스템 (28) 은 이 문서에서 설명된 로케이션 관련 데이터 이송 시스템 (10) 의 방법들을 구현하기 위한 컴퓨터 명령들 (이 문서에서, "명령들") 의 세트를 포함한다. 명령들 (48) 은 도 2a 에서 이 문서에서 설명된 로케이션 관련 데이터 이송 시스템 (10) 의 방법을 이해함에 있어서의 지원으로서 도식적으로 단독으로 도시된다. 명령들은 다양한 내부 메모리에 저장될 수도 있거나 하드웨어로 구현될 수도 있다. 명령들은 또한 예를 들면, 보안성 인트라넷 상에, 인터넷 상에, 또는 그것으로부터 명령들이 모바일 디바이스 (16) 로 송신될 수도 있는 기지국에서, 모바일 디바이스 (16) 의 외부에 로케이팅된 컴퓨터의 컴퓨터 프로세싱 시스템에 포함될 수도 있다. 명령들과 연관된 데이터는 수신되고, 저장되고, 프로세싱되고 모바일 디바이스들로 송신될 수도 있으나, 명료함을 위해 단일의 모바일 디바이스 (16) 만이 도시된다. 명령들과 연관된 데이터는 또한 수신되고, 저장되고, 프로세싱되고 무선 통신 시스템 전체에 걸쳐 하나 이상의 기지국들로/로부터 송신될 수도 있다. 대안적으로, 명령들과 연관된 데이터는 또한 수신되고, 저장되고, 프로세싱되고 무선 네트워크에 연결된 컴퓨터 서버로/로부터 송신될 수도 있다.
도 2b 는, 도 1 과 교차 참조하여, 로케이션 서버 (26) 가 적어도 하나의 컴퓨터 프로세싱 시스템 (58) 을 포함하는 것을 도시한다. 일 양태에서, 컴퓨터 프로세싱 시스템 (58) 은 로케이션 서버 (26) 에 하우징된다. 컴퓨터 프로세싱 시스템 (58) 은 로케이션 포지션 데이터와 적어도 연계하여 명령들을 수신하고, 저장하고, 프로세스하고, 실행하도록 구성된다.
로케이션 서버 (26) 의 컴퓨터 프로세싱 시스템 (58) 은 도 2b 의 블록도에 도시된다. 도시한 바와 같이, 컴퓨터 프로세싱 시스템 (58) 은 로케이션 서버 (26) 로 하여금 포지션 신호들 및 포지션 로케이션 데이터를 포함하는 기지국 포지션 로케이션 신호들을 포함하는 포지션 로케이션 데이터에 대한 데이터 및 정보와 연계하여 명령들을 수신하고, 프로세스하고, 저장하고, 실행하도록 하는 다양한 컴포넌트들을 포함할 수도 있다. 컴포넌트들은 버스 (64) 에 의해 결합된 데이터 프로세서 (60) 및 저장 매체 (62) 를 포함할 수도 있다. 저장 매체 (62) 는 기계 판독가능 매체 또는 컴퓨터 판독가능 매체이며, ROM, 플래시, EPROM, EEPROM, 및 버블 메모리와 같은 비휘발성 메모리들뿐만 아니라 DRAM 및 SRAM 과 같은 휘발성 메모리들을 포함할 수도 있지만 그에 제한되지는 않는다.
또한, 옵션적 2차 스토리지 (66), 외부 스토리지 (68), 로케이션 서버 (26) 와 함께 포함될 수도 있는 모니터 (70) 와 같은 출력 디바이스들, 및 옵션적 구성들에 있어서, 입력 디바이스, 이를테면, 키보드 (72), 마우스 (74), 및 프린터 (76) 는 버스에 결합될 수 있다. 2차 스토리지 (66) 는 하드 디스크 드라이브, 자기 드럼, 및 버블 메모리와 같은 기계 판독가능 미디어를 포함할 수도 있지만 그에 제한되지는 않는다. 외부 스토리지 (68) 는 플로피 디스크, 착탈식 하드 드라이브, 자기 테이프, CD-ROM, 착탈식 메모리 카드들, 및 심지어는 통신 라인을 통하여 연결된 다른 컴퓨터들과 같은 기계 판독가능 미디어를 포함할 수도 있다. 옵션적 2차 스토리지 (66) 와 외부 스토리지 (68) 사이의 구분은 주로 기계 판독가능 메모리의 사용을 설명함에 있어서의 편의를 위함이다. 그와 같이, 이 기술분야의 숙련된 자는 컴포넌트들 사이에 그리고 컴포넌트들 중에서 실질적인 기능적 오버랩이 있다는 것을 이해할 것이다. 컴퓨터 소프트웨어 및 사용자 프로그램들은 저장 매체 (62) 및 외부 스토리지 (68) 에 저장될 수 있다. 컴퓨터 소프트웨어의 실행가능한 버전들은 저장 매체 (62) 또는 다른 비휘발성 저장 매체로부터 판독될 수 있거나, 실행을 위해 휘발성 저장 매체로 직접적으로 로딩될 수 있거나, 비휘발성 저장 매체로부터 직접적으로 실행될 수 있거나, 또는 실행을 위해 휘발성 저장 매체 내로 로딩되기 전에 2차 스토리지 상에 저장될 수 있다.
로케이션 서버 (26) 의 컴퓨터 프로세싱 시스템 (58) 은 이 문서에서 설명된 로케이션 관련 데이터 이송 시스템 (10) 의 방법들을 구현하기 위한 컴퓨터 명령들 (이 문서에서, "명령들") 의 세트를 포함한다. 명령들 (78) 은 다양한 내부 메모리에 저장될 수도 있거나 하드웨어로 구현될 수도 있다. 명령들은 또한, 예를 들면, 보안성 인트라넷 상에, 인터넷 상에, 또는 그것으로부터 명령들이 로케이션 서버 (26) 로 송신될 수도 있는 기지국에서, 로케이션 서버 (26) 의 외부에 로케이팅된 컴퓨터의 컴퓨터 프로세싱 시스템에 포함될 수도 있다.
일 양태에서, 로케이션 서버와 모바일 디바이스 사이의 진행중인 데이터 이송 세션에서의 로케이션 관련 데이터의 수정을 허용하는 시스템이 LPP 의 능력들을 확장하도록 구성된다. 예를 들면, LPP 메시지는 3GPP TS 36.355 에 정의된 바와 같이 LPP 에 대한 정보 및 파라미터들과, 부가 정보를 포함하고 부가 절차들을 지원하는 부가적인 내장형 LPPe (LPP 확장 프로토콜) 메시지를 포함하도록 구성될 수도 있다. 정의된 절차들에 따른 LPP 에 대해서 말하자면 내장형 LPPe 메시지 내에서 반송되는 정보는 어시스턴스 데이터 및 로케이션 정보의 이송을 지원하기 위하여 사용될 수도 있다. 이 절차들은 초기 이송을 중지 또는 중단하는 일 없이도 LPPe 에 의해 반송되는 어시스턴스 데이터 또는 로케이션 정보의 주기적인 이송을 수정할 수도 있다. 다른 양태에서, LPPe 에 의해 사용된 절차들은 3GPP TS 36.355 에서 LPP 에 대하여 이미 정의된 절차들과 호환되며 LPP 레벨에서의 프로토콜 에러들을 방지한다.
일 양태에서, LPPe 절차는 이송을 이후에 수정할 능력과 함께 로케이션 관련 데이터의 주기적 이송을 지원하도록 정의된다. 로케이션 관련 데이터는 어시스턴스 데이터 및 로케이션 측정 정보를 포함할 수도 있다. 이 절차는 비응답형 (unsolicited) 및/또는 응답형 (solicited) LPP 어시스턴스 데이터 이송 절차의 다수의 인스턴스들, 또는 비응답형 및/또는 응답형 LPP 로케이션 정보 이송 절차의 다수의 인스턴스들을 포함할 수도 있으며, 둘 중 어느 하나의 절차의 각각의 인스턴스는 TS 36.355 에 정의한 바와 같다 (예를 들면, 각각의 그러한 인스턴스에 대한 마지막 메시지는 그런 다음 트랜잭션 표시자의 종단을 포함할 것이다).
도 6a 는 3 GPP TS 36.355 에서 LPP 에 대하여 정의된 바와 같이 어시스턴스 데이터를 로케이션 서버 (예를 들면, 도 1 에서의 로케이션 서버 (26)) 로부터 타깃 디바이스 (예를 들면, 도 1 에서의 모바일 디바이스 (16)) 로 이송하는 절차를 도시한다. 옵션적으로 단계 1 에서, 타깃 디바이스는 어시스턴스 데이터에 대한 LPP 요청을 로케이션 서버로 전송한다. 단계 1 에서의 LPP 메시지는 일부 트랜잭션 ID T1, 및 요청된 로케이션 어시스턴스 데이터의 유형을 정의하는 파라미터들을 포함한다.
단계 2 에서, 로케이션 서버 (26) 는 단계 1 에서 요청된 어시스턴스 데이터 및 단계 1 에서 사용된 동일한 트랜잭션 ID T1 를 포함하는 LPP 메시지를 타깃으로 전송한다. 만약 단계 1 이 발생하지 않으면, 로케이션 서버 (26) 는 단계 2 에서 타깃 디바이스로 여전히 어시스턴스 데이터를 전송할 수 있지만 이 경우에 어시스턴스 데이터는 비응답형 어시스턴스 데이터로서 전송된다. 더욱이, 어시스턴스 데이터가 비응답형 어시스턴스 데이터로서 전송되면, 로케이션 서버는 데이터 자체의 콘텐츠를 결정할 수도 있거나 이 데이터를 도 6a 에 도시되지 않은 타깃 디바이스로부터의 일부 이전 요청에 기초할 수도 있다. 단계 2 는 부가적인 데이터를 동시에 전송하거나 부가적인 데이터를 1 회 이상의 연속적인 횟수들로 전송하기 위하여 1 회 이상 반복될 수도 있다.
단계 3 에서, 로케이션 서버는 최종 어시스턴스 데이터를 전송하고 트랜잭션 T1 에 대한 트랜잭션 표시의 종단을 포함함으로써 절차의 종단을 나타낸다. 만약 어시스턴스 데이터의 하나의 세트만이 전송되면, 단계 2 는 스킵될 수 있고 오직 단계 3 및 옵션적으로 단계 1 이 발생할 수 있다.
도 6b 는 3GPP TS 36.355 에서 LPP 에 대해 정의된 바와 같이 로케이션 정보를 타깃 디바이스 (예를 들면, 도 1 에서의 모바일 디바이스 (16)) 로부터 로케이션 서버 (예를 들면, 도 1 에서의 로케이션 서버 (26)) 로 이송하는 절차를 도시한다. 옵션적으로 단계 1 에서, 로케이션 서버는 로케이션 정보에 대한 LPP 요청을 타깃 디바이스로 전송한다. 단계 1 에서의 LPP 메시지는 일부 트랜잭션 ID T2 및 요청된 로케이션 정보의 유형을 정의하는 파라미터들을 포함한다.
단계 2 에서, 타깃은 단계 1 에서 요청된 로케이션 정보 및 단계 1 에서 사용된 동일한 트랜잭션 ID T2 를 포함하는 LPP 메시지를 로케이션 서버 (26) 로 전송한다. 만약 단계 1 이 발생하지 않으면, 타깃은 단계 2 에서 로케이션 서버 (26) 로 여전히 로케이션 정보를 전송할 수 있지만 이 경우에 로케이션 정보는 비응답형 로케이션 정보로서 전송된다. 더욱이, 로케이션 정보가 비응답형 로케이션 정보로서 전송되면, 타깃 디바이스는 로케이션 정보 자체의 콘텐츠를 결정할 수도 있거나 이 정보를 도 6b 에 도시되지 않은 로케이션 서버 (26) 로부터의 일부 이전 요청에 기초할 수도 있다. 단계 2 는 부가적인 데이터를 동시에 전송하거나 부가적인 데이터를 1 회 이상의 연속적인 횟수들로 전송하기 위하여 1 회 이상 반복될 수도 있다.
단계 3 에서, 타깃 디바이스는 최종 로케이션 정보를 전송하고 트랜잭션 T2 에 대한 트랜잭션 표시의 종단을 포함함으로써 절차의 종단을 나타낸다. 만약 로케이션 정보의 하나의 세트만이 전송되면, 단계 2 는 스킵될 수 있고 오직 단계 3 및 옵션적으로 단계 1 이 발생할 수 있다.
3GPP TS 36.355 에서의 LPP 규칙들은 도 6a 및 도 6b 에 도시된 바와 같이 동일한 절차의 모든 메시지들에서 동일한 트랜잭션 ID 의 사용을 요구하며 최종 메시지가 트랜잭션 표시자의 종단을 반송하도록 요구한다. 규칙들은 또한 한쪽 단이 도 6a 및 도 6b 에서의 단계 1 에서와 같이 전송될 데이터를 명시하지만 초기 요청이 일단 전송되었으면 데이터를 수정하기 위한 조항을 포함하지 않도록 허용한다. LPPe 메시지들은 LPP 절차들을 따르는 LPPe 절차들을 이용하여 LPP 메시지들 내부에서 반송되도록 요청되므로, 도 6a 및 도 6b 에 도시된 유형의 단일 LPP 절차를 단지 확장함으로써 로케이션 관련 데이터 이송을 수정할 직접적인 방법은 없다. 대신에, 다수의 LPP 절차들은 본원에서 개시된 바와 같이 사용될 수 있다.
일 양태는 (도 1 에서의 로케이션 서버 (26) 와 동일할 수도 있는) 서버 (302) 로부터 (도 1 에서의 모바일 디바이스 (16) 와 동일할 수도 있는) 모바일 디바이스와 같은 타깃 (301) 으로 주기적 또는 트리거된 어시스턴스 데이터를 전달하는 것을 지원하는 절차를 제공한다. 이 경우에서, 서버 (302) 는 미리 합의된 시간들에 (예를 들면, 고정된 주기적 시간 간격들로) 또는 서버 (302) 에서 특정 트리거 조건이 발생하면 (예를 들면, 새로운 어시스턴스 데이터가 가용해지거나 또는 이전에 전송된 어시스턴스 데이터가 무효화되면) 어시스턴스 데이터의 이전에 합의된 유형들을 타깃 (301) 으로 이송할 것이다. 전달 절차 동안에, 타깃 (301) 은 전달 중인 어시스턴스 데이터의 유형 및/또는 어시스턴스 데이터가 전송될 때 제어하는 주기적 또는 트리거링 파라미터들을 수정할 수도 있다.
도 3a 는 타깃 업데이트와 함께 예시적인 주기적 및/또는 트리거된 어시스턴스 데이터 이송에 대한 메시지 흐름도를 도시한다. 이 절차는 타깃 (301) 이 서버 (302) 에게 어시스턴스 데이터를 정의된 시간 간격들로 또는 특정 트리거링 기준이 충족되면 전송하도록 요청하는 것을 가능하게 한다. 이 절차는 또한 데이터 이송 세션이 진행되는 중에 타깃 (301) 이 어시스턴스 데이터의 유형 및/또는 주기성 및 트리거링 기준을 수정하도록 허용한다.
타임 1 에서, 타깃 (301) 은 가용 트랜잭션 ID T1 을 이용하여 LPP RequestAssistanceData 메시지를 서버 (302) 에 전송한다. 이 메시지는 절차의 동일한 유형의 임의의 다른 인스턴스에 대하여 타깃 (301) 과 서버 (302) 사이에 현재 사용되는 임의의 다른 LPPe 세션 ID 와는 상이한 세션 ID S 를 포함할 수도 있다. 이 메시지는 또한 요청되는 어시스턴스 데이터의 유형, 데이터를 전송하기 위한 트리거링 또는 주기성 조건들, 및 어시스턴스 데이터 이송을 종료하기 위한 지속시간 또는 다른 특정 조건(들) 중 어느 하나를 식별하는 LPPe 제어 파라미터들을 포함할 수도 있다. 타임 2 에서, 서버 (302) 는 LPP ProvideAssistanceData 메시지를 이용하여 타깃 (301) 에 응답한다. 이 메시지는 타임 1 로부터의 트랜잭션 ID T1 를 사용하며 이 트랜잭션의 종단을 나타낸다. 이 메시지는 세션 ID S 및 타임 1 에서 전송된 요청이 지원될 수 있는지의 여부를 나타내는 LPPe 제어 파라미터들을 포함한다. 만약 요청이 지원될 수 있다면, LPPe 제어 파라미터들은 어시스턴스 데이터의 유형 및 이 데이터를 전송하기 위한 조건들을 수정할 수도 있다. 예를 들면, 수정은 이송된 어시스턴스 데이터의 유형, 데이터를 이송하기 위한 트리거링 또는 주기성 파라미터들 및/또는 어시스턴스 데이터 이송을 종료하기 위한 지속시간 또는 다른 조건들을 확인 또는 재정의하는 것을 포함할 수도 있다. LPPe 제어 파라미터들은 또한 전달될 어시스턴스 데이터의 추가 특징들을 포함할 수도 있다. 단계 2 에서의 메시지는 단계 1 에서 시작된 (트랜잭션이라고도 알려진) LPP 절차를 종료하며 3GPP TS 36.355 에서의 LPP 규칙들을 따른다 (예를 들면, 도 6a 에서의 단계 1 및 단계 3 에 대응한다). 절차는 후속 단계들에서 어떤 어시스턴스 데이터가 이송될 것인지를 확립하지만 실제로는 임의의 어시스턴스 데이터를 이송하지 않으므로, 이 절차는 제어 트랜잭션 또는 제어 절차라고 지칭될 수도 있다.
타임 3 에서, 제 1 트리거링 또는 주기성 조건(들) 이 발생하면, 서버 (302) 는 세션 ID S, 및 타임 2 또는 타임 1 에서 확인 또는 정의된 어시스턴스 데이터를 포함하는 LPPe 데이터 파라미터들을 포함하는 비응답형 LPP ProvideAssistanceData 메시지를 타깃 (301) 으로 전송한다. 이 메시지는 T1 과는 상이할 수도 있는 가용 트랜잭션 ID T2 를 사용한다. 이 절차에 적용가능한 LPPe 제어 파라미터들 및 LPPe 데이터 파라미터들은 서로 구별가능하다. 세션 ID S 는 어시스턴스 데이터가 단계 1 및 단계 2 에서 합의된 것들에 대응한다는 것을 타깃 (301) 에 확인한다.
타임 4 에서, 서버 (302) 는 각각의 부가적인 트리거링 또는 주기성 조건 (들) 이 발생하였을 때 타임 2 또는 타임 1 에서 확인 또는 재정의된 어시스턴스 데이터를 포함하는 추가의 LPP ProvideAssistanceData 메시지들을 타깃 (301) 으로 전송하는 것을 계속할 수도 있다. 만약 어시스턴스 데이터 이송을 종료하기 위한 지속시간 또는 다른 조건들이 발생하면, 이송된 마지막 ProvideAssistanceData 메시지는 트랜잭션 T2 의 종단을 나타내며 타임 5 내지 타임 8 에서 발생하는 트랜잭션들은 생략된다. 이 경우에서, 절차 (또는 트랜잭션) 는 3GPP TS 36.355 에서의 LPP 에 대한 규칙들에 따라서 종료된다 (예를 들면, 어시스턴스 데이터의 비응답형 이송에 대한 도 6a 에서의 단계 2 및 단계 3 에 대응한다). 이 경우에서, 절차는 어시스턴스 데이터를 이송하지만 이 어시스턴스 데이터의 콘텐츠를 협상 또는 수정하지는 않으므로, 이 절차는 데이터 트랜잭션 또는 데이터 절차라고 지칭될 수도 있다.
어시스턴스 데이터의 전달이 종료되기 전에, 타깃 (301) 은 가용 트랜잭션 ID T3 을 이용하여 타임 5 에서 LPP RequestAssistanceData 메시지를 서버 (302) 로 전송함으로써 어시스턴스 데이터의 유형 및/또는 트리거링 및 주기성 조건들 및/또는 종료를 위한 지속시간 또는 조건(들)을 업데이트할 수도 있다. ID T3 는 T2 와는 상이하다. 이 메시지는 세션 ID S, 및 요청되는 어시스턴스 데이터의 임의의 새로운 유형, 이 데이터를 전송하기 위한 임의의 새로운 트리거링 또는 주기성 조건들 및 어시스턴스 데이터 이송을 종료하기 위한 임의의 새로운 지속시간 또는 특정 조건들을 식별하는 LPPe 제어 파라미터들을 포함한다. 제어 파라미터들은 또한 만약 새로운 요청이 지원될 수 없다면 이전의 어시스턴스 데이터 전달이 계속되어야 하는지 (디폴트) 또는 중단되어야 하는지를 나타낼 수도 있다. 세션 ID S 를 포함하는 것은 서버 (302) 에게 새로운 요청이 단계 1 내지 단계 4 의 어시스턴스 데이터 이송에 관련된다는 것을 알려준다. 단계 5 에서의 요청이 타깃 (301) 과 서버 (302) 양쪽 모두에 의해 단계 3 및 단계 4 와 연관된 것과는 상이한 LPP 절차 (상이한 트랜잭션) 에 속한 것으로서 보여지기 때문에, T2 와 상이한 트랜잭션 ID T3 의 사용은 LPP 프로토콜 위반을 방지한다. 트랜잭션 ID T3 이 T2 와 동일하였다면, 프로토콜 위반이 있었을 것이며 서버 (302) 는 이송을 중단할 수도 있었을 것이다.
타임 6 에서, 서버 (302) 는 LPP ProvideAssistanceData 메시지를 이용하여 타깃 (301) 에 응답한다. 이 메시지는 트랜잭션 ID T3 을 사용하며 이 트랜잭션의 종단을 나타낸다. 이 메시지는 타임 5 에서의 수정된 요청이 지원될 수 있는지의 여부를 나타내는 LPPe 제어 파라미터들을 포함한다. 만약 요청이 지원될 수 있다면, 제어 파라미터들은 어시스턴스 데이터의 임의의 새로운 유형, 임의의 새로운 트리거링 또는 주기성 파라미터들, 및 어시스턴스 데이터 이송을 종료하기 위한 임의의 새로운 지속시간 또는 다른 조건(들)을 명백하게 확인 또는 재정의할 수도 있다. 전달될 어시스턴스 데이터의 추가 특징들은 또한 LPPe 제어 파라미터들에서 제공될 수도 있다. 만약 타임 5 에서의 요청이 지원될 수 없다면, 그렇다면, 타임 5 에서 달리 요청되지 않는 한, 타임 1 에서의 초기 요청은, 데이터 이송 세션이 정상적으로 종료되거나 타임 5 에서 발생하는 요청의 반복에 의해 수정되거나 타깃 (301) 에 의해 중단될 때까지, 타임 4 에서 발생하는 트랜잭션의 추가 반복들을 통하여 계속될 것이다. 만약 타임 5 에서 달리 요청되면, (트랜잭션 T2 를 포함하는) 초기 요청은 임의의 추가 어시스턴스 데이터를 타깃 (301) 으로 전송하는 일 없이 서버 (302) 에서 중단된다. 어떠한 경우에도, 타임 7 및 타임 8 에서 발생하는 트랜잭션들은 그런 다음 생략된다. (단계 6 에서 트랜잭션 표시자의 종단이 서버 (302) 에 의해 포함되었기 때문에) 단계 5 및 단계 6 과 연관된 절차는 그런 다음 종료되고 3GPP TS 36.355 에서의 LPP 절차 규칙을 따른다 (예를 들면, 도 6a 에서의 단계 1 및 단계 3 에 대응한다). 절차는 이송되는 어시스턴스 데이터를 수정하지만 실제로 임의의 어시스턴스 데이터를 이송하지 않으므로, 이 절차는 제어 트랜잭션 또는 제어 절차라고 지칭될 수도 있다.
타임 7 에서, 만약 서버 (302) 가 타임 5 에서 발생하는 요청을 지원할 수 있다면, 서버 (302) 는 타임 1 에서의 요청을 지원하는 것을 멈춘다. 레이스 (race) 조건들로 인하여, 타임 4 에서 발생하는 메시지의 일 회 이상의 반복들은 타깃 (301) 에 의해 타임 5 에 뒤이어 그리고 타임 6 이전에 발생한 것으로 인지될 수도 있다. 타임 6 에 뒤이어 제 1 업데이트된 트리거링 또는 주기성 조건(들) 이 발생하면, 서버 (302) 는 세션 ID S, 및 타임 6 또는 타임 5 에서 확인 또는 정의된 새로운 어시스턴스 데이터를 포함하는 LPPe 데이터 파라미터들을 포함하는 비응답형 LPP ProvideAssistanceData 메시지를 타깃 (301) 으로 전송한다. 이 메시지는 트랜잭션 ID T2 를 계속하여 사용하며 이것은 어시스턴스 데이터의 이송에 대한 LPP 절차를 방해하는 것 (예를 들면, 위반하는 것) 을 방지한다. 타깃 (301) 은 단계 6 에서의 LPP 메시지가 언제 수신되었는지에 따라서 어시스턴스 데이터 이송을 서버 (302) 가 언제 변경했는지를 결정할 수 있다. (3GPP TS 35.355에서 LPP 에 대한 요건인) 서버 (302) 에 의해 전송된 순서로 LPP 메시지들이 타깃 (301) 으로 전달되었다면, 단계 4 의 모든 인스턴스들은 단계 6 이 발생하기 전에 멈출 것이며 단계 7 은 단계 6 이 발생한 후에 발생할 것이다. 이것은 어시스턴스 데이터 이송에 대한 변경들이 발생하였다는 것을 구체적으로 나타내기 위하여 단계 7 에서 LPP 메시지에 임의의 것을 포함해야 할 필요성을 방지하며 이것은 LPP 및 LPPe 메시지 콘텐츠를 단순화한다.
타임 8 에서, 각각의 부가적 트리거링 또는 주기성 조건(들) 이 발생하면 서버 (302) 는 세션 ID S, 및 타임 6 또는 타임 5 에서 확인 또는 재정의된 새로운 어시스턴스 데이터를 포함하는 LPPe 데이터 파라미터들을 포함하는 부가적 LPP ProvideAssistanceData 메시지들을 타깃 (301) 으로 전송하는 것을 계속할 수도 있다. 만약 어시스턴스 데이터 이송을 종료하기 위한 지속시간 또는 다른 조건들이 발생하면, 이송된 마지막 LPP ProvideAssistanceData 메시지는 트랜잭션 T2 의 종단을 나타낸다. 트랜잭션의 종단 이전에, 타깃 (301) 은 어시스턴스 데이터의 유형, 트리거링 또는 주기성 조건들 및/또는 이송을 종료하기 위한 지속시간 또는 다른 조건들을 업데이트할 수도 있으며, 타임 5 및 타임 6 에서 발생하는 트랜잭션들은 반복된다. 트랜잭션 식별자의 종단을 포함하는 것에 의한 단계 8 에서의 절차의 종료는 LPP 절차 규칙들을 따른다 (예를 들면, 단계 8 은 도 6a 에서의 단계 3 에 대응한다). 게다가, 단계 3, 단계 4, 단계 7 및 단계 8 에서의 어시스턴스 데이터의 완전한 이송은 도 6a 의 단계 2 및 단계 3 에서 도시된 바와 같은 어시스턴스 데이터의 정상적 비응답형 LPP 이송에 대응한다. 이 단계들은 어시스턴스 데이터를 이송하지만 이 어시스턴스 데이터의 콘텐츠를 정의하거나 수정하지는 않으므로, 이 단계들은 데이터 트랜잭션 또는 데이터 절차라고 지칭될 수도 있다.
위의 설명으로부터, 도 3a 에서의 전체 절차는 3 개의 별도의 더 작은 LPP 절차들 또는 트랜잭션들: 이송될 어시스턴스 데이터를 정의 및 합의하기 위한 단계 1 및 단계 2 에서의 제어 트랜잭션, 이송될 어시스턴스 데이터를 수정하기 위한 단계 5 및 단계 6 에서의 또 다른 제어 트랜잭션, 및 어시스턴스 데이터를 이송하기 위한 단계 3, 단계 4, 단계 7 및 단계 8 에서의 데이터 트랜잭션으로 이루어졌다는 것을 알 수도 있다. 이러한 더 작은 절차들 (또는 트랜잭션들) 은 3GPP TS 36.355 에서의 LPP 규칙들을 따르며 이렇게 하여 전체 복합 절차들이 또한 LPP 를 따르도록 한다.
도 3b 는 도 3a 의 어시스턴스 데이터 이송 세션이 어떻게 개시되고 종료되는지를 도시한 메시지 흐름도이다. 타임 1 에서, 타깃 (301) 은 가용한 트랜잭션 ID T1 을 사용하여 서버 (302) 로 LPP RequestAssistanceData 메시지를 전송한다. 이 메시지는 동일한 유형의 절차의 임의의 다른 인스턴스에 대하여 타깃 (301) 과 서버 (302) 사이에 현재 사용 중인 임의의 다른 LPPe 세션 ID 와는 상이한 세션 ID S 를 포함한다. 이 메시지는 메시지가 주기적/트리거된 어시스턴스 데이터 이송에 대한 초기 요청이라는 표시를 포함한다. 이 메시지는 또한 요청되는 어시스턴스 데이터의 유형, 데이터를 전송하기 위한 트리거링 또는 주기성 조건들, 및 어시스턴스 데이터 이송을 종료하기 위한 지속시간 또는 다른 특정 조건(들) 중 어느 하나를 식별하는 LPPe 제어 파라미터들을 포함한다.
타임 2 에서, 서버 (302) 는 LPP ProvideAssistanceData 메시지를 이용하여 타깃 (301) 에 응답한다. 이 메시지는 타임 1 에서 트랜잭션 ID T1 을 사용하고 이 트랜잭션의 종단을 나타낸다. 이 메시지는 세션 ID S, 메시지가 초기 요청에 대한 응답이라는 표시, 및 LPPe 제어 파라미터들을 포함한다. LPPe 제어 파라미터들은 타임 1 에서 발생하는 요청이 지원될 수 있는지의 여부를 나타낸다. 만약 요청이 지원될 수 있다면, LPPe 제어 파라미터들은 어시스턴스 데이터의 유형, 트리거링 또는 주기성 파라미터들, 및 어시스턴스 데이터 이송을 종료하기 위한 지속시간 또는 다른 조건(들)을 확인 또는 재정의할 수도 있다. 전달될 어시스턴스 데이터의 추가 특징들이 또한 LPPe 제어 파라미터들에 제공될 수도 있다. 만약 절차가 지원될 수 없다면, 에러 사유는 LPPe 레벨에서 제공되고 도 3b 에서의 타임 3 내지 타임 7 에서 발생하는 트랜잭션들은 수행되지 않는다. 단계 1 및 단계 2 에서의 메시지들은 3GPP TS 36.355 에서의 LPP 에 대한 규칙들에 따른 단일 LPP 절차 (또는 트랜잭션) 를 포함한다 (예를 들면, 도 6a 에서의 단계 1 및 단계 3 에 대응한다). 절차는 후속 단계들에서 어떤 어시스턴스 데이터가 이송될 것인지를 확립하지만 실제로 임의의 어시스턴스 데이터를 이송하지 않으므로, 이 절차는 제어 트랜잭션 또는 제어 절차라고 지칭될 수도 있다.
제 1 트리거링 또는 주기성 조건(들)이 발생하면, 타임 3 에서 서버 (302) 는 비응답형 LPP ProvideAssistanceData 메시지를 타깃 (301) 으로 전송한다. 이 메시지는 세션 ID S, 트랜잭션이 주기적/트리거된 어시스턴스 데이터 전달이라는 표시, 및 타임 2 또는 타임 1 에서 확인 또는 정의된 어시스턴스 데이터를 포함하는 LPPe 데이터 파라미터들을 포함한다. 이 메시지는 T1 과는 상이할 수도 있는 일부 가용한 트랜잭션 ID T2 를 사용한다. 이 절차에 적용가능한 LPPe 제어 파라미터들 및 LPPe 데이터 파라미터들은 서로 구별가능하다. 단계 1 및 단계 2 와 동일한 세션 ID S 를 포함하는 것은 타깃 (301) 에게 메시지가 단계 1 및 단계 2 에서 합의된 어시스턴스 데이터 이송에 관련된다는 것을 알려준다. 새로운 절차의 일부로서 메시지를 전송하는 것은 LPP 프로토콜 규칙들을 위반하는 것을 방지한다.
타임 4 에서, 서버 (302) 는 추가 LPP ProvideAssistanceData 메시지들을 타깃 (301) 으로 전송하는 것을 계속할 수도 있다. 메시지들은 각각의 부가 트리거링 또는 주기성 조건(들)이 발생하면 타임 2 에서 확인 또는 재정의되는 어시스턴스 데이터를 포함한다. 메시지들은 또한 단계 3 에서와 동일한 트랜잭션 ID T2 및 세션 ID S 를 포함하며, 따라서 타깃 (301) 에 의해 단계 3 과 연관된 절차의 연속으로서 보여진다.
만약 세션이 종료되도록 하는 에러 조건(들)이 타깃 (301) 에서 발생하면, 타깃 (301) 은, 타임 5 에서, 옵션적으로 LPP 및/또는 LPPe 에러 코드들을 포함할 수도 있는 트랜잭션 T2 에 대한 LPP Abort 를 서버 (302) 에 전송한다. 부가적으로, 만약 세션이 종료되면, 도 3b 에서 타임 6 및 타임 7 에서 발생하는 트랜잭션들은 그런 다음 생략된다. 중단을 유도할 수도 있는 에러 조건들은 서버 (302) 에 의해 제공된 최종 제어 파라미터들이 타깃 (301) 에 허용될 수 없는 어시스턴스 데이터 이송을 업데이트하기 위한, 타깃 (301) 또는 서버 (302) 중 어느 하나에 의한 시도를 포함할 수도 있다.
만약 추가 어시스턴스 데이터의 전달 없이 세션이 종료되도록 하는 에러 조건이 서버 (302) 에서 발생하면, 서버 (302) 는, 타임 6 에서, 옵션적으로 LPP 및/또는 LPPe 에러 코드들을 포함할 수도 있는 트랜잭션 T2 에 대한 LPP Abort 를 타깃 (301) 에 전송한다. 도 3b 에서의 타임 7 에서 발생하는 트랜잭션들은 그런 다음 생략된다. 단계 5 또는 단계 6 에서의 LPP Abort 메시지의 전송은 3GPP TS 36.355 에서의 LPP 규칙들에 의해 허용되고 따라서 LPP 와 일치한다. 단계 5 또는 단계 6 에서의 LPP Abort 메시지는 트랜잭션 ID T2 를 반송하며 따라서 단계 3 및 단계 4 와 연관된 트랜잭션의 일부 (및 종단) 로서 보여진다는 것에 유의한다.
어시스턴스 데이터 이송을 종료하기 위한 지속시간 또는 다른 조건(들)이 발생하면, 마지막 LPP ProvideAssistanceData 메시지는 타임 7 에서 전송된다. 이 메시지는 트랜잭션 T2 의 종단을 나타낸다. 일 양태에서, 어시스턴스 데이터 이송에 특정한 부가 종료 정보는 그런 다음 포함될 수도 있기 때문에, 가능하다면 이송을 중단하는 것보다는 이송을 종료하는 것이 사용된다. 단계 3, 단계 4 및 단계 7 에서의 어시스턴스 데이터의 완전한 이송은 도 6a 의 단계 2 및 단계 3 에서 도시한 바와 같은 어시스턴스 데이터의 정상적 비응답형 LPP 이송에 대응한다. 이 단계들은 어시스턴스 데이터를 이송하지만 이 어시스턴스 데이터의 콘텐츠를 정의하거나 수정하지는 않으므로, 이 단계들은 데이터 트랜잭션 또는 데이터 절차라고 지칭될 수도 있다.
위의 설명으로부터, 도 3b 에서의 전체 절차는 2 개의 별도의 더 작은 LPP 절차들 또는 트랜잭션들: 이송될 어시스턴스 데이터를 정의 및 합의하기 위한 단계 1 및 단계 2 에서의 제어 트랜잭션, 및 어시스턴스 데이터를 이송하기 위한 단계 3, 단계 4, 및 단계 7 에서의 데이터 트랜잭션으로 이루어졌다는 것을 알 수도 있다. 이 더 작은 절차들 (또는 트랜잭션들) 은 3GPP TS 36.355 에서의 LPP 규칙들을 따르며 이렇게 하여 전체 복합 절차들이 또한 LPP 를 따르도록 한다.
도 3c 는 타깃 (301) 이 도 3b 에 따라서 도시된 진행중인 주기적/트리거된 어시스턴스 데이터 이송을 어떻게 업데이트할 수도 있는지를 도시한 호 흐름도이다. 타임 1 에서, 도 3b 의 단계 1 및 단계 2 에서와 같이 LPPe 주기적/트리거된 어시스턴스 데이터 이송 절차는 업데이트와 함께 제어 트랜잭션 또는 제어 절차를 이용하여 개시된다. 타임 2 에서, 서버 (302) 는 타임 1 에서 합의된 어시스턴스 데이터를 포함하고 트랜잭션 ID T2 를 사용하는 0, 하나 또는 그 이상의 LPP ProvideAssistanceData 메시지들을 타깃 (301) 으로 전송할 수도 있다.
타깃 (301) 은 어시스턴스 데이터의 전달이 종료되기 전에 어시스턴스 데이터를 수정할 수도 있다. 타깃 (301) 은, 타임 3 에서, 가용한 트랜잭션 ID T3 을 사용하는 LPP RequestAssistanceData 메시지를 서버 (302) 로 전송한다. ID T3 는 (만약 T2 이 시작되었다면) T2 와는 상이하다. 어시스턴스 데이터의 수정은 이송된 어시스턴스 데이터의 유형, 어시스턴스 데이터를 이송하기 위한 트리거링 및 주기성 조건들, 및/또는 이송 세션을 종료하기 위한 지속시간 또는 조건들을 업데이트하는 것을 포함할 수도 있다. 타임 3 에서 전송된 요청은 세션 ID S, 이 요청이 주기적/트리거된 어시스턴스 데이터 이송에 대한 업데이트 요청이라는 표시, 및 LPPe 제어 파라미터들을 포함한다. LPPe 제어 파라미터들은 요청되는 어시스턴스 데이터의 임의의 새로운 유형, 데이터를 전송하기 위한 임의의 새로운 트리거링 또는 주기성 조건(들), 및 어시스턴스 데이터 이송을 종료하기 위한 임의의 새로운 지속시간 또는 특정 조건(들)을 식별한다. 만약 새로운 요청이 지원될 수 없다면, 요청은 또한 이전의 어시스턴스 데이터 전달이 계속되어야 할 것인지 또는 중단되어야 할 것인지를 나타낸다.
타임 4 에서, 서버 (302) 는 LPP ProvideAssistanceData 메시지를 이용하여 타깃 (301) 에 응답한다. 이 메시지는 트랜잭션 ID T3 을 사용하며 이 트랜잭션의 종단을 나타낸다. 이 메시지는 세션 ID S, 및 메시지가 업데이트 요청에 대한 응답이라는 표시를 포함한다. 이 메시지는 또한 타임 3 에서의 업데이트 요청이 지원될 수 있는지의 여부를 나타내는 LPPe 제어 파라미터들을 포함한다. 만약 요청이 지원될 수 있다면, 제어 파라미터들은 어시스턴스 데이터의 임의의 새로운 유형, 임의의 새로운 트리거링 또는 주기성 파라미터들, 및 어시스턴스 데이터 이송을 종료하기 위한 임의의 새로운 지속시간 또는 다른 조건(들)을 명백하게 확인 또는 재정의할 수도 있다. 전달될 어시스턴스 데이터의 추가 특징들은 또한 이 메시지에서 제공될 수도 있다. 만약 타임 3 에서의 요청이 지원될 수 없다면, 그렇다면, 만약 타임 3 에서 요청되면, 타임 1 에서 합의된 초기 요청은 그것이 정상적으로 종료될 때까지 타임 2 에서 발생한 트랜잭션들의 추가 반복들을 통하여 계속되거나, 타임 3 에서 발생한 트랜잭션의 반복에 의해 수정되거나, 또는 중단된다. 타임 3 에서 달리 요청되면, (트랜잭션 T2 를 포함한) 초기 요청은 임의의 추가 어시스턴스 데이터를 타깃 (301) 에 전송하는 일 없이 서버 (302) 에서 중단될 것이다. 어떤 경우에도, 트랜잭션들은 타임 5 및 타임 6 에 대한 개요를 서술하며, 그런 다음 생략된다. (단계 4 에서 트랜잭션 표시자의 종단은 서버 (302) 에 의해 포함되기 때문에) 단계 3 및 단계 4 와 연관된 절차는 그런 다음 종료되고 3GPP TS 36.355 에서의 LPP 절차 규칙들을 따른다 (예를 들면, 도 6a 에서의 단계 1 및 단계 3 에 대응한다). 절차는 이송되는 어시스턴스 데이터를 수정하지만 실제로 임의의 어시스턴스 데이터를 이송하지 않으므로, 이 절차는 제어 트랜잭션 또는 제어 절차라고 지칭될 수도 있다.
만약 서버 (302) 가 타임 3 에서의 요청을 지원할 수 있다면, 서버 (302) 는 타임 1 에서의 요청을 지원하는 것을 멈춘다. 레이스 조건들로 인하여, 타임 2 에서 발생하는 트랜잭션의 일 회 이상의 반복들은 타깃 (301) 에 의해 타임 3 에 뒤이어 그리고 타임 4 이전에 발생한 것으로 인지될 수도 있다는 것에 유의한다. 타임 4 에 뒤이어 제 1 업데이트된 트리거링 또는 주기성 조건(들) 이 발생하면, 서버 (302) 는, 타임 5 에서, 세션 ID S, 이것이 주기적/트리거된 어시스턴스 데이터라는 표시 및 LPPe 데이터 파라미터들을 포함하는 비응답형 LPP ProvideAssistanceData 메시지를 타깃 (301) 으로 전송한다. LPPE 데이터 파라미터들은 타임 4 에서 확인 또는 정의된 새로운 어시스턴스 데이터를 포함한다. 이 메시지는 트랜잭션 ID T2 를 계속 사용하며 이것은 어시스턴스 데이터의 이송에 대한 LPP 절차를 방해하는 것 (예를 들면, 위반하는 것) 을 방지한다. 타깃 (301) 은 단계 4 에서 LPP 메시지가 언제 수신되었는지에 따라서 어시스턴스 데이터 이송을 서버 (302) 가 언제 변경했는지를 결정할 수 있다. (3GPP TS 35.355에서 LPP 에 대한 요건인) 서버 (302) 에 의해 전송된 순서로 LPP 메시지들이 타깃 (301) 으로 전달되었다면, 단계 2 의 모든 인스턴스들은 단계 4 가 발생하기 전에 멈출 것이며 단계 5 는 단계 4 가 발생한 후에 발생할 것이다. 이것은 어시스턴스 데이터 이송에 대한 변경들이 발생하였다는 것을 구체적으로 나타내기 위하여 단계 5 에서 LPP 메시지에 임의의 것을 포함해야 할 필요성을 방지하며 이것은 LPP 및 LPPe 메시지 콘텐츠를 단순화한다.
타임 6 에서, 각각의 부가적 트리거링 또는 주기성 조건(들) 이 발생하면 서버 (302) 는 세션 ID S, 및 타임 4 또는 타임 3 에서 확인 또는 재정의된 새로운 어시스턴스 데이터를 포함하는 LPPe 데이터 파라미터들을 포함하는 추가 LPP ProvideAssistanceData 메시지들을 타깃 (301) 으로 전송하는 것을 계속할 수도 있다. 만약 어시스턴스 데이터 이송을 종료하기 위한 지속시간 또는 다른 조건들이 발생하면, 이송된 마지막 LPP ProvideAssistanceData 메시지는 트랜잭션 T2 의 종단을 나타낸다. 트랜잭션의 종단 이전에, 타깃 (301) 은 타임 3 및 타임 4 에서 발생하는 트랜잭션을 반복함으로써 어시스턴스 데이터의 유형, 트리거링 또는 주기성 조건(들) 및/또는 이송을 종료하기 위한 지속시간 또는 다른 조건들을 업데이트할 수도 있다. 트랜잭션 식별자의 종단을 포함하는 것에 의한 단계 6 에서의 절차의 종료는 LPP 절차 규칙들을 따른다 - 예를 들면, 단계 6 은 도 6a 에서의 단계 3 에 대응한다. 게다가, 단계 2, 단계 5, 및 단계 6 에서의 어시스턴스 데이터의 완전한 이송은 도 6a 의 단계 2 및 단계 3 에서 설명된 바와 같은 어시스턴스 데이터의 정상적 비응답형 LPP 이송에 대응한다. 이 단계들은 어시스턴스 데이터를 이송하지만 이 어시스턴스 데이터의 콘텐츠를 정의하거나 수정하지는 않으므로, 이 단계들은 데이터 트랜잭션 또는 데이터 절차라고 지칭될 수도 있다.
위의 설명으로부터, 도 3c 에서의 전체 절차는 3 개의 별도의 더 작은 LPP 절차들 또는 트랜잭션들 - 이송될 어시스턴스 데이터를 정의 및 합의하기 위한 단계 1 에서의 제어 트랜잭션, 타깃 (301) 이 이송되는 어시스턴스 데이터를 수정하도록 하기 위한 단계 3 및 단계 4 에서의 또 다른 제어 트랜잭션, 및 어시스턴스 데이터를 이송하기 위한 단계 2, 단계 5, 및 단계 6 에서의 데이터 트랜잭션으로 이루어졌다는 것을 알 수도 있다. 이러한 더 작은 절차들 (또는 트랜잭션들) 은 3GPP TS 36.355 에서의 LPP 규칙들을 따르며 이렇게 하여 전체 복합 절차들이 또한 LPP 를 따르도록 한다.
도 3d 는 서버 (302) 가 도 3b 에 따라서 개시된 진행중인 주기적/트리거된 어시스턴스 데이터 이송을 어떻게 업데이트할 수도 있는지를 도시한 호 흐름도이다. 타임 1 에서, 주기적/트리거된 어시스턴스 데이터 이송 세션은 도 3b 에서의 단계 1 및 단계 2 에서와 같이 제어 트랜잭션 또는 제어 절차를 이용하여 개시된다. 타임 2 에서, 서버 (302) 는 타임 1 에서 합의된 어시스턴스 데이터를 포함하고 트랜잭션 ID T2 를 사용하는 0, 하나 또는 그 이상의 LPP ProvideAssistanceData 메시지들을 타깃 (301) 으로 전송할 수도 있다.
서버 (302) 는 일부 가용한 트랜잭션 ID T3 을 사용하여 비응답형 LPP ProvideAssistanceData 메시지를 타깃 (301) 으로 전송함으로써, 어시스턴스 데이터의 전달이 종료되기 전에, 서버 (302) 가 어시스턴스 데이터를 수정할 것이라는 것을 나타낼 수도 있다. ID T3 은 T2 와는 상이할 것이다. 어시스턴스 데이터의 수정은 이송될 어시스턴스 데이터의 유형, 데이터를 이송하기 위한 트리거링 및 주기성 조건들, 및/또는 이송 세션을 종료하기 위한 지속시간 또는 조건들을 업데이트하는 것을 포함한다. 타임 3 에서 전송된 메시지는 단계 1 및 단계 2 에서 사용된 세션 ID S, 이 메시지가 주기적/트리거링된 어시스턴스 데이터 이송에 대한 서버 업데이트라는 표시, 및 LPPe 제어 파라미터들을 포함한다. LPPe 제어 파라미터들은 제공될 어시스턴스 데이터의 임의의 새로운 유형, 이 데이터를 전송하기 위한 임의의 새로운 트리거링 또는 주기성 조건들 및 어시스턴스 데이터 이송을 종료하기 위한 임의의 새로운 지속시간 또는 특정 조건들을 식별한다. 이 메시지를 전송한 후에, 서버 (302) 는 타임 1 에서의 합의에 따른 어시스턴스 데이터의 이송을 멈춘다. 세션 ID S 의 포함은 타깃 (301) 에게 새로운 요청이 단계 1 및 단계 2 의 어시스턴스 데이터 이송에 관련된 것이라는 것을 알려준다. 단계 3 에서의 요청이 타깃 (301) 과 서버 (302) 양쪽 모두에 의해 단계 2 와 연관된 것과는 상이한 절차 (상이한 트랜잭션) 에 속한 것으로서 보여지기 때문에, T2 와 상이한 트랜잭션 ID T3 의 사용은 LPP 프로토콜 위반을 방지한다. 트랜잭션 ID T3 이 T2 와 동일하였다면, 프로토콜 위반이 있었을 것이며 타깃 (301) 은 이송을 중단할 수도 있었을 것이다. 단계 3 은 또한 3GPP TS 36.355 에서의 LPP 절차 규칙들을 따른다 (예를 들면, 어시스턴스 데이터의 단일 비응답형 이송에 대하여 도 6a 에서의 단계 3 에 대응한다). 그러나 절차는 실제로 이송되는 어시스턴스 데이터를 수정하지만 임의의 실제 어시스턴스 데이터를 이송하지는 않으므로, 이 절차는 제어 트랜잭션 또는 제어 절차라고 지칭될 수도 있다.
타임 4 및 타임 5 에서, (타임 3 에서 정의된 바와 같이) 제 1 업데이트된 트리거링 또는 주기성 조건(들) 이 발생하면, 서버 (302) 는 세션 ID S, 이 메시지가 주기적/트리거된 어시스턴스 데이터라는 표시, 및 타임 3 에서 정의된 새로운 어시스턴스 데이터를 포함하는 LPPe 데이터 파라미터들을 포함하는 비응답형 LPP ProvideAssistanceData 메시지를 타깃 (301) 으로 전송한다. 이 메시지는 계속해서 트랜잭션 ID T2 를 사용하며 이것은 어시스턴스 데이터의 이송에 대한 LPP 절차를 방해하는 것 (예를 들면, 위반하는 것) 을 방지한다. 타깃 (301) 은 단계 4 에서의 LPP 메시지가 언제 수신되었는지에 따라서 어시스턴스 데이터 이송을 서버 (302) 가 언제 변경했는지를 결정할 수 있다. (3GPP TS 36.355에서 LPP 에 대한 요건인) 서버 (302) 에 의해 전송된 순서로 LPP 메시지들이 타깃 (301) 으로 전달되었다면, 단계 2 의 모든 인스턴스들은 단계 3 이 발생하기 전에 멈출 것이며 단계 4 는 단계 3 이 발생한 후에 발생할 것이다. 이것은 어시스턴스 데이터 이송에 대한 변경들이 발생하였다는 것을 구체적으로 나타내기 위하여 단계 4 에서 LPP 메시지에 임의의 것을 포함해야 할 필요성을 방지하며 이것은 LPP 및 LPPe 메시지 콘텐츠를 단순화한다.
서버 (302) 는 각각의 부가적인 트리거링 또는 주기성 조건 (들) 이 발생하였을 때 세션 ID S 및 타임 3 에서 정의된 새로운 어시스턴스 데이터를 포함하는 LPPe 데이터 파라미터들을 포함하는 추가의 LPP ProvideAssistanceData 메시지들을 타깃 (301) 으로 전송하는 것을 계속할 수도 있다. 만약 어시스턴스 데이터 이송을 종료하기 위한 지속시간 또는 다른 조건들이 발생하면, 이송된 마지막 LPP ProvideAssistanceData 메시지는 트랜잭션 T2 의 종단을 나타낸다. 서버 (302) 는 타임 3 에서 발생하는 트랜잭션을 반복함으로써 어시스턴스 데이터의 유형, 트리거링 또는 주기성 조건들 및/또는 이송을 종료하기 위한 지속시간 또는 다른 조건들을 업데이트할 수도 있다. 트랜잭션 식별자의 종단을 포함하는 것에 의한 단계 5 에서의 절차의 종료는 LPP 절차 규칙들을 따른다 (예를 들면, 단계 5 는 도 6a 에서의 단계 3 에 대응한다). 게다가, 단계 2, 단계 4, 및 단계 5 에서의 어시스턴스 데이터의 완전한 이송은 도 6a 의 단계 2 및 단계 3 에서 도시된 바와 같은 어시스턴스 데이터의 정상적 비응답형 LPP 이송에 대응한다. 이 단계들은 어시스턴스 데이터를 이송하지만 이 어시스턴스 데이터의 콘텐츠를 정의하거나 수정하지는 않으므로, 이 단계들은 데이터 트랜잭션 또는 데이터 절차라고 지칭될 수도 있다.
위의 설명으로부터, 도 3d 에서의 전체 절차는 3 개의 별도의 더 작은 LPP 절차들 또는 트랜잭션들: 이송될 어시스턴스 데이터를 정의 및 합의하기 위한 단계 1 에서의 제어 트랜잭션, 서버 (302) 가 이송되는 어시스턴스 데이터를 수정하도록 하기 위한 단계 3 에서의 또 다른 제어 트랜잭션, 및 어시스턴스 데이터를 이송하기 위한 단계 2, 단계 4, 및 단계 5 에서의 데이터 트랜잭션으로 이루어졌다는 것을 알 수도 있다. 이러한 더 작은 절차들 (또는 트랜잭션들) 은 3GPP TS 36.355 에서의 LPP 규칙들을 따르며 이렇게 하여 전체 복합 절차가 또한 LPP 를 따르도록 한다.
다른 양태는 주기적 또는 트리거된 로케이션 정보를 타깃으로부터 서버 (302) 로 전달하는 것을 지원하는 절차를 제공하며 여기에서 서버 (302) 는 전달 절차 동안에 전달되는 (또한 로케이션 측정 정보라고도 지칭되는) 로케이션 정보의 유형 및/또는 주기적 또는 트리거링 파라미터들을 수정하도록 허용된다. 로케이션 정보는 GPS 또는 GNSS 위성들의 측정치들, 서빙 네트워크 또는 다른 네트워크들 내의 인근 기지국들에 의해 송신된 신호들의 측정치들 및 타깃 (301) 에 의해 계산되었다면 로케이션 좌표뿐만 아니라 다른 정보를 포함할 수도 있다. 도 4a 는 서버 업데이트와 함께 예시적인 주기적/트리거된 로케이션 정보 이송에 대한 호 흐름도를 도시한다. 이 절차는 정의된 시간간격들로 주기적으로 또는 특정 트리거링 기준이 충족되면 로케이션 정보를 전송할 것을 서버 (302) 가 타깃 (301) 에게 요청하도록 한다. 절차는 또한 전달 절차가 진행되는 중에 서버 (302) 가 로케이션 정보의 유형 및/또는 주기성 및 트리거링 기준을 수정하도록 허용한다.
타임 1 에서, 서버 (302) 는 가용한 트랜잭션 ID T1 을 이용하여 LPP RequestLocationInformation 메시지를 타깃 (301) 으로 전송한다. 이 메시지는 절차의 동일한 유형의 임의의 다른 인스턴스에 대하여 타깃 (301) 과 서버 (302) 사이에서 현재 사용 중인 임의의 다른 LPPe 세션 ID 와는 상이한 세션 ID S 를 포함할 수도 있다. 이 메시지는 또한 요청된 로케이션 정보의 유형, 이 정보를 전송하기 위한 트리거링 또는 주기성 조건(들), 및 로케이션 정보 이송을 종료하기 위한 지속시간 또는 다른 특정 조건(들)을 식별하는 LPPe 제어 파라미터들을 포함할 수도 있다.
타임 2 에서, 타깃 (301) 은 LPP ProvideLocationInformation 메시지를 이용하여 서버 (302) 에 응답한다. 이 메시지는 트랜잭션 ID T1 을 사용하며 이 트랜잭션의 종단을 나타낸다. 이 메시지는 세션 ID S 및 타임 1 에서의 요청이 지원될 수 있는지의 여부를 나타내는 LPPe 제어 파라미터들을 포함한다. 만약 요청이 지원될 수 있다면, 제어 파라미터들은 로케이션 정보의 유형, 트리거링 또는 주기성 파라미터들, 및 로케이션 정보 이송을 종료하기 위한 지속시간 또는 다른 조건(들)을 확인 또는 재정의할 수도 있다. 전달될 로케이션 정보의 추가 특징들은 또한 이 메시지에 제공될 수도 있다. 단계 2 에서의 메시지는 (또한 트랜잭션이라고도 알려진) 단계 1 에서 시작된 LPP 절차를 종료하고 3GPP TS 36.355 에서의 LPP 규칙들을 따른다 (예를 들면, 도 6b 에서의 단계 1 및 단계 3 에 대응한다). 절차는 후속 단계들에서 어떤 로케이션 정보가 이송될 것인지를 확립하지만 실제로는 임의의 로케이션 정보를 이송하지 않으므로, 이 절차는 제어 트랜잭션 또는 제어 절차라고 지칭될 수도 있다.
제 1 트리거링 또는 주기성 조건(들)이 발생하면, 타깃 (301) 은 타임 3 에서 비응답형 LPP ProvideLocationInformation 메시지를 서버 (302) 에 전송한다. 이 메시지는 세션 ID S 및 타임 2 또는 타임 1 에서 확인 또는 정의된 로케이션 정보를 포함하는 LPPe 데이터 파라미터들을 포함한다. 이 메시지는 T1 과는 상이할 수도 있는 일부 가용한 트랜잭션 ID T2 를 사용한다. 이 절차에 적용가능한 LPPe 제어 파라미터들 및 LPPe 데이터 파라미터들은 서로 구별가능하다. 세션 ID S 는 로케이션 정보가 단계 1 및 단계 2 에서 합의된 것에 대응한다는 것을 서버 (302) 에 확인한다.
타임 4 에서, 타깃 (301) 은 각각의 부가적인 트리거링 또는 주기성 조건 (들) 이 발생하였을 때 타임 2 에서 확인된 로케이션 정보를 포함하는 추가의 LPP ProvideLocationInformation 메시지들을 서버 (302) 로 전송하는 것을 계속할 수도 있다. 만약 로케이션 정보를 종료하기 위한 지속시간 또는 다른 조건들이 발생하면, 이송된 마지막 ProvideLocationInformation 메시지는 트랜잭션 T2 의 종단을 나타낸다. 이 경우에서, 도 4a 에서의 타임 5 내지 타임 8 에서 발생하는 트랜잭션들은 생략된다. 이 경우에서, 절차 (또는 트랜잭션) 는 3GPP TS 36.355 에서의 LPP 에 대한 규칙들에 따라 종료된다 (예를 들면, 로케이션 정보의 비응답형 이송에 대한 도 6b 에서의 단계 2 및 단계 3 에 대응한다). 이 경우에서, 절차는 로케이션 정보를 이송하지만 이 로케이션 정보의 콘텐츠를 협상 또는 수정하지는 않으므로, 이 절차는 데이터 트랜잭션 또는 데이터 절차라고 지칭될 수도 있다.
로케이션 정보의 전달이 종료되기 전에, 서버 (302) 는 가용 트랜잭션 ID T3 을 이용하여 타임 5 에서 LPP RequestLocationInformation 메시지를 타깃 (301) 으로 전송함으로써 로케이션 정보의 유형 및/또는 트리거링 및 주기성 조건들 및/또는 종료를 위한 지속시간 또는 조건들을 업데이트할 수도 있다. ID T3 는 T2 와는 상이하다. 이 메시지는 세션 ID S, 및 요청되는 로케이션 정보의 임의의 새로운 유형, 이 정보를 전송하기 위한 임의의 새로운 트리거링 또는 주기성 조건들, 및 로케이션 정보 이송을 종료하기 위한 임의의 새로운 지속시간 또는 특정 조건들을 식별하는 LPPe 제어 파라미터들을 포함한다. 제어 파라미터들은 또한 만약 새로운 요청이 지원될 수 없다면 이전의 로케이션 정보 전달이 계속되어야 하는지 (디폴트) 또는 중단되어야 하는지를 나타낼 수도 있다. 세션 ID S 의 포함은 새로운 요청이 단계 1 내지 단계 4 의 로케이션 정보 이송에 관련된다는 것을 타깃 (301) 에게 알려준다. 단계 5 에서의 요청이 서버 (302) 와 타깃 (301) 양쪽 모두에 의해 단계 3 및 단계 4 와 연관된 것과는 상이한 절차 (상이한 트랜잭션) 에 속한 것으로서 보여지기 때문에, T2 와 상이한 트랜잭션 ID T3 의 사용은 LPP 프로토콜 위반을 방지한다. 트랜잭션 ID T3 이 T2 와 동일하였다면, 프로토콜 위반이 있었을 것이며 타깃 (301) 은 이송을 중단할 수도 있었을 것이다.
타임 6 에서, 타깃 (301) 은 LPP ProvideLocationInformation 메시지를 이용하여 서버 (302) 에 응답한다. 이 메시지는 트랜잭션 ID T3 을 사용하며 이 트랜잭션의 종단을 나타낸다. 이 메시지는 타임 5 에서의 수정된 요청이 지원될 수 있는지의 여부를 나타내는 LPPe 제어 파라미터들을 포함한다. 만약 요청이 지원될 수 있다면, 제어 파라미터들은 로케이션 정보의 임의의 새로운 유형, 및 새로운 트리거링 또는 주기성 파라미터들, 및 로케이션 정보 이송을 종료하기 위한 임의의 새로운 지속시간 또는 다른 조건들을 확인 또는 재정의할 수도 있다. 전달될 로케이션 정보의 추가 특징들은 또한 제공될 수도 있다. 만약 타임 5 에서의 요청이 지원될 수 없으면, 그렇다면, 타임 5 에서 달리 요청되지 않는 한, 타임 1 에서의 초기 요청은, 그것이 정상적으로 종료되거나 타임 5 에서 발생하는 트랜잭션의 반복에 의해 수정되거나 서버 (302) 에 의해 중단될 때까지, 타임 4 에서 발생하는 트랜잭션들의 추가 반복들을 통하여 계속될 것이다. 그러나 만약 타임 5 에서 달리 요청되면, 임의의 추가 로케이션 정보를 서버 (302) 에 전송하는 일 없이 (트랜잭션 T2 를 포함하는) 초기 요청은 타깃 (301) 에서 중단된다. 어떠한 경우에도, 도 4a 에서의 타임 7 및 타임 8 에서 발생하는 트랜잭션들은 그런 다음 생략된다. (트랜잭션 표시자의 종단은 단계 6 에서 타깃 (301) 에 의해 포함되었기 때문에) 단계 5 및 단계 6 과 연관된 절차는 그런 다음 종료되고 3GPP TS 36.355 에서의 LPP 절차 규칙들을 따른다 (예를 들면, 도 6b 에서의 단계 1 및 단계 3 에 대응한다). 절차는 이송되는 로케이션 정보를 수정하지만 임의의 로케이션 정보를 실제로 이송하지는 않으므로, 이 절차는 제어 트랜잭션 또는 제어 절차라고 지칭될 수도 있다.
만약 타깃 (301) 이 타임 5 에서 요청을 지원할 수 있다면, 타깃 (301) 은 타임 1 에서의 요청을 지원하는 것을 멈춘다. 레이스 조건들로 인하여, 타임 4 에서 발생하는 메시지의 일 회 이상의 반복들은 서버 (302) 에 의해 타임 5 에 뒤이어 그리고 타임 6 이전에 발생한 것으로 인지될 수도 있다. 타임 6 에 뒤이어 제 1 업데이트된 트리거링 또는 주기성 조건(들) 이 발생하면, 타깃 (301) 은 세션 ID S, 및 타임 6 또는 타임 5 에서 확인 또는 정의된 새로운 로케이션 정보를 포함하는 LPPe 데이터 파라미터들을 포함하는 비응답형 LPP ProvideLocationInformation 메시지를 서버 (302) 로 전송한다. 이 메시지는 트랜잭션 ID T2 를 계속 사용하며 이것은 로케이션 정보의 이송에 대한 LPP 절차를 방해하는 것 (예를 들면, 위반하는 것) 을 방지한다. 서버 (302) 는 단계 6 에서의 LPP 메시지가 언제 수신되었는지에 따라서 로케이션 정보 이송을 타깃 (301) 이 언제 변경했는지를 결정할 수 있다. (3GPP TS 35.355에서 LPP 에 대한 요건인) 타깃 (301) 에 의해 전송된 순서로 LPP 메시지들이 서버 (302) 로 전달되었다면, 단계 4 의 모든 인스턴스들은 단계 6 이 발생하기 전에 멈출 것이며 단계 7 은 단계 6 이 발생한 후에 발생할 것이다. 이것은 로케이션 정보 이송에 대한 변경들이 발생하였다는 것을 구체적으로 나타내기 위하여 단계 7 에서 LPP 메시지에 임의의 것을 포함해야 할 필요성을 방지하며 이것은 LPP 및 LPPe 메시지 콘텐츠를 단순화한다.
타임 8 에서, 타깃 (301) 은 세션 ID S 및 LPPe 데이터 파라미터들을 포함하는 추가 LPP ProvideLocationInformation 메시지들을 서버 (302) 로 전송하는 것을 계속할 수도 있다. LPPe 데이터 파라미터들은 각각의 부가 트리거링 또는 주기성 조건(들)이 발생하면 타임 6 또는 타임 5 에서 확인 또는 재정의되는 새로운 로케이션 정보를 포함한다. 만약 로케이션 정보 이송을 종료하기 위한 지속시간 또는 다른 조건(들)이 발생하면, 이송된 마지막 LPP ProvideLocationInformation 메시지는 트랜잭션 T2 의 종단을 나타낸다. 트랜잭션의 종단이 발생하기 전에, 서버 (302) 는 로케이션 정보의 유형, 트리거링 또는 주기성 조건들 및/또는 이송을 종료하기 위한 지속시간 또는 다른 조건(들)을 업데이트할 수도 있으며, 타임 5 및 타임 6 에서 발생하는 트랜잭션들은 반복된다. 트랜잭션 식별자의 종단을 포함함에 의한 단계 8 에서의 절차의 종료는 LPP 절차 규칙들을 따른다 (예를 들면, 단계 8 은 도 6b 에서의 단계 3 에 대응한다). 게다가, 단계 3, 단계 4, 단계 7 및 단계 8 에서의 로케이션 정보의 완전한 이송은 도 6b 의 단계 2 및 단계 3 에서 도시된 바와 같은 로케이션 정보의 정상적 비응답형 LPP 이송에 대응한다. 이러한 단계들은 로케이션 정보를 이송하지만 이 로케이션 정보의 콘텐츠를 정의 또는 수정하지는 않으므로, 이 단계들은 데이터 트랜잭션 또는 데이터 절차라고 지칭될 수도 있다.
위의 설명으로부터, 도 4a 에서의 전체 절차는 3 개의 별도의 더 작은 LPP 절차들 또는 트랜잭션들: 이송될 로케이션 정보를 정의 및 합의하기 위한 단계 1 및 단계 2 에서의 제어 트랜잭션, 이송될 로케이션 정보를 수정하기 위한 단계 5 및 단계 6 에서의 또 다른 제어 트랜잭션, 및 로케이션 정보를 이송하기 위한 단계 3, 단계 4, 단계 7 및 단계 8 에서의 데이터 트랜잭션으로 이루어졌다는 것을 알 수도 있다. 이러한 더 작은 절차들 (또는 트랜잭션들) 은 3GPP TS 36.355 에서의 LPP 규칙들을 따르며 이렇게 하여 전체 복합 절차가 또한 LPP 를 따르도록 한다.
도 4b 는 도 4a 에 도시된 로케이션 정보 이송 세션의 예시적인 개시 및 종료를 도시한 호 흐름도이다. 타임 1 에서, 서버 (302) 는 일부 가용한 트랜잭션 ID T1 을 사용하는 LPP RequestLocationInformation 메시지를 타깃 (301) 으로 전송한다. 이 메시지는 (절차의 동일한 유형의 임의의 다른 인스턴스에 대하여 타깃 (301) 과 서버 (302) 사이에 현재 사용되는 임의의 다른 LPPe 세션 ID 와는 상이한) 세션 ID S, 메시지가 주기적/트리거된 로케이션 정보 이송에 대한 초기 요청이라는 표시, 및 LPPe 제어 파라미터들을 포함한다. LPPe 제어 파라미터들은 요청된 로케이션 정보의 유형, 이 정보를 전송하기 위한 트리거링 또는 주기성 조건들, 및 로케이션 정보 이송을 종료하기 위한 지속시간 또는 다른 특정 조건(들)을 식별한다.
타임 2 에서, 타깃 (301) 은 LPP ProvideLocationInformation 메시지를 이용하여 서버 (302) 에 응답한다. 이 메시지는 타임 1 에서의 트랜잭션 ID T1 를 사용하며 이 트랜잭션의 종단을 나타낸다. 이 메시지는 세션 ID S, 메시지가 초기 요청에 대한 응답이라는 표시, 및 타임 1 에서의 요청이 지원될 수 있는지의 여부를 나타내는 LPPe 제어 파라미터들을 포함한다. 만약 요청이 지원될 수 있다면, 제어 파라미터들은 로케이션 정보의 유형, 트리거링 또는 주기성 파라미터들, 및 로케이션 정보 이송을 종료하기 위한 지속시간 또는 다른 조건들을 명백하게 확인 또는 재정의할 수도 있다. 전달될 로케이션 정보의 추가 특징들은 또한 메시지에 제공될 수도 있다. 만약 절차가 지원될 수 없다면, 에러 사유는 LPPe 레벨에서 제공되고 나머지 단계들을 그런 다음 수행되지 않는다. 단계 1 및 단계 2 에서의 메시지들은 3GPP TS 36.355 에서의 LPP 에 대한 규칙들에 따른 단일 LPP 절차 (또는 트랜잭션) 를 포함한다 (예를 들면, 도 6b 의 단계 1 및 단계 3 에 대응한다). 절차는 후속 단계들에서 어떤 로케이션 정보가 이송될 것인지를 확립하지만 실제로는 임의의 로케이션 정보를 이송하지 않으므로, 이 절차는 제어 트랜잭션 또는 제어 절차라고 지칭될 수도 있다.
타임 3 에서, 제 1 트리거링 또는 주기성 조건(들) 이 발생하면, 타깃 (301) 은 세션 ID S, 메시지가 주기적/트리거된 로케이션 정보 전달이라는 표시, 및 LPPe 데이터 파라미터들을 포함한 비응답형 LPP ProvideLocationInformation 메시지를 서버 (302) 에 전송한다. LPPe 데이터 파라미터들은 단계 2 또는 단계 1 에서 확인 또는 정의된 로케이션 정보를 포함한다. 이 메시지는 T1 과는 상이할 수도 있는 일부 가용한 트랜잭션 ID T2 를 사용한다. 단계 1 및 단계 2 와 동일한 세션 ID S 를 포함하는 것은 서버 (302) 에게 메시지가 단계 1 및 단계 2 에서 합의된 로케이션 정보 이송에 관련된다는 것을 알려준다. 새로운 절차의 일부로서 메시지를 전송하는 것은 LPP 프로토콜 규칙들을 위반하는 것을 방지한다.
타임 4 에서, 타깃 (301) 은 각각의 부가적인 트리거링 또는 주기성 조건 (들) 이 발생하였을 때 타임 2 또는 타임 1 에서 확인 또는 재정의된 로케이션 정보를 포함하는 추가의 LPP ProvideLocationInformation 메시지를 서버 (302) 로 전송하는 것을 계속할 수도 있다. 메시지들은 또한 단계 3 에서와 동일한 트랜잭션 ID T2 및 세션 ID S 를 포함하며 따라서 서버 (302) 에 의해 단계 3 과 연관된 절차의 연속으로서 보여진다.
만약 세션이 종료되도록 하는 에러 조건(들)이 서버 (302) 에서 발생하면, 서버 (302) 는, 타임 5 에서, 옵션적으로 LPP 및/또는 LPPe 에러 코드들을 포함할 수도 있는 트랜잭션 T2 에 대한 LPP Abort 를 타깃 (301) 에 전송한다. 타임 6 및 타임 7 에서 발생하는 남아있는 단계들은 그런 다음 생략된다. 중단을 유도할 수도 있는 에러 조건들은 타깃 (301) 에 의해 제공된 최종 제어 파라미터들이 서버 (302) 에 허용될 수 없는 로케이션 정보 이송을 업데이트하기 위한, 서버 (302) 또는 타깃 (301) 중 어느 하나에 의한 시도를 포함한다.
만약 추가 로케이션 정보의 전달 없이 세션이 종료되도록 하는 에러 조건(들)이 타깃 (301) 에서 발생하면, 타깃 (301) 은, 타임 6 에서, 옵션적으로 LPP 및/또는 LPPe 에러 코드들을 포함할 수도 있는 트랜잭션 T2 에 대한 LPP Abort 를 서버 (302) 에 전송한다. 타임 7 에서의 남아있는 단계는 그런 다음 생략된다. 단계 5 또는 단계 6 에서의 LPP Abort 메시지의 전송은 3GPP TS 36.355 에서의 LPP 규칙들에 의해 허용되고 따라서 LPP 와 일치한다. 단계 5 또는 단계 6 에서의 LPP Abort 메시지는 트랜잭션 ID T2 를 반송하며 따라서 단계 3 및 단계 4 와 연관된 트랜잭션의 일부 (및 종단) 로서 보여진다는 것에 유의한다.
로케이션 정보 이송을 종료하기 위한 지속시간 또는 다른 조건(들)이 발생하면, 타임 7 에서, 전송된 마지막 LPP ProvideLocationInformation 메시지는 트랜잭션 T2 의 종단을 나타낸다. 이송을 종료하는 것은, 이송을 중단하는 것에 비하여, 로케이션 정보 이송에 특정한 부가 종료 정보가 포함될 수도 있도록 허용한다. 단계 3, 단계 4 및 단계 7 에서의 로케이션 정보의 완전한 이송은 도 6b 의 단계 2 및 단계 3 에서 도시한 바와 같은 로케이션 정보의 정상적 비응답형 LPP 이송에 대응한다. 이 단계들은 로케이션 정보를 이송하지만 이 로케이션 정보의 콘텐츠를 정의하거나 수정하지는 않으므로, 이 단계들은 데이터 트랜잭션 또는 데이터 절차라고 지칭될 수도 있다.
위의 설명으로부터, 도 4b 에서의 전체 절차는 2 개의 별도의 더 작은 LPP 절차들 또는 트랜잭션들: 이송될 로케이션 정보를 정의 및 합의하기 위한 단계 1 및 단계 2 에서의 제어 트랜잭션, 및 로케이션 정보를 이송하기 위한 단계 3, 단계 4, 및 단계 7 에서의 데이터 트랜잭션으로 이루어졌다는 것을 알 수도 있다. 이 더 작은 절차들 (또는 트랜잭션들) 은 3GPP TS 36.355 에서의 LPP 규칙들을 따르며 이렇게 하여 전체 복합 절차들이 또한 LPP 를 따르도록 한다.
도 4c 는 도 4b 에 따라서 시작된 진행중인 주기적/트리거된 로케이션 정보 이송을 서버 (302) 가 어떻게 업데이트할 수도 있는지를 도시한 호 흐름도이다. 타임 1 에서, 주기적/트리거된 로케이션 정보 이송 절차는 도 4b 의 단계 1 및 단계 2 에서의 제어 트랜잭션 또는 제어 절차를 이용하여 개시된다. 타임 2 에서, 타깃 (301) 은 타임 1 에서 합의된 로케이션 정보를 포함하고 트랜잭션 ID T2 를 사용하는 0, 하나 또는 그 이상의 LPP ProvideLocationInformation 메시지들을 서버 (302) 로 전송할 수도 있다.
타임 3 에서, 서버 (302) 는 로케이션 정보를 수정할 수도 있다. 로케이션 정보를 수정하는 것은 로케이션 정보의 유형, 로케이션 정보를 이송하기 위한 트리거링 및 주기성 조건들, 및/또는 종료를 위한 지속시간 또는 조건(들)을 포함한다. 서버 (302) 는 일부 가용한 트랜잭션 ID T3 을 사용하는 LPP RequestLocationInformation 메시지를 타깃 (301) 으로 전송한다. ID T3 는 (만약 T2 이 시작되었다면) T2 와는 상이하다. 이 메시지는 세션 ID S, 메시지가 주기적/트리거된 로케이션 정보 이송에 대한 업데이트 요청이라는 표시, 및 LPPe 제어 파라미터들을 포함한다. LPPe 제어 파라미터들은 요청되는 로케이션 정보의 임의의 새로운 유형, 이 로케이션 정보를 전송하기 위한 임의의 새로운 트리거링 또는 주기성 조건들, 및 로케이션 정보 이송을 종료하기 위한 임의의 새로운 지속시간 또는 특정 조건(들)을 식별한다. 만약 새로운 요청이 지원될 수 없다면, 제어 파라미터들은 또한 이전의 로케이션 정보 전달이 계속되어야 할 것인지 또는 중단되어야 할 것인지를 나타낼 수도 있다. 세션 ID S 를 포함하는 것은 타깃 (301) 에게 새로운 요청이 단계 1 및 단계 2 의 로케이션 정보 이송에 관련된다는 것을 알려준다. 단계 3 에서의 요청이 서버 (302) 와 타깃 (301) 양쪽 모두에 의해 단계 2 와 연관된 것과는 상이한 절차 (상이한 트랜잭션) 에 속한 것으로서 보여지기 때문에, T2 와 상이한 트랜잭션 ID T3 의 사용은 LPP 프로토콜 위반을 방지한다. 트랜잭션 ID T3 이 T2 와 동일하였다면, 프로토콜 위반이 있었을 것이며 서버 (302) 는 이송을 중단할 수도 있었을 것이다.
타임 4 에서, 타깃 (301) 은 LPP ProvideLocationInformation 메시지를 이용하여 서버 (302) 에 응답한다. 이 메시지는 트랜잭션 ID T3 을 사용하며 이 트랜잭션의 종단을 나타낸다. 이 메시지는 세션 ID S 및 메시지가 업데이트 요청에 대한 응답이라는 표시를 포함한다. 이 메시지는 또한 타임 3 에서의 업데이트 요청이 지원될 수 있는지의 여부를 나타내는 LPPe 제어 파라미터들을 포함한다. 만약 요청이 지원될 수 있다면, 제어 파라미터들은 로케이션 정보의 임의의 새로운 유형, 임의의 새로운 트리거링 또는 주기성 파라미터들, 및 로케이션 정보 이송을 종료하기 위한 임의의 새로운 지속시간 또는 다른 조건(들)을 명백하게 확인 또는 재정의할 수도 있다. 전달될 로케이션 정보의 추가 특징들은 또한 메세지에서 제공될 수도 있다. 만약 타임 3 에서의 요청이 지원될 수 없다면, 그렇다면, 만약 타임 3 에서 요청되면, 타임 1 에서의 초기 요청은, 그것이 정상적으로 종료되거나 타임 3 에서의 트랜잭션의 반복에 의해 수정되거나 중단될 때까지, 타임 2 에서의 트랜잭션들의 추가 반복들을 통하여 계속될 것이다. 그러나 만약 타임 3 에서 달리 요청되면, (트랜잭션 T2 를 포함하는) 초기 요청은 임의의 추가 로케이션 정보를 서버 (302) 로 전송하는 일 없이 타깃 (301) 에서 중단된다. 어떠한 경우에도, 타임 5 및 타임 6 에서 발생하는 단계들은 그런 다음 생략된다. (단계 4 에서 트랜잭션 표시자의 종단이 타깃 (301) 에 의해 포함되었기 때문에) 단계 3 및 단계 4 와 연관된 절차는 그런 다음 종료되고 3GPP TS 36.355 에서의 LPP 절차 규칙들을 따른다 (예를 들면, 도 6b 에서의 단계 1 및 단계 3 에 대응한다). 절차는 이송되는 로케이션 정보를 수정하지만 실제로 임의의 로케이션 정보를 이송하지 않으므로, 이 절차는 제어 트랜잭션 또는 제어 절차라고 지칭될 수도 있다.
만약 타깃 (301) 이 타임 3 에서의 요청을 지원할 수 있다면, 그런 다음 타임 4 에 뒤이어, 타깃 (301) 은 타임 1 에서의 트랜잭션에서 발생하는 요청을 지원하는 것을 멈춘다. 레이스 조건들로 인하여, 타임 2 에서 발생하는 단계의 일 회 이상의 반복들은 서버 (302) 에 의해 타임 3 에 뒤이어 그리고 타임 4 이전에 발생한 것으로 인지될 수도 있다. 타임 4 에 뒤이어 제 1 업데이트된 트리거링 또는 주기성 조건(들) 이 발생하면, 타깃 (301) 은 세션 ID S, 메시지가 주기적/트리거된 로케이션 정보라는 표시, 및 LPPe 데이터 파라미터들을 포함하는 비응답형 LPP ProvideLocationInformation 메시지를 서버 (302) 로 전송한다. LPPe 데이터 파라미터들은 타임 4 또는 타임 3 에서 확인 또는 정의된 새로운 로케이션 정보를 포함한다. 이 메시지는 트랜잭션 ID T2 를 계속 사용하며 이것은 로케이션 정보의 이송에 대한 LPP 절차를 방해하는 것 (예를 들면, 위반하는 것) 을 방지한다. 서버 (302) 는 단계 4 에서의 LPP 메시지가 언제 수신되었는지에 따라서 로케이션 정보 이송을 타깃 (301) 이 언제 변경했는지를 결정할 수 있다. (3GPP TS 35.355 에서 LPP 에 대한 요건인) 타깃 (301) 에 의해 전송된 순서로 LPP 메시지들이 서버 (302) 로 전달되었다면, 단계 2 의 모든 인스턴스들은 단계 4 가 발생하기 전에 멈출 것이며 단계 5 는 단계 4 가 발생한 후에 발생할 것이다. 이것은 로케이션 정보 이송에 대한 변경들이 발생하였다는 것을 구체적으로 나타내기 위하여 단계 5 에서 LPP 메시지에 임의의 것을 포함해야 할 필요성을 방지하며 이것은 LPP 및 LPPe 메시지 콘텐츠를 단순화한다.
타임 6 에서, 타깃 (301) 은 각각의 부가적인 트리거링 또는 주기성 조건들 이 발생하였을 때 세션 ID S, 및 타임 4 또는 타임 3 에서 확인 또는 재정의된 새로운 로케이션 정보를 포함하는 LPPe 데이터 파라미터들을 포함하는 추가의 LPP ProvideLocationInformation 메시지들을 서버 (302) 로 전송하는 것을 계속할 수도 있다. 만약 로케이션 정보 이송을 종료하기 위한 지속시간 또는 다른 조건(들)이 발생하면, 이송된 마지막 LPP ProvideLocationInformation 메시지는 트랜잭션 T2 의 종단을 나타낸다. 만약, 이것이 발생하기 전에, 서버 (302) 가 로케이션 정보의 유형, 트리거링 또는 주기성 조건들 및/또는 이송을 종료하기 위한 지속시간 또는 다른 조건(들)을 업데이트하기를 원하면, 타임 3 및 타임 4 에서 발생하는 단계들은 반복된다. 트랜잭션 식별자의 종단을 포함하는 것에 의한 단계 6 에서의 절차의 종료는 LPP 절차 규칙들을 따른다 (예를 들면, 단계 6 은 도 6b 에서의 단계 3 에 대응한다). 게다가, 단계 2, 단계 5 및 단계 6 에서의 로케이션 정보의 완전한 이송은 도 6b 의 단계 2 및 단계 3 에서 도시된 바와 같은 어시스턴스 데이터의 정상적 비응답형 LPP 이송에 대응한다. 이 단계들은 로케이션 정보를 이송하지만 이 로케이션 정보의 콘텐츠를 정의하거나 수정하지는 않으므로, 이 단계들은 데이터 트랜잭션 또는 데이터 절차라고 지칭될 수도 있다.
위의 설명으로부터, 도 4c 에서의 전체 절차는 3 개의 별도의 더 작은 LPP 절차들 또는 트랜잭션들 - 이송될 로케이션 정보를 정의 및 합의하기 위한 단계 1 에서의 제어 트랜잭션, 서버 (302) 가 이송되는 로케이션 정보를 수정하도록 하기 위한 단계 3 및 단계 4 에서의 또 다른 제어 트랜잭션, 및 로케이션 정보를 이송하기 위한 단계 2, 단계 5 및 단계 6 에서의 데이터 트랜잭션으로 이루어졌다는 것을 알 수도 있다. 이러한 더 작은 절차들 (또는 트랜잭션들) 은 3GPP TS 36.355 에서의 LPP 규칙들을 따르며 이렇게 하여 전체 복합 절차가 또한 LPP 를 따르도록 한다.
도 4d 는 도 4b 에 따라서 시작된 진행중인 주기적/트리거된 로케이션 정보 이송을 타깃 (301) 이 어떻게 업데이트할 수도 있는지를 도시한 호 흐름도이다.
타임 1 에서, 절차는 도 4b 에서의 단계 1 및 단계 2 에서와 같은 제어 트랜잭션 또는 제어 절차를 이용하여 개시된다. 타임 2 에서, 타깃 (301) 은 타임 1 에서 합의된 로케이션 정보를 포함하고 트랜잭션 ID T2 를 사용하는 0, 하나 또는 그 이상의 LPP ProvideLocationInformation 메시지를 서버 (302) 로 전송할 수도 있다.
타임 3 에서, 로케이션 정보의 전달이 종료되기 전에, 타깃 (301) 은 로케이션 정보의 유형, 트리거링 및 주기성 조건들, 및/또는 종료를 위한 지속시간 또는 조건(들)을 업데이트할 수도 있다. 타깃 (301) 은 일부 가용한 트랜잭션 ID T3 을 사용하여 비응답형 LPP ProvideLocationInformation 메시지를 서버 (302) 로 전송한다. ID T3 은 (만약 T2 이 시작되었다면) T2 와는 상이하다. 이 메시지는 단계 1 및 단계 2 에서 사용된 세션 ID S, 메시지가 주기적/트리거된 로케이션 정보 이송에 대한 타깃 업데이트라는 표시, 및 LPPe 제어 파라미터들을 포함한다. LPPe 제어 파라미터들은 제공될 로케이션 정보의 임의의 새로운 유형, 로케이션 정보를 전송하기 위한 임의의 새로운 트리거링 또는 주기성 조건들, 및 로케이션 정보 이송을 종료하기 위한 임의의 새로운 지속시간 또는 특정 조건(들)을 식별한다. 이 메시지를 전송한 후에, 타깃 (301) 은 타임 2 의 그것에 따른 로케이션 정보 이송을 멈춘다. 세션 ID S 를 포함하는 것은 서버 (302) 에게 새로운 요청이 단계 1 및 단계 2 의 로케이션 정보 이송에 관련된다는 것을 알려준다. 단계 3 에서의 요청이 서버 (302) 와 타깃 (301) 양쪽 모두에 의해 단계 2 와 연관된 것과는 상이한 절차 (상이한 트랜잭션) 에 속한 것으로서 보여지기 때문에, T2 와 상이한 트랜잭션 ID T3 의 사용은 LPP 프로토콜 위반을 방지한다. 트랜잭션 ID T3 이 T2 와 동일하였다면, 프로토콜 위반이 있었을 것이며 서버 (302) 는 이송을 중단할 수도 있었을 것이다. 단계 3 은 또한 3GPP TS 36.355 에서의 LPP 절차 규칙들을 따른다 (예를 들면, 로케이션 정보의 단일 비응답형 이송에 대하여 도 6b 에서의 단계 3 에 대응한다). 그러나, 절차는 이송되는 로케이션 정보를 수정하지만 임의의 실제 로케이션 정보를 이송하지 않으므로, 이 절차는 제어 트랜잭션 또는 제어 절차라고 지칭될 수도 있다.
(타임 3 에서 정의된 바와 같은) 제 1 업데이트된 트리거링 또는 주기성 조건들이 발생하면, 타깃 (301) 은, 타임 4 에서, 세션 ID S, 메시지가 주기적/트리거된 로케이션 정보라는 표시, 및 LPPe 데이터 파라미터들을 포함하는 비응답형 LPP ProvideLocationInformation 메시지를 서버 (302) 로 전송한다. LPPe 데이터 파라미터들은 타임 3 에서 정의된 새로운 로케이션 정보를 포함한다. 이 메시지는 트랜잭션 ID T2 를 계속 사용하며 이것은 로케이션 정보의 이송에 대한 LPP 절차를 방해하는 것 (예를 들면, 위반하는 것) 을 방지한다. 서버 (302) 는 단계 4 에서의 LPP 메시지가 언제 수신되었는지에 따라서 로케이션 정보 이송을 타깃 (301) 이 언제 변경했는지를 결정할 수 있다. (3GPP TS 36.355에서 LPP 에 대한 요건인) 타깃 (301) 에 의해 전송된 순서로 LPP 메시지들이 서버 (302) 로 전달되었다면, 단계 2 의 모든 인스턴스들은 단계 3 이 발생하기 전에 멈출 것이며 단계 4 는 단계 3 이 발생한 후에 발생할 것이다. 이것은 로케이션 정보 이송에 대한 변경들이 발생하였다는 것을 구체적으로 나타내기 위하여 단계 4 에서 LPP 메시지에 임의의 것을 포함해야 할 필요성을 방지하며 이것은 LPP 및 LPPe 메시지 콘텐츠를 단순화한다.
타임 5 에서, 각각의 부가적 트리거링 또는 주기성 조건(들) 이 발생하면 타깃 (301) 은 세션 ID S, 및 타임 3 에서 정의된 새로운 로케이션 정보를 포함하는 LPPe 데이터 파라미터들을 포함하는 추가 LPP ProvideLocationInformation 메시지들을 서버 (302) 로 전송하는 것을 계속할 수도 있다. 만약 로케이션 정보이송을 종료하기 위한 지속시간 또는 다른 조건(들)이 발생하면, 이송된 마지막 LPP ProvideLocationInformation 메시지는 트랜잭션 T2 의 종단을 나타낸다. 트랜잭션이 종료되기 전에, 타깃 (301) 은 타임 3 의 트랜잭션을 반복함으로써 로케이션 정보의 유형, 트리거링 또는 주기성 조건(들) 및/또는 이송을 종료하기 위한 지속시간 또는 다른 조건(들)을 업데이트할 수도 있다. 트랜잭션 식별자의 종단을 포함하는 것에 의한 단계 5 에서의 절차의 종료는 LPP 절차 규칙들을 따른다 (예를 들면, 단계 5 는 도 6b 에서의 단계 3 에 대응한다). 게다가, 단계 2, 단계 4, 및 단계 5 에서의 로케이션 정보의 완전한 이송은 도 6b 의 단계 2 및 단계 3 에서 도시된 바와 같은 로케이션 정보의 정상적 비응답형 LPP 이송에 대응한다. 이 단계들은 로케이션 정보를 이송하지만 이 로케이션 정보의 콘텐츠를 정의하거나 수정하지는 않으므로, 이 단계들은 데이터 트랜잭션 또는 데이터 절차라고 지칭될 수도 있다.
위의 설명으로부터, 도 4d 에서의 전체 절차는 3 개의 별도의 더 작은 LPP 절차들 또는 트랜잭션들: 이송될 로케이션 정보를 정의 및 합의하기 위한 단계 1 에서의 제어 트랜잭션, 타깃 (301) 이 이송되는 로케이션 정보를 수정하도록 하기 위한 단계 3 에서의 또 다른 제어 트랜잭션, 및 로케이션 정보를 이송하기 위한 단계 2, 단계 4 및 단계 5 에서의 데이터 트랜잭션으로 이루어졌다는 것을 알 수도 있다. 이러한 더 작은 절차들 (또는 트랜잭션들) 은 3GPP TS 36.355 에서의 LPP 규칙들을 따르며 이렇게 하여 전체 복합 절차가 또한 LPP 를 따르도록 한다.
도 5a 는 모바일 디바이스와 같은 타깃의 로케이션을 결정하기 위한 예시적인 방법 (501) 을 도시한다. 블록 510 에서, 로케이션 서버와 모바일 디바이스 사이의 이송을 위한 로케이션 관련 데이터는 제 1 트랜잭션을 이용하여 정의된다. 블록 512 에서, 로케이션 관련 데이터는 로케이션 서버와 모바일 디바이스 사이에서 제 2 트랜잭션을 이용하여 이송된다.
도 5b 는 모바일 디바이스와 같은 타깃의 로케이션을 결정하기 위한 예시적인 방법 (502) 을 도시한다. 블록 520 에서, 로케이션 서버와 모바일 디바이스 사이의 이송을 위한 로케이션 관련 데이터는 제 1 트랜잭션을 이용하여 정의된다. 블록 522 에서, 로케이션 관련 데이터는 로케이션 서버와 모바일 디바이스 사이에서 제 2 트랜잭션을 이용하여 이송된다. 블록 524 에서, 로케이션 서버와 모바일 디바이스 사이의 로케이션 관련 데이터의 주기적 이송은 제 3 트랜잭션을 이용하여 수정된다. 블록 526 에서, 수정된 로케이션 관련 데이터는 로케이션 서버와 모바일 디바이스 사이에서 제 2 트랜잭션을 이용하여 주기적으로 이송된다. 블록 528 에서, 로케이션 서버와 모바일 디바이스 사이의 로케이션 관련 데이터의 주기적 이송은 제 2 트랜잭션을 종료함으로써 종료된다.
도 7 은 모바일 디바이스 (16), 타깃, 또는 로케이션 서버 (26) 와 같은 장치의 블록도를 도시한다. 이 장치는 제 1 트랜잭션을 이용하여 로케이션 서버와 모바일 디바이스 사이의 이송을 위한 로케이션 관련 데이터를 정의하기 위한 모듈 (710) 을 포함한다. 이 장치는 또한 제 2 트랜잭션을 이용하여 로케이션 서버와 모바일 디바이스 사이에서 로케이션 관련 데이터를 이송하기 위한 모듈 (720) 을 포함한다. 도 7 에서의 모듈들은 프로세서들, 전자 디바이스들, 하드웨어 디바이스들, 전자 컴포넌트들, 로직 회로들, 메모리들, 소프트웨어 코드들, 펌웨어 코드들 등, 또는 이들의 임의의 조합일 수도 있다.
숙련된 자들은 본원의 개시와 연계되어 설명된 다양한 예시적인 논리 블록들, 모듈들, 회로들 및 알고리즘 단계들은 전자 하드웨어, 컴퓨터 소프트웨어, 또는 양측의 조합들로서 구현될 수도 있다는 것을 추가로 이해할 것이다. 하드웨어와 소프트웨어의 이러한 상호교환성을 명확히 예시하기 위하여, 다양한 예시적인 컴포넌트들, 블록들, 모듈들, 회로들, 및 단계들이 위에서 이들의 기능성의 면에서 일반적으로 설명되었다. 그러한 기능성이 하드웨어 또는 소프트웨어로 구현되는지의 여부는 특정 애플리케이션 및 전체 시스템 상에 부과된 설계 제약조건들에 좌우된다. 숙련된 자들은 설명된 기능성을 각각의 특정 애플리케이션에 대한 다양한 방식들로 구현할 수도 있으나, 그러한 구현 결정들은 본 개시의 범위로부터의 이탈을 초래하는 것으로 해석되지 않아야 한다.
본원에서 설명된 방법론들은 애플리케이션에 따라 다양한 수단들에 의해 구현될 수도 있다. 예를 들면, 이 방법론들은 하드웨어, 펌웨어, 소프트웨어, 또는 이들의 임의의 조합으로 구현될 수도 있다. 하드웨어 구현을 위하여, 프로세싱 유닛들은 하나 이상의 주문형 집적 회로들 (ASIC들), 디지털 신호 프로세서들 (DSP들), 디지털 신호 프로세싱 디바이스들 (DSPD들), 프로그램가능 로직 디바이스들 (PLD들), 필드 프로그램가능 게이트 어레이들 (FPGA들), 프로세서들, 제어기들, 마이크로제어기들, 마이크로프로세서들, 전자 디바이스들, 본원에서 설명된 기능들을 수행하도록 설계된 다른 전자 유닛들, 또는 이들의 조합 내에서 구현될 수도 있다.
펌웨어 및/또는 소프트웨어 구현을 위하여, 방법론들은 본원에서 설명된 기능들을 수행하는 모듈들 (예를 들면, 절차들, 기능들 등) 을 이용하여 구현될 수도 있다. 명령들을 유형으로 구체화하는 임의의 기계 판독가능 매체 또는 컴퓨터 판독가능 매체는 본원에서 설명된 방법론들을 구현함에 있어서 사용될 수도 있다. 예를 들면, 소프트웨어 코드는 메모리에 저장되어 프로세서에 의해 실행될 수도 있다. 프로세서에 의해 실행되면, 실행 소프트웨어 코드는 본원에서 제시된 교시들의 상이한 양태들의 다양한 방법론들 및 기능성들을 구현하는 운영 환경을 생성한다. 메모리는 프로세서 내에서 또는 메모리 외부에서 구현될 수도 있다. 본원에서 사용되는 바와 같이, 용어 "메모리" 는 장기 메모리, 단기 메모리, 휘발성 메모리, 비휘발성 메모리 또는 다른 메모리의 임의의 유형을 지칭하며, 메모리 또는 많은 메모리의 임의의 특정 유형, 또는 메모리가 저장되는 미디어의 유형에 제한되지 않는다.
본원에서 설명된 방법론들 및 기능들을 정의하는 소프트웨어 코드를 저장하는 기계 판독가능 매체 또는 컴퓨터 판독가능 매체는 물리적 컴퓨터 저장 미디어를 포함한다. 저장 매체는 컴퓨터에 의해 액세스될 수 있는 임의의 가용한 매체일 수도 있다. 제한되지는 않는 예로서, 그러한 컴퓨터 판독가능 매체는 RAM, ROM, EEPROM, CD-ROM 또는 다른 광 디스크 스토리지, 자기 디스크 스토리지 또는 다른 자기 스토리지 디바이스들, 또는 명령들 또는 데이터 구조들의 형태로 원하는 프로그램 코드를 저장하기 위해 사용될 수 있고 컴퓨터에 의해 액세스될 수 있는 임의의 다른 매체를 포함할 수 있다. 본원에서 사용되는 바와 같이, 디스크 (disk) 및/또는 디스크 (disc) 는 콤팩트 디스크 (CD), 레이저 디스크, 광 디스크, 디지털 다용도 디스크 (DVD), 플로피 디스크 및 블루레이 디스크를 포함하며, 여기에서 디스크들 (disks) 은 보통 자기적으로 데이터를 재생하고 디스크들 (discs) 은 레이저를 이용하여 데이터를 광학적으로 재생한다. 위에 설명한 것들의 조합들이 또한 컴퓨터 판독가능 매체의 범위 내에 포함되어야 한다.
컴퓨터 판독가능 매체상에 저장되는 것에 부가하여, 명령들 및/또는 데이터는 통신 장치에 포함된 송신 미디어상의 신호들로서 제공될 수도 있다. 예를 들면, 통신 장치는 명령들 및 데이터를 나타내는 신호들을 가지는 송수신기를 포함할 수도 있다. 명령들 및 데이터는 하나 이상의 프로세서들로 하여금 청구항들에서 개요가 서술된 기능들을 구현하게 하도록 구성된다. 그러나, 통신 장치는 컴퓨터 판독가능 매체상의 명령들 및/또는 데이터의 모두를 저장하지 않을 수도 있다.
본 개시는 Wi-Fi/WLAN 또는 다른 무선 네트워크들과 함께 구현될 수도 있다. Wi-Fi/WLAN 신호들에 부가하여, 무선국/이동국은 또한 글로벌 포지셔닝 시스템 (GPS), 갈릴레오 (Galileo), GLONASS, NAVSTAR, QZSS, 이 시스템들의 조합으로부터의 위성들을 사용하는 시스템, 또는 미래에 개발되는 임의의 SPS 로부터 기인할 수도 있는 위성들로부터 신호들을 수신할 수도 있으며, 각각의 시스템은 본원에서 일반적으로 위성 포지셔닝 시스템 (SPS) 또는 GNSS (글로벌 내비게이션 위성 시스템) 이라고 지칭된다. 본 개시는 또한 의성들 (pseudolites) 또는 의성들을 포함하는 시스템들의 조합과 함께 구현될 수도 있다. 본 개시는 또한 펨토셀들 또는 펨토셀들을 포함하는 시스템들의 조합과 함께 구현될 수도 있다.
본원에서 설명된 포지션 결정 기법들은 무선 광역 네트워크 (WWAN), 무선 근거리 네트워크 (WLAN), 무선 사설 네트워크 (WPAN) 등과 같은 다양한 무선 통신 네트워크들과 함께 구현될 수도 있다. 용어 "네트워크" 및 "시스템" 은 종종 상호교환적으로 사용된다. WWAN 은 코드 분할 다중 접속 (CDMA) 네트워크, 시분할 다중 접속 (TDMA) 네트워크, 주파수 분할 다중 접속 (FDMA) 네트워크, 직교 주파수 분할 다중 접속 (OFDMA) 네트워크, 단일 캐리어 주파수 분할 다중 접속 (SC-FDMA) 네트워크, 롱 텀 에볼루션 (LTE) 네트워크, WiMAX (IEEE 802.16) 네트워크 등일 수도 있다. CDMA 네트워크는 cdma2000, 광대역-CDMA (W-CDMA) 등과 같은 하나 이상의 라디오 액세스 기술들을 구현할 수도 있다. cdma2000 는 IS-95, IS-2000, 및 IS-856 표준들을 포함한다. TDMA 네트워크는 이동 통신 세계화 시스템 (GSM), 디지털 어드밴스드 모바일 폰 시스템 (D-AMPS) 또는 일부 다른 RAT 를 구현할 수도 있다. GSM 및 W-CDMA 는 "3세대 파트너십 프로젝트" (3GPP) 라고 명명된 컨소시엄으로부터의 문서들에서 설명된다. cdma2000 는 "3세대 파트너십 프로젝트 2" (3GPP2) 라고 명명된 컨소시엄으로부터의 문서들에서 설명된다. 3GPP 및 3GPP2 문서들은 공개적으로 입수가능하다. WLAN 은 IEEE 802.11x 네트워크일 수도 있으며, WPAN 은 블루투스 네트워크, IEEE 802.15x 또는 네트워크의 일부 다른 유형일 수도 있다. 기법들은 또한 WWAN, WLAN, 및/또는 WPAN 의 임의의 조합과 함께 구현될 수도 있다.
이전의 설명이 주로 GPS 에 대한 것이지만, 본원에서 설명된 방법 및 장치는 다양한 글로벌 위성 포지셔닝 시스템들 (SPS) 과 함께 사용될 수도 있다. 위성 포지셔닝 시스템 (SPS) 은 전형적으로 엔티티들로 하여금 송신기들로부터 수신된 신호들에 적어도 부분적으로 기초하여 지구상에서의 또는 지구 위에서의 그 엔티티들의 위치를 결정하는 것을 가능하게 하기 위하여 포지셔닝된 송신기들의 시스템을 포함한다. 그러한 송신기는 전형적으로 설정된 수의 칩들의 반복되는 의사-랜덤 노이즈 (PN) 코드를 이용하여 마킹된 신호를 송신하며, 지상 기반 제어국들, 사용자 장비 및/또는 우주선들상에 로케이팅될 수도 있다. 특정 예에서, 그러한 송신기들은 지구 궤도를 도는 위성 비행체들 (SV들) 상에 로케이팅될 수도 있다. 예를 들면, 글로벌 포지셔닝 시스템 (GPS), 갈릴레오, 글로나스 (Glonass) 또는 콤파스 (Compass) 와 같은 글로벌 내비게이션 위성 시스템 (GNSS) 의 무리에서의 SV 는 (예를 들면, GPS 에서와 같이 각각의 위성에 대한 상이한 PN 코드들을 이용하거나 또는 글로나스에서와 같이 상이한 주파수들상에 동일한 코드를 이용하여) 무리에서의 다른 SV들에 의해 송신된 PN 코드들로부터 구별가능한 PN 코드로 마킹된 신호를 송신할 수도 있다. 일정한 양태들에 따라서, 본원에서 제시된 기법들은 SPS 에 대한 글로벌 시스템들 (예를 들면, GNSS) 에 한정되지 않는다. 예를 들면, 본원에서 제공된 기법들은, 예를 들면, 일본의 준청전 위성 시스템 (QZSS), 인도의 인도 지역 내비게이션 위성 시스템 (IRNSS), 중국의 베이더우 등과 같은 다양한 지역 시스템들 및/또는 다양한 보강 시스템들 (예를 들면, 하나 이상의 글로벌 및/또는 지역 내비게이션 위성 시스템들과 연관되거나 아니면 이 지역 내비게이션 위성 시스템들에서 사용될 수도 있는 위성 기반 보강 시스템 (SBAS)) 에 적용되거나 아니면 사용될 수도 있다. 제한되지는 않는 예로서, SBAS 는 광역 오차보정 시스템 (WAAS), 유러피안 정지궤도 내비게이션 오버레이 서비스 (EGNOS), 다기능 위성 오차보정 시스템 (MSAS), GPS 지원 정지궤도 보강 내비게이션 또는 GPS 및 정지궤도 보강 내비게이션 시스템 (GAGAN) 및/또는 그와 유사한 것과 같은, 무결성 정보, 상이한 보정들 등을 제공하는 보강 시스템(들)을 포함할 수도 있다. 따라서, 본원에서 사용되는 바와 같이, SPS 는 하나 이상의 글로벌 내비게이션 위성 시스템들, 지역 내비게이션 위성 시스템들, 및/또는 보강 시스템들의 임의의 조합을 포함할 수도 있으며, SPS 신호들은 SPS, SPS와 유사한 것, 및/또는 그러한 하나 이상의 SPS 와 연관된 다른 신호들을 포함할 수도 있다.
방법론들은 의성들 또는 위성들과 의성들의 조합을 활용하는 포지셔닝 결정 시스템들과 함께 사용될 수도 있다. 의성들은 PN 코드 또는 GPS 시간과 동기화될 수도 있는 L-대역 (또는 다른 주파수) 캐리어 신호 상에 변조된 (GPS 또는 CDMA 셀룰러 신호와 유사한) 다른 레인징 코드를 브로드캐스트하는 지상 기반 송신기들이다. 각각의 그러한 송신기는 원격 수신기에 의한 식별을 허용하기 위하여 고유의 PN 코드가 배정될 수도 있다. 의성들은, 터널들, 광산들, 빌딩들, 도심 협곡들 또는 다른 에워싸인 영역들과 같은, 궤도를 선회하는 위성로부터의 신호들이 사용 불가능할 수도 있는 조건들에서 유용하다. 의성들의 다른 구현은 라디오-비컨들로 알려져 있다. 본원에서 사용되는 바와 같이, 용어 "위성" 은 의성들, 의성들의 등가물들, 및 유사한 디바이스들을 포함할 의도를 가진다. 본원에서 사용되는 바와 같이, 용어 "SPS 신호들" 은 의성들 또는 의성들의 등가물들로부터의 SPS 와 유사한 신호들을 포함할 의도를 가진다.
본 개시 내에서 사용된 바와 같이, 모바일 디바이스는 셀룰러 또는 다른 무선 통신 디바이스, 개인 통신 시스템 (PCS) 디바이스, 개인 내비게이션 디바이스 (PND), 개인 정보 관리자 (PIM), 개인 휴대 정보 단말기 (PDA), 랩톱, 태블릿 또는 무선 통신 및/또는 내비게이션 신호들을 수신할 수 있는 다른 적합한 이동국 디바이스와 같은 디바이스를 지칭한다. 용어 "모바일 디바이스" 는 또한, 위성 신호 수신, 어시스턴스 데이터 수신, 및/또는 포지션-관련 프로세싱이 디바이스에서 또는 PND 에서 발생하는지의 여부에 상관없이, 단거리 무선, 적외선, 와이어라인 접속, 또는 다른 접속에 의한 것과 같이, 개인 내비게이션 디바이스 (PND) 와 통신하는 디바이스들을 포함할 의도를 가진다. 또한, "모바일 디바이스" 는 인터넷, WiFi, 또는 다른 네트워크들을 통하는 것과 같이, 그리고 위성 신호 수신, 어시스턴스 수신, 및/또는 포지션-관련 프로세싱이 디바이스에서, 서버에서, 또는 네트워크와 연관된 다른 디바이스에서 발생하는지의 여부에 상관없이, 서버와 통신할 수 있는 무선 통신 디바이스들, 컴퓨터들, 랩톱들 등을 포함하는 모든 디바이스들을 포함할 의도를 가진다. 위에서 설명한 것들의 임의의 동작가능한 조합은 또한 "모바일 디바이스" 로 여겨진다.
이 개시는 예시적인 실시형태들을 포함하지만; 그러나, 다른 구현들도 사용될 수 있다. 무엇인가가 "최적화된다", "요구된다" 라는 지정 또는 다른 지정은 현재의 개시가 최적화된 시스템들 또는 "요구된" 엘리먼트들이 존재하는 시스템들에만 적용된다는 것을 나타내는 것은 아니다 (또는 다른 지정들에 기인한 다른 제한을 나타내는 것은 아니다). 이러한 지정들은 특정의 설명된 구현에만 적용된다. 물론, 많은 구현들이 가능하다. 기법들은 개발중이거나 개발될 프로토콜들을 포함하여 본원에서 논의된 프로토콜들이 아닌 프로토콜들과 함께 사용될 수 있다.
본 개시의 이전의 설명은 이 기술분야의 숙련된 사람이 이 개시를 제작하거나 사용할 수 있도록 하기 위하여 제공된다. 본 개시에 대한 다양한 수정들은 이 기술분야의 숙련된 자들에게 쉽게 명확할 것이며, 본원에서 정의된 일반적인 원리들은 본 개시의 정신 또는 범위를 벗어나지 않고 다른 변형들에 적용될 수도 있다. 따라서, 본 개시는 본원에서 설명된 예들 및 설계들에 제한될 의도를 가지지 않으며 본원에서 개시된 원리들 및 신규한 피쳐들에 일치하는 가장 넓은 범위를 따른다.