ES2770823T3 - Optimizaciones de posicionamiento de acuse de recibo seleccionadas - Google Patents

Optimizaciones de posicionamiento de acuse de recibo seleccionadas Download PDF

Info

Publication number
ES2770823T3
ES2770823T3 ES13760169T ES13760169T ES2770823T3 ES 2770823 T3 ES2770823 T3 ES 2770823T3 ES 13760169 T ES13760169 T ES 13760169T ES 13760169 T ES13760169 T ES 13760169T ES 2770823 T3 ES2770823 T3 ES 2770823T3
Authority
ES
Spain
Prior art keywords
message
acknowledgment
mobile terminal
lpp
request field
Prior art date
Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
Active
Application number
ES13760169T
Other languages
English (en)
Inventor
Ronald Blumstein
Yongjin Jiang
Kirk Burroughs
Current Assignee (The listed assignees may be inaccurate. Google has not performed a legal analysis and makes no representation or warranty as to the accuracy of the list.)
Qualcomm Inc
Original Assignee
Qualcomm Inc
Priority date (The priority date is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the date listed.)
Filing date
Publication date
Application filed by Qualcomm Inc filed Critical Qualcomm Inc
Application granted granted Critical
Publication of ES2770823T3 publication Critical patent/ES2770823T3/es
Active legal-status Critical Current
Anticipated expiration legal-status Critical

Links

Classifications

    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04W—WIRELESS COMMUNICATION NETWORKS
    • H04W64/00—Locating users or terminals or network equipment for network management purposes, e.g. mobility management
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04W—WIRELESS COMMUNICATION NETWORKS
    • H04W4/00—Services specially adapted for wireless communication networks; Facilities therefor
    • H04W4/02—Services making use of location information
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L67/00—Network arrangements or protocols for supporting network services or applications
    • H04L67/50—Network services
    • H04L67/52—Network services specially adapted for the location of the user terminal
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04W—WIRELESS COMMUNICATION NETWORKS
    • H04W4/00—Services specially adapted for wireless communication networks; Facilities therefor
    • H04W4/02—Services making use of location information
    • H04W4/024—Guidance services
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04W—WIRELESS COMMUNICATION NETWORKS
    • H04W4/00—Services specially adapted for wireless communication networks; Facilities therefor
    • H04W4/02—Services making use of location information
    • H04W4/025—Services making use of location information using location based information parameters
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04W—WIRELESS COMMUNICATION NETWORKS
    • H04W4/00—Services specially adapted for wireless communication networks; Facilities therefor
    • H04W4/02—Services making use of location information
    • H04W4/029—Location-based management or tracking services
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04W—WIRELESS COMMUNICATION NETWORKS
    • H04W80/00—Wireless network protocols or protocol adaptations to wireless operation
    • H04W80/08—Upper layer protocols
    • H04W80/085—Upper layer protocols involving different upper layer protocol versions, e.g. LCS - SUPL or WSN-SOA-WSDP

Landscapes

  • Engineering & Computer Science (AREA)
  • Computer Networks & Wireless Communication (AREA)
  • Signal Processing (AREA)
  • Mobile Radio Communication Systems (AREA)
  • Position Fixing By Use Of Radio Waves (AREA)
  • Detection And Prevention Of Errors In Transmission (AREA)

Abstract

Un procedimiento realizado por un servidor de localización en un entorno de plano de control de protocolo de posicionamiento de evolución a largo plazo, LPP, comprendiendo el procedimiento: generar (202) un mensaje que contiene datos de asistencia que un terminal móvil va a procesar y un campo de petición de acuse de recibo; determinar si el terminal móvil (120) solicita el mensaje; establecer, en base a dicha determinación, el campo de petición de acuse de recibo en el mensaje para indicar que se requiere acuse de recibo cuando el terminal móvil solicita el mensaje y para indicar que no se requiere acuse de recibo cuando el terminal móvil no solicita el mensaje; y transmitir (204) el mensaje desde el servidor de localización al terminal móvil (120).

Description

DESCRIPCIÓN
Optimizaciones de posicionamiento de acuse de recibo seleccionadas
ANTECEDENTES
Campo de antecedentes
[0001] Los modos de realización de la materia objeto descrita en el presente documento están relacionados en general con la generación y la transmisión de mensajes que contienen datos de asistencia, y más en particular con el requerimiento selectivo de acuse de recibo de un mensaje que contiene datos de asistencia en base a si el mensaje se solicita o no se solicita.
Antecedentes pertinentes
[0002] A menudo es deseable, y a veces necesario, conocer la ubicación de un terminal, por ejemplo, un teléfono móvil. Los términos "ubicación" y "posición" son sinónimos y se usan de manera intercambiable en el presente documento. Por ejemplo, un cliente de servicios de localización (LCS) puede desear conocer la ubicación del terminal. El terminal (por ejemplo, un equipo de usuario (UE), una estación móvil (MS), un terminal habilitado para plano de usuario seguro (SUPL) (SET), etc.) se puede comunicar entonces con un servidor de localización para obtener una estimación de localización para el terminal. El terminal o el servidor de localización pueden presentar entonces la estimación de localización al cliente LCS.
[0003] Se puede ejecutar un flujo de mensajes (que también se puede denominar flujo de llamadas o procedimiento) para establecer una sesión de localización cada vez que el cliente LCS desea conocer la ubicación del terminal. Se pueden intercambiar diversos mensajes entre el terminal y el servidor de localización por medio de una o más entidades de red para el flujo de mensajes. Estos mensajes pueden seguir un protocolo de posicionamiento tal como el protocolo de posicionamiento de evolución a largo plazo (LPP) definido por el Proyecto de Colaboración de Tercera Generación (3GPP) o el protocolo de ampliaciones LPP (LPPe) que la Alianza Móvil Abierta (OMA) está definiendo. Los mensajes pueden transferir datos de asistencia desde el servidor de localización al terminal para ayudar al terminal a obtener mediciones relacionadas con la localización (por ejemplo, mediciones de señales de satélites GPS) y/o calcular una estimación de localización a partir de estas mediciones. Los mensajes también pueden transferir información de localización (por ejemplo, mediciones o una estimación de localización) desde el terminal al servidor de localización para permitir que el servidor de localización determine la ubicación del terminal.
Sumario
[0004] De acuerdo con la presente invención, se proporciona un procedimiento y un aparato para optimizaciones de posicionamiento de acuse de recibo seleccionadas, tal como se expone en las reivindicaciones independientes. Los modos de realización preferentes se describen en las reivindicaciones dependientes.
[0005] Un servidor de localización, tal como un centro de localización de móviles en servicio (SMLC) o E-SMLC y un terminal móvil implementan selectivamente el mecanismo de transporte fiable usado, por ejemplo, en los protocolos LPP o LPPe, disminuyendo de ese modo los retardos innecesarios. El mecanismo de transporte fiable se puede implementar selectivamente ya que no requiere un acuse de recibo para mensajes específicos, tal como un mensaje de datos de asistencia no solicitado. Sin embargo, cuando se solicitan datos de asistencia, el mensaje de datos de asistencia de respuesta incluye una petición de acuse de recibo según el mecanismo de transporte fiable.
[0006] En una implementación, un procedimiento incluye generar un mensaje con un servidor de localización en un entorno de plano de control LPP, conteniendo el mensaje datos de asistencia y un campo de petición de acuse de recibo, en el que el campo de petición de acuse de recibo indica que se requiere un acuse de recibo cuando un terminal móvil solicita el mensaje y el campo de petición de acuse de recibo indica que no se requiere acuse de recibo cuando el terminal móvil no solicita el mensaje; y transmitir el mensaje desde el servidor de localización al terminal móvil.
[0007] En una implementación, un aparato incluye un transceptor para transferir mensajes a un dispositivo móvil; y un procesador conectado al transceptor, estando adaptado el procesador para generar un mensaje en un entorno de plano de control LPP, conteniendo el mensaje datos de asistencia y un campo de petición de acuse de recibo, en el que el campo de petición de acuse de recibo indica que se requiere un acuse de recibo cuando un terminal móvil solicita el mensaje y el campo de petición de acuse de recibo indica que no se requiere un acuse de recibo cuando el terminal móvil no solicita el mensaje, y para transmitir el mensaje al terminal móvil con el transceptor.
[0008] En una implementación, un aparato incluye medios para generar un mensaje en un entorno de plano de control LPP, conteniendo el mensaje datos de asistencia y un campo de petición de acuse de recibo, en el que el campo de petición de acuse de recibo indica que se requiere un acuse de recibo cuando un terminal móvil solicita el mensaje y el campo de petición de acuse de recibo indica que no se requiere acuse de recibo cuando el terminal móvil no solicita el mensaje; y medios para transmitir el mensaje al terminal móvil.
[0009] En una implementación, un medio no transitorio legible por ordenador que incluye un código de programa almacenado en él incluye un código de programa para generar un mensaje en un entorno de plano de control LPP, conteniendo el mensaje datos de asistencia y un campo de petición de acuse de recibo, en el que el campo de petición de acuse de recibo indica que se requiere acuse de recibo cuando un terminal móvil solicita el mensaje y el campo de petición de acuse de recibo indica que no se requiere acuse de recibo cuando el terminal móvil no solicita el mensaje; y código de programa para transmitir el mensaje al terminal móvil.
[0010] En una implementación, un procedimiento incluye recibir desde un servidor de localización un mensaje no solicitado en un entorno de plano de control LPP, conteniendo el mensaje no solicitado datos de asistencia y un campo de petición de acuse de recibo, en el que el campo de petición de acuse de recibo indica que no se requiere acuse de recibo; procesar los datos de asistencia contenidos en el mensaje no solicitado; y esperar un mensaje posterior desde el servidor de localización sin transmitir un acuse de recibo del mensaje no solicitado.
[0011] En una implementación, un aparato incluye un transceptor para recibir y transmitir mensajes a un servidor de localización; y un procesador conectado al transceptor, estando adaptado el procesador para recibir con el transceptor un mensaje no solicitado desde un servidor de localización en un entorno de plano de control LPP, conteniendo el mensaje no solicitado datos de asistencia y un campo de petición de acuse de recibo, en el que el campo de petición de acuse de recibo indica que no se requiere acuse de recibo, procesar los datos de asistencia contenidos en el mensaje no solicitado, y esperar un mensaje posterior desde el servidor de localización sin transmitir un acuse de recibo del mensaje no solicitado.
[0012] En una implementación, un aparato incluye medios para recibir desde un servidor de localización un mensaje no solicitado en un entorno de plano de control LPP, conteniendo el mensaje no solicitado datos de asistencia y un campo de petición de acuse de recibo, en el que el campo de petición de acuse de recibo indica que no se requiere acuse de recibo; medios para procesar los datos de asistencia contenidos en el mensaje no solicitado; y medios para esperar un mensaje posterior desde el servidor de localización sin transmitir un acuse de recibo del mensaje no solicitado.
[0013] En una implementación, un medio no transitorio legible por ordenador que incluye un código de programa almacenado en él, incluye un código de programa para recibir desde un servidor de localización un mensaje no solicitado en un entorno de plano de control LPP, conteniendo el mensaje no solicitado datos de asistencia y un campo de petición de acuse de recibo, en el que el campo de petición de acuse de recibo indica que no se requiere acuse de recibo; un código de programa para procesar los datos de asistencia contenidos en el mensaje no solicitado; y un código de programa para esperar un mensaje posterior desde el servidor de localización sin transmitir un acuse de recibo del mensaje no solicitado.
BREVE DESCRIPCIÓN DE LOS DIBUJOS
[0014]
La fig. 1 muestra una arquitectura de red capaz de implementar selectivamente un mecanismo de transporte fiable, tal como el usado en los protocolos de posicionamiento LPP/LPPe.
La fig. 2 ilustra un flujo de llamadas LPP convencional que usa el mecanismo de transporte fiable para transmitir datos de asistencia no solicitados.
La fig. 3 ilustra un modo de realización de un flujo de llamadas LPP con el mecanismo de transporte fiable implementado selectivamente en un mensaje de datos de asistencia no solicitado.
La fig. 4 ilustra un flujo de llamadas LPP convencional que usa el mecanismo de transporte fiable para transmitir un mensaje de error.
La fig. 5 ilustra un modo de realización de un flujo de llamadas LPP con el mecanismo de transporte fiable implementado selectivamente en un mensaje de error no solicitado.
La fig. 6 es un diagrama de flujo que ilustra un procedimiento de implementación selectiva del mecanismo de transporte fiable usado con LPP/LPPe.
La fig. 7 es otro diagrama de flujo que ilustra el punto de decisión en la implementación selectiva del mecanismo de transporte fiable usado con LPP/LPPe.
La fig. 8 es un diagrama de bloques esquemático que ilustra determinadas características de ejemplo de un servidor de localización que implementa selectivamente el mecanismo de transporte LPP/LPPe fiable.
La fig. 9 es un diagrama de flujo que ilustra un procedimiento de la implementación selectiva del mecanismo de transporte LPP/LPPe fiable recibido por un terminal móvil.
La fig. 10 es un diagrama de bloques esquemático que ilustra determinadas características de ejemplo de un terminal móvil que está configurado para recibir mensajes desde un servidor de localización que implementa selectivamente el mecanismo de transporte LPP/LPPe fiable.
DESCRIPCIÓN
[0015] La fig. 1 muestra una arquitectura de red 100 capaz de implementar selectivamente un mecanismo de transporte fiable, como el usado en LPP/LPPe, en mensajes entre un terminal móvil 120 (a veces denominado UE, MS, SET, etc. o en general "objetivo") y un servidor de localización 150 (a veces denominado servidor o centro de localización de móviles en servicio (SMLC) o E-SMLC. El terminal móvil 120 se puede comunicar con el servidor de localización 150 a través de una red 130 usando una red de acceso por radio (RAN) 140, que está asociada con la red 130 para servicios de posicionamiento y localización. El terminal móvil 120 puede recibir y medir señales desde una RAN 140, que se puede usar para la determinación de posición. El terminal móvil 120 también puede recibir señales desde uno o más vehículos satélite (SV) en órbita terrestre 180, que forman parte del sistema de posicionamiento por satélite (SPS). El terminal móvil 120 puede medir señales SV 180 y/o RAN 140 asociadas con la red 130 y puede obtener mediciones de pseudoalcance para los satélites y mediciones desde unas RAN 140. Las mediciones de pseudoalcance y/o las mediciones de red se pueden usar para obtener una estimación de posición para el terminal móvil 120. El servidor de localización 150 se puede usar para proporcionar información relacionada con localización, tal como datos de asistencia, al terminal móvil 120, que se puede usar para ayudar a adquirir y medir señales de unos SV 180 y unas RAN 140 y/o para obtener una estimación de posición a partir de estas mediciones. Adicionalmente, el terminal móvil 120 puede proporcionar información relacionada con localización, tal como una posición estimada o unas mediciones de localización (por ejemplo, mediciones de satélite desde uno o más GNSS, o mediciones de red desde una o más redes, etc.), al servidor de localización 150.
[0016] Un terminal móvil como se usa en el presente documento es un dispositivo capaz de comunicarse inalámbricamente con un servidor a través de una o más redes y que admite servicios de posicionamiento y localización, que pueden incluir, pero no se limitan a, la solución de localización de plano de usuario seguro (SUPL), definida por la OMA y la solución de localización de plano de control, definida por el 3GPP para su uso con una red de servicio LTE. La solución de localización SUPL se define en los documentos OMA-TS-ULP-V2 0-20110527-C y OMA-TS-ULP-V3_0-20110819-D de la OMA que están disponibles para el público. La solución de localización de plano de control para LTE se define en 3GPP TS 23.271 y 3GPP TS 36.305, que están disponibles para el público. Los servicios de localización (LCS) se pueden realizar en nombre de un cliente LCS 160 que accede al servidor de localización 150 y emite una petición para la localización del terminal móvil 120 y recibe del servidor de localización 150 una estimación de localización para el terminal móvil 120. El cliente LCS 160 también se puede conocer como agente SUPL, por ejemplo, cuando la solución de localización usada por el servidor de localización 150 y el terminal móvil 120 es SUPL. El terminal móvil 120 también puede incluir un cliente LCS o un agente SUPL (no mostrado en la fig. 1A) que puede emitir una petición de localización para alguna función con capacidad de localización dentro del terminal móvil 120 y posteriormente recibir una estimación de localización para el terminal móvil 120. El cliente LCS o el agente SUPL dentro del terminal móvil 120 puede realizar servicios de localización para el usuario del terminal móvil 120 ; por ejemplo, proporcionar instrucciones de navegación o identificar puntos de interés en las inmediaciones del terminal móvil 120.
[0017] La arquitectura de red 100 puede usar, por ejemplo, el protocolo LPP para posicionamiento. El protocolo LPP se describe en la especificación técnica (TS) 3GPP 36.355, que está disponible para el público. Los mensajes elementales LPP (de petición y provisión de capacidades e información de localización y datos de asistencia) incluyen cada uno un contenedor, una EPDU, que se puede usar mediante estandarización fuera de 3GPP para definir sus propias ampliaciones de mensajes LPP. Las ampliaciones OMA LPP (LPPe) aprovechan esta opción. OMA está definiendo las LPPe y estas se usarían en combinación con el LPP, de modo que cada mensaje LPP/LPPe combinado sería un mensaje LPP (como se define en 3GPP TS 36.355) que contiene un mensaje LPPe integrado. Por tanto, como se usa en el presente documento, el entorno del plano de control LPP incluye LPPe y se puede denominar LPP/LPPe o simplemente LPP.
[0018] La sección 4.3.1 del estándar LPP describe un mecanismo de transporte fiable y establece que "LPP requiere una entrega en secuencia fiable de mensajes LPP desde las capas de transporte subyacentes.... Un UE que implementa LPP para la solución de plano de control admitirá un transporte LPP fiable (incluyendo las tres de detección, acuse de recibo y retransmisión duplicados)". Para admitir la parte de retransmisión de transporte fiable, el estándar establece en la sección 4.3.4.1 "cuando un mensaje LPP que requiere acuse de recibo se envía y no se acusa recibo del mismo, el emisor lo reenvía después de un período de tiempo de espera hasta tres veces". El procedimiento de transporte fiable requiere la entrega en secuencia fiable de mensajes LPP desde las capas de transporte subyacentes. Por lo tanto, los mecanismos de transporte fiable convencionales en el plano de control del entorno LPP requieren que se acuse recibo de los mensajes y que si no se acusa recibo de un mensaje, el emisor retransmita el mensaje después de un período de tiempo de espera hasta tres veces. Cuando se envía un mensaje LPP que requiere acuse de recibo y no se acusa recibo de este, el emisor reenvía el mensaje después de un período de tiempo de espera, hasta tres veces. Si después de tres veces, sigue sin acusarse recibo del mensaje, el emisor cancelará toda la actividad LPP para la sesión asociada. El período de tiempo de espera viene determinado por la implementación del emisor, pero no es inferior a un valor mínimo de 250 ms.
[0019] Por tanto, el requisito de retransmisión tiene el potencial de retardar una sesión de localización de plano de control. En determinadas situaciones, el servidor de localización 150, por ejemplo, un centro de localización de móviles en servicio (SMLC) o E-SMLC, puede enviar información de datos de asistencia no solicitada para ayudar al terminal móvil 120 en una sesión de posición. Si se pierde esta información de datos de asistencia no solicitada y se implementan mecanismos de transporte fiables, la sesión puede retardarse innecesariamente. Un retardo en la sesión, en general no es deseable, e incluso puede impedir la finalización de la sesión dentro de las limitaciones de tiempo de un tipo de flujo de llamadas de servicios de emergencia.
[0020] En consecuencia, la arquitectura de red 100 es capaz de implementar selectivamente el mecanismo de transporte LPP/LPPe fiable en mensajes entre el terminal móvil 120 y el servidor de localización 150. El mecanismo de transporte fiable se puede realizar selectivamente ya que no requiere un acuse de recibo para mensajes específicos. A modo de ejemplo, el servidor de localización 150 puede enviar mensajes de datos de asistencia no solicitados al terminal móvil 120 sin una petición de acuse de recibo. Por otro lado, cuando el terminal móvil 120 solicita datos de asistencia, el servidor de localización 150 envía un mensaje de datos de asistencia solicitado al terminal móvil 120 con una petición de acuse de recibo. Si se desea, también se puede enviar un mensaje de error no solicitado desde el servidor de localización 150 sin una petición de acuse de recibo.
[0021] La fig. 2 ilustra, a modo de ejemplo, un flujo de llamadas LPP convencional que usa el mecanismo de transporte fiable para transmitir datos de asistencia no solicitados, por ejemplo, en las etapas e-l. El flujo de llamadas de la fig. 2 se describe como sigue:
Etapa a: El servidor de localización (LS) envía un mensaje LPP Solicitar capacidades que requiere acusar recibo al terminal móvil, es decir, el equipo de usuario (UE). El servidor de localización también inicia el temporizador Tcap para asegurar que recibe las capacidades de UE a su debido tiempo.
Etapa b: El UE responde con un acuse de recibo explícito.
Etapa c: El UE proporciona el mensaje LPP Proporcionar capacidades.
Etapa d: El LS detiene el temporizador Tcap y responde con un acuse de recibo explícito.
Etapa e: El LS envía un mensaje LPP Proporcionar datos de asistencia no solicitado. Siguiendo los procedimientos de transporte fiables, el LS solicita acuse de recibo e inicia el temporizador Tack.
Etapa f-k: El UE responde con un acuse de recibo explícito que de alguna manera no llega al LS (etapas f, j) o el UE no responde con un acuse de recibo explícito (etapa h). En cada caso, después de la expiración del temporizador Tack, el LS retransmite el mensaje LPP no solicitado Proporcionar datos de asistencia, por ejemplo, etapas g, i y k. Etapa l: El UE responde con un acuse de recibo explícito que finalmente llega al LS. Aunque el UE recibe los datos de asistencia, si el ACK en la etapa i tampoco llega al LS, el flujo de llamadas tendrá que cancelarse innecesariamente al expirar Tack.
Etapa m: El LS envía el mensaje LPP Solicitar información de localización al UE.
Etapa n: El UE responde con un acuse de recibo explícito.
Etapa o: El UE puede solicitar opcionalmente datos de asistencia adicionales si los datos de asistencia proporcionados en las etapas i, k no contenían suficientes datos de asistencia.
Etapa p: El LS responde con un acuse de recibo explícito.
Etapa q: El LS envía el mensaje solicitado LPP Proporcionar datos de asistencia.
Etapa r: El UE responde con un acuse de recibo explícito.
Etapa s: El UE envía el mensaje solicitado Proporcionar información de localización.
Etapa t: El LS detiene el temporizador Tresp y responde con un acuse de recibo explícito.
[0022] Por tanto, como se ilustra en la fig. 2, las etapas f-l añaden retardos innecesarios en la sesión de posicionamiento. El mensaje no solicitado de datos de asistencia no es un mensaje obligatorio en la sesión de posicionamiento. Si el UE no recibe el mensaje no solicitado de datos de asistencia, el UE tiene una posibilidad de solicitar los datos de asistencia que faltan en la etapa o. El problema se agrava aún más por el hecho de que muchos UE no pueden conectar sus receptores GNSS hasta la etapa m, retardando por tanto aún más la sesión de posicionamiento.
[0023] Para evitar retardos innecesarios como se describe anteriormente, un servidor de localización 150 puede implementar selectivamente el mecanismo de transporte fiable, estableciendo la petición de acuse de recibo en False cuando no se solicita un mensaje de datos de asistencia. Esto también tiene el efecto de inhabilitar el procedimiento de retransmisión. Se debe entender que esto es aplicable tanto a la señalización LPP como a la señalización LPPe, lo que a veces se puede denominar conjuntamente en el presente documento LPP o LPP/LPPe simplemente. Por ejemplo, esto es aplicable a cualquier mensaje LPP en el que la EPDU se usa como contenedor para la carga útil LPPe.
[0024] La fig. 3 ilustra un flujo de llamadas LPP con el mecanismo de transporte fiable implementado selectivamente con el servidor de localización 150 que envía un mensaje de datos de asistencia no solicitado sin solicitar un acuse de recibo del terminal móvil 120. Después de enviar el mensaje de datos de asistencia no solicitado, el servidor de localización 150 puede enviar de inmediato un mensaje LPP Solicitar información de localización para permitir que el UE comience a recopilar mediciones, evitando de este modo retardos innecesarios. La fig. 3 se describe como sigue: Etapa a: El servidor de localización (LS) envía un mensaje LPP Solicitar capacidades que requiere acusar recibo al terminal móvil, es decir, al equipo de usuario (UE), es decir, ackRequest se establece en True. El servidor de localización también inicia el temporizador Tcap para asegurar que recibe las capacidades de UE a su debido tiempo. Etapa b: El UE responde con un acuse de recibo explícito.
Etapa c: El UE proporciona el mensaje LPP Proporcionar capacidades.
Etapa d: El LS detiene el temporizador Tcap y responde con un acuse de recibo explícito.
Etapa e: El LS envía un mensaje LPP Proporcionar datos de asistencia no solicitado. En este caso, el LS no sigue el mecanismo de transporte de fiabilidad y no solicita un acuse de recibo, es decir, ackRequest se establece en False, ni inicia el temporizador de respuesta Tack.
Etapa f: El LS envía el mensaje LPP Solicitar información de localización al UE sin haber recibido primero un acuse de recibo del mensaje anterior de la etapa e.
Etapa g: El UE responde con un acuse de recibo explícito.
Etapa h: El UE puede solicitar opcionalmente datos de asistencia adicionales si los datos de asistencia proporcionados en la etapa e no contenían suficientes datos de asistencia.
Etapa i: El LS responde con un acuse de recibo explícito.
Etapa j: El LS envía el mensaje LPP Proporcionar datos de asistencia solicitado, con una petición de acuse de recibo, es decir, ackRequest se establece en True.
Etapa k: El UE responde con un acuse de recibo explícito.
Etapa l: El UE envía el mensaje solicitado Proporcionar información de localización.
Etapa m: El LS detiene el temporizador Tresp y responde con un acuse de recibo explícito.
[0025] Si se desea, el servidor de localización 150 puede implementar selectivamente el mecanismo de transporte fiable para otros mensajes, tales como mensajes de error, también. A modo de ejemplo, la fig. 4 ilustra un flujo de llamadas LPP convencional que usa el mecanismo de transporte fiable para transmitir un mensaje de error en las etapas c-j. El flujo de llamadas de la fig. 4 se describe como sigue:
Etapa a: El servidor de localización (LS) recibe un mensaje LPP de enlace ascendente que requiere acuse de recibo del terminal móvil, es decir, el equipo de usuario (UE). El servidor de localización determina que el mensaje recibido es erróneo (por ejemplo, error de decodificación, tipo de mensaje no válido o ausencia de IE significativo, etc.) Etapa b: El LS responde con un acuse de recibo explícito (si es posible).
Etapa c: El LS envía un mensaje LPP Error de enlace descendente que incluye el tipo de error y la petición de acuse de recibo del UE, es decir, ackRequest se establece en True. El LS inicia el temporizador Tack.
Etapa d-i: Suponiendo que el mensaje LPP Error de enlace descendente llega al UE, si el UE encuentra que el mensaje LPP Error de enlace descendente es erróneo, el UE puede no enviar un mensaje LPP Acuse de recibo explícito (etapa d); o el mensaje LPP Acuse de recibo explícito enviado por el UE puede perderse debido a un transporte defectuoso en la red (etapas f y h). Después de la expiración del temporizador Tack, el LS retransmite el mensaje LPP Error de enlace descendente y reinicia el temporizador Tack (etapa e, g e i), hasta 3 veces. El LS no puede continuar con los posteriores mensajes LPP en el enlace descendente hasta que no recibe un acuse de recibo al mensaje LPP Error.
Etapa j: El UE responde con un acuse de recibo explícito que finalmente llega al LS. Si el acuse de recibo en la etapa j tampoco llega al LS, el flujo de llamadas se tendrá que cancelar cuando expire Tack, a veces innecesariamente (por ejemplo, la carga útil en el mensaje UL LPP erróneo en la etapa a todavía podría ser usable para avanzar con el flujo de llamadas, a pesar de un error en la cabecera).
Etapa k: El flujo de llamadas continúa con el siguiente mensaje DL LPP (si lo hubiera).
[0026] Por tanto, como se ilustra en la fig. 4, las etapas d-i pueden añadir retardos innecesarios en la sesión de posicionamiento, porque el LS no recibió el acuse de recibo explícito en el enlace ascendente.
[0027] Para evitar retardos innecesarios como se describe anteriormente, un servidor de localización 150 puede implementar selectivamente el mecanismo de transporte fiable para un mensaje de error no solicitado. La fig. 5 ilustra un flujo de llamadas LPP que implementa selectivamente el mecanismo de transporte fiable en el que el servidor envía el mensaje LPP Error de enlace descendente sin solicitar un acuse de recibo del UE. El servidor de localización 150 puede proceder de inmediato a enviar el siguiente mensaje LPP de enlace descendente si es necesario según el flujo de llamadas. La fig. 5 se describe como sigue:
Etapa a: El servidor de localización (LS) recibe un mensaje LPP de enlace ascendente que requiere acuse de recibo del terminal móvil, es decir, el equipo de usuario (UE). El servidor de localización 150 determina que el mensaje recibido es erróneo (por ejemplo, error de descodificación, tipo de mensaje no válido o ausencia de IE significativo, etc.).
Etapa b: El LS responde con un acuse de recibo explícito (si es posible).
Etapa c: El LS envía un mensaje LPP Error de enlace descendente que incluye el tipo de error; sin embargo, el LS no solicita acuse de recibo del UE, es decir, ackRequest se establece en False.
Etapa d: El flujo de llamadas continúa con el mensaje DL LPP posterior (si lo hubiera), sin requerir un acuse de recibo del mensaje previo de la etapa c.
[0028] El UE puede no recibir el mensaje LPP Error de enlace descendente de la etapa c (que no requiere acuse de recibo). Si el UE recibe el LPP ACK (etapa b), pero no el mensaje LPP Error de enlace descendente, y el mensaje LPP en la etapa a requiere una respuesta (por ejemplo, un mensaje LPP Solicitar AD), algún tipo de temporizador de guarda del UE (si existe) finalmente expirará. El UE tiene que avanzar sin los datos de asistencia solicitados. Si el mensaje LPP en la etapa a no requiere una respuesta (por ejemplo, el mensaje LPP Proporcionar información de localización o el mensaje LPP Proporcionar capacidad), el UE terminará la transacción sin siquiera darse cuenta del error en el mensaje LPP en la etapa a. En el lado del LS, en caso de que el mensaje LPP erróneo en la etapa a sea un mensaje Proporcionar capacidad, suponiendo que dicho error impide que el LS avance a la etapa d (por ejemplo, para enviar un mensaje LPP Solicitar información de localización), el LS no retransmitirá la etapa c; por lo tanto, la sesión finalmente fallará. En el lado del LS, en caso de que el mensaje LPP erróneo en la etapa a sea un mensaje Proporcionar información de localización, lo más probable es que no haya una etapa d en el flujo de llamadas. Si la carga útil en el mensaje Proporcionar información de localización no es usable, el LS puede tener que presentar una solución basada en célula/sector a la MME. Si el UE no recibe el LPP ACK (etapa b), el UE debe retransmitir la etapa a al expirar el Tack del UE.
[0029] La fig. 6 es un diagrama de flujo que ilustra un procedimiento de implementación selectiva del mecanismo de transporte fiable usado con LPP/LPPe. Como se ilustra, un servidor de localización genera un mensaje en un entorno de plano de control LPP, conteniendo el mensaje datos de asistencia y un campo de petición de acuse de recibo, en el que el campo de petición de acuse de recibo indica que se requiere acuse de recibo cuando un terminal móvil solicita el mensaje y el campo de petición de acuse de recibo indica que no se requiere acuse de recibo cuando el terminal móvil (202) no solicita el mensaje. El mensaje se transmite desde el servidor de localización al terminal móvil (204). Se debe entender que el entorno del plano de control LPP incluye LPPe. El mensaje se puede segmentar en una pluralidad de segmentos de mensaje, en el que uno o más de los segmentos de mensaje de la pluralidad de segmentos de mensaje contiene un campo de petición de acuse de recibo que indica que se requiere acuse de recibo cuando el terminal móvil solicita el mensaje e indica que no se requiere acuse de recibo cuando el terminal móvil no solicita el mensaje. Por ejemplo, cada segmento de mensaje de la pluralidad de segmentos de mensaje puede incluir un campo de petición de acuse de recibo que indica que se requiere acuse de recibo cuando el terminal móvil solicita el mensaje e indica que no se requiere acuse de recibo cuando el terminal móvil no solicita el mensaje. En otro modo de realización, solo el último segmento de la pluralidad de segmentos de mensaje puede contener el campo de petición de acuse de recibo. El procedimiento puede incluir además enviar un mensaje posterior al terminal móvil sin recibir un mensaje de acuse de recibo del terminal móvil. El procedimiento también puede incluir generar un segundo mensaje, que es un mensaje de error que contiene un segundo campo de petición de acuse de recibo que indica que no se requiere acuse de recibo.
[0030] La fig. 7 es otro diagrama de flujo que ilustra el punto de decisión en la implementación selectiva del mecanismo de transporte fiable usado con LPP/LPPe. Como se ilustra, un servidor de localización genera un mensaje LPP Proporcionar datos de asistencia. Como se ilustra mediante el punto de decisión 222, si el equipo del usuario solicita el mensaje LPP, el campo LPP Solicitar acuse de recibo se establece en True (224), mientras que si el equipo de usuario no solicita el mensaje LPP, el campo LPP Solicitar acuse de recibo se establece en False (226). El mensaje LPP Proporcionar datos de asistencia se transmite entonces al equipo de usuario (228).
[0031] A continuación, se hace referencia a la fig. 8, que es un diagrama de bloques esquemático que ilustra determinadas características de ejemplo del servidor de localización 150, por ejemplo, E-SMLC, que está habilitado para evitar retardos innecesarios implementando selectivamente el mecanismo de transporte LPP/LPPe fiable como se ha analizado anteriormente. El servidor de localización 150 puede, por ejemplo, incluir una o más unidades de procesamiento 352, una memoria 354 y un transceptor 360 (por ejemplo, una interfaz de red alámbrica o inalámbrica), que pueden estar acoplados operativamente con una o más conexiones 356 (por ejemplo, buses, líneas, fibras, enlaces, etc.). En determinadas implementaciones de ejemplo, la totalidad o una parte del servidor de localización 150 puede adoptar la forma de un conjunto de chips y/o similares. El transceptor 360 puede incluir un transmisor 362 y un receptor 364 que admiten la transmisión y/o la recepción alámbrica y, si se desea, pueden admitir, de forma adicional o alternativa, la transmisión y la recepción de una o más señales a través de uno o más tipos de redes de comunicación inalámbrica.
[0032] La unidad de procesamiento 352 se puede implementar usando una combinación de hardware, firmware y software. La unidad de procesamiento 352 puede incluir una unidad de mensajes 366 que puede generar mensajes, tales como un mensaje de datos de asistencia, mensaje de error, etc., y una unidad de selección de acuse de recibo 368 que se usa para solicitar selectivamente un acuse de recibo, por ejemplo, indicando que el acuse de recibo no se requiere en el campo de acuse de recibo en mensajes de datos de asistencia no solicitados y mensajes de error. Al seleccionar para indicar que no se requiere acuse de recibo, el servidor de localización 150 puede implementar selectivamente el mecanismo de transporte LPP/LPPe fiable así como inhabilitar el procedimiento de retransmisión. La unidad de mensajes 366 y la unidad de selección de acuse de recibo 368 se pueden implementar en hardware, firmware y software o una combinación de los mismos.
[0033] Las metodologías descritas en el presente documento en diagramas de flujo y flujos de mensajes se pueden implementar por diversos medios, dependiendo de la aplicación. Por ejemplo, estas metodologías se pueden implementar en hardware, firmware, software o en cualquier combinación de los mismos. Para una implementación en hardware, la unidad de procesamiento 352 se puede implementar dentro de uno o más circuitos integrados específicos de la aplicación (ASIC), procesadores de señales digitales (DSP), dispositivos de procesamiento de señales digitales (DSPD), dispositivos lógicos programables (PLD), matrices de puertas programables in situ (FPGA), procesadores, controladores, microcontroladores, microprocesadores, dispositivos electrónicos, otras unidades electrónicas diseñadas para realizar las funciones descritas en el presente documento, o una combinación de los mismos.
[0034] En una implementación en firmware y/o software, las metodologías se pueden implementar con módulos (por ejemplo, procedimientos, funciones, etc.) que realizan las funciones descritas en el presente documento. Cualquier medio legible por máquina que realiza instrucciones de forma tangible se puede usar para implementar las metodologías descritas en el presente documento. Por ejemplo, los códigos de software se pueden almacenar en un medio no transitorio legible por ordenador 370 o en una memoria 354 que está conectada a, y es ejecutada por, una unidad de procesamiento 352. La memoria se puede implementar dentro de la unidad de procesador o fuera de la unidad de procesamiento. Como se usa en el presente documento, el término "memoria" se refiere a cualquier tipo de memoria de largo plazo, de corto plazo, volátil, no volátil o uno diferente, y no se debe limitar a ningún tipo de memoria o número de memorias en particular, ni al tipo de medio en el que se almacena la memoria.
[0035] Si se implementa en firmware y/o software, las funciones se pueden almacenar como una o más instrucciones 358 o código en un medio no transitorio legible por ordenador, tal como el medio legible por ordenador 370 y/o la memoria 354. Los ejemplos incluyen medios legibles por ordenador codificados con una estructura de datos y medios legibles por ordenador codificados con un programa informático. Los medios no transitorios legibles por ordenador incluyen medios físicos de almacenamiento informático. Un medio de almacenamiento puede ser cualquier medio no transitorio disponible al que se puede acceder mediante un ordenador. A modo de ejemplo, y no de limitación, dichos medios no transitorios legibles por ordenador pueden comprender RAM, ROM, EEPROM, CD-ROM u otro almacenamiento de disco óptico, almacenamiento de disco magnético u otros dispositivos de almacenamiento magnético, o cualquier otro medio que se pueda usar para almacenar código de programa deseado en forma de instrucciones o estructuras de datos y al que se puede acceder mediante un ordenador; como se usa en el presente documento, un disco incluye un disco compacto (CD), un disco láser, un disco óptico, un disco versátil digital (DVD), un disco flexible y un disco Blu-ray, de los cuales los discos flexibles normalmente reproducen datos magnéticamente, mientras que los demás discos reproducen datos ópticamente con láseres. Las combinaciones de los anteriores también se deben incluir dentro del alcance de los medios legibles por ordenador.
[0036] Además de almacenarse en un medio legible por ordenador, las Instrucciones y/o los datos se pueden proporcionar como señales en medios de transmisión incluidos en un aparato de comunicación. Por ejemplo, un aparato de comunicación puede incluir un transceptor que tiene señales que indican instrucciones y datos. Las instrucciones y los datos están configurados para hacer que uno o más procesadores implementen las funciones descritas de forma general en el presente documento. Es decir, el aparato de comunicación incluye medios de transmisión con señales indicativas de información para realizar las funciones divulgadas.
[0037] La memoria 354 puede representar cualquier mecanismo de almacenamiento de datos. La memoria 354 puede incluir, por ejemplo, una memoria principal y/o una memoria secundaria. La memoria principal puede incluir, por ejemplo, memoria de acceso aleatorio, memoria de solo lectura, etc. Aunque en este ejemplo se ilustra independiente de la unidad de procesamiento 352, se debe entender que la totalidad o una parte de una memoria principal se puede proporcionar dentro de, u ocupar la misma ubicación que, o estar acoplada de otro modo con, la unidad de procesamiento 352. La memoria secundaria puede incluir, por ejemplo, el mismo tipo de memoria que, o uno similar a, la memoria principal y/o uno o más dispositivos o sistemas de almacenamiento de datos, tales como, por ejemplo, una unidad de disco, una unidad de disco óptico, una unidad de cinta, una unidad de memoria de estado sólido, etc.
[0038] En determinadas implementaciones, la memoria secundaria puede ser operativamente receptiva de, o configurable de otra manera para acoplarse a, un medio no transitorio legible por ordenador 370. Así pues, en determinadas implementaciones de ejemplo, los procedimientos y/o aparatos presentados en el presente documento pueden adoptar la forma, total o parcial, de un medio legible por ordenador 370 que puede incluir instrucciones 358 implementables por ordenador almacenadas en el mismo, que, si son ejecutadas por al menos una unidad de procesamiento 352, se pueden habilitar operativamente para realizar la totalidad o unas partes de las operaciones de ejemplo como se describe en el presente documento. El medio legible por ordenador 370 puede formar parte de la memoria 354.
[0039] Por tanto, el servidor de localización 150 incluye un medio para generar un mensaje en un entorno de plano de control LPP, conteniendo el mensaje datos de asistencia y un campo de petición de acuse de recibo, en el que el campo de petición de acuse de recibo indica que se requiere acuse de recibo cuando un terminal móvil solicita el mensaje y el campo de petición de acuse de recibo indica que no se requiere acuse de recibo cuando el terminal móvil no solicita el mensaje, que puede ser, por ejemplo, una unidad de mensajes 366 y una unidad de selección de acuse de recibo 368. Los medios para transmitir el mensaje al terminal móvil pueden ser, por ejemplo, el transceptor 360. El servidor de localización 150 puede incluir además medios para generar un segundo mensaje, siendo el segundo mensaje un mensaje de error y conteniendo un segundo campo de petición de acuse de recibo que indica que no se requiere acuse de recibo, que pueden ser, por ejemplo, una unidad de mensajes 366 y una unidad de selección de acuse de recibo 368. El servidor de localización 150 puede incluir además medios para enviar un mensaje posterior al terminal móvil sin recibir un mensaje de acuse de recibo del terminal móvil, que pueden incluir, por ejemplo, el transceptor 360.
[0040] La fig. 9 es un diagrama de flujo que ilustra un procedimiento de la implementación selectiva del mecanismo de transporte LPP/LPPe fiable recibido por el terminal móvil. Como se ilustra, se recibe un mensaje no solicitado desde un servidor de localización en un entorno de plano de control LPP, conteniendo el mensaje no solicitado datos de asistencia y un campo de petición de acuse de recibo, en el que el campo de petición de acuse de recibo indica que no se requiere acuse de recibo (252). Los datos de asistencia contenidos en el mensaje no solicitado se procesan (254), y se espera un mensaje posterior del servidor de localización sin transmitir un acuse de recibo del mensaje (256). Se debe entender que el entorno del plano de control LPP incluye LPPe. El mensaje se puede segmentar en una pluralidad de segmentos de mensaje, donde el último segmento de la pluralidad de segmentos de mensaje contiene el campo de petición de acuse de recibo que indica que no se requiere acuse de recibo. El procedimiento puede incluir además recibir desde el servidor de localización un segundo mensaje en el entorno de plano de control LPP, conteniendo el segundo mensaje un segundo campo de petición de acuse de recibo que indica que se requiere acuse de recibo, y transmitiéndose el acuse de recibo del segundo mensaje al servidor de localización. El procedimiento también puede incluir recibir un segundo mensaje desde el servidor de localización; siendo el segundo mensaje un mensaje de error y conteniendo un segundo campo de petición de acuse de recibo que indica que no se requiere acuse de recibo.
[0041] La fig. 10 ilustra un diagrama de bloques esquemático que ilustra determinadas características de ejemplo del terminal móvil 120, por ejemplo, el terminal móvil que está configurado para recibir mensajes desde un servidor de localización que implementa selectivamente el mecanismo de transporte LPP/LPPe fiable como se analiza anteriormente, por ejemplo, para evitar retardos innecesarios. El terminal móvil 120 puede, por ejemplo, incluir una o más unidades de procesamiento 302, una memoria 304, un transceptor 310 (por ejemplo, una interfaz de red inalámbrica) y (según corresponda) un receptor SPS 340, que puede estar acoplado operativamente con una o más conexiones 306 (por ejemplo, buses, líneas, fibras, enlaces, etc.). En determinadas implementaciones de ejemplo, la totalidad o una parte del terminal móvil 120 puede adoptar la forma de un conjunto de chips y/o similares.
[0042] El transceptor 310 puede, por ejemplo, incluir un transmisor 312 habilitado para transmitir una o más señales a través de uno o más tipos de redes de comunicación inalámbrica y un receptor 314 para recibir una o más señales transmitidas a través del uno o más tipos de redes de comunicación inalámbrica, por ejemplo, la red inalámbrica 130 por medio de una RAN 140 en la fig. 1. Las redes de comunicación inalámbrica pueden ser redes inalámbricas de área amplia (WWAN), redes inalámbricas de área local (WLAN), una red inalámbrica de área personal (WPAN), etc. Los términos "red" y "sistema" se usan a menudo de manera intercambiable. Una WWAN puede ser una red de acceso múltiple por división de código (CDMA), una red de acceso múltiple por división de tiempo (TDMA), una red de acceso múltiple por división de frecuencia (FDMA), una red de acceso múltiple por división ortogonal de frecuencia (OFDMA), una red de acceso múltiple por división de frecuencia de portadora única (SC-FDMA), una red de evolución a largo plazo (LTE), una red WiMAX, etc. Una red CDMA puede implementar una o más tecnologías de acceso por radio (RAT), tales como cdma2000, CDMA de banda ancha (W-Cd Ma ), etc. La cdma2000 incluye los estándares IS-95, IS-2000 e IS-856. Una red TDMA puede implementar el sistema global para comunicaciones móviles (GSM), el sistema avanzado de telefonía móvil digital (D-Am PS) o alguna otra RAT. El GSM, el W-CDMA y la LTE se describen en documentos del 3GPP. La Cdma2000 se describe en documentos de un consorcio llamado "Proyecto de Colaboración de Tercera Generación 2" (3GPP2). Los documentos del 3GPP y del 3GPP2 están disponibles para el público. Una WLAN puede ser una red IEEE 802.1 lx, y una WPAN puede ser una red Bluetooth, una red IEEE 802.15x o algún otro tipo de red. Las técnicas también se pueden implementar junto con cualquier combinación de WWAN, WLAN y/o WPAN. Por ejemplo, la RAN 140 puede ser, por ejemplo, una red de acceso por radio terrestre UMTS evolucionada (E-UTRAN) (LTE), una red W-CDMA UTRAN , una red de acceso por radio de GSM/EDGE (GERAN), una red lxRTT, una red de evolución de datos optimizada (EvDO), una red WiMax o una WLAN.
[0043] El receptor SPS 340 puede estar habilitado para recibir señales asociadas con uno o más recursos SPS, por ejemplo, los vehículos satélite (SV) 180 en la fig. 1. Los SV, por ejemplo, pueden estar en una constelación del sistema mundial de navegación por satélite (GNSS), tal como el sistema de posicionamiento global (GPS), Galileo, Glonass o Compass. De acuerdo con determinados aspectos, las técnicas presentadas en el presente documento no están restringidas a sistemas globales (por ejemplo, el GNSS) para SPS. Por ejemplo, las técnicas proporcionadas en el presente documento se pueden aplicar a, o su uso se puede permitir de otro modo en, diversos sistemas regionales tales como, por ejemplo, el sistema de satélites cuasicenital (QZSS) sobre Japón, el sistema de satélites de navegación regional de India (IRNSS) sobre India, Beidou o Compass sobre China, etc., y/o diversos sistemas de aumento (por ejemplo, un sistema de aumento basado en satélite (SBAS)) que pueden estar asociados a, o su uso se puede permitir de otro modo en, uno o más sistemas de satélites de navegación global y/o regional. A modo de ejemplo, pero no de limitación, un SBAS puede incluir un sistema de aumento que proporciona información de integridad, correcciones diferenciales, etc., tales como, por ejemplo, el sistema de aumento de área amplia (WAAS), el servicio europeo de navegación por complemento geoestacionario (EGNOS), el sistema de aumento por satélite multifuncional (MSAS), el sistema de navegación aumentado geostacionario asistido por GPS o de navegación aumentado por GPS y órbita geostacionaria (GAGAN), y/o similares. Por tanto, como se usa en el presente documento, un SPS puede incluir cualquier combinación de uno o más sistemas de satélites de navegación global y/o regional y/o sistemas de aumento, y las señales SPS pueden incluir señales SPS, señales tipo SPS y/u otras señales asociadas con dicho uno o más SPS.
[0044] La unidad de procesamiento 302 se puede implementar usando una combinación de hardware, firmware y software. La unidad de procesamiento 302 puede representar uno o más circuitos configurables para realizar al menos una parte de un procedimiento o proceso de cálculo de señales de datos, relacionado con el funcionamiento del terminal móvil 120. La unidad de procesamiento 302 puede incluir una unidad de recepción de mensajes 316 que, por ejemplo, procesa datos recibidos en mensajes y una unidad de acuse de recibo 318 que genera un mensaje de acuse de recibo como respuesta a una petición de acuse de recibo en un mensaje recibido. La unidad de recepción de mensajes 316 y la unidad de acuse de recibo 318 pueden estar implementadas en hardware, firmware y software o una combinación de los mismos.
[0045] Las metodologías descritas en el presente documento en diagramas de flujo y flujos de mensajes se pueden implementar por diversos medios, dependiendo de la aplicación. Por ejemplo, estas metodologías se pueden implementar en hardware, firmware, software o en cualquier combinación de los mismos. Para una implementación en hardware, la unidad de procesamiento 302 se puede implementar dentro de uno o más circuitos integrados específicos de la aplicación (ASIC), procesadores de señales digitales (DSP), dispositivos de procesamiento de señales digitales (DSPD), dispositivos lógicos programables (PLD), matrices de puertas programables in situ (FPGA), procesadores, controladores, microcontroladores, microprocesadores, dispositivos electrónicos, otras unidades electrónicas diseñadas para realizar las funciones descritas en el presente documento, o una combinación de los mismos.
[0046] En una implementación en firmware y/o software, las metodologías se pueden implementar con módulos (por ejemplo, procedimientos, funciones, etc.) que realizan las funciones descritas en el presente documento. Cualquier medio legible por máquina que realiza instrucciones de forma tangible se puede usar para implementar las metodologías descritas en el presente documento. Por ejemplo, los códigos de software se pueden almacenar en un medio no transitorio legible por ordenador 320 o en una memoria 304 que está conectada a, y es ejecutada por, una unidad de procesamiento 302. La memoria puede estar implementada dentro de la unidad de procesamiento o fuera de la unidad de procesamiento. Como se usa en el presente documento, el término "memoria" se refiere a cualquier tipo de memoria de largo plazo, de corto plazo, volátil, no volátil o uno diferente, y no se debe limitar a ningún tipo de memoria o número de memorias en particular, ni al tipo de medio en el que se almacena la memoria.
[0047] Si se implementa en firmware y/o software, las funciones se pueden almacenar como una o más instrucciones 308 o código en un medio no transitorio legible por ordenador, tal como el medio legible por ordenador 320 y/o la memoria 304. Los ejemplos incluyen medios legibles por ordenador codificados con una estructura de datos y medios legibles por ordenador codificados con un programa informático. Los medios no transitorios legibles por ordenador incluyen medios físicos de almacenamiento informático. Un medio de almacenamiento puede ser cualquier medio no transitorio disponible al que se puede acceder mediante un ordenador. A modo de ejemplo, y no de limitación, dichos medios no transitorios legibles por ordenador pueden comprender RAM, ROM, EEPROM, CD-ROM u otro almacenamiento de disco óptico, almacenamiento de disco magnético u otros dispositivos de almacenamiento magnético, o cualquier otro medio que se pueda usar para almacenar código de programa deseado en forma de instrucciones o estructuras de datos y al que se puede acceder mediante un ordenador; como se usa en el presente documento, un disco incluye un disco compacto (CD), un disco láser, un disco óptico, un disco versátil digital (DVD), un disco flexible y un disco Blu-ray, de los cuales los discos flexibles normalmente reproducen datos magnéticamente, mientras que los demás discos reproducen datos ópticamente con láseres. Las combinaciones de los anteriores también se deben incluir dentro del alcance de los medios legibles por ordenador.
[0048] Además de almacenarse en un medio legible por ordenador, las instrucciones y/o los datos se pueden proporcionar como señales en medios de transmisión incluidos en un aparato de comunicación. Por ejemplo, un aparato de comunicación puede incluir un transceptor que tiene señales que indican instrucciones y datos. Las instrucciones y los datos están configurados para hacer que uno o más procesadores implementen las funciones descritas de forma general en las reivindicaciones. Es decir, el aparato de comunicación incluye medios de transmisión con señales indicativas de información para realizar las funciones divulgadas.
[0049] La memoria 304 puede representar cualquier mecanismo de almacenamiento de datos. La memoria 304 puede incluir, por ejemplo, una memoria principal y/o una memoria secundaria. La memoria principal puede incluir, por ejemplo, memoria de acceso aleatorio, memoria de solo lectura, etc. Aunque en este ejemplo se ilustra independiente de la unidad de procesamiento 302, se debe entender que la totalidad o una parte de una memoria principal se puede proporcionar dentro de, u ocupar la misma ubicación que, o estar acoplada de otro modo con, la unidad de procesamiento 302. La memoria secundaria puede incluir, por ejemplo, el mismo tipo de memoria que, o uno similar a, la memoria principal y/o uno o más dispositivos o sistemas de almacenamiento de datos, tales como, por ejemplo, una unidad de disco, una unidad de disco óptico, una unidad de cinta, una unidad de memoria de estado sólido, etc.
[0050] En determinadas implementaciones, la memoria secundaria puede ser operativamente receptiva de, o configurable de otra manera para acoplarse a, un medio no transitorio legible por ordenador 320. Así pues, en determinadas implementaciones de ejemplo, los procedimientos y/o aparatos presentados en el presente documento pueden adoptar la forma, total o parcial, de un medio legible por ordenador 320 que puede incluir instrucciones 308 implementables por ordenador almacenadas en el mismo, que, si son ejecutadas por al menos una unidad de procesamiento 302, se pueden habilitar operativamente para realizar la totalidad o unas partes de las operaciones de ejemplo como se describe en el presente documento. El medio legible por ordenador 320 puede formar parte de la memoria 304.
[0051] Por lo tanto, el terminal móvil 120 puede incluir medios para recibir desde un servidor de localización un mensaje no solicitado en un entorno de plano de control LPP, el conteniendo el mensaje no solicitado datos de asistencia y un campo de petición de acuse de recibo, en el que el campo de petición de acuse de recibo indica que no se requiere acuse de recibo, que pueden ser, por ejemplo, el transceptor 310. El terminal móvil 120 puede incluir además medios para procesar los datos de asistencia contenidos en el mensaje no solicitado, que pueden ser, por ejemplo, la unidad de recepción de mensajes 316. Un medio para esperar un mensaje posterior desde el servidor de localización sin transmitir un acuse de recibo del mensaje no solicitado, puede incluir, por ejemplo, la unidad de acuse de recibo 318. El terminal móvil 120 puede incluir además medios para recibir un segundo mensaje desde el servidor de localización, en el que el segundo mensaje es un mensaje de error y contiene un segundo campo de petición de acuse de recibo que indica que no se requiere acuse de recibo, que pueden ser, por ejemplo, el transceptor 310. Un medio para recibir desde el servidor de localización un segundo mensaje en el entorno del plano de control LPP, conteniendo el segundo mensaje un segundo campo de petición de acuse de recibo que indica que se requiere acuse de recibo, por ejemplo, el transceptor 310, y un medio para transmitir un acuse de recibo del segundo mensaje al servidor de localización puede incluir la unidad de acuse de recibo 318 y el transceptor 310.

Claims (11)

REIVINDICACIONES
1. Un procedimiento realizado por un servidor de localización en un entorno de plano de control de protocolo de posicionamiento de evolución a largo plazo, LPP, comprendiendo el procedimiento:
generar (202) un mensaje que contiene datos de asistencia que un terminal móvil va a procesar y un campo de petición de acuse de recibo;
determinar si el terminal móvil (120) solicita el mensaje;
establecer, en base a dicha determinación, el campo de petición de acuse de recibo en el mensaje para indicar que se requiere acuse de recibo cuando el terminal móvil solicita el mensaje y para indicar que no se requiere acuse de recibo cuando el terminal móvil no solicita el mensaje; y
transmitir (204) el mensaje desde el servidor de localización al terminal móvil (120).
2. El procedimiento de la reivindicación 1, en el que el mensaje se segmenta en una pluralidad de segmentos de mensaje y en el que un último segmento de la pluralidad de segmentos de mensaje contiene el campo de petición de acuse de recibo que indica que se requiere acuse de recibo cuando el terminal móvil (120) solicita el mensaje e indica que no se requiere acuse de recibo cuando el terminal móvil (120) no solicita el mensaje.
3. El procedimiento de la reivindicación 1, que comprende además generar un segundo mensaje, en el que el segundo mensaje es un mensaje de error y contiene un segundo campo de petición de acuse de recibo que indica que no se requiere acuse de recibo.
4. El procedimiento de la reivindicación 1, que comprende además enviar un mensaje posterior al terminal móvil (120) sin recibir un mensaje de acuse de recibo desde el terminal móvil (120).
5. El procedimiento de la reivindicación 1, en el que el entorno de plano de control LPP incluye LPPe.
6. Un aparato (150), que comprende:
medios para generar un mensaje en un entorno de plano de control de protocolo de posicionamiento de evolución a largo plazo, LPP, conteniendo el mensaje datos de asistencia que un terminal móvil va a procesar y un campo de petición de acuse de recibo;
medios para determinar si el terminal móvil (120) solicita el mensaje;
medios para establecer, en base a dicha determinación, el campo de petición de acuse de recibo en el mensaje para indicar que se requiere acuse de recibo cuando el terminal móvil solicita el mensaje y para indicar que no se requiere acuse de recibo cuando el terminal móvil (120) no solicita el mensaje; y
medios para transmitir el mensaje al terminal móvil.
7. El aparato de la reivindicación 6, en el que el mensaje se segmenta en una pluralidad de segmentos de mensaje y en el que uno o más de los segmentos de mensaje de la pluralidad de segmentos de mensaje contiene el campo de petición de acuse de recibo que indica que se requiere acuse de recibo cuando el terminal móvil solicita el mensaje e indica que no se requiere acuse de recibo cuando el terminal móvil (120) no solicita el mensaje.
8. El aparato de la reivindicación 6, que comprende además medios para generar un segundo mensaje, en el que el segundo mensaje es un mensaje de error y contiene un segundo campo de petición de acuse de recibo que indica que no se requiere acuse de recibo.
9. El aparato de la reivindicación 6, que comprende además medios para enviar un mensaje posterior al terminal móvil (120) sin recibir un mensaje de acuse de recibo desde el terminal móvil (120).
10. El aparato de la reivindicación 6, en el que el entorno del plano de control LPP incluye LPPe.
11. Un medio no transitorio legible por ordenador que incluye código de programa almacenado en el mismo, que comprende código para, cuando es ejecutado por un procesador, llevar a cabo las etapas de cualquiera de las reivindicaciones 1 a 5.
ES13760169T 2012-09-27 2013-08-26 Optimizaciones de posicionamiento de acuse de recibo seleccionadas Active ES2770823T3 (es)

Applications Claiming Priority (3)

Application Number Priority Date Filing Date Title
US201261706671P 2012-09-27 2012-09-27
US13/744,277 US8855678B2 (en) 2012-09-27 2013-01-17 Selected acknowledgment positioning optimizations
PCT/US2013/056653 WO2014051910A1 (en) 2012-09-27 2013-08-26 Selected acknowledgment positioning optimizations

Publications (1)

Publication Number Publication Date
ES2770823T3 true ES2770823T3 (es) 2020-07-03

Family

ID=50339336

Family Applications (1)

Application Number Title Priority Date Filing Date
ES13760169T Active ES2770823T3 (es) 2012-09-27 2013-08-26 Optimizaciones de posicionamiento de acuse de recibo seleccionadas

Country Status (7)

Country Link
US (2) US8855678B2 (es)
EP (1) EP2901722B1 (es)
JP (2) JP6009681B2 (es)
CN (2) CN106231546B (es)
ES (1) ES2770823T3 (es)
HU (1) HUE047001T2 (es)
WO (1) WO2014051910A1 (es)

Families Citing this family (8)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US8855678B2 (en) 2012-09-27 2014-10-07 Qualcomm Incorporated Selected acknowledgment positioning optimizations
US10027763B2 (en) 2016-03-25 2018-07-17 Qualcomm Incorporated Abort messages for position location message flows
EP3226032A1 (en) * 2016-03-31 2017-10-04 Sequans Communications S.A. New messaging scheme for positioning
US10638254B2 (en) * 2017-01-18 2020-04-28 Qualcomm Incorporated Handling an early position fix for LPP-type positioning sessions
US10313825B2 (en) * 2017-02-28 2019-06-04 Qualcomm Incorporated Control plane LCS solution for improving multiple reporting LPP messaging
CN108810875A (zh) * 2017-05-05 2018-11-13 中兴通讯股份有限公司 融合定位的方法及装置
US11240706B2 (en) * 2017-10-08 2022-02-01 Qualcomm Incorporated Methods and systems for segmentation of positioning protocol messages
CN110650467B (zh) 2018-06-26 2022-03-29 华为技术有限公司 管理用户数据的方法和装置

Family Cites Families (12)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US7546395B2 (en) 2002-10-10 2009-06-09 Sirf Technology, Inc. Navagation processing between a tracker hardware device and a computer host based on a satellite positioning solution system
US20080139114A1 (en) * 2006-12-06 2008-06-12 Motorola, Inc. Method for determining user location based on association with seamless mobility context
US20090069032A1 (en) * 2007-09-11 2009-03-12 Qualcomm Incorporated Dynamic measure position request processing in a mobile radio network
US8306523B2 (en) * 2008-02-15 2012-11-06 Qualcomm Incorporated Methods and apparatuses supporting multiple positioning protocol versions in wireless communication networks
US8660574B2 (en) 2008-04-02 2014-02-25 Qualcomm Incorporated Generic positioning protocol
JP4780482B2 (ja) * 2008-06-09 2011-09-28 アドコアテック株式会社 通信処理装置、通信処理方法及びそのプログラム
US9435874B2 (en) * 2009-04-21 2016-09-06 Qualcomm Incorporated Method and apparatus for supporting positioning for terminals in a wireless network
US8750915B2 (en) * 2010-01-05 2014-06-10 Qualcomm Incorporated Exchange of location information using a wireless communication device
US8699460B2 (en) 2010-04-10 2014-04-15 Qualcomm Incorporated Position location call flow
US8942102B2 (en) 2010-11-05 2015-01-27 Qualcomm Incorporated Segmented data transfer with resume capability
US8675474B2 (en) * 2010-12-10 2014-03-18 Htc Corporation Method and system for handling error in LPP messages exchange
US8855678B2 (en) 2012-09-27 2014-10-07 Qualcomm Incorporated Selected acknowledgment positioning optimizations

Also Published As

Publication number Publication date
CN104662932A (zh) 2015-05-27
CN106231546B (zh) 2019-11-01
JP2016076954A (ja) 2016-05-12
HUE047001T2 (hu) 2020-04-28
CN106231546A (zh) 2016-12-14
JP2015537407A (ja) 2015-12-24
CN104662932B (zh) 2016-08-24
JP6009643B2 (ja) 2016-10-19
US20140087759A1 (en) 2014-03-27
JP6009681B2 (ja) 2016-10-19
US8855678B2 (en) 2014-10-07
WO2014051910A1 (en) 2014-04-03
EP2901722B1 (en) 2019-12-04
US20150024777A1 (en) 2015-01-22
US8983499B2 (en) 2015-03-17
EP2901722A1 (en) 2015-08-05

Similar Documents

Publication Publication Date Title
ES2770823T3 (es) Optimizaciones de posicionamiento de acuse de recibo seleccionadas
US9591523B2 (en) Segmented data transfer with resume capability
JP6219423B2 (ja) 測位サービスのためのｓｉｍカード選択のための方法および装置
ES2466018T3 (es) Soporte de múltiples protocolos de posicionamiento
JP5591803B2 (ja) 無線通信ネットワークにおける種々の衛星測位システムに関連する感度支援情報を要求／供与するための方法および装置
JP2015533032A (ja) Ｌｔｅ上での制御プレーンｌｃｓのための拡張ｌｔｅ測位プロトコル情報転送プロシージャ
KR20160058134A (ko) 실내 포지셔닝에 있어서 더 양호한 사용자 경험을 위한 동적 포지션 분할
US10313825B2 (en) Control plane LCS solution for improving multiple reporting LPP messaging
US20150237465A1 (en) Method and apparatus to switch between network-based and mobile-based positioning modes