TW201639332A - 藉由使用數據承載特性分類應用程式類型來控制應用程式操作的系統和方法 - Google Patents

Abstract

藉由計算承載度量的統計向量和對應於該統計向量的標籤地圖上的定位點來將承載的應用程式類型分類以獲得應用程式類型資訊。該應用程式類型資訊被輸出到網路節點以控制應用程式的操作。承載度量包括承載識別符資訊和承載條件資訊，其中該承載狀態資訊包括通道條件資訊和細胞擁塞程度資訊。該承載是成對的，使得用於相同應用程式的上行鏈路和下行鏈路承載被識別，使得成對的承載被分類在一起。標籤地圖使用先前分類的承載資訊被產生以計算群集質心和定義該地圖為特定應用程式類型的部分的群集區域。該承載藉由確定哪一個群集區域最接近於在與用於特定承載的該統計向量相關的該標籤地圖上的點被分類。

Description

藉由使用數據承載特性分類應用程式類型來控制應用程式操作的系統和方法

範例實施例一般關於藉由基於數據承載特性分類數據承載的應用程式類型來控制應用程式操作的系統和方法。

圖1顯示傳統的第三代合作夥伴計畫長期演進(3GPP LTE)網路10。網路10包括網際網路協定(IP)連接存取網路(IP-CAN)100和IP封包數據網路(IP-PDN)1001。IP-CAN 100通常包括：伺服閘道器(SGW)101；封包數據網路(PDN)閘道器(PGW)103；策略和計費規律功能(PCRF)106；行動管理實體(MME)108和E-UTRAN節點B(eNB)105(即，基地台，在本文目的中，用語基地台和eNB可以互換地使用)。雖然未顯示，EPS的IP-PDN 1001部分可以包括應用程式或代理伺服器、媒體伺服器、電子郵件伺服器等。

在IP-CAN 100內，eNB 105是被稱為演進通用行動電信系統(UMTS)陸地無線電存取網路(EUTRAN)的一部分，以及包括SGW 101、PGW 103、PCRF 106和MME 108被稱為演進封包核心(EPC)的IP-CAN 100的一部分。雖然只有單一eNB 105被顯示於圖1中，應該理解的是，EUTRAN可以包括任意數量的eNB。同樣地，雖然只有單一SGW、PGW和MME被顯示於圖1中，應該理解的是，EPC可以包括任意數量的這些核心網路元件。

eNB 105針對一或多個用戶設備(UE)110提供無線資源和無線電覆蓋。這就是說，任何數目的UE 110可以被連接(或附著)到eNB 105。eNB 105被可操作地耦接到SGW 101和MME 108。

SGW 101路由和轉發用戶數據封包，同時在UE的eNB間切換期間也作為用戶平面的行動錨點。SGW 101也作為第三代合作夥伴計畫長期演進(3GPP LTE)和其它3GPP技術之間行動的錨點。對於閒置的UE 110，SGW 101終止下行鏈路數據路徑並且當下行鏈路數據到達時對於UE 110觸發呼叫。

PGW 103藉由UE 110的流量的入口/輸出的點來提供UE 110和外部封包數據網路(例如，IP-PDN)之間的連接。如已知的，給定的UE 110可以具有同時與一個以上的PGW 103連接以存取多個PDN。

PGW 103也執行策略實施、UE 110的封包過 濾、收費支援、合法攔截和封包篩選，其中每一個是眾所皆知的功能。PGW 103也作為用於3GPP和非3GPP技術，例如全球互聯微波存取(WiMAX)和第三代合作夥伴計劃2(3GPP2(碼分多重存取(CDMA)1X和增強語音數據最佳化(EVDO))之間的行動性錨點。

仍參照圖1，eNB 105也可操作地耦接到MME 108。MME 108是用於EUTRAN的控制節點，並且負責閒置模式UE 110的呼叫和標記程序，包括重新傳送。MME 108也負責在UE到網路的初始連接期間，以及在關於核心網(CN)節點重定位的LTE內切換期間選擇用於UE的特定SGW。該MME 108藉由與沒有在圖1中顯示的家用訂戶伺服器(HSS)的互動來驗證UE 110。

非存取層(NAS)信號終止於MME 108，並負責對於UE 110產生和分配臨時身份。MME 108也檢查UE 110的授權以停駐在伺服提供商的公共陸地行動網路(PLMN)，並執行UE 110漫遊限制。MME 108網路中用於NAS信號的加密/完整性保護的終止點，並處理安全密鑰管理。

MME 108也提供具有來自在MME 108終止的SGSN(未顯示)介面的LTE和2G/3G存取網路之間的行動性的控制平面功能。

該策略和計費規律功能(PCRF)106是做出策略決定和數套計費規律的實體。它可以存取訂戶數據庫並且在3GPP架構中扮演如同在3GPP TS 23.303中指定的 “策略和計費控制架構”。

圖2顯示傳統的E-UTRAN節點B(eNB)105。eNB 105包括：記憶體225；處理器210；排程器215；無線通訊介面220；針對每個承載的無線電鏈路控制(RLC)緩衝器230；以及後端介面235。處理器210也可以作為核心網路實體處理電路、EPC實體處理電路等。處理器210可以包括一或多個核心處理單元，無論是實體地耦接在一起或分散的。處理器210控制eNB 105的功能(如本文所述)，並且可操作地耦接到記憶體225和通訊介面220。儘管只有一個處理器210顯示在圖2中，應該理解的是，多個處理器可被包括在典型的eNB 105。由處理器執行的功能可以使用硬體來實現。這種硬體可以包括一或多個中央處理單元(CPU)、數位訊號處理器(DSP)、特殊應用程式積體電路、現場可程式化閘陣列(FPGA)電腦等。貫穿本文使用的用語處理器可以指任何這些範例的實現，儘管該用語並不限於這些範例。以虛擬無線電存取網路(VRAN)架構，各種功能的eNB元件可以跨多個處理電路和VRAN雲端內的多個實體節點分佈。

eNB 105可包括在個人幾何覆蓋扇形區域內的一或多個細胞或扇區。每個細胞分別可以包含圖2所示的元件。在本文中的用語eNB、細胞或扇區應互換使用。

仍參照圖2，通訊介面220包括各種不同的介面，其包括連接到一或多個天線以發送/接收(有線和/ 或無線地)控制和數據訊號到/從UE 110或經由控制平面或介面到其它EPC網路元件和/或RAN元件的一或多個發射器/接收器。後端介面235是eNB 105的部分，其在IP-CAN 100內與SGW 101和MME 108介面。排程器215將由eNB 105進行發送和接收到和來自UE 110的控制和數據通訊排程。記憶體225可緩衝和儲存被發送和接收到和來自eNB 105的數據。

每個傳輸時間間隔(TTI)，通常等於1毫秒，排程器215可以將一定數量的實體資源區塊(PRB)分配給在下行鏈路方向(即，從eNB 105發送到UE 110)和上行鏈路方向(即從UE 110接收在eNB 105的數據，其在後端235上接收)中無線鏈路上攜帶數據的不同承載。“承載”可以被理解為用於交換資訊以在UE 110上運行應用程式的鏈路或通道。排程器215可確定調變和編碼模式(MCS)，其可以定義每赫茲每秒有多少位元的資訊可被封包到PRB的分配數。後者是由3GPP TS36.213表7.1.7.1-1和7.1.7.2.1-1(其內容是藉由引用其整體來併入)所定義，其中MCS是由介於0和28之間的數來定義，其中較高的MCS值指出更多的位元可以被分配在若干PRB。表7.1.7.1-1和7.1.7.2.1-1包括用於若干數據位元的查找表，其可被包括在針對給定的分配數量的PRB和MCS值的每個TTI發送的PRB中。MCS是藉由使用由UE 110報告的通道品質指示符(CQI)值的排程器來計算，其接著可以從測量的UE 110無線通道情況以訊號對 干擾和雜訊比(SINR)的形式來衍生。

排程器215可基於代表流量優先權階層的伺服品質(QoS)程度識別(QCI)做出PRB分配決策。目前在LTE中定義有9個QCI程度，以1表示最高的優先權並且以9表示最低的優先權。QCI 1至4被保留用於該排程器維護某些特定數據流QoS特性的保證位元率(GBR)程度。QCI 5至9被保留用於各類型別的最大努力流量。

而排程器215操作不標準化，有可能是可普遍被接受的某些一般類型的排程器。範例包括嚴格優先權排程器(SPS)和按比例加權公平共享排程器(PWFSS)。兩類型型都試圖首先兌現GBR的需要，藉由分配專用的資源來盡可能滿足的GBR承載產出量的限制同時留下足夠的資源來維持非GBR類型的某些最低數據流量。該SPS以可能需要的資源(除了某些最小量的資源，以避免使低優先權類型飢餓)分配較高的優先權類型，並且較低優先權類型通常接收剩餘的資源。PWFSS將資源的某些權重共享給每個非GBR QCI類型，除非未利用的資源是可用的，否則不會被超過。

傳統上，運行在UE上的上層行動應用程式上的數據流量主要在使用最佳功效(BE)承載的網路上被攜帶。用語“最佳功效”通常表示承載流量不享有保證位元率，並且承載因此不提供保證的服務品質(QoS)。然而，在上層行動應用程式上的差異的通常具有不同的QoS 需求和/或要求。使eNB 105注意用於在特定的BE承載上攜帶的應用程式流量到UE的“應用程式類型情境”，如知道承載是否在進行按照需求的HTTP自適應串流(HAS)視頻、直播視頻直播、直播對話視頻、大檔案傳輸協定(ftp)應用程式、網路瀏覽搜索、電子郵件數據、間歇FTP應用程式(例如)，可成功地使各種技術可被用於改善對於特定行動應用程式的終端用戶經驗品質(QoE)。用語“應用程式類型情境”可以視為與用語“應用程式類型”同義並且“應用程式情境類型”貫穿本文可互換使用。

用於改善QoE的技術的範例可以包括可以由eNB排程器215實現的承載情境類型意識資源分配，其中不同的排程策略可被應用於取決於承載攜帶的應用程式情境的BE承載。這樣的排程策略差異可能在擁塞情況下特別有利。

傳統上，承載流量的應用程式情境類型可以藉由施加深度封包檢測(DPI)來獲得。開放系統互連(OSI)模型將通訊系統分割成7個概念層。從底部開始，這些層是：實體、數據鏈路、網路、傳輸、會話、表達和應用程式。網路中的數據封包包含標頭層，其允許封包的路由和處理。最外側的標頭對應於最低層。在IP網路中，封包使用代表網路層的網際網路協定(IP)標頭來路由。DPI通常關於檢查和分類應用程式IP封包標頭，其位於IP標頭層之外(即，屬於OSI層4~7的封包標 頭，從傳輸層開始)。傳輸層4可通常藉由傳輸控制協定(TCP)或用戶數據包協定(UDP)標頭被表示並可以負責應用程式會話封包的順序遞送和完整性驗證。在TCP的情況下，傳輸層4也可以負責應用程式會話封包的可靠傳送。會話層5提供開放、關閉的機制並且管理終端用戶處理之間的會話，藉由偵聽層4和層5標頭，包括在TCP或UDP標頭的來源和目的地TCP和UDP埠號，並施加眾所皆知的與特定應用程式相關的埠號，DPI技術可以分類應用程式類型和情境。當這些埠號提供足夠的資訊，DPI可以進一步查看會話層標頭，例如，即時串流協定(RTSP)會話標頭的存在可能指出該數據封包屬於直播對話視頻應用程式。

DPI技術具有數個顯著缺點。首先，多數的應用程式利用終端-終端數據流量加密(例如YouTube、Netflix、Skype等)，並且此加密不允許DPI技術在無線存取網路的數據流上被執行，因為在IP數據封包中的層4~7可以被加密。再者，即使當數據流沒有被加密，在eNB添加DPI能力(其中對於應用程式情境類型知識的真實需求存在)可能是成本高的。3GPP目前定義PGW用以主辦DPI功能，其中eNB可藉由使用來自隧道標頭的單一識別符域來執行從每個承載通用封包無線電流量(GPRS)隧道協定(GTP)隧道切換到空氣中的承載流的簡單數據流。因此，在eNB增加DPI功能可能需要成本高的硬體升級。可替代地，藉由發訊號從PGW傳遞確定 的應用程式情境資訊到eNB也可能需要非平凡的標準改變。

至少一個範例實施例關於一種藉由分類應用程式類型來控制應用程式之操作的方法。

在一個範例實施例中，該方法包括藉由至少一個網路節點的一或多個處理器來獲得用於一或多個承載的承載度量；藉由該一或多個處理器來計算用於該承載度量的統計向量；藉由該一或多個處理器，藉由將點定位於對應於該統計向量的標籤地圖上來將該應用程式類型分類以獲得應用程式類型資訊；藉由該一或多個處理器，輸出該應用程式類型資訊到網路節點的節點處理器以控制應用程式的操作。

在一個範例實施例中，該輸出包括輸出該應用程式類型資訊到運行應用程式功能的節點處理器，e-節點B的節點處理器，和用戶裝置的節點處理器，和管理實體節點的節點處理器中的至少一個以控制該應用程式的操作。

在一個範例實施例中，該獲得包括獲得係為無線電鏈路控制(RLC)緩衝器大小、實體資源區塊(PRB)利用率、傳輸叢發間隔和閒置時間間隔中的至少一個的每個承載度量。

在一個範例實施例中，該獲得進一步包括獲 得承載條件資訊和承載識別符資訊，該承載條件資訊包括承載通道條件資訊和細胞擁塞程度資訊中的至少一個。

在一個範例實施例中，該計算進一步包括，識別與該獲得的承載度量相關的承載對，其中每一對承載屬於相同的應用程式，並且包括攜帶上行鏈路傳輸的第一承載和攜帶下行鏈路傳輸的第二承載，針對每個該識別的承載對來計算用於承載度量的該統計向量。

在一個範例實施例中，該方法進一步包括藉由下列步驟來獲得該標籤地圖，在先前分類的承載上獲得承載報告，針對至少一個特定的應用程式類型來計算群集質心和定義的群集區域，該標籤地圖包括針對該至少一個特定的應用程式類型的該計算的群集質心和該定義的群集區域。

在一個範例實施例中，該承載報告包括針對包括承載識別符、先前識別的應用程式類型、先前計算的統計向量、先前確定的承載條件，和先前確定的在承載配對上的資訊中的至少一個的先前分類承載的基於每個承載的先前確定的承載資訊。

在一個範例實施例中，該分類進一步包括，位於或鄰近於對應於該統計向量的該標籤地圖的該定義的群集區域的定位點，其中與各定位點最接近的該至少一個特定的應用程式類型相關的該定義的群集區域被確定為該分類的應用程式類型。

在一個範例實施例中，與該標籤地圖的該獲 得相關的步驟被重複做為額外的承載的應用程式類型被分類成特定的應用程式類型之一。

至少一個範例實施例包括網路節點。

在一個範例實施例中，該網路節點包括一或多個處理器，其配置以，獲得一或多個承載的承載度量，針對該承載度量計算統計向量，藉由在對應於該統計向量的標籤地圖上的定位點來將該應用程式類型分類以獲得應用程式類型資訊，以及將該應用程式類型資訊輸出到處理器網路節點以控制應用程式的操作。

在一個範例實施例中，該一或多個處理器係進一步配置以藉由輸出該應用程式類型資訊到運行應用程式功能的節點處理器、e-節點B的節點處理器、和用戶裝置的節點處理器，和管理實體節點的節點處理器中的至少一個來將該應用程式類型資訊輸出以控制該應用程式的操作。

在一個範例實施例中，該一或多個處理器係進一步配置以藉由獲得係為無線電鏈路控制(RLC)緩衝器大小、實體資源區塊(PRB)利用率、傳輸叢發間隔和閒置時間間隔中的至少一個的每個承載度量來獲得該承載度量。

在一個範例實施例中，該一或多個處理器係進一步配置以藉由獲得承載條件資訊和承載識別符資訊來獲得該承載度量，該承載條件資訊包括承載通道條件資訊和細胞擁塞程度資訊中的至少一個。

在一個範例實施例中，該一或多個處理器係進一步配置以藉由下列步驟來計算統計向量，識別與該獲得的承載度量相關的承載對，其中每一對承載屬於相同的應用程式，並且包括攜帶上行鏈路傳輸的第一承載和攜帶下行鏈路傳輸的第二承載，針對每個該識別的承載對來計算用於承載度量的該統計向量。

在一個範例實施例，其中該一或多個處理器係進一步配置以，藉由下列步驟來獲得該標籤地圖，在先前分類的承載上獲得承載報告，針對至少一個特定的應用程式類型來計算群集質心和定義的群集區域，該標籤地圖包括針對該至少一個特定的應用程式類型的該計算的群集質心和該定義的群集區域。

在一個範例實施例中，該承載報告包括針對包括承載識別符、先前識別的應用程式類型、先前計算的統計向量、先前確定的承載條件，和先前確定的在承載配對上的資訊中的至少一個的先前分類承載的基於每個承載的先前確定的承載資訊。

在一個範例實施例中，該一或多個處理器係進一步配置以藉由下列步驟來將該應用程式類型分類，位於或鄰近於對應於該統計向量的該標籤地圖的該定義的群集區域的定位點，其中與各定位點最接近的該至少一個特定的應用程式類型相關的該定義的群集區域被確定為該分類的應用程式類型。

在一個範例實施例中，該一或多個處理器係 進一步配置以重複做為額外的承載的應用程式類型被分類成特定的應用程式類型之一的該標籤地圖的該獲得相關的步驟。

10‧‧‧網路

10a‧‧‧網路

100‧‧‧網際網路協定(IP)連接存取網路(IP-CAN)

101‧‧‧伺服閘道器(SGW)

103‧‧‧封包資料網路(PDN)閘道器(PGW)

105‧‧‧E-UTRAN節點B(eNB)

105a‧‧‧eNB

106‧‧‧策略和計費規則功能(PCRF)

108‧‧‧行動管理實體(MME)

110‧‧‧用戶設備(UE)

1001‧‧‧IP封包資料網路(IP-PDN)

205‧‧‧實體資源區塊(TMP)度量

210‧‧‧處理器

210a‧‧‧處理器

215‧‧‧排程器

220‧‧‧無線通訊介面

225‧‧‧記憶體

230‧‧‧無線電鏈路控制(RLC)緩衝器

235‧‧‧後端介面

240‧‧‧應用程式情境識別功能(ACIF)

250‧‧‧承載度量收集器(BMC)

260‧‧‧承載統計電腦(BSC)

270‧‧‧應用程式情境分類器(ACC)

280‧‧‧應用程式情境回報器(ACR)

300‧‧‧應用程式情境感知功能(ACAF)

310‧‧‧群集模板管理器(CTM)

320‧‧‧群集標籤器(CL)

330‧‧‧應用程式情境分佈器(ACTD)

340‧‧‧處理器

350‧‧‧記憶體

S600‧‧‧步驟

S610‧‧‧步驟

S620‧‧‧步驟

S630‧‧‧步驟

S640‧‧‧步驟

S650‧‧‧步驟

S700‧‧‧步驟

S710‧‧‧步驟

S720‧‧‧步驟

S730‧‧‧步驟

S740‧‧‧步驟

S750‧‧‧步驟

S760‧‧‧步驟

藉由參照附圖詳細描述範例實施例，範例實施例的上述和其它特徵和優點將變得更加清楚。附圖意在描述範例實施例並且不應當解釋為限制申請專利範圍的預期範圍。除非明確地指出，附圖並不被認為是按比例繪製的。

圖1顯示傳統的第三代合作夥伴計畫長期演進(3GPP LTE)網路；圖2顯示傳統的E-UTRAN節點B(eNB)；圖3根據範例實施例顯示重新配置3GPP LTE網路；圖4根據範例實施例顯示重新配置e-節點B；圖5根據範例實施例顯示應用程式情境感知功能；圖6是根據範例實施例使用承載特性的應用程式類型分類的方法；圖7是根據範例實施例的產生應用程式情境類型標籤地圖的方法；圖8A根據範例實施例描繪用於承載HTTP自適應串流(HAS)應用程式的承載的檢測無線電鏈路控制(RLC)緩衝器的範例；圖8B根據範例實施例描繪用於承載HTTP自適應串 流(HAS)應用程式的承載的檢測的實體資源區塊(PRB)分配的範例；圖9A根據範例實施例描繪用於實現檔案傳輸協定(FTP)應用程式的承載的檢測的無線電鏈路控制(RLC)緩衝器的的範例；圖9B根據範例實施例描繪用於實現檔案傳輸協定(FTP)應用程式的承載的檢測的實體資源區塊(PRB)分配的範例；圖10A根據範例實施例描繪用於實現間歇性檔案傳輸協定(FTP)應用程式的承載的檢測的無線電鏈路控制(RLC)緩衝器的範例；圖10B根據範例實施例描繪用於實現間歇性檔案傳輸協定(FTP)應用程式的承載的檢測的實體資源區塊(PRB)分配的範例；圖11A根據範例實施例描繪用於實現網際網路控制訊息協定(ICMP或“ping”)訊息的承載的檢測的無線電鏈路控制(RLC)緩衝器的範例；圖11B根據範例實施例描繪用於實現網際網路控制訊息協定(ICMP或“ping”)訊息的承載的檢測的實體資源區塊(PRB)分配的範例；圖12是根據範例實施例的關於應用程式類型對承載特性的表格；圖13A根據範例實施例描繪不同應用程式類型的群集的範例；以及 圖13B根據範例實施例描繪用於不同應用程式類型的群集區域。

儘管範例實施例能夠有各種修改和替代形式，其實施例藉由在圖式中範例的方式顯示並且將在本文中詳細描述。然而，應該理解，沒有意圖將範例實施例限制為揭露的特定形式，而是相反地，範例實施例將涵蓋所有在申請專利範圍的範圍之內的修改、等同物和替代物。相同的數字指代相同的附圖的描述的元件。

在更詳細地討論範例實施例之前，應當注意，一些範例實施例被描述為程序或描繪為流程圖的方法。雖然流程圖將操作描述為順序程序，但是許多操作可以並行地、同時地或同步地執行。此外，操作的次序可以被重新安排。當其操作被完成，程序被終止，但也可以具有未包括在圖中的額外步驟。程序可以對應於方法、功能、程序、子例程、子程式等。

下面討論的方法，其中一些是藉由流程圖來說明，可以藉由硬體、軟體、韌體、中間件、微碼、硬體描述語言，或其任意組合來實現。當以軟體、韌體、中間件或微碼實現時，用以執行必要任務的程式代碼或代碼段可以被儲存在機器或電腦可讀媒體，如儲存媒體，如非暫態儲存媒體。處理器可以執行必要任務。

本文揭露的具體結構和功能細節僅是代表性 的用於描述範例實施例的目的。然而，本發明可以體現為許多替代形式，並不應被解釋為僅限於這裡闡述的實施例。

應該理解的是，儘管用語第一、第二等在這裡可以用於描述各種元件，但是這些元件不應被這些用語限制。這些用語僅是用來將一個元件與另一個相區別。例如，第一元件可以被稱為第二元件，並且類似地，第二元件可以被稱為第一元件，而不偏離範例實施例的範圍。如本文中所使用的，用語“和/或”包括一或多個相關所列的項目的任意和所有組合。

應當理解，當元件被稱為“連接”或“耦接”到另一元件時，它可以被直接連接或耦接到另一元件或中間元件可以存在。相反，當一個元件被稱為被“直接連接”或“直接耦接”到另一元件時，不存在中間元件。用於描述元件之間關係的其他詞語應該以類似的方式解釋(例如，“之間”與“直接之間”，“相鄰”與“直接相鄰”等)。

本文所使用的用語僅用於描述特定實施例的目的，而不是意在限制範例實施例。如本文所用，單數形式“一”、“一個”和“該”也意圖包括複數形式，除非上下文清楚地另外指明。將進一步理解，用語“包含”、“包含”、“包括”和/或“包括”在本文中使用時，指定所陳述的特徵、整數、步驟、操作、元件和/或組件的存在，但不排除存在於或額外的一或多個其它特徵、整數、步驟、操作、元件、組件和/或其組合。

進一步應當注意的是，在一些替代實現中，指出的功能/動作可能不以在圖中指出的順序發生。例如，連續顯示的兩個圖實際上可以同時執行或有時可以以相反的順序被執行，其取決於涉及的功能/動作。

除非另有定義，否則這裡使用的所有用語(包括技術和科學用語)具有如範例實施例屬於的領域的普通技術人員通常理解的相同含義。將進一步理解，用語，例如那些在常用字典中定義的，應當被解釋為具有在相關領域的上下文中的含義一致的含義，並且不會被解釋為理想的或過於正式的意義，除非在此明確定義如此。

範例實施例的部分和對應的詳細描述以電腦記憶體內的軟體，或演算法以及對數據位元操作的符號呈現來表示。這些描述和表示是由本領域普通技術人員有效地傳達他們的工作實質給其他本領域普通技術人員。演算法，如在這裡使用的，並且因為它是通常使用的，被設想為導致期望結果的步驟的前後一致的序列。步驟是那些需要實體量的實體操作。通常，儘管不是必須的，這些量採用能夠被儲存、傳輸、組合、比較，以及操作的光、電，或磁訊號的形式。它已隨時間證明，主要由於普遍使用的原因，將這些訊號稱為位元、值、元件、符號、字符、項目、數字等。

在下面的描述中，說明性的實施例將參照動作和操作的符號表示來描述(例如，以流程圖的形式)，其可以被實現為程式模組或功能程序包括例程、程式、物 件、元件、數據結構等，其執行特定任務或實現特定抽象數據類型，並可使用在現有網路元件的現有硬體來實現。這樣的現有硬體可以包括一或多個中央處理單元(CPU)、數位訊號處理器(DSP)、特殊應用程式積體電路、現場可程式化閘陣列(FPGA)電腦等。

應當牢記，然而，所有這些和類似的用語都將與適當的實體量相關並且僅僅是應用程式於這些量的方便的標籤。除非特別指出，否則，如從討論中顯而易見的，諸如“處理”或“運算”或“計算”或“顯示”的“確定”等，指的是電腦系統或類似電子計算裝置的動作和處理，其操縱和轉換表示為電腦系統的暫存器和記憶體內的實體、電子量的數據成類似地表示為電腦系統記憶體或暫存器或其它這種資訊記憶體、傳輸或顯示裝置內的實體量的其他數據。

也應注意，範例實施例的軟體實現態樣通常被編碼在某種形式的程式儲存媒體上或者藉由某類型的傳輸媒體來實現。程式儲存媒體可以是任何非暫態儲存媒體，例如磁性的(例如，軟碟或硬碟)或光學的(例如，唯讀光碟，或“CD ROM”)，並可以是唯讀或隨機存取。類似地，傳輸媒體可以是雙絞線、同軸電纜、光纖，或本領域已知的一些其它合適的傳輸媒體。範例實施例不被任何給定實現的這些態樣限制。

一般方法：

範例實施例獲得用於無線電存取網路細胞的各別承載的應用程式情境(即，應用程式“類型”)上的資訊。應用程式類型的知識意味著服務品質(QoS)的應用程式，對於與最佳功效(BE)無線電存取承載相關的應用程式，其可被獲得而無需施加深度封包檢測(DPI)。

在一般情況下，對於在eNB的特定承載度量，應用程式類型可以藉由施加具有群集技術的數據分析被識別。範例實施例可以適合於攜帶流量的承載，其屬於單一行動應用程式類型，或屬於多個同時應用程式類型的流量，對數據量而言是主導的應用程式類型中的一個。範例實施例可被實現在智慧手機和平板電腦上的行動應用程式，其中通常有單一主導的前台應用程式(如視頻、網頁瀏覽、社交網路應用程式)。

圖3顯示重新配置的3GPP LTE網路10a。網路10a可以包括相同的元件，如圖1的3GPP LTE網路10中所顯示的那些，具有以下不同。首先，IP-CAN 100a可以包括重新配置的eNB 105a(顯示於下面圖4)，其可包括應用程式情境識別功能(ACIF)240，其功能進一步在圖4和圖6中描述。其次，IP-CAN 100a可以包括應用程式情境感知功能(ACAF)300，其功能進一步在圖5和圖7中描述。應當理解的是，ACAF 300可以被包括於獨立的、專用伺服器(如顯示於圖3)，其可以由專用伺服器處理器來控制。可替代地，ACAF 300可以替代地包括在eNB 105a中，或者在任何其他現有節點(例如MME 108 或SGW 101)，其可以是相當接近eNB 105a和IP-CAN 100a內。

圖4根據範例實施例顯示重新配置的e-節點B(eNB)105a。具體地，重新配置的eNB 105a可以包括額外的應用程式情境識別功能(ACIF)240，其可以與排程器215、RLC緩衝器230和後端介面235介面。具體地，ACIF 240可以包括以下元件：承載度量收集器(BMC)250、承載統計電腦(BSC)260、應用程式情境分類器(ACC)270，和應用程式情境回報器(ACR)280。如下述，ACIF 240的元件的功能被定義並且關於圖6的流程圖被說明。

圖5根據範例實施例顯示應用程式情境感知功能(ACAF)300。ACAF 300可包括以下元件：群集模板管理器(CTM)310，其又可以包括群集標籤器(CL)320，和應用程式情境分佈器(ACTD)330。ACAF 300可選擇性地包括記憶體350和處理器340，如果ACAF 300是專用的、獨立的伺服器(如圖3所示)。如果ACAF 300被包含在eNB 105a或另一個現有的網路節點內，該專用的記憶體350和處理器340可以不需要。在下面詳細描述，ACAF 300的元件的功能被定義，並且關於圖7的流程圖被解釋。

圖6根據範例實施例是使用承載特性的應用程式類型分類的方法。圖6的討論關於ACIF 240的元件的功能(顯示於圖4)，其中步驟被描述為由處理器240 執行。關於圖6，應該理解的是，應用程式數據消耗模式可使用一些以下的指標來表徵：(a)由應用程式發送/接收到的數據速率的特徵，(b)數據傳輸叢發(持續時間、峰值等)的特徵，(c)閒置週期期間，其為沒有數據被發送時的期間，以及(d)“拉與推”的數據傳輸模式。

應當理解的是，“拉模式”是當應用程式終端(例如，在行動裝置上的用戶端)發送請求以從網路獲得數據，其中此請求被發送到應用程式同儕，以使應用程式終端可以接收數據(作為對請求的響應)。“推模式”關於發送數據而無需事先請求的應用程式端點。在拉模式中的應用程式操作的範例包括HTTP自適應串流(HAS)視頻、檔案傳輸協定(FTP)、網路瀏覽。在推模式中的應用程式操作的範例包括現場對話視頻，或視頻廣播。

為了表徵上面列出的指標，在步驟S600中，處理器240可導致BMC 250用以收集下列感興趣的每個承載度量，其可隨後發送至BCS 260：

(1a)對於下行鏈路承載，在時間間隔△t₁的平均RLC緩衝器大小(佔有率)，其中時間△t₁可以是例如被配置以介於1秒和50毫秒之間。

(1b)對於上行鏈路承載，在無線傳輸之前儲存數據的緩衝器可以位於UE 110。因此，對於上行鏈路承載，感興趣的度量可以被定義為在時間間隔△t₁期間 藉由無線鏈路接收的承載數據的平均量，其中△t₁可以被配置為與度量(1a)相同。

(2a)對於下行鏈路承載，在連續時間間隔的長度(持續時間)和頻率的平均(超過時間間隔△t₂)RLC緩衝器大小保持在M位元組之上，其中M可以是例如配置以在0和10000位元組之間。時間△t₂可以配置以在0和1000毫秒之間。如藉由RLC緩衝器大小指示符測量的，這些時間間隔可以表示傳輸叢發(上述的指示符(b))。如藉由RLC緩衝器大小指示符測量的，這些時間間隔(傳輸叢發)之間的間隙代表傳輸閒置時間(上述的指示符(c))。當M被配置為0，這些測量表示時間間隔期間的長度和頻率，其中RLC緩衝器不是空的，其可以作為用於攜帶單一應用程式的流量的承載的傳輸叢發的表徵。M可被配置為大於0以表徵用於攜帶一個主導應用程式和一或多個背景應用程式的承載的主導應用程式的傳輸叢發。

(2b)對於上行鏈路承載，在無線傳輸之前儲存數據的緩衝器可以位於UE 110。因此，對於上行鏈路承載感興趣的度量可被定義相同於度量(2a)，但用於追蹤在無線鏈路上接收的承載的數據量，而不是追蹤RLC緩衝器大小的目的。

整個說明書的其餘部分，為簡單起見在下行鏈路承載的情境中應當稱為度量(1)和(2)(指(1a)和(2a))。相同的描述應適用於上行鏈路承載，對於上 行鏈路承載不同的是，該度量關於在無線鏈路上接收的承載數據的量，而不是RLC緩衝器大小。

(3)PRB的平均數藉由在時間間隔△t₁的排程器分配給承載(其中，此度量同樣適用於上行鏈路和下行鏈路承載)此時間間隔△t₁可以被配置與上方度量(1)相同。

(4)長度(持續時間)和連續時間間隔的頻率(時間間隔△t₃上的平均)在此期間，PRB利用率可能低於每秒N PRB的閾值(其中，此度量同樣適用於上行鏈路和下行鏈路承載)。這些時間間隔可能代表藉由PRB利用率測量的閒置週期(上述指示符(c))。這些時間間隔之間的間隙可以表示傳輸叢發時間(上述指示符(b))，如藉由PRB利用率測量的。由於資源被分配給其他承載，為了導致排程器215不分配資源給承載，時間間隔△t₃可以被配置為例如20和200毫秒之間(而不是因為沒有數據要發送)。時間間隔△t₃也可以被配置為根據由排程器服務的目前承載數目的變數。閾值N可以被配置為範圍，例如，每秒介於0和500 PRB之間。當N被配置為0，這些測量代表長度和時間間隔的頻率，在此期間，沒有資源藉由公平排程器被分配，其作為閒置時間的特性，用於攜帶單一應用程式流量的承載。N可以被配置為大於0，以表徵主要應用程式的閒置時間，用於攜帶一個主要應用程式和一或多個背景應用程式的承載。

度量(1)和(3)可以表徵指示符(a)、 (b)和(c)，因為這些量度反映應用程式接收/傳送來自/到網路的數據量和這些數據傳輸的頻率。此外，在度量(1a)中可觀察的模式可以指示傳輸控制協定(TCP)擁塞窗口行為。在度量(1)和(3)的峰值可指示傳輸叢發(表徵指示符(b))，而空的延長時間的(或低於閾值M)RLC緩衝器和零(或低於閾值N)的平均PRB利用率可表徵閒置時間週期(其表徵指示符(c))。度量(2)和(4)可以提供指示符(b)和(c)的特定表徵。為了藉由上述(4)收集度量(1)，每個時間單元序列可針對每個承載被收集(其中時間單位等於在排程器215排程資源並且可以等於1毫秒的頻率)，記為：R _k ：={r _k (n)：n=0,1,2,...}--等式1

以及，P _k ：={p _k (n)：n=0,1,2,...},--等式2其中n可以是時間單元數；在可從排程器215獲得的時間單位n期間，p _k (n)可以是配置到承載k的PRB數目；對於下行鏈路承載k，r _k (n)可以是在時間n用於承載k的RLC緩衝器大小；對於上行鏈路承載k，r _k (n)可以是在時間單位n期間藉由無線鏈路接收的沒有錯誤的承載k數據量，其可從排程器215獲得。

針對承載k從序列R _k (等式1)和R _k (等式2)計算的上述四個度量(1)-(4)可以被分別表示為,i=1,2,3,4。度量和可以被計算為在每個時間單位m的平均值序列如下

(m)可以是在持續時間△t₁的時間間隔的RLC緩衝器的平均尺寸，其在測量時間點m結束(T是在時間間隔△t₁中的時間單位數，並且△t₁在上述度量(1)中所定義)。

(m)可以是在持續時間△t₁的時間間隔的平均PRB配置，其在測量時間點m結束(T是在時間間隔△t₁中的時間單位數，並且△t₁在上述度量(1)中所定義)。

用於承載k的度量和可以被分別計算為數據叢發和閒置時間間隔的持續時間的序列：

其中(l)對於i=2,4，可以如下被計算。

其中(l)係使用RLC緩衝器尺寸數據(來自等式1)R _k 計算的時間間隔數l的長度(持續時間)，(l)是使用PRB利用率數據P _k(來自等式2)計算的時間間隔數l的長度(持續時間)，α _i 是介於0和1之間的配置數，其表示確定使用RLC緩衝器的對應時間間隔數l的長度與使用PRB利用率的對應時間間隔數l的長度的相對權重。指數i=2代表傳輸叢發時間間隔的持續時間，指數i=4代表閒置時間間隔的持續時間。用於(l)和(l)的計 算的範例實施例如下。

在一個範例實施例中，(l)可以被計算為時間間隔((l),(l))的長度(持續時間)的序列量，平均RLC緩衝器大小可以至少是M。作為時間間隔開始的(l)以及作為時間間隔數結束的(l)順序可以被計算為如下： 其中，n為對應的時間單元數；(n)為平均的RLC緩衝器大小在從n-△t2至n(持續時間△t2)的時間間隔，其可以使用等式4來計算，其中，在等式4中用於此計算的目的，m等於n，並且T等於△t2，其中m和△t2係在度量(2)中被定義。

其中，(l)和(l)各別為對於時間間隔△t2平均的平均時間間隔數的左和右端點，RLC緩衝器大小可以大於在上述度量(2)定義的變量M。

接著(l)可以被計算為各自的時間間隔長度(持續時間)如下：

在一個範例實施例中，(l)可以被計算為由等式8和9確定的時間間隔((l),(l))之間間隙的長度(持續時間)的序列：

在一個範例實施例中，(l)可以被計算為平均 PRB利用率可以至少為N的時間間隔((l),(l))的長度(持續時間)的序列，作為間隔數開始的(l)，以及作為時間間隔數結束的(l)可以被計算如下： 其中，n為對應的時間單元數；(n)可以是在從n-△t3到n的時間間隔(持續時間△t3)的平均PRB利用率，其中(n)可以使用等式4來計算，其中在等式4中用於該計算的目的，m等於n，T等於△t3，以及其中N和△t3是在上面度量(4)中定義的。使用等式12和13計算的(l)和(l)係為時間間隔數的左和右端點，其中平均的PRB利用率可以小於上面度量(4)中定義的變量N。

接著(l)可以被計算為時間間隔的長度(持續時間)：

在一個範例實施例中，(l)可以被計算為由等式12和13確定的時間間隔((l),(l))之間的間隙的長度(持續時間)序列：

注意，由於序列(l)和(l)儘管代表數據傳輸叢發(如，閒置時間)中的間隙長度(持續時間)，也可以作為數據傳輸叢發的頻率的指示符。同樣地，(l)和(l)儘管代表數據傳輸叢發的長度(持續時間)，也指出 在數據閒置期間中的差距，因此作為閒置週期的頻率。

注意，和可以被計算為利用在時間窗口△t1(其中△t1可以被配置為50毫秒至1秒之間的時間間隔)的平均值的序列。用於計算度量,i-2,4的序列(l)可使用在時間窗口△t2的RLC緩衝器大小的平均值(n)來計算，作為傳輸叢發時間間隔的序列對於(n)M保持i=2，以及作為閒置時間間隔的序列對於(n)<M保持i=4。用於計算度量,i=2,4的序列(l)可以使用在時間窗口△t3的PRB利用率的平均值(n)來計算，作為發送叢發時間間隔的序列對於(n)N保持i=2，以及作為閒置時間間隔的序列對於(n)<N保持i=4。配置參數M、N、△t1、△t2、△t3可以用來調諧四個度量。

其他配置參數可以包括在等式7中的參數α_i,i=2,4。例如，配置α_i=1導致在度量,i-2,4中對應的時間間隔的持續時間係僅使用RLC緩衝器數據被計算。配置α_i=0導致在度量,i=2,4中對應的時間間隔的持續時間係僅使用PRB利用率數據被計算。配置α_i=0.5導致對應的時間間隔的持續時間係被計算為使用RLC緩衝器數據和PRB利用率數據計算的持續時間平均值。配置α_i>0.5產生RLC緩衝器數據的更多權重。

一種特殊情況可以是一種情形，其中平均的RLC緩衝器總保持幾乎是空的(例如，如圖11A所示，用於ICMP ping，由於低容量和不經常發射)，即，(n)對於所有的n可以總是小於M，從而可以由單一元件0 組成，並且可以由等於大的持續時間I的單一元件組成： 其中I可以被分配為等於記錄的承載會話的長度，或一些其他預定的大值。

另一種特殊情況可以是一種情形，其中RLC緩衝器可以總是高於閾值M(例如，如圖8A所示用於FTP)，即r_k(n)>M對於所有的n，從而可以由單一元件0組成，並且可以由等於大的持續時間I的單一元件組成： 其中I可以是和等式16相同的。

雖然R_k和P_k的測量可在小的時間尺度，如1毫秒被收集，該度量和基於序列,i=1,2,3,4的處理統計的計算可根據計算成本和識別靈敏度之間的折衷操作者偏好以應用在更大的時間尺度。

除了如上所述感興趣的每個承載度量，在步驟S600中的BMC 250可以收集來自排程215的承載條件數據。承載條件數據可包括承載的通道條件和細胞的擁塞程度。

承載通道條件可以用一或多個形式來收集，包括如由UE110報告的平均訊號對干擾和雜訊比(SINR)、平均通道品質指示符(CQI)、或如由排程器215報告的平均調變編碼方案(MCS)。

在一個範例實施例中，細胞擁塞程度可以用介於0(無擁塞)之間的整數值的形式被收集和具有映射到每秒最大平均數量PRB(MAVNPPS)的配置範圍的擁塞程度數中的每一個的配置的MC(最大擁塞)，該MAVNPPS可用於如排程器215報告的承載。例如，具有11個擁塞程度被配置，擁塞程度0可配置以指示MAVNPPS大於10000、擁塞程度1可配置以指示MAVNPPS 9000和10000之間、...、擁塞程度10可配置以指示MAVNPPS介於1000和2000之間、擁塞程度11可配置以指示MAVNPPS低於1000。

BMC 250可連同承載識別符傳遞收集的每個承載度量和條件數據到BSC 260。承載識別符可以是數字或字母數字序列，其唯一地識別eNB 105a內的承載。

在步驟S610中，處理器240可導致BCS 260用以識別包含攜帶屬於相同應用程式的上行鏈路和下行鏈路數據的承載對的“複合承載”。構成“複合承載”的承載對的識別可在承載建立時藉由將用於同樣的用戶裝置(UE)終端的上行鏈路和下行鏈路承載的存取點名稱(APN)和服務品質(QoS)類型識別(QCI)的組合匹配來執行，例如，上行鏈路和下行鏈路最佳功效(BE)QCI 9承載對於相同的UE具有相同的APN。BSC 260也可以使用對於相同APN和相同UE的上行鏈路和下行鏈路承載的建立時間，作為額外的承載匹配標準(即，對於相同應用程式的承載可被建立為在時間上非常接近彼此)。 藉由比較上述用於識別上行鏈路和下行鏈路承載對的四個度量，BCS 260可以分類推拉數據傳輸，其可被用來表徵指示符(d)。例如，具有小週期性上行流量的大下行鏈路承載容量可以是基於下行鏈路拉力的TCP的指示。大致相同大的同步上行鏈路和下行鏈路容量可以是基於即時對話視頻的UDP或TCP的指示。

在步驟S620中，對於每對識別的上行鏈路和下行鏈路承載，統計向量可用於從等式3和6來確定感興趣的度量，i=1,2,3,4。

雖然，R_k和P_k的測量可在小的時間尺度，例如1毫秒被收集，該度量的計算和基於序列，i=1,2,3,4的處理統計可以應用於更大的時間尺度，根據計算成本和識別靈敏度之間的折衷操作者偏好。

感興趣的度量統計：

要確定承載正常行為，機率密度函數可以從收集的四個度量，i=1,2,3,4的取樣序列來確定。根據網路操作者關於計算成本的偏好，對機率密度估計的各種方法可選擇性地包括：直方圖，使用最大可能性估計的眾所周知的參數密度估計，和非參數密度估計，諸如核心密度估計。在一個範例實施例中，度量，i=1,2,3,4可藉由對於i=1,2,3,4的其直方圖=(,...,)被個別地表徵，其中第i個度量的取樣可以被量化成Q_i間隔(λ₁,...,)。的期望和變異可接著如下被估計：

在一個範例實施例中，承載k的數據消耗行為可以藉由如下的刻意向量被表徵，

在另一範例實施例中，簡化的向量可以被用於如下：

在又一範例實施例中，用以表徵承載k行為的一種更複雜但更精確的方式可以藉由考慮，i=1,2,3,4的共同性能和配製四維變量Y _k 其中 來確定，其中四維直方圖 H _k ：=(k _k,1,...,h _k,Q )可用為離散狀態空間尺寸的Q被計算。第k個承載的性能可以被表徵為：

在又一範例實施例中，簡化的向量可被用於：

在又一範例實施例中，為了更好地表徵雙向應用程式的行為，計算的統計特徵可以包括攜帶應用程式流量的上行鏈路和下行鏈路承載(如針對給定UE的BE上行鏈路和BE下行鏈路承載)。對於上面列出的每個替代方案，一種“複合承載”包括下行鏈路和上行鏈路承載的匹配對可被如下表示：

其中向量C _k可以包含C _k(上行鏈路)和C _k(下行鏈路)的座標並且C _k(上行鏈路)和C _k(下行鏈路)各可以使用在等式20、21、22和23所描述的替代方案之一來計算。

作為步驟S620的一部分，處理器240可以導致BSC 260用以轉發度量(1)-(4)的確定統計向量連同承載條件和承載識別符到ACC 270。

在步驟S630中，處理器240可導致ACC 270從CTM 310請求對應於每個承載的承載條件的應用程式情境類型標籤地圖(ACTLM)。ACTLM提供對應於不同應用程式情境類型的統計向量圖的不同區域的描述。

用於說明的目的，ACTLM的範例在圖13B中給定，如圖所示，具有用於單一下行鏈路承載的統計向量的3維圖被計算為度量,i=1,2,3,4的預期值。在這個範例中，兩個水平軸顯示度量和的期望值，並且垂直軸顯示的度量和的期望值的比率。該軸和在該ACTLM中的維度數目可被配置為根據在S620中計算的統計向量的選擇。在一個範例實施例中，該軸和在該ACTLM中的維度數目的選擇可以基於在等式18~24描述的統計向量中的至少一個。

不同的承載條件可能導致在無線鏈路產出量的差異，而由於在不同無線鏈路的產出量特性下度量(1)-(4)的行為差異又可能會產生不同ACTLMs。例 如，圖13B中的ACTLM可提供用於以下的承載條件類型：擁塞程度0(無擁塞)，和MCS 26至27。ACAF 300內的CTM 310可以計算並保持每個類型的承載條件的ACTLMs，使用從各種eNB 105a的ACR 280接收的承載度量。如下述，ACTLM計算、承載條件類型以及ACAF 300的元件的功能的進一步細節被定義並關於圖7的流程圖被解釋。

返回到圖6，在步驟S640中，處理器240可以導致ACC 270用以從承載對的每個上行鏈路-下行鏈路統計向量識別應用程式情境類型。在一個範例實施例中，識別可藉由將點與對應於在ACTLM圖上具有應用程式情境類型區域的統計向量的座標匹配來執行，其中如果代表在ACTLM圖上的承載統計向量的點可位於可被以特定應用程式情境類型標記的區域內則發生完全匹配。如果完全匹配不發生(表示在圖上的承載統計的點位於任何標記的區域外)，則承載可被分類至最接近的標記區域的應用程式類型。如下述，標記的區域和ACTLM圖形上的點和標記區域之間的距離的概念關於圖7的流程圖被定義並被解釋。

在最後的步驟S640，ACC 270可以轉發每個承載的數據到ACR 280。轉發的數據可以包括，對於每個承載的承載識別符、識別的應用程式情境類型、計算的統計向量、承載條件、承載類型：上行鏈路(UL)或下行鏈路(DL)，和在步驟S610中確定的UL-DL對中的匹配 相反方向承載的承載識別符。

在步驟S650中，處理器240可導致ACR 280用以連同報告的時間戳記和eNB 105a的唯一細胞ID從ACC 270轉發在步驟S640中接收的數據到ACAF 300。

此外，如果配置是這樣，在步驟S650中，ACR 280可以(對於至少一個承載)將承載ID連同識別的應用程式情境類型轉發到排器215。

在一個範例實施例中，ACR 280可以被配置以只轉發關於特定應用程式情境類型(例如HAS應用程式)或類型組(例如HAS和會話視頻)的承載資訊給排程器215。

在另一範例實施例中，ACR 280可以被配置以只轉發屬於特定的UE 110的承載的承載應用程式情境類型資訊給排程器215。

在接收承載應用程式情境類型時，排程器215可以採用特定排程策略(其對於不同應用程式情境類型可能是不同的)來排程用於承載的PRB分配，以提高的終端用戶的經驗品質(QoE)。這樣的排程策略差異在擁塞情況下可能尤其有利。在一個範例實施例中，即使在擁塞條件下，排程器215可提供某些最小頻寬保證到攜帶行動視頻流量的最佳功效承載，對於FTP或IFTP承載，稍長檔案下載時間為代價。這樣的排程差異可能會為行動視頻用戶提供顯著的QoE改善(如，沒有視頻中止、視頻始終播放)，而沒有對於FTP或IFTP用戶在QoE的顯著下 降(如，對於終端用戶，稍長檔案下載甚至可能不易察覺)。

圖7是根據範例實施例產生應用程式情境類型標籤地圖的方法。圖7的討論關於在圖5中所示的ACAF 300的元件的功能。雖然以下步驟被描述為由處理器340執行(用於ACAF 300的專用處理器)，但應該理解的是，在eNB 105a的處理器(處理器210a)，或在另一網路節點的另一處理器可以替代地執行這些步驟。

CTM 310可以接收並處理從位於在無線電存取網路中的各種eNB 105a的ACRS 280被接收的數據報告的每個承載的記錄。在步驟S700中，處理器340可導致CTM 310用以在記憶體中儲存先前的記錄接收的每個承載報告。各記錄可以包括報告何時被接收的時間戳記、報告的承載識別符、識別的應用程式情境類型、計算的統計向量、承載條件、承載類型(上行鏈路(UL)或下行鏈路(DL))，和在UL-DL對中的匹配相反方向承載的承載識別符。該記錄可包含在不同時間對同一承載接收的報告的多個範例。

CTM 310可進一步將屬於同一承載條件分類的記錄聚合在一起。承載條件可藉由報告的承載通道條件的元組組成和報告的細胞擁塞程度(如上所定義)被識別。可能的承載條件可被分成非重疊承載條件分類的配置離散有限集。承載條件的類型可以包括具有某種範圍的報告的承載通道條件的承載條件和某種範圍的報告的細胞擁塞程 度。例如承載條件的類型可以包括具有報告的平均MCS值20和擁塞程度5的承載條件。在另一範例中，承載條件類型可以包括具有擁塞程度2或3和平均MCS值介於18和20之範圍內的承載條件。

CL 320可分類來自屬於同一類型的承載條件的複合承載報告的統計向量，以使統計向量可以被分組到對應於應用程式情境類型的“群集”。如在本文詳細描述的，用語“群集”關於圖形地分組具有相似統計向量(例如參見圖13A和13B)的承載報告，以便接著分類該承載到應用程式情境類型。注意，圖的維度數目以及軸的值可以根據在步驟S620中計算的統計向量的選擇被配置。作為範例，在圖13A和13B的圖具有3維(3軸)，與用於單一下行鏈路承載的統計向量，其可僅被計算為度量,i=1,2,3,4的期望值。兩個水平軸顯示度量和的期望值，而垂直軸顯示度量和的期望值。

在一個範例實施例中，軸和圖中維度數目的選擇可以基於在等式18~24中描述的統計向量中的至少一個。注意，配置統計向量的每個座標值可存在不同尺度。用於群集的目的，這些值可以用最大振幅來標準化，使得值的範圍可落入區間，其中該區間可以被定義為[0,1]。在一個範例實施例中，眾所皆知的群集演算法如模糊C-均值(FCM)群集可以被施加用以群集向量{C _k ：k-1....k}。

通常，群集演算法最佳化群集質心 Z：={Z _l ：l=1,...,L}，其中L代表數個群集，並且第k個複合承載可以被分配給第l個群集(或稱為成員)的機率U={u _kl ：k=1,...,K；l=1,...,L}可藉由最小化距離函數的總和被確定，如示： 其中d(x,y)可以是距離函數。在一個範例實施例中，d(x,y)可以是歐幾里得距離∥x-y∥。在另一範例實施例中，其中C _k 可以是聯合多維度直方圖，作為距離函數的Kullback-Leibler(KL)差異可以被表示為

由於統計向量可在高維度空間中被群集，標準的FCM演算法僅在數據集包含可以是大致相同的形狀(例如，超球面)的群集時可以被使用。為了克服此限制，可以實現之更適當的方法是眾所皆知的基於核心的FCM方法。此方法允許在高維度空間中的樣本的分離，其中，在低維度Hilbert空間，這樣的分離/分類是不可行的。

CL 320可執行應用程式情境類型群集的標註：

群集演算法可以識別群集質心，和在圖中的每個群集包圍它的不同區域，其可作為可表徵群集中分組的應用程式的標籤。對於特定類型的承載條件的這種標籤的集合可稱為應用程式情境類型標籤地圖(ACTLM)，其對應於承載條件類型。

圖12是根據範例實施例關於用於一類型的承載條件的承載特性的應用程式類型的基本表。在圖12中承載條件的類型可藉由以MCS值26或27和擁塞程度為0報告的承載通道條件來定義。該表可以藉由使用如替代二簡化向量(藉由等式21定義的)計算的報告統計資訊 來得到，其中特性的選擇可表示為。 在本範例中，E()可以是期望的值，以及V()可以是用於下行鏈路承載k由等式3和6所定義的四個度量中的每一個，其中度量可以基於RLC緩衝器數據(等式7中α ₂=1)被單獨定義，並且度量可以基於PRB利用率數據(等式7中α ₄=0)被單獨定義。特別地，E()可以是用於下行鏈路承載k的平均RLC緩衝區大小的期望值(有時也被稱為平均值)。E()可以是用於下行鏈路承載k的平均數據傳輸叢發時間間隔的期望值(如藉由使用具有α ₂=1的等式7與等式10的RLC緩衝器大小數據計算的)，並且V()可以是指示用於傳輸叢發時間間隔的持續時間的記錄值與期望值如何顯著地不同的變異。E()可以是用於下行鏈路承載k的平均PRB利用率的預期值。E()是用於下行鏈路承載k的平均閒置時間間隔(如藉由使用具有α ₄=0的等式7與和等式15的PRB利用率數據計算的)的持續時間的期望值，並且V()是指示用於閒置時間間隔的持續時間的記錄值與期望值如何顯著地不同的變異。

在一個範例實施例中，L質心表示為 {Z _l： l=1,...,L}，報告中的統計向量可以包括期望和基於每個承載針對每個度量,i=1,2,3,4計算的變異，其中第1組可代表屬於同一類型的承載條件的分組的承載進行的應用程式行為。每項度量的期望和變異可分別表示為和。根據和的分佈，群集可以針對不同類型的應用程式被識別。例如，高,i=1,3和高,i=2,4表示高的數據傳輸需求，而較少的圖案(不規律、非週期性)可以在數據請求頻率中找到，其可對應於應用程式，例如網頁瀏覽或間歇檔案傳輸協定(IFTP)。

圖13A根據範例實施例描繪具有類似的承載條件(來自相同類型的承載條件)的不同承載應用程式情境類型的群集的範例。具體而言，圖13A顯示使用 軸的三維群集的範例，其中該第三軸顯示 E()和E()的比率。()和E()的值可被標準化到0和1 之間，並且值可以被標準化到0和N之間。表徵下行 鏈路承載的向量並且其對應的應用程式落 入顯示於圖中的四個不同區域(標記為IFTP、PING HAS和FTP)。藉由分析代表四個區域的質心，我們可以辨別可能是附近區域的應用程式群組。

圖13B顯示根據範例實施例的用於不同應用程式類型的群集區域。具體而言，圖13B顯示具有包含E()軸和E()軸的平面，其可以被劃分成由索引1至9 表示的區域，而垂直軸可以被劃分成由符號A、B和 C表示的間隔。該有限狀態空間可以被劃分成二十七個子 區塊(或子區域)，以及不同的應用程式落入子塊中的一個。用於一類型型承載條件(MCS 26或27，和擁塞程度0)的ACTLM在本範例實施例中是應用程式情境類型群集質心和圍繞它們的不同區域的收集(C3用於HAS、C8用於FTP、A1用於ping、B1用於IFTP)。

結合圖12查看圖13A和圖13B，應當理解的是，如下述，從相同承載條件類型的承載可以藉由統計向量來分組(“群集”)。而圖8~11的討論(下文描述，結合圖12和圖13)關於涉及MCS 26或27和擁塞程度為0的承載條件的範例，應當理解的是，範例實施例可同樣適用於其它的MCS值和其他擁擠程度(其中這些其他MCS值和其他擁塞程度可能又產生看起來與圖8~11有所不同的度量(即承載特性)圖)。

HTTP自適應串流播放(HAS)應用程式：

如圖12所示，HAS應用程式共享具有高E()(預期平均RLC緩衝器大小)和E()(預期平均PRB利用率)的一般特性作為關於大量數據傳輸叢發的應用程式。此外，當每個視頻區段作為叢發被發送，以及RLC緩衝器在完成傳輸數據的每個區段的傳輸之後被清除，用於相同類型承載條件的HAS應用程式關於相對低的E()值。數據傳輸叢發的預期持續時間通常等於區段的預期下載時間。在範例實施例中，其中每個HAS視頻區段的播放持續時間是約2秒、自適應機制選擇接近於可用頻寬的 最大視頻編碼速率、承載通道條件良好、擁塞程度低(數據傳輸叢發通常持續1和2秒之間)。這些特徵反映在圖8A和8B，其描繪在RLC緩衝器是空的並且沒有PRB被分配的短週期之後，在RLC緩衝器大小中的規律突波和在傳輸叢發間隔期間的PRB利用率。

HAS應用程式也關於相對低的E()，當應用程式一般包括小的(或不存在)在連續傳輸叢發之間的閒置時間間隔，而應用程式緩衝區未滿、並且當應用程式緩衝區已滿以及速度選擇是在特定的最佳速度、一致的閒置時間間隔。根據這些特徵，圖13B中分組在子區域C3中的承載可被標記為“HAS應用程式”。

在另一範例實施例中，當考慮到複合承載時，用於下行鏈路HAS應用程式的匹配上行鏈路承載的特性通常可包括具有顯著規律閒置時間的低量上行鏈路流量和對應於TCP確認的規律傳輸叢發，連同不頻繁規律和與對應於下一個視頻區段的請求的下行鏈路閒置時間同步的上行鏈路傳輸叢發。

FTP應用程式：

FTP應用程式(如本文所述)包括大型數據物件，如zip檔案或包含完整應用程式的可執行檔案、系統影像、更新、大型視頻檔案、漸進式下載等的批量傳輸。它們共享具有中間的E()和E()值的一般特性，如圖12所示，當應用程式關於數據源源不斷的連續傳輸，直到數 據已經被傳送。此外，FTP應用程式關於非常高的E()值，當整個傳輸實質上作為單一叢發處理。因此，沒有E()或閒置週期可以被預期，直到整個傳輸已經完成。此外，可以預期的是，被清除的RLC緩衝器將與整個數據傳輸的完成吻合(在下面描述，未明確顯示在圖10A/10B中)。這些特徵反映在圖10A和10B中，其描繪在RLC緩衝器大小中的連續介質程度和PRB分配產出量該傳輸。在此基礎上，圖13B中被分組在子區域C8中的承載可被標記為“FTP應用程式”。

在另一範例實施例中，當考慮到複合承載時，用於FTP應用程式的匹配上行鏈路承載的特性可通常包括低量流量具有顯著規律閒置時間的低量流量和對應於TCP確認的定期傳輸叢發(其可以表現出類似於ICMP PING應用程式的模式，下面將詳細介紹)。

IFTP應用程式：

IFTP應用程式關於檔案的批量傳輸，但不像FTP應用程式，IFTP通常關於許多較小的不相交的檔案的傳送(而不是單一的大檔案)。IFTP應用程式可能包括如網頁瀏覽活動。如圖12所示，這些應用程式共享具有低的E()和E()的一般特性，當應用程式關於在不規律的時間間隔傳輸的每個檔案的單一叢發，隨後明顯很長的閒置時間。另外，當每個檔案的大小是小的(相對於FTP)，IFTP應用程式關於E()的低值。此外，通常伴隨 IFTP的較小不相交檔案的收集導致不均勻的和不可預測的中等E()或閒置週期。儘管可以預期的RLC緩衝器將在每個傳輸(叢發)的完成被清除，其可能不總是保持如此，由於一些這些小的下載的可能重疊同時發生。然而，可以預期，一旦檔案的收集已經轉移，RLC緩衝器將被清除(例如，在網頁的下載的完成)並且在檔案的下一收集之前接著顯著閒置週期。這些特徵反映在圖8A和8B，其描繪RLC緩衝器大小中的低程度叢發和伴隨的PRB分配，具有傳輸之間的不規律閒置週期。根據這些特徵，在圖13B的子區域B1中被分組的承載可能被標記為“IFTP應用程式”。

在另一範例實施例中，當考慮到複合承載時，對於IFTP應用程式的匹配上行鏈路承載的特性可通常包括低量流量具有顯著規律閒置時間和對應於TCP確認的規律傳輸叢發。

應當注意的是，電子郵件和社交網路網站可以被認為是大檔案的FTP應用程式和關於相對較小檔案的IFTP應用程式的組合。

ICMP(PING)應用程式：

ICMP PING關於在規律時間間隔的非常少量數據的傳輸(類似的應用程式包括眾所皆知的網路可達性工具)。如圖12所示，ICMP PING具有零(或接近0)E()和E()值的特性，當傳輸的數據量是足夠小的，數 據能夠在不具有RLC緩衝器中的閒置(對於任何顯著的時間週期)下被發送出去。此外，ICMP PING應用程式關於非常低的E()值，當傳送的數據量和需要傳輸數據的PRB數量是非常小的。此外，傳輸之間的時間(當週期性的)是大的，從而導致高的E()或閒置週期，由於少量的數據傳輸，其中RLC緩衝器通常總是被清除。這些特徵反映在圖9A和9B，其描繪在零的平均RLC緩衝器大小和伴隨傳輸之間的不規律閒置週期的PRB分配。根據這些特徵，在圖13B的子區域A1中被分組的承載可被標記為“ICMP應用程式”。

在另一範例實施例中，當考慮到複合承載時，用於ICMP PING應用程式的匹配上行鏈路承載的特性可通常包括流量的類似模式，在這種情況下，可以關於對應於具有已接收數據的拷貝的來源。

根據上面的範例，在另一個範例實施例中，用於複合承載的更精細和更堅固分類可以被實現，如果完整向量C _k 可以在高維度空間中被考慮。基於以上應用程式的討論，應該理解的是，上述範例可以容易地推廣到其他類型的應用程式。

返回到圖7，在步驟S700中，處理器340可能導致CTM 310用以在記憶體中儲存並且保持先前計算的群集數據，並針對每個類型的承載條件儲存ACTLM資訊。在一個範例實施例中，最初的群集數據和ACTLM可以配置在使用來自各種過去數據記錄收集和無線網路模擬 組裝的數據的CTM 310記憶體。在另一範例實施例中，如下詳述，CTM 310可以藉由處理接收的報告來建立初始儲存群集數據和ACTLM。

在步驟S710中，處理器340可導致CTM 310用以接收來自ACR 280的每個承載報告，其可以包括(對於每個承載)承載識別符、識別的應用程式情境類型、計算的統計向量、承載條件、承載類型(上行鏈路(UL)或下行鏈路(DL))，以及相同應用程式的承載攜帶流量的UL-DL對中的匹配相反方向承載的承載識別符，連同報告的時間戳記，以及eNB 105a的唯一細胞ID。

CTM 310可以轉發該承載識別符、應用程式情境類型、報告的時間戳記和用於eNB 105a的唯一細胞ID到ACD 330，用於進一步分發到IP-CAN 100a和網路10a內的各個實體。如果承載是複合承載，以及承載統計向量包括用於複合承載的UL和DL分量計算的統計、由CTM 310發送到ACD 330的資訊可接著包括UL和DL承載分量。CTM 310接著可以使用以下步驟進行，其可能允許更新和改進先前儲存的ACTLM。

在步驟S720中，處理器340可導致CTM 310用以識別承載條件類型，其可以包括匹配於報告的承載條件的一組承載條件。CTM 310接著可以選擇用於識別的承載條件類型的現有記錄、群集數據和ACTLM，並將此資訊傳遞到CL 320。CTM 310也可以儲存用於識別的承載 條件類型的新報告數據連同先前接收的報告數據。

在步驟S730中，處理器340可導致CL 320用以新增用於識別的承載條件類型的新報告承載統計向量到先前計算的群集數據。

在步驟S740中，處理器340可導致CL 320用以確認加入的新數據是否導致群集調整的需求，其可能關於群集中的至少一個的質心的重新計算座標，或產生新標籤地圖由於至少一個群集區域的改變的邊界。在一個範例實施例，根據群集標籤，如果新的承載被分類，可能需要群集質心的重新計算座標和重新標籤，以及繪圖承載統計向量將承載放置在群集區域之外。在另一範例實施例中，群集質心的重新計算不需要產生新的標籤，如果新的承載向量統計被繪製在群集標籤之內則可能需要，但群集的重心已移動由於新報告的統計向量的加入。

如果在步驟S740中，可確定需要群集的調整，接著在步驟S750中，處理器340可導致CL 320用以調整群集質心和可以使用配置的眾所皆知的群集技術被重新計算的群集邊界，以及新的ACTLM可被產生。此步驟可以總結學習過程。

在步驟S760中，處理器340可導致ACD 330用以發送具有承載識別符的細胞ID和識別的承載應用程式情境類型到網路10a的元件。在一個範例實施例中，ACAF 300可提供應用程式感知回饋給網路10a的元件以控制應用程式的操作。

在一個範例實施例中，處理器340可以藉由使ACAF 300提供回饋至eNB排程器215以調整應用程式情境類型的排程器演算法來控制應用程式的操作。在接收承載的應用程式情境類型的回饋之後，排程器215可以實現承載情境類型感知資源分配。此分配可以提供不同的排程策略(具有不同的資源分配量)被應用到取決於承載攜帶的應用程式情境的最大努力(BE)承載。這種基於情境的差異可以使行動應用程式的流暢運行在典型的最佳功效QCI優先權，以更高的速率、更大的穩定，而沒有凍結或對於行動視頻品質的其他負面影響。這些調整也提供了網頁瀏覽和社交網路應用程式的較佳反應時間，同時保持更多延遲容忍的應用程式，如FTP的令人滿意效能。此外，此排程策略差異可能在存在資源短缺時的擁塞情況下特別有利。

在一個範例中，在擁塞情況下，排程器215可以藉由實現最佳功效(BE)承載之間的政策差異來控制應用程式的操作，藉由將PRB資源分配優先化到攜帶可能更敏感於延遲和抖動的應用程式類型的承載，例如行動視頻流量。在這個範例中，排程器215可以從最高到最低的優先權的順序分配優先權，如下：第一優先順序可以是攜帶即時會話視頻和直播視頻(其中視頻數據的很少或沒有緩衝可以在視頻用戶端執行，並且延遲可能導致視頻凍結和由終端用戶的潛在會話關閉)的承載以及低容量承載，如攜帶ICMP PING或TCP確認；第二優先順序可以 是攜帶HTTP自適應串流視頻或漸進式視頻的承載(其中在用戶端進行緩衝，但是過多的延遲可能會導致用戶端視頻緩衝器耗盡導致視頻凍結)；第三優先權順序可以是攜帶間歇FTP的承載，諸如網路瀏覽或社交網路(其中某些延遲可被終端用戶容忍，但在網頁載入或社交網路更新的過度延遲可能導致終端用戶放棄應用程式服務)；第四優先順序可以是攜帶FTP(其中終端用戶可能通常更寬容的對於一些較長下載時間)的承載。加權公平排程器215可以藉由分配較高的權重到攜帶行動視頻應用程式流量的承載來行使這種優先權。為了避免上述低優先權的應用程式的飢餓，排程器對於較低優先權的應用程式可以實現某些最小頻寬保證，使這些應用程式避免顯著的性能下降。

在另一範例中，情境感知排程器215可以針對從已知的應用程式情境類型得到的承載使用滿足某些最小頻寬、延遲和抖動要求的資源分配模式。

在另一範例中，排程器215可以藉由處理攜帶FTP或間歇的FTP應用程式作為最佳功效的保證位元率(GBR)承載來控制應用程式的操作，同時繼續優先化攜帶行動視頻應用程式類型的GBR承載。這樣的差別處理允許網路繼續為高階用戶提供GBR服務(其根據它們的服務程度協定，基於它們的IMSI身份來獲得GBR服務)，同時GBR用戶觀看行動視頻，當GBR用戶不使用GBR服務時，同時允許其他用戶利用網路資源。

在另一範例實施例中，ACAF 300對於額外的 應用程式情境驅動流量控制提供回饋到PGW 103或PCRF 106(其中，PGW 103和PCRF 106可被稱為“管理實體”節點)。在此範例中，在接收特定BE承載可攜帶對於延遲或最小產出量敏感的應用程式情境類型(例如行動視頻)的通知時，PCRF 106可以執行這樣的BE承載的優先權的提高到更高的非GBR QCI優先權(或甚至到GBR QCI優先權)。此優先權的提高可以經由藉由具有與選擇的QCI相關的封包延遲餘裕控制的延遲設置的標準3GPP定義的承載修改程序來執行，並且可以藉由用於GBR配置的最小位元速率控制的產出量。

應當理解的是，儘管範例實施例將ACIF 240功能元件放在eNB105a內，在虛擬的RAN或軟體定義的網路架構中，其中eNB 105a的功能元件可以分佈和動態地初始化在通用計算節點的雲端內，該ACIF 240和ACAF 300功能元件可以同樣被分佈和動態地初始化在通用計算節點的雲端內。

應當理解，儘管範例實施例關於LTE網路，這些實施例也可以應用程式於用於發送數據流量的無線資源可以藉由對應的用於資源分配的無線存取技術排程器被分配為細胞負載等功能和每赫茲每秒位元計算(類似於LTE MCS)的其它無線存取網路。這些技術的範例包括但不限於3GPP WCDMA、UMTS、3GPP2 EVDO、WiMAX、Wi-Fi。

範例實施例已從而描述，但是顯而易見的 是，可以用許多方式變化。這樣的變化不應被認為是脫離範例實施例的預期精神和範圍，並且所有對於本領域技術人員將是顯而易見的這樣的修改意於被包括在以下的申請專利範圍的範圍之內。

10‧‧‧網路

100‧‧‧網際網路協定(IP)連接存取網路(IP-CAN)

101‧‧‧伺服閘道器(SGW)

103‧‧‧封包資料網路(PDN)閘道器(PGW)

105‧‧‧E-UTRAN節點B(eNB)

106‧‧‧策略和計費規則功能(PCRF)

108‧‧‧行動管理實體(MME)

110‧‧‧用戶設備(UE)

1001‧‧‧IP封包資料網路(IP-PDN)

Claims (10)

1. 一種藉由分類應用程式類型來控制應用程式之操作的方法，其包含：藉由至少一個網路節點(S600)的一或多個處理器來獲得用於一或多個承載的承載度量；藉由該一或多個處理器來計算用於該承載度量(S620)的統計向量；藉由該一或多個處理器，藉由將點定位於對應於該統計向量的標籤地圖上來將該應用程式類型分類以獲得應用程式類型資訊(S640)；以及藉由該一或多個處理器，輸出該應用程式類型資訊到網路節點的節點處理器以控制應用程式的操作(S650)。
2. 如申請專利範圍第1項的方法，其中該獲得包括獲得係為無線電鏈路控制(RLC)緩衝器大小、實體資源區塊(PRB)利用率、傳輸叢發間隔和閒置時間間隔中的至少一個的每個承載度量。
3. 如申請專利範圍第1項的方法，其中該計算進一步包括，識別與該獲得的承載度量相關的承載對(S620)，其中每一對承載屬於相同的應用程式，並且包括攜帶上行鏈路傳輸的第一承載和攜帶下行鏈路傳輸的第二承載，針對每個該識別的承載對來計算用於承載度量的該統計向量。
4. 如申請專利範圍第1項的方法，其進一步包含： 藉由下述者來獲得該標籤地圖，在先前分類的承載上獲得承載報告(S710)，針對至少一個特定的應用程式類型來計算群集質心和定義的群集區域(S750)，該標籤地圖包括針對該至少一個特定的應用程式類型的該計算的群集質心和該定義的群集區域。
5. 如申請專利範圍第4項的方法，其中該分類進一步包括，位於或鄰近於對應於該統計向量的該標籤地圖的該定義的群集區域的定位點，其中與各定位點最接近的該至少一個特定的應用程式類型相關的該定義的群集區域被確定為該分類的應用程式類型(S640)。
6. 一種網路節點，其包含：一或多個處理器(210a/340)，其配置以，獲得一或多個承載的承載度量(S600)，針對該承載度量計算統計向量(S620)，藉由在對應於該統計向量的標籤地圖上的定位點來將該應用程式類型分類以獲得應用程式類型資訊(S640)，以及將該應用程式類型資訊輸出到處理器網路節點以控制應用程式的操作(S650)。
7. 如申請專利範圍第6項的網路節點，其中該一或多個處理器係進一步配置以藉由獲得係為無線電鏈路控制(RLC)緩衝器大小、實體資源區塊(PRB)利用率、傳 輸叢發間隔和閒置時間間隔中的至少一個的每個承載度量來獲得該承載度量。
8. 如申請專利範圍第6項的網路節點，其中該一或多個處理器係進一步配置以藉由下述者來計算統計向量，識別與該獲得的承載度量相關的承載對(S620)，其中每一對承載屬於相同的應用程式，並且包括攜帶上行鏈路傳輸的第一承載和攜帶下行鏈路傳輸的第二承載，針對每個該識別的承載對來計算用於承載度量的該統計向量。
9. 如申請專利範圍第6項的網路節點，其中該一或多個處理器係進一步配置以，藉由下述者來獲得該標籤地圖，在先前分類的承載上獲得承載報告(S710)，針對至少一個特定的應用程式類型來計算群集質心和定義的群集區域(S750)，該標籤地圖包括針對該至少一個特定的應用程式類型的該計算的群集質心和該定義的群集區域。
10. 如申請專利範圍第9項的網路節點，其中該一或多個處理器係進一步配置以藉由下述者來將該應用程式類型分類，位於或鄰近於對應於該統計向量的該標籤地圖的該定義的群集區域的定位點，其中與各定位點最接近的該至少一個特定的應用程式類型相關的該定義的群集區域被確定為該分類的應用程式類型(S640)。