CN110383792B - 通信系统中的计算系统和方法 - Google Patents

通信系统中的计算系统和方法 Download PDF

Info

Publication number
CN110383792B
CN110383792B CN201880014570.2A CN201880014570A CN110383792B CN 110383792 B CN110383792 B CN 110383792B CN 201880014570 A CN201880014570 A CN 201880014570A CN 110383792 B CN110383792 B CN 110383792B
Authority
CN
China
Prior art keywords
identifier
packet
session
downstream
data packet
Prior art date
Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
Active
Application number
CN201880014570.2A
Other languages
English (en)
Other versions
CN110383792A (zh
Inventor
阿西玛·马哈帕特拉
Current Assignee (The listed assignees may be inaccurate. Google has not performed a legal analysis and makes no representation or warranty as to the accuracy of the list.)
Microsoft Technology Licensing LLC
Original Assignee
Microsoft Technology Licensing LLC
Priority date (The priority date is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the date listed.)
Filing date
Publication date
Application filed by Microsoft Technology Licensing LLC filed Critical Microsoft Technology Licensing LLC
Publication of CN110383792A publication Critical patent/CN110383792A/zh
Application granted granted Critical
Publication of CN110383792B publication Critical patent/CN110383792B/zh
Active legal-status Critical Current
Anticipated expiration legal-status Critical

Links

Images

Classifications

    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L45/00—Routing or path finding of packets in data switching networks
    • H04L45/74—Address processing for routing
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F9/00—Arrangements for program control, e.g. control units
    • G06F9/06—Arrangements for program control, e.g. control units using stored programs, i.e. using an internal store of processing equipment to receive or retain programs
    • G06F9/46—Multiprogramming arrangements
    • G06F9/50—Allocation of resources, e.g. of the central processing unit [CPU]
    • G06F9/5005—Allocation of resources, e.g. of the central processing unit [CPU] to service a request
    • G06F9/5027—Allocation of resources, e.g. of the central processing unit [CPU] to service a request the resource being a machine, e.g. CPUs, Servers, Terminals
    • G06F9/5033—Allocation of resources, e.g. of the central processing unit [CPU] to service a request the resource being a machine, e.g. CPUs, Servers, Terminals considering data affinity
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L47/00—Traffic control in data switching networks
    • H04L47/10—Flow control; Congestion control
    • H04L47/12—Avoiding congestion; Recovering from congestion
    • H04L47/125—Avoiding congestion; Recovering from congestion by balancing the load, e.g. traffic engineering
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L67/00—Network arrangements or protocols for supporting network services or applications
    • H04L67/14—Session management
    • H04L67/146—Markers for unambiguous identification of a particular session, e.g. session cookie or URL-encoding
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04W—WIRELESS COMMUNICATION NETWORKS
    • H04W28/00—Network traffic management; Network resource management
    • H04W28/02—Traffic management, e.g. flow control or congestion control
    • H04W28/08—Load balancing or load distribution
    • H04W28/0827—Triggering entity
    • H04W28/0831—Core entity
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04W—WIRELESS COMMUNICATION NETWORKS
    • H04W76/00—Connection management
    • H04W76/10—Connection setup
    • H04W76/11—Allocation or use of connection identifiers
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04W—WIRELESS COMMUNICATION NETWORKS
    • H04W88/00—Devices specially adapted for wireless communication networks, e.g. terminals, base stations or access point devices
    • H04W88/16—Gateway arrangements
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F2209/00—Indexing scheme relating to G06F9/00
    • G06F2209/50—Indexing scheme relating to G06F9/50
    • G06F2209/5016—Session
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L45/00—Routing or path finding of packets in data switching networks
    • H04L45/50—Routing or path finding of packets in data switching networks using label swapping, e.g. multi-protocol label switch [MPLS]

Landscapes

  • Engineering & Computer Science (AREA)
  • Computer Networks & Wireless Communication (AREA)
  • Signal Processing (AREA)
  • Software Systems (AREA)
  • Theoretical Computer Science (AREA)
  • Physics & Mathematics (AREA)
  • General Engineering & Computer Science (AREA)
  • General Physics & Mathematics (AREA)
  • Data Exchanges In Wide-Area Networks (AREA)
  • Mobile Radio Communication Systems (AREA)

Abstract

系统和方法涉及将针对给定无线订户的包处理限制或“固定”于单个“包处理程序”核心，从而提高电信系统的吞吐量并降低缓存丢失的概率和发生率。包头数据可以包含订户的隧道端点标识符(“TEID”)和/或会话标识符。负载平衡器核心可以使用一种或两种标识符来选择可以引导包的双向流量通过的包处理程序核心。可以使用散列算法来为多个包处理程序核心中的每一个分配多个UE。其他实施例涉及通过利用分区多协议标签交换(“MPLS”)标签空间在系统启动的代理流量与下游UE流量之间进行区分。例如，MPLS标签空间可以被分成UE池地址域和代理环回地址域。

Description

通信系统中的计算系统和方法
相关申请的交叉引用
本申请要求2017年1月25日提交的第62/450,162号美国临时专利申请的优先权，其全部内容通过引用并入本文。
技术领域
本发明的实施例总体上涉及电信系统，并且具体地涉及通信系统中对数据包的处理和路由。
背景技术
当通过电信网络传送数据文件时，可以将它们分解成数据“包”，该数据“包”从来源路由至目的地以进行处理。随着包网络应用复杂度的增加，使用多处理器核心架构(“多核心网络”)正变得越来越普及。
发明内容
根据所公开的主题，提供了用于在通信系统中向包处理程序核心发送包的系统和方法。在一些实施例中，所公开的主题包括计算设备，该计算设备用于接收和订户相对应的创建会话的请求。在一些实施例中，计算设备为会话分配下游标识符和上游标识符并将会话标识符与会话进行关联。在一些实施例中，会话标识符唯一地标识与订户相关联的会话。在一些实施例中，计算设备接收包括下游标识符和上游标识符的数据包，并基于所接收的下游标识符和上游标识符识别与数据包相关联的会话标识符。在一些实施例中，计算设备随后基于会话标识符将数据包路由至包处理程序核心。
在一些实施例中，上游标识符包括隧道端点标识符(“TEID”)或加密秘钥。在一些实施例中，处理器可以利用加密秘钥加密或解密数据包。在一些实施例中，下游标识符包括用户设备(“UE”)互联网协议(“IP”)地址或TEID。在一些实施例中，上游标识符和下游标识符共享公共值。例如，公共值可以包括上游标识符和下游标识符的前24位。在一些实施例中，处理器可以对会话标识符应用散列算法来确定包处理程序核心。在一些实施例中，处理器可以识别用于数据包的代理服务、将数据包路由至代理服务模块，以及将包处理程序核心的标识符与会话标识符进行关联。在一些实施例中，处理器可以基于包处理程序核心的标识符将数据包路由至包处理程序核心。
在一些实施例中，系统启动的代理流量可以通过利用分区多协议标签交换(“MPLS”)标签空间与下游订户流量进行区分。在一些实施例中，MPLS空间可以被分成UE池地址域和代理环回地址域。
在查看以下附图、详细描述以及权利要求之后，可以更全面地理解所公开主题的这些以及其他性能。应当理解，本文所使用的措辞和术语是为了描述的目的而不应当被认为作为限制。
附图说明
为了更完整地理解所公开主题的各种实施例，现在将结合附图参考以下描述，其中：
图1是根据所公开主题的一些实施例的示出包流通过多核心通信系统的示意图。
图2示出了根据所公开主题的一些实施例的利用单根输入/输出虚拟化(“SR-IOV”)的数据平面开发工具包(“DPDK”)端口位掩码。
图3是根据所公开主题的一些实施方式的示出SR-IOV数据端口连接性的示意图。
图4是根据所公开主题的一些实施方式的示出SR-IOV核心映射的示意图。
图5是示出现有的负载平衡方法的示意图。
图6是根据所公开主题的一些实施例的示出针对利用移动内容云端(“MCC”)的非代理应用程序的负载平衡散列法的示意图。
图7是根据所公开主题的一些实施例的示出针对具有独立式分组数据网络网关(“PGW”)和独立式服务网关(“SGW”)的非代理MCC应用程序的负载平衡散列法的示意图。
图8是根据所公开主题的一些实施例的示出针对利用MCC作为“Gi”的非代理应用程序的负载平衡散列法的示意图。
图9是根据所公开主题的一些实施例的示出针对利用可信无线接入网关(“WAG”)的非代理应用程序的负载平衡散列法的示意图。
图10是根据所公开主题的一些实施例的示出针对利用具有互联网协议安全(“IPsec”)加密的可信WAG的非代理应用程序的负载平衡散列法的示意图。
图11是根据所公开主题的一些实施例的示出利用演进分组数据网关(“ePDG”)的负载平衡散列法的示意图。
图12是根据所公开主题的一些实施例的示出针对代理流量应用程序的负载平衡散列法的示意图。
图13是根据所公开主题的一些实施例的示出针对代理和非代理多协议标签交换(“MPLS”)流量应用程序的负载平衡散列法的示意图。
图14是根据所公开主题的一些实施例的示出示范性网络架构的示意图。
图15是根据所公开主题的一些实施例的示出MCC的示范性配置的示意图。
图16是根据所公开主题的一些实施例的涉及建立会话的流程图。
图17是根据所公开主题的一些实施例的示出用于建立会话的方法的流程图。
图18是根据所公开主题的一些实施例的示出用于处理上游数据包的方法的流程图。
图19是根据所公开主题的一些实施例的示出用于处理下游数据包的方法的流程图。
图20是根据所公开主题的一些实施例的示出用于处理涉及代理服务的数据包的方法的流程图。
具体实施方式
本文所述的一些实施例涉及将针对给定无线订户的包处理限制或“固定”于单个“包处理程序”核心，从而提高电信系统的吞吐量并降低缓存丢失的概率和发生率。例如，包头数据可以包含订户的隧道端点标识符(“TEID”)和/或会话标识符(“会话ID”或“工作流会话ID”)，并且负载平衡器核心可以使用一种或两种标识符来选择可以引导包的双向流量通过的包处理程序核心。在一些此类实施例中，使用散列算法来为多个包处理程序核心中的每一个分配多个UE，从而平衡多个核心的集体负载。
其他实施例涉及利用分区多协议标签交换(“MPLS”)标签空间在系统启动的代理流量与下游UE(例如，非代理)流量之间进行区分。例如，MPLS标签空间可以被分成UE池地址域和代理环回地址域。
使用TEID和工作流会话ID来识别并路由上游和下游流量
在接入网络和分组数据网络之间路由电信流量的传统方法中，其对包处理核心的选择基于包源数据和包目的地数据。相比而言，在本公开的实施例中，针对给定无线订户的用户设备(“UE”)，从网络的接入侧接收到的包和相对应的来自互联网核心的响应包基于对应订户的隧道端点标识符(“TEID”)和工作流会话ID被识别并路由至处理核心。DPDK负载平衡器核心使用TEID和工作流会话ID的公共值(例如，其各自的前24位)来选择/分配特定和核心，从而只要对应于该工作流ID的UE订户会话是活跃的则将UE的包处理固定到该核心。在一些实施方式中，TEID是订户特定标识符，其在移动管理实体(“MME”)或演进节点B(“eNodeB”)和本公开的MCC之间进行协商。例如，在一些实施例中，初始“创建会话”请求从MME/eNodeB发送至MCC。MCC分配工作流会话ID(例如，24位)、包含工作流会话ID的隧道发送ID(“TEID”)(例如，32位，其包含24位工作流会话ID)，以及UE IP地址。换言之，对工作流会话ID的分配可以包括复制TEID的前24位作为工作流会话ID的24位(从而确保各自的前24位相匹配)。在MCC处的这些分配可以由本文所述的一种或多种系统来执行。MCC将TEID和UEIP地址发送回MME/eNodeB，而MME/eNodeB将经修改的TEID发送回MCC。在一些此类实施例中，经修改的TEID包含和最初提议的TEID的TEID相同的24位工作流会话ID。正是MME/eNodeB和MCC之间的这种反复协商得到了最终的TEID，其之后将在相关联的会话期间用于对分配给特定用户的数据包进行识别和/或路由。在MCC处将最终TEID从控制平面传送至WSM和数据平面中的一个或多个IOM备用。可以在输入-输出多路复用(“IOM”)阶段将该TEID添加到包头。一旦确立了经协商的TEID，则可以将源自一个或多个UE并具有TEID承载头的订户数据包以虚拟地GTP-U隧道方式发送至MCC。随后可以在包头上使用散列算法为所有可用的核心指定或分配多个UE。
图14是示出根据一些实施例的示范性网络架构的示意图。用户设备(“UE”)1402与eNodeB 1404进行通信，其继而与移动管理试题(“MME”)1406和移动内容云端(“MCC”)1416进行通信。MCC 1416包括若干逻辑节点，包括服务网关(“SGW”)1408、分组数据网络网关(“PGW”)1410、一系列工作流服务模块(“WSM”)，以及一系列输入/输出多路复用器(“IOM”)1414。MCC 1416被进一步连接至分组数据网络，例如互联网1422，通过该网络其可以访问外部服务器1424。MCC 1416接收与UE 1402相关联的上游数据包1418。MCC 1416还接收与UE1402相关联的下游数据包1420。在一些实施例中，上游包通常指的是流动离开UE 1402的包而下游包通常指的是流向UE 1402的包。如以下所进一步详细描述的，MCC 1416使用TEID、UE IP地址和会话ID将与UE 1402相关联的上游包和下游包两者固定到MCC内的某个包处理程序核心。
图15是示出MCC 1416的示范性配置的示意图。MCC 1416可以在具有一个或多个物理或虚拟处理核心的处理机上实现。如图所示，逻辑节点通过交换机1502相连接。例如，用于一系列工作流服务模块(“WSM”)1412、一系列输入/输出多路复用器(“IOM”)1414和一系列SGW 1408/PGW 1410模块的逻辑节点连接至交换机1502。一系列工作流服务模块(“WSM”)1412中的每一个包括负载平衡核心(“LBC”)1504和一系列包处理程序核心(“PHC”)1506。输入/输出多路复用器配置为接收上游数据包1418和下游数据包1420。一系列输入/输出多路复用器(“IOM”)1414中的每一个包括用于选择并为流入数据包分配特定WSM和PHC的一个或多个表。
图16示出了根据一些实施例的流程图。在步骤1602中，MCC 1416从MME 1406接收到为用户设备创建会话的请求。该请求包括TEID，MCC 1416稍后将使用其用于指向用户设备的下游流量(指定“TEID_D”)。在步骤1604中，MCC 1416创建与新会话相关联的TEID，该TEID由eNodeB 1404/MME 1406用于与用户设备相关联的上游流量(指定“TEID_D”)。MCC1416还创建与新会话相关联的会话ID。在一些实施例中，TEID_U和会话ID共享公共值。例如，TEID_U的前24位可以与会话ID的前24位相匹配。一旦创建了TEID_U和会话ID，则MCC1416通知MCC 1416内所有的IOM该新创建的TEID_U和新创建的会话ID相对应。在一些实施例中，各IOM可以将该信息的记录保存在表中。
MCC 1416还分配与新会话相关联的UE IP地址。该UE IP地址可以用作源IP地址，以用于到例如互联网1422的外部数据网络的流出流量。其还可以用作目的地IP地址，以用于来自外部数据网络的针对用户设备的流入流量。在创建UE IP地址时，MCC 1416通知MCC1416内的所有IOM该新创建的UE IP地址与新创建的会话ID相关联。在一些实施例中，各IOM可以将该相关性的记录保存在表中。在步骤1606中，MCC 1416向eNodeB 1404/MME 1406发送创建会话响应。该创建会话响应包含TEID_U。
在步骤1608中，MCC从eNodeB 1404/MME 1406接收上游数据包。该上游数据包包含之前建立的TEID_U。在步骤1610中，MCC 1416识别和TEID_U相对应的会话ID。在一些实施例中，IOM通过利用作为表的索引的TEID_U识别会话ID。IOM随后可以基于会话ID选择工作流服务模块(“WSM”)，以用于处理上游数据包并且将上游数据包路由至所选择的WSM。WSM基于会话ID选择特定的包处理程序核心(“PHC”)。在一些实施例中，使用散列算法来基于会话ID为PHC分配上游数据包。在步骤1612中，上游数据包被路由至其在外部数据网络(例如，互联网1422)中的目的地地址。
在步骤1614中，MCC 1416接收包含UE IP地址的下游数据包。UE IP地址指示该下游数据包与设备用户相关联。在步骤1616中，MCC 1416识别和UE IP地址相对应的会话ID。在一些实施例中，IOM通过利用作为表的索引的UE IP地址识别会话ID。IOM随后可以基于会话ID选择工作流服务模块(“WSM”)，以用于处理下游数据包并且将下游数据包路由至所选择的WSM。WSM基于会话ID选择特定的包处理程序核心(“PHC”)。在一些实施例中，使用散列算法来基于会话ID为PHC分配下游数据包。由于针对该下游数据包所识别的会话ID与针对上游数据包所识别的会话ID相匹配，与设备用户相关联的流量可以被限制或“固定”至特定的包处理程序核心。另选地，在一些实施例中，在步骤1614中，将接收的UE IP地址直接映射到包处理程序核心。例如，IOM可以保存将UE IP地址与之前针对对应的会话ID所识别的包处理程序核心进行关联的表。包处理程序核心对下游数据包进行处理。在步骤1618中，通过利用TEID_D将下游数据包路由至eNodeB 1404/MME 1406。
图17是根据一些实施例的示出用于建立会话的方法的流程图。在步骤1702中，接收创建会话的请求。在步骤1704中，创建TEID_U和会话ID，两者均与新会话相关联。在步骤1706中，通知IOM相关联的TEID_U和会话ID。在一些实施例中，IOM可以将该相关性的记录保存在表中。在步骤1708中，创建和新会话相对应的UE IP地址。在步骤1710中，通知IOM该UEIP地址和其与新会话和会话ID的相关性。在一些实施例中，各IOM可以将该相关性的记录保存在表中。在一些实施例中，直接将UE IP地址映射到包处理程序核心。在步骤1712中，发送包含TEID_U的创建会话响应。
图18是根据一些实施例的示出用于处理上游数据包的方法的流程图。在步骤1802中，接收到上游数据包。上游数据包包含与会话ID相对应的TEID_U。在步骤1804中，从上游数据包中提取该TEID_U。在步骤1806中，基于查找表识别与该TEID_U相对应的会话ID。在步骤1808中，基于已识别的会话ID为WSM分配上游数据包。在步骤1810中，基于会话ID进一步为包处理程序核心分配上游数据包。在一些实施例中，基于会话ID的散列化值为特定的包处理程序核心分配上游数据包。
图19是根据一些实施例的示出用于处理下游数据包的方法的流程图。在步骤1902中，接收到下游数据包。下游数据包包含与会话ID相对应的UE IP地址。在步骤1904中，从下游数据包中提取该UE IP地址。在步骤1906中，基于查找表识别与该UE IP地址相对应的会话ID。在步骤1908中，基于已识别的会话ID为WSM分配下游数据包。在步骤1910中，基于会话ID进一步为包处理程序核心分配上游数据包。在一些实施例中，基于会话ID的散列化值为特定的包处理程序核心分配下游数据包。
分割MPLS标签空间以在面向互联网核心的接口上区分UE流量和系统启动的代理 流量
在一些实施例中，当在核心侧使用多协议标签交换(“MPLS”)时，为了区分系统启动的代理流量和下游UE流量，可以将MPLS标签空间分成两个不同的域：UE池地址域和代理环回地址域。对应于给定UE的IP地址的静态路由可以利用来自UE域的标签来通告，而对应于代理环回地址的静态路由可以通过多协议边界网关协议(“MP-BGP”)利用来自环回地址域的标签来通告。DPDK负载平衡器核心随后可以使用标签范围信息来区分代理流量和下游UE流量。例如，当下游代理流量包基于5元组值(例如，以下中的一个或多个：源地址、目的地地址、源端口、目的地端口和以太网类型)
在IPv4源网络地址转换(“NAT”)地址中嵌入核心ID信息以用于固定下游代理流量
当系统识别出针对订户/UE的代理服务时，来自该订户/UE的所有包被引导至增值服务(“VAS”)模块以用于代理服务。工作流服务模块使用基于IPv4的源NAT来与VAS模块进行通信。NAT地址的第三字节被编码以携载核心ID信息。在返回路径上，在工作流服务模块上的负载平衡器核心从NAT地址中提取核心信息并将包引导到对应的核心以用于下游处理。这确保了上游和下游UE代理流量在同一核心上进行处理，从而最大化了L2缓存利用率并提高了系统的性能。
现有技术的解决方案基于作为散列值的UE地址来获得包核心。但是这种解决方案在多种服务平台上并不起作用。此外，并没有针对工作流服务模块的负载平衡以及基于MPLS标签识别代理还是非代理下游流量的解决方案。
基于TEID和会话ID固定UE流量是在所有服务平台上用于提高数据吞吐量的全方位的解决方案。使用MPLS标签来识别下游UE流量并在NAT地址中嵌入核心信息进一步有助于将UE绑定到特定的核心，从而更好地增强了用户体验。
现在转向附图，图1是根据所公开主题的一些实施例的示出包流通过多核心通信网络的示意图。例如，可以如图所示来实现WSM模块、IOM模块或者组合WSM/IOM模块。如图1中所示，多核心系统100包括设备层、输入/输出(“I/O”)层以及包处理程序层(本文中也被称为“快速路径”层)。一般而言，如本文中所使用的，源自服务器并且向数据中心内的另一服务器传递的包按描述沿东-西(“E/W”)方向行进并通过E/W端口(112A，112B)。然而，在网络订户的用户设备(UE)(例如移动设备或计算机)和分组数据网络目的地(例如，互联网)之间传递的包按描述沿北-南(“N/S”)方向行进并通过N/S端口(114A，114B)。在多核心系统100中，E/W端口112B和N/S端口114B是任选的。不管包流量是E/W还是N/S，对应的包通过数据平面开发工具包(“DPDK”)轮询模式驱动器(110A，11B)传递至I/O层并在I/O层中通过接收(Rx)核心(106A，106B)接收。Rx核心将包传递到可操作地耦合至其的相关负载平衡器(“LB”)核心(104A，104B)。LB核心随后通过服务质量(“QoS”)队列将可能已经被相应LB核心修改的包传递到包处理程序(“HD”)核心(102A，102B)中的一个。由于多个包处理程序核心(例如，在快速路径层中)的可用性以及路由通过该多个包处理程序核心，包数据子集可能由于对同一数据子集做出的非协同编辑而被损坏，从而可能需要“锁定”数据结构的机制来减轻数据损坏的风险。当将包路由通过多个核心时，还可能出现缓存丢失，其中处理所需的数据在缓存存储器中无法找到，从而导致了处理延迟。利用本文中所述的技术，通过将针对给定订户/UE的包流量“固定”至多核心系统内的单个包处理程序核心，减少或排除了缓存丢失和对锁定机制的需要，从而使得所有对应的北行和南行流量通过统一包处理程序核心。本文中所述的方法还可以针对代理应用程序实施。例如，通过N/S端口114来自UE的包可以通过Rx核心106B，并且随后到达LB核心104B。LB核心104B可以为该包分配包处理程序核心(102B)中的一个。另外，在确定该包为代理包时，LB核心104B可以对包执行内部网络地址转换(“NAT”)转换以嵌入IP地址和源端口，从而命令该包被路由至内部代理以用于处理。在处理包的同时，包处理程序核心102B可以确定(例如，基于由LB核心104B对包做出的修改)包为代理包并将该包转发至和包处理程序核心102B位于一处或在其远程的另一服务器以用于处理。为了定义返回路径，服务器从包中提取IP地址和目的地端口号以确保该包通过包处理程序核心102B路由返回到N/S端口114A。
图2示出了根据所公开主题的一些实施例的利用单根输入/输出虚拟化(“SR-IOV”)的DPDK端口220位掩码。在一些实施方式中，系统存储对针对内部使用哪些端口是N/S端口以及哪些端口是E/W端口的映射。这种映射可以用于将每个以太网端口定义为“Gi”(例如，面向互联网的)端口或“Gn”(例如，来自订户的流量)端口。这种端口映射按照XML代码编写的一个示例性片段如下所示：
/etc/platform/platform.xml
platform.xml->/etc/platform/platform_SRIOV_RED.xml
<！--Variables for DPDK-->
<dpdk>
<sriov>true</sriov>
<loadbalDpdkPorts>3c</loadbalDpdkPorts>
<loadbalThreadsCount>1</loadbalThreadsCount>
<loadbalHugePageSize>25</loadbalHugePageSize>
<loadbalHugePageCount>1500</loadbalHugePageCount>
<loadbalCoreCount>fffffff0</loadbalCoreCount>
<loadbalIoCorePortMask0>24</loadbalIoCorePortMask0>
<loadbalIoCorePortMask1>18</loadbalIoCorePortMask1>
<loadbalIoFctGrouping>all-separated</loadbalIoFctGrouping>
<workflowDpdkPorts>24</workflowDpdkPorts>
<workflowThreadsCount>1</workflowThreadsCount>
<workflowHugePageSize>25</workflowHugePageSize
<workflowHugePageCount>1500</workflowHugePageCount>
<workflowCoreCount>fffffff0</workflowCoreCount>
<workflowIoCorePortMask0>24</workflowIoCorePortMask0>
<workflowIoFctGrouping>all-separated</workflowIoFctGrouping>
图3是根据所公开主题的一些实施方式的示出SR-IOV数据端口连接性的示意图。如图3中所示，冗余E/W交换机(312A，312B)和冗余N/S交换机(314A，314B)各自可操作地耦合至多个服务器322(例如，C7000刀锋服务器)。在一些实施方式中，每个服务器322连接至单个N/S交换机。每个交换机可以具有单个物理函数(“PF”:328A-328D)，该单个物理函数具有多个相关联的虚拟函数(“VF”)，并且这些VF可以在相关VM实例化时映射到每个PF。每个服务器322可以包括多个虚拟机(“VM”)，如：(1)数字控制模块“DCM”VM 324，例如，由于其为内拟机仅连接至E/W交换机；和(2)输入/输出多路复用器“IOM”VM 326。每个VM可以包括多个逻辑接口(“Eth-3”、“Eth-4”等)，如图3中所示，并且这些逻辑接口可以被分配作为Gi或Gn接口，例如当实例化相关的VM时。在一些实施例中，每个VF对应于仅一个此类逻辑接口。
图4是根据所公开主题的一些实施方式的示出SR-IOV核心映射的示意图。如图4所呈现，核心0-3被保留用于在VM上运行的Linux操作。核心4在初始化期间由DPDK(Intel提供的库)使用并且随后释放给Linux。核心5由DPDK用于周期地监控缓冲池，或者由Linux使用。核心6、8和10分别对应于Rx、Tx和LB，用于对应于端口掩码组0的E/W光纤端口，如之前参考图2所示和所述。核心7、9和11分别对应于Rx、Tx和LB，用于对应于端口掩码组1的N/S光纤端口，如之前参考图2所示和所述。核心12-19(总共7个核心)被用于包处理。核心10和11包含负载平衡算法，并且在核心12-19上实现负载平衡。
在一些现有的配置中，默认负载平衡算法基于源地址和目的地地址，并且分两个阶段执行。在第一阶段中，LB核心基于以太网类型确定用于内IP包的协议。MPLS可以在该阶段期间得到识别，并且可以针对内IP包将负载平衡算法设置为5元组。光纤包以及其他包(或“有效载荷”)类型可以通过查看以太网类型来识别。以太网类型可以用于在IOM和WSM之间进行包的路由，以及用于确定包的方向性(例如，互联网界的或访问侧界的)和/或用于指示哪种协议封装在以太网帧的有效载荷中。例如，IOM可以提取接收自UE的包，确定目的地WSM的MAC地址，以及向包添加以太网头以确保该包被正确地交换/路由至目的地WSM。
现在参考图5，在工作流服务模块(“WSM”)530上，对于通用分组无线业务(GPRS)隧道协议(“GTP”)型的网络流模块到工作流模块(GNFM-到-WFM)(即，UE-到-互联网包传播-参见从IOM 526A指向WSM 530的箭头)的以太网类型，由负载平衡算法规定的路由可以基于源地址(“SrcAddr”)或基于源地址和目的地地址的组合(“(Src+Dst)Addr”或“(S+D)Addr”)。在IOM 526B上，对于WFM-到-GiFM(参见从WSM 530指向IOM 526B的箭头)的以太网类型，由负载平衡算法规定的路由可以基于源地址(“SrcAddr”)或基于5元组。在第二阶段，已经在第一阶段确定了用于内IP包的协议的LB核心识别通用路由封装(“GRE”)、封装安全有效载荷(“ESP”)、层2隧道协议(“L2TP”)和/或通用分组无线业务隧道协议(“GTP”)包。在一些实施方式中，L2TP包是基于目的地地址“DstAddr”或“DAddr”)而达到负载平衡的，因为假定了该包是下游UE包。此类负载平衡还可以应用于在图5中的GiFM-到-WFM箭头上所示的IP包。对于GTP-U包(即，携载用户数据的GTP包——参见从WSM 530指向IOM 526A的箭头)，由负载平衡算法规定的路由可以基于SrcAddr或(Src+Dst)Addr。如果协议是ESP，则由负载平衡算法规定的路由可以基于循环或(Src+Dst)Addr。然而，利用本段落中所述的方法，在Gi接口处不存在能够区分流入代理包和下游UE包的机制。在两种情况下均利用5元组来执行负载平衡。该方法在接收到IP片段的情况下可能不起作用。此外，对于独立式的SGW/PGW应用程序，关于包是要用于SGW还是PGW在S5/S8界面上并没有差别。GTP-U包是利用(Src+Dst)Addr达到负载平衡的。在WSM/SSM上，下游UE代理包是利用5元组达到负载平衡的。由于NAT转换，UE地址在DPDK级上并不可用。
如以上所讨论的，在现有的通信架构中，从接入网络到达WSM的包基于源地址和目的地地址被识别并路由至一个或多个包处理核心，而从分组数据网络到达WSM的包通过目的地地址被识别和/或路由。此类设计缺乏灵活性，因为它们并不与所有的联网架构兼容。相比而言，在本文所述的方法中(例如，在之后的示范性实施例中)，从接入网络到达WSM的包基于TEID被识别并路由至一个或多个包处理核心，而从分组数据网络到达WSM的包基于会话ID被识别并路由至一个或多个包处理核心。TEID和会话ID各自包含相同的前24位。因此，本文中所述方法和系统的负载平衡能力(从包的角度看)可以按照独立于网络配置的方式来实现。
如本文中所使用的，“GnFM-到-WFM”以太网类型代表“通用分组无线业务(GPRS)隧道协议(“GTP”)型的网络流模块到工作流模块”以太网类型，指的是封装用户数据以促进网络流模块(例如，网络的接入/用户侧)和工作流模块之间通信的任何以太网类型。同样，“WFM-到-GnFM”以太网类型指的是封装用户数据以促进工作流模块和网络流模块之间的通信的任何以太网类型。
如本文中所使用的，“WFM-到-GiFM”以太网类型指的是封装用户数据以促进工作流模块和面向互联网模块(例如，与分组数据网络进行通信的IOM)之间的通信的任何以太网类型。同样，“GiFM-到-WFM”以太网类型指的是封装用户数据以促进面向互联网模块和工作流模块之间的通信的任何以太网类型。
如本文中所使用的，“SECM-到-SECM”以太网类型指的是促进通信网络内联网的安全模块之间通信的任何以太网类型。
如本文中所使用的，“SECM-到-IOM”以太网类型指的是促进通信网络内安全模块和输入-输出多路复用器模块之间通信的任何以太网类型。
图6是根据所公开主题的一些实施例的示出针对发生在移动内容云端(“MCC”)100中的的非代理(例如，在UE和互联网之间的直接包流量)应用程序的负载平衡散列法的示意图。如图6中所示，源自UE并到达接入网络615的“S1 U”接口/端口的数据包被以GTP-U隧道方式发送至IOM 626A。在IOM 626A处的包通过源地址和目的地地址的散列(“(Src+Dst)Addr”)被识别，并且包含经协商的TEID(GTP-U头隧道ID)。在一些实施方式中，所有的IOM基于返回目的地IP地址接收将UE与会话ID相关联的数据。在该IOM阶段TEID被添加到包头(例如，由控制平面中的eNodeB节点添加并随后发送至数据平面中的IOM)。该包通过IOM 626A利用GnFM-到-WFM以太网类型(如上所示，其代表通用分组无线业务(GPRS)隧道协议(“GTP”)型的网络流模块到工作流模块”)转发至WSM 630上的WFM(即，转发至WSM 630A的IP地址)。该包通过WSM上的负载平衡器接收，并且WSM 630确定分配给该包哪个包处理程序核心。在GnFM-到-WFM分包内是UE包，可以从UE包中提取GTP头。GTP头携载了TEID(其前24位与会话ID的前24位相同)。在WSM 630处，包通过其24位的TEID被识别，并且该TEID被散列化以识别出要将包路由至的适当包处理程序核心。该包由WSM 630利用WFM-到-GiFM以太网类型转发至IOM 626B(即，转发至IOM 626B的IP地址)，其中其利用5元组(例如，源地址、目的地地址、源端口、目的地端口以及以太网类型)被识别并且可以被发送至分组数据网络625，以用于在返回到IOM 626B之前进行进一步的处理(例如，包括网络接入标识)，其中其利用5元组再次被识别。IOM 526B利用查找表来确定要添加到包头的适当会话ID。在一些实施方式中，查找表在IOM上进行维护，并且包括用于每个所服务的订户的数据。这一查找表可以在例如为订户创建会话时进行填充。如本文所述，会话同时携载TEID和会话ID。当包从互联网侧进入MCC时，其目的地地址为订户的IP地址(这是去向订户的下游包)。这一IP地址可以用于和查找表相互对照以识别相关联订户的会话ID。当包从接入侧进入时，其源地址为订户地址而其目的地地址为用户正在尝试接入的互联网中服务器的地址。这一源地址可以用于和查找表相互对照以识别相关联的TEID。由于4G网络的性质，在一些实施例中，在接入侧并不是总能获取到会话ID，但是TEID可以是能够访问的。类似地，在PDN侧，会话ID可以是能够访问的。如此，在一些实施方式中，针对包识别和/或路由，在接入侧使用TEID而在PDN侧使用会话ID。由于TEID和会话ID的高24位被设计成相同，这些位散列到同一核心，由此将订户固定至特定的核心。
IOM 526B将适当的会话ID添加到包头。随后，继续沿其返回路径，该包由IOM 626B利用GiFM-到-WFM以太网类型转发至WSM 630上的WFM，并且在WSM 630处基于其24位的会话ID被识别并路由至处理核心。WSM 630散列会话ID以识别对应的TEID。随后在返回到接入网络615和包来源的UE之前，该包利用WFM-到-GnFM从WSM 630以GTP-U隧道方式返回到IOM626A。在一些实施例中，IOM 626A和IOM 626B驻留在同一物理位置处。在一些实施例中，IOM626A和IOM 626B表示单个IOM。
图7是根据所公开主题的一些实施例的示出针对具有独立式分组数据网络网关(“PGW”)(其还可以用作网关GPRS支持节点，“GGSN”)和独立式服务网关(“SGW”)(其还可以用作服务GPRS支持节点，“SGSN”)的非代理MCC应用程序的负载平衡散列法的示意图。如图7中所示，沿着独立式PGW/GGSN路径，源自UE的数据包经过接入网络715的“S5/S8”接口/端口并且以GTP-U隧道方式发送至利用其(Src+Dst)Addr识别的IOM 726A，并且可以包含经协商的TEID(GTP-U头隧道ID)。该包由IOM 726A利用GnFM-到-WFM以太网类型转发至WSM 730A上的WFM(即，至WSM 730A的IP地址)，并且基于其TEID被识别并路由至处理核心。该包由WSM730A利用WFM-到-GiFM以太网类型转发至IOM 726B(即，至IOM 726B的IP地址)，其中其利用5元组(例如，源地址、目的地地址、源端口、目的地端口以及以太网类型)被识别和路由并且可以被发送至分组数据网络725，以用于在返回到IOM 726B之前进行进一步的处理，其中其利用5元组再次被识别。继续沿其返回路径，该包由IOM 726B利用GiFM-到-WFM以太网类型转发至WSM 730A上的WFM，并且基于其会话ID被识别并路由至处理核心。随后在返回到接入网络715和包来源的UE之前，该包利用WFM-到-GnFM从WSM 730A以GTP-U隧道方式返回至IOM726A。
沿着图7中的独立式SGW/GGSN路径，源自UE的数据包经过接入网络715的“S1U”接口/端口并且以GTP-U隧道方式发送至利用其(Src+Dst)Addr识别的IOM 726C，并且可以包含经协商的TEID(GTP-U头隧道ID)。该包由IOM 726C利用GnFM-到-WFM以太网类型转发至WSM 730B上的WFM(即，至WSM 730B的IP地址)，并且基于其TEID被识别并路由至处理核心。该包由WSM 730B利用WFM-到-GiFM以太网类型以GTP-U隧道方式发送至IOM 726D，其中其利用其(Src+Dst)Addr被识别，并且可以在返回到IOM 726D之前被发送至分组数据网络725以用于进一步处理，其中其再次利用其(Src+Dst)Addr被识别。这种从IOM 726D到分组数据网络725的传输可以是到S5/S8接口的GTP-U隧道式发送，并且可以应用GGSN、PGW(“4G”标准)和/或G1服务。在其通过独立式SGW的返回路径上，该包由IOM 726D利用GiFM-到-WFM以太网类型转发至WSM 730B上的WFM，并且基于其会话ID被识别并路由至处理核心。随后在返回到接入网络715和包来源的UE之前，该包利用WFM-到-GnFM从WSM 730B以GTP-U隧道方式返回至IOM 726C。
图8是根据所公开主题的一些实施例的示出针对利用MCC作为“Gi”网关(例如，可以提供例如被称为“Gi服务”的增值服务的面向互联网的网关)的非代理应用程序的负载平衡散列法的示意图。如图8中所示，包可以来自接入网络侧或者分组数据网络侧。为了使流入数据包的来源清楚，传递接口接入属性以识别出包是来自接入侧(在这种情况下，源地址用于散列)还是来自互联网/分组数据网络侧(在这种情况下，目的地地址用于散列)。在一些此类实施方式中，源自UE的数据包通过Gi接入接口从接入网络815传递到利用其源地址(“SAddr”)识别的IOM 826A，因为接口接入属性和来自接入网络的包相对应。作为这一传输的一部分，可以将接口属性推送到DPDK以识别Gi接入接口。该包由IOM 826A利用GnFM-到-WFM以太网类型转发至WSM 830上的WFM(即，至WSM 830的IP地址)，并且基于其TEID被识别并路由至处理核心。该包由WSM 830利用WFM-到-GiFM以太网类型转发至IOM 826B(即，至IOM 826B的IP地址)，其中其利用5元组被识别，并且可以被发送至分组数据网络825以用于在返回到IOM 826B之前进行进一步的处理，其中其利用DAddr再次被识别。继续沿其返回路径，该包由IOM 826B利用GiFM-到-WFM以太网类型转发至WSM 830上的WFM，并且基于其会话ID被识别并路由至处理核心。随后在返回到接入网络815和包来源的UE之前，该包利用WFM-到-GnFM从WSM 830传递回IOM 826A。
利用Wi-Fi网络来扩展网络覆盖并减少宏蜂窝网络上的流量对于服务提供方可以具有成本优势。可信Wi-Fi网络可以是例如服务提供方维护(例如，在机场的托管热点)的热点或与服务方合作部署的热点。服务提供方可以是移动或固定网络运营商。例如，有线供应商康卡斯特(Comcast)当前通过其已在美国部署的数千个无线热点同时提供无线语音和数据服务。
可信网络可以被定义为其中服务提供方可以验证基本的用户信息并对接入点施加一定程度的控制的网络。例如，Wi-Fi用户可以通过服务提供方的认证、授权和计费(AAA)系统来经由可信的WLAN代理(“TWAP”)得到认证，同时语音/数据流量本身可以通过可信WLAN接入网关(“TWAG”)并被卸载到网络上以用于回程。在本文所述的一些实施例中，对来源于订户的包执行Gi服务，如策略实施(例如，服务质量(“QoS”)策略、内容过滤、网页/视频优化，以及安全服务，如NAT、防火墙和互联网协议安全(“IPSec”)。
在一些实施方式中，将订户的网络体验——包括增值服务和无缝会话切换，扩展至可信的Wi-Fi网络涉及与服务提供方的核心网络的紧密集成。可信Wi-Fi接入的一个示例是在较大购物中心的无线漫游，其中一旦进入购物中心，移动订户可以从购物中心外的宏蜂窝网络无缝地移动到无线LAN(WLAN)。在此场景下，订户可在室内享有更佳的无线接收而无需登录到网络或者中断现有的会话。如以上所讨论的，TWAP可以保护与AAA服务器的通信以用于认证/授权，同时TWAG可以将语音/数据流量(和任选地，流量上的增强策略)卸载到分组数据网络上。然而，并非所有的流量可以直接路由到互联网上。某些流量可以通过TWAG路由至包核心网络。本文所述的实施例可以支持工业标准S2a接口，其使TWAG能够直接与任何工业标准演进分组核心(“EPC”)网关进行通信，无论其是本地虚拟EPC解决方案还是现有的第三方EPC解决方案的一部分。
在具有百万计Wi-Fi接入点的世界中，不可信Wi-Fi网络屡见不鲜，其中服务提供方无法认证用户或者控制网络上的流量的流动。不可信网络的示例可是咖啡店中的Wi-Fi网络或者由竞争提供方托管的网络。在本文所述的一些实施例中，为了便于将不可信Wi-Fi网络引入到核心网络中，可以布置演进分组数据网关(“ePDG”)。
通过不可信网络的通信可以利用添加安全级别来进行保护，其被称为互联网协议安全(“IPSec”)加密。工业标准授权所有的移动设备上必须具有IPSec客户端。在此类情况下，语音和数据会话安全地通过IPSec隧道。这些隧道往往在预计到流入或流出呼叫时保持开放，使得在任何给定时间，在网络中可能需要数百万计的IPSec隧道保持开放。基于硬件的ePDG被设计为处理这一对于开放IPSec隧道的高需求，然而对于虚拟化的ePDG实例，历史上已经证明这些同样高加密的要求是存在问题的。根据本文所述的一些实施例，实现了稳健的虚拟ePDG，其可以在单个服务器上传送5G级别的经IPSec加密的通信。
图9是根据所公开主题的一些实施例的示出针对利用具有Gi服务的可信无线接入网关(“WAG”)的非代理应用程序的负载平衡散列法的示意图。如图9的上部部分中所示，UE可以通过可信Wi-Fi连接或通过3G/4G连接来连接至包网络，并且分别通过具有Gi服务(“GiSvcs”)927的TWAG(例如，通过TWAP利用AAA认证)或SGW向分组数据网络传送包。图9的下部部分显示了在TWAG 927中对经由接入网络源自UE的数据包的处理。该包通过GRE封装的透明以太网桥接(“TEB”)到达IOM 926A，利用其SAddr被识别。该包由IOM 926A利用GnFM-到-WFM以太网类型转发至WSM 930上的WFM(即，至WSM 830的IP地址)，并且基于其TEID被识别并路由至处理核心。该包随后由WSM 930利用WFM-到GiFM以太网类型转发至IOM 926B(例如，至IOM 926B的IP地址，或者以GTP-U隧道方式发送)，其中其利用5元组或其源地址和目的地地址(“(Src+Dst)Addr”)被识别，并且可以发送至分组数据网络(根据用户配置：(1)如果TWAG 927正在提供Gi服务则IP包直接到PDN，或者(2)如果TWAG 927未在提供Gi服务，则通过S2A接口)，以用于在返回到IOM 926B之前进行进一步处理，其中其利用其5元组或源地址和目的地地址(“(Src+Dst)Addr”)再次被识别。继续沿其返回路径，该包由IOM 926B利用GiFM-到-WFM以太网类型转发至WSM 930上的WFM，并且基于其会话ID被识别并路由至处理核心。随后利用WFM-到-GnFM，通过GRE封装的TEB，该包从WSM 930传递回IOM 926A，此时包在返回到接入网络和包来源的UE之前通过其SAddr被识别。
图10是根据所公开主题的一些实施例的示出针对利用具有互联网协议安全(“IPsec”)加密的可信WAG的非代理应用程序的负载平衡散列法的示意图。如图10的上部部分中所示，UE可以通过可信Wi-Fi连接或通过3G/4G连接来连接至包网络，并且分别通过具有Gi服务(“GiSvcs”)1027的TWAG(例如，通过TWAP利用AAA认证)或SGW向分组数据网络传送包。图10的下部部分显示了在TWAG 1027中对源自UE的数据包的处理，该数据包通过IP封装安全有效载荷(“ESP”)从接入网络到IOM 1026A，利用其源地址和目的地地址(Src+Dst)Addr被识别。该包在由IOM 1026A转发至WSM 1030A上的另一SECM(即，至WSM 1030的IP地址)之前通过在IOM 1026A内部的安全模块(“SECM”)(即，SECM-到-SECM传输)和IP封装安全有效载荷(“IP ESP”)进行处理，并且基于其会话ID被识别并路由至处理核心。在WSM 1030A内，包从SECM传递至IOM。包随后由WSM 1030A利用GnFM-到-WFM转发至WSM 1030B上的WFM，并且基于其会话ID再次被识别并路由至处理核心。WSM 1030B利用WFM-到-GiFM以太网类型将包传递至IOM 1026B(即，至IOM 1026B的IP地址，或者以GTP-U隧道方式发送)，其中其利用5元组或其源地址和目的地地址(Src+Dst)Addr被识别，并且可以被发送至分组数据网络，以用于在返回到IOM 1026B之前进行进一步的处理，其中其利用其5元组或其(Src+Dst)Addr再次被识别。继续沿其返回路径，该包由IOM 026B利用GiFM-到-WFM以太网类型转发至WSM 1030B上的WFM，并且基于其会话ID被识别并路由至处理核心。该包随后利用WFM-到-GnFM通过GRE封装的TEB从WSM 1030B传递回IOM 026A，此时包通过其SAddr被识别。该包随后通过用于加密的SECM-到-SECM传输由IOM 1026A的SECM重新引导到WSM 030A的SECM，并且在返回到接入网络和包来源的UE之前通过SECM-到-IOM被传递回IOM 1026A。
图11是示出根据所公开主题的一些实施例的利用ePDG的负载平衡散列法的示意图。如图11的上部部分所示，UE可以通过不可信Wi-Fi连接或通过3G/4G连接连接至包网络，并且通过ePDG 1129向分组数据网络传送包。图11的下部部分显示了在ePDGE 1129中对源自UE的数据包的处理，该数据包利用IP ESP以太网类型从接入网络到IOM 1126A，并且在IOM 1126A处利用其(Src+Dst)Addr被识别。IOM 1126A创建将包的会话并且将包的关键值映射到其本地会话数据以确定会话ID。包在由IOM 1126A利用IP ESP以太网类型转发至WSM1130上的SECM之前(即，SECM-到-SECM传输)通过在IOM 1126A内的SECM进行处理，并且基于其会话ID被识别和路由至处理核心并被解密。在WSM 1130A内，包从SECM传递到WFM，其中会话ID可以由WFM使用以将包路由至处理核心。该包随后由WSM 1130利用WFM-到-GiFM以太网类型转发至IOM 1126B(例如，以GTP-U隧道方式发送)，其中其利用其(Src+Dst)Addr被识别和路由，并且可以被发送至分组数据网络以用于在返回到IOM 1126B之前进行进一步的处理，其中其利用其(Src+Dst)Addr再次被识别。继续沿其返回路径，该包由IOM 1126B利用GiFM-到-WFM以太网类型转发至WSM 1130B上的WFM，并且基于其TEID被识别和路由。在WSM1130A内，包从WFM传递至SECM以用于加密，并且应用了IP ESP。该包随后利用SECM-到-IOM和IP ESO以太网类型从WSM 1130传递回IOM 1126A，此时包在返回到接入网络和包来源的UE之前通过其(Src+Dst)Addr被识别。
图12是根据所公开主题的一些实施例的示出针对代理流量应用程序的负载平衡散列法的示意图。如图12中所示，源自UE并到达接入网络1215的“S1 U”接口/端口的数据包以GTP-U隧道方式发送至IOM 1226A，并且通过(Src+Dst)Addr被识别。该包由IOM 1226A利用GnFM-到-WFM以太网类型转发至WSM 1230上的WFM(即，至WSM 1230的IP地址)，并且通过其TEID被识别。在WSM 1230处，TEID被散列化以用于核心选择。在WSM 1230内，确定包需要代理服务，并将其从WFM传递到执行网络地址转换(“NAT”)的工作流转移模块，其中基于用户源IP地址和分配给该包的目的地MAC地址(去除了UE IP地址)的映射将包流量转向。相应地，当包从PM返回时，工作流转向模块可以执行反向查找并且放回UE IP地址。当转向包流量时，工作流转向模块将具有以太网类型(例如，DEA8-DEAF)的包传递至一个或多个服务模块刀锋PM代理模块(“PM”)1232以用于HTTP代理服务(和/或其他服务，例如视频自适应服务)。当转向的包到达PM时，TCP连接可以由于NAT被终止(即，PM识别出目的地IP地址为其自己的)。当从WSM 1230向PM 1232发送包时，WSM 1230使用“本地”IP地址来代替UE IP地址。这一本地IP地址经由NAT转换通过将UE IP地址映射成本地IP地址来生成。该地址用作源地址(当离开WSM 1230时)和目的地地址(当沿包的返回路径到达WSM 1230时)，并且该IP地址在其位的子集中包含核心信息。换言之，由WSM 1230选择的“本地IP地址”是从可用IP地址的列表中选择的，并且对应于由WSM 1230基于包的TEID的散列针对包而选择的核心。
该包由PM 1232利用给定的以太网类型(例如，“BEEF”)转发至IOM 1226B(即，转发至IOM 1226B的IP地址)，其中其利用5元组被识别并且可以被发送至分组数据网络1225以用于在返回到IOM 1226B之前进行进一步的处理，其中其利用5元组再次被识别。继续沿其返回路径，包由IOM 1226B利用PM 1232上的环回IP地址(例如，PM使用的IP地址，从而使得外部世界可以与其进行通信，并且使得包循环回到PM而不是到WSM)并以一定以太网类型(例如，向IOM 1226B指示包为代理包的DEA8-DEAF)转发至HTTP代理。包随后以指示包方向性(和相对应的，应当如何路由、处理包，等等)的以太网类型BEEF从PM 1232路由回到WSM1230的工作流转向模块。在一些实施方式中，WFM和工作流转向模块软件运行在公共核心上(例如，与TEID、会话ID等相关联)，从而使得可以总是使用相关联的核心。在生成MAC IP地址之前，可以将核心信息嵌入到IP地址内以指示哪个核心生成了正被发送至PM的MAC包。LB核心随后可以识别出其为代理包(例如，其可以获取约7位来识别核心)。在WSM 1230A内，包从工作流转向模块传递至WFM。包由WSM 1230利用WFM-到-GnFM以太网类型以GTP-U隧道方式发送至IOM 1226A，其中其在(同样以GTP-U隧道方式发送)返回接入网络1215和包来源的UE之前利用其(Src+Dst)Addr被识别。
图13是根据所公开主题的一些实施例的示出同时针对代理和非代理多协议标签交换(“MPLS”)流量应用程序的负载平衡散列法的示意图。在图13中所示实施例的一些实施方式中，WSM 1330确定是否要将从IOM 1326A接收的包转移到PM 1332。如图13中所示，源自UE并到达接入网络1315的“S1 U”接口/端口的数据包以GTP-U隧道方式发送至IOM 1326A，并且通过(Src+Dst)Addr被识别。该包由IOM 1326A利用GnFM-到-WFM以太网类型转发至WSM1330(即，至WSM 1330的IP地址)，并且基于其TEID再次被识别并路由至处理核心。
在WSM 1330内，如果确定包需要代理服务，则通过DEA8-DEAF以太网类型将包从WSM 1330传递到一个或多个PM 1332以用于HTTP代理服务，并且执行网络地址转换(“NAT”)。沿着代理路径(以虚线指示)，包由PM 1332利用BEEF以太网类型和多协议标签转换(“MPLS”)转发至IOM 1326B(即，至IOM 1326B的IP地址)，其中其利用5元组被识别并且可以从IOM 1326B发送至分组数据网络1325以用于进一步处理。一旦返回到IOM 1326B，则包利用5元组再次被识别。继续沿其返回路径，包由IOM 1326B利用PM 1332上的环回IP并利用DEA8-DEAF以太网类型转发至HTTP代理。该包随后利用BEEF以太网类型从PM 1332路由回WSM 1330。包由WSM 1330利用WFM-到-GnFM以太网类型以GTP-U隧道方式发送回IOM 1326A，其中其在以GTP-U隧道方式发送回接入网络1315和包来源的UE之前被识别。
如果在WSM 1330处确定北行包并不需要代理服务，则包直接由WSM 1330利用WFM-到-GnFM转发至IOM 1326B(即，至IOM 1326B的IP地址)，其中其利用5元组被识别并且可以从IOM 1326B发送至分组数据网络1325以用于进一步处理。一旦返回到IOM 1326B，则包利用5元组再次被识别。继续沿其返回路径，该包由IOM 1326B利用GiFM-到-WFM转发至WSM1330，其中其基于其会话ID被识别并路由至处理核心。如同在代理返回路径中，包随后由WSM 1330利用WFM-到-GnFM以太网类型以GTP-U隧道方式发送回IOM 1326A，其中其在以GTP-U隧道方式发送回接入网络1315和包来源的UE之前利用其(Src+Dst)Addr被识别。
图20示出了如上所述的涉及代理服务的根据一些实施例的流程图。在步骤2002中，MCC 1416从MME 1406接收到为用户设备创建会话的请求。该请求包括TEID，MCC 1416稍后将使用其用于指向用户设备的下游流量(指定“TEID_D”)。在步骤2004中，MCC 1416创建与新会话相关联的TEID，该TEID被eNodeB 1404/MME 1406用于与用户设备相关联的上游流量(指定“TEID_D”)。MCC 1416还创建与新会话相关联的会话ID。在一些实施例中，TEID_U和会话ID共享公共值。例如，TEID_U的前24位可以与会话ID的前24位相匹配。一旦创建了TEID_U和会话ID，则MCC 1416通知MCC 1416内所有的IOM该新创建的TEID_U和新创建的会话ID相对应。在一些实施例中，各IOM可以将该信息的记录保存在表中。
在步骤2006中，MCC 1416从eNodeB 1404接收上游数据包。该上游数据包包含之前建立的TEID_U。在步骤2010中，MCC 1416识别和TEID_U相对应的会话ID。在一些实施例中，IOM通过利用作为表的索引的TEID_U识别会话ID。IOM随后可以基于会话ID选择工作流服务模块(“WSM”)以用于处理上游数据包并且将上游数据包路由至所选择的WSM。WSM基于会话ID选择特定的包处理程序核心(“PHC”)。在一些实施例中，使用散列算法来基于会话ID为PHC分配上游数据包。
MCC 1416确定上游数据包需要代理服务。例如，上游数据包可能需要特定的视频编码、访问已缓存的内容、SMTP，以及其他的代理服务。代理服务模块可以用于增强对这种数据的处理。MCC 1416随后可以终止现有的IP呼叫并且创建新的环回IP地址，以用于与例如外部分组数据网络进行通信。环回IP地址可以用作和用户设备相关的流出流量的源地址，以及作为和用户设备相关的流入流量的目的地址。MCC 1416随后将环回IP地址映射至和选定的包处理程序核心相对应的标识符并且任选地将这种相关性存储在网络地址转换表(“NAT”)中。
在步骤2012中，通过利用环回IP地址作为源ip地址将上游数据包传输至互联网1422。在步骤2014中，利用环回IP地址作为目的地地址接收下游数据包。在步骤2016中，MCC1416基于环回IP地址将下游数据包路由至代理服务模块。MCC 1416基于环回IP地址使用存储在NAT中的相关性来将下游数据包映射到选定的包处理程序核心。在步骤2018中，通过利用TEID_D将下游数据包路由回eNodeB 1404。
本文所公开的技术和系统可以被实现为计算机程序产品，以用于与网络、计算机系统或计算机化的电子设备一起使用。此类实施方式可以包含一系列的计算机指令或逻辑，其被固定在有形介质上，如计算机可读介质(例如，磁盘、CD-ROM、ROM、闪存或其他存储器或固定盘)，或者通过调制解调器或者其他接口设备(如，通过一定介质连接至网络的通信适配器)传输至网络、计算机系统或设备。
介质可以是有有形介质(例如，光学的或者模拟的通信线路)或者利用无线技术(例如，Wi-Fi、蜂窝、微波、红外或其他传输技术)实现的介质。一系列的计算机指令体现了本文中关于系统所述的功能性的至少一部分。本领域技术人员应当理解，此类计算机指令可以采用多种的编程语言进行编写以用于与许多计算机架构或操作系统一起使用。
此外，此类指令可以存储在任何有形的存储器设备中，例如半导体、磁性、光学或其他的存储器设备，并且可以利用任何的通信技术进行传输，例如光、红外、微波或其他的传输技术。
可以预期，此类计算机程序产品可以按照具有印刷或电子文档(例如，压缩打包软件)与计算机系统一起预加载(例如，在系统ROM或固定磁盘)的可移动介质分发，或者通过网络(例如，互联网或万维网)从服务器或电子公告栏分发。当然，本发明的一些实施例可以被实现为软件(例如，计算机程序产品)和硬件两者的组合。本发明的其他实施例被整体实现为硬件或者整体实现为软件(例如，软件程序产品)。
在前述描述中，某些步骤或过程可以在特定服务器上执行或者作为特定引擎的一部分。这些描述仅是例示性的，因为特定步骤可以在各种硬件设备上执行，包括但不限于服务器系统和/或移动设备。同样地，要执行的特定步骤对在何处划分可以不同，应当理解不进行划分或者不同的划分在本发明的范围内。此外，对用于描述计算机系统处理的“模块”和/或其他术语的使用旨在是可互换的并且旨在表示其中可以执行功能的逻辑或电路。

Claims (24)

1.一种用于在通信系统中向包处理程序核心发送包的计算系统，其包括：
处理器；和
存储器，所述存储器耦合至所述处理器并且包括计算机可读指令，当所述计算机可读指令由所述处理器执行时促使所述处理器：
接收创建会话的请求，其中所述请求和订户相对应，为所述会话分配下游标识符和上游标识符，
接收包括所述下游标识符或所述上游标识符的数据包，确定所述数据包是否需要代理服务，以及
当确定所述数据包不需要所述代理服务时：
将所述下游标识符和所述上游标识符与会话标识符进行关联，所述会话标识符唯一地标识所述会话，
基于所述下游标识符或所述上游标识符识别与所述数据包相关联的所述会话标识符，以及
基于所述会话标识符将所述数据包路由至包处理程序核心，以及
当确定所述数据包需要代理服务时：
识别用于所述数据包的代理服务，
将所述数据包路由至所述代理服务，
将所述包处理程序核心的标识符与所述下游标识符进行关联；以及
基于所述包处理程序核心的所述标识符将所述数据包路由至所述包处理程序核心。
2.根据权利要求1所述的计算系统，其中所述上游标识符包括隧道端点标识符TEID或加密秘钥。
3.根据权利要求2所述的计算系统，其中进一步促使所述处理器利用所述加密秘钥来加密或解密所述数据包。
4.根据权利要求1所述的计算系统，其中所述下游标识符包括用户设备UE互联网协议IP地址或TEID。
5.根据权利要求1所述的计算系统，其中上游标识符和下游标识符共享公共值。
6.根据权利要求5所述的计算系统，其中所述公共值包括所述上游标识符和下游标识符的前24位部分。
7.根据权利要求1所述的计算系统，其中进一步促使所述处理器对所述会话应用散列算法以确定所述包处理程序核心。
8.一种用于在通信系统中向包处理程序核心发送包的方法，其包括：
通过计算设备接收创建会话的请求，其中所述请求和订户相对应，
通过所述计算设备为所述会话分配下游标识符和上游标识符，
通过所述计算设备接收包括所述下游标识符或所述上游标识符的数据包，
确定所述数据包是否需要代理服务，以及
当确定所述数据包不需要所述代理服务时：
通过所述计算设备将所述下游标识符和所述上游标识符与会话标识符进行关联，所述会话标识符唯一地标识所述会话，
通过所述计算设备基于所述下游标识符或所述上游标识符识别与所述数据包相关联的所述会话标识符，以及
通过所述计算设备基于所述会话标识符将所述数据包路由至包处理程序核心，以及
当确定所述数据包需要代理服务时：
识别用于所述数据包的代理服务，
将所述数据包路由至所述代理服务，
将所述包处理程序核心的标识符与所述下游标识符进行关联；以及
基于所述包处理程序核心的所述标识符将所述数据包路由至所述包处理程序核心。
9.根据权利要求8所述的方法，其中所述上游标识符包括隧道端点标识符TEID或加密秘钥。
10.根据权利要求8所述的方法，进一步包括以下一项或多项：利用所述加密秘钥来加密或解密所述数据包。
11.根据权利要求10所述的方法，其中所述下游标识符包括用户设备UE互联网协议IP地址或TEID。
12.根据权利要求10所述的方法，其中上游标识符和下游标识符共享公共值。
13.根据权利要求12所述的方法，其中所述公共值包括所述上游标识符和下游标识符的前24位部分。
14.根据权利要求10所述的方法，进一步包括：对所述会话应用散列算法以确定所述包处理程序核心。
15.一种用于在通信系统中向包处理程序核心发送包的计算系统，其包括：
处理器；和
存储器，所述存储器耦合至所述处理器并且包括计算机可读指令，当所述计算机可读指令由所述处理器执行时促使所述处理器：
接收创建会话的请求，其中所述请求和订户相对应，
为所述会话分配下游标识符和上游标识符，
将所述下游标识符和所述上游标识符与会话标识符进行关联，所述会话标识符唯一地标识所述会话，
接收包括所述下游标识符或所述上游标识符的数据包，
确定所述数据包需要代理服务，
确定所述数据包是否包括所述下游标识符或所述上游标识符，以及
当所述数据包包括所述上游标识符时，基于所述上游标识符识别与所述数据包相关联的所述会话标识符，并且基于所述会话标识符将所述数据包路由至包处理程序核心，
当所述数据包包括所述下游标识符时，基于所述下游标识符将所述数据包路由至所述包处理程序核心。
16.根据权利要求15所述的计算系统，其中所述下游标识符包括UE环回IP地址。
17.根据权利要求15所述的计算系统，其中所述上游标识符包括TEID。
18.根据权利要求15所述的计算系统，其中系统启动的代理流量通过利用分区多协议标签交换(“MPLS”)标签空间与下游订户流量进行区分。
19.根据权利要求18所述的计算系统，其中所述MPLS标签空间被分成UE池地址域和代理环回地址域。
20.一种用于在通信系统中向包处理程序核心发送包的方法，其包括：
通过计算设备接收创建会话的请求，其中所述请求和订户相对应，
通过所述计算设备为所述会话分配下游标识符和上游标识符，
通过所述计算设备将所述下游标识符和所述上游标识符与会话标识符进行关联，所述会话标识符唯一地标识所述会话，
通过所述计算设备接收包括所述下游标识符或所述上游标识符的数据包，
通过所述计算设备确定所述数据包需要代理服务，
通过所述计算设备确定所述数据包是否包括所述下游标识符或所述上游标识符，以及
当所述数据包包括所述上游标识符时，基于所述上游标识符识别与所述数据包相关联的所述会话标识符，并且基于所述会话标识符将所述数据包路由至包处理程序核心，
当所述数据包包括所述下游标识符时，基于所述下游标识符将所述数据包路由至所述包处理程序核心。
21.根据权利要求20所述的方法，其中所述下游标识符包括UE环回IP地址。
22.根据权利要求20所述的方法，其中所述上游标识符包括TEID。
23.根据权利要求20所述的方法，其中系统启动的代理流量通过利用分区多协议标签交换(“MPLS”)标签空间与下游订户流量进行区分。
24.根据权利要求23所述的方法，其中所述MPLS空间被分成UE池地址域和代理环回地址域。
CN201880014570.2A 2017-01-25 2018-01-25 通信系统中的计算系统和方法 Active CN110383792B (zh)

Applications Claiming Priority (3)

Application Number Priority Date Filing Date Title
US201762450162P 2017-01-25 2017-01-25
US62/450,162 2017-01-25
PCT/US2018/015276 WO2018140621A1 (en) 2017-01-25 2018-01-25 Load balancing of wireless subscriber packet processing over multiple packet processing cores

Publications (2)

Publication Number Publication Date
CN110383792A CN110383792A (zh) 2019-10-25
CN110383792B true CN110383792B (zh) 2022-05-24

Family

ID=61231311

Family Applications (1)

Application Number Title Priority Date Filing Date
CN201880014570.2A Active CN110383792B (zh) 2017-01-25 2018-01-25 通信系统中的计算系统和方法

Country Status (6)

Country Link
US (1) US10321360B2 (zh)
EP (1) EP3574629B1 (zh)
JP (1) JP7100061B2 (zh)
KR (1) KR102455902B1 (zh)
CN (1) CN110383792B (zh)
WO (1) WO2018140621A1 (zh)

Families Citing this family (7)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN109787912A (zh) * 2019-03-04 2019-05-21 南京邮电大学 一种dpdk环境下基于nat的负载均衡方法
US11444877B2 (en) * 2019-03-18 2022-09-13 At&T Intellectual Property I, L.P. Packet flow identification with reduced decode operations
KR20200112439A (ko) * 2019-03-22 2020-10-05 삼성전자주식회사 멀티 코어를 포함하는 전자 장치 및 이의 패킷 처리를 위한 방법
CN109995672B (zh) * 2019-03-22 2022-03-25 烽火通信科技股份有限公司 基于dpdk的虚拟家庭网关带宽调度控制方法及系统
CN112042158A (zh) 2019-04-04 2020-12-04 柏思科技有限公司 通过多个隧道发送分组的方法和系统
US11425043B2 (en) * 2020-06-16 2022-08-23 T-Mobile Usa, Inc. Duplex load balancing for massive IoT applications
US20220394017A1 (en) * 2021-06-07 2022-12-08 Vmware, Inc. Ipsec processing on multi-core systems

Citations (2)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN102292955A (zh) * 2008-11-25 2011-12-21 思杰系统有限公司 用于负载平衡实时流传输协议的系统和方法
CN105981345A (zh) * 2013-09-27 2016-09-28 瑞典爱立信有限公司 Wi-fi/分组核心网接入的合法侦听

Family Cites Families (5)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US7003574B1 (en) * 2000-11-01 2006-02-21 Microsoft Corporation Session load balancing and use of VIP as source address for inter-cluster traffic through the use of a session identifier
US8079077B2 (en) 2006-08-08 2011-12-13 A10 Networks, Inc. System and method for distributed multi-processing security gateway
US8560708B2 (en) * 2010-06-29 2013-10-15 Alcatel Lucent Method and apparatus for allocating bundles of sessions in a network element
EP2843885A1 (en) * 2013-08-29 2015-03-04 NTT DoCoMo, Inc. Apparatus and method for implementing a packet gateway user plane
US9854051B2 (en) 2014-04-25 2017-12-26 Wilmerding Communications Llc Using proxy devices as dynamic data relays

Patent Citations (2)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN102292955A (zh) * 2008-11-25 2011-12-21 思杰系统有限公司 用于负载平衡实时流传输协议的系统和方法
CN105981345A (zh) * 2013-09-27 2016-09-28 瑞典爱立信有限公司 Wi-fi/分组核心网接入的合法侦听

Non-Patent Citations (3)

* Cited by examiner, † Cited by third party
Title
3GPP.3GPP TS 23.401 V13.9.0.《3rd Generation Partnership Project *
General Packet Radio Service (GPRS) enhancements for Evolved Universal Terrestrial Radio Access Network (E-UTRAN) access(Release 13)》.2016, *
Technical Specification Group Services and System Aspects *

Also Published As

Publication number Publication date
EP3574629A1 (en) 2019-12-04
KR102455902B1 (ko) 2022-10-17
US10321360B2 (en) 2019-06-11
JP7100061B2 (ja) 2022-07-12
US20180213440A1 (en) 2018-07-26
EP3574629B1 (en) 2022-12-21
KR20190107709A (ko) 2019-09-20
JP2020507289A (ja) 2020-03-05
CN110383792A (zh) 2019-10-25
WO2018140621A1 (en) 2018-08-02

Similar Documents

Publication Publication Date Title
CN110383792B (zh) 通信系统中的计算系统和方法
US11831544B2 (en) Virtual layer-2 network
CN108886825B (zh) 分布式软件定义无线分组核心系统
US12010173B2 (en) Class-based queueing for scalable multi-tenant RDMA traffic
US10237230B2 (en) Method and system for inspecting network traffic between end points of a zone
CN104521249A (zh) 方法和设备
US11032199B2 (en) Methods and apparatus for providing traffic forwarder via dynamic overlay network
CN113395212B (zh) 网络装置及其操作方法和非暂时性计算机可读介质
WO2022146466A1 (en) Class-based queueing for scalable multi-tenant rdma traffic
US20050237955A1 (en) Method and system for connecting manipulation equipment between operator&#39;s premises and the internet
CN116724546A (zh) 用于融合以太网上的RDMA（RoCE）云规模多租赁
US20240291889A1 (en) CLOUD SCALE MULTI-TENANCY FOR RDMA OVER CONVERGED ETHERNET (RoCE)
US20240323255A1 (en) Class-based queueing for scalable multi-tenant rdma traffic
EP4272408A1 (en) Cloud scale multi-tenancy for rdma over converged ethernet (roce)
WO2022262951A1 (en) Coordination of segmented service chains

Legal Events

Date Code Title Description
PB01 Publication
PB01 Publication
SE01 Entry into force of request for substantive examination
SE01 Entry into force of request for substantive examination
REG Reference to a national code

Ref country code: HK

Ref legal event code: DE

Ref document number: 40015071

Country of ref document: HK

TA01 Transfer of patent application right
TA01 Transfer of patent application right

Effective date of registration: 20200911

Address after: Washington State

Applicant after: MICROSOFT TECHNOLOGY LICENSING, LLC

Address before: Massachusetts, USA

Applicant before: AFFIRMED NETWORKS, Inc.

GR01 Patent grant
GR01 Patent grant