A-GPS

Source: https://www.2cm.com.tw/2cm/zh-tw/tech/B8621B3CA49446569786794C1A20291C

結合連線/離線式架構優勢　A-GPS定位效能再升級

2008-07-22

• 蔡金源

全球衛星定位系統(GPS)的應用愈來愈普及，如個人導航裝置(PND)就已是3C賣場中的熱門產品，而愈來愈多手機也開始將GPS功能納入其中，希望能提供個人用戶多樣的定位服務(Location-based Service, LBS)。不過，為了提供更好的使用經驗，今日的GPS設備仍得在縮短首次定位時間(TTFF)、準確性(Accuracy)和靈敏度(Sensitivity)上下功夫。其中，輔助式GPS(Assisted GPS, A-GPS)，即是在此一市場訴求下而備受重視。

A-GPS最早的發展背景是來自於美國聯邦通訊傳播委員會(FCC)所制定的E911政策，要求美國境內手機均須具備即時定位功能，以在緊急時刻發揮定位尋人的用途。A-GPS是可協助達成此目標的技術之一，其他技術還包括微細胞識別碼(Cell-ID)、時差抵達(Time Difference of Arrival, TDoA)、加強觀察時間差(Enhanced Observed Time Difference, E-OTD)、角度到達時間(Angle of Arrival, AOA)及混合式的技術等。然而，隨著GPS走向消費性，加上A-GPS又有助縮短TTFF，因而從政策驅動轉變為市場驅動的明星技術。  

A-GPS大幅縮短TTFF　準確衛星時間扮要角

要建置A-GPS技術，必須先從衛星訊號接收的基本原理開始認識。在沒有輔助訊號的自主定位(Autonomous Positioning)模式下，GPS接收器必須從天空中完整接收到四顆以上的衛星訊號，才能順利解出終端用戶所在的三度空間位置。這個過程包括三個階段：衛星搜尋(Acquisition)與訊號下載、追蹤(Tracking)和導航(Navigation)，又以第一階段最耗時間。  

在前面幾期新通訊元件雜誌專欄中已經介紹過衛星訊號的組成，在此就不再贅述。衛星訊號的每個訊框，提供衛星的星期時間(Time of Week, TOW)、廣播星曆(Broadcast Ephemeris)、電離層參數及萬年曆(Almanac)等資料，這些資料的取得決定了定位所需的時間與準確性。其中廣播星曆為個別衛星本身的精確軌道位置，每小時更新一次，每次更新有效性約4小時；萬年曆則為所有衛星在軌道上的概略位置及其狀況等，每天更新一次，有效時間可達數週。  

要完成定位，關鍵資料是衛星訊框中的前三個子訊框，即廣播星曆和星期時間、時間改正係數等，完整下載至少需要18秒鐘。然而，當用戶處於建築物林立的街道中、騎樓下，甚至是室內環境中，由於訊號接收條件差，只要有一些訊號未被完整的下載，就得再重複30秒的訊框下載。衛星訊息組成及接收所需時間請參考圖1。

圖1　衛星訊息組成及接收所需時間

A-GPS是透過其他網路來即時或預先提供這些衛星資料，以加速定位計算時間。欲求得GPS用戶的位置，必須量測出四顆衛星與終端器之距離，這可以從訊號傳輸時間乘以光速來求得，而傳輸時間就必須計算TOW。衛星導航定位系統測距的基礎是測時，而定軌和定位的前提是各觀測量的時間同步(Time Synchronization)，故時間同步正是衛星導航定位的關鍵。  

因此，雖然同樣是A-GPS，但提供準確衛星時間(Precise GPS Time)或粗略衛星時間(Coarse GPS Time)，對定位速度影響差異甚大(圖2)。當GPS接收器預先獲得廣播星曆和同步準確性小於400微秒的準確GPS時間，此時將可得到最佳定位速度，如冷啟動TTFF只需4秒。這是因為兩項資料讓待搜尋頻率和訊號延遲視窗(Window of Code Delay)範圍變小；此外，準確的GPS時間能夠用來計算衛星位置，而且可跳過對TOW的求解。

圖2　透過輔助資料有助於加速定位，額外的同步訊號能進一步縮短定位時間。

相較之下，在A-GPS模式下若只能獲得粗略衛星時間，定位時間會大幅拉長，如同步準確性若小於8毫秒，還須要進行位元同步(Bit Sync)，冷啟動的TTFF約需12秒；如果同步準確性大於8毫秒，會同時須要進行位元同步和訊框同步(Frame Sync)，TTFF約需24秒以上。  

一旦衛星時間不夠準確，就無法有效預估訊號延遲視窗，若要達到與具有準確時間相同的表現，將需要500倍的搜尋資源。此外，因為衛星速度達每秒800公里，太快的速度也無法求得精確的衛星位置，將和自主式模式一樣必須求解TOW，這會造成定位時間拉長至6秒，在弱訊號下更無法解碼。雖然還有另一個方式是求解衛星時間，不過這需要多一顆衛星的資料，也就是五顆衛星才能進行定位。 在了解A-GPS的原理與優勢後，接著來談談A-GPS的建置方法。要取得衛星定位輔助資料有兩種方式，一是即時性的透過GSM、GPRS、CDMA或UMTS等行動通訊系統來取得，也就是連線式A-GPS(Online A-GPS)；另一種是採離線(Offline)，也就是依使用者的方便，透過行動網路或直接由網際網路預先下載衛星資料，當需要時就能做為輔助定位之用。  

連線式A-GPS提供即時資訊  

由於衛星的軌道資料會定時更新，因此理想上最好能夠即時獲得最新的輔助資料，這就得採用連線式A-GPS模式。不過，既然是連線方式，其獲取資料的速度就會受到行動網路速率的影響，這是較不可控的因素。CDMA和GSM/GPRS的協定中都定義出A-GPS手機的最低運作效能標準：CDMA的標準定義在3GPP2 C.S0036-0(TIA 916)，GSM/GPRS則是3GPP TS 25.171。其中CDMA要求最大的反應時間，即最長的TTFF是在16秒之內，GSM則是20秒。目前各家的解決方案都致力於滿足這項要求。  

當支援A-GPS的終端啟動時，它會同時接收來自天空中的衛星訊號，並從行動網路的基地台獲取輔助資料，這些資料並不儲存在GPS接收器或系統的記憶體中，而且每次啟動連結時，資料都會更新。在終端與基地台的連結介面上，A-GPS的發展可分為政策導向和市場導向，其中政策導向的語音緊急服務因需要高可靠性的定位功能，因此產生了控制平面(Control Plane)架構；市場導向的LBS或導航應用，強調透過無線資料傳輸來達成的定位應用服務，因此產生了用戶平面(User Plane)架構。  

控制平面和用戶平面的差異在於，前者是專為緊急救援而設計，目的是要讓手機能提供隨時隨地的定位功能，因而不允許其他應用優先於此需求，例如為了強化GPS接收器的靈敏度而優先進行戶外的定位；相較之下，用戶平面被使用在非緊急的應用上，其目的是要縮短TTFF的時間及提升定位的準確性。進一步解釋如下：

‧

控制平面

A-GPS只是定位技術之控制平面標準的一種，其他還包括基於CDMA通訊技術的進階前向鏈路三角定位(Advanced Forward Link Trilateration, AFLT)、WCDMA的觀察到達時間差(Observed Time Difference of Arrival, OTDOA)和GSM的強化到達時間差(E-OTD)等。因此，控制平面中的終端設備(Mobile Station, MS)可以是本身具有GPS接收器的手機，也可以是普通手機；通訊架構中各個單元的功能基本上維持不變，但為了支援位置服務，必須新增閘道伺服器(Gateway Server)、定位伺服器(Positioning Server)和定位業務(Location Services, LCS)終端。控制平面標準與架構定義如表1。 表1　控制平面標準與架構定義 空中介面 定位技術 定位伺服器 閘道伺服器 CDMA(IS-95) IS-801 PDSS PDE MPC WCDMA TS 25.331 RRC (Radio Resource Control) SAS GMLC GSM TS 04.31 RRLP (Radio Resource LCS Protocol) SMLC GMLC 不同行動系統針對定位輔助功能定義出不同的介面規格，其中GSM/GPRS是無線資源定位協議(RRLP)，UMTS/WCDMA是無線資源控制(RRC)，CDMA則是IS-801A。除了介面規格不同外，不同的系統服務商往往會建立屬於自己的控制平面運作系統，此舉雖然能保證較佳的服務品質，但建置成本極高，用戶也得受限於系統服務商。目前美國的CDMA系統已使用於E911，而GSM業者在進行3G建置時也開始加入相關架構。

‧

用戶平面

用戶平面主要以TCP/IP做為資料傳送方式，目前包括CDMA、3GPP2和OMA都制定出用戶平面的標準，其中OMA制定的安全用戶平面位址(Secure User Plane Location, SUPL)獲得業者普遍的支援。用戶平面標準與架構定義如表2。SUPL透過將RRC、RRLP等訊息包裹為一致性的規格後再發送出去。其定位的運算通常也在用戶端(MS-based)，能減少網路成本及維護管理上的需求；若是主要運算端為網路伺服器，則稱為MS-assisted。 表2　用戶平面標準與架構定義 組織 User Plane標準 定位技術標準 定位伺服器 閘道伺服器 CDMA V1/V2(CDG) IS-801 PDSS PDE MPC 3GPP2(CDMA-2000) X.S0024 IS-801 PDSS PDE PS OMA SUPL IS-801 PDSS TS 04.31 RRLP TS 25.331 RRC SPC SLC 在建置上，用戶平面較控制平面來得容易施行，用戶平面提供的位置服務相關訊號包括定位等級(Positioning Level)和服務等級(Service Level)兩類，它使用控制平面定位技術的相關協定，基本上功能相當，差別在於以TCP/IP的方式傳送，而優勢在於通用性高，系統建置成本較低，也不必受到GSM、CDMA、WCDMA不同系統的限制，因此有助於A-GPS在手機等行動設備中的推行。

離線式A-GPS不受服務品質影響連線效率  

由於連線式容易因行動通訊商的服務品質及用戶所在位置而影響連線效率，而且會受限於行動通訊商的管理，因此發展出離線模式。採用離線式A-GPS，用戶只須在外出定位前，先透過行動網路或網際網路從伺服器端中取得輔助資料，下載後即可中斷連線。當啟動GPS功能，這些資料就會用來協助定位，同樣能加速定位所需的時間。離線式A-GPS服務架構如圖3。

圖3　離線式A-GPS服務架構示意圖

由於離線式所提供的輔助資料必須具有較長的有效性，因此資料提供者得具備專業的衛星軌道預測能力，如藉由天文學及重力等模式來預測及修正衛星軌道。有能力提供離線式服務的供應商並不多，不過目前已有業者可以透過差分萬年曆修正資料(Differential Almanac Correction Data)的作法，將衛星軌道的準確度從3～5公里提升到10～50公尺(圖4)。

圖4　透過差分萬年曆修正資料來提升軌道預測的準確度

採用離線式A-GPS，能省下衛星軌道資料的下載時間，而且加上定位時毋須隨時保持連線，因此可省下不少連線費用。目前已有業者能提供達14天的有效時間，讓用戶下載使用。不過，由於輔助資料的準確性會隨著時間而下降，因此最好能經常維持資料的更新。相較於透過SUPL等連線式A-GPS等複雜的方案，用戶若能免費利用網路來獲得衛星輔助資料，將能大幅降低A-GPS系統建置的門檻，有助於推廣A-GPS的應用。  

連線/離線可並行　A-GPS效能加倍  

具備GPS功能的終端設備要支援A-GPS並不困難，若要採用連線式，則須考慮是採用MS-based或MS-assisted模式，也就是定位運算的主體在終端或伺服端。MS-based較為單純，在取得網路輔助資料後，就回到獨立運算的狀態，但對終端系統的運算資源要求較高；MS-assisted則較為複雜，終端器將接收到的衛星訊號資料傳送給網路伺服器，由伺服器計算出結果後再將位置資訊送回給終端器，此舉雖能降低終端器的運算負荷，而且能進行較複雜的運算以取得更精確的位置，但對於連線品質要求甚高，一旦在過程中失聯就會失去定位結果。  

在記憶體需求方面，連線式只需一些即時的資料，對於記憶體容量的要求極低，每次下載的檔案大小只有1～3KB；離線式的記憶體需求量也不大，下載1天的衛星預測資料，大約只需要10KB，14天的預測資料量則約為90KB。這些資料通常儲存於非揮發性的快閃可擦除可程式唯讀存儲器(Flash EPROM)中，而依系統架構的不同，有的GPS接收器會配置記憶體，可以直接溝通；另一種架構則是使用主處理器的記憶體來儲存，可節省記憶體的成本與占用空間(圖5)。

圖5　GPS接收器透過主處理器取得儲存資料的運作架構

值得一提的是，連線式或離線式並非二選一的方案，兩者其實可以互補。其作法上能以連線式為優先，也就是當終端器能與網路順暢的連線時，即採用連線式來取得最佳化的定位服務，當連線品質下滑時，就轉為離線方式；也可以離線方式為優先來降低連線費，即當記憶體中的衛星資料過時了，才轉為即時連線方式，並可同步再下載新的衛星資料。  

對於GPS市場的既有業者來說，手機開始內建GPS功能無疑是一大利多，這意味著整個市場將大幅擴展開來。不過，手機的GPS應用與PND大為不同，訴求目標已從車載導航轉移到個人用途，因此須要在更多樣的使用環境下獲得快速的定位服務，而A-GPS就成了不可或缺的一項實現技術。  

(本文作者任職於u-blox)

Ubuntu 20.04 setup

# Fix PuTTY can't show all 'ls -l' output.
# Fix vi keymap.
sudo nano /etc/default/locale

# Fail to boot from one partition
(ref: http://www.netadmin.com.tw/article_content.aspx?sn=1501070001&jump=3)
sudo update-grub

sudo apt-get install efibootmgr
sudo efibootmgr

# Install and enable SSH
sudo apt-get install openssh-server sshfs

# Refresh SSH credential in peer hosts

ssh-keygen -f "~/.ssh/known_hosts" -R <IP>

# Install BeyondCompare

sudo dpkg --add-architecture i386
wget https://www.scootersoftware.com/bcompare-4.4.6.27483_amd64.deb
sudo apt update
sudo apt install ./bcompare-4.4.6.27483_amd64.deb

# Setup environment
.bashrc
.ssh
.vimrc
.flexlmrc

# Normalize disk labels.
ls -l /dev/disk/by-uuid
sudo gtk-launch /etc/fstab &
sudo mkdir /HOUSE
sudo mkdir /work

sudo mount -a
sudo rmdir /opt
sudo ln -s /HOUSE/opt /opt


# Enable Samba server.
sudo apt-get install samba samba-common python-glade2 system-config-samba
sudo bcompare /HOUSE/etc/samba/smb.conf /etc/samba/smb.conf &
sudo service smbd restart
sudo smbpasswd -a

# Install screen utility
sudo apt-get install screen

# Use BASH
sudo ln -sf /bin/bash /bin/sh

# Update toolchain
sudo apt-get install build-essential chrpath coreutils desktop-file-utils diffstat docbook-utils fakeroot g++ gawk gcc git git-core help2man libgmp3-dev libmpfr-dev libreadline6-dev libtool libxml2-dev make python-pip python-pysqlite2 quilt sed subversion texi2html texinfo unzip wget

# Support 32-bits tools. Fix files are there and executable but not when invoked.
sudo echo "foreign-architecture i386" > /etc/dpkg/dpkg.cfg.d/multiarch
sudo apt-get update
sudo apt-get install libc6:i386 libncurses5:i386 libstdc++6:i386

# Install dmverity
sudo apt-get install cryptsetup-bin

# Install xmlstartlet
sudo apt-get install xmlstartlet

# Install libncurses.so.5 

# (error while loading shared libraries: libncurses.so.5: cannot open shared object file: No such file or directory)
for 32-bit binaries : sudo apt-get install libncurses5:i386
for 64-bit binaries : sudo apt-get install libncurses5

# Unify tab size to 4
$ tabs -4
$ git config --global core.pager 'less -x1,5'
$ grep tabstop ~/.vimrc
set tabstop=4

# Install and setup docker

$ docker container ls
Got permission denied while trying to connect to the Docker daemon socket at unix:///var/run/docker.sock: Get http://%2Fvar%2Frun%2Fdocker.sock/v1.32/containers/json: dial unix /var/run/docker.sock: connect: permission denied
$ sudo apt install docker.io
$ sudo usermod -aG docker $USER
$ sudo reboot
CONTAINER ID IMAGE COMMAND CREATED STATUS PORTS NAMES

Identify floating point type of a Linux executable.

Ref: https://stackoverflow.com/questions/20555594/how-can-i-know-if-an-arm-library-is-using-hardfp

Execute readelf -A library.so: if the list of printed tags contains Tag_ABI_VFP_args: VFP registers, then it is a hardfp binary, otherwise assume softfp.

E.g. readelf -A /lib/arm-linux-gnueabihf/libm.so.6 will produce

Attribute Section: aeabi
File Attributes
  Tag_CPU_name: "7-A"
  Tag_CPU_arch: v7
  Tag_CPU_arch_profile: Application
  Tag_ARM_ISA_use: Yes
  Tag_THUMB_ISA_use: Thumb-2
  Tag_FP_arch: VFPv3-D16
  Tag_ABI_PCS_wchar_t: 4
  Tag_ABI_FP_denormal: Needed
  Tag_ABI_FP_exceptions: Needed
  Tag_ABI_FP_number_model: IEEE 754
  Tag_ABI_align_needed: 8-byte
  Tag_ABI_align_preserved: 8-byte, except leaf SP
  Tag_ABI_enum_size: int
  Tag_ABI_HardFP_use: SP and DP
  Tag_ABI_VFP_args: VFP registers
  Tag_ABI_optimization_goals: Aggressive Speed
  Tag_CPU_unaligned_access: v6

On the other side, readelf -A /lib/arm-linux-gnueabi/libm.so.6 produces

Attribute Section: aeabi
File Attributes
  Tag_CPU_name: "7-A"
  Tag_CPU_arch: v7
  Tag_CPU_arch_profile: Application
  Tag_ARM_ISA_use: Yes
  Tag_THUMB_ISA_use: Thumb-2
  Tag_FP_arch: VFPv3-D16
  Tag_ABI_PCS_wchar_t: 4
  Tag_ABI_FP_denormal: Needed
  Tag_ABI_FP_exceptions: Needed
  Tag_ABI_FP_number_model: IEEE 754
  Tag_ABI_align_needed: 8-byte
  Tag_ABI_align_preserved: 8-byte, except leaf SP
  Tag_ABI_enum_size: int
  Tag_ABI_optimization_goals: Aggressive Speed
  Tag_CPU_unaligned_access: v6

Compare "echo cancellation and noise suppression (ECNS)" from "echo cancellation and noise reduction (ECNR)" by ChatGPT

Echo cancellation and noise suppression are similar to echo cancellation and noise reduction, but with a subtle difference in their goals. Echo cancellation and noise suppression algorithms are designed to remove both echoes and unwanted background noise from an audio signal. However, while noise reduction algorithms aim to reduce the noise level as much as possible, noise suppression algorithms aim to only reduce the noise level when speech or other relevant sounds are not present.

A-GPS control plane / user plane

https://en.wikipedia.org/wiki/Assisted_GNSS

 A-GPS protocols are part of Positioning Protocol defined by two different standardization bodies, 3GPP and Open Mobile Alliance (OMA).

Control Plane Protocol

Defined by the 3GPP for various generations of mobile phone systems. These protocols are defined for circuit switched networks. The following positioning protocols have been defined.

• RRLP – 3GPP defined RRLP (Radio Resource Location Protocol) to support positioning protocol on GSM networks.
• TIA 801 – CDMA2000 family defined this protocol for CDMA 2000 networks.
• RRC position protocol – 3GPP defined this protocol as part of the RRC standard for UMTS network.
• LPP – 3GPP defined LPP or LTE positioning protocol for LTE networks.

User Plane Protocol

Defined by the OMA to support positioning protocols in packet switched networks. Three generations of Secure User Plane Location (SUPL) protocol have been defined, from version 1.0 to 3.0.

SUPL[edit]

The SUPL (Secure User Plane Location) protocol, unlike its control-plane equivalents restricted to mobile networks, runs on the Internet's TCP/IP infrastructure. As a result, its application goes beyond the original intended use of mobile devices and may be used by general-purpose computers.^[5] SUPL 3.0 legitimizes such use by adding allowance for WLAN and broadband connections.^[6]

Actions defined by SUPL 3.0 include a wide range of services such as geofencing and billing. The A-GNSS functions are defined in the SUPL Positioning Functional Group. It includes:^[6]

• SUPL Assistance Delivery Function (SADF), which provides the basic information sent to the device in both A-GNSS modes.
• SUPL Reference Retrieval Function (SRRF), which tells the server to prepare the information mentioned above by receiving from the satellites.
• SUPL Position Calculation Function (SPCF), which lets the client or the server ask for the client's location. The server-generated location may result from MSA or from mobile cell. If a MSB (SET based) mode is used, the client reports its location to the server instead.

The specifics of communication is defined in the ULP (Userplane Location Protocol) substandard of SUPL suite. As of December 2018, GNSS systems supported include GPS, Galileo, GLONASS, and BeiDou.

"IMS/IPME (IMS IP Messaging) ITU recommendation A.76" by ChatGPT

 IMS/IPME (IMS IP Messaging) is a communication service defined by the International Telecommunication Union (ITU) recommendation A.76. It provides an end-to-end messaging service that allows users to exchange text, multimedia, and other content in real-time using IP-based networks.

The IMS/IPME service is designed to work within the context of the IP Multimedia Subsystem (IMS), which is a standardized architecture for multimedia services over IP networks. The IMS provides a framework for real-time multimedia communication between various devices, including smartphones, tablets, and computers.

IMS/IPME messaging service is based on the Session Initiation Protocol (SIP), which is a protocol used to set up and control multimedia communication sessions. SIP enables the establishment of multimedia sessions, including voice, video, and messaging, over IP networks. The IMS also includes a variety of other protocols, including the Diameter protocol for authentication and authorization and the Session Description Protocol (SDP) for describing multimedia sessions.

IMS/IPME messaging supports a range of multimedia content, including text, pictures, videos, and audio. It also supports group messaging, which allows users to communicate with multiple users simultaneously. IMS/IPME messaging service can be used to provide a range of messaging applications, including instant messaging, chat, and multimedia messaging.

IMS/IPME messaging has several advantages over traditional messaging services. It is designed to work over IP networks, which are becoming more widespread and offer faster and more reliable connectivity than traditional cellular networks. IMS/IPME also provides enhanced messaging features, including support for multimedia content, group messaging, and real-time delivery notifications.

In conclusion, IMS/IPME (IMS IP Messaging) is a standardized communication service that provides an end-to-end messaging service using IP-based networks. It is designed to work within the context of the IP Multimedia Subsystem (IMS) and supports a range of multimedia content and messaging applications. IMS/IPME messaging service is based on the Session Initiation Protocol (SIP) and provides enhanced messaging features, including support for multimedia content, group messaging, and real-time delivery notifications.

"RCS" and "ITU recommendation A.67" by ChatGPT

RCS stands for "Rich Communication Services," which is a communication protocol that enables enhanced messaging and communication services on mobile devices beyond traditional SMS and MMS. RCS allows for richer media types, such as high-resolution images, videos, and audio files, to be sent over cellular networks, along with features such as read receipts, typing indicators, and group messaging.

RCS also allows for the integration of additional services, such as payment and location-sharing, within the messaging application, making it a more versatile communication tool.

ITU recommendation A.67, on the other hand, is a technical specification document issued by the International Telecommunication Union (ITU) that outlines the technical requirements for implementing RCS on mobile networks. The document defines the necessary interfaces, protocols, and parameters that must be implemented in the mobile network to enable RCS services.

ITU recommendation A.67 also provides guidelines for implementing various RCS features, such as messaging, file transfer, and presence, and specifies how these features should be integrated with the existing network infrastructure. The document helps ensure that RCS services can be deployed effectively and efficiently across different mobile networks, making it easier for users to communicate and access additional services through their messaging app.