TWI813262B

TWI813262B - 通訊裝置以及用來接收聚合封包的方法

Info

Publication number: TWI813262B
Application number: TW111114991A
Authority: TW
Inventors: 葉倫武; 謝金龍
Original assignee: 瑞昱半導體股份有限公司
Priority date: 2022-04-20
Filing date: 2022-04-20
Publication date: 2023-08-21
Also published as: TW202343996A; US20230345303A1

Abstract

本發明提供一種通訊裝置以及用來接收一聚合封包的方法，其中該通訊裝置包含一聚合封包解聚合裝置以及一傳輸介面。該聚合封包解聚合裝置是用來依據該聚合封包產生多個子訊框封包，其中該多個子訊框封包的每一者的長度小於該聚合封包的長度。該傳輸介面是用來將該通訊裝置耦接至一主裝置，尤其該傳輸介面將該多個子訊框封包傳送至該主裝置，以容許該主裝置依據該多個子訊框封包的任一者的最大可容許長度來預分配多個緩衝空間以供接收該多個子訊框封包。

Description

通訊裝置以及用來接收聚合封包的方法

本發明是關於封包傳輸，尤指一種通訊裝置以及用來接收一聚合封包的方法。

由於Wi-Fi是基於競爭視窗進行傳輸，因此相較於利用多次的運作來完成多個封包的傳輸，該多個封包較佳為被合併成一個聚合封包以容許該多個封包的傳輸能在一次運作裡完成。當一電子裝置接收到該聚合封包時，典型地會透過驅動程式以軟體的方式拆解該聚合封包以取得該多個封包。然而，由於該驅動程式無法預期每次接收到的封包的大小，因此典型地會基於通訊標準所規範的長度限制來分配處理封包時所需使用的暫存空間，使得記憶體資源容易被佔據而造成浪費。

因此，需要一種新穎的架構以及方法，以在沒有或較低副作用的情況下改善記憶體資源的使用效率。

本發明之目的在於提供一種通訊裝置以及用來接收一聚合封包的方法，以使得一主裝置(host device)的驅動程式能基於較小的封包長度預分配(pre-allocate)所需的緩衝空間。

本發明至少一實施例提供一種通訊裝置，其中該通訊裝置可包含一聚合封包解聚合裝置以及一傳輸介面。該聚合封包解聚合裝置可用來依據一聚合封包產生多個子訊框封包，其中該多個子訊框封包的每一者的長度小於該聚合封包的長度。該傳輸介面可用來將該通訊裝置耦接至一主裝置，尤其該傳輸介面可將該多個子訊框封包傳送至該主裝置，以容許該主裝置依據該多個子訊框封包的任一者的最大可容許(allowable)長度來預分配多個緩衝空間以供接收該多個子訊框封包。

本發明至少一實施例提供一種用來接收一聚合封包的方法，其中該方法可包含：利用一通訊裝置的一聚合封包解聚合裝置依據該聚合封包產生多個子訊框封包，其中該多個子訊框封包的每一者的長度小於該聚合封包的長度；以及利用該通訊裝置的一傳輸介面將該多個子訊框封包自該通訊裝置傳送至一主裝置，以容許該主裝置依據該多個子訊框封包的任一者的最大可容許長度來預分配多個緩衝空間以供接收該多個子訊框封包。

本發明的實施例提供的通訊裝置以及方法能用硬體的方式先對接收到的聚合封包進行解聚合，以使主裝置在進行緩衝空間的預分配時僅需滿足子訊框封包的長度的要求。因此，不論通訊裝置接收到的是長度較短的單位封包諸如媒體存取控制(medium access control,MAC)服務資料單元(MAC service data unit,MSDU)或是長度較長的聚合封包諸如聚合媒體存取控制服務資料單元(aggregate MSDU,AMSDU)，都能確保基於單位封包的長度來預分配緩衝空間即可滿足需求，而不需要總是基於聚合封包的長度來預分配緩衝空間。因此，記憶體資源的使用效率能被妥善地提升。

50:主裝置

51:主機處理器

52:主機緩衝器

52L:主機緩衝清單

53:主機控制器介面

100:通訊裝置

110:接收引擎

110A:聚合媒體存取控制服務資料單元(AMSDU)解聚合引擎

120:接收封包緩衝器

130:主機控制器介面

111:聚合媒體存取控制服務資料單元(AMSDU)有效性檢查電路

112:解聚合電路

113:標頭轉換電路

114:負載對齊電路

P_AG:聚合媒體存取控制服務資料單元封包

{P_deAG}:解聚合封包

{P_newHEADER}:轉換後封包

S310~S390:步驟

400:聚合媒體存取控制服務資料單元封包

RX_Desc:描述符

MAC_header:媒體存取控制標頭

AMSDU_subframe_header_1:子訊框標頭

AMSDU_subframe_header_2:子訊框標頭

AMSDU_subframe_header_3:子訊框標頭

Payload_1,Payload_2,Payload_3:資料負載

510~530:媒體存取控制服務資料單元封包

RX_Desc_1,RX_Desc_2,RX_Desc_3:描述符

Translated_header_1,Translated_header_2,Translated_header_3:轉譯後標頭

Padding_align_2,Padding_align_3:填充位元組

RX_Buffer_1~RX_Buffer_N:緩衝條目

S810~S820:步驟

第1圖為依據本發明一實施例之一通訊裝置耦接至一主裝置的示意圖。

第2圖為依據本發明一實施例之一聚合封包解聚合裝置的示意圖。

第3圖為依據本發明一實施例之第2圖所示之聚合封包解聚合裝置處理一接收封包的工作流程的示意圖。

第4圖為依據本發明一實施例之一聚合封包的示意圖。

第5圖為依據本發明一實施例之對多個子訊框封包進行負載對齊的示意圖。

第6圖為依據本發明一實施例之一主裝置在一聚合封包解聚合裝置被禁能的情況下預分配緩衝空間的示意圖。

第7圖為依據本發明一實施例之一主裝置在一聚合封包解聚合裝置的解聚合功能被致能的情況下預分配緩衝空間的示意圖。

第8圖為依據本發明一實施例之一種用來接收一聚合封包的方法的工作流程。

Wi-Fi的封包是可基於IEEE 802.11所規範的聚合媒體存取控制(medium access control，簡稱MAC)服務資料單元(MAC service data unit，簡稱MSDU)為單元進行傳輸，其中當一發送器欲發送多個MSDU封包時，該發送器可將該多個MSDU封包聚合為一個聚合MSDU(aggregate MSDU，簡稱AMSDU)封包，使得在基於競爭視窗的通訊協定下能以較佳的效率被發送。

第1圖為依據本發明一實施例之一通訊裝置100耦接至一主裝置50的示意圖，其中通訊裝置100可實施在一有線/無線網卡中以提供網路通訊服務給主裝置50。如第1圖所示，通訊裝置100可包含一接收引擎110、一接收封包緩衝器120以及一傳輸介面諸如主機控制器介面(Host controller interface)130，其中接收引擎110可包含一聚合封包解聚合裝置諸如AMSDU解聚合引擎110A。具體來說，接收引擎110可包含多層的電路諸如射頻電路層、基頻電路層以及MAC層，其中AMSDU解聚合引擎110A可實施在MAC層，但本發明不限於此。在某些實施例中，AMSDU解聚合引擎110A可設置於接收引擎110的外部，例如 AMSDU解聚合引擎110A可耦接於接收引擎110與接收封包緩衝器120之間。另外，主裝置50可包含一主機處理器51、一主機緩衝器52以及一傳輸介面諸如主機控制器介面53。主裝置50的主機控制器介面53以及通訊裝置100的主機控制器介面130可為符合快捷外設組件互連(Peripheral Component Interconnect Express,PCIe)標準或通用序列匯流排(Universal Serial Bus)標準的傳輸介面，但本發明不限於此。

在本實施例中，當通訊裝置100接收到一AMSDU封包時，AMSDU解聚合引擎110A可依據該AMSDU封包產生多個子訊框封包諸如多個MSDU封包，其中該多個MSDU封包的每一者的長度小於該AMSDU封包的長度。接收封包緩衝器120可暫存/緩衝AMSDU解聚合引擎110A所輸出的該多個MSDU封包並且傳送給主機控制器介面130。主機控制器介面130可用來將通訊裝置100耦接至主裝置50(例如耦接至主裝置50的主機控制器介面53)，其中主機控制器介面130可將該多個MSDU封包傳送至主裝置50，以容許主裝置50依據該多個子訊框封包的任一者的最大可容許(allowable)長度(例如IEEE 802.11所規範之MSDU封包的最大可容許長度)來預分配(pre-allocate)多個緩衝空間諸如主機緩衝清單52L以供接收該多個MSDU封包。例如，主裝置50可在基於上述IEEE 802.11所規範之MSDU封包的最大可容許長度來預分配該多個緩衝空間的情況下接收來自通訊裝置100的封包(例如該多個MSDU封包)，以供後續處理及使用。

第2圖為依據本發明一實施例之AMSDU解聚合引擎110A的示意圖。如第2圖所示，AMSDU解聚合引擎110A可包含一AMSDU有效性檢查電路111、一解聚合電路112、一標頭轉換電路113以及一負載對齊電路114。為便於說明，假設三個MSDU封包在一發送器被聚合為AMSDU封包P_AG。在本實施例中，AMSDU封包P_AG可包含多個欄位諸如{RX_Desc,MAC_header,AMSDU_subframe_1,Padding_1,AMSDU_subframe_2,Padding_2, AMSDU_subframe_3,Padding_3,FCS}，其中RX_Desc為這個AMSDU封包的描述符，MAC_header為傳送這個AMSDU封包所使用的通訊協定之對應的標頭(尤其可指出這個AMSDU封包的來源位址以及目的地位址)，AMSDU_subframe_1、AMSDU_subframe_2及AMSDU_subframe_3為分別與該三個MSDU封包對應的子訊框，Padding_1、Padding_2及Padding_3為填充位元組(byte)，以及FCS為校驗碼。當AMSDU解聚合引擎110A接收到一封包(例如AMSDU封包P_AG)時，AMSDU有效性檢查電路111可檢查在這個封包中的長度欄位載有的封包長度資訊(例如描述符RX_Desc及/或子訊框AMSDU_subframe_1、AMSDU_subframe_2及AMSDU_subframe_3的長度欄位載有的封包長度資訊)所指出的至少一長度(例如一或多個長度)的總和是否等於這個封包的總長度，其中AMSDU封包P_AG中的長度欄位載有的封包長度資訊所指出的該至少一長度的總和不等於AMSDU封包P_AG的總長度，AMSDU有效性檢查電路111可判斷AMSDU封包P_AG是無效的AMSDU封包。另外，AMSDU有效性檢查電路111可檢查AMSDU封包P_AG的總長度是否小於IEEE 802.11所規範之一個AMSDU封包的最大可容許長度，其中若AMSDU封包P_AG的總長度大於IEEE 802.11所規範之一個AMSDU封包的最大可容許長度，AMSDU有效性檢查電路111可判斷AMSDU封包P_AG是無效的AMSDU封包。若AMSDU有效性檢查電路111判斷AMSDU封包P_AG是有效的AMSDU封包，有效性檢查電路111可將AMSDU封包P_AG傳送給解聚合電路。

解聚合電路112可對AMSDU封包P_AG進行解聚合以產生多個解聚合封包{P_deAG}(例如產生一第一解聚合封包、一第二解聚合封包以及一第三解聚合封包)，其中通訊裝置100輸出給主裝置50的多個MSDU封包(例如上述AMSDU解聚合引擎110A產生的多個MSDU封包)是分別依據多個解聚合封包{P_deAG}(例如該第一解聚合封包、該第二解聚合封包以及該第三解聚合封包) 被產生。另外，多個解聚合封包{P_deAG}中的每一解聚合封包可具有一描述符以用來載有所述每一解聚合封包的資訊(例如所述每一解聚合封包的封包索引值、封包長度、封包類型及/或指出此封包是否被解聚合過的資訊)，因此所述每一解聚合封包的資訊(例如上述封包索引值及封包長度)可指出所述每一解聚合封包是否為多個解聚合封包{P_deAG}中的最後一個解聚合封包以及所述每一解聚合封包的長度。在某些實施例中，AMSDU封包P_AG的標頭MAC_header可在多個解聚合封包{P_deAG}中的一或多者被保留或捨棄。在某些實施例中，AMSDU封包P_AG的填充位元組Padding_1、Padding_2及Padding_3中之一或多者可分別在多個解聚合封包{P_deAG}中的一或多者被保留或捨棄。在某些實施例中，AMSDU封包P_AG的校驗碼FCS可在多個解聚合封包{P_deAG}中的任一者被保留或捨棄。

例如，解聚合電路112可在該第一解聚合封包保留標頭MAC_header以及填充位元組Padding_1、在該第二解聚合封包保留填充位元組Padding_2、並且在該第三解聚合封包保留校驗碼FCS，因此該第一解聚合封包可表示為{RX_Desc_1,MAC_header,AMSDU_subframe_1,Padding_1}，該第二解聚合封包可表示為{RX_Desc_2,AMSDU_subframe_2,Padding_2}，以及該第三解聚合封包可表示為{RX_Desc_3,AMSDU_subframe_3,FCS}，其中描述符RX_Desc_1可載有該第一解聚合封包的資訊(例如封包索引值及/或封包長度)，描述符RX_Desc_2可載有該第二解聚合封包的資訊(例如封包索引值及/或封包長度)，以及描述符RX_Desc_3可用來載有該第三解聚合封包的資訊(例如封包索引值及/或封包長度)。又例如，解聚合電路112可在該第一解聚合封包、該第二解聚合封包以及該第三解聚合封包中均保留標頭MAC_header，並且捨棄填充位元組Padding_1、Padding_2及Padding_3以及校驗碼FCS，因此該第一解聚合封包可表示為{RX_Desc_1,MAC_header,Payload_1}，該第二解聚合封包可表示為{RX_Desc_2,MAC_header,Payload_2}，以及該第三解聚合封包可表示為 {RX_Desc_3,MAC_header,Payload_3}，其中Payload_1為子訊框AMSDU_subframe_1中的資料負載，Payload_2為子訊框AMSDU_subframe_2中的資料負載，以及Payload_3為子訊框AMSDU_subframe_3中的資料負載。又例如，解聚合電路112可捨棄標頭MAC_header、填充位元組Padding_1、Padding_2及Padding_3、以及校驗碼FCS，因此該第一解聚合封包可表示為{RX_Desc_1,Payload_1}，該第二解聚合封包可表示為{RX_Desc_2,Payload_2}，以及該第三解聚合封包可表示為{RX_Desc_3,Payload_3}。

標頭轉換電路113可對多個解聚合封包{P_deAG}分別進行標頭轉換以產生多個轉換後封包{P_newHEADER}(例如一第一轉換後封包、一第二轉換後封包以及一第三轉換後封包)，其中多個轉換後封包{P_newHEADER}的每一轉換後封包可具有一特定標頭，以容許主裝置50依據與該特定標頭對應的通訊標準進行後續傳輸。舉例來說，一存取點(access point)裝置可包含主裝置50，以及該存取點裝置可依據與該特定標頭對應的通訊標準將通訊裝置100輸出給主裝置50的多個MSDU封包(例如上述AMSDU解聚合引擎110A產生的多個MSDU封包)進一步傳送至其他電子裝置，其中該多個MSDU封包是分別依據多個轉換後封包{P_newHEADER}(例如該第一轉換後封包、該第二轉換後封包以及該第三轉換後封包)被產生。

例如，標頭轉換電路113可將標頭MAC_header轉換或轉譯為符合IEEE 802.3乙太網路-II標準的標頭802.3_eth_II，因此該第一解聚合封包可表示為{RX_Desc_1,802.3_eth_II,Payload_1}，該第二解聚合封包可表示為{RX_Desc_2,802.3_eth_II,Payload_2}，以及該第三解聚合封包可表示為{RX_Desc_3,802.3_eth_II,Payload_3}。又例如，標頭轉換電路113可將標頭MAC_header轉換或轉譯為符合IEEE 802.3子網路存取協定(Sub-network Access Protocol,SNAP)標準的標頭802.3_SNAP，因此該第一解聚合封包可表示為{RX_Desc_1, 802.3_SNAP,Payload_1}，該第二解聚合封包可表示為{RX_Desc_2,802.3_SNAP,Payload_2}，以及該第三解聚合封包可表示為{RX_Desc_3,802.3_SNAP,Payload_3}。又例如，標頭轉換電路113可將標頭MAC_header轉換或轉譯為符合一自定義標準的標頭Self_defined，因此該第一解聚合封包可表示為{RX_Desc_1,Self_defined,Payload_1}，該第二解聚合封包可表示為{RX_Desc_2,Self_defined,Payload_2}，以及該第三解聚合封包可表示為{RX_Desc_3,Self_defined,Payload_3}。

若標頭轉換電路113被禁能，負載對齊電路114可自解聚合電路112取得多個解聚合封包{P_deAG}，並且將填充位元組分別附加至多個解聚合封包{P_deAG}以產生多個對齊後封包，其中該多個對齊後封包之各自的資料負載(例如上述資料負載Payload_1、Payload_2及Payload_3)是基於一特定數量的位元組互相對齊，例如以4位元組為基準互相對齊、以8位元組為基準互相對齊、或者以快取列大小(cache line size)諸如32位元組、64位元組、128位元組...等等為基準互相對齊，以改善主裝置50處理通訊裝置100輸出給主裝置50的多個MSDU封包的效率，其中該多個MSDU封包是分別依據該多個對齊後封包被產生。若標頭轉換電路113被致能，負載對齊電路114可自標頭轉換電路113取得多個轉換後封包{P_newHEADER}，並且將填充位元組分別附加至多個轉換後封包{P_newHEADER}以產生該多個對齊後封包。需注意的是，第2圖同時展示了在標頭轉換電路113被禁能與被致能的情況下的訊號路徑，然而這只是為了方便說明。實作上，其可為選擇性的操作，當標頭轉換電路113被禁能時，負載對齊電路114停止自標頭轉換電路113取得多個轉換後封包{P_newHEADER}；以及當標頭轉換電路113被致能時，負載對齊電路114停止自解聚合電路112取得多個解聚合封包{P_deAG}；但本發明不限於此。

第3圖為依據本發明一實施例之第2圖所示之AMSDU解聚合引擎 110A處理一接收封包的工作流程的示意圖。需注意的是，第3圖所示之工作流程只是為了說明之目的，並非對本發明的限制。尤其，一或多個步驟可在第3圖所示之工作流程中被新增、刪除或修改。另外，只要不影響整體結果，這些步驟並非必須完全依照第3圖所示之順序執行。

在步驟S310中，當AMSDU解聚合引擎110A接收到一接收封包時，流程開始。

在步驟S320中，AMSDU解聚合引擎110A可判斷該接收封包是否為有效的AMSDU封包(在第3圖中標示為「有效AMSDU封包？」以求簡明)。若判斷結果為「是」，流程進入步驟S330；若判斷結果為「否」，流程進入步驟S390。

在步驟S330中，AMSDU解聚合引擎110A可判斷對AMSDU封包進行解聚合的功能是否被致能(在第3圖中標示為「致能解聚合AMSDU？」以求簡明)。若判斷結果為「是」，流程進入步驟S340；若判斷結果為「否」，流程進入步驟S390。

在步驟S340中，AMSDU解聚合引擎110A可利用解聚合電路112對該AMSDU封包進行解聚合以產生多個解聚合封包，並且更新接收描述符至該多個解聚合封包(在第3圖中標示為「對AMSDU進行解聚合並且更新接收描述符」以求簡明)。

在步驟S350中，AMSDU解聚合引擎110A可判斷對該多個解聚合封包進行標頭轉換的功能是否被致能(在第3圖中標示為「致能標頭轉換？」以求簡明)。若判斷結果為「是」，流程進入步驟S360；若判斷結果為「否」，流程進入步驟S370。

在步驟S360中，AMSDU解聚合引擎110A可利用標頭轉換電路113對該多個解聚合封包執行標頭轉換以產生多個轉換後封包(在第3圖中標示為「執行標頭轉換」以求簡明)。

在步驟S370中，AMSDU解聚合引擎110A可判斷對該多個解聚合封包或該多個轉換後封包進行負載對齊填充的功能是否被致能(在第3圖中標示為「致能負載對齊填充？」以求簡明)。若判斷結果為「是」，流程進入步驟S380；若判斷結果為「否」，流程進入步驟S390。

在步驟S380中，AMSDU解聚合引擎110A可附加填充位元組至該多個解聚合封包或該多個轉換後封包以供資料負載互相對齊(在第3圖標示為「附加填充位元組以供負載對齊」以求簡明)。

在步驟S390中，AMSDU解聚合引擎110A的工作流程結束，最終的多個MSDU封包可被輸出至接收封包緩衝器120。

第4圖為依據本發明一實施例之一AMSDU封包400的示意圖。如第4圖所示，AMSDU封包400可包含多個欄位諸如描述符RX_Desc、MAC標頭MAC_header、子訊框標頭AMSDU_subframe_header_1、資料負載Payload_1、子訊框標頭AMSDU_subframe_header_2、資料負載Payload_2、子訊框標頭AMSDU_subframe_header_3以及資料負載Payload_3。在AMSDU解聚合引擎110A(例如其內的解聚合電路112、標頭轉換電路113及負載對齊電路114)對AMSDU封包400執行上述處理後，AMSDU解聚合引擎110A可產生第5圖所示之多個子訊框封包諸如MSDU封包510、520及530。

在第5圖的實施例中，MSDU封包510可包含多個欄位諸如描述符RX_Desc_1、MAC標頭MAC_header、轉譯後標頭Translated_header_1以及資料負載Payload_1，MSDU封包520可包含多個欄位諸如描述符RX_Desc_2、填充位元組Padding_align_2、轉譯後標頭Translated_header_2以及資料負載Payload_2，以及MSDU封包530可包含多個欄位諸如描述符RX_Desc_3、填充位元組Padding_align_3、轉譯後標頭Translated_header_3以及資料負載Payload_3。如第5圖所示，透過將填充位元組Padding_align_2以及Padding_align_3分別附加至 MSDU封包520及530中，資料負載Payload_1、Payload_2及Payload_3的起始位元組能以一特定數量的位元組的整數倍為基準互相對齊，例如以4位元組、8位元組、...、或快取列大小(例如32位元組、64位元組、128位元組等大小)為基準互相對齊，使得主裝置50在收到MSDU封包510、520及530時能以較佳的效率進行後續處理。

第6圖為依據本發明一實施例之主裝置50在AMSDU解聚合引擎110A被禁能的情況下預分配緩衝空間諸如第1圖所示之主機緩衝清單52L的示意圖。當AMSDU解聚合引擎110A被禁能時，接收引擎110接收到任何封包時可將此封包旁通AMSDU解聚合引擎110A，使得主裝置50取得未經任何預處理的封包。在此狀況下，由於主裝置50無法預期這個封包是MSDU封包或是AMSDU封包，因此為了確保預分配的緩衝空間能滿足這個封包的需求，主裝置50可依據IEEE 802.11標準所規範的一個AMSDU封包的最大可容許長度決定主機緩衝清單52L的緩衝條目RX_Buffer_1、RX_Buffer_2、RX_Buffer_3、RX_Buffer_4、...及RX_Buffer_N中的每一緩衝條目的大小，其中N為正整數。

第7圖為依據本發明一實施例之主裝置50在AMSDU解聚合引擎110A被致能的情況下預分配緩衝空間諸如主機緩衝清單52L的示意圖。若接收引擎110接收到MSDU封包，接收引擎110可將這個MSDU封包旁通AMSDU解聚合引擎110A；而若接收引擎110接收到AMSDU封包，AMSDU解聚合引擎110A可對這個AMSDU封包進行解聚合以產生多個MSDU封包。因此，不論接收引擎110接收到哪一種類型的封包，都能確保以IEEE 802.11標準所規範的一個MSDU封包的最大可容許長度作為主機緩衝清單52L的緩衝條目RX_Buffer_1、RX_Buffer_2、RX_Buffer_3、RX_Buffer_4、...及RX_Buffer_N中的每一緩衝條目的大小即可滿足需求。

例如，IEEE 802.11標準所規範的一個MSDU封包的最大可容許長度可為2304位元組，而IEEE 802.11標準所規範的一個AMSDU封包的最大可容許長度可為7935位元組。當主裝置50欲在主機緩衝器52中佇列256個封包時，在AMSDU解聚合引擎110A被禁能的情況下會需要2031360位元組(即256×7935)的記憶體空間。相對的，在AMSDU解聚合引擎110A被致能的情況下則僅需要589824位元組(即256×2304)的記憶體空間，大幅地減少了所需的記憶體資源。

第8圖為依據本發明一實施例之一種用來接收一聚合封包諸如AMSDU封包的方法的工作流程，其中該方法是可應用於第1圖所示之通訊裝置100。需注意的是，第8圖所示之工作流程只是為了說明之目的，並非對本發明的限制。尤其，一或多個步驟可在第8圖所示之工作流程中被新增、刪除或修改。另外，只要不影響整體結果，這些步驟並非必須完全依照第8圖所示之順序執行。

在步驟S810中，通訊裝置100可利用其內的聚合封包解聚合裝置諸如第1圖所示之AMSDU解聚合引擎110A依據該聚合封包產生多個子訊框封包諸如MSDU封包，其中該多個子訊框封包的每一者的長度小於該聚合封包的長度。

在步驟S820中，通訊裝置100可利用其內的傳輸介面諸如第1圖所示之主機控制器介面130將該多個子訊框封包自通訊裝置100傳送至主裝置50，以容許主裝置50依據該多個子訊框封包的任一者的最大可容許長度來預分配多個緩衝空間以供接收該多個子訊框封包。

總結來說，本發明的通訊裝置以及方法能透過硬體的方式對AMSDU封包進行解聚合，以確保主裝置接收到的封包的大小均小於或等於IEEE 802.11標準所規範的一個MSDU封包的最大可容許長度。因此，記憶體資源能以更有效率的方式被利用。

以上所述僅為本發明之較佳實施例，凡依本發明申請專利範圍所做之均等變化與修飾，皆應屬本發明之涵蓋範圍。