基于用戶位置信令在城市交通規劃中應用的大數據模型挖掘

趙越 王瑜 孫宏 劉芳琦 鮑麗娜 蘭婷

中國聯合網絡通信股份有限公司江蘇省分公司

0 引言

隨著我國社會經濟快速發展和人民生活水平不斷提高，我國城市化發展進程加快，城市人口的增長、機動車擁有量的增加、城市形態的變化以及社會活動數量和規模的增加給國內的大、中城市的交通狀況及其管理系統增加了越來越重的負荷，交通需求與供給之間的矛盾也變得越來越突出，因此需要大力推進城市交通信息化的發展。

另外一方面，隨著智能移動終端的普及，運營商手中實時采集海量用戶信令數據，通過這些用戶信令信息可以對用戶進行精準定位，從而實現對OD矩陣、居住地就業崗位分布、客流集散地人流數據的分析。

1 定位算法模型研究

1.1 基于MR三角定位算法

終端與小區間距離的計算是定位算法準確與否的關鍵因素。Tadv（時間提前量）是網管直接統計的由于終端與基站間距離導致的時間差，不受陰影衰落與穿透損耗等因素影響，精度更高。因此在LTE MR數據中，主服務小區Tadv，盡量都用Tadv計算得到距離；在主服務小區沒有Tadv的情況下，才用RSRP測算距離。

MR中Tadv取值0～1282，1個Tadv等于78米，因此距離= Tadv值×78米

MR中的鄰區由于沒有Tadv，因此只能用RSRP計算距離。采用RSRP計算距離的方法分為2類，如下所述：

（1）FDD：參考信號功率(dBm)= dlRsBoost + pMax/10 -Round(10 × Log(dlChBw/10 × 5 × 12) / Log(10), 2)

（2）TDD：參考信號功率（dBm）= dlRsBoost + pMax/10- Round(10 × Log(ChBw/10 × 5 × 12) / Log(10), 2)

根據鏈路預算公式，可通過路徑損耗計算得到接入距離：

S=10^((路 徑 損 耗 (dB)-161.04+7.1×LOG10(20)-7.5×LOG10(20)+(24.37-3.7×(20/天 線 掛 高 (m))^2)×LOG10(天線 掛 高 (m))-20×LOG10(頻 點 (GHz))+(3.2×(LOG10(11.75×UE 高度 (m)))^2-4.97)+3×(43.42-3.1×LOG10(天線掛高 (m))))/(43.42-3.1×LOG10(天線掛高(m))))

其中，路徑損耗計算如下：

路徑損耗(dB)= 參考信號發射功率(dBm) -參考信號接收電平RSRP(dBm) -穿透損耗(dB) -陰影衰落（dB)）-基站饋線損耗(dB) +基站天線發射增益（dBi）+終端天線接收增益（dBi）-終端接收線纜與人體損耗（dB）。

（1）判斷采樣點的各導頻中（包含服務小區和鄰小區）RSRP最強的導頻是否為室內小區：若是，則直接將采樣點定位在室內小區所在的位置半徑50米內隨機撒點；若否，則采樣下述定位算法進行定位。

（2）對于室外定位，是一個平面幾何問題，關鍵點在于在平面上確定一點的信息量是否充足。

（3）對于不重合點小于3個的情況，在平面上確定一點的位置是“信息不充分的”，因此需要結合小區天線方位角作最大可能性判定，本算法中用算法擬合選取的規則，以可能的位置點來作為定位點。

（4）對于不重合點大于等于3個的情況，信息量是冗余的，可以充分的利用信息的冗余量，求出趨近于真實點的位置。不同算法的關鍵在于用冗余數據修正數據準確性方式的不同。其中，最小二乘法是數學上比較好的逼近方法。

（5）已知n個節點的坐標，及它們到未知節點D的距離，確定節點D的坐標。

1.2 基于OTT位置GPS數據定位

（1）關鍵字匹配算法

不同APP的HTTP表頭中URI包含的經緯度信息表達方式不盡相同，傳統處理方式是對關鍵字逐項迭代匹配，找到表頭經緯度字段提取，單條記錄多次匹配，如圖1所示。

圖1 關鍵字匹配算法圖

（2）特征數據匹配算法

考慮關鍵字匹配算法的局限性，進行改進研究，引入特征數據匹配算法，根據URI數據結構進行經緯度特征數據值匹配（例如長春市邊界為：（127.05～124.6,45.2～43.29）數據只需進行N次特征匹配就能定位到經緯度信息，如圖2所示。

圖2 特征數據匹配算法圖

2 城市規劃數據模型建立

2.1 城市網格化實現方案

在用戶位置數據挖掘前，首先需要對城市進行網格化分，將城市按照相應算法切割成足夠小的網格，對應可以將用戶位置規整地劃分到分解的網格中。Geohash算法其實就是將整個地圖或者某個分割所得的區域進行一次劃分，由于采用的是base32編碼方式，即Geohash中的每一個字母或者數字（如wx4g0e中的w）都是由5bits組成（2^5 = 32，base32），這5bits可以有32種不同的組合（0～31），這樣我們可以將整個地圖區域分為32個區域，通過00000 ～ 11111來標識這32個區域，可以根據需要進行多次劃分，根據GEOHASH編碼不同精度，計算出來的網格大小不同。

本文采用將用戶經緯度數據進行GEOHASH編碼，然后按七位歸類劃分網格。有一個重大缺點就是GEOHASH不能實現所有最近位置編碼前輟越接近的規律，而出現相離幾米的用戶出現在兩個網格中。我們系統的實現時，采用地圖系統對小區進行PIO、AIO取樣分析，然后通過磁力聚合原理，將相同屬性，相近距離的小區劃成一組網格，最近通過中心點計算，最后形成網格，這樣在位置分析時，網格更有意義，路徑計算也更加合理。

2.2 位置數據模型構建方案

城市規劃中，按目標人群分為工作地和居住地。工作地、居住地可以根據時間維度、駐留維度進行劃分。工作地居住地的提取是位置分析里一個比較基礎與重要的功能，算法上可以采用簡單的方式通過上下班時間歸類提取數據滿足一些需求。職住數據也是很多其他位置分析的基礎數據，如果質量不好，直接影響其他業務的分析結果，不管其他業務的算法有多好。在較高數據精度需求中，就需求改進、優化職住地址提取算法，并加入機器學習算法。上下班時間段停留數據作為基本的數據，系統在以下幾個方面做了算法優化處理：家庭地址變化識別及快速切換，公司地址變化識別及快速切換，中長期出差人員識別及歷史數據保留，無職人員識別，辦公及生產區域識別，居住小區識別，在職人員活躍度識別，加班人員識別。

以上所有算法都比較復雜，并需要很大的計算資源，所有識別過程采用機器學習，數據逐步修正與完善，后期的準確性都建立在前期的學習模型上。由于通信業務白天是高峰期，晚上數據量比較少，系統在資源分配及編排上，晚間啟動更多的學習進程，保證不影響每10min粒度的報表數據輸出。

（1）人員工作地分布情況

工作地計算口徑：最近30天內，在工作日（周一～周五）的工作時間段內（10：00～16：00），在網格內停留時長大于3小時的天數〉=15天的目標，且工作日（周一～周五）的休息時間段內（22：00～05：00），在網格內的停留時長大于3小時的天數＜=8天，則判斷目標的工作地在該網格。

（2）人員居住地分布情況

居住地計算口徑：最近30天內，在工作日（周一～周五）的工作時間段內（10：00～16：00），在網格內停留時長大于3小時的天數＜=8天的目標，且工作日（周一～周五）的休息時間段內（22：00～05：00），在網格內的停留時長大于3小時的天數＞=15天，則判斷目標人員的居住地在該網格。

（3）居住地工作地人員遷移情況

出發時間：早晚高峰時，最后一次離開O的時間

到達時間：早晚高峰時，第一次到達D的時間，若無則默認為凌晨0時起每5min作為一個時間間隔，統計在這5min內從O出發的用戶，最終到達D，每條軌跡的人數，所用時間分布等信息；

早高峰：6：30～9：30

晚高峰：17：00～19：30

加班時段：21：30～24：00

（4）網格內人員遷移情況

統計每個網格當前的用戶，10min后的分布情況，以及到達用時，在當前網格逗留時長。

（5）區域實時人數

統計每10min內，當前區域下用戶數。

（6）人員遷移路徑

統計口徑：6∶30～21∶30 之間{網格 ID1，…，網格IDn}：到達時間：離開時間。

2.3 基于流式大數據處理機制

位置數據是一組順序、大量、快速、連續到達的數據序列,一般情況下,數據流可被視為一個隨時間延續而無限增長的動態數據集合。

普通流數據具有四個特點：

（1）數據實時到達；

（2）數據到達次序獨立，不受應用系統所控制；

（3）數據規模宏大且不能預知其最大值；

（4）數據一經處理，除非特意保存，否則不能被再次取出處理，或者再次提取數據代價昂貴。

用戶信令數據流的獨特性主要有：

（1）數據相對實時性；

（2）數據到達次序在短周期內無順序性；

（3）數據規模宏大，但由于用戶數與每天的使用頻率有一定規律，數據能夠進行估算。

（4）在進行位置分析時，由于算法復雜，并且要求較快的處理速度，中間數據不能采用

普通方式進行存儲。

流式大數據處理框架：

（1）Apache Storm，在Storm中，先要設計一個用于實時計算的圖狀結構，我們稱之為拓撲。這個拓撲將會被提交給集群，由集群中的主控節點分發代碼，將任務分配給工作節點執行。

（2）Apache Spark Streaming，核心是Spark API的一個擴展，在處理前按時間間隔預先將其切分為一段一段的批處理作業。

通過對當前業務系統的分析，都不太適合需求，原因如下：

（1）系統結構復雜；

（2）部分不太完善，實際使用中有不少BUG；

（3）不適合進行位置路徑處理；

（4）當前業務分析時帶有龐大的內存數據，不適合分布方式高速處理，能發低下；

（5）完成本業務需求中的數據需要龐大的計算機硬件資源；

結合位置信令特點，此次數據模型挖掘采用基于容器技術的微服務系統，平臺采用Golang開發的微服務系統再運行于基于Kubernetes加框的容器系統中完成流數據處理及其本業務系統中的所有服務。

由于位置信令流的獨特性，在流式處理前，需要進行一次基于內存計算的預處理。信令信息數據收集過程中，在5-10min內的數據，上無序數據，在進行流式處理前，需要對數據進行準確性排序處理，由于數據量非常大，系統采用10min延遲入庫，按分鐘切片排序，然后再匯合成正確時序的數據流。

2.4 位置信令數據抖動處理

何為抖動，指某用戶在兩個或多個小區基站中間時，可能由于無線信令原因，或者其在一個小小范圍的距離之間移動時，會頻繁的產生不同的位置信令，我們在對網格進行磁力聚合處理后，會自動處理部分數據，但不能完全達到合理，我們通過對該用戶的持續位置采樣，能夠分析出該用戶的信令特征，如果數據抖動注冊時，能夠將抖動產生的信令數據進行過濾，保證用戶路徑的穩定性與合理性。

抖動數據處理學習服務。在抖動處理中，利用了機器學習技術，系統能夠完成該區域多用戶持續性采樣學習，從而進行更準確的數據處理。

數據處理的過程就也是學習的過程，隨著系統不停運行，數據處理能夠得到持續優化。

當然這個學習過程也是非常耗費計算資源的，這里也充分地展示了基于彈性微服務架構的一個優勢，在流處理時，將初步判斷有抖動嫌疑的數據送到一個學習微服務，這個微服務可能在云計算中的其他節點，學習后的結果再階段性加入到流處理過程中。當學習負荷比較大時，可以按預先進行的容器編排設置啟動多個學習服務，學習服務負荷小的時間，再把資源釋放出來。還有一個重要的容錯特征，系統始終會保持一個或多個學習服務，即使其中一臺主機崩潰時，也會在短時間不到1min內在其他主機自動部署新的學習服務。

3 總結與展望

通過將挖掘后數據進行整合呈現，實現了交通OD的全局實時感知，可以細化到每個OD每條道路，每個交通小區，實現對交通治理的數據決策支撐。通過數據挖掘，某地市出行距離在5-10km的人群最多，達到32%，私家車出行的比例達到48%。

圖3 城市數據大腦—交通態勢實時感知圖

通過一個月內人員出行軌跡的分析計算，可得出公交快7線路的運力配置與客流高峰分布有差異。快7沿線職住分布及客流覆蓋率如下圖：

圖4 快7沿線職住分布及客流覆蓋率圖

快7沿線客流總需求及公交運力時間分布（早高峰）如下圖：

圖5 快7沿線客流總需求及公交運力時間分布（早高峰）圖