用于在通信网络中处理服务请求过程的方法和系统
技术领域
本公开涉及无线通信系统，并且更具体地，涉及用于在无线通信系统中处理服务请求过程的方法和系统。
背景技术
为了满足自部署4G通信系统以来增加的无线数据业务的需求，已经做出努力来开发改进的5G或预5G通信系统。因此，5G或预5G通信系统也被称为“超4G网络”或“后LTE系统”。5G通信系统被考虑在更高频率(毫米波)的频带(例如，60GHz频带)中实施，以便实现更高的数据速率。为了降低无线电波的传播损耗和增加传输距离，在5G通信系统中讨论了波束形成、大规模多输入多输出(multiple-input multiple-output，MIMO)、全维度MIMO(Full Dimensional MIMO，FD-MIMO)、阵列天线、模拟波束形成、大规模天线技术。此外，在5G通信系统中，基于先进小小区、云无线电接入网(Radio Access Network，RAN)、超密集网络、设备对设备(device-to-device，D2D)通信、无线回程、移动网络、协作通信、协作多点(Coordinated Multi-Points，CoMP)、接收端干扰消除等，正在进行系统网络改进的开发。在5G系统中，作为高级编码调制(advanced coding modulation，ACM)的混合FSK和QAM调制(Hybrid FSK and QAM Modulation，FQAM)和滑动窗口叠加编码(sliding windowsuperposition coding，SWSC)，和作为高级接入技术的滤波器组多载波(filter bankmulti carrier，FBMC)、非正交多址(non-orthogonal multiple access，NOMA)和稀疏码多址(sparse code multiple access，SCMA)已经被开发。
作为人类在其中生成和消费信息的以人为中心的连接网络的互联网现在正在演变为其中分布式实体(诸如事物)在没有人为干预的情况下交换和处理信息的物联网(IoT)。作为IoT技术和大数据处理技术通过与云服务器的连接的结合的万物互联(Internet of Everything，IoE)已经出现。随着IoT实施对“感测技术”、“有线/无线通信和网络基础设施”、“服务接口技术”和“安全技术”等技术元素的需求，最近已经对传感器网络、机器对机器(Machine-to-Machine，M2M)通信、机器类型通信(Machine TypeCommunication，MTC)等进行了研究。这种IoT环境可以提供智能互联网技术服务，其通过收集和分析联网事物之间生成的数据，为人类生活创造新的价值。通过现有信息技术(Information Technology，IT)与各种工业应用的融合和结合，IoT可以应用于各种领域，包括智能家居、智能建筑、智能城市、智能汽车或联网汽车、智能电网、医疗保健、智能电器和高级医疗服务。
与此相一致，已经进行了各种尝试来将5G通信系统应用于IoT网络。例如，诸如传感器网络、机器类型通信(MTC)和机器对机器(M2M)通信的技术可以通过波束形成、MIMO和阵列天线来实施。云无线电接入网(RAN)作为上述大数据处理技术的应用也可以被认为是5G技术和IoT技术之间的融合的示例。
当前的第三代合作伙伴计划(3rd Generation Partnership Project，3GPP)协议规定，用户设备(User Equipment，UE)100一次只能支持一个服务请求过程。当UE 100中涉及多个接入(3GPP接入和非3GPP接入)时，这造成影响。考虑正在通过3GPP进行服务请求过程时的示例场景。与此同时，其他接入(即，非3GPP)有数据/信令请求要发送到网络，UE 100必须等待直到在3GPP接入上完成服务请求过程才在非3GPP上触发服务请求，这可能导致在10秒至约2分钟之间不等的显著延迟。
如果由于另一接入上正在进行的服务请求过程而不允许某接入上的服务请求过程，则存在许多未被正确处理的现有场景。对于所有现有场景，考虑到UE 100和网络实体(包括网络实体内的通信)之间的消息交换，考虑完成服务请求过程的理想时间比如为10秒(类似于T3417)。
在现有场景中，UE 100的预置条件包括3GPP接入上的3GPP-5GMM-REGISTERED(3GPP 5GMM注册)、5GMM-CONNECTED(5GMM连接)模式和非3GPP接入上的Non-3GPP-5GMM-REGISTERED(非3GPP 5GMM注册)、5GMM-CONNECTED模式。如图1中所示，服务请求通过3GPP发起。然而，UE 100在非3GPP上注册，并且有数据要发送(非3GPP协议数据单元(ProtocolData Unit，PDU)也将被选择性地激活)，直到3GPP上的服务请求过程完成，才能发起服务请求。然而，假设3GPP服务请求没有失败或重试，直到在3GPP上完成服务请求过程，对于非3GPP PDU才将存在延迟。
如图1中所示，在1处，UE 100向5G核心网(5G Core Network，5GC)200发送3GPP上的服务请求(service request over 3GPP)。在2处，非3GPP PDU有数据要发送。在3处，在3GPP上在UE 100和5GC 200之间建立建立的用户平面/DRB。在4处，5GC 200向UE 100发送3GPP上的服务接受消息。在5处，UE 100向5GC 200发送非3GPP上的服务请求(servicerequest over the Non-3GPP)。
如图2中所示，在1处，UE 100向5GC 200发送3GPP上的服务请求。在2处，非3GPPPDU有数据要发送。在3-6处，UE 100向5GC 200重新发送3GPP上的服务请求。在7处，在3GPP上在UE 100和5GC 200之间建立建立的用户平面/DRB。在8处，5GC 200向UE 100发送3GPP上的服务接受消息。在9处，UE 100向网络200发送非3GPP上的服务请求。在10处，UE 100等待直到TX期满(比如1分钟)，并且在11处，UE 100发送非3GPP上的服务请求。
在另一现有的场景中，如图2中所示，针对在3GPP上的PDU1发起服务请求。同时，UE100对于在非3GPP上的PDU2有数据要发送。然而，由于(任何)异常情况，服务请求过程完成在3GPP上被延迟。此外，由于已经正在进行的3GPP上的服务请求过程，UE 100不能发送非3GPP上的服务请求。这种场景导致对于非3GPP PDU2的由于异常情况的在10秒至约2分钟范围内的显著延迟。一般地，根据3GPP规范，定时器T3325值是以最小60秒来定义的实施方式。因此，取决于由特定实施方式选择的T3325的定时器值，延迟可以超过150秒。
在另一现有的场景中，UE 100的预置条件包括3GPP接入上的3GPP-5GMM-REGISTERED、5GMM-CONNECTED模式和非3GPP接入上的Non-3GPP-5GMM-REGISTERED、5GMM-CONNECTED模式。针对在3GPP上的PDU1发起服务请求。现在，映射到低时延要求的应用/非3GPP PDU2(期望低时延的app)有数据要在3GPP/非3GPP上发送。并且，PDU2还没有建立的上行链路(uplink，UL)。直到正在进行的3GPP上的服务请求过程完成，才能针对PDU2触发新的服务请求。这种场景导致无法满足对低时延服务的5G要求。在没有针对第一服务请求(service request，SR)的重试的成功情况下，在UE 100能够为3GPP/非3GPP上的PDU2请求UL资源之前，将花费最多10秒。
在另一现有的场景中，UE 100的预置条件包括3GPP接入上的3GPP-5GMM-REGISTERED、5GMM-CONNECTED模式和非3GPP接入上的Non-3GPP-5GMM-REGISTERED、5GMM-CONNECTED模式。针对3GPP上的PDU1发起服务请求。并发地，网络200具有针对(通过非3GPP建立的)其他PDU(比如PDU2)的下行链路(downlink，DL)数据，对于该PDU，网络200通过3GPP向UE 100发送通知(在3GPP接入上UE发起的SR和网络发起的通知消息的交叉)。直到正在进行的3GPP上的服务请求过程完成，UE 100才能发起对针对非3GPP的通知的响应。然而，由于当前协议，这种场景导致从10秒至约2分钟(异常情况)不等的延迟。
在另一现有的场景中，UE 100的预置条件包括3GPP接入上的3GPP-5GMM-REGISTERED、5GMM-CONNECTED模式和非3GPP接入上的Non-3GPP-5GMM-REGISTERED、5GMM-IDLE(5GMM空闲)模式。在3GPP上发起服务请求。同时，非3GPP接入处于非3GPP上的5GMM-IDLE模式，并且当其获得非3GPP接入上的覆盖时，必须发送服务请求以进入5GMM-CONNECTED模式。然而，UE 100必须等待直到在3GPP接入上完成服务请求过程才发送非3GPP接入上的服务请求。这种场景可能发生得更频繁，因为基于非3GPP接入点，非3GPP覆盖可能很容易丢失和重新获得。此外，对于非3GPP而言，可能存在从10秒(假设服务请求没有失败或重试)至约2分钟(考虑到异常情况)的延迟。
在另一现有的场景中，UE 100的预置条件包括3GPP接入上的3GPP-5GMM-REGISTERED、5GMM-CONNECTED模式和非3GPP接入上的Non-3GPP-5GMM-REGISTERED、5GMM-CONNECTED模式。在3GPP上发起服务请求。这是该过程的首次尝试。现在，非3GPP需要发送针对移动发起(mobile originated，MO)数据的服务请求，但是必须等待直到在3GPP上服务请求过程完成。然而，3GPP上的服务请求的首次尝试失败。现在，应当为3GPP还是为非3GPP触发服务请求的问题出现了。此外，如何处理两个接入都具有其必须触发服务请求的条件的情况。然而，触发任一接入上的服务请求都将存在超过10秒至约2分钟的延迟。
在现有场景中，UE 100的预置条件包括3GPP上的3GPP-5GMM-REGISTERED、5GMM-IDLE以及非3GPP上的Non-3GPP-5GMM-REGISTERED、5GMM-CONNECTED，PDU3和PDU4与仅针对PDU3建立的UP一起存在。开始移动性注册更新过程。针对3GPP的PDU1生成数据。因为移动性注册更新过程正在进行，所以服务请求不能在3GPP上发送，并且被挂起，直到更新过程完成。针对非3GPP的PDU4生成数据。此时的行为应当是什么？此时UE 100能够发送非3GPP上的服务请求吗？在3GPP上成功完成移动性注册更新过程之后，出现以下两种情况之一，并且需要定义UE行为。情况1：如果在非3GPP上发送服务请求，则3GPP上的服务请求需要进一步等待，直到非3GPP上的服务请求过程完成。情况2：如果服务请求被挂起，那么哪个服务请求将首先被处理，是3GPP的还是非3GPP的？然而，在任何一种情况下，根据当前协议，接入上的一个服务请求的延迟的范围将在10秒至约2分钟之间。
在现有场景中，UE 100的预置条件包括3GPP接入上的PLMN 1的3GPP-5GMM-REGISTERED、5GMM-CONNECTED模式和非3GPP接入上的PLMN 2的Non-3GPP-5GMM-REGISTERED、5GMM-CONNECTED模式。在3GPP上(用PLMN 1注册)发起服务请求。然而，UE 100在非3GPP上(用PLMN 2)处于注册状态，并且有数据要发送(非3GPP PDU也将被选择性地激活)，直到完成在3GPP上的服务请求过程才能发起服务请求。然而，假设3GPP服务请求没有失败或重试，直到在3GPP上完成服务请求过程，对于非3GPP PDU才将存在延迟。这种场景下的延迟是不必要的，因为UE 100是在不同的PLMN上注册的。
因此，期望解决上述缺点或其他不足，或者至少提供有用的替代方案。
发明内容
技术问题
本文的实施例的主要目的是提供用于在无线通信系统中处理服务请求过程的方法和系统。
本文的实施例的另一目的是由UE将协议数据单元(PDU)会话类型配置为始终在线(always-ON)类型。
本文的实施例的另一目的是在初始PDU会话建立过程期间，由UE向网络发送PDU会话建立请求消息，该PDU会话建立请求消息包括PDU会话类型为始终在线类型。
本文的实施例的另一目的是由网络从UE接收PDU会话建立请求消息，该PDU会话建立请求消息包括PDU会话类型为始终在线类型。
本文的实施例的另一目的是由网络基于PDU会话建立请求消息来确定PDU会话类型为始终在线类型或正常PDU类型。
本文的实施例的另一目的是由UE向网络发起服务请求过程和注册请求过程中的一个，其中服务请求过程和注册请求过程中的一个在上行链路数据状态信息元素(information element，IE)请求中包括PDU会话类型为始终在线类型的PDU会话标识符。
本文的实施例的另一目的是在服务请求过程和注册请求过程中的一个期间，由网络激活用于处理服务请求的特定PDU会话的用户平面资源，而不管在上行链路状态信息元素(IE)请求中没有PDU会话类型为始终在线的指示。
本文的实施例的另一目的是由网络使用UE通用配置更新过程和PDU修改过程中的一个，动态地触发对应于始终在线类型的PDU会话类型到正常PDU类型或者正常PDU类型的PDU会话类型到始终在线类型的配置改变。
本文的实施例的另一目的是由UE动态地配置对应于始终在线类型的PDU会话类型到正常PDU类型或者正常PDU类型的PDU会话类型到始终在线类型的改变。
本文的实施例的另一目的是由UE在PDU会话建立请求消息中向网络指示PDU会话类型为始终在线类型和正常类型中的一个，而不管PDU建立原因。
本文的实施例的另一目的是由网络从UE接收作为始终在线类型和正常类型中的一个的PDU会话类型。
本文的实施例的另一目的是由网络基于PDU会话建立请求消息、网络中的配置和网络中的订阅中的一个来确定PDU会话类型是始终在线类型还是正常类型。
本文的实施例的另一目的是定义每当UE从CM IDLE(CM空闲)模式移动到CONNECTED(连接)模式时其用户平面资源活动的始终在线PDU。
本文的实施例的另一目的是在与网络建立PDU会话期间，通过上层(即，应用层)指示PDU是否是始终在线PDU。
本文的实施例的另一目的是每当UE发起服务请求或注册请求过程时在上行链路状态IE请求中包括类型为始终在线的PDU，以避免PDU的资源建立中的任何延迟。
本文的实施例的另一目的是当UE处于CONNECTED模式时，确保用于始终在线PDU的用户平面资源。
本文的实施例的另一目的是在初始PDU会话建立过程期间，在UE和网络之间的协商中，确定PDU是否是始终在线PDU。
本文的实施例的另一目的是，如果网络决定将PDU偏好类型从始终在线改变为正常，或者从正常改变为始终在线，则使用过程(例如，UE通用配置更新过程、PDU修改过程等)来动态触发配置改变。
问题的解决方案
因此，本文的实施例提供了用于在无线通信系统中处理服务请求过程的方法。该方法包括由用户设备(UE)将协议数据单元(PDU)会话类型配置为始终在线类型或正常PDU类型。此外，该方法包括在初始PDU会话建立过程期间，由UE向网络发送PDU会话建立请求消息以激活PDU会话，该PDU会话建立请求消息包括PDU会话类型为始终在线类型或正常PDU类型。即，UE发送始终在线PDU会话请求IE作为PDU会话建立请求(PDU SESSIONESTABLISHMENT REQUEST)的一部分，其值或者是请求始终在线PDU会话(指示UE请求为始终在线类型的PDU会话类型)，或者是不请求始终在线PDU会话(指示UE请求为正常PDU类型的PDU会话类型)。此外，术语正常PDU类型和非始终在线PDU会话可以互换使用。此外，该方法包括由网络从UE接收PDU会话建立请求消息，该PDU会话建立请求消息包括PDU会话类型为始终在线类型或正常PDU类型。此外，该方法包括由网络基于PDU会话建立请求消息或网络或本地配置信息中存储用于PDU会话的订阅参数，建立PDU会话类型为始终在线类型或正常PDU类型的PDU会话。
在实施例中，UE基于包括通用集成电路卡(Universal Integrated CircuitCard，UICC)的UE中的配置、从上层到NAS层的指示和来自网络的UE路由选择策略(UE RouteSelection Policy，URSP)命令中的一个，将PDU会话类型配置为始终在线类型。
在实施例中，在PDU会话建立过程期间，网络基于网络中的配置、网络中的订阅和来自UE的PDU会话类型为始终在线类型或正常PDU类型的指示中的一个，在PDU会话建立响应消息中将PDU会话配置为始终在线类型或正常PDU类型(即，例如，PDU会话建立接受(PDUSESSION ESTABLISHMENT ACCEPT)作为始终在线PDU会话指示IE的一部分，其值为需要始终在线PDU会话或不允许始终在线PDU会话)。
在实施例中，服务请求过程和注册请求过程中的一个在上行链路数据状态IE请求中包括PDU会话类型为始终在线类型的PDU会话标识符，即使用于PDU会话的用户平面资源没有被建立。
在实施例中，如果UE具有与发送服务请求消息的接入类型相关联的一个或多个活动的始终在线PDU会话，并且用于这些PDU会话的用户平面资源没有被建立，则UE将在服务请求消息中包括上行链路数据状态IE，并且指示UE针对那些PDU会话有挂起的用户数据要发送。
在实施例中，其中，如果网络(200)在来自网络(200)的PDU会话建立响应中没有向UE(100)指示PDU会话是否为始终在线类型或正常PDU类型中的一个，则UE(100)将PDU会话类型视为正常PDU类型，而不管UE配置如何。
因此，本文的实施例提供了用于在无线通信系统中处理服务请求过程的方法。该方法包括由UE向网络发起服务请求过程和注册请求过程中的一个。服务请求过程和注册请求过程中的一个在上行链路数据状态信息元素(IE)请求中包括PDU会话类型为始终在线类型的PDU会话标识符。
在实施例中，上行链路数据状态IE请求中PDU会话类型为始终在线类型的PDU会话标识符指示在上行链路数据状态IE中设置PDU会话ID的位图。
在实施例中，当UE从CM IDLE模式移动到CM-CONNECTED模式时，PDU会话类型为始终在线类型指示UE和网络之间的用户平面资源对于PDU会话始终被激活。
因此，本文的实施例提供了用于在无线通信系统中处理服务请求过程的方法。该方法包括由网络将PDU配置为始终在线。此外，该方法包括在服务请求过程和注册请求过程中的一个期间，由网络激活用于处理服务请求的特定PDU会话的用户平面资源，而不管在上行链路状态信息元素(IE)请求中没有PDU会话类型为始终在线的指示。
因此，本文的实施例提供了用于在无线通信系统中处理服务请求过程的方法。该方法包括由网络使用UE通用配置更新过程和网络发起的PDU会话修改过程中的一个，动态地触发对应于始终在线类型的PDU会话类型到正常PDU类型或者正常PDU类型的PDU会话类型到始终在线类型的配置改变。
因此，本文的实施例提供了用于在无线通信系统中处理服务请求过程的方法。该方法包括由用户设备(UE)动态地配置对应于始终在线类型的PDU会话类型到正常PDU类型或者正常PDU类型的PDU会话类型到始终在线类型的改变。此外，该方法包括由UE在PDU会话建立请求消息中向网络指示PDU会话类型为始终在线类型和正常类型中的一个，而不管PDU建立原因。此外，该方法包括由网络从UE接收作为始终在线类型和正常类型中的一个的PDU会话类型。此外，该方法包括由网络基于PDU会话建立请求消息、网络中的配置和网络中的订阅中的一个来确定PDU会话类型是始终在线类型还是正常类型。
在实施例中，PDU建立原因指示切换场景、紧急场景和正常场景中的至少一个。
在实施例中，在UE和网络处维持作为始终在线类型的PDU会话类型，该作为始终在线类型的PDU会话类型可以在5G和传统无线电接入技术(例如4G)之间的系统间改变期间使用。
因此，本文的实施例提供了用于处理服务请求过程的无线通信系统。该系统包括UE将协议数据单元(PDU)会话类型配置为始终在线类型或正常PDU类型，并在初始PDU会话建立过程期间向网络发送包括PDU会话类型为始终在线类型或正常PDU类型的PDU会话建立请求消息。网络从UE接收包括PDU会话类型为始终在线类型或正常类型的PDU会话建立请求消息，并基于PDU会话建立请求消息，建立PDU会话类型为始终在线类型或正常类型的PDU会话。
因此，本文的实施例提供了用于处理服务请求过程的无线通信系统。该系统包括被配置为向网络发起服务请求过程和注册请求过程中的一个的UE，其中，服务请求过程和注册请求过程中的一个在上行链路数据状态信息元素(IE)请求中包括PDU会话类型为始终在线类型的PDU会话标识符。
因此，本文的实施例提供了用于在无线通信系统中处理服务请求过程的网络。该网络包括与存储器和处理器耦合的协议数据单元(PDU)会话类型处理机。PDU会话类型处理机将PDU配置为始终在线，并且在服务请求过程和注册请求过程中的一个期间，激活用于处理服务请求的特定PDU会话的用户平面资源，而不管在上行链路状态信息元素(IE)请求中没有PDU会话类型为始终在线的指示。
因此，本文的实施例提供了用于在无线通信系统中处理服务请求过程的网络。该网络包括与存储器和处理器耦合的协议数据单元(PDU)会话类型处理机。PDU会话类型处理机使用UE通用配置更新过程和PDU修改过程中的一个，动态地触发对应于始终在线类型的PDU会话类型到正常PDU类型或者正常PDU类型的PDU会话类型到始终在线类型的配置改变。
因此，本文的实施例提供了用于处理服务请求过程的无线通信系统。该系统包括：UE动态地配置对应于始终在线类型的PDU会话类型到正常PDU类型或者正常PDU类型的PDU会话类型到始终在线类型的改变，并在PDU会话建立请求消息中向网络指示PDU会话类型为始终在线类型和正常类型中的一个，而不管PDU建立原因。网络从UE接收作为始终在线类型和正常类型中的一个的PDU会话类型，并且基于PDU会话建立请求消息、网络中的配置和网络中的订阅中的一个来确定PDU会话类型是始终在线类型还是正常类型。
当结合以下描述和附图考虑时，将更好地理解和明白本文的实施例的这些和其他方面。然而，应当理解的是，以下描述虽然指示了优选实施例及其许多具体细节，但是是以说明而非限制的方式给出的。在不脱离本文实施例的精神的情况下，可以在本文实施例的范围内进行许多改变和修改，并且本文的实施例包括所有这些修改。
发明的有益效果
本发明提供了用于在无线通信系统中有效处理服务请求过程的方法和系统。
此外，本发明提供了用于在无线通信系统中有效地将协议数据单元(PDU)会话类型配置为始终在线类型的方法和系统。
附图说明
本发明在附图中示出，在所有附图中，相同的参考字母指示不同附图中的相应部分。从下面参考附图的描述中将更好地理解本文的实施例，其中：
图1是示出根据现有技术的场景的序列图，其中，直到在3GPP上完成服务请求过程，非3GPP PDU存在延迟；
图2是示出根据现有技术的场景的序列图，其中，非3GPP PDU2存在由于异常情况而导致的延迟；
图3是示出根据本文公开的实施例的用于在单个接入上为3GPP和非3GPP PDU两者发送服务请求响应(接受/拒绝)的各种操作的序列图；
图4是示出根据本文公开的实施例的用于在两个接入上(3GPP、非3GPP单独地)为它们对应的PDU发送服务请求响应(接受/拒绝)的各种操作的序列图；
图5是示出根据本文公开的实施例的用于允许两个不同接入上的并发服务请求过程并维持每个接入的尝试计数器的各种操作的序列图；
图6是示出根据本文公开的实施例的用于维持每个接入的服务请求尝试计数器的各种操作的序列图；
图7是示出根据本文公开的实施例的用于允许每个会话的并发服务请求过程的各种操作的序列图，其中两个(独立的)服务请求会话都是成功的；
图8是示出根据本文公开的实施例的用于允许每个会话的并发服务请求过程的各种操作的序列图，其中UE保持尝试，直到UE独立地用尽每个会话的最大服务请求尝试限制；
图9是示出根据本文公开的实施例的在UE和5GC之间通信传送的各种信令消息的序列图；
图10是示出根据本文公开的实施例的在UE和5GC之间通信传送的各种信令消息的序列图；
图11是示出根据本文公开的实施例的处于3GPP的CM连接状态的PDU移动的序列图；
图12是示出根据本文公开的实施例的处于3GPP的CM连接状态的PDU移动的序列图；
图13是示出根据本文公开的实施例的当至少一个PDU的UL数据挂起时，UE将触发服务请求的序列图；
图14是示出根据本文公开的实施例的当没有上行链路数据挂起时，UE将触发移动性注册更新的序列图；
图15是根据本文公开的实施例的PDU会话建立过程的图示；
图16是根据本文公开的实施例的维持UE上下文的网络的图示；
图17是根据本文公开的实施例的在移动到RRC非活动状态时指令UE的网络的图示；
图18是根据本文公开的实施例的执行服务请求过程的图示；
图19是根据本文公开的实施例的请求的PDU会话的DRB的图示；
图20是根据本文公开的实施例的PDU会话重新激活结果的图示；
图21是根据本文公开的实施例的接收第二服务接受消息的图示；
图22是根据本文公开的实施例的完成UE角度SR过程的图示；
图23是根据本文公开的实施例的MME不检查S-TAU指示的图示；
图24是根据本文公开的实施例的MME检查S-TAU指示的图示；
图25是根据本文公开的实施例的用于网络将在PDU会话建立响应消息中向UE指示PDU是否是始终在线的方法的图示；
图26是根据本文公开的实施例的用于向UE动态配置PDU类型(是否是始终在线PDU)的方法的图示；
图27是根据本文公开的实施例的用于在无线通信系统中处理服务请求过程的系统的示意图；和
图28-图30是示出了根据本文公开的实施例的由无线通信系统实施的处理服务请求过程的各种操作的流程图。
具体实施方式
参考在附图中示出并在以下描述中详细描述的非限制性实施例，更全面地解释本文的实施例及其各种特征和有益细节。省略了对众所周知的组件和处理技术的描述，以免不必要地模糊本文的实施例。此外，本文描述的各种实施例不一定是互斥的，因为一些实施例可以与一个或多个其他实施例组合以形成新的实施例。除非另有说明，否则本文使用的术语“或”是指非排他性的“或”。本文使用的示例仅仅意在便于理解可以实践本文的实施例的方式，以及进一步使本领域技术人员能够实践本文的实施例。因此，这些示例不应被解释为限制本文的实施例的范围。
如本领域中的传统，实施例可以按照执行所描述的一个或多个功能的块来描述和说明。这些块(在本文可以被称为单元或模块等)由模拟或数字电路(诸如逻辑门、集成电路、微处理器、微控制器、存储器电路、无源电子组件、有源电子组件、光学组件、硬连线电路等)物理地实施，并且可以可选地由固件和软件驱动。电路可以例如被体现在一个或多个半导体芯片中，或者被体现在诸如印刷电路板等的基底支撑上。构成块的电路可以由专用硬件实施，或者由处理器(例如，一个或多个编程的微处理器和相关电路)实施，或者由执行块的一些功能的专用硬件和执行块的其他功能的处理器的组合来实施。在不脱离本发明的范围的情况下，实施例的每个块可以物理地被分成两个或更多个相互作用和分立的块。同样，在不脱离本发明的范围的情况下，实施例的块可以物理地组合成更复杂的块。
附图用于帮助容易地理解各种技术特征，并且应当理解，本文呈现的实施例不受附图的限制。因此，除了在附图中具体阐述的那些之外，本公开还应当被解释为扩展到任何变更、等同物和替代物。虽然术语第一、第二等可以在本文用于描述各种元件，但是这些元件不应受这些术语的限制。这些术语通常仅用于区分一个元件和另一元件。
本文的实施例实现了用于在无线通信系统中处理服务请求过程的方法。该方法包括由用户设备(UE)将协议数据单元(PDU)会话类型配置为始终在线类型或正常PDU类型。此外，该方法包括在初始PDU会话建立过程期间，由UE向网络发送PDU会话建立请求消息，该PDU会话建立请求消息包括PDU会话类型为始终在线类型或正常PDU类型。此外，该方法包括由网络从UE接收PDU会话建立请求消息，该PDU会话建立请求消息包括PDU会话类型为始终在线类型或正常PDU类型。此外，该方法包括由网络基于PDU会话建立请求消息建立PDU会话类型为始终在线类型或正常PDU类型的PDU会话。
始终在线类型对应于请求始终在线PDU会话。正常PDU类型对应于不请求始终在线PDU会话。
始终在线PDU会话：对于其用户平面资源必须在从5GMM-IDLE模式到5GMM-CONNECTED模式的每次转换期间被激活的PDU会话。UE基于来自上层(即，应用层)的指示请求将PDU会话建立为始终在线PDU会话，并且网络决定PDU会话是否被建立为始终在线PDU会话。
与传统系统和方法不同，所提出的方法可以用于降低给定接入内服务请求过程的两个触发器之间的延迟。所提出的方法可以用于在为延迟敏感PDU会话建立用户平面资源时避免延迟。假设从UE发送第一服务请求消息，同时NAS层接收为延迟敏感PDU会话(比如PDU会话“x”)建立用户平面资源的请求。现在，在UE能够通过重新触发服务请求过程来请求用于PDU会话“x”的用户平面资源之前，UE被迫等待直到第一服务请求过程完成。这种延迟对于延迟敏感服务(如任务关键型)是不可接受的。
为了解决上述问题，UE和网络首先协商PDU会话是否是延迟敏感PDU会话，并将其称为始终在线PDU会话。此外，在每个服务请求过程(或注册请求过程)中，如果用户平面资源不可用，UE也为始终在线PDU会话请求用户平面资源。因此，当服务请求过程或注册过程正在进行时，如果有上行链路数据要被发送用于始终在线PDU会话，则用户平面资源对于UE来说可容易地用于发送上行链路数据，并且在请求用户平面资源同时等待第一服务请求过程完成时没有延迟。换句话说，第一服务请求过程或注册过程已经携带为始终在线PDU会话建立用户平面资源的请求。因此，UE不需要为始终在线PDU会话发起第二服务请求过程，而是在完成第一服务请求过程或注册过程之后其将立即获得所需的用户平面资源。
所提出的方法可以用于完全避免单个接入上的服务请求过程之间的延迟，因为它们被视为独立的过程。所提出的方法可以用于解决多接入在服务请求过程的触发中的依赖性，以显著降低延迟。
所提出的方法可以用于发送单个服务请求，该单个服务请求包括要被激活的3GPP和非3GPP PDU两者的列表，同时维持单个尝试计数器。所提出的方法可以用于允许两个不同接入上的并发服务请求过程，并维持每个接入的尝试计数器。这将任一接入的延迟降低到预定值。
该方法可以用于降低无线通信系统中的数据平面建立时延。所提出的方法可以用于降低信令开销，该信令开销由于如下原因而避免：如果UE上下文被删除则需要为所有PDU执行PDU建立过程，并且寻呼也可以从MME转发到AMF，使得至少对于高优先级PDU或紧急情况，UE不会由于当前限制而错过任何寻呼。
该方法可以用于通过如UE通用配置更新、网络发起的PDU会话修改的过程或来自网络的支持UE的动态配置的任何过程提供的PDU类型(即，是否是始终在线PDU)的动态配置。
所提出的方法可以用于允许每个会话的并发服务请求过程，其中每个会话由新的标识符“服务请求标识符(Service Request Identifier，SRI)”组成以在会话之间进行区分并且每个会话独立地维持尝试计数器、过程的相关定时器(T3517、T3325)。这导致降低了在3GPP和非3GPP接入之间触发服务请求之间的延迟。
在实施例中，该方法可以用于发送单个服务请求，该单个服务请求包括要被激活的3GPP和非3GPP PDU两者的列表，同时维持单个尝试计数器。这将任一接入的延迟降低到预定值。在另一实施例中，该方法可以用于允许两个不同接入上的并发服务请求过程，并维持每个接入的尝试计数器。这将完全避免接入之间的任何延迟。在另一实施例中，该方法可以用于允许每个会话的并发服务请求过程，其中每个会话由标识符“服务请求标识符(SRI)”组成以在会话之间进行区分并且每个会话独立地维持尝试计数器、过程的相关定时器(T3517、T3325)。
在实施例中，该方法允许3GPP和N3GPP(非3GPP)接入处于空闲(IDLE)模式，并且UE利用N3GPP接入获得3GPP中的寻呼。此外，UE可以被配置为发送具有可移动的N3GPP PDU的允许列表的服务请求。同时，UE试图通过发送服务请求在N3GPP中移动到CM_CONNECTED状态。该服务请求不应包含在3GPP服务请求中发送的“处于PDU的允许列表中的”PDU。它可以包含基于上行链路数据的“处于PDU的允许列表中”的3GPP中的服务请求中未发送的PDU的列表。
在实施例中，该方法允许3GPP接入处于CM-CONNECTED状态并且N3GPP接入处于IDLE模式，并且UE获得具有PDU会话标识(id)的针对N3GPP的下行链路数据的通知。如果通知已经到来的PDU会话被允许在3GPP上移动，则UE可以被配置为发送服务请求，否则UE将发送通知响应。同时，如果UE试图通过发送服务请求在N3GPP中移动到CM_CONNECTED状态。该服务请求不应包含在3GPP中针对下行链路数据的通知已经到来的PDU，并且如果该服务请求被允许在3GPP上被重新激活。服务请求可以包含不被允许在3GPP上被激活或者在3GPP中通知没有到来的基于上行链路数据的N3GPP PDU。
在实施例中，该方法允许UE在至少一个PDU的UL数据挂起时触发服务请求。在实施例中，该方法允许UE在没有上行链路数据挂起时触发移动性注册更新。
在所提出的方法中，寻呼可以从移动性管理实体(Mobility Management Entity，MME)转发到认证管理功能(Authentication management function，AMF)，使得至少对于高优先级PDU或紧急情况，UE不会由于当前限制而错过任何寻呼。该方法可以用于降低5G网络中的数据平面建立时延。
在实施例中，当通过考虑其中上层通知NAS为始终在线PDU或优先PDU的这样的高优先级PDU而请求建立与网络的PDU会话时，应用处理器(application processor，AP)或上层向通信处理器(communication processor，CP)或NAS层提供PDU类型(高优先级、低时延或延迟不容忍、请求PDU的应用类型等)。这种关于始终在线PDU的信息被保持在CP处，并用于在随后的服务请求或注册过程中每当这些过程被触发时就设置上行链路数据状态IE(例如，在RLF之后，由于挂起的数据等，发起SR)。AT命令也可以用于向调制解调器或NAS层指示哪些PDU将被认为是始终在线PDU。
在实施例中，当UE正在激活这种始终在线PDU时，则它将在PDU建立过程期间通知网络，并且网络使用始终在线PDU的UE指示来管理由于在RAN侧的非活动定时器期满而导致的DRB释放。当在RAN处针对始终在线PDU的非活动定时器期满时，则当为多于1个PDU建立用户平面资源时，网络不应释放映射到该特定的始终在线PDU的DRB。当在RAN处针对始终在线PDU的非活动定时器期满，并且没有用于该UE的建立了用户平面资源的其他PDU时，则网络将把该UE移动到RRC非活动状态。
在另一实施例中，当发送服务请求或注册请求消息时，UE使用上行链路数据状态IE来标记其数据挂起的PDU。在这样做的同时，UE可以采用以下两种方法中的任何一种。在上行链路数据状态IE中标记所有始终在线PDU(没有用户平面资源或没有DRB)。在上行链路数据状态IE中标记所有活动PDU(没有用户平面资源或没有DRB)。可替代地，当发送服务请求或注册请求消息时，如果UE具有始终在线PDU，则UE将向网络指示它需要DRB用于所有活动PDU。在这种情况下，网络应当为UE的所有活动PDU建立用户平面资源。此外，如果由于任何异常场景，UE和网络之间的连接丢失，则预期网络将在再次建立连接之后与UE重新建立用于始终在线PDU的用户平面资源。
在另一实施例中，如果UE在其等待完成正在进行的服务请求过程的同时接收到新的PDU会话ID(始终在线PDU)的上行链路数据，则UE可以中止当前正在进行的服务请求过程并进行新的服务请求过程。当发送服务请求时，UE使用上行链路数据状态IE标记其数据挂起的PDU。在这样做的同时，UE可以采用以下两种方法中的任何一种。在上行链路数据状态IE中标记所有始终在线PDU(没有用户平面资源或没有DRB)。在上行链路数据状态IE中标记所有活动PDU(没有用户平面资源或没有DRB)。可替代地，当发送服务请求或注册请求消息时，如果UE具有始终在线PDU，则UE将向网络指示它需要DRB用于所有活动PDU。在这种情况下，网络应当为UE的所有活动PDU建立用户平面资源。此外，在UE侧，通过检查是否为对于其用户平面无线电资源在最近发送的服务请求消息中被请求并且在PDU会话重新激活结果IE中被指示成功激活的所有(一个或多个)PDU会话ID建立了DRB，SR过程被标记为完成。AT命令也可以用于向调制解调器或NAS层指示哪些PDU将被认为是始终在线PDU。
在另一实施例中，UE在最近的服务请求中不立即请求已经请求的PDU，其中AT命令还可以用于向调制解调器或NAS层指示哪些PDU将被认为是始终在线PDU。
该方法可以用于在无线通信系统中识别始终在线PDU会话。该方法可以用于动态地改变PDU会话类型(即，始终在线类型到正常PDU类型或正常PDU类型到始终在线类型)。该方法可以用于处理两个网络之间(例如，4G网络到5G网络或5G网络到4G网络)的PDU移动。
现在参考附图，更具体地，参考图3至图30，示出了优选实施例。
图3是示出根据本文公开的实施例的用于在单个接入上为3GPP和非3GPP PDU两者发送服务请求响应(接受/拒绝)的各种操作的序列图。
在1处，UE 100通过3GPP向网络200发送服务请求(PTI＝1)。在1a处，3GPP上服务请求的首次尝试失败。在2处，非3GPP PDU有数据要发送。在3处，UE 100通过3GPP向网络200发送包括3GPP PDU和非3GPP PDU两者的服务请求。在4处，为3GPP PDU和非3GPP PDU两者建立用户平面/DRB。在5处，UE 100从网络200接收包括用于3GPP PDU和非3GPP PDU两者的PDU会话状态的服务接受消息。
如图3中所示，该方法包括发送包括3GPP和非3GPP PDU两者的单个服务请求，并维持单个尝试计数器。这将任一接入的延迟降低到最大10秒。考虑一系列场景：
服务请求在5GMM-CONNECTED模式中通过3GPP触发，可选地，包括过程事务标识(Procedure Transaction Identity，PTI)以唯一地标识会话/过程，
5GMM-CONNECTED模式下的非3GPP PDU有MO数据要发送，
3GPP上的服务请求过程的首次尝试由于任何异常场景而失败，
(a)下一服务请求尝试应当包括要被激活的3GPP和非3GPP PDU两者，将尝试计数器递增1。因此，将延迟降低到最大T3517秒，(或)
(b)下一服务请求尝试应当包括要被激活的3GPP和非3GPP PDU两者，将尝试计数器重置为0。因此，将延迟降低到最大T3517秒，(或)
(c)下一服务请求尝试应当包括要被激活的3GPP和非3GPP PDU两者，而不改变尝试计数器的值。因此，将延迟降低到最大T3517秒。
网络200以两种方式中的任一种发送对UE 100发送的服务请求的响应(服务接受或服务拒绝)：
如图3中所示，针对3GPP和非3GPP PDU两者的服务请求响应(接受/拒绝)都是在单个接入上发送的，单个接入优选地是触发服务请求的接入，如果UE的SR消息包括PTI，则可选地维持与服务请求消息中相同的PTI。
图4是示出根据本文公开的实施例的用于在两个接入上(3GPP、非3GPP单独地)为它们对应的PDU发送服务请求响应(接受/拒绝)的各种操作的序列图。
如图4中所示，在1处，UE 100通过3GPP向网络200发送服务请求。在1a处，3GPP上服务请求的首次尝试失败。在2处，非3GPP PDU有数据要发送。在3处，UE 100通过3GPP发送包括3GPP PDU和非3GPP PDU两者的服务请求。在4a处，为3GPP PDU建立用户平面/DRB。在4b处，UE 100接收包括3GPP PDU的PDU会话状态的服务接受消息。在4c处，为非3GPP PDU建立用户平面/DRB。在4d处，UE 100接收包括非3GPP PDU的PDU会话状态的服务接受消息。
结合图3，网络200向UE 100发送响应(服务接受或服务拒绝)。在两个接入上(3GPP、非3GPP单独地)为它们对应的PDU，服务请求响应(接受/拒绝)被发送，并且如果UE的SR消息包括PTI，则可选地维持相同的PTI。
此外，在服务接受/拒绝消息IE中需要新添加PTI和表示最终响应位的新的位(F)，以指示响应消息是针对单个接入还是两个接入：
A.如果该字段未被设置，则当前响应是针对接入中的一个的，并且UE需要等待针对另一接入的服务响应消息，或者等待直到过程定时器T3517期满以将过程标记为完成，
B.如果该字段被设置(这意味着网络正在发送针对3GPP和非3GPP两者一起的响应)，并且UE 100将过程标记为完成。
备用八位字节中的一位可以用于上述目的。->位的位置需要待讨论。
服务拒绝的具体情况：如果以下原因代码中的任何一个在一个接入上进入服务拒绝，则它自动适用于另一接入。
原因代码#3-非法UE，
原因代码#6-非法ME，
原因代码#8-5GS服务不允许，
原因代码#11-PLMN不允许，
原因代码#22-拥塞(3GPP、非3GPP的核心网相同)，以及
原因代码#xx-N1模式不允许(3GPP、非3GPP用相同PLMN注册)。
所有上述提议都适用于当UE利用相同AMF在3GPP和N3GPP中在相同PLMN上注册的情况。
图5是示出根据本文公开的实施例的用于允许两个不同接入上的并发服务请求过程并维持每个接入的尝试计数器的各种操作的序列图。
如图5中所示，在1处，服务请求过程正在UE 100和网络200之间在3GPP上进行(包括PTI＝1)。在2处，非3GPP PDU有数据要发送。在3处，通过非3GPP向网络200触发服务请求过程(包括PTI＝2)。在4处，为3GPP PDU建立用户平面/DRB，并且在5处，为非3GPP PDU建立用户平面/DRB。在6处，UE 100通过3GPP接收服务接受消息(PTI＝1)，并且在7处，UE 100通过非3GPP接收服务接受消息(PTI＝2)。
如图5中所示，该方法包括在两个不同的接入上允许并发服务请求过程，并维持每个接入的尝试计数器。这将不涉及接入之间的任何延迟。
1.在5GMM-CONNECTED模式下通过3GPP触发服务请求。
2. 5GMM-CONNECTED模式下的非3GPP PDU有MO数据要发送。
3.现在，UE 100通过非3GPP发送服务请求，而不等待正在进行的3GPP上的服务请求过程的结果。
4.每个接入都可以触发服务请求过程，而无需等待另一接入。此外，维持独立的尝试计数器并独立地处理过程。
使用这种提议的方法，在对数据或信令过程的接入之间将不会有任何种类的依赖性和延迟。
图6是示出根据本文公开的实施例的用于维持每个接入的服务请求尝试计数器的各种操作的序列图。如图6中所示，MSC描绘了服务请求尝试计数器是如何按每个接入维持的。
如图6中所示，在1处，服务请求过程在3GPP上进行(包括PTI＝1)。在2处，非3GPPPDU有数据要发送。在3处，UE 100通过3GPP重新发送服务请求过程(包括PTI＝1)。在4处，通过非3GPP触发服务请求过程(包括PTI＝2)。在5处，为3GPP PDU建立用户平面/DRB，并且在6处，为非3GPP PDU建立用户平面/DRB。在7处，UE 100通过3GPP接收服务接受消息(PTI＝1)。在8处，UE 100通过非3GPP接收服务接受消息(PTI＝2)。
图7是示出根据本文公开的实施例的用于允许每个会话的并发服务请求过程的各种操作的序列图，其中两个(独立的)服务请求会话都是成功的。
如图7中所示，在1处，UE 100通过3GPP向网络200发送SR＝1的针对PDU 1的服务请求。在2处，PDU2有数据要发送。在3处，UE 100通过3GPP发送SR＝2的针对PDU2的服务请求。在4a处，为3GPP PDU 1建立用户平面/DRB。在4b处，UE接收针对PDU 1的SR＝1的服务接受消息。在5a处，为3GPP PDU2建立用户平面/DRB。在5b处，UE接收针对PDU2的SR＝2的服务接受消息。在6a处，为PDU 1建立用户平面/DRB。在6b处，为PDU 2建立用户平面/DRB。在6c处，UE100接收包括PDU会话状态的服务接受消息。
如图7中所示，该方法包括允许每个会话的并发服务请求过程，其中每个会话由新的标识符“服务请求标识符(SRI)”组成以在会话之间进行区分并且每个会话独立地维持尝试计数器、过程的相关定时器(T3517、T3325)。这将完全避免接入上的请求之间的任何延迟。这可以被称为“基于SRI的服务请求”过程。
在实施例中，该方法仅包括两个服务请求会话。此外，允许的并发会话数量取决于实施方式。
1.在5GMM-CONNECTED模式下，针对PDU1通过3GPP触发服务请求，SRI＝1。
2.现在，考虑这样的情况，其中3GPP上的PDU2有MO数据要发送，或者网络200在3GPP上发送用于PDU2的数据通知。
3.UE 100触发SRI＝2的针对PDU2的服务请求过程。不管对PDU1的服务请求会话(SRI＝1)的响应如何，该过程将对PDU2独立执行。
4.此外，基于来自网络200的响应，以下三种情况(A、B和C)是可能的。如果网络200发送：
情况A：包括由UE 100在请求消息中发送的SRI的针对PDU1的服务接受。类似地，UE100接收针对PDU2的服务接受。
替代地，网络200可以发送具有更新的PDU会话状态的单个服务接受消息，并且UE100将处理该消息，仅清除那些已经从网络200接收到响应的PDU的SRI上下文。这是其中两个(独立的)服务请求会话都成功的情况。
在实施例中，与两个会话相关的所有基于SRI的上下文(即，尝试计数器、定时器、SRI值)将在过程完成后分别被清除。
情况B：由于任何异常情况，没有针对PDU1服务请求的响应。在T3517期满之后，UE100重新发送针对PDU1的服务请求(SRI＝1)。同时，UE 100接收针对PDU2服务请求的响应(接受/拒绝)。两个会话独立进行。在实施例中，如果PDU2的服务接受到来，那么当过程成功时，所有的上下文(尝试计数器、定时器和SRI值)将被清除，否则上下文被维持，直到过程结束。然而，对于PDU1(SRI＝1)，由于过程尚未完成，所以在UE侧维持上下文。
图8是示出了根据本文公开的实施例的用于允许每个会话的并发服务请求过程的各种操作的序列图，其中，UE 100继续尝试，直到UE 100独立地用尽每个会话的最大服务请求尝试限制。
如图8中所示，在1处，UE 100通过3GPP发送SR＝1的针对PDU 1的服务请求。在2处，PDU2有MO数据要发送。在3处，UE 100通过3GPP发送SR＝2的针对PDU 2的服务请求。在4处，3GPP上针对PDU 1的服务请求的首次尝试失败。在5处，UE 100通过3GPP重新发送SR＝1的针对PDU 1的服务请求。在6处，3GPP上针对PDU 2的服务请求的首次尝试失败。在7处，UE 100通过3GPP重新发送SR＝2的针对PDU 2的服务请求。在8处，针对PDU 1达到最大尝试，导致T3325定时器开始，但是针对PDU 2还剩一次尝试。在9处，T3325定时器处于运行状态。
如图8中所示，对于任何服务请求没有响应，导致对于所有现有的基于SRI的SR会话的T3517定时器期满。UE 100继续尝试，直到它独立地用尽每个会话的最大服务请求尝试限制。如果没有来自网络的响应，并且任何一个会话的最大尝试已用尽，则停止所有正在进行的服务请求会话，清除基于SRI的服务请求会话上下文，并开始定时器T3325。只有在以下情况下，UE 100才可以尝试服务请求过程：
T3325定时器期满。
UE 100针对尚未成为最近服务请求会话的一部分的PDU(新PDU)有MO数据要发送(这可以使用上行链路数据状态IE来标识)。
它响应于来自网络200的寻呼。
下表1指示了对不同服务拒绝原因的处理。
表1：服务拒绝的具体情况
下表2指示了服务拒绝的具体情况。
表2：UE侧的异常情况
图9和图10是示出根据本文公开的实施例的在UE和5GC之间通信传送的各种信令消息的序列图。
如图9中所示，在1处，UE 100通过3GPP发送SR＝1的针对PDU 1的服务请求。在2处，高优先级PDU2有MO数据要发送。在3处，UE 100通过3GPP发送SR＝2的包括PDU1和PDU2的新服务请求。在4处，为3GPP PDU 1建立用户平面/DRB。在5处，UE接收到针对PDU 1的SR＝1的服务接受消息。当等待来自新SR的响应时，该消息被UE 100丢弃。在6处，为3GPP PDU2建立用户平面/DRB。在7处，UE 100接收针对PDU1和PDU2的SR＝2的服务接受消息。该消息被UE100接受。
如图10中所示，在1处，UE 100通过3GPP发送SR＝1的针对PDU 1的服务请求。在2处，高优先级PDU2有MO数据要发送。在3处，UE 100通过3GPP发送SR＝2的包括PDU1和PDU2的新服务请求。在4处，为3GPP PDU 1建立用户平面/DRB，并且在5处，为3GPP PDU 2建立用户平面/DRB。在6处，UE接收针对PDU1和PDU2的SR＝2的服务接受消息。
如图9和图10中所示，可以尽可能快地请求用户平面资源(DRB)。考虑这样的场景，其中UE 100已经触发了针对PDU1的SRI＝1(服务请求标识符)的服务请求过程。有针对一些其他PDU(可以是更高优先级的PDU)发送MO数据的请求。在这种情况下，UE 100将中止正在进行的服务请求过程，并触发另一服务请求过程作为全新的过程。为了实现上述行为，使用了服务请求标识符(SRI)，其可以用来唯一地标识每个服务请求过程。它必须被包括在每个服务请求程序消息(服务请求或服务接受或服务拒绝消息等)中。SRI唯一地标识服务请求过程的特定事务。可选地，第一服务请求过程消息可以不包括SRI。即，仅来自第二服务请求过程的SRI被包括在服务请求过程消息中。
为了更好地理解概念，考虑以下示例：针对PDU1触发服务请求，SRI＝1。现在，考虑这样的情况，其中PDU2必须通过3GPP发送数据，或者网络200通过3GPP发送用于PDU2的数据通知。根据当前的现有技术，因为SR过程已经正在进行，所以UE 100将阻止新的服务请求，即阻止关于PDU2的新数据请求。提出UE 100将中止SRI＝1的服务请求过程(即，正在进行的服务请求过程)，并将以下面的方式“情况A”或“情况B”之一触发新的服务请求过程。
情况A，UE 100在上行链路数据状态IE中触发包括PDU1和PDU2两者的SRI＝2的服务请求。现在，网络200为UE 100配置用于PDU1的承载，并发送针对PDU1的SRI＝1的服务接受。
由于UE 100已经中止了SRI＝1的服务请求过程，并且正在等待针对SRI＝2的服务请求的响应，因此UE 100将丢弃SRI＝1的服务接受(或服务拒绝)。
同时，网络200还为UE 100配置用于PDU2的承载，并发送包括以下可能选项之一的服务接受消息：
SRI＝2的服务接受或服务拒绝消息。这将被UE 100接受。
UE 100触发在上行链路数据状态IE中仅包括PDU2的服务请求，其中SRI＝1或2(取决于实施方式，这里SRI＝2用作示例)，因为对于UE 100，它是新的服务请求。(其中UE只想要用于PDU2的用户平面)
网络为UE配置用于PDU1的承载，对于其，UE必须立即丢弃或释放资源，将其视为无效消息。如果包括服务接受，UE将丢弃服务接受。5.现在，网络为UE配置用于PDU2的承载，对于其，UE将平和地接受该过程的进行。如果服务接受不包括关于PDU1的信息(这是预期行为)，则指示新的(第二个)服务请求过程的结束。如果对于PDU1有任何挂起的MO数据或者从网络接收到数据通知，则UE将触发针对PDU1的SR。
所提出的方法还处理相同接入的并发服务请求。
作为实现选项，AMF 500可以存储时间“x”(通过运行定时器)的PDU会话重新激活结果IE的值。因此，如果AMF 500接收到与先前的服务请求消息相比具有增加的SRI值的新SR消息，则AMF 500可以只对上行链路数据状态IE的增量部分起作用，并且对于其已经向UE100发送了响应的PDU会话ID，不需要重新请求SMF建立DRB，即，例如第一SR过程(具有SRI1)请求的PDU 1和PDU 2。AMF 500建立PDU1和PDU2(在请求SMF之后)，并且向UE 100发送具有PDU会话重新激活结果IE的服务接受。同时，AMF 500接收具有PDU1、PDU2和PDU3的新服务请求消息(具有SRI 2)，然后AMF 500使用存储的PDU会话重新激活结果IE来确定PDU 1和PDU2的结果，并且仅针对PDU3请求SMF建立PDU会话。然后最后，AMF 500通过用(来自SRI 1的)PDU1和PDU2的存储值以及PDU3的新结果对PDU会话重新激活结果IE进行编码来发送服务接受。
在又一实施例中，如果给定PDU会话的用户平面资源(或DRB)已经是活动的，则AMF500将对该特定PDU会话的PDU会话重新激活结果是PDU会话的成功激活进行编码，即使AMF500从UE 100接收到建立该特定PDU会话的请求也如此。
图11是示出根据本文公开的实施例的处于3GPP的CM连接状态的PDU移动的序列图。
如图11中所示，在1处，UE 100在N3GPP接入模式和3GPP接入模式上处于CM Idle。在2处，AMF 500向RAN发送指示非3GPP接入的寻呼。在3处，RAN 400向UE 100发送指示非3GPP接入的寻呼。在4处，UE 100向AMF发送服务请求。在5处，UE 100在N3GPP上处于待连接的CM Idle。在6处，AMF 500在3GPP上开始N3GPP PDU激活。在7处，直到3GPP服务请求过程结束，UE 100才将通过N3GPP触发针对在3GPP中被允许重新激活的PDU的服务请求。此外，UE100可以触发针对不允许在3GPP上激活的PDU的服务请求。
在实施例中，3GPP和N3GPP接入处于IDLE模式，并且UE 100利用N3GPP接入获得3GPP中的寻呼。UE 100发送具有可移动的N3GPP PDU的被允许列表的服务请求。在此期间，UE 100试图通过发送服务请求在N3GPP中移动到CM_CONNECTED状态。
在实施例中，服务请求不应包含在3GPP服务请求中发送的“处于PDU的被允许列表中的”PDU。它可以包含基于上行链路数据的“处于PDU的被允许列表中”的3GPP中的服务请求中未发送的PDU的列表。
图12是示出根据本文公开的实施例的处于3GPP的CM连接状态的PDU移动的序列图。
如图12中所示，在1处，UE 100在N3GPP接入上处于CM Idle，并且在3GPP接入上处于CM连接。在2处，AMF 500向RAN发送指示非3GPP接入PDU会话id的通知。在3处，RAN 400向UE 100发送指示非3GPP接入PDU会话id的通知。在4处，UE 100向AMF发送服务请求。在5处，UE 100在N3GPP上处于待连接的CM Idle，并且在6处，AMF 500在3GPP上开始N3GPP PDU激活。在7处，直到3GPP服务请求过程结束，UE 100才将通过N3GPP触发针对在3GPP中被允许重新激活并且对于其通知已经到来的PDU的服务请求。此外，UE 100可以基于上行链路数据来触发针对不被允许在3GPP上激活或者在3GPP中对于其通知没有到来的N3GPP PDU的服务请求。
在实施例中，3GPP接入处于CM-CONNECTED状态，并且N3GPP接入处于IDLE模式，并且UE 100利用PDU会话id/接入技术获得针对N3GPP的下行链路数据的通知。如果对于其通知已经到来的PDU会话被允许在3GPP上移动，则UE 100发送服务请求，否则，UE 100将发送通知响应。在此期间，如果UE 100试图通过发送服务请求来在N3GPP中移动到CM_CONNECTED状态。
在实施例中，服务请求不应包含对于其在3GPP中对下行链路数据的通知已经到来的PDU，并且如果服务请求被允许在3GPP上被重新激活。可替代地，服务请求不应包含被允许在3GPP上重新激活的PDU。
服务请求可以包含不被允许在3GPP上被激活或者对于其在3GPP中通知没有到来的基于上行链路数据的N3GPP PDU。
图13是示出根据本文公开的实施例的当对于至少一个PDU的UL数据挂起时，UE100将触发服务请求的序列图。
问题场景包括：
在1处，PDU1和PDU2用户平面在3GPP接入上是活动的(即，DRB被建立)，
在2处，RLF发生，并且
在3处，UE 100从RLF恢复
在恢复之后，如果上行链路数据挂起，则UE 100可以发送服务请求(下面的情况A)，或者当上行链路数据未挂起时，发送移动性更新(下面的情况B)。
下面列出的两个情况场景提供了解决方案：
情况A：当UL数据对于至少一个PDU挂起时，UE 100将以3个替代选项之一触发服务请求：
在4a处，UE 100触发包括PDU1、PDU2(即，在服务请求的最近上行链路数据状态中被请求激活的所有PDU)的服务请求；或者
在4b处，UE 100同时为PDU1、PDU2(即，在服务请求的最近上行链路数据状态中被请求激活的所有PDU)触发服务请求；或者
在4c处，UE 100在为紧急PDU(如果有的话)获得服务之后立即触发服务请求，该紧急PDU在RLF发生之前是活动的。
图14是示出根据本文公开的实施例的当没有上行链路数据挂起时，UE100将触发移动性注册更新的序列图。
情况B：当没有上行链路数据挂起时，UE 100将以两个选项之一触发移动性注册更新：
在图14中的4a处，UE触发上行链路数据状态IE中的紧急PDU的移动性注册更新，或者
在图14中的4b处，UE触发包括最近上行链路数据状态IE中活动的所有PDU的移动性注册更新。
图15是根据本文公开的实施例的PDU会话建立过程的图示。
如图15中所示，应用处理器(AP)通过发送要建立的指示它是否是始终在线PDU(即，更高优先级的PDU会话)的PDU来发起与通信处理器(CP)120或NAS的PDU会话建立过程。并且CP 120在到网络200的PDU建立请求消息中包括类型指示。稍后，网络200在非活动定时器期满期间利用该PDU的信息及其类型来确定是否需要释放用户平面资源。如果PDU类型为始终在线，则即使非活动定时器期满之时网络200也将并不释放用户平面资源，并且继续维持UE上下文，或者如果PDU类型为始终在线，则网络200将不运行非活动定时器。由于任何RLF原因或错误情况，DRB被释放，然后网络200将重新激活始终在线PDU会话。AMF 500将通知gNodeB、SMF、UPF和其他相关网络元件关于始终在线PDU会话。因此，如果网络元件确定这种PDU会话DRB被释放，则网络元件可以开始DRB激活过程。
如图15中所示，在1处，AP 110向CP 120请求针对PDU 5的PDU建立，类型-正常/始终在线。在2a处，CP 120向网络200发送PDU建立请求PDU 5，类型-正常/始终在线。在2b处，CP 120存储PDU信息(即，PDU 5，类型-正常/始终在线)。在3a处，网络200存储PDU信息(即，PDU 5，类型-正常/始终在线)。在3b处，在AP 110和网络200之间执行PDU会话建立过程。
图16是根据本文公开的实施例的维持UE上下文的网络200的图示。
在图16中的实施例中，其中UE 100具有多于1个具有用户平面资源的PDU，其中一个为始终在线PDU类型。当非活动定时器对于始终在线PDU期满时，网络200将不释放维持UE上下文的用户平面资源。
图17是根据本文公开的实施例的在移动到RRC非活动状态时指令UE 100的网络200的图示。
在图17的实施例中，UE 100仅具有一个具有活动的用户平面资源的类型为始终在线的PDU。当非活动定时器对于该始终在线PDU期满时，网络200将不释放用户平面资源，并指令UE 100在1-3处进入RRC非活动状态。替代地，如果gNode-B正在具有始终在线PDU会话，并且非活动定时器期满，指示在取决于实施方式的时间内没有数据传输，则gNode-B可以释放DRB的物理资源，并将该特定DRB移动到非活动状态，从而保持所有其他DRB活动，即，每DRB非活动状态移动。现在，无论何时在移动到非活动(INACTIVE)的DRB上接收到数据，其都通过物理资源分配来恢复。
图18是根据本文公开的实施例的执行服务请求过程的图示。
在图18中的实施例中，在1处，如果任何应用有数据要发送，则在2a和2b处，UE 100将发送包括该PDU会话id(映射到所请求的应用)以及所有其他活动PDU或者在上行链路数据状态IE中不具有用户平面资源的始终在线类型的所有活动PDU的服务请求。因此，延迟被最小化，并满足低时延、延迟不容忍服务PDU的关键要求。可替代地，当发送服务请求或注册请求消息时，UE 100具有始终在线PDU，则UE 100将向网络200指示UE 100需要DRB用于所有活动PDU。在这种场景下，网络200应当为UE 100的所有活动PDU建立用户平面资源。也就是说，一般地，如果AP 110已经指示了始终在线PDU会话，则每次UE 100触发服务请求过程时，并且如果没有为那些PDU会话建立DRB，则UE 100将在上行链路数据状态IE中包括那些PDU会话ID。可替代地，一般地，如果AP 110已经指示了始终在线PDU会话，则每次UE 100触发服务请求过程时，不管为那些PDU会话建立的DRB如何，UE 100都将在上行链路数据状态IE中包括那些PDU会话ID。可替代地，如果UE 100是更高优先级接入或支持任务关键型服务或低时延应用的类型，则每次UE 100触发服务请求过程时，它将设置所有活动PDU会话ID作为上行链路数据状态IE的一部分。可替代地，如果UE 100是更高优先级接入或支持任务关键型服务或低时延应用的类型，则网络200将运行长持续时间的非活动定时器，或者将不运行非活动定时器，使得DRB永远不会被释放，并且每当DRB释放发生时，网络元件将发起重新建立DRB的过程。网络200可以从订阅信息或来自UE的明确指示或者在确定UE 100正在请求的服务类型之后(例如，如果UE请求任务关键型服务并因此建立那些PDU会话)，理解UE具有更高优先级接入或支持任务关键型服务或低时延应用。
在图15-图18的实施例中，AP 110正对于PDU 5将(PDU)类型指示为正常或始终在线。这样做只是为了清楚地理解解决方案。来自AP 110的(PDU)类型的指示仅针对始终在线PDU发送，否则暗示它们属于正常PDU类型。在本公开中描述的始终在线(或更高优先级的PDU会话)是为需要低时延和低连接建立时间的服务(例如任务关键型服务)建立的PDU会话。
图19是根据本文公开的实施例的请求的PDU会话的DRB的图示。
在1处，UE 100向网络200发送针对PDU 5的SR 1。在2处，高优先级PDU 6有MO数据要发送。在3处，UE 100发送针对PDU 5、PDU 6的服务请求2。在4处，为PDU 5建立DRB，并且在5处，为PDU 6建立DRB以及针对PDU 5和PDU 6的服务接受(PDU重新激活结果：对于PDU 5为0并且对于PDU 6为0)。
在实施例中，系统公开了接收到服务接受，并且激活了所有请求的SR-2的PDU会话ID的DRB。从UE的角度来看，SR过程被标记为完成，因为DRB为在最近发送的服务请求消息中为其请求了用户平面无线电资源的所有PDU会话ID建立了，并且在服务接受消息中的PDU会话重新激活结果IE中也被指示成功激活。
图20是根据本文公开的实施例的PDU会话重新激活结果的图示。
如图20中所示，在1处，UE 100向网络200发送针对PDU 5的SR 1。在2处，高优先级PDU 6有MO数据要发送。在3处，UE 100发送针对PDU 5、PDU 6的服务请求2。在4处，为PDU 5建立DRB以及针对PDU 5和PDU 6的服务接受(PDU重新激活结果：对于PDU 5为0并且对于PDU6为1)。
在实施例中，系统公开了关于在接收到具有指示第二服务请求消息建立的所请求的PDU会话ID的DRB之一已经失败的PDU会话重新激活结果IE的服务接受消息之后。从UE的角度来看，SR过程被标记为完成，因为UE 100接收到在与服务接受消息中的PDU会话重新激活结果IE相匹配的最近发送的SR消息中为其请求了用户平面资源的所有PDU会话ID的用户平面激活结果。
图21是根据本文公开的实施例接收第二服务接受消息的图示。
如图21中所示，在1处，UE 100向网络200发送针对PDU 5的SR 1。在2处，高优先级PDU 6有MO数据要发送。在3处，UE 100发送针对PDU 5、PDU 6的服务请求2。在4处，为PDU 5建立DRB。在5处，网络200发送仅包括针对PDU 5的服务接受(PDU重新激活结果：对于PDU5为0并且对于PDU 6为0)。在6处，为PDU 6建立DRB以及PDU 5和PDU 6的服务接受(PDU重新激活结果：对于PDU 6为0)
在实施例中，系统描述了关于在接收到第二服务接受消息之后，即当UE 100发送第二SR并且在它到达网络200之前，AMF 500可能已经用针对第一SR的服务接受进行了响应。UE 100接收SR1的第一服务接受，其中PDU会话重新激活结果IE指示PDU 5的成功用户平面激活。从UE的角度来看，SR过程仍未完成(即，UE仍处于5GMM服务请求发起(5GMM-service-request-initiated)状态)，因为用户平面资源尚未针对最近发送的SR消息中请求的所有PDU会话ID被激活(即，在本示例中，对于PDU 6，用户平面资源尚未建立)。此外，当UE 100接收到下一服务接受消息时，从UE的角度来看，SR过程被标记为完成，因为它包括在最近发送的SR消息(SR2)中请求的所有用户平面资源的PDU会话激活结果IE。
在图19-图21中的实施例中，系统描述了关于UE 100已经发起服务请求过程并且接收到针对(具有更高优先级的应用的)新的PDU的上行链路数据请求，同时UE 100等待完成服务请求过程的情况，然后UE 100可以中止当前正在进行的服务请求过程并进行新的服务请求过程。UE 100向AMF发送服务请求(上行链路数据状态IE设置为5)消息。UE 100处于5GMM服务请求发起状态，并且5GMM层从上层接收为PDU会话ID 6建立DRB的请求。UE 100中止第一服务请求并发送第二服务请求消息(重启T3517)，其中上行链路数据状态IE中的PDU会话ID被设置为5和6。网络200接收新的SR消息并处理最近接收的SR消息。当任何以下事件发生时，在UE侧服务请求过程被认为完成。
图22是根据本文公开的实施例的完成UE角度SR过程的图示。
如图22中所示，在1处，UE 100向网络200发送针对PDU 5的SR。在2处，高优先级PDU6有MO数据要发送。在3处，UE 100发送针对PDU 5、PDU 6的服务请求。在4处，为PDU 5建立DRB。在5处，为PDU 6建立DRB以及针对PDU 5、PDU 6的服务接受(PDU重新激活结果：对于PDU6为0)。
在实施例中，UE 100已经发起服务请求过程，并且接收到上行链路数据请求。
对于(具有更高优先级的应用的)新的PDU，当UE 100等待完成服务请求过程时，UE100可以中止当前正在进行的服务请求过程，并进行新的服务请求过程。此外，UE 100向AMF发送服务请求(上行链路数据状态IE设置为5)消息。UE 100处于5GMM服务请求发起状态，并且5GMM层从上层接收为PDU会话ID 6建立DRB的请求。UE中止第一服务请求并发送第二服务请求消息，其中上行链路数据状态IE中的PDU会话id被设置为5和6。网络200接收新的SR消息并处理最近接收的SR消息。在成功完成服务请求过程时，UE 100和网络200将触发定时器T3519(类似于3G中的T3319)。直到该定时器期满，UE 100才将为在最近服务请求过程中请求的PDU发起服务请求。即使UE 100为在最近服务请求过程中请求的PDU发起服务请求，网络200也被期望忽略该请求，直到T3519期满。
在图19至图22的实施例中，如果没有从网络200接收到服务接受消息，并且定时器T3517(在UE侧保护服务请求过程)期满，则UE 100将服务请求过程标记为完成。
在图19-图22的实施例中，每当UE中止第一服务请求过程(SR1)并发送新的服务请求消息(SR2)时，则它重启定时器T3517(在UE侧保护服务请求过程)。
图23是根据本文公开的实施例的MME 600不检查S-TAU指示的图示。
在图23中的实施例中，系统描述了关于MME 600不检查S-TAU指示。当UE 100中的EPC周期性TAU定时器期满时，则UE 100应当被允许向UDM(经由AMF)发送指示，指示UE 100由于5G上正在进行的数据会话而不能触发TAU过程。然后，UDM 700将向MME 600指示UE 100发送了可以被视为半TAU(semi-TAU，S-TAU)过程的指示。MME 600可以延长UE 100的TAU定时器期满时间。一旦5G数据会话结束，则UE 100可以触发TAU并更新到MME。像UDM 700一样，可以有任何其他节点或接口可以用于将TAU路由到MME。与支持单注册的UE相比，支持双注册的UE的周期性定时器值更大。
图24是根据本文公开的实施例的MME 600检查S-TAU指示的图示。
在图24的实施例中，当UE 100中的EPC周期性TAU定时器期满时，则UE 100应当被允许向UDM(经由AMF)发送指示，指示UE由于5G上正在进行的数据会话而不能触发TAU过程。当MME侧周期性定时器期满时，MME 600与UDM 700一起检查UE 100是否在5G中可用以及是否有任何数据会话是活动的。如果UDM已经从UE 100接收到指示，则UDM 700可以更新到MME600，并且MME 600可以将UE上下文保持一段时间。像UDM 700一样，可以有任何其他节点或接口可以用于将TAU路由到MME。
在实施例中，将存在由于在双重Rx、单一Tx配置中注册，其寻呼将被错过的高优先级的PDU(延迟不容忍、低时延等)。考虑这样的情况，其中UE 100通过正在5G(5G连接模式、4G Idle(4G空闲)模式)上进行的数据会话被双重注册(双重Rx、单一Tx)到4G、5G两者。由于这种情况，如果UE 100不针对4G上的寻呼时机进行调谐，那么4G上将会错过寻呼。这是一个主要问题。现有方法和系统通过如下方式解决了这个问题：MME 600通过4G向UE 100发送寻呼，同时通过5G发送通知(因为5G处于连接模式)，并且只有当MME 600不能到达UE(并且知道UE支持双重注册)时，MME 600才通过5G发送通知。可替代地，只有当针对高优先级PDU的请求到来时，MME 600才可以通过5G发送通知，而不是针对每个PDU向5G发送通知。此外，高优先级PDU是应当被优先考虑的那些具有诸如低时延、延迟不容忍或紧急PDU等要求的PDU。当通过5G接收到4G PDU的通知时，UE 100需要进一步执行以下动作之一：如果MT寻呼是针对高优先级PDU的，UE 100响应通过4G的寻呼：或者UE 100移动4G PDU(到已经接收到寻呼的PDU或所有高优先级PDU)到5G(因为5G处于连接模式)。
在实施例中，UE可以在寻呼时机期间调谐到4G以监听寻呼或执行TAU。当周期性TAU定时器期满时，UE可以调谐到4G以发送TAU，暂停5G上正在进行的会话。一旦TAU过程被执行，UE进入4G IDLE状态，并恢复5G上的暂停的数据会话。如果针对高优先级PDU的MT寻呼已经到来，则UE可以暂停5G上当前正在进行的会话，以响应针对4G上的高优先级PDU的寻呼，并且执行PDU从4G到5G的移动，并且响应寻呼。高优先级PDU是应当被优先考虑的那些具有低时延、延迟不容忍或紧急PDU等要求的PDU。这种方法将导致高电池消耗和正在进行的数据会话的RAT的性能下降。因此，这不是有效的解决方案。
在实施例中，网络200在PDU会话建立响应消息中向UE 100指示PDU是否是始终在线。在PDU会话建立请求中，UE 100将向网络200指示PDU类型偏好(始终在线或正常)，或者将不指示PDU类型偏好。
在实施例中，AT命令还可以用于向调制解调器或NAS层指示哪些PDU将被认为是始终在线PDU。在PDU建立过程期间，UE 100将可选地向网络指示PDU类型偏好(始终在线或正常)，或者在请求消息中不包括到网络200的PDU类型偏好，并且网络200将在PDU会话建立响应消息中向UE 100指示PDU是否是始终在线PDU。
在另一实施例中，在类似4G到5G或5G到4G的接入之间的PDU移动期间，UE 100将指示PDU类型偏好(始终在线或正常)，而不管PDU建立原因(切换、紧急、正常等)并且网络200将响应于UE 100而指示该PDU是否是始终在线PDU。UE 100随后将使用由网络200在上述响应中提供的相同指示，直到网络另有指示。
在另一实施例中，如果PDU没有必要自始至终为始终在线PDU，那么这个特性/特征应当是可动态配置的。网络200将基于不同的因素做出决定，例如UE 100驻留在归属网络或访问网络上、网络切片实例、拥塞或与基于当前注册区域中的订阅的其他更高优先级用户相比的优先级等。应通过比如UE通用配置更新、PDU修改的过程或支持UE的动态配置的任何过程来提供PDU类型(是否是始终在线PDU)的这种动态配置。
在另一实施例中，PDU及其类型(是否是始终在线PDU)将通过SIM静态地配置，并且如果网络200动态地配置它，这些对应的SIM字段将被更新。下面列出了通过SIM实现这一点(增加新的EF)的几种替代方案。为每个PDU/DNN/S-NSSAI添加此功能/规则作为URSP(UE路由选择策略)的一部分。可选地包括UE在归属网络以及访问网络中对于该特定PDU/DNN/S-NSSAI的预期行为(可以是新EF的一部分或者修改现有EF)。替代地，该信息将存储在UE的非易失性存储器中。在UE内部提供作为配置对象。在SIM中为每个PDU添加新的EF(可选地，归属网络或访问网络各自一个/每个PDU一个，而不管驻留网络)。可替代地，添加一个定义被网络200认为是始终在线PDU的候选的PDU的数量的EF，并且为每个PDU添加EF以指示PDU类型偏好。网络200将使用静态/动态方法来由网络更新PDU类型偏好。
在另一实施例中，在静态/动态方法期间，CP 120存储由网络200配置的PDU类型偏好(始终在线或正常)。基于此，CP 120将决定PDU类型是始终在线还是正常。此外，CP 120基于AT命令参数、设备类型或者基于在AT命令中指示的时延、优先级要求或DNN/APN名称来决定PDU类型偏好。
在另一实施例中，UE 100和网络200之间的PDU类型偏好(始终在线或正常)的协商将被包括作为UE在注册过程期间支持的特征，并且网络将在注册响应消息中确认PDU的该协商特征是否被支持。网络200将指示为独立的特征支持或网络特征支持IE的一部分。只有在网络确认特征支持时，UE 100才将在PDU建立过程或其中可以协商PDU类型偏好的其他类似过程期间为PDU设置PDU类型偏好。
在另一实施例中，网络或运营商将添加被称为“针对始终在线PDU会话的配置的APN/DNN/基于切片的(NSSAI)”的具有始终在线PDU类型偏好的预定义的APN/DNN。这些“配置的APN/DNN/基于切片的(NSSAI)”可以由网络使用提出的方法之一进行修改。在所有后续过程中，UE 100将使用与在针对始终在线PDU会话的配置的APN/DNN/基于切片的(NSSAI)中设置的相同的PDU类型偏好，直到网络另有指示。
在另一实施例中，该方法可以用于处理网络200向UE发送对服务请求或PDU会话建立过程或在其中协商PDU类型偏好的任何其他过程的拒绝的异常情况。
在PDU会话建立过程期间因某种原因被拒绝之后，执行以下动作中的任何一种。
选项1：UE 100可以立即为该DNN/S-NSSAI重新请求PDU会话建立，但不标记为始终在线，
选项2：UE 100可以为该DNN/S-NSSAI重新请求PDU会话建立，并仅在基于该原因的预定义时间之后标记为始终在线，
选项3：UE 100将永远不会为该DNN/S-NSSAI重新请求PDU会话为始终在线，以及
选项4：UE 100可以为该DNN/S-NSSAI重新请求PDU会话建立，并基于一些预定义的次数标记为始终在线。
在获得服务拒绝之后，基于拒绝原因，可能的选项为：
a)当发送下一SR时，UE 100不将始终在线PDU包括作为上行链路数据状态IE的一部分，除非在发送SR时该PDU有数据挂起，
b)当发送下一SR时，UE 100继续将始终在线PDU包括作为上行链路数据状态IE的一部分，
c)如上文(b)点所述操作，但仅在预定义的时间内，且在该时间过去之后，则如上文(a)点所述继续，
d)如(a)点所述操作，直到UE 100断电，USIM被移除，
e)上述4个选项(即，a至d)可以基于DNN或S-NSSAI或其任何组合来执行。
在另一实施例中，如果UE 100在注册接受消息中接收到3GPP接入中的不同的5G-GUTI，则网络200在注册接受的结果IE中或以任何其他方式指示需要N3GPP注册，然后UE100将通过N3IWF 300使用新的5G-GUTI为非3GPP接入进行重新注册。
在另一实施例中，如果UE 100在注册接受消息中接收到3GPP接入中的不同的5G-GUTI，则网络200在注册接受的结果IE中或以任何其他方式指示需要N3GPP注册，并且UE100将通过以下方式为非3GPP接入进行重新注册。UE 100将使用新的5G-GUTI作为路由参数，使得N3WIF选择新的AMF。在注册消息中，UE 100将发送用于N3WIF的旧GUTI，以便新AMF从旧AMF获取上下文。
在另一实施例中，如果UE 100在注册接受消息中接收到N3GPP接入中的不同的5G-GUTI，则UE 100和/或网络200在注册接受的结果IE中或以任何其他方式(例如，如果网络200只为N3GPP提供注册接受)指示需要3GPP注册，则UE 100将通过3GPP接入RAN使用新的5G-GUTI为3GPP进行重新注册。
在另一实施例中，如果UE 100在注册接受消息中接收到N3GPP接入中的不同的5G-GUTI，则UE 100和/或网络200在注册接受的结果IE中或以任何其他方式(例如，如果网络200只为N3GPP提供注册接受)指示需要3GPP注册，然后UE 100将通过以下方式使用3GPP接入RAN 400为3GPP进行重新注册。UE 100将使用新的5G-GUTI作为路由参数，使得5G节点B选择新的AMF。在注册消息中，UE将发送本在那儿用于3GPP的旧GUTI，以便新AMF从旧AMF获取上下文。
图25是根据本文公开的实施例的网络200在PDU会话建立响应消息中向UE 100指示PDU是否是始终在线的图示。
在实施例中，当UE 100发起PDU会话建立过程时，可选地将把指示PDU类型偏好为始终在线PDU或正常PDU，并且网络200将在PDU会话建立接受消息中向UE 100指示所接受的PDU偏好类型(始终在线或正常)。
在1处，AP 110请求针对PDU 5的PDU建立，类型-正常/始终在线(可选)。在2a处，CP120向网络200发送PDU建立请求PDU 5，类型-正常/始终在线(可选)。在2b处，CP 120存储PDU信息：PDU 5，类型-正常/始终在线(可选)。在3a处，网络200向UE 100发送PDU会话建立接受PDU 5，类型-始终在线。在3b处，网络200存储PDU信息：PDU 5，类型-正常/始终在线。
图26是根据本文公开的实施例的用于向UE 100动态配置PDU类型(即，是否是始终在线PDU)的方法的图示。
在初始PDU会话建立过程期间，网络200和UE 100为每个PDU协商PDU偏好类型。考虑这样的场景，其中网络200由于比如订阅问题而决定将PDU偏好类型从始终在线修改为正常。这可以通过使用如UE通用配置更新或PDU修改等过程来动态配置PDU偏好类型来实现。
如图26中所示，在1处，初始PDU会话建立过程PDU 5，类型-始终在线。在2处，网络200存储PDU信息(即，PDU 5，类型-正常/始终在线)。在3处，CP 120存储PDU信息(即，PDU 5，类型-正常/始终在线(可选))。在4处，网络决定将PDU类型偏好改变为正常PDU 5，类型-正常。在5处，UE 100执行配置更新/PDU修改过程PDU 5和类型-正常。
在实施例中，如果UE 100具有未被网络200接受为始终在线PDU会话的一个或多个活动PDU会话，并且对于那些PDU会话没有上行链路用户数据挂起待发送，则UE 100将不在注册请求消息中的上行链路数据状态IE中包括那些PDU会话。
在实施例中，如果UE 100具有未被网络200接受为始终在线PDU会话的一个或多个活动PDU会话，并且对于那些PDU会话没有上行链路用户数据挂起待发送，则UE 100将不在服务请求消息中的上行链路数据状态IE中包括那些PDU会话。
如果在PDU会话修改命令消息中包括始终在线PDU会话指示IE，则
IE的值被设置为“需要始终在线PDU会话”，UE 100将把所建立的PDU会话视为始终在线PDU会话；或者
b)IE的值被设置为“不允许始终在线PDU会话”，UE 100将不把所建立的PDU会话视为始终在线PDU会话。
在实施例中，如果UE 100在PDU会话修改命令消息中没有接收到始终在线PDU会话指示IE，则UE将不把修改后的PDU会话认为是始终在线PDU会话。
在实施例中，如果UE 100请求建立新的PDU会话作为始终在线PDU会话，则UE 100应当在PDU会话建立请求消息中包括始终在线PDU会话请求IE，并将IE的值设置为“请求始终在线PDU会话”。
在实施例中，AT命令可以用于向调制解调器/NAS层指示关于哪些PDU将被认为是始终在线PDU。当UE 100发起PDU会话建立过程时，可选地将指示PDU类型偏好为始终在线PDU或正常PDU，并且网络200将在PDU会话建立接受消息中向UE 100指示所接受的PDU偏好类型(始终在线或正常)。
图27是根据本文公开的实施例的用于处理服务请求过程的无线通信系统2700的示意图。在实施例中，无线通信系统2700包括UE 100和网络200。UE 100包括AP 110、CP120、PDU会话类型处理机130、通信器140、存储器150和处理器160。网络200包括PDU会话类型处理机210、通信器220、存储器230和处理器240。
处理器160与AP 110、CP 110、PDU会话类型处理机130、通信器140和存储器150通信。PDU会话类型处理机130将PDU会话类型配置为始终在线类型。此外，PDU会话类型处理机130被配置为向网络200发起服务请求和注册请求过程中的一个。服务请求和注册请求过程中的一个在上行链路状态信息元素(IE)请求中包括PDU会话类型为始终在线类型。此外，PDU会话类型处理机130被配置为基于服务请求和注册请求过程中的一个来处理无线通信系统中的服务请求过程，该服务请求和注册请求过程中的一个在上行链路状态IE请求中包括PDU会话类型为始终在线类型。
在实施例中，当UE 100从CM IDLE模式移动到CONNECTED模式时，PDU会话类型为始终在线类型指示激活UE 100和网络200之间的用户平面资源。在实施例中，上行链路状态IE请求中的PDU会话类型为始终在线类型避免了PDU的资源建立中的延迟。
在实施例中，当UE(100)处于CM_CONNECTED模式时，PDU会话类型为始终在线类型管理用户平面资源。
在实施例中，PDU会话类型处理机130被配置为基于来自上层(例如，应用层110)的指示，请求将PDU会话建立为始终在线PDU会话，并且网络200决定PDU会话是否被建立为始终在线PDU会话。
在实施例中，在初始PDU会话建立过程期间，UE(100)将协议数据单元(PDU)会话类型配置为始终在线类型，并向网络(200)发送包括PDU会话类型为始终在线类型的PDU会话建立请求消息。网络(200)从UE(100)接收包括PDU会话类型为始终在线类型的PDU会话建立请求消息，并基于PDU会话建立请求消息确定PDU会话类型为始终在线类型或正常PDU类型。
在实施例中，UE(100)基于通用集成电路卡(UICC)中的配置、来自上层的指示和注意(attention，AT)命令中的一个，将PDU会话类型配置为始终在线类型。
在实施例中，基于网络(200)中的配置、网络(200)中的订阅中的一个，PDU会话类型被确定为始终在线类型或正常PDU类型，并且在PDU会话建立响应消息中向UE(100)指示。
在实施例中，网络(200)基于网络(200)中的配置和网络(200)中的订阅中的一个，在PDU会话建立响应消息中将PDU会话配置为始终在线类型，而不管在PDU会话建立过程期间没有来自UE(100)的PDU会话类型为始终在线类型的指示。
在实施例中，UE(100)基于UE配置将PDU会话类型配置为始终在线类型，而不管在来自网络(200)的PDU会话建立响应中没有指示。
在实施例中，UE(100)被配置为向网络(200)发起服务请求过程和注册请求过程中的一个，其中服务请求过程和注册请求过程中的一个在上行链路数据状态信息元素(IE)请求中包括PDU会话类型为始终在线类型的PDU会话标识符。
在实施例中，上行链路数据状态IE请求中PDU会话类型为始终在线类型的PDU会话标识符指示在上行链路数据状态IE中设置始终在线类型的PDU会话ID的位图。
在实施例中，当UE(100)从CM IDLE模式移动到CM-CONNECTED模式以及UE(100)处于CM-CONNECTED模式中的一者时，始终在线类型的PDU会话类型指示UE(100)和网络(200)之间的用户平面资源始终被激活用于PDU会话。
在另一实施例中，UE(100)将动态地配置对应于始终在线类型的PDU会话类型到正常PDU类型或者正常PDU类型的PDU会话类型到始终在线类型的改变，并且在PDU会话建立请求消息中向网络(200)指示PDU会话类型为始终在线类型和正常类型中的一个，而不管PDU建立原因。网络(200)从UE(100)接收作为始终在线类型和正常类型中的一个的PDU会话类型，并且基于PDU会话建立请求消息、网络(200)中的配置和网络(200)中的订阅中的一个来确定PDU会话类型为始终在线类型或正常类型。
在实施例中，PDU建立原因指示切换场景、紧急场景和正常场景中的至少一个。
在实施例中，在UE(100)和网络(200)处维持作为始终在线类型的PDU会话类型。
在实施例中，UE 100具有未被网络200接受为始终在线PDU会话的一个或多个活动PDU会话，并且对于那些PDU会话没有上行链路用户数据挂起待发送，则PDU会话类型处理机130将不在注册请求消息中的上行链路数据状态IE中包括那些PDU会话。
在实施例中，如果UE 100具有未被网络200接受为始终在线PDU会话的一个或多个活动PDU会话，并且对于那些PDU会话没有上行链路用户数据挂起待发送，则PDU会话类型处理机130将不在服务请求消息中的上行链路数据状态IE中包括那些PDU会话。
在实施例中，如果PDU会话类型处理机130没有在PDU会话修改命令消息中接收到始终在线PDU会话指示IE，则UE 100将不将修改后的PDU会话视为始终在线PDU会话。
在实施例中，如果UE 100请求建立新的PDU会话为始终在线PDU会话，则PDU会话类型处理机130将包括始终在线PDU会话请求IE，并且在PDU会话建立请求消息中将IE的值设置为“请求始终在线PDU会话”。
在实施例中，所请求的PDU会话需要被建立为始终在线PDU会话，SMF将在PDU会话建立接受消息中包括始终在线PDU会话指示IE，并且将把值设置为“需要始终在线PDU会话”。
下表3指示了PDU会话建立请求消息内容。
表3
下表4指示了PDU会话建立接受消息内容。
表4
下表5指示了PDU会话修改请求消息内容。
表5
始终在线PDU会话请求信息元素如表6中所示进行编码。
表6
表7指示了始终在线PDU会话请求信息：
表7
在另一实施例中，始终在线PDU会话指示信息元素如表8中所示进行编码。始终在线PDU会话指示是类型1信息元素。
表8
表9指示了始终在线PDU会话指示。
表9
处理器160被配置为执行存储在存储器150中的指令以及执行各种处理。通信器140被配置用于在内部硬件组件之间进行内部通信以及经由一个或多个网络与外部设备进行通信。
存储器150还存储将由处理器160执行的指令。存储器150可以包括非易失性存储元件。这种非易失性存储元件的示例可以包括磁硬盘、光盘、软盘、闪存或电可编程存储器(EPROM)或电可擦除可编程(EEPROM)存储器的形式。此外，在一些示例中，存储器150可以被认为是非暂时性存储介质。术语“非暂时性”可以指示存储介质没有体现在载波或传播信号中。然而，术语“非暂时性”不应被解释为存储器150是不可移动的。在一些示例中，存储器150可以被配置为存储比存储器更大量的信息。在某些示例中，非暂时性存储介质可以存储能够随时间变化的数据(例如，在随机存取存储器(RAM)或高速缓存中)。
在实施例中，网络(200)包括与存储器(230)和处理器(240)耦合的PDU会话类型处理机(210)。PDU会话类型处理机(210)被配置为从UE(100)接收服务请求和注册请求过程中的一个。服务请求和注册请求过程中的一个包括协议数据单元(PDU)会话标识符和PDU会话类型为始终在线PDU类型。PDU会话类型处理机(210)被配置为基于PDU会话标识符来确定为PDU提供用户平面资源。PDU会话类型处理机(210)被配置为基于用户平面资源来处理无线通信系统中的服务请求过程。
在实施例中，PDU会话类型处理机(210)将PDU配置为始终在线，并且在服务请求过程和注册请求过程中的一个期间，激活用于处理服务请求的特定PDU会话的用户平面资源，而不管在上行链路状态信息元素(IE)请求中没有PDU会话类型为始终在线的指示。
在实施例中，PDU会话类型处理机(210)使用UE通用配置更新过程和PDU修改过程中的一个，动态地触发对应于始终在线类型的PDU会话类型到正常PDU类型或者正常PDU类型的PDU会话类型到始终在线类型的配置改变。
在实施例中，PDU会话类型处理机(210)被配置为从用户设备(UE)(100)接收服务请求和注册请求过程中的一个。服务请求和注册请求过程中的一个包括协议数据单元(PDU)会话类型为始终在线PDU类型的PDU会话标识符。PDU会话类型处理机(210)被配置为基于PDU会话标识符来确定为PDU提供用户平面资源。PDU会话类型处理机(210)被配置为使用UE通用配置更新过程和PDU修改过程中的一个来动态地触发对应于PDU会话类型的配置改变。PDU会话类型处理机(210)被配置为基于配置改变来处理无线通信系统中的服务请求过程。
在实施例中，PDU会话类型处理机(210)被配置为在初始PDU会话建立过程期间，在用户设备(UE)(100)和网络(200)之间的协商中，确定PDU会话类型为始终在线PDU类型或正常PDU类型。PDU会话类型处理机(210)被配置为确定为PDU提供用户平面资源。PDU会话类型处理机(210)被配置为基于用户平面资源来处理无线通信系统中的服务请求过程。
处理器240被配置为执行存储在存储器230中的指令以及执行各种处理。通信器220被配置用于在内部硬件组件之间进行内部通信以及经由一个或多个网络与外部设备进行通信。
存储器230还存储将由处理器240执行的指令。存储器230可以包括非易失性存储元件。这种非易失性存储元件的示例可以包括磁硬盘、光盘、软盘、闪存或电可编程存储器(EPROM)或电可擦除可编程(EEPROM)存储器的形式。此外，在一些示例中，存储器230可以被认为是非暂时性存储介质。术语“非暂时性”可以指示存储介质没有体现在载波或传播信号中。然而，术语“非暂时性”不应被解释为存储器230是不可移动的。在一些示例中，存储器230可以被配置为存储比存储器更大量的信息。在某些示例中，非暂时性存储介质可以存储能够随时间变化的数据(例如，在随机存取存储器(RAM)或高速缓存中)。
在实施例中，PDU会话类型处理机(130)包括用于在无线通信系统中处理服务请求过程的PDU会话类型配置单元。在实施例中，PDU会话类型处理机(210)包括PDU类型确定单元、用户平面资源处理单元、用于处理无线通信系统中的服务请求过程的PDU会话类型处理单元。
尽管图27示出了无线通信系统2700的各种硬件组件，但是要理解，其他实施例不限于此。在其他实施例中，无线通信系统2700可以包括更少或更多数量的组件。此外，组件的标签或名称仅用于说明目的，并不限制本发明的范围。一个或多个组件可以组合在一起以执行相同或基本相似的功能来处理无线通信系统2700中的服务请求过程。
图28-图30是示出了根据本文公开的实施例的由无线通信系统2700实施的处理服务请求过程的各种操作的流程图2800-3000。
如图28中所示，在2802处，UE(100)将PDU会话类型配置为始终在线类型或正常PDU类型。在2804处，在初始PDU会话建立过程期间，UE(100)向网络(200)发送PDU会话建立请求消息，该PDU会话建立请求消息包括PDU会话类型为始终在线类型或正常PDU类型。在2806处，网络(200)从UE(100)接收PDU会话建立请求消息，该PDU会话建立请求消息包括PDU会话类型为始终在线类型或正常PDU类型。在2808处，网络(200)建立PDU会话类型为始终在线类型或正常PDU类型的PDU会话。
如图29中所示，在2902处，网络(200)将PDU配置为始终在线。在2904处，在服务请求过程和注册请求过程中的一个期间，网络(200)激活用于处理服务请求的特定PDU会话的用户平面资源，而不管在上行链路状态IE请求中没有PDU会话类型为始终在线的指示。
如图30中所示，在3002处，UE(100)动态地配置对应于始终在线类型的PDU会话类型到正常PDU类型或者正常PDU类型的PDU会话类型到始终在线类型的改变。在3004处，UE(100)在PDU会话建立请求消息中向网络(200)指示PDU会话类型为始终在线类型和正常类型中的一个，而不管PDU建立原因。在3006处，网络(200)从UE(100)接收作为始终在线类型和正常类型中的一个的PDU会话类型。在3008处，网络(200)基于PDU会话建立请求消息、网络(200)中的配置和网络(200)中的订阅中的一个，确定PDU会话类型为始终在线类型或正常类型。
流程图2800-3000中的各种动作、行动、块、步骤等可以以呈现的顺序、以不同的顺序或同时执行。此外，在一些实施例中，在不脱离本发明的范围的情况下，一些动作、行动、块、步骤等可以被省略、添加、修改、跳过等。
本文公开的实施例可以通过运行在至少一个硬件设备上并执行网络管理功能来控制元件的至少一个软件程序来实施。
特定实施例的前述描述将如此充分地揭示本文实施例的一般性质，以至于其他人可以通过应用当前知识，在不脱离一般概念的情况下，容易地修改和/或调整这些特定实施例以用于各种应用，因此，这些调整和修改应当并且旨在被理解为在所公开的实施例的等同物的含义和范围内。要理解，本文采用的措辞或术语是为了描述的目的，而不是为了限制。因此，尽管已经根据优选实施例描述了本文的实施例，但是本领域技术人员将认识到，可以利用在本文描述的实施例的精神和范围内的修改对本文的实施例进行实践。
