[發明專利]數據傳輸方法、裝置、計算機設備和存儲介質

有效

• 申請號: 201911293553.X
• 申請日: 2019-12-16
• 公開（公告）號: CN111107176B
• 公開（公告）日: 2021-08-24
• 發明（設計）人: 徐慧俊;卜斌龍;王琪;李學鋒
• 申請（專利權）人: 京信網絡系統股份有限公司
• 主分類號: H04L29/12
• 分類號: H04L29/12
• 代理公司: 廣州華進聯合專利商標代理有限公司 44224
• 代理人: 樊倩

本申請涉及一種數據傳輸方法、裝置、計算機設備和存儲介質，由于預先在基站的SDAP模塊中建立了地址映射表，映射單元根據接收的數據，將MAC地址與IP地址的映射關系存儲至地址映射表中，在接收到數據為ARP/RARP請求數據時，只需在地址映射表中查詢是否存在待查詢地址的對應映射關系，并在存在對應映射關系時，根據查詢結果直接進行響應，相當于，映射單元執行數據監控、自學習，構建內部MAC地址與IP地址的映射表，在終端發起相應查詢請求時，率先查找自身映射表，存在時直接給予終端響應服務，這樣，極大降低了業務響應的時延，提升了客戶體驗。

技術領域

本申請涉及通信技術領域，特別是涉及一種數據傳輸方法、裝置、計算機設備和存儲介質。

背景技術

在4G通信系統中，終端無法進行傳統以太網業務，例如，地址解析協議(A ddressResolution Protocol，ARP)、反向地址轉換協議(Reverse Address R esolutionProtocol，RARP)業務等，這些業務在5G系統中均得到了支持。

現有5G基站對以太網會話的業務數據，不進行深度分析，更不進行大數據的自學習，尤其ARP/RARP業務，也就是說，5G基站并無直接具備對以太網會話業務的響應能力，其僅僅處于轉發相應業務報文的工作位置，雖然有些廠商對A RP業務的支持，但也是建立在代理和系統配合的角度，而非直接地、獨立地支持。

因此，現有5G基站對以太網會話中ARP/RARP的服務響應存在時延問題。

發明內容

基于此，有必要針對上述技術問題，提供一種數據傳輸方法、裝置、計算機設備和存儲介質。

第一方面，本申請實施例提供一種數據傳輸方法，該方法包括：

接收PDCP模塊發送的上行數據；

若上行數據為ARP/RARP請求數據，獲取ARP/RARP請求數據中的待查詢第一地址，待查詢第一地址包括待查詢IP地址或待查詢MAC地址；

從預設的地址映射表中，查詢待查詢第一地址對應的第二地址；地址映射表中包括多個MAC地址與IP地址的映射關系；

若地址映射表中存在第二地址，則將第二地址發送至PDCP模塊。

在其中一個實施例中，若待查詢第一地址為IP地址，則第二地址為MAC地址；若待查詢第一地址為MAC地址，則第二地址為IP地址。

在其中一個實施例中，從預設的地址映射表中，查詢待查詢第一地址對應的第二地址之前，該方法還包括：

若地址映射表中不存在第二地址，將上行數據發送至GTP模塊。

在其中一個實施例中，在獲取ARP/RARP請求數據中的待查詢第一地址之前，該方法包括：

判斷上行數據是否為以太網會話；

若上行數據為以太網會話，判斷上行數據是否為ARP/RARP請求數據；

若上行數據是ARP/RARP請求數據，則執行獲取ARP/RARP請求數據中的待查詢第一地址的步驟；

若不是ARP/RARP請求數據，則將上行數據發送至GTP模塊。

在其中一個實施例中，判斷上行數據是否為以太網會話，包括：若上行數據的承載類型為以太網會話對應的承載類型，則確定上行數據為以太網會話。

在其中一個實施例中，判斷上行數據是否為ARP/RARP請求數據，包括：若上行數據中攜帶的數據類型標識為ARP/RARP請求數據對應的標識，則確定上行數據為ARP/RARP請求數據。

在其中一個實施例中，該方法還包括：