CN111837371A - 基于增强mptcp的应用移动性 - Google Patents
基于增强mptcp的应用移动性 Download PDFInfo
- Publication number
- CN111837371A CN111837371A CN201980018379.XA CN201980018379A CN111837371A CN 111837371 A CN111837371 A CN 111837371A CN 201980018379 A CN201980018379 A CN 201980018379A CN 111837371 A CN111837371 A CN 111837371A
- Authority
- CN
- China
- Prior art keywords
- mptcp
- wtru
- host
- app
- message
- 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.)
- Pending
Links
Images
Classifications
-
- 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/24—Traffic characterised by specific attributes, e.g. priority or QoS
-
- 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/24—Multipath
-
- 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/19—Flow control; Congestion control at layers above the network layer
- H04L47/193—Flow control; Congestion control at layers above the network layer at the transport layer, e.g. TCP related
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
- H04L69/00—Network arrangements, protocols or services independent of the application payload and not provided for in the other groups of this subclass
- H04L69/14—Multichannel or multilink protocols
Landscapes
- Engineering & Computer Science (AREA)
- Computer Networks & Wireless Communication (AREA)
- Signal Processing (AREA)
- Computer Security & Cryptography (AREA)
- Mobile Radio Communication Systems (AREA)
- Data Exchanges In Wide-Area Networks (AREA)
Abstract
在WTRU上运行的客户端应用被配置成通过TCP会话与在WTRU上运行的MPTCP栈传送数据业务。所述数据业务通过与第一移动边缘(ME)主机设备的第一MPTCP子流而被与服务应用进行交换。所述WTRU被锚定到第二ME锚节点。所述WTRU从第二ME主机设备接收第一消息,该第一消息指示所述WTRU应该加入与所述第二ME主机设备的第二MPTCP子流。所述WTRU响应于所述第一消息而加入所述第二MPTCP子流,其中所述第二子流被配置成不交换数据业务。所述WTRU从所述第二ME主机设备接收配置所述第二MPTCP子流以交换数据业务的第二消息。所述WTRU通过与所述第二ME主机设备的所述第二MPTCP子流来与所述服务器应用交换所述数据业务。
Description
相关申请的交叉引用
本申请要求在2018年1月26日提交的美国临时专利申请No.62/622,586的权益,其内容通过引用结合于此。
背景技术
随着无线协议和标准的进步,新的性能目标可能由新的使用情况引起。例如,在5G无线通信中,可能需要超可靠和低延时通信(URLLC)。示例使用情况可以包括执行协作和安全功能的自主交通工具、智能网格的监视和控制、用于远程医疗过程的触觉反馈、无人驾驶航空交通工具的控制和协调、机器人技术、工业自动化等。因此,可能期望创建和/或改进各种能力,诸如在设备正在移动时维持URLLC连接。
发明内容
方法、系统、设备和WTRU,其被配置成处理该WTRU的移动。在WTRU上运行的客户端应用(application)被配置成通过TCP会话与在所述WTRU上运行的MPTCP栈传送数据业务。该数据业务通过与第一移动边缘(ME)主机设备的第一MPTCP子流而被与服务器应用进行交换。所述WTRU被锚定到第二ME锚节点。所述WTRU从第二ME主机设备接收第一消息,该第一消息指示所述WTRU应该加入与所述第二ME主机设备的第二MPTCP子流。所述WTRU响应于所述第一消息而加入所述第二MPTCP子流,其中所述第二子流被配置成不交换数据业务。所述WTRU从所述第二ME主机设备接收配置所述第二MPTCP子流以交换数据业务的第二消息。所述WTRU通过与所述第二ME主机设备的所述第二MPTCP子流而与所述服务器应用交换所述数据业务。
附图说明
从以下结合附图以示例方式给出的详细描述中,可以获得更详细的理解,其中图中的相同参考标号指示相同元素,且其中:
图1A是示出了可以实施所公开的一个或多个实施例的示例性通信系统的系统示意图;
图1B是示出了根据实施例的可以在图1A所示的通信系统内部使用的示例性无线发射/接收单元(WTRU)的系统示意图;
图1C是示出了根据实施例的可以在图1A所示的通信系统内部使用的示例性无线电接入网络(RAN)和示例性核心网络(CN)的系统示意图;
图1D是示出了根据实施例的可以在图1A所示的通信系统内部使用的另一个示例性RAN和另一个示例性CN的系统示意图;
图2是示出了示例标准TCP协议栈和示例标准MPTCP协议栈的框图;
图3是示出了简化的示例MEC拓扑的框图;
图4A是示出了在网络中的ME App移动性期间失去连接性的示例情形的消息序列图;
图4B是继续说明其中在图4A的网络中的ME App移动性期间失去连接性的示例情形的消息序列图;
图5A是示出了MPTCP栈移动性方法的示例全局视图的消息序列图;
图5B是继续说明图5A的MPTCP栈移动性方法的示例全局视图的消息序列图;
图6是示出了示例移动性订阅和触发的消息序列图;
图7A是示出了示例MPTCP会话转移(session transfer)准备阶段的消息序列图;
图7B是继续说明图7A的示例MPTCP会话转移准备阶段的消息序列图;
图8A是示出了示例MPTCP会话转移完成阶段的消息序列图;
图8B是继续说明图8A的示例MPTCP会话转移完成阶段的消息序列图;
图9是示出了示例性的修改的子流优先级(MP_PRIO)选项的位图;
图10是示出了示例性的修改的加入连接(MP_JOIN)选项的位图;
图11是示出了示例性的修改的加入连接(MP_JOIN)选项的位图;
图12A是示出了示例MPTCP会话转移准备阶段的消息序列图;
图12B是继续说明图12A的示例MPTCP会话转移准备阶段的消息序列图;
图13A是示出了示例MPTCP会话转移完成阶段的消息序列图;
图13B是继续说明图13A的示例MPTCP会话转移完成阶段的消息序列图;
图14是示出了示例性的修改的加入连接(MP_JOIN)选项的位图;
图15是示出了示例性的修改的加入连接(MP_JOIN)选项的位图;
图16是示出了示例性修改添加地址(ADD_ADDR)选项的位图;
图17A是一消息序列图,其示出了WTRU发起的PRE_ALLOCATED子流创建的示例网络地址转换(NAT)使用情况;以及
图17B是一消息序列图,其继续说明图17A中WTRU发起的PRE_ALLOCATED子流创建的示例网络地址转换(NAT)使用情况。
具体实施方式
图1A是示出了可以实施所公开的一个或多个实施例的示例性通信系统100的示意图。该通信系统100可以是为多个无线用户提供诸如语音、数据、视频、消息传递、广播等内容的多址接入系统。该通信系统100可以通过共享包括无线带宽在内的系统资源而使多个无线用户能够访问此类内容。举例来说,通信系统100可以使用一种或多种信道接入方法,例如码分多址(CDMA)、时分多址(TDMA)、频分多址(FDMA)、正交FDMA(OFDMA)、单载波FDMA(SC-FDMA)、零尾唯一字DFT-扩展OFDM(ZT UW DTS-s OFDM)、唯一字OFDM(UW-OFDM)、资源块过滤OFDM以及滤波器组多载波(FBMC)等等。
如图1A所示,通信系统100可以包括无线发射/接收单元(WTRU)102a、102b、102c、102d、RAN 104/113、核心网络(CN)106/115、公共交换电话网络(PSTN)108、因特网110以及其他网络112,然而应该了解,所公开的实施例设想了任意数量的WTRU、基站、网络和/或网络部件。所述CN可以代表下一代核心(NGC)网络,诸如使用新无线电(NR)的5G系统。WTRU102a、102b、102c、102d每一者可以是被配置成在无线环境中工作和/或通信的任何类型的设备。举例来说,WTRU 102a、102b、102c、102d任何一者都可以被称为―站”和/或―STA”,其可以被配置成发射和/或接收无线信号,并且可以包括用户设备(UE)、移动站、固定或移动订户单元、基于签约的单元、寻呼机、蜂窝电话、个人数字助理(PDA)、智能电话、膝上型计算机、上网本、个人计算机、无线传感器、热点或Mi-Fi设备、物联网(IoT)设备、手表或其他可穿戴设备、头戴显示器(HMD)、运载工具、无人机、医疗设备和应用(例如远程手术)、工业设备和应用(例如机器人和/或在工业和/或自动处理链环境中工作的其他无线设备)、消费类电子设备、以及在商业和/或工业无线网络上工作的设备等等。WTRU 102a、102b、102c、102d中的任何一者可被可交换地称为UE。
所述通信系统100还可以包括基站114a和/或基站114b。基站114a、114b的每一者可以是被配置成通过以无线方式与WTRU 102a、102b、102c、102d中的至少一者无线对接来促使其接入一个或多个通信网络(例如CN 106/115、因特网110、和/或其他网络112)的任何类型的设备。例如,基站114a、114b可以是基地收发信台(BTS)、节点B、e节点B、家庭节点B、家庭e节点B、gNB、新无线电(NR)节点B、站点控制器、接入点(AP)、以及无线路由器等等。虽然基站114a、114b的每一者都被描述成了单个部件,然而应该了解,基站114a、114b可以包括任何数量的互连基站和/或网络部件。
基站114a可以是RAN 104/113的一部分,并且该RAN还可以包括其他基站和/或网络部件(未显示),例如基站控制器(BSC)、无线电网络控制器(RNC)、中继节点等等。基站114a和/或基站114b可被配置成在名为小区(未显示)的一个或多个载波频率上发射和/或接收无线信号。这些频率可以处于授权频谱、无授权频谱或是授权与无授权频谱的组合之中。小区可以为相对固定或者有可能随时间变化的特定地理区域提供无线服务覆盖。小区可被进一步分成小区扇区。例如,与基站114a相关联的小区可被分为三个扇区。由此,在一个实施例中,基站114a可以包括三个收发信机,即,每一个收发信机都对应于小区的一个扇区。在实施例中,基站114a可以使用多输入多输出(MIMO)技术,并且可以为小区的每一个扇区使用多个收发信机。例如,通过使用波束成形,可以在期望的空间方向上发射和/或接收信号。
基站114a、114b可以通过空中接口116来与WTRU 102a、102b、102c、102d中的一者或多者进行通信,其中所述空中接口可以是任何适当的无线通信链路(例如射频(RF)、微波、厘米波、毫米波、红外线(IR)、紫外线(UV)、可见光等等)。空中接口116可以使用任何适当的无线电接入技术(RAT)来建立。
更具体地说,如上所述,通信系统100可以是多址接入系统,并且可以使用一种或多种信道接入方案,例如CDMA、TDMA、FDMA、OFDMA以及SC-FDMA等等。例如,RAN 104/113中的基站114a与WTRU 102a、102b、102c可以实施某种无线电技术,例如通用移动电信系统(UMTS)陆地无线电接入(UTRA),其中所述技术可以使用宽带CDMA(WCDMA)来建立空中接口115/116/117。WCDMA可以包括如高速分组接入(HSPA)和/或演进型HSPA(HSPA+)之类的通信协议。HSPA可以包括高速下行链路(DL)分组接入(HSDPA)和/或高速UL分组接入(HSUPA)。
在实施例中,基站114a和WTRU 102a、102b、102c可以实施某种无线电技术,例如演进型UMTS陆地无线电接入(E-UTRA),其中所述技术可以使用长期演进(LTE)和/或先进LTE(LTE-A)和/或先进LTE Pro(LTE-A Pro)来建立空中接口116。
在实施例中,基站114a和WTRU 102a、102b、102c可以实施某种可以使用新无线电(NR)建立空中接口116的无线电技术,例如NR无线电接入。
在实施例中,基站114a和WTRU 102a、102b、102c可以实施多种无线电接入技术。例如,基站114a和WTRU 102a、102b、102c可以共同实施LTE无线电接入和NR无线电接入(例如使用双连接(DC)原理)。由此,WTRU 102a、102b、102c使用的空中接口可以通过多种类型的无线电接入技术和/或向/从多种类型的基站(例如,eNB和gNB)发送的传输来表征。
在其他实施例中,基站114a和WTRU 102a、102b、102c可以实施以下的无线电技术,例如IEEE 802.11(即,无线高保真(WiFi))、IEEE 802.16(即,全球微波接入互操作性(WiMAX))、CDMA2000、CDMA2000 1X、CDMA2000EV-DO、临时标准2000(IS-2000)、临时标准95(IS-95)、临时标准856(IS-856)、全球移动通信系统(GSM)、用于GSM演进的增强数据速率(EDGE)、以及GSM EDGE(GERAN)等等。
图1A中的基站114b可以例如是无线路由器、家庭节点B、家庭e节点B或接入点,并且可以使用任何适当的RAT来促成局部区域中的无线连接,例如营业场所、住宅、运载工具、校园、工业设施、空中走廊(例如供无人机使用)以及道路等等。在一个实施例中,基站114b与WTRU 102c、102d可以通过实施IEEE 802.11之类的无线电技术来建立无线局域网(WLAN)。在实施例中,基站114b与WTRU 102c、102d可以通过实施IEEE 802.15之类的无线电技术来建立无线个人局域网(WPAN)。在再一个实施例中,基站114b和WTRU 102c、102d可通过使用基于蜂窝的RAT(例如WCDMA、CDMA2000、GSM、LTE、LTE-A、LTE-A Pro、NR等等)来建立微微小区或毫微微小区。如图1A所示,基站114b可以直连到因特网110。由此,基站114b不需要经由CN 106/115来接入因特网110。
RAN 104/113可以与CN 106/115进行通信,所述CN可以是被配置成向WTRU 102a、102b、102c、102d的一者或多者提供语音、数据、应用和/或借助网际协议语音(VoIP)服务的任何类型的网络。该数据可以具有不同的服务质量(QoS)需求,例如不同的吞吐量需求、延时需求、容错需求、可靠性需求、数据吞吐量需求、以及移动性需求等等。CN 106/115可以提供呼叫控制、记账服务、基于移动位置的服务、预付费呼叫、因特网连接、视频分发等等,和/或可以执行用户认证之类的高级安全功能。虽然在图1A中没有显示,然而应该了解,RAN104/113和/或CN 106/115可以直接或间接地和其他那些与RAN 104/113使用相同RAT或不同RAT的RAN进行通信。例如,除了与使用NR无线电技术的RAN 104/113相连之外,CN 106/115还可以与使用GSM、UMTS、CDMA 2000、WiMAX、E-UTRA或WiFi无线电技术的别的RAN(未显示)通信。
CN 106/115还可以充当供WTRU 102a、102b、102c、102d接入PSTN 108、因特网110和/或其他网络112的网关。PSTN 108可以包括提供简易老式电话服务(POTS)的电路交换电话网络。因特网110可以包括使用了公共通信协议(例如传输控制协议/网际协议(TCP/IP)网际协议族中的TCP、用户数据报协议(UDP)和/或IP)的全球性互联计算机网络设备系统。所述网络112可以包括由其他服务提供方拥有和/或运营的有线或无线通信网络。例如,所述网络112可以包括与一个或多个RAN相连的另一个CN,其中所述一个或多个RAN可以与RAN104/113使用相同RAT或不同RAT。
通信系统100中的一些或所有WTRU 102a、102b、102c、102d可以包括多模能力(例如WTRU 102a、102b、102c、102d可以包括在不同无线链路上与不同无线网络通信的多个收发信机)。例如,图1A所示的WTRU 102c可被配置成与使用基于蜂窝的无线电技术的基站114a通信,以及与可以使用IEEE 802无线电技术的基站114b通信。
图1B是示出了示例性WTRU 102的系统示意图。如图1B所示,WTRU 102可以包括处理器118、收发信机120、发射/接收部件122、扬声器/麦克风124、数字键盘126、显示器/触摸板128、不可移除存储器130、可移除存储器132、电源134、全球定位系统(GPS)芯片组136和/或周边设备138。应该了解的是,在保持符合实施例的同时,WTRU 102还可以包括前述部件的任何子组合。
处理器118可以是通用处理器、专用处理器、常规处理器、数字信号处理器(DSP)、多个微处理器、与DSP核心关联的一个或多个微处理器、控制器、微控制器、专用集成电路(ASIC)、现场可编程门阵列(FPGA)电路、其他任何类型的集成电路(IC)以及状态机等等。处理器118可以执行信号编码、数据处理、功率控制、输入/输出处理、和/或其他任何能使WTRU102在无线环境中工作的功能。处理器118可以耦合至收发信机120,收发信机120可以耦合至发射/接收部件122。虽然图1B将处理器118和收发信机120描述成单独组件,然而应该了解,处理器118和收发信机120也可以一起集成在一电子组件或芯片中。
发射/接收部件122可被配置成经由空中接口116来发射或接收去往或来自基站(例如,基站114a)的信号。举个例子,在一个实施例中,发射/接收部件122可以是被配置成发射和/或接收RF信号的天线。作为示例,在另一实施例中,发射/接收部件122可以是被配置成发射和/或接收IR、UV或可见光信号的放射器/检测器。在再一个实施例中,发射/接收部件122可被配置成发射和/或接收RF和光信号。应该了解的是,发射/接收部件122可以被配置成发射和/或接收无线信号的任何组合。
虽然在图1B中将发射/接收部件122描述成是单个部件,但是WTRU 102可以包括任何数量的发射/接收部件122。更具体地说,WTRU 102可以使用MIMO技术。由此,在一个实施例中,WTRU 102可以包括两个或更多个通过空中接口116来发射和接收无线信号的发射/接收部件122(例如多个天线)。
收发信机120可被配置成对发射/接收部件122所要传送的信号进行调制,以及对发射/接收部件122接收的信号进行解调。如上所述,WTRU 102可以具有多模能力。因此,收发信机120可以包括允许WTRU 102借助多种RAT(例如NR和IEEE 802.11)来进行通信的多个收发信机。
WTRU 102的处理器118可以耦合到扬声器/麦克风124、数字键盘126和/或显示器/触摸板128(例如液晶显示器(LCD)显示单元或有机发光二极管(OLED)显示单元),并且可以接收来自这些部件的用户输入数据。处理器118还可以向扬声器/麦克风124、键盘126和/或显示器/触摸板128输出用户数据。此外,处理器118可以从诸如不可移除存储器130和/或可移除存储器132之类的任何适当的存储器中存取信息,以及将信息存入这些存储器。不可移除存储器130可以包括随机存取存储器(RAM)、只读存储器(ROM)、硬盘或是其他任何类型的记忆存储设备。可移除存储器132可以包括订户身份模块(SIM)卡、记忆棒、安全数字(SD)记忆卡等等。在其他实施例中,处理器118可以从那些并非实际位于WTRU 102的存储器存取信息,以及将数据存入这些存储器,作为示例,此类存储器可以位于服务器或家庭计算机(未显示)。
处理器118可以接收来自电源134的电力,并且可被配置分发和/或控制用于WTRU102中的其他组件的电力。电源134可以是为WTRU 102供电的任何适当设备。例如,电源134可以包括一个或多个干电池组(如镍镉(Ni-Cd)、镍锌(Ni-Zn)、镍氢(NiMH)、锂离子(Li-ion)等等)、太阳能电池以及燃料电池等等。
处理器118还可以耦合到GPS芯片组136,该GPS芯片组可被配置成提供与WTRU 102的当前位置相关的位置信息(例如经度和纬度)。作为来自GPS芯片组136的信息的补充或替换,WTRU 102可以经由空中接口116接收来自基站(例如基站114a、114b)的位置信息,和/或根据从两个或更多个附近基站接收的信号定时来确定其位置。应该了解的是,在保持符合实施例的同时,WTRU 102可以借助任何适当的定位方法来获取位置信息。
处理器118还可以耦合到其他周边设备138,其中所述周边设备可以包括提供附加特征、功能和/或有线或无线连接的一个或多个软件和/或硬件模块。例如,所述周边设备138可以包括加速度计、电子指南针、卫星收发信机、数码相机(用于照片和/或视频)、通用串行总线(USB)端口、振动设备、电视收发信机、免提耳机、模块、调频(FM)无线电单元、数字音乐播放器、媒体播放器、视频游戏机模块、因特网浏览器、虚拟现实和/或增强现实(VR/AR)设备、以及活动跟踪器等等。所述周边设备138可以包括一个或多个传感器,所述传感器可以是以下的一者或多者:陀螺仪、加速度计、霍尔效应传感器、磁强计、方位传感器、邻近传感器、温度传感器、时间传感器、地理位置传感器、高度计、光传感器、触摸传感器、磁力计、气压计、手势传感器、生物测定传感器和/或湿度传感器等。
WTRU 102可以包括全双工无线电设备,其中对于该无线电设备来说,一些或所有信号(例如与用于UL(例如对传输而言)和下行链路(例如对接收而言)的特定子帧相关联)的接收或传输可以是并发和/或同时的。全双工无线电设备可以包括借助于硬件(例如扼流线圈)或是凭借处理器(例如单独的处理器(未显示)或是凭借处理器118)的信号处理来减小和/或基本消除自干扰的干扰管理单元139。在实施例中,WTRU 102可以包括传送和接收一些或所有信号(例如与用于UL(例如对传输而言)或下行链路(例如对接收而言)的特定子帧相关联)的半双工无线电设备。
图1C是示出了根据实施例的RAN 104和CN 106的系统示意图。如上所述,RAN 104可以通过空中接口116使用E-UTRA无线电技术来与WTRU 102a、102b、102c进行通信。所述RAN 104还可以与CN 106进行通信。
RAN 104可以包括e节点B 160a、160b、160c,然而应该了解,在保持符合实施例的同时,RAN 104可以包括任何数量的e节点B。e节点B 160a、160b、160c每一者都可以包括通过空中接口116与WTRU 102a、102b、102c通信的一个或多个收发信机。在一个实施例中,e节点B 160a、160b、160c可以实施MIMO技术。由此,举例来说,e节点B 160a可以使用多个天线来向WTRU 102a发射无线信号,和/或接收来自WTRU 102a的无线信号。
e节点B 160a、160b、160c每一者都可以关联于一个特定小区(未显示),并且可被配置成处理无线电资源管理决策、切换决策、UL和/或DL中的用户调度等等。如图1C所示,e节点B 160a、160b、160c彼此可以通过X2接口进行通信。
图1C所示的CN 106可以包括移动性管理实体(MME)162、服务网关(SGW)164以及分组数据网络(PDN)网关(或PGW)166。虽然每一前述部件都被描述成是CN 106的一部分,然而应该了解,这其中的任一部件都可以由CN运营商之外的实体拥有和/或运营。
MME 162可以经由S1接口连接到RAN 104中的e节点B 162a、162b、162c的每一者,并且可以充当控制节点。例如,MME 162可以负责认证WTRU 102a、102b、102c的用户,执行承载激活/去激活处理,以及在WTRU 102a、102b、102c的初始附着过程中选择特定的服务网关等等。MME 162可以提供用于在RAN 104与使用其他无线电技术(例如GSM和/或WCDMA)的其他RAN(未显示)之间进行切换的控制平面功能。
SGW 164可以经由S1接口连接到RAN 104中的e节点B 160a、160b、160c的每一者。SGW 164通常可以路由和转发去往/来自WTRU 102a、102b、102c的用户数据分组。并且,SGW164还可以执行其他功能,例如在eNB间的切换过程中锚定用户平面,在DL数据可供WTRU102a、102b、102c使用时触发寻呼处理,以及管理并存储WTRU 102a、102b、102c的上下文等等。
SGW 164可以连接到PGW 146,所述PGW可以为WTRU 102a、102b、102c提供分组交换网络(例如因特网110)接入,以便促成WTRU 102a、102b、102c与启用IP的设备之间的通信。
CN 106可以促成与其他网络的通信。例如,CN 106可以为WTRU 102a、102b、102c提供对电路交换网络(例如PSTN 108)的接入,以便促成WTRU 102a、102b、102c与传统的陆线通信设备之间的通信。例如,CN 106可以包括IP网关(例如IP多媒体子系统(IMS)服务器)或与之进行通信,并且该IP网关可以充当CN 106与PSTN 108之间的接口。此外,CN 106可以为WTRU 102a、102b、102c提供针对所述其他网络112的接入,其中该网络可以包括其他服务提供方拥有和/或运营的其他有线和/或无线网络。
虽然在图1A-1D中将WTRU描述成了无线终端,然而应该想到的是,在某些代表性实施例中,此类终端与通信网络可以使用(例如临时或永久性)有线通信接口。
在代表性实施例中,所述其他网络112可以是WLAN。
采用基础架构基本服务集(BSS)模式的WLAN可以具有用于所述BSS的接入点(AP)以及与所述AP相关联的一个或多个站(STA)。所述AP可以访问或是对接到分布式系统(DS)或是将业务量送入和/或送出BSS的别的类型的有线/无线网络。源于BSS外部且去往STA的业务量可以通过AP到达并被递送至STA。源自STA且去往BSS外部的目的地的业务量可被发送至AP,以便递送到相应的目的地。处于BSS内部的STA之间的业务量可以通过AP来发送,例如在源STA可以向AP发送业务量并且AP可以将业务量递送至目的地STA的情况下。处于BSS内部的STA之间的业务量可被认为和/或称为点到点业务量。所述点到点业务量可以在源与目的地STA之间(例如在其间直接)用直接链路建立(DLS)来发送。在某些代表性实施例中,DLS可以使用802.11e DLS或802.11z通道化DLS(TDLS))。举例来说,使用独立BSS(IBSS)模式的WLAN不具有AP,并且处于所述IBSS内部或是使用所述IBSS的STA(例如所有STA)彼此可以直接通信。在这里,IBSS通信模式有时可被称为―自组织(Ad-hoc)”通信模式。
在使用802.11ac基础设施工作模式或类似的工作模式时,AP可以在固定信道(例如主信道)上传送信标。所述主信道可以具有固定宽度(例如20MHz的带宽)或是经由信令动态设置的宽度。主信道可以是BSS的工作信道,并且可被STA用来与AP建立连接。在某些代表性实施例中,所实施的可以是具有冲突避免的载波感测多址接入(CSMA/CA)(例如在802.11系统中)。对于CSMA/CA来说,包括AP在内的STA(例如每一个STA)可以感测主信道。如果特定STA感测到/检测到和/或确定主信道繁忙,那么所述特定STA可以回退。在指定的BSS中,在任何指定时间都有一个STA(例如只有一个站)进行传输。
高吞吐量(HT)STA可以使用宽度为40MHz的信道来进行通信(例如借助于将宽度为20MHz的主信道与宽度为20MHz的相邻或不相邻信道相结合来形成宽度为40MHz的信道)。
甚高吞吐量(VHT)STA可以支持宽度为20MHz、40MHz、80MHz和/或160MHz的信道。40MHz和/或80MHz信道可以通过组合连续的20MHz信道来形成。160MHz信道可以通过组合8个连续的20MHz信道或者通过组合两个不连续的80MHz信道(这种组合可被称为80+80配置)来形成。对于80+80配置来说,在信道编码之后,数据可被传递并经过一个分段解析器,所述分段解析器可以将数据非成两个流。在每一个流上可以单独执行逆快速傅里叶变换(IFFT)处理以及时域处理。所述流可被映射在两个80MHz信道上,并且数据可以由执行传输的STA来传送。在执行接收的STA的接收机上,用于80+80配置的上述操作可以是相反的,并且组合数据可被发送至介质接入控制(MAC)。
802.11af和802.11ah支持1GHz以下的工作模式。相比于802.11n和802.11ac,在802.11af和802.11ah中使用信道工作带宽和载波有所缩减。802.11af在TV白空间(TVWS)频谱中支持5MHz、10MHz和20MHz带宽,并且802.11ah支持使用非TVWS频谱的1MHz、2MHz、4MHz、8MHz和16MHz带宽。依照代表性实施例,802.11ah可以支持仪表类型控制/机器类型通信(MTC)(例如宏覆盖区域中的MTC设备)。MTC设备可以具有某种能力,例如包含了支持(例如只支持)某些和/或有限带宽在内的受限能力。MTC设备可以包括电池,并且该电池的电池寿命高于阈值(例如用于保持很长的电池寿命)。
对于可以支持多个信道和信道带宽的WLAN系统(例如802.11n、802.11ac、802.11af以及802.11ah)来说,这些系统包含了可被指定成主信道的信道。所述主信道的带宽可以等于BSS中的所有STA所支持的最大公共工作带宽。主信道的带宽可以由某一个STA设置和/或限制,其中所述STA源自在支持最小带宽工作模式的BSS中工作的所有STA。在关于802.11ah的示例中,即使BSS中的AP和其他STA支持2MHz、4MHz、8MHz、16MHz和/或其他信道带宽工作模式,但对支持(例如只支持)1MHz模式的STA(例如MTC类型的设备)来说,主信道的宽度可以是1MHz。载波感测和/或网络分配向量(NAV)设置可以取决于主信道的状态。如果主信道繁忙(例如因为STA(其只支持1MHz工作模式)对AP进行传输),那么即使大多数的可用频带保持空闲并且可供使用,也可以认为整个可用频带繁忙。
在美国,可供802.11ah使用的可用频带是902MHz到928MHz。在韩国,可用频带是917.5MHz到923.5MHz。在日本,可用频带是916.5MHz到927.5MHz。依照国家码,可用于802.11ah的总带宽是6MHz到26MHz。
图1D是示出了根据实施例的RAN 113和CN 115的系统示意图。如上所述,RAN 113可以通过空中接口116使用NR无线电技术来与WTRU 102a、102b、102c进行通信。RAN 113还可以与CN 115进行通信。
RAN 113可以包括gNB 180a、180b、180c,但是应该了解,在保持符合实施例的同时,RAN 113可以包括任何数量的gNB。gNB 180a、180b、180c每一者都可以包括一个或多个收发信机,以便通过空中接口116来与WTRU 102a、102b、102c通信。在一个实施例中,gNB180a、180b、180c可以实施MIMO技术。例如,gNB 180a、180b可以使用波束成形处理来向和/或从gNB 180a、180b、180c发射和/或接收信号。由此,举例来说,gNB 180a可以使用多个天线来向WTRU 102a发射无线信号,以及接收来自WTRU 102a的无线信号。在实施例中,gNB180a、180b、180c可以实施载波聚合技术。例如,gNB 180a可以向WTRU 102a(未显示)传送多个分量载波。这些分量载波的子集可以处于无授权频谱上,而剩余分量载波则可以处于授权频谱上。在实施例中,gNB 180a、180b、180c可以实施协作多点(CoMP)技术。例如,WTRU102a可以接收来自gNB 180a和gNB 180b(和/或gNB 180c)的协作传输。
WTRU 102a、102b、102c可以使用与可扩缩数字配置相关联的传输来与gNB 180a、180b、180c进行通信。例如,对于不同的传输、不同的小区和/或不同的无线传输频谱部分来说,OFDM符号间隔和/或OFDM子载波间隔可以是不同的。WTRU 102a、102b、102c可以使用具有不同或可扩缩长度的子帧或传输时间间隔(TTI)(例如包含了不同数量的OFDM符号和/或持续不同的绝对时间长度)来与gNB 180a、180b、180c进行通信。
gNB 180a、180b、180c可被配置成与采用独立配置和/或非独立配置的WTRU 102a、102b、102c进行通信。在独立配置中,WTRU 102a、102b、102c可以在不接入其他RAN(例如,e节点B 160a、160b、160c)的情况下与gNB 180a、180b、180c进行通信。在独立配置中,WTRU102a、102b、102c可以使用gNB 180a、180b、180c中的一者或多者作为移动锚定点。在独立配置中,WTRU 102a、102b、102c可以使用无授权频带中的信号来与gNB 180a、180b、180c进行通信。在非独立配置中,WTRU 102a、102b、102c会在与别的RAN(例如e节点B 160a、160b、160c)进行通信/相连的同时与gNB 180a、180b、180c进行通信/相连。举例来说,WTRU 102a、102b、102c可以通过实施DC原理而以基本同时的方式与一个或多个gNB 180a、180b、180c以及一个或多个e节点B 160a、160b、160c进行通信。在非独立配置中,e节点B 160a、160b、160c可以充当WTRU 102a、102b、102c的移动锚定点,并且gNB 180a、180b、180c可以提供附加的覆盖和/或吞吐量,以便为WTRU 102a、102b、102c提供服务。
gNB 180a、180b、180c每一者都可以关联于特定小区(未显示),并且可以被配置成处理无线电资源管理决策、切换决策、UL和/或DL中的用户调度、支持网络切片、双连接、实施NR与E-UTRA之间的互通处理、路由去往用户平面功能(UPF)184a、184b的用户平面数据、以及路由去往接入和移动性管理功能(AMF)182a、182b的控制平面信息等等。如图1D所示,gNB 180a、180b、180c彼此可以通过Xn接口通信。
图1D所示的CN 115可以包括至少一个AMF 182a、182b,至少一个UPF 184a、184b,至少一个会话管理功能(SMF)183a、183b,并且有可能包括数据网络(DN)185a、185b。所述AMF 182a、182b,UPF 184a、184b和SMF 183a、183b可以是相同或不同类型的设备,这些设备的硬件可以包括处理器、存储器、收发信机和其它必要的数据接口。在一个示例中,AMF182a、182b,UPF 184a、184b和SMF 183a、183b硬件可以类似于这里描述的WTRU的硬件。在另一个示例中,所述AMF 182a、182b,UPF 184a、184b和SMF 183a、183b中的每一个可以包括多于一个的设备。虽然每一前述部件都被描述了CN 115的一部分,但是应该了解,这其中的任一部件都可以被CN运营商之外的实体拥有和/或运营。
AMF 182a、182b可以经由N2接口连接到RAN 113中的gNB 180a、180b、180c的一者或多者,并且可以充当控制节点。例如,AMF 182a、182b可以负责认证WTRU 102a、102b、102c的用户,支持网络切片(例如处理具有不同需求的不同PDU会话),选择特定的SMF 183a、183b,管理注册区域,终止NAS信令,以及移动性管理等等。AMF 182a、182b可以使用网络切片处理,以便基于WTRU 102a、102b、102c使用的服务类型来定制为WTRU 102a、102b、102c提供的CN支持。作为示例,针对不同的使用情况,可以建立不同的网络切片,例如依赖于超可靠低延时(URLLC)接入的服务、依赖于增强型大规模移动宽带(eMBB)接入的服务、和/或用于机器类通信(MTC)接入的服务等等。AMF 182可以提供用于在RAN 113与使用其他无线电技术(例如,LTE、LTE-A、LTE-A Pro和/或诸如WiFi之类的非3GPP接入技术)的其他RAN(未显示)之间切换的控制平面功能。
SMF 183a、183b可以经由N11接口连接到CN 115中的AMF 182a、182b。SMF 183a、183b还可以经由N4接口连接到CN 115中的UPF 184a、184b。SMF 183a、183b可以选择和控制UPF 184a、184b,并且可以通过UPF 184a、184b来配置业务量路由。SMF 183a、183b可以执行其他功能,例如管理和分配WTRU或UE IP地址,管理PDU会话,控制策略实施和QoS,以及提供下行链路数据通知等等。PDU会话类型可以是基于IP的,不基于IP的,以及基于以太网的等等。
UPF 184a、184b可以经由N3接口连接RAN 113中的gNB 180a、180b、180c的一者或多者,这样可以为WTRU 102a、102b、102c提供对分组交换网络(例如因特网110)的接入,以便促成WTRU 102a、102b、102c与启用IP的设备之间的通信,UPF 184、184b可以执行其他功能,例如路由和转发分组、实施用户平面策略、支持多宿主PDU会话、处理用户平面QoS、缓冲下行链路分组、以及提供移动性锚定处理等等。
CN 115可以促成与其他网络的通信。例如,CN 115可以包括或者可以与充当CN115与PSTN 108之间的接口的IP网关(例如IP多媒体子系统(IMS)服务器)进行通信。此外,CN 115可以为WTRU 102a、102b、102c提供针对其他网络112的接入,这其中可以包括其他服务提供方拥有和/或运营的其他有线和/或无线网络。在一个实施例中,WTRU 102a、102b、102c可以经由对接到UPF 184a、184b的N3接口以及介于UPF 184a、184b与本地数据网络(DN)185a、185b之间的N6接口并通过UPF 184a、184b连接到DN 185a、185b。
有鉴于图1A-1D以及关于图1A-1D的相应描述,在这里对照以下的一项或多项描述的一个或多个或所有功能可以由一个或多个仿真设备(未显示)来执行:WTRU 102a-d、基站114a-b、e节点B 160a-c、MME 162、SGW 164、PGW 166、gNB 180a-c、AMF 182a-b、UPF 184a-b、SMF 183a-b、DN185 a-b和/或这里描述的一个或多个其他任何设备。这些仿真设备可以是被配置成模拟这里描述的一个或多个或所有功能的一个或多个设备。举例来说,这些仿真设备可用于测试其他设备和/或模拟网络和/或WTRU功能。
仿真设备可被设计成在实验室环境和/或运营商网络环境中实施关于其他设备的一项或多项测试。例如,所述一个或多个仿真设备可以在被完全或部分作为有线和/或无线通信网络一部分实施和/或部署的同时执行一个或多个或所有功能,以便测试通信网络内部的其他设备。所述一个或多个仿真设备可以在被临时作为有线和/或无线通信网络的一部分实施或部署的同时执行一个或多个或所有功能。所述仿真设备可以直接耦合到别的设备以执行测试,和/或可以使用空中无线通信来执行测试。
一个或多个仿真设备可以在未被作为有线和/或无线通信网络一部分实施或部署的同时执行包括所有功能在内的一个或多个功能。例如,该仿真设备可以在测试实验室和/或未被部署(例如测试)的有线和/或无线通信网络的测试场景中使用,以便实施关于一个或多个组件的测试。所述一个或多个仿真设备可以是测试设备。所述仿真设备可以使用直接的RF耦合和/或借助RF电路(例如,该电路可以包括一个或多个天线)的无线通信来发射和/或接收数据。
如本文所讨论的,可以使用以下缩写:分支点(BP);双栈MIP(DSMIP);通用分组无线业务(GPRS);GPRS通道化协议(GTP);移动边缘(ME);移动边缘计算,或等效地,多访问边缘计算(MEC);ME编排器(MEO);ME平台(MEP);MEP管理器(MEPM);移动IP(MIP);多路径TCP(MPTCP);网络地址转换(NAT);分组数据单元(PDU);代理移动IP(PMIP);接入点(PoA);上行链路分类器(UL CL);用户平面功能(UPF);以及超可靠和低延时通信(URLLC)。此外,编排器或MEO可以是或包括边缘或雾系统内的移动性控制器实体,其触发跨边缘主机的ME App重定位。在欧洲电信标准协会(ETSI)MEC参考体系结构中,编排器角色可由MEO、MEPM、MEP或这些MEC实体的组合来实现。ME App可以是或包括在ME平台上的网络边缘上运行的应用(App)。
在一些实施例中,可以在保持与远程对等端的连接的同时,实现应用移动性(例如,快速应用移动性)。这种移动性可以使用MPTCP来实现;例如,该MPTCP被修改以支持MPTCP会话移动性。
MPTCP可以包括对链路故障、负载平衡和带宽聚合能力的支持。可以在两个对等端之间创建多个子流以支持这种情况。在一些实现中,MPTCP可以用于其它目的,诸如支持应用移动性,同时保持客户端应用与移动边缘(ME)应用之间的会话连接性。在一些实现中,可以创建朝向不同主机的子流。例如,在这样的实现中,可以创建从WTRU客户端应用朝向不同目标的多个子流,从而导致在所述WTRU处的MPTCP会话具有与相同MPTCP会话相关联的朝向第一对等端的子流和朝向另一对等端的另一子流。在这种情况下,可以假设支持多归属和会话连续性的网络架构,例如,如由第3代合作伙伴计划和/或因特网工程任务组(IETFTM)分布式移动性管理(DMM)所定义的网络架构。
如本文所讨论的,可以使用重定向技术来维持会话连续性。例如,可以使用如DSMIP、PMIP或GTP的通道化协议。在一些情况下,这些协议可用于允许WTRU在相同的IP地址处可达,例如即使WTRU移动并附着到一个或多个PoA或服务节点。例如,在一些实现中,数据业务总是被定向到已经向WTRU提供了IP地址的锚节点。如果WTRU从锚节点移动到另一节点(例如服务节点),则DL业务可以从所述锚节点向所述服务节点进行通道化传输,并从所述服务节点提供给WTRU。反向路径可以在UL方向(即,WTRU到服务节点、到锚节点、到对应节点)中使用。在一些情况下,虽然通道化协议可以实现会话连续性,但是所得到的数据路径可能不是最优的,例如,增加了延时。
图2是示出了标准应用层和TCP栈200的示例以及示例应用层和MPTCP协议栈240的框图。应用层和TCP栈200包括应用层210和TCP栈,该TCP栈包括TCP层220和IP层230。应用层和MPTCP协议栈240包括应用层250和MPTCP栈,该MPTCP栈包括MPTCP层260、子流层270和280以及IP层290和295。
MPTCP是TCP的扩展,其便于主机使用多个路径(例如,多个IP地址)来发送和接收属于一个连接的数据。这些多个路径或子流对于TCP/IP会话的各种使用(例如,同时使用)可以改进网络内的资源使用,并且因此可以例如通过更高的吞吐量和/或改进的弹性(例如,对网络故障的弹性)来改进用户体验。MPTCP可以在传输层操作,并且对于较高层和较低层都可以是透明的。MPTCP可以向层叠在标准TCP的特征之上的应用提供附加特征集,诸如图2中所示。MPTCP连接可以包括被称为子流的若干TCP连接。所述MPTCP连接可以管理这些子流的创建、移除和利用以发送数据。注意,虽然示例应用层和MPTCP协议栈240示出了两个子流层270、280(以及相关联的IP层290、295),但是MPTCP连接在各种情况下可以具有少于两个或多于两个子流。
在MPTCP连接已经开始之后,可以将附加子流添加到该连接。主机可以知晓它们自己的IP地址,并且可以例如通过信令交换而知道其它主机的IP地址。如果其它路径可用,则可以在这些路径上创建附加TCP会话(―子流”),并且可以将附加TCP会话(―子流”)与现有MPTCP会话组合。如示例应用层和MPTCP协议栈240所示,MPTCP层将促进所述MPTCP会话继续表现为到两端的应用的单个连接,而不管多个子流。
一些MPTCP实现可以从应用取得输入数据流,并将其分成一个或多个子流,这些子流具有足够的控制信息以允许其被重新组装并被可靠地且按顺序地递送到接收方应用。例如,MPTCP可以添加连接级(connection-level)序列号,以允许对以不同网络延迟到达的多个子流上的分段进行重组。
一些应用可以存储TCP连接的IP地址。在实现MPTCP的主机上运行的应用(其本身不被配置成在MPTCP协议之上运行)(―不知晓MPTCP的(MPTCP-unaware)”应用)可以仅跟踪第一子流的IP地址。这样的应用可以忽略由其它子流使用的IP地址。
一些MPTCP实现方式可以保持MPTCP连接,即使原始子流的IP地址不再被分配给主机。在这种情况下,向不知晓MPTCP的应用暴露的IP地址可能不同于MPTCP实际使用的地址。例如,如果子流270首先被创建,并且稍后在目标主机上被断开连接,则MPTCP可能仅使用IP地址295,而在目标主机上运行的不知晓MPTCP的应用可能认为它正在使用IP地址290。换句话说,如果子流270首先被创建,并且稍后在目标主机上被断开连接,则MPTCP可能仅使用IP地址295,而IP地址290仍然被暴露给在目标主机上运行的不知晓MPTCP的应用。
在一些情况下,在MPTCP连接的生存期期间,解除分配的IP地址可能变为被指派给不同的主机。如果IP地址由(例如,在应用协议内部的)多个应用交换,则这可能产生问题。这个问题可以通过启用―命运共享”(即,将初始子流和MPTCP连接作为一个整体考虑)来解决。在命运共享方法中,如果初始子流被关闭,则MPTCP会话也可以被关闭。然而,命运共享方法可能牺牲了弹性,例如,因为在这样的方法下,MPTCP连接不能在不关闭MPTCP会话的情况下关闭初始子流。如果第一子流的IP地址例如由于移动性事件而不再可用,则MPTCP实用性可以被降低。
图3是示出了示例性简化MEC拓扑300的框图。MEC可以支持用户移动性和移动边缘实例之间的相关联的ME App迁移。用于ME App迁移的MEC支持可以包括:(1)ME App实例重定位(即,虚拟机或容器),其中完整的ME App在MEP主机之间迁移(App状态和可执行),或(2)ME App状态重定位,其中ME App状态的一部分在MEC主机之间迁移。在任一情况下,所述ME App可跟随所述用户。跟随用户移动所述ME App的一个益处是提供尽可能最短的数据路径,从而保持延时尽可能低。另外,与其他方法(例如,在通道化上)相比,在网络中可以使用较少的资源来服务WTRU以保持会话连续性。
在图3所示的示例MEC拓扑300中,应用服务器(ME App 305)在MEC节点(移动边缘主机310)上运行。ME App 305是与在WTRU 320上运行的客户端WTRU App 315通信的服务器App。使用编排器来实现应用服务器移动性。ME编排器MEO 325(或ME平台管理器(MEPM))检测到WTRU 320正在远离ME主机310并朝向ME主机330移动。因此,MEO 325促使ME App 305作为ME App 335转移到目标ME主机330,以便ME App经由ME App实例迁移或经由ME App状态重定位而―跟随”WTRU 320。
DMM将移动性锚定点(anchor)推向网络的边缘。在MEC架构中,分布式网关(D-GW)逻辑实体可以放置在网络的边缘,靠近移动节点。多个D-GW可存在于DMM域中,并且可锚定附着到该域的移动节点(例如,WTRU)的移动性会话。当移动节点移动并与不同的附着点和锚定点执行切换操作时,该WTRU可以获得新的IP地址。这可能导致在同一接口上分配多个IP地址。可以经由锚定点之间的数据通道化来处理已经运行的应用的会话连续性(即,自切换到新的附着点和锚定点之前)。已经运行的应用可以保持使用相同的IP地址,并且其业务可以被通道化传输到其锚节点。新启动的应用(即,在切换到新的附着点和锚定点之后启动的)可以与新获得的IP地址(来自新的锚定点)相关联,该新获得的IP地址可被直接锚定在连接的锚节点处。这种机制可以实现针对在切换之后开始的新应用的最短数据路径选择。注意,WTRU的分配的IP地址及其关联的D-GW IP地址被保存在核心网络(例如归属用户服务器(HSS)或统一数据管理服务器(UDM))中,并且可用于所有的D-GW(即,锚节点)。
5G核心网络可以支持PDU连接服务(即,提供设备和数据网络之间的PDU交换的服务)。PDU会话可以与多个IPv6前缀相关联。这种会话可以被称为多归属PDU会话。该PDU会话可以经由多于一个PDU(IPv6)锚定点提供对数据网络(DN)的访问。通向多个IP锚定点的不同用户平面路径可以在―公共”用户平面功能(UPF)处分支出来,该―公共”用户平面功能(UPF)被称为支持―分支点”(BP)和/或―上行链路分类器”(UL CL)功能的UPF。该分支点和上行链路分类器可提供将UL业务转发到不同IP锚定点以及将DL业务合并到移动设备(即,合并来自到所述设备的链路上的不同IPv6锚定点的业务)。注意,UL CL或分支点与PDU会话锚定点的共同定位可以是部署选项。
3GPP 5G要求可以包括超可靠和低延时通信(URLLC)。URLLC的使用情况可以包括但不限于执行协作和安全功能的自主车辆、智能电网的监视和控制、用于远程医疗过程的触觉反馈、无人驾驶航空车辆的控制和协调、机器人技术、工业自动化等等。这些使用情况可能需要具有特定延时容限的交互。例如,这样的使用情况可能需要具有低于特定阈值的延时的交互,这可以被称为例如低延时交互或非常低延时交互。这样的动作可能不能容忍诸如使用一些类型的通道化方法而被引导到一遥远的或―远离的”主机的业务,在那里将引入超过阈值的延时。
在一些实现中,可以利用增强的MPTCP方法来解决这样的使用情况,例如,实现快速应用移动性。
MEC支持应用移动性,其允许应用服务器在移动设备移动并连接到不同的接入点和/或接入网络时―跟随”该移动设备,诸如在如上所述的DMM中。例如,MEC可支持将ME App从一个ME主机移动到另一个ME主机,如上所述。移动ME App以跟随用户可具有例如在试图保持延时尽可能低时提供最短(或适当短)数据路径的优点。
在示例情况中,WTRU可以连接到另一个PoA/锚节点,并且从当前连接的锚定点获得新的IP地址,同时保留其先前被指派的IP地址。从当前连接的锚定点获得新IP地址可具有实现最短(或适当短)数据路径的优点,例如,因为当使用新IP地址时可不需要移动性管理处理(例如,通道化)。然而,到WTRU的所述数据路径还取决于对应节点(即,通过数据路径与WTRU通信的节点)的位置和/或锚定。例如,在WTRU从保持在相同位置(例如,在特定ME主机上)的ME App(对等端)移开(例如,移动到不同的锚定点)的第一情况下,WTRU上的客户端app与ME App之间的数据路径可能比ME App移动以跟随WTRU(例如,被转移到更靠近WTRU的ME主机)的第二情况相对更长。在所述第二种情况下,假设使用新的IP地址,数据路径可以更短。为了解决数据路径的这个方面,可以实现ME App移动性以使得能够将通信节点移动到更靠近WTRU以及更靠近其锚节点。
由于ME App移动性在解决5G使用情况时可能是有用的,因此注意MEC假设当边缘应用服务器跨ME主机转移时,底层网络维持移动设备与该边缘应用服务器之间的连接性。如本文所讨论的连接性可以指在WTRU上运行的客户端应用与在网络侧(例如,在ME主机上)运行的应用服务器之间建立的TCP会话。可能需要保持该TCP会话(其被绑定到与特定网络节点有关的特定IP地址)以保持连接性。
如果运行在ME主机上的应用服务器(或ME App)被移动到另一ME主机,则可能遇到各种连接性问题。从连接性的观点来看,可以根据情况不同地处理ME App移动性。
一些ME移动性解决方案可包括采用使用DNS重定向的先断后通(Break-Before-Make)。在一些示例中,ME App在移动到新ME主机之前关闭与其对等端(即,WTRU App)的TCP连接。从此,在WTRU App和ME App之间没有应用数据被交换。WTRU App执行指定ME App URL的DNS查找,此后,WTRU App可以经由DNS重定向而被重定向到新的ME主机。与现在在新ME主机上运行的ME App建立新TCP连接,此后,WTRU App与ME App之间的应用数据传送可恢复。在这种先断后通的解决方案中,ME App根据需要跟随WTRU;然而,先断后通方法可能导致在一定时间内失去连接性。这种连接性丢失对于具有某些延时要求的应用(例如,低延时应用)可能是不可接受的。
一些ME移动性解决方案可包括采用先断后通而无DNS重定向。在一些示例中,MEApp在移动到新ME主机之前关闭TCP连接。从此点开始,在WTRU App和ME App之间没有应用数据被交换。WTRU App执行指定ME App URL的DNS查找,但是该DNS查找可能不会立即被重定向,例如因为ME主机App URL通常被缓存在WTRU上。因此,WTRU App与在其初始位置的MEApp建立新的TCP连接。这种重新连接可能引起若干问题。可能出现的一个示例问题是连接性可能在某个时间丢失,这对于具有某些延时要求的应用(例如,低延时应用)可能是不可接受的。可能出现的另一示例问题是ME App可能仍在初始ME主机上运行,但是WTRU App会话已经被转移;因此,与WTRU App的应用数据传输可能不会从TCP连接被关闭的点继续。可能出现的一个示例问题是ME App可能不再运行在初始ME主机上,并且因此可能不会与WTRUApp重新建立通信。
一些ME移动性解决方案可包括使用应用特定通信的先断后通。在一些示例中,MEApp可例如经由应用专用通信来通知WTRU App:其将移动或已移动到新ME主机。可以指定该新ME主机的IP地址,并且WTRU App可以关闭初始TCP连接并且建立朝向该新ME主机的新TCP连接。WTRU App可不发布DNS查找,例如因为用于到达所述新ME主机的信息(即,新IP地址)可由ME App经由专有信令(例如,在应用层)提供。在这种解决方案中,连接性在一定时间内丢失。这种连接性丢失对于具有某些延时要求的应用(例如,低延时应用)可能是不可接受的。此类解决方案涉及WTRU App参与ME App移动性,这可能是不期望的,因为它可能需要支持ME App移动性的所有App被更新以支持所述ME App移动性。
一些ME移动性解决方案可包括使用ME编排器(例如,MEO、MEPM和/或MEP)来采用先断后通。在一些示例中,所述编排器可通知WTRU App:ME App将移动或已移动到新ME主机。所述编排器可以将新ME主机IP地址传送到WTRU App,此后WTRU App可以关闭其初始TCP连接并且建立朝向新ME主机的新TCP连接。WTRU App可以不发布DNS查找,例如因为用于到达新ME主机的信息(即,新IP地址)由编排器提供。在这种解决方案中,连接性在一定时间内丢失。这种连接性丢失对于具有某些延时要求的应用(例如,低延时应用)可能是不可接受的。
一些ME移动性解决方案可使用应用特定通信或编排器通信来采用先通后断(Make-Before-Break)。在一些示例中,ME App或编排器可通知WTRU App:它将移动或已移动到新ME主机,此后,除了与在初始ME主机上运行的ME App的现有TCP连接,WTRU App可建立朝向具有ME App的新ME主机的新TCP连接。ME App或编排器可通知WTRU App何时准备在其新位置(即,新ME主机)接收数据,在此时间或在此时间之后,WTRU App和ME App可开始使用新TCP连接用于数据传送,并且WTRU App可关闭初始TCP连接。此类解决方案涉及WTRUApp参与ME App移动性,这可能是不期望的,因为它可能需要支持ME App移动性的所有App被更新以支持ME App移动性。此外,当新TCP连接使用开始时(即,2个ME App应用同时运行),初始ME App和新ME App可能需要被同步。例如,序列号可能需要被同步。此类同步问题可对ME App侧施加新要求,例如要求对此类ME App的进一步更新。
一些ME移动性解决方案可包括采用经由通道化而获得的会话连续性。在一些示例中,ME App可被移动到新ME主机,并且在该ME主机上运行的移动性支持服务可在初始ME主机与目标ME主机之间建立通道,从而允许保留TCP连接。WTRU App可能不知晓ME App重定位,并且可继续通过TCP连接与初始ME主机发送业务。该初始ME主机充当分支点或服务节点,将来自WTRU的UL业务重定向到新ME主机,并将来自新ME主机的DL业务重定向到WTRU。通道(例如,PMIP或GTP)可在初始ME主机与新ME主机之间用于此目的。这样的解决方案可以保留TCP连接而没有数据传输中断,然而,例如由于所述通道化需要封装数据分组并且导致较长的数据路径,所以延时可能增加。这种增加的延时对于具有某些延时要求的应用(例如,低延时应用)可能是不可接受的。这可能与将ME App移向WTRU的一些目的冲突,例如,为了维持尽可能短的数据路径,并保持延时尽可能低。
一些ME移动性解决方案可包括采用中间盒(middlebox)来处理WTRU与ME App服务器之间的连接性。在一些实现中,中间盒是出于除分组转发之外的目的而变换、检查、过滤或以其它方式操纵数据分组或其它业务的设备。所述中间盒可用于将WTRU App与ME App移动性事件隔离,然而,保持连接性可能是有问题的。例如,所述中间盒可能需要与新ME主机上的ME App建立新TCP连接,并将该新连接与WTRU App的现有会话相关联。这样的过程可能引入延迟,这对于具有某些延时要求的应用(例如,低延时应用)可能是不可接受的,和/或可能不满足5G使用情况的延时要求。
如在以上讨论的情形中,通过将ME App移动到另一ME主机上,现有TCP会话可不再用于到达ME App(除了在通道化情形中),因为与现有TCP会话相关联的IP地址仍在寻址初始ME主机。因此,连接性可能丢失,直到在客户端应用(或中间盒)与新ME主机上的ME App之间建立新TCP会话为止,从而引入对于具有某些延时要求的应用(例如,低延时应用)不可接受的延迟和/或延时
需要有限延时交互(例如,非常低延时交互)的应用和需要TCP会话连续性(例如,用于长期运行的套接字)的应用可能不能容忍与DNS重定向、TCP连接超时和/或TCP连接重建相关联的延迟或延时。
图4是示出了针对在网络中的ME App移动性期间失去连接性的示例性情形,在WTRU 400、第一ME主机403、ME编排器MEO 406(或ME平台管理器MEPM)和第二ME主机409之间的示例性信令的消息序列图。在该示例中,WTRU App 410在WTRU 400上启动,并且ME App413在ME主机403上启动。在WTRU App 410和ME App 413之间建立第一TCP连接416。在操作419,WTRU 400移动(例如在空间中移动)。MEC ME App移动性可被用于促进ME App―跟随”WTRU 400(即,重定位或以其他方式在更接近WTRU 400的新位置的不同ME主机上被执行)。这里,MEO 406在步骤420中检测(例如,如上所述)WTRU 400正在移动,并且触发ME App到新ME主机409的转移作为ME App 421。在步骤420之后,在ME主机403上运行(或先前运行)的MEApp现在在ME主机409上作为ME App 421运行。
MEC可以假设例如如以下示例中所述地保持连接性。示例情况(a)、(b)、(c)和(d)各发生在ME主机409上的ME App 421启动之后。在第一示例情况(a)中,在操作430,与ME主机403处的ME App的TCP连接可能丢失或关闭,例如,作为ME App移动到ME主机409的结果。在情况(a)中,WTRU App 410可检测与ME主机403处的ME App的TCP连接的丢失,并且可在操作435中执行DNS查询以获得重定位到ME主机409的ME App的IP地址。注意,操作435中的DNS查询可能会给连接性重建时间增加延迟。
在替换情况(b)中,在步骤437中,可通知(例如,由MEO 406或在ME主机403上执行的ME App通知)在WTRU 400上执行的WTRU App 410继续与在新ME主机409上运行的ME App421的数据传送。可例如由MEO 406或在ME主机403上执行的ME App向WTRU App 410提供到达在ME主机409上执行的ME App 421的新IP地址。然而,WTRU App 410在ME App转移中的这种参与可能具有各种问题,如先前所讨论的。在操作439,与ME主机403处的ME App的TCP连接可能丢失或关闭。
在示例情况(c)(在情况(a)或情况(b)之后),WTRU 400在操作440中发起与ME主机409的新TCP会话445。所述连接性丢失,并且数据传送被中断,直到与ME主机409建立新的TCP连接。
在示例情况(d)中,在操作450中,可使用初始ME主机403与目标ME主机409之间的通道化来处理ME App移动性支持。在该示例中,在操作419中,WTRU 410已移动到ME主机409,然而在WTRU App与在ME主机403上执行的ME App之间的TCP连接可通过在ME主机409与ME主机403之间建立通道459来保留。这里,例如,来自WTRU 400的针对在ME主机403上执行的ME App的IP地址的UL数据453首先被传送到ME主机409(假设ME主机409是WTRU的第一跳),并且经由通常的IP路由被转发到ME主机403。ME主机403然后经由通道459将UL数据453通道化传输到ME主机409。以这种方式维持TCP连接性可能要求数据总是经由初始ME主机传播,从而使数据路径更长并且增加延迟/延时。这样的解决方案可以保持TCP连接而没有数据传输中断,然而,例如由于所述通道化需要封装和解封装数据分组并且导致更长的数据路径,所以延时可能增加。这种增加的延时对于具有某些延时要求的应用(例如,低延时应用)可能是不可接受的。这可能与将ME App移向WTRU的一些目的冲突,例如,为了维持尽可能短的数据路径,以及保持尽可能低的延时
可能期望在ME App(实例或状态)在ME主机之间转变时,保持客户端App(例如,WTRU App)与ME App之间的连接性,同时还满足延时要求,诸如最大延时阈值(例如,5G或另一使用情况的最大延时阈值),其可被称为―低延时”。这里,ME App转变可包括在目标ME主机上创建ME App的新实例,以及用初始ME主机上当前运行的ME App的状态来配置该新实例。在一些情况下,ME App可能已经在目标ME主机上运行;在此类情况下,ME App可能不需要被重新实例化,但可用初始ME主机上当前运行的ME App的状态来重新配置。还期望在WTRU App不参与ME App移动性操作的情况下,在WTRU App与其新位置(ME主机)处的ME App之间建立直接连接。
因此,MPTCP协议可用于WTRU和ME主机以保持连接性并满足延时要求,而WTRU App无需一定参与ME App移动性操作。MPTCP会话在单个MPTCP会话的保护下(即,使用子流概念)对多个TCP会话进行分组,这对于应用是透明的(例如,没有该应用的参与)。在这样的实现中,所述MPTCP会话对于所述应用而言可以表现为常规TCP会话。因此,通过允许创建朝向新ME App实例(在新ME App实例或―目标”ME主机上的ME App实例)的附加MPTCP子流(即,另一TCP会话)并且一旦完成ME App转移就允许将业务重定向到该新连接,从而可以使用MPTCP会话来支持ME App转移。这样,数据传输可以是不间断的,延时可以不增加,并且应用转移对于客户端应用可以是透明的,其继续向相同的连接(即,TCP连接)发送数据。通过拦截来自所述应用的常规TCP会话,MPTCP栈允许所述应用继续其TCP会话,就好像它正在使用相同的TCP连接一样,即使MPTCP子流(它们自己的TCP连接)在MPTCP层之下被改变。在一些实现中,可在触发ME App转移和MPTCP会话转移之前,选择目标ME主机(例如,由MEO或MEPM选择)。
在一些实施例中,MPTCP可以在WTRU(或中间盒上的MPTCP代理)和ME主机上实现以克服各种连接性问题,例如上面讨论的那些。然而,这样的方法可能导致其他问题。例如,MEC可预期ME App转移将由MEO或MEPM处理(例如,其中ME应用实例被移至新ME主机或ME应用的状态被转移至新ME主机),然而,MEO(或MEPM或MEP)可能不知晓ME应用是否是基于TCP的以及MPTCP是否被用在先前的ME主机上。而且,当使用MPTCP时,编排器或PM可能不知晓哪个MPTCP会话被使用并且应当被转移到新ME主机。此外,可能需要修改MPTCP以支持MPTCP会话转移。
因此,ME App移动性方法可集中于ME App重定位,而MPTCP方法可对应用而言是透明的。MPTCP栈可使用一个或多个子流(即,TCP会话)来创建MPTCP会话,其中应用可能不知晓该MPTCP会话和子流创建/使用。因此,在一些实现中,MPTCP栈转移(其可能是MPTCP栈―跟随”ME App所必需的)不由ME应用本身处理。在一些情况下,在ME App在某种意义上是知晓MPTCP(MPTCP-aware)的(例如,ME App知道MPTCP正在运行并且可经由API配置MPTCP栈以控制其行为中的一些行为)的情况下,ME App可能不知晓MPTCP栈内部。因此,在一些实现中,MPTCP栈转移同样不被知晓MPTCP的ME App处理。在一些情况下,编排器可能不知晓MEApp是否实现MPTCP。因此,可能需要通知该编排器ME:ME主机是否正在使用MPTCP以及MEApp是否是基于TCP的,使得MPTCP栈可与ME App一起被移至新ME主机。
MPTCP可能需要支持将现有MPTCP会话转移到新MPTCP栈实例以及将该MPTCP会话适配到新主机。换句话说,MPTCP栈可能需要利用关于现有MPTCP会话的信息而被配置或启动。MPTCP会话可能需要从ME主机被转变到另一ME主机,同时维持与WTRU对等端的连接性,并且保留链接所述MPTCP栈与关联的ME App的套接字信息。适配目标MPTCP栈可包括将MPTCP会话编号适配到其他现有MPTCP会话(例如,使得目标MPTCP会话的会话编号不复制已经由另一MPTCP会话使用的会话编号)。
所述MPTCP会话和相关信息(例如,其包括会话标识符、相关联的对等端的IP地址、安全密钥、序列号等)的转移也可能需要被支持。
因此,在一些实现中,API可被用于使另一应用(例如,MEO/MEPM/MEP)能够获得或设置MPTCP栈会话信息细节,该信息细节可能是支持ME App―跟随”WTRU(即,到新ME主机)的移动性情况所需要的。在一些实现中,可以在两个MPTCP服务器实例之间提供直接通信,从而允许MPTCP会话转移。在一些实现中,MPTCP可以被修改,使得MPTCP会话可以涉及多于两个对等端(即,可以涉及具有与相同MPTCP会话相关联的不同对等端的子流)。在一些实现中,套接字描述符可以被转移到新的主机,并且可以被适配到现有的套接字。
对于一些应用,在5G网络中可能需要某些延时目标(例如,低于期望阈值的延时,或―非常低的延时”)。在一些实现中,转移应用服务器(或网络应用)以跟随其用户(例如,WTRU从一个ME主机移开并更靠近另一个ME主机)同时保持会话连续性可以使得能够满足这些要求。
一些实施例提供MPTCP会话移动性,从而允许ME App被移动到另一ME主机,同时保持ME App与其对应的客户端应用(例如,在WTRU上执行的客户端应用)之间的连接性,并且保持低延时。在一些实现中,ME App移动性允许应用服务器(例如,运行在ME主机上的应用服务器)保持(例如,物理地)靠近移动设备(例如,WTRU),从而使得能够使用网络中的最短数据路径。与使用增强MPTCP(例如,如本文所讨论的增强MPTCP)获得的WTRU应用的TCP会话保持一起使用的这种移动性可以减少或最小化延时。
在一些实施例中,MPTCP会话转移向应用重定位过程添加很少延迟或不添加延迟。例如,ME应用可在重定位到目标ME主机时,暂停数据传输,然后在所述重定位完成之后恢复数据传输。在ME App重定位完成之后,在一些实现中,增强型MPTCP已经完成移动所述MPTCP会话。因此,应用数据可立即在对应的WTRU App与在目标ME主机上执行的ME App之间交换。在一些实现中,例如,如本文进一步讨论的,MPTCP会话转移可缩短ME App重定位和数据传送继续所需的总时间。
在一些实施例中,MPTCP可以解决各种连接性问题。例如,MPTCP可以用于在向新ME主机转移ME App期间和之后,帮助维持WTRU App和ME App之间的会话连续性。在一些实施方式中,这种MPTCP促进的ME App转移和随后的连接性对于WTRU App而言可以是透明的,MEApp转移和/或连接性支持可能不需要WTRU App的参与,尽管在一些实施方式中,可能涉及在所述WTRU上运行的MPTCP栈。
在一些实施例中,MPTCP会话可以是移动的,其中与初始ME主机的MPTCP会话(即,WTRU和初始ME主机之间的会话)可被移动到目标ME主机(即,使得所述MPTCP会话在WTRU和目标主机之间)。对于这种MPTCP会话移动性的各种方法是可能的。在这样的方法中,运行在WTRU上的MPTCP栈可以如这里所讨论的那样被修改。
在一些实施例中,第三方应用(例如,编排器)可使用在ME主机上本地提供的一个或多个API来获得MPTCP配置并用现有MPTCP会话(即,在初始ME主机上的MPTCP会话)配置目标MPTCP实例(即,在目标ME主机上的MPTCP实例)。
在一些实施例中,新的MPTCP消息可用于使用MPTCP实例之间的相互通信来促进MPTCP会话转移。在这种情况下,某些MPTCP实例可以是―特殊”MPTCP对等端。在这种情况下,可能不创建应用通信路径,并且在特定MPTCP对等端之间可能不交换应用数据业务—相反,在MPTCP实例之间交换MPTCP特定信息。典型的(即,非特殊的)MPTCP对等端可以包括例如具有―客户端-服务器”角色的应用。这样的应用可以在处理应用业务的传输的MPTCP栈的顶部运行。然而,使用此处的各种方法,业务可包括用于MPTCP转移的服务器-服务器通信,其中该业务对―客户端”对等端是透明的。
在一些实施例中,MPTCP会话可具有多于两个活动MPTCP对等端(例如,其可包括WTRU、当前ME主机和目标ME主机)。因此,在一些实施例中,可以在MPTCP会话和多于一个的不同对等端之间创建子流。多个对等端之间的这种通信对于WTRU MPTCP栈可以是透明的,并且在一些实现中可以通过在两个对等端(例如,在ME主机这两者-初始和目标ME主机)上使用相同的安全密钥来实现。在一些实施例中,MPTCP栈可适配于新ME主机环境。例如,MPTCP栈可被透明地适配于MPTCP会话用户(例如,ME App),MPTCP会话用户可继续使用相同的套接字号来向WTRU App发送数据和从其接收数据。在一些实施例中,MPTCP会话可被保留,即使其初始子流被断开或以其他方式不可用。这可以具有避免可能破坏连接性并增加延迟的命运共享解决方案的优点。
注意,虽然为了方便和描述的方便,在此关于特定类型的网络描述了各种实施例,但是在此讨论的实施例都不限于特定类型的网络,并且可以在任何合适的通信系统的上下文中采用。
表1示出了在重定位的各个步骤处,以下两种方法的比较:将ME App从初始ME主机重定位到目标ME主机的示例应用重定位的基于TCP的方法、以及用于相同重定位的基于增强MPTCP的方法。对于每种方法,标记(-)的语句强调应用数据可能不被交换的阶段,而标记(+)的语句强调应用数据可以被交换的阶段。
表1
图5是示出了在使用增强的MPTCP方法来管理ME App移动性的示例性情况下,在WTRU 500、第一ME主机503、MEO 506(或MEPM)和第二ME主机509之间的示例性通信的消息序列图。该示例实现MPTCP栈移动性,其中ME App和MPTCP会话被转移到新ME主机。
如图5中所例示的,MPTCP可以在设备上和应用服务器节点上使用以支持应用服务器移动性。这种支持可能涉及多于新MPTCP子流/路径的创建。相反,可以用已经活动的MPTCP会话来实例化的新MPTCP实例(或可以继续执行的当前MPTCP实例)被适配到新ME主机并利用新子流。
如本文所使用的,―编排器”可被认为是表示ME平台管理器(MEPM)或ME平台(MEP)实体的通用术语。如本文所讨论的以及图中所示的,为了简单起见,ME编排器、MEPM以及有时MEP可在同一框中被指定,然而,例如可使用关于图3所示和所述的对应体系结构。在这种情况下,经由套接字API直接与MPTCP栈交互的实体可在同一ME主机上运行,并因此可被假定为MEP实体。在这种情况下,MEP、MEPM和MEO之间的交互可将信息传递到在目标ME主机上运行的MPTCP实例。
图5的消息序列图被显示及描述于三个部分A、B及C。部分A描述在WTRU 500移动前的操作,部分B描述在WTRU 500开始移动后的MPTCP会话转移准备操作,及部分C描述与MEApp转移相关的MPTCP会话转移完成操作。
在图5的部分A中,WTRU 500开始运行WTRU App 510,该App与(或将与)运行在网络边缘处的基于网络的App(即,ME主机503上的ME App 513)进行通信520。MPTCP栈516在WTRU500上运行,并且MPTCP栈519在ME主机503上运行,其中MPTCP栈516和MPTCP栈519是MPTCP对等端。MPTCP可以对所述App而言是透明的,然而,在一些实现中,知晓MPTCP的应用可以在任一设备上使用。WTRU App 510可以使用套接字接口511来创建TCP会话,并且MPTCP栈516截取该套接字请求。因此,MPTCP会话523被创建,并且处理数据业务529的传输的TCP子流526在两个MPTCP栈516和519之间被创建。根据在WTRU 500和ME主机503上使用的接口的数量以及在它们中的每一个上指派的IP地址的数量,可以在WTRU 500和ME主机503之间创建许多子流。为了简单起见,在图5中仅示出了一个子流。
关于部分B,WTRU 500移动,发起切换530。在切换530期间,WTRU 500附着到另一个PoA并且变为锚定到网络中的另一个锚节点,其中网络支持如这里所讨论的会话连续性。WTRU从新的锚定点获得新的IP地址,同时仍然保留已经在使用并与子流526相关联的IP地址。
在切换530之后,子流526的数据路径比切换530之前长,因为在切换530之后,数据业务529经由ME主机509从WTRU 500转发到ME主机503。在该示例中,数据业务529在两个锚定点之间被通道化传输;即,经由通道533在当前连接的ME主机509和先前连接的ME主机503之间被通道化传输。在步骤536中,MEO 506被通知(例如,由网络通知,例如,MEO 506可以注册到网络以当WTRU移动/切换到另一个PoA/锚定点时被通知)WTRU 500的移动,并且确定MEApp 513应当被移动到另一个ME主机以―跟随”(即,物理上更靠近)所述WTRU。
ME App移动性可用于实现WTRU App 510与ME App 513之间的最短数据路径的维护,例如以获得更好的数据传送性能。另外,与其他方法相比,例如基于通道化来维持会话连续性的那些方法,在网络中可以使用更少的资源来服务所述WTRU。
在步骤539,为了准备ME App转移并保持所述连接性,编排器触发MPTCP会话转移准备。在步骤539期间,信息(例如,安全密钥、令牌、序列号等)被转移到在目标ME主机509上运行的目标MPTCP栈540,以使得能够在ME App 513的转移和MPTCP会话523的转移完成之前,创建与WTRU 500上的现有MPTCP会话523(即,MPTCP栈516)相关联的新子流543。新子流543是―预分配的(pre-allocated)”(例如,可以用优先级PRE_ALLOCATED(预分配的)创建),并且在这一点上不用于数据业务传送。以此方式提前创建与目标ME主机509的子流543可在完成ME App和MPTCP会话重定位之后尽快促进目标ME主机509与WTRU 500之间的数据传送,而不中断WTRU App 510与ME App之间的数据业务。
由ME主机509上的MPTCP栈540用于子流543创建的WTRU 500的IP地址可以是在切换530期间由当前锚节点分配的IP地址。在该示例中,锚节点可以访问WTRU的连接性信息,如先前关于DMM所讨论的。可使该连接性信息对MEO 506可用,例如以配置MPTCP栈540。由当前锚节点分配给WTRU 500的IP地址可以作为所述MPTCP会话转移过程的一部分而被提供给MPTCP栈540。
子流543可使用在MPTCP栈516和MPTCP栈540之间交换的MPTCP消息来创建。MPTCP栈移动性对于MPTCP栈516可以是透明的。因此,MPTCP栈516可能不知晓它正在与MPTCP栈540通信而不是与MPTCP栈519通信。
在部分B的结尾,使用子流526在WTRU App 510与ME App 513之间传送数据业务529;然而,该数据路径现在比切换530之前长得多。这是因为WTRU的―第一跳”或网络中的入口点现在是ME主机509,因此数据业务529必须从WTRU 500行进通过ME主机509,然后照常被路由到其目的地(在这种情况下,目的地为运行在ME主机503上的ME App 513)。在DL方向上使用相同的路径。本文进一步描述准备步骤(例如步骤539)的各个方面。
关于部分C,在步骤546,MEO 506触发ME App 513到ME主机509的转移(其中转移的ME App称为ME App 549)。在步骤550中,MEO 506触发从MPTCP栈519到MPTCP栈540的MPTCP会话转移的完成。在完成会话转移之后,在步骤550,ME主机509上的MPTCP栈540将子流543从预分配状态改变为常规状态(例如,将优先级从―PRE_ALLOCATED”改变为―REGULAR(常规)”)。MPTCP栈540还(例如,使用相同的MPTCP消息)将子流526改变为不可用状态(例如,将优先级改变为NOT_AVAILABLE(不可用))。在该示例中,将子流526改变为不可用状态触发了将子流543用于WTRU App 510与重定位的ME App 549之间的数据业务529。注意,子流526和子流543不能同时都传送数据(即,不能同时都处于常规状态),然而,初始子流526可以被保留(例如,处于不可用状态)。
在初始ME主机503上,仅初始子流526被维持,被设置为不可用(例如,优先级被设置为NOT_AVAILABLE)。如果有来自ME主机503的其它子流,则其被关闭。例如,如果在WTRU500和ME主机503之间配置了冗余或备用(例如具有优先级―BACKUP(备用)”)子流(未示出)(即,为子流526备用或提供冗余),则在将子流543改变为常规状态之前关闭该子流。
在图5的示例中,初始子流526可被维持,即使它可能不用于数据传输,例如以支持WTRU上的应用,该应用已经将该初始子流的IP地址关联到会话或应用。因此,为了保留MPTCP会话并避免命运共享行为,初始子流526可被保留,并且其相关联的IP地址可保持被指派给WTRU直到MPTCP会话被关闭。在不再需要保留初始子流526的非常时期中,则可以关闭子流526,而不是将其维持在不可用状态或以其他方式改变其状态。
在完成部分C之后,WTRU App 510可以照常继续发送和接收数据业务529,而不知道新数据路径或ME App重定位,并且MPTCP会话转移可以被认为是完成的。所述完成的各种进一步的细节以及图5的示例的其它方面在此被进一步描述。
注意,MPTCP会话重定位仅对由被移动的ME App 513(即,作为ME App 549被移动到ME主机509)所使用的那些MPTCP会话执行。由ME主机503上的MPTCP栈519处理的任何其他MPTCP会话(未示出)不受移动和重定位的影响。然而,注意,遵循与针对单个MPTCP会话所描述的相同过程,多个MPTCP会话可同时移动。
图6是示出了WTRU 600、第一ME主机603和MEO 606(或MEPM或MEP)之间的示例通信的消息序列图,其示出了示例移动性订阅和触发。部分A更具体地涉及移动性订阅,并且部分B更具体地涉及触发。部分A和部分B将在下面更详细地讨论。在该示例中,MEO 606知晓WTRU 600的移动性,并且基于(例如,如本文所述从网络获得的)WTRU的移动,确定是否将MEApp 613从ME主机603移动,以及确定应该将ME App 613移动到哪个目标ME主机。MEO 606还确定哪个目标ME主机。虽然如这里所讨论的编排器(其是MEO、MEPM、MEP或这些中的任何的组合)可以负责移动性和触发,但是这里所讨论的涉及编排器的概念可以由服务于该功能的另一实体来执行。
ME App 613可能知晓它是否是基于TCP的,但是它可能不知晓WTRU 600的MPTCP使用(即,MPTCP栈616)。在一些示例中,MPTCP对ME App 613是透明的。稍后描述涉及知晓MPTCP的应用的示例实现。
所述ME App可订阅从MEO 606接收客户端(即,WTRU)相关移动性事件。在该步骤期间,ME App 613可向MEO 606提供信息(例如,ME App标识符和WTRU标识符信息)。该信息可以使得编排器能够将与移动性事件相关联的特定WTRU标识符映射到ME应用。MEO 606因此可具有足够的信息来触发ME App移动性过程。
MEO 606还可能需要确定MPTCP会话是否正在由ME App 613使用。如果是,则MPTCP会话也必须被转移到目标ME主机。在ME App 613和WTRU App 610之间可以存在多个MPTCP会话(例如,对于不同的业务类型的多个MPTCP会话)。如果确实如此,则这些MPTCP会话都要被转移到目标ME主机。
因此,除上面指定的参数(即,ME App标识符和WTRU标识符)之外,由ME App 613用于WTRU 600的套接字描述符可用其类型(例如,TCP或UDP)来指定。在一些示例中,如果指定UDP,则不使用MPTCP。因此,MEO 606可以忽略连接性(UDP是无连接的)。如果指定了TCP,则所述套接字描述符可对应于MPTCP会话标识符(例如,与之相同),并且可假设MPTCP已在主机处启动,并且当TCP套接字被打开时,它被自动使用。MEO 606随后使用该标识符来触发MPTCP会话转移,如这里所讨论的。
基于来自ME App 613的移动性订阅,MEO 606可基于所述套接字描述符,确定在检测到WTRU移动性时是否必须转移MPTCP会话,以及转移哪个MPTCP会话。
关于图6描述的订阅和通知步骤是如何将套接字描述符传递给编排器的示例。在一些实现中,所述套接字描述符可以以其他方式传递而不影响MPTCP会话转移过程,如这里所讨论的。
图6的部分A更详细地描述了订阅。这里,WTRU App 610在WTRU 600上启动。WTRUApp 610意图参与与服务器(诸如运行在ME主机603上的ME App 613)的通信620。MPTCP栈616在WTRU 600上运行,MPTCP栈619在ME主机603上运行。WTRU App 610可创建TCP套接字611以经由TCP连接与ME App 613通信。由于MPTCP栈616在WTRU 600上运行,它可以截取套接字请求并创建与ME主机603的MPTCP会话623(即,经由MPTCP栈619)。TCP子流626被创建以处理WTRU App 610与ME App 613之间(即,所述应用的客户端侧和服务器侧之间)的数据业务629。在该示例中,ME App 613支持主机重定位,并且向MEO 606传送订阅640以接收移动性事件的通知。该订阅(或相关通信)可以包括关于由ME App 613用于与WTRU App 610通信的协议(例如―proto_TCP”)和相应的套接字描述符(例如―sockfd”)的信息。
图6的部分B更详细地描述了触发。这里,MEO 606接收WTRU 600的移动性事件645。由于ME App 613已订阅该特定WTRU(即,WTRU 600)的该事件,MEO 606将通知650传送给MEApp 613。MEO 606还在步骤655使用在订阅时间接收到的套接字描述符(例如,―sockfd”)参数来触发MPTCP会话转移。MPTCP栈可以使用套接字描述符参数来确定需要转移哪个MPTCP会话,例如,如这里进一步描述的。
在一些实施例中,MPTCP会话转移可以使用不同的方法来实现。在第一示例方法中,该转移可由编排器使用套接字API来处理。在第二示例方法中,该转移可经由当前MPTCP栈与目标MPTCP栈之间的直接通信来处理。本文进一步详细描述了此类方法。这两种方法将使用例如编排器来触发MPTCP会话转移而被描述。为了触发MPTCP会话转移,在一些示例中,编排器必须知晓标识要转移的MPTCP会话的套接字文件描述符。在本文的各示例中,假定编排器在移动性事件订阅期间从ME App获得此信息,例如,如先前所描述的。然而,注意,在一些实施例中,编排器可以以另一种合适的方式获得该信息。
WTRU App所使用的多个MPTCP会话可能需要被移动;因此,可能需要移动多个MPTCP会话。在这样的情况下,在一些实现中,相同的移动性过程被顺序地或并行地重复多次。或者,在一些实施方案中,可使用单个程序来同时或同时移动多个会话。
例如,如关于图5的部分B所示和所述,编排器可以在ME App重定位之前触发MPTCP会话重定位的准备阶段。在准备阶段期间,如果MPTCP栈尚未运行,则可在目标ME主机上实例化该MPTCP栈。在实例化之后,目标MPTCP栈可以准备好接收与要转移的MPTCP会话有关的信息。例如,如本文进一步描述的,这样的信息可以包括安全密钥、令牌、序列号等。所述MPTCP栈可例如在该MPTCP会话配置中接收所述WTRU已从所述MPTCP栈在其上运行的ME主机或从接近所述目标ME主机的锚节点获得的IP地址。WTRU可以在附着到不同锚定点的同时获得多个IP地址。为了获得WTRU与ME App之间的最短数据路径,可选择由目标ME主机或由最靠近目标ME主机的锚节点指派的WTRU IP地址。
在这些操作完成之后,可以在运行于目标主机上的MPTCP实例和运行于WTRU上的MPTCP客户端之间创建新的子流。该新的子流可以最初被创建,其优先级或类型被设置为指示其是―预分配”状态;即,在这一点上它不能用于数据传送。由目标ME主机(即,WTRU已移动到的地方的ME主机-WTRU的当前锚节点)分配给WTRU的IP地址可被用于创建该新的子流,例如,以便于最短的数据路径被用于该新的子流。
在一些实现中,目标ME MPTCP栈与WTRU MPTCP栈之间的通信可能需要将用于原始MPTCP会话(即,WTRU与原始ME主机之间的MPTCP会话)的安全信息(例如,安全密钥)转移到目标MPTCP栈。在一些实现中,该转移可以以安全的方式完成。
WTRU可能不知晓新的(预分配的)子流已经被创建到另一个ME主机(即,目标MPTCP栈)。该目标MPTCP栈可使用与原始ME主机上的初始MPTCP栈相同的密钥。此时,通信和数据传输在WTRU和初始ME主机之间仍可进行。如本文所讨论的,可执行这种―预先”子流创建,以便一旦完成ME App转移,则加速从原始子流(在WTRU与原始ME主机之间的子流)到新子流(在WTRU与目标ME主机之间的子流)的连接切换。
如例如关于图5的部分C所示和所述,编排器可以在完成MPTCP会话重定位的同时触发ME App重定位。在该步骤,目标MPTCP栈可能已经被配置有正被转移的现有MPTCP会话,并且目标ME主机和WTRU之间的新子流可能已经被创建,其状态或优先级被设置为―预分配”。这可以在准备步骤期间处理,如前所述。
在触发所述ME App重定位之后,可经由MEO在初始MPTCP栈与目标MPTCP栈之间交换与所述子流和数据传输有关的动态信息(例如,MPTCP会话的序列号)的更新。该MPTCP信息转移可以在ME App转移期间执行;因此,在一些情况下,它不延长所述ME App重定位过程。此时,目标ME主机准备好处理来自WTRU的数据业务。为了开始处理该数据业务,从WTRU朝向目标ME主机的新MPTCP子流(其被预先创建(即,在准备阶段期间被创建))可被配置为―常规”子流(即,从―预分配”改变其类型或优先级)。在新子流被配置为―常规”子流之后,初始子流可以被改变为―不可用”子流。如果存在与原始ME主机相关联的其它子流,则可关闭该其它子流。在初始子流被变得―不可用”之后,数据业务然后可以经由新的子流而在WTRU App和目标ME App之间被交换。
一些应用可以存储被指派给TCP连接的IP地址。因此,为了从WTRU App的角度支持透明的MPTCP会话和ME App移动性,只要MPTCP会话存在,就可以维持与该MPTCP会话相关联的初始子流—即使其不再用于数据业务。因此,这样的子流可以被标识为不可用(例如,使用优先级或状态―NOT_AVAILABLE”)。该优先级可指示所述子流必须被维持,尽管不再被用于数据业务,并且不能使用与此子流相关联的ME主机地址来创建其他子流。子流优先级(例如,―MP_PRIO”)消息可由原始ME主机用来将初始子流优先级从―常规”改变为―不可用”。朝向目标ME主机的新子流优先级可由目标ME主机从―预分配”改变为―常规”。
在一些实现中,基于如本文所讨论的MPTCP会话转移,重定位的ME App可在ME App转移完成之后,恢复业务数据传输,就好像它仍位于先前ME主机上一样,这可例如使用相同的套接字描述符而无需与所述WTRU建立新的TCP连接来完成。
关于要转移的MPTCP信息,在一些实施例中,与正被重定位的ME App相关联的所有MPTCP会话被转移到在目标主机上运行的MPTCP栈。对于要转移的每个MPTCP会话,还转移与该MPTCP会话有关的信息。例如,这种信息可包括安全密钥(例如,服务器安全密钥和客户端安全密钥)、标识所述会话的令牌(例如,新子流创建或现有子流移除可能需要的服务器令牌和客户端令牌)、以及整个MPTCP会话的序列号等。
在一些实施例中,MPTCP会话转移由编排器处理(与如稍后所讨论的经由MPTCP服务器之间的直接通信相反)。通常,编排器可以知晓所述WTRU的移动;这可便于编排器协调MPTCP会话转移。在这样的实施例中,编排器朝向当前MPTCP栈(在初始ME主机上的MPTCP栈)使用API来获得要被转移到目标MPTCP栈的MPTCP信息。所述目标MPTCP栈也可以使用API来配置。此处进一步详细讨论了这些API的示例。
图7是示出了针对准备阶段的示例MPTCP会话转移,WTRU 700、第一ME主机703、MEO706(或MEPM)和第二ME主机709之间的示例通信的消息序列图,其中MPTCP会话转移由编排器处理。在该示例中,MEO 706与其关联的MEP实例MEP 1和MEP 2一起被示出。在该图中,MEP1和MEP 2分别在ME主机703和ME主机709上运行以与MEO 706交互。如图7所示,在准备数据流转移的过程中,与MPTCP会话相关的信息可被转移到在另一ME主机上运行的另一MPTCP实例。图7的消息序列图在四个部分A、B、C和D中被示出和描述。
在图7的部分A中,WTRU 700开始运行WTRU App 710,该App正在或将要与运行在ME主机703上的ME App 713通信。MPTCP栈716运行在WTRU 700上,MPTCP栈719运行在ME主机703上,其中MPTCP栈716和MPTCP栈719是MPTCP对等端。WTRU App 710创建TCP套接字711以经由相应的TCP套接字704与ME App 713通信。套接字创建请求被MPTCP栈716截取,其创建与相关联的子流726的MPTCP会话,之后可以在客户端应用侧和服务器应用侧(即,分别为WTRU App 710和ME App 713)之间交换数据业务729。
在图7的部分B中,在步骤730中,WTRU 700移动,附着到ME主机709处的新的锚节点,并且从ME主机709获得新的IP地址。尽管如图7所示,使用子流726的数据路径比步骤730中的切换之前更长,但是可以为子流726保留会话连续性。
在该示例中,数据业务729在两个锚定点之间被通道化传输;即,经由通道733在当前连接的ME主机709与先前连接的ME主机703之间被通道化传输。在步骤736中,MEO 706被通知(例如,由网络通知。例如,MEO 706可以注册到网络,以当WTRU移动/切换到另一个PoA/锚定点时,被通知)WTRU 600的移动,并且确定ME App 713应当被移动到另一个ME主机以―跟随”(即,物理上更靠近)所述WTRU。在步骤739中,如果MPTCP栈740尚未运行,则在ME主机709上实例化该MPTCP栈740,并且MEO 706触发MPTCP会话转移的准备。
在该示例中,MEP 1在ME主机703本地使用套接字API 741来获得要转移的MPTCP信息742,例如以创建新的子流。信息742可以包括例如WTRU 700的IP地址、安全密钥等等。在一些示例中,―getsockopt”套接字API可以用于该目的,然而,可以使用其他套接字,例如,如本文进一步讨论的。所获得的信息被转移到MEO 706。MPTCP 716和MPTCP 719之间的任何现有子流不被转移到MPTCP 740;相反,在WTRU 700与目标ME主机709之间建立新子流。
图7的部分C描述了由目标ME主机709用于配置所述MPTCP会话的套接字API。这里,MPTCP信息742从MEO 706传递到ME主机709,并且MPTCP会话在MPTCP栈740上用从MPTCP栈719获得的信息来创建。例如,所述MPTCP会话可例如使用相同的套接字文件描述符、安全密钥和序列号在目标ME主机709上被复制。―socket”套接字API 750和―setsockopt”套接字API 755可以用于该目的。WTRU 700的IP地址从ME主机709获得,与所转移的MPTCP会话相关联,并且被配置到MPTCP栈740上。现有子流与两个地址相关联:来自WTRU 700的第一IP地址和来自ME主机的第二IP地址。因为ME主机703的IP地址在目标ME主机709上不是有效的,所以该信息不被转移。
在图7的D部分中,在完成C部分的MPTCP信息转移之后,目标MPTCP栈740基于WTRU700的IP地址(作为所转移息的一部分而获得)和在ME主机709上有效的本地IP地址来发起新子流770的创建。通过使用发送到WTRU 700的MPTCP消息765,从ME主机709发起与MPTCP栈716(即,子流770的MPTCP对等端)的新子流770的创建,作为PRE_ALLOCATED子流。在该示例中,消息765是MP_JOIN消息,但是注意到在其他实现中可以使用其他合适的消息。在本文别处描述了预分配的子流。在一些示例中,可以预先创建多个新的预分配子流(未示出)以替换现有子流。例如,如果WTRU 700最初具有朝向ME主机703的2个子流(例如,通过使用蜂窝和WiFi接口的2个子流),则可使用ME主机709IP地址来创建朝向ME主机709的2个预分配子流(例如,如果ME主机709上支持,则也使用蜂窝和WiFi来创建)。
在关于图7描述的MPTCP会话转移准备阶段完成之后,数据业务继续在WTRU 700和ME主机703之间交换。仅有MPTCP会话转移准备在该点执行;因此,ME App 713仍可在ME主机703上运行。因此,虽然MPTCP会话转移可能已开始,并且可能已创建了朝向ME主机709的新的预分配子流770,但该子流在该阶段可能不用于传输数据业务。注意,在其他实现中,新的预分配子流创建可以由WTRU发起,如本文稍后所描述的。
图8是示出了WTRU 800、第一ME主机803、MEO 806(或MEPM)和第二ME主机809之间的示例通信的消息序列图,该示例通信用于MPTCP会话转移完成阶段,其中MPTCP会话转移由编排器处理。在该示例中,MEO 806连同其相关联的MEP实例MEP 1和MEP 2一起被示出。在该图中,MEP 1和MEP 2分别在ME主机803和ME主机809上运行以与MEO 806交互。在示例完成阶段期间,完成了例如如参照图7所述的已经预先准备的MPTCP会话转移。目标MPTCP实例可以用与最近的数据传输相关的动态信息来更新。这种更新可以发生在所述准备步骤和完成步骤之间,之后数据业务可以经由MPTCP目标实例在WTRU和目标ME主机809之间交换。
图8的部分A示出了在WTRU 800上执行的WTRU App 810。图8的部分A中所示的各种元件和通信基本上类似于图7的部分A中所示的相应元件和通信。WTRU APP 810与在ME主机803上执行的ME App 813交互。WTRU App 810和ME App 813可分别以客户端-服务器关系进行运行。WTRU 800运行MPTCP栈816,并且ME主机803运行相应的MPTCP栈819。WTRU App 810创建TCP套接字811以经由相应的TCP套接字804与ME App 813通信。TCP套接字请求由MPTCP栈816截取,其基于TCP套接字请求811,利用到对应的MPTCP栈819的子流826,创建MPTCP会话,。数据业务829在WTRU App 810与ME App 813之间通过子流826被交换。
图8的部分B示出了在WTRU 800移动并锚定到ME主机809之后的上下文。图8的部分B中所示的各种元件和通信基本上类似于图7的部分B中所示的相应元件和通信。MEO 806被通知WTRU移动,并确定ME App 813应被移动到ME主机809以―跟随”WTRU。在该示例中,MEO806触发MPTCP会话转移的准备,并且MPTCP会话可被转移到ME主机809的MPTCP栈840。MPTCP栈840在WTRU 800和ME主机809之间创建新的预分配子流870(例如,其中子流870具有优先级―PRE_ALLOCATED”)。在图8的部分B的末尾,WTRU App 810与ME App 813之间的数据业务829继续经由ME主机809和通道833在子流826上被传输。
在图8的部分C中,MEO 806在步骤834触发ME App 813到ME主机809的转移。所转移的ME App在图8中称为ME App 849。MEO 806还在步骤850触发MPTCP会话转移完成。注意,应用转移(例如,步骤834)和MPTCP会话转移(例如,步骤850)可以并行地(例如,同时或并发地)执行。
MPTCP会话特定信息已经被转移到目标MPTCP栈840(在部分B),然而,由于数据传送在准备阶段期间可能继续,因此一些信息可能需要被更新(例如,MPTCP序列号)。在此示例中,该更新由MEO 806传送消息851以向ME主机803上的MPTCP栈819查询经更新的MPTCP会话信息(例如,通过使用―getsockopt”函数进行,如本文进一步讨论的)来处理,这可在消息852中返回所述信息。MEO 806将具有该信息的消息853传送到目标ME主机809上的MPTCP栈840(例如,通过使用如本文进一步讨论的―setsockopt”函数进行)。MEO 806可向ME主机803上的MPTCP栈819通知:所述MPTCP会话已被移动。目标ME主机809上的MPTCP栈840可通过传送消息855以将预分配子流870的优先级改变为REGULAR,从而完成其侧的MPTCP会话转移。
在子流870改变成常规子流之后,在步骤890中,通过从ME主机803上的MPTCP栈819向WTRU 800上的MPTCP栈816发送MPTCP消息891,关闭与ME主机803相关联的与所转移的MPTCP会话相关的所有子流,除了初始子流826之外。在该示例中,为了描述的方便,仅示出了1个子流;因此,用虚线示出了关闭其他子流的示例步骤。如前所述,所述初始子流是特殊情况,并且在一些实现中,即使它不再被用于传输数据业务,也被保留。因此,在这个示例中,通过从ME主机803上的MPTCP栈819向WTRU 800上的MPTCP栈816发送MP_PRIO消息893,与初始子流相关联的优先级被设置为―NOT_AVAILABLE”。初始TCP子流可以保持活动,尽管未被使用,直到在操作894处,其从WTRU侧被关闭或其期满(即,没有来自保活的响应)。当剩余子流被关闭时或者如果所述MPTCP会话被WTRU关闭,所述MPTCP会话可以被默默地丢弃。
在一些实现中,所述默默MPTCP会话丢弃在ME主机803上被本地独占处理;即,在这点上,没有任何东西被发送到WTRU,因为所述MPTCP会话可能仍然存在用于WTRU 800,并且被转移到不同的ME主机。因此,初始ME主机803上的MPTCP栈819可执行存储器清理以释放存储器。如果稍后ME App 849被转移到又一ME主机(例如ME主机3,未示出),则一旦完成MEApp和MPTCP的转移,与ME主机809相关联的所有子流可被关闭。ME主机2上的MPTCP会话也可被默默地丢弃。与ME主机803相比,该行为不同,因为初始子流与ME主机803相关联,而不与ME主机809相关联。因此,在转移ME App 849之后,ME主机809可被完全清理。
在部分C结束时,在步骤895完成到ME App 849的ME App转移,MPTCP会话转移完成,初始子流826被保留在非数据传送优先级(例如,―NOT_AVAILABLE”),并且数据业务829可在子流870上在WTRU 800上的WTRU App 810与ME主机809上的ME App 849之间被传送。
注意,在替换实施例(未示出)中,BACKUP优先级而不是PRE_ALLOCATED优先级可以用于在准备步骤期间创建的子流(例如,图8的部分B期间的子流870)。在这种情况下,在关闭初始ME主机上的所有子流(并且初始子流被设置为NOT_AVAILABLE)之后,与目标ME主机相关联的BACKUP子流可被用作正常备用子流。在MPTCP会话转移完成之后,该子流的优先级可以稍后被改变为REGULAR。
在该替换中,除了BACKUP标志之外,可能需要在BACKUP子流上设置额外的标志(例如,如在此进一步讨论的DON’T_USE(不使用)标志)。在准备阶段已经结束之后但在完成阶段已经开始之前初始子流失败的情况下,可能需要该额外的标志。在此类情况下,目标ME主机上的备用子流可不被使用,因为ME App尚未被转移到此ME主机上。相反,可使用来自初始ME主机的备用子流(如果有的话)。
所述编排器可使用一个或多个新API,例如,如下所述的API,以从在当前ME主机(例如,ME主机1)上运行的MPTCP栈获得MPTCP相关信息,并在目标ME主机(例如,ME主机2)上配置所述MPTCP栈。
所述ME App使用的套接字文件描述符(例如,―sockfd”)可使用ME主机上的现有命令(例如,类似―netstat”的命令)或通过查看系统文件(例如,类似―/proc/net/tcp”,―/proc/{pid}/fd”的系统文件)来获得。另一可能性可以是例如经由注册机制直接从ME App获得文件描述符。该信息可经由注册机制而被提供给编排器(MEP、MEPM或MEO)。注意,在这里的各种示例中,MEO知晓哪个WTRU正在移动,ME App知道哪个WTRU与哪个用户和哪个sockfd相关联,MEO需要知道MPTCP会话应当被转移到哪个sockfd,并且知晓MPTCP的MEApp可以直接触发所述MPTCP会话转移。
表2描述了用于创建与MPTCP会话相关联的套接字的函数―socket”的示例参量。新的套接字协议值(IPPROTO_MPTCP)可以使得能够创建由MPTCP栈处理的套接字,并且使用指定的文件描述符值。在创建该MPTCP套接字之后,可以期望使用setsockopt()的套接字配置。该套接字可在目标ME主机平台上被调用以创建与特定文件描述符(sockfd)相关联的套接字。使用指定描述符创建MPTCP套接字的API的示例如下:
socket(domain,type,proto,sockfd)
表2
表3描述了函数―get MPTCP session info(获取MPTCP会话信息)”的示例参量。与MPTCP会话相关的信息可以通过使用getsockopt()函数调用来检索。这可以通过引入新的套接字选项MPTCP_GET_INFO来实现。所述MPTCP会话可以由字段描述符(sockfd)来标识。用于检索MPTCP会话信息的套接字API的示例如下:
getsockopt(sockfd,IPPROTO_TCP,option,mptcp_info,mptcp_info_len)
表3
表4描述了函数―set MPTCP session info(设置MPTCP会话信息)”的示例参量。可以调用该函数以利用先前经由getsockopt(…,MPTCP_GET_INFO…)获得的信息来配置MPTCP会话。从当前ME主机分配的WTRU的IP地址也可以被指定。套接字API的示例如下:
setsockopt(sockfd,IPPROTO_TCP,option,mptcp_info,mptcp_info_len,nb_addr,WTRU’s local addr)
表4
表5描述了函数―set MPTCP session moved(设置MPTCP会话移动)”的示例参量。可调用此功能来通知所述MPTCP栈:指定的MPTCP会话已被移动。所述MPTCP栈在接收到该消息时,可能需要立即关闭除初始子流之外的所有子流,所述初始子流可能需要被维持但不再用于数据业务传输。在这种情况下,可以通过向WTRU发送MP_PRIO消息来在所述初始子流上设置优先级NOT_AVAILABLE。所述套接字API的示例如下:
setsockopt(sockfd,IPPROTO_TCP,option)
表5
| option | 被设置为MPTCP_SESSION_MOVED。 |
各种MPTCP消息和协议可用于本文公开的一个或多个实施例。例如,图9是示出了示例性的修改的子流优先级(MP_PRIO)选项的位图900。MPTCP消息的修改的MP-PRIO选项被增强以支持初始子流的保留,同时使用新的优先级将它们标记为不可用。该新的优先级是:MP_PRIO选项中的NOT_AVAILABLE(新)-N比特。在一些实现中,使用位图中的标记为―N”的位来设置该新的优先级。在示例实现中,标志(N)被设置为(1)以将优先级设置为NOT_AVAILABLE,否则其被设置为(0)。
图10和图11示出了位图1000和位图1100,其分别示出了用于初始SYN和用于响应SYN/ACK的示例性修改加入连接(MP_JOIN)选项。该修改的MP_JOIN选项被增强以支持优先级BACKUP和DON’T_USE的子流,并且在一些实现中,它可以被用作PRE_ALLOCATED优先级的替代。
新子流类型可以表示为:MSG中的DON’T_USE(新)-D位。在一些实现中,使用位图中的标记为―D”的位来设置新的子流类型。在一个示例实现中,标志(D)可以被设置为(1)以建立可能不用于数据传输的子流,甚至备用一常规子流;否则,它可以被设置为(0)。
上面讨论的各种实施例涉及由编排器(例如MEO)协调的MPTCP会话转移。相反,在一些实施例中,MPTCP移动性可以使用MPTCP栈之间的直接通信来处理。在一些示例中,所讨论的MPTCP栈是在初始连接到WTRU的ME主机(例如,ME主机1)上运行的MPTCP栈,以及在目标ME主机(例如,ME主机2)上运行的MPTCP栈。这样的栈通常处理服务器侧通信,因此,在MPTCP移动性使用这样的实例之间的直接通信来处理的实施方式涉及服务器到服务器通信,并且在一些实施方式中,对于客户端(即,WTRU)侧是透明的。
使用MPTCP栈之间的直接通信来处理MPTCP移动性的一些实施例涉及―非对等端”MPTCP栈之间的通信。
与发生在2个MPTCP对等端之间交换信息以创建具有相关子流的MPTCP会话来传输应用数据的典型通信相比,在一些实施例中,―非对等端”通信不传输数据业务(例如应用数据),而是将MPTCP会话信息转移到目标MPTCP栈,使得该目标MPTCP栈可以继续与WTRU上的MPTCP栈进行现有通信。为了处理该通信,可以在两个ME MPTCP栈之间建立IP连接。
图12是消息序列图,其示出了针对在准备阶段的示例MPTCP会话转移,WTRU 1200、第一ME主机1203、MEO 1206(或MEPM)以及第二ME主机1209之间的示例通信,其中MPTCP会话转移使用MPTCP栈之间的直接通信来处理。在这个示例中,MEO 1206与其关联的MEP实例MEP1和MEP 2一起被示出。在这个图中,MEP 1和MEP 2分别在ME主机1203和ME主机1209上运行,以与MEO 1206交互。图12的消息序列图在四个部分A、B、C和D中被示出和描述。
类似于编排器处理的方法,使用MPTCP栈之间的直接通信来处理MPTCP会话转移的实施例可包括准备阶段。在这种情况下,与所述MPTCP会话有关的信息可被转移到在另一ME主机上运行的另一MPTCP栈,以准备数据流转移。在一些实施例中,所述MPTCP会话转移由编排器(例如MEO)触发,编排器可通知适当的MEPM和/或MEP。此时,可以使用套接字接口来完成与MPTCP栈的交互。在一些实施例中,使用初始ME主机与目标ME主机之间的直接通信(例如,基于IP的通信)来执行所述MPTCP会话转移和相关信息的交换。
在图12的部分A中,WTRU 1200开始运行WTRU App 1210,该App正在或将要与运行在ME主机1203上的ME App 1213通信。MPTCP栈1216运行在WTRU 1200上,MPTCP栈1219运行在ME主机1203上,其中MPTCP栈1216和MPTCP栈1219是MPTCP对等端。WTRU App 1210创建TCP套接字1211以经由TCP连接与ME App 1213通信。套接字创建请求被MPTCP栈1216拦截,该MPTCP栈创建具有相关联的子流1226的MPTCP会话,在此之后数据业务1229可以在客户端应用侧和服务器应用侧(即,分别为WTRU App 1210和ME App 1213)之间交换。
在图12的B部分中,在步骤1230中,WTRU 1200移动,附着到ME主机1209处的新锚节点,并从ME主机1209获得新IP地址。尽管如图12所示,使用子流1226的数据路径比在步骤1230中的切换之前更长,但是可以为子流1226保持会话连续性。在该示例中,数据业务1229在两个锚定点之间被通道化传输;即,在当前连接的ME主机1209和先前连接的ME主机1203之间经由通道1233进行传输。
在步骤1236中,MEO 1206被通知(例如,由网络通知。例如,MEO 1206可向该网络注册以在WTRU移动/确实切换至另一PoA/锚定点时被通知)WTRU 1200的移动,并确定ME App1213应被移动至另一ME主机(即,ME主机1209)以―跟随”(即,物理上更靠近)所述WTRU。在步骤1239中,MPTCP栈1240(其没有任何相关联的子流)如果还没有运行的话,其在ME主机1209上被实例化,并且MEO 1206在步骤1241中触发MPTCP会话重定位的准备。
在这个示例中,MEO 1206(通过运行在ME主机11203上的MEP 1)使用ME主机1203上的本地套接字API 1242来获得要转移的MPTCP信息1243。信息1243可以包括例如WTRU 1200的IP地址、安全密钥等等。MPTCP栈1240被配置有从ME主机1203上的MPTCP栈1219获得的安全密钥。该密钥可用于允许建立与所转移的MPTCP会话相关联的新子流。MPTCP栈1240也被配置有由ME主机1209指派给WTRU 1200的IP地址。
这可以例如使用被改进为支持MPTCP会话转移的常规套接字API来完成,例如,如本文所讨论的。以这种方式基于套接字API来配置MPTCP栈1240的本地调用由消息1244、1245和1246示出。
在这一点上,所述密钥由ME主机1203和WTRU 1200使用,它们是与MPTCP会话相关联的两个对等端。例如,可以经由MEP API通知目标MPTCP栈:MPTCP会话重定位过程已经开始。在一些示例中,可以使用套接字接口或另一接口经由MEP API通知目标MPTCP栈;该接口可被描述成使得它可以是基于套接字的,或者可以是可存在于MEO 1206与运行ME主机1209的应用之间的任何其它接口。所述MEO 1206和ME主机1209上的目标MPTCP栈1240之间的该接口可用于使MEO 1206保持被通知所述转移状态。
由于在此示例中MEO 1206本身不处理所述转移,因此MEO 1206可能需要被告知(或接收它可用来确定的信息)何时触发ME App转移,诸如一旦MPTCP转移准备完成。所述目标MPTCP栈还可能需要被告知(或接收它可用来确定的信息)何时完成所述MPTCP会话转移,例如当ME App转移被触发时。
在图12的部分C,目标ME主机1209可启动它自己与ME主机1203之间的连接的建立,然后传送该信息。该两个ME主机之间的连接可以是TCP会话或添加到待重定位的MPTCP会话的子流。后者在图12的示例中说明。
如图所示,目标ME主机1209可例如使用消息1250来发起朝向当前ME主机1203的子流1253的创建。在该示例中,消息1250是建立MPTCP子流1253的MP_JOIN(重定位)消息。子流1253可与现有MPTCP会话相关联,并且可使用MPTCP子流优先级RELOCATION(重定位)(其与现有的REGULAR和BACKUP优先级相反)而被创建。在此示例中,所述RELOCATION优先级指示此子流1253可仅用于传输与MPTCP会话转移相关的信息(即,不传输数据业务)。对于该RELOCATION子流,要使用的安全密钥可以是当MPTCP转移被触发时(在步骤2)时配置的安全密钥。当目标ME主机使用所述WTRU的密钥时,当前ME主机可继续使用其密钥。
注意,在这一点,三个对等端与所述MPTCP会话相关联–所述WTRU 1200、当前ME主机1203、以及目标ME主机1209。每个MPTCP子流仅存在于两个对等端之间,然而,所述多个子流不具有相同的两个对等端。例如,子流1226存在于ME主机1203与WTRU 1200之间,而子流1253存在于ME主机1203与ME主机1209之间。如稍后将描述的,另一子流1260将存在于ME主机1209和WTRU 1200之间。
在此示例中,WTRU 1200不涉及子流1253,可能不知晓子流1253存在,并且不需要知道其两个对等端(即,ME主机1203和ME主机1209)是不同的。相反,WTRU 1200可将ME主机1203和ME主机1209视为相同的MPTCP对等端。
在ME主机1203和ME主机1209之间建立通信之后,MPTCP会话相关信息可被转移到目标ME主机1209。在该示例中,所述MPTCP会话相关信息使用消息1256经由子流1253而被转移。消息1256可以是例如MP_SET_INFO(info)消息。
在图12的D部分中,在所述MPTCP会话转移完成之后,在步骤1259,目标MPTCP栈1240触发与WTRU 1200的―预分配”子流1260的建立。在此情况下,且对于与WTRU的所有其它通信,目标ME主机1209可使用主机安全密钥,诸如ME主机1203安全密钥(而不是WTRU1200密钥用于重定位子流)。在该示例中,MPTCP栈1240可通过将消息1265发送到MPTCP栈1216来建立子流1260。应注意,在其它实施例(未示出)中,备选地,―预分配”子流创建(在目标ME主机1209与WTRU 1200之间)可由先前已向目标ME主机1209查询可用IP地址的当前ME主机1203触发。
此时,创建WTRU和目标主机之间的子流1260,尽管它还没有被用于传送应用数据业务,因为它是―预分配的”子流。相反,应用数据仍然经由子流1226在WTRU 1204上的WTRUApp 1210和ME主机1203上的ME App 1213之间交换。目标ME主机1209上的MPTCP栈1240使用消息1270通知MEO 1206:它已准备好用于所述转移传输的下一阶段。在该示例中,消息1270是Notify(RelocReady)消息。
注意,在其它实施例(未示出)中,可使用独立的TCP连接(即,从MPTCP会话―界限之外”的连接)来交换与要转移的MPTCP会话有关的信息,而不是使用与该MPTCP会话相关联的子流。在这种情况下,MEO 1206可以在每侧配置独立的安全密钥。一组新的安全密钥可用于服务器-服务器通信,并且可在以上图12的部分B期间在触发MPTCP会话转移时被配置(例如,使用图13中未示出的3次握手)。
图13是示出了针对在完成阶段的示例MPTCP会话转移,WTRU 1300、第一ME主机1303、MEO 1306(或MEPM)和第二ME主机1309之间的示例通信的消息序列图,其中MPTCP会话转移使用MPTCP栈之间的直接通信来处理。在这个示例中,MEO 1306与其相关联的MEP实例MEP 1和MEP 2一起被示出。在这个图中,MEP 1和MEP 2分别在ME主机1303和ME主机1309上运行,以与MEO 1306交互。在完成阶段期间,完成如这里所述的已经预先准备的MPTCP会话转移。目标MPTCP实例用与最近的数据传输相关的动态信息来更新,并且应用数据然后可以在WTRU和该MPTCP目标实例之间被交换。图13的消息序列图在四个部分A、B、C和D中被示出和描述。
在图13的部分A中,WTRU 1300开始运行WTRU App 1310,该App正在或将要与运行在ME主机1203上的ME App 1213通信。MPTCP栈1316在WTRU 1300上运行,并且MPTCP栈1319在ME主机1303上运行,其中MPTCP栈1316和MPTCP栈1319是MPTCP对等端。WTRU App 1310创建TCP套接字1311以经由TCP连接与ME App 1313通信。套接字创建请求被MPTCP栈1316拦截,其创建具有相关联的子流1326的MPTCP会话,之后数据业务1329可以在客户端应用侧和服务器应用侧(即,分别为WTRU App 1310和ME App 1313)之间被交换。
在图13的部分B中,WTRU 1300移动,附着到ME主机1309处的新的锚节点,并从ME主机1309获得新的IP地址。尽管如图13所示,使用子流1326的数据路径比步骤1330中的切换之前更长,但可以为子流1326保持会话连续性。在该示例中,数据业务1329在两个锚定点之间被通道化传输;即,在当前连接的ME主机1309和先前连接的ME主机1303之间通过通道1333而被传送。MEO 1306被通知(例如,由网络通知。例如,MEO 1306可向该网络注册以在WTRU移动/进行到另一PoA/锚定点的切换时被通知)WTRU 1300的移动,并确定ME App 1313应被移动到另一ME主机(即,ME主机1309)以―跟随”(即,物理上更靠近)所述WTRU。如果MPTCP栈1340(没有任何相关联的子流)尚未运行,则其在ME主机1309上被实例化,并且MEO1306触发MPTCP会话重定位的准备。
重定位子流1353在ME主机1303与ME主机1309之间被创建,MPTCP会话信息通过子流1353被转移到ME主机1309,并且预分配子流1360在ME主机1309与WTRU 1300之间被创建,如关于图12的重定位子流1253和预分配子流1260所描述的。尽管如图13所示,使用子流1326的数据路径比在WTRU 1300移动之前更长,但可为子流1326保持会话连续性。在该示例中,数据业务1329在两个锚定点之间被通道化传输;即,在当前连接的ME主机1309和先前连接的ME主机1303之间通过通道1333传输。
在图13的部分C中,MEO 1306在步骤1341触发ME App 1313到ME主机1309的作为MEApp 1345的转移。MEO 1306可能经由目标ME主机1309上的MEP向ME主机1309传送消息1347。在步骤1350,消息1347的接收可触发MPTCP会话转移完成阶段。在此阶段,MPTCP会话特定信息可能已经被转移到目标MPTCP栈1340,然而,由于数据传送在准备阶段期间可能继续,因此可能需要更新一些信息(例如,MPTCP序列号),这可在此点完成。目标MPTCP栈1340可例如使用消息1354(其可以是MP_RELOC_READY消息)通知当前MPTCP栈1319:其准备好接收最新信息并完成所述MPTCP会话转移。作为响应,MPTCP栈1319可例如使用消息1356(其可以是MP_SET_INFO消息)将更新后的信息发送到MPTCP栈1340。
在目标ME主机1309上接收到与MPTCP会话相关的更新信息之后,MPTCP栈1340可通过向MPTCP栈1316发送消息1359(其可为MP_PRIO消息)来将子流1360的优先级从PRE_ALLOCATED改变为REGULAR。对于在WTRU 1300和ME主机1309上的MPTCP栈1340之间建立的每个子流,这种优先权改变可以重复。然而,为了简单起见,在图13中仅示出了一个这样的子流1360。
由于到ME主机1309的MPTCP会话转移现在已完成,所以除了初始子流1326之外,在步骤1390中可通过发送MPTCP消息1391来关闭ME主机1303上的MPTCP栈1319与WTRU 1300上的MPTCP栈1316之间的子流。然而,注意,在该示例中,即使初始子流不再被使用,也保留该初始子流。所有其它这样的子流(如果有的话)可以被关闭。为了简单起见,在ME主机1的示例中仅使用1个子流(初始子流);因此,用虚线示出了关闭其他子流的示例步骤。
如前所述,所述初始子流1326是特殊情况,并且在一些实现中即使它不再用于传送数据业务也被保留。因此,在这个示例中,ME主机1303上的MPTCP栈1319通过从ME主机1303上的MPTCP栈1319向WTRU 1300上的MPTCP栈1316发送MP_PRIO消息1393来将初始子流优先级改变为―NOT_AVAILABLE”。
在部分C结束时,在步骤1395完成到ME App 1345的ME App转移,完成MPTCP会话转移,初始子流1326被保留在非数据传输优先级(例如,―NOT_AVAILABLE”),并且数据业务1329可通过子流1360在WTRU 800上的WTRU App 1310与ME主机1309上的ME App 1345之间传送。
在图13的部分D中,所述MPTCP会话可完全转移到ME主机1309。在一些实施例中,剩余的步骤可以用于清除目的。此时,不再需要用于服务器到服务器通信(即,在ME主机1303上的MPTCP栈1319与ME主机1309上的MPTCP栈1340之间的通信)的重定位子流1353,因此在1398使用FIN消息将其关闭。
在ME主机1303上,所述MPTCP会话可被默默地丢弃(即,其中没有消息被发送到WTRU)。对于ME主机1303,该MPTCP会话可能不再存在,然而,它仍可在具有ME主机1309作为新对等端的WTRU上使用。因此,所述初始TCP子流可以在ME主机1303和WTRU 1300上保持活动(尽管未被用于传输应用数据业务),直到它被WTRU 1300关闭或它期满(即,没有来自保活的响应)。ME主机1309上的MPTCP栈1340可使用消息1399(其可为Notify(RelocDone)消息)来通知MEO 1306:所述MPTCP会话转移已完成。
MEP API可以用于MPTCP会话重定位。以下API可被用于同步所述编排器和MPTCP栈转移阶段。在MPTCP会话信息转移中不涉及编排器的实施例中,可能需要通知它:MPTCP会话转移何时准备好用于ME App转移。可以假设在编排器/MEPM、MEP和运行在ME主机上的MEApp之间存在通信。在本文的示例中,在ME主机上运行的MPTCP栈可以是ME应用。在MPTCP会话转移经由当前MPTCP栈与目标MPTCP栈之间的直接通信来处理的情况下,该API可促进所述MPTCP会话转移。或者,该API可以使用套接字API来实现。以下是所述API的示例:
Notify(notification_type,params,params_len)。
以下是示例通知类型:
RelocPrep(重定位准备)、RelocReady(重定位准备好)、Reloc(重定位)、RelocDone(重定位完成)。
表6描述了示例RelocPrep通知参数。该通知可从MEP发送到目标MPTCP栈以通知MPTCP实例:将执行MPTCP会话转移,例如以触发所述准备阶段。在表6中列出了当使用该通知时可以指定的示例参数。
表6
| request ID | 标识所述请求的编号。将与―RelocReady()”调用相关联。 |
| sockfd | 标识所述MPTCP会话。在注册期间被获得。 |
表7描述了示例RelocReady通知参数。该通知可从目标MPTCP栈发送到MEP以指示所述准备步骤已完成,以及例如MPTCP栈已准备好继续所述MPTCP会话转移。
表7
| request ID | 标识所述请求的编号。从―RelocPrep()”调用获得。 |
表8描述了示例性Reloc通知参数。该通知可从MEP发送到目标MPTCP栈以触发所述MPTCP会话转移的完成。这可以触发所述完成阶段。
表8
| request ID | 标识所述请求的编号。将与―RelocDone()”调用相关联。 |
表9描述了示例RelocDone通知参数。该通知可从目标MPTCP栈发送到MEP以指示所述MPTCP会话转移完成。
表9
| request ID | 标识所述请求的编号。从―Reloc()”调用获得。 |
套接字API可由编排器使用以从运行在当前ME主机(例如,ME主机1)上的MPTCP栈获得MPTCP相关信息,并配置目标ME主机(例如,ME主机2)上的MPTCP栈。如本文先前所讨论的,可以使用创建MPTCP套接字API。
Get MPTCP_RELOC是一可以用于准备MPTCP会话的重定位的选项。它可被发送到当前ME主机(例如,ME主机1)以指示即将发生的MPTCP会话转移。同时,与MPTCP会话相关联的安全密钥可被检索并被转移到目标ME主机上。所指定的安全密钥是那些已经被ME主机(例如ME主机1)和WTRU使用的安全密钥。表10描述了Get MPTCP_RELOC API参数的示例。下面是所述套接字API的示例:
getsockopt(sockfd,IPPROTO_TCP,option,info,len)。
表10
Set MPTCP_RELOC是一可用于准备将MPTCP会话重定位到目标ME主机上的选项。它可被发送到目标ME主机(例如,ME主机2)以触发所述MPTCP会话转移并被配置所需信息,例如安全密钥。在其中指定的安全密钥可以是ME主机(例如ME主机1)和WTRU使用的安全密钥。
表11描述了示例Set MPTCP_RELOC API参数。以下是该套接字API的示例:
setsockopt(sockfd,IPPROTO_TCP,MPTCP_RELOC,info,len,nb_addr,WTRU’slocal addr)。
表11
各种MPTCP协议和消息可被修改和定义以支持MPTCP会话转移。例如,图14是示出了用于初始SYN的示例修改的加入连接(MP_JOIN)选项的位图1400。图15是示出了用于响应SYN/AC的示例性修改的加入连接(MP_JOIN)选项的位图1500。如本文所讨论的MP_JOIN选项可以被进一步增强以支持优先级RELOCATION的子流。
新的子流优先级可以表示为:RELOCATION-MSG中的R位。在一些实现中,示例标志(R)被设置为(1)以建立要用于与当前MPTCP栈和目标MPTCP栈之间(例如,服务器到服务器)的MPTCP会话重定位有关的信息转移的子流;否则,它可以被设置为(0)。
MP_SET_INFO是一可用于将MPTCP会话信息从当前MPTCP栈转移到目标MPTCP栈以准备MPTCP会话转移的选项。MP_SET_INFO还可以在完成阶段被使用,以更新在准备阶段可能已经改变的动态信息。可以使用该选项转移的信息的示例包括:来自ME主机1(即,初始主机)和运行在WTRU上的MPTCP对等端的安全密钥、令牌、MPTCP会话序列号。
MP_RELOC_READY是一可由目标MPTCP栈用于所述当前MPTCP栈以触发MPTCP会话转移的完成的选项。MP_RELOC_READY可以指示所述目标MPTCP栈准备好完成所述转移。
一些实施例包括ME App转移机制以支持所维持的连接性(即,其中不需要App在目标主机上开始新TCP会话)。这种机制可以包括对ME App和MPTCP栈这两者重用相同的套接字号。对于MPTCP,套接字信息可保存在被转移到目标主机上的MPTCP会话相关信息中。对于ME App,所述套接字号还可能需要添加到要转移到目标主机上的所述信息。
在一些情况下,所述MPTCP栈可能已经在目标ME主机上运行,并且MPTCP会话可能已经存在,其中它们中的一个可能正在使用与所转移的会话相同的会话号(或套接字号)。为了解决这样的情况,在一些实施例中,可使MPTCP套接字文件描述符(fd)值不同于常规TCP套接字fd(例如,MPTCP使用对其ME主机唯一的种子来生成其自己的套接字值)。在另一ME主机上生成这种号码的概率可能非常低。在目标平台上已经存在完全相同的套接字号的不太可能的情况下,所述MPTCP栈可以创建将在目标平台上使用的新的套接字号。该新的号码可以与所转移的MPTCP会话相关联,并且可以被用信号通知给所述编排器/MEPM/MEP。然后,新的套接字号可被转移到ME App并被添加到其要被转移的信息。
在一个实施例中,WTRU可以发起PRE_ALLOCATED子流的创建。NAT可防止ME主机建立朝向所述WTRU的新子流。在这种情况下,目标ME主机可将其可用地址传递到当前ME主机。可能已经与WTRU通信的当前ME主机可使用MPTCP ADD_ADDR选项来向所述WTRU通告目标主机可用地址。
图16是示出了示例性修改添加地址(ADD_ADDR)选项的位图1600。ME主机可能不具有关于WTRU(即,基于MPTCP ADD_ADDR消息)是否或何时创建新子流的控制。在一些实施例中,ME主机可能不能够强制WTRU创建(或通告WTRU应该)具有被设置为―预分配”的优先级的该新子流。
因此,在一些实施例中,ME主机可使用图16的修改的ADD_ADDR选项来实现这一点。在位图1600中,IPVer字段可表示IP地址版本(即,IPv4或IPv6)。因此,该4位字段可被设置为0100(4)或0110(6)。因此,两个比特可能足以编码该版本,最左边的比特和最右边的比特总是为0。因此,在一些实施例中,这两个比特可用于编码其它信息,例如所述优先级和立即比特,其通知接收机立即创建朝向指定地址的子流。如图16所示,在一些实施例中,位―D”可被设置为1以指示DON’T_USE(预分配)优先级,被设置为0以指示REGULAR。在一些实施例中,位―I”可以被设置为1以指示需要立即创建子流,否则,它可以被设置为0。
图17是消息序列图,其示出了示例NAT使用情况(其中WTRU发起PRE_ALLOCATED子流的创建),并且示出了使用在此讨论的第一方法(即,其中MPTCP会话转移由编排器使用套接字API协调)或第二方法(即,其中MPTCP会话转移经由当前ME主机上的MPTCP栈和目标ME主机上的MPTCP栈之间的直接通信来处理)的MPTCP会话转移的示例。图17示出了WTRU1700、第一ME主机1703、MEO 1706(或MEPM)和第二ME主机1709之间的示例通信。在该示例中,MEO 1706与其相关联的MEP实例MEP 1和MEP 2一起被示出。在该图中,MEP 1和MEP 2分别在ME主机1703和ME主机1709上运行以与MEO 1706交互。图17的消息序列图在两个部分A和B中被示出和描述。
部分A中所示的操作和信令与关于图12和图7所示和所述的操作和信令相同或相似。因此,为了简洁省略了部分A的详细描述。在部分B中,当前MPTCP栈1719可在步骤1750中使用所述第一方法或第二方法从目标ME主机1709获得可用地址。
例如,使用方法1,MEO 1706可以在1753处使用getsockopt(sockfd,MPTCP_GET_ADDR),其中所述套接字描述符和所述请求MPTCP_GET_ADDR可以在该请求上被指定,并且所述地址可以在响应消息1756中被返回。MEO 1706然后可在1759使用setsockopt(sockfd,MPTCP_SET_ADDR)来将该地址配置到初始ME主机1703上。在另一示例中,使用方法2,初始ME主机1703可在消息1763中将MP_GET_ADDR(MPTCP会话id,addr)发送到目标ME主机1709。可以在该请求中提供所述会话,并且可以在响应消息1766中返回所述地址。
在任一情况下,初始ME主机1703可在消息1770中将此地址发送到WTRU(使用MPTCP消息ADD_ADDR),同时请求立即创建新的预分配子流(例如,使用位I=1,以及D=1,如本文进一步讨论的)。在步骤1775,接收此请求的WTRU 1700可发起创建朝向接收地址的预分配子流,在此示例中,该接收地址是朝向目标ME主机1709的。WTRU 1700可在其可用地址中选择已经从当前锚节点(即,目标ME主机1709)获得的一个地址。WTRU 1700上的MPTCP栈1716向目标ME主机1709上的MPTCP栈1745发送MPTCP消息1780(在该示例中,MP_JOIN(PRE_ALLOCATED)消息),以发起所述子流的创建,并且因此在WTRU 1700和目标ME主机1709之间创建新的预分配子流1785。
注意,这个预分配的子流创建涉及三个对等端。初始ME主机1703通过配置要用于子流的地址并通过指定―立即创建”来触发所述子流创建。WTRU 1700和目标ME主机1709交换消息以建立所述子流。
一些实施例包括知晓MPTCP的ME App。如上所述,MPTCP会话转移过程可假定MEApp不知晓MPTCP使用。然而,在一些实施例中,所述转移过程可以与知晓MPTCP的应用一起使用,例如,通过较小的修改以利用MPTCP特定API。
例如,在当前ME主机上执行的ME App可使用MPTCP专用API来触发MPTCP会话转移。在要被转移的ME App知晓MPTCP使用的情况下,ME App本身可请求所述MPTCP会话转移。对于App,sockfd可以与需要跟随所述App转移的通信信道相关联。ME App可请求MPTCP会话移动性,使用MPTCP特定套接字API将适当的套接字文件描述符(sockfd)传递到MPTCP栈。编排器可触发所述ME App转移,但可能不涉及到所述MPTCP会话转移。
ME App实例可被转移到目标ME主机(如果它尚未运行),MPTCP会话也是如此。当前(源)ME主机上的知晓MPTCP的ME App可通过获得要被转移的MPTCP特定信息并通过将其转移到目标ME主机上来处理所述MPTCP会话转移。该转移可在ME App级别被处理。一旦MPTCP会话信息被目标ME主机上的ME App接收,它就可被传递到MPTCP栈。可使用如本文所讨论的第一方法(即,其中MPTCP会话转移由编排器使用套接字API来协调)或第二方法(即,其中MPTCP会话转移经由当前ME主机上的MPTCP栈与目标ME主机上的MPTCP栈之间的直接通信来处理)所定义的套接字API。所述sockfd(其对应于MPTCP会话标识符)如果已经在目标ME主机上被使用,则其可被修改。
源(初始)ME主机上的ME App从本地MPTCP栈(可能使用套接字接口)获得关于要被转移的MPTCP会话的信息,即,SRC App→获取要被转移的信息(sockfd)→SRC MPTCP。初始ME主机上的ME App将MPTCP会话信息转移到目标ME主机上的ME App,即,SRC App→转移MPTCP会话相关信息→DST App。目标ME主机上的ME App利用所接收的关于MPTCP会话的信息(可能使用套接字接口)来配置本地MPTCP栈,即,DST App→设置来自转移的MPTCP信息(sockfd)→DST MPTCP。
到目标ME主机上的MPTCP会话适配可经由MPTCP特定API来处理。MPTCP事件―MPTCP会话转移完成”可用于此目的。当MPTCP转移完成时,ME App可以接收该事件,同时指定在该点要用于继续与远程对等端(即,WTRU)通信的新套接字号。所述sockfd可以保持相同,这意味着如果它尚未在目标ME主机上被使用,则它可以不改变。如果该sockfd值已经被使用,则新的号可由MPTCP栈生成并与所转移的MPTCP会话相关联。该新号可经由该新MPTCP特定事件而被被本地发送到目标ME主机上的ME App。所述MPTCP栈→MPTCP转移完成((original_sockfd,new_sockfd)→ME App。
尽管上述按照特定组合描述了特征和元素,但是本领域技术人员将理解的是每个特征或元素可以被单独使用或以与其它特征和元素的任何组合来使用。此外,于此描述的方法可以在嵌入在计算机可读介质中由计算机或处理器执行的计算机程序、软件或固件中实施。计算机可读媒体的示例包括电子信号(通过有线或无线连接传输)和计算机可读存储媒体。计算机可读存储媒体的示例包括但不限于只读存储器(ROM)、随机存取存储器(RAM)、寄存器、缓冲存储器、半导体存储设备、诸如内部硬盘和可移除磁盘之类的磁媒体、磁光媒体、以及诸如CD-ROM碟片和数字多用途碟片(DVD)之类的光媒体。与软件相关联的处理器可以用于实施在WTRU、UE、终端、基站、RNC或任意主计算机中使用的射频收发信机。
Claims (20)
1.一种在无线发射/接收单元(WTRU)中实施的方法,该方法包括
在所述WTRU的处理单元上运行客户端应用,所述客户端应用被配置成通过传输控制协议(TCP)会话与在所述WTRU上运行的多点传输控制协议(MPTCP)栈传送数据业务;
通过与第一移动边缘(ME)主机设备的第一MPTCP子流来与服务器应用交换所述数据业务;
锚定到第二ME锚节点;
从第二ME主机设备接收第一消息,所述第一消息指示所述WTRU应当加入与所述第二ME主机设备的第二MPTCP子流;
响应于所述第一消息,加入所述第二MPTCP子流,其中所述第二子流被配置为不交换数据业务;
从所述第二ME主机设备接收第二消息,该第二消息将所述第二MPTCP子流配置为交换数据业务;
响应于所述第二消息,通过与所述第二ME主机设备的所述第二MPTCP子流来与所述服务器应用交换所述数据业务。
2.根据权利要求1所述的方法,其还包括从所述第一ME主机设备接收将所述第一子流配置为不交换数据业务的第三消息。
3.根据权利要求2所述的方法,其中所述第三消息配置所述第一子流以从常规优先级子流改变为不可用优先级子流。
4.根据权利要求2所述的方法,其中,所述第三消息包括MP_PRIO消息。
5.根据权利要求1所述的方法,其中所述第二消息配置所述第二子流应当改变为常规优先级子流。
6.根据权利要求1所述的方法,其中所述第二消息将所述第二子流配置为从预先分配的优先级子流改变为常规优先级子流。
7.根据权利要求1所述的方法,其中所述第二消息包括MP_PRIO消息。
8.根据权利要求1所述的方法,其中所述第一消息将所述第二子流配置为不交换数据业务。
9.根据权利要求1所述的方法,其中所述第一消息将所述第二子流配置为预先分配的优先级子流。
10.根据权利要求1所述的方法,其中所述第一消息包括MP_JOIN消息。
11.一种无线发射/接收单元(WTRU),该WTRU包括:
处理器,被配置成运行客户端应用,所述客户端应用被配置成通过TCP会话与在所述WTRU上运行的MPTCP栈传送数据业务;
收发信机,被配置为通过与第一移动边缘(ME)主机设备的第一MPTCP子流来与服务器应用交换所述数据业务;
所述处理器被配置为锚定到第二锚节点;
所述收发信机被配置成从第二ME主机设备接收第一消息,所述第一消息指示所述WTRU应当加入与所述第二ME主机设备的第二MPTCP子流;
所述处理器被配置为响应于所述第一消息而加入所述第二MPTCP子流,其中所述第二子流被配置为不交换数据业务;
所述收发信机被配置成从所述第二ME主机设备接收第二消息,该第二消息将所述第二MPTCP子流配置成交换数据业务;
所述收发信机被配置成响应于所述第二消息,通过与所述第二ME主机设备的所述第二MPTCP子流来与所述服务器应用交换所述数据业务。
12.根据权利要求11所述的WTRU,其中所述收发信机被配置成从所述第一ME主机设备接收将所述第一子流配置为不交换数据业务的第三消息。
13.根据权利要求12所述的WTRU,其中所述第三消息将所述第一子流配置为从常规优先级子流改变为不可用优先级子流。
14.根据权利要求12所述的WTRU,其中所述第三消息包括MP_PRIO消息。
15.根据权利要求11所述的WTRU,其中所述第二消息配置所述第二子流应当改变为常规优先级子流。
16.根据权利要求11所述的WTRU,其中所述第二消息配置所述第二子流以从预先分配的优先级子流改变为常规优先级子流。
17.根据权利要求11所述的WTRU,其中所述第二消息包括MP_PRIO消息。
18.根据权利要求11所述的WTRU,其中所述第一消息将所述第二子流配置为不交换数据业务。
19.根据权利要求11所述的WTRU,其中所述第一消息将所述第二子流配置为预分配的优先级子流。
20.根据权利要求11所述的WTRU,其中所述第一消息包括MP_JOIN消息。
Applications Claiming Priority (3)
| Application Number | Priority Date | Filing Date | Title |
|---|---|---|---|
| US201862622586P | 2018-01-26 | 2018-01-26 | |
| US62/622,586 | 2018-01-26 | ||
| PCT/US2019/015201 WO2019147970A1 (en) | 2018-01-26 | 2019-01-25 | Application mobility based on enhanced mptcp |
Publications (1)
| Publication Number | Publication Date |
|---|---|
| CN111837371A true CN111837371A (zh) | 2020-10-27 |
Family
ID=65409533
Family Applications (1)
| Application Number | Title | Priority Date | Filing Date |
|---|---|---|---|
| CN201980018379.XA Pending CN111837371A (zh) | 2018-01-26 | 2019-01-25 | 基于增强mptcp的应用移动性 |
Country Status (4)
| Country | Link |
|---|---|
| US (1) | US12445382B2 (zh) |
| EP (2) | EP4629586A3 (zh) |
| CN (1) | CN111837371A (zh) |
| WO (1) | WO2019147970A1 (zh) |
Cited By (3)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| CN113691589A (zh) * | 2021-07-27 | 2021-11-23 | 杭州迪普科技股份有限公司 | 报文传输方法、装置及系统 |
| CN114189912A (zh) * | 2021-12-21 | 2022-03-15 | 中国联合网络通信集团有限公司 | 会话方法、控制面功能实体及代理、会话系统 |
| WO2022267994A1 (zh) * | 2021-06-24 | 2022-12-29 | 中移(成都)信息通信科技有限公司 | 通信系统、方法、装置、第一设备、第二设备及存储介质 |
Families Citing this family (16)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| CN111416794B (zh) * | 2019-01-08 | 2022-07-29 | 华为技术有限公司 | 一种数据传输方法及电子设备 |
| US12425288B2 (en) * | 2019-02-12 | 2025-09-23 | Apple Inc. | Systems and methods to deploy user plane function (UPF) and edge computing virtualized network functions (VNFS) in network functions virtualization (NFV) environment networks |
| CN111866956B (zh) * | 2019-04-28 | 2023-07-14 | 华为技术有限公司 | 一种数据传输方法及对应的设备 |
| CN112367605A (zh) * | 2019-07-25 | 2021-02-12 | 中兴通讯股份有限公司 | 基于边缘计算的应用重定位方法及装置 |
| CN113994650B (zh) * | 2019-08-15 | 2024-07-19 | 三星电子株式会社 | 用于传输层上网络切换的方法和系统 |
| WO2021042400A1 (zh) * | 2019-09-06 | 2021-03-11 | 华为技术有限公司 | 路径切换方法、通信装置和通信系统 |
| KR102745241B1 (ko) * | 2019-09-09 | 2024-12-20 | 삼성전자주식회사 | 엣지 컴퓨팅 서비스를 위한 방법 및 장치 |
| US11228896B2 (en) * | 2019-09-20 | 2022-01-18 | Verizon Patent And Licensing Inc. | Authorization of roaming for new radio subscribers via an alternative radio access technology |
| US11824754B2 (en) * | 2019-12-03 | 2023-11-21 | Red Hat, Inc. | Multi-cluster networking using hub and spoke elastic mesh |
| TWI793399B (zh) * | 2020-02-14 | 2023-02-21 | 緯創資通股份有限公司 | 使用者裝置及資料流量傳遞之排程方法 |
| CN113573326B (zh) * | 2020-04-28 | 2023-08-22 | 华为技术有限公司 | 一种地址获取方法及装置 |
| CN114449585B (zh) * | 2020-10-31 | 2025-09-12 | 华为技术有限公司 | 应用接入网络的方法、装置及系统 |
| CN114531475A (zh) * | 2020-11-02 | 2022-05-24 | 中兴通讯股份有限公司 | 一种业务传输方法、通信设备及存储介质 |
| CN114845344A (zh) * | 2021-02-01 | 2022-08-02 | 华为云计算技术有限公司 | 一种多接入边缘计算网络、流量处理方法及相关设备 |
| CN112702362B (zh) * | 2021-03-24 | 2021-06-08 | 北京翼辉信息技术有限公司 | Tcp/ip协议栈的增强方法、装置、电子设备及存储介质 |
| US12255831B2 (en) | 2022-07-18 | 2025-03-18 | Cisco Technology, Inc. | Workload migration for multipath routed network sessions |
Citations (5)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| EP2538637A2 (en) * | 2011-06-22 | 2012-12-26 | Telefonaktiebolaget L M Ericsson (publ) | Multi-path transmission control protocol proxy service |
| CN104285472A (zh) * | 2014-04-24 | 2015-01-14 | 华为技术有限公司 | Mptcp连接的移动性管理方法和装置 |
| CN105874830A (zh) * | 2014-11-04 | 2016-08-17 | 华为技术有限公司 | 一种移动性管理的方法、装置及系统 |
| CN106465436A (zh) * | 2014-04-04 | 2017-02-22 | 诺基亚技术有限公司 | 利用多路径传输进行访问管理 |
| WO2017107203A1 (zh) * | 2015-12-25 | 2017-06-29 | 华为技术有限公司 | 业务传输方法、装置及设备 |
Family Cites Families (6)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| US20140321328A1 (en) | 2011-11-29 | 2014-10-30 | Interdigital Patent Holdings, Inc. | Methods For IP Mobility Management |
| KR20150110103A (ko) | 2014-03-24 | 2015-10-02 | 삼성전자주식회사 | 전송 경로 최적화를 위한 컨텐츠 서버 간 핸드오버 방법 및 장치 |
| WO2015168909A1 (zh) * | 2014-05-08 | 2015-11-12 | 华为技术有限公司 | 数据传输控制节点、通信系统及数据传输管理方法 |
| WO2015174901A1 (en) * | 2014-05-15 | 2015-11-19 | Telefonaktiebolaget L M Ericsson (Publ) | Method and devices for controlling usage of multi-path tcp |
| WO2016007051A1 (en) * | 2014-07-07 | 2016-01-14 | Telefonaktiebolaget L M Ericsson (Publ) | Multi-path transmission control protocol |
| CN108029060B (zh) * | 2015-10-09 | 2020-12-04 | 苹果公司 | 网络发起的分组数据网络连接 |
-
2019
- 2019-01-25 EP EP25196891.3A patent/EP4629586A3/en active Pending
- 2019-01-25 WO PCT/US2019/015201 patent/WO2019147970A1/en not_active Ceased
- 2019-01-25 US US16/964,795 patent/US12445382B2/en active Active
- 2019-01-25 EP EP19704959.6A patent/EP3744063B1/en active Active
- 2019-01-25 CN CN201980018379.XA patent/CN111837371A/zh active Pending
Patent Citations (5)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| EP2538637A2 (en) * | 2011-06-22 | 2012-12-26 | Telefonaktiebolaget L M Ericsson (publ) | Multi-path transmission control protocol proxy service |
| CN106465436A (zh) * | 2014-04-04 | 2017-02-22 | 诺基亚技术有限公司 | 利用多路径传输进行访问管理 |
| CN104285472A (zh) * | 2014-04-24 | 2015-01-14 | 华为技术有限公司 | Mptcp连接的移动性管理方法和装置 |
| CN105874830A (zh) * | 2014-11-04 | 2016-08-17 | 华为技术有限公司 | 一种移动性管理的方法、装置及系统 |
| WO2017107203A1 (zh) * | 2015-12-25 | 2017-06-29 | 华为技术有限公司 | 业务传输方法、装置及设备 |
Non-Patent Citations (1)
| Title |
|---|
| VINCENT JACQUOT: "Test Bed for Multipath TCP", 《AAALTO UNIVERSITY SCHOOL OF ELECTRICAL ENGINEERING》 * |
Cited By (5)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| WO2022267994A1 (zh) * | 2021-06-24 | 2022-12-29 | 中移(成都)信息通信科技有限公司 | 通信系统、方法、装置、第一设备、第二设备及存储介质 |
| CN113691589A (zh) * | 2021-07-27 | 2021-11-23 | 杭州迪普科技股份有限公司 | 报文传输方法、装置及系统 |
| CN113691589B (zh) * | 2021-07-27 | 2023-12-26 | 杭州迪普科技股份有限公司 | 报文传输方法、装置及系统 |
| CN114189912A (zh) * | 2021-12-21 | 2022-03-15 | 中国联合网络通信集团有限公司 | 会话方法、控制面功能实体及代理、会话系统 |
| CN114189912B (zh) * | 2021-12-21 | 2024-01-09 | 中国联合网络通信集团有限公司 | 会话方法、控制面功能实体及代理、会话系统 |
Also Published As
| Publication number | Publication date |
|---|---|
| EP4629586A2 (en) | 2025-10-08 |
| WO2019147970A1 (en) | 2019-08-01 |
| US20210058329A1 (en) | 2021-02-25 |
| EP4629586A3 (en) | 2025-11-19 |
| EP3744063A1 (en) | 2020-12-02 |
| EP3744063B1 (en) | 2025-09-24 |
| US12445382B2 (en) | 2025-10-14 |
Similar Documents
| Publication | Publication Date | Title |
|---|---|---|
| KR102830210B1 (ko) | Quic와의 다중 호스트 다중경로 보안 전송을 가능하게 하기 위한 방법들 및 장치들 | |
| CN111837371A (zh) | 基于增强mptcp的应用移动性 | |
| CN114430897B (zh) | 用于边缘解析功能的方法、装置和系统 | |
| EP4035436A1 (en) | Transparent relocation of mec application instances between 5g devices and mec hosts | |
| WO2021092441A1 (en) | Address change notification associated with edge computing networks | |
| US20210266254A1 (en) | Device to device forwarding | |
| WO2019014426A9 (en) | Communication path management | |
| WO2021237107A1 (en) | Method of wtru to network relay handover | |
| JP2023525557A (ja) | サービス機能識別子のトランスペアレントな交換のための方法及び装置 | |
| EP4154471A1 (en) | Method of multimedia broadcast/multicast service (mbms) delivery mode switch | |
| US20240155722A1 (en) | Network node apparatus and methods for achieving end-to-end reliability and improving fault tolerance in wireless systems | |
| TWI891740B (zh) | 以分佈式sfc控制執行區域生命週期管理之方法及裝置 | |
| US20240414020A1 (en) | Multicast-broadcast traffic delivery for distributed terminals | |
| US20250374355A1 (en) | Handset apparatus and methods for achieving end-to-end reliability and improving fault tolerance in wireless systems | |
| WO2024035880A1 (en) | Method and apparatus for service continuity in a personal internet-of-things (iot) network (pin) | |
| WO2024035879A1 (en) | Service continuity associated with inter pine communication changes from direct mode to using intermediate pegc | |
| WO2025175181A1 (en) | Extending mpquic protocol support in atsss | |
| KR20250172624A (ko) | Pegc에서의 ip 연결 변경에 대해 pine의 애플리케이션 클라이언트들에게 통지하기 위한 방법 | |
| WO2025075956A1 (en) | Methods and apparatus to manage indirect communication via gateways in personal internet of things (iot) networks | |
| WO2024211761A1 (en) | Method for initiating new pc5 link based on cause code |
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 | ||
| TA01 | Transfer of patent application right | ||
| TA01 | Transfer of patent application right |
Effective date of registration: 20230329 Address after: Delaware Applicant after: INTERDIGITAL PATENT HOLDINGS, Inc. Address before: Wilmington, Delaware, USA Applicant before: IDAC HOLDINGS, Inc. |