CN113923716A - 一种用户信息获取方法、装置和电子设备 - Google Patents

一种用户信息获取方法、装置和电子设备 Download PDF

Info

Publication number
CN113923716A
CN113923716A CN202111515087.2A CN202111515087A CN113923716A CN 113923716 A CN113923716 A CN 113923716A CN 202111515087 A CN202111515087 A CN 202111515087A CN 113923716 A CN113923716 A CN 113923716A
Authority
CN
China
Prior art keywords
data
associated data
protocol
user information
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.)
Granted
Application number
CN202111515087.2A
Other languages
English (en)
Other versions
CN113923716B (zh
Inventor
马驰超
王翔
徐文盛
Current Assignee (The listed assignees may be inaccurate. Google has not performed a legal analysis and makes no representation or warranty as to the accuracy of the list.)
Beijing Fule Technology Co ltd
Original Assignee
Beijing Fule Technology Co ltd
Priority date (The priority date is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the date listed.)
Filing date
Publication date
Application filed by Beijing Fule Technology Co ltd filed Critical Beijing Fule Technology Co ltd
Priority to CN202111515087.2A priority Critical patent/CN113923716B/zh
Publication of CN113923716A publication Critical patent/CN113923716A/zh
Application granted granted Critical
Publication of CN113923716B publication Critical patent/CN113923716B/zh
Active legal-status Critical Current
Anticipated expiration legal-status Critical

Links

Images

Classifications

    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04W—WIRELESS COMMUNICATION NETWORKS
    • H04W28/00—Network traffic management; Network resource management
    • H04W28/02—Traffic management, e.g. flow control or congestion control
    • H04W28/0205—Traffic management, e.g. flow control or congestion control at the air interface
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L67/00—Network arrangements or protocols for supporting network services or applications
    • H04L67/01—Protocols
    • H04L67/02—Protocols based on web technology, e.g. hypertext transfer protocol [HTTP]
    • 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/16—Implementation or adaptation of Internet protocol [IP], of transmission control protocol [TCP] or of user datagram protocol [UDP]
    • H04L69/163—In-band adaptation of TCP data exchange; In-band control procedures
    • 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/18—Multiprotocol handlers, e.g. single devices capable of handling multiple protocols
    • 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/22—Parsing or analysis of headers
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04W—WIRELESS COMMUNICATION NETWORKS
    • H04W28/00—Network traffic management; Network resource management
    • H04W28/02—Traffic management, e.g. flow control or congestion control
    • H04W28/06—Optimizing the usage of the radio link, e.g. header compression, information sizing, discarding information

Landscapes

  • Engineering & Computer Science (AREA)
  • Computer Networks & Wireless Communication (AREA)
  • Signal Processing (AREA)
  • Computer Security & Cryptography (AREA)
  • Computer And Data Communications (AREA)

Abstract

本申请涉及一种用户信息获取方法、装置和电子设备，方法包括：获取N11接口采集的AMF网元和SMF网元之间的待处理数据；根据TCP协议对待处理数据进行上下行关联，得到第一关联数据；根据HTTP2协议对第一关联数据进行请求与响应关联，得到第二关联数据；识别第二关联数据的消息类型，并根据消息类型获取对应的用户信息。本申请在N11接口采集AMF网元和SMF网元之间的用户信息得到采集待处理数据后，依次通过N11接口协议栈的TCP协议进行数据上下行关联、HTTP2进行请求与响应关联，得到第二关联数据，基于第二关联数据的消息类型的不同获取相应的用户信息，保证了用户信息及时获取和维护，提高了系统的业务能力。

Description

一种用户信息获取方法、装置和电子设备
技术领域
本申请涉及信息处理的技术领域，尤其是涉及一种用户信息获取方法、装置和电子设备。
背景技术
目前，5G是面向2020年以后移动通信需求而发展的新一代移动通信系统。5G具有超高的频谱利用率和能效，无线覆盖性能、传输时延、系统安全和用户体验得到显著提高。
现有的5G采用了控制面与用户面分离的架构，用户信息只在控制面中的部分接口才会出现，其他接口可能不具有用户信息采集的功能，因此，对用户信息采集和维护较差，可能存在移动网中的用户面数据无法关联到具体用户的情况，进而不能满足构建在数据之上的分析业务。
因此，如何提供一种解决上述技术问题的方案是本领域技术人员目前需要解决的问题。
发明内容
本申请目的一是提供一种用户信息获取方法，能够对用户信息进行及时的采集和维护，以提高业务处理能力。
本申请的上述申请目的一是通过以下技术方案得以实现的：
一种用户信息获取方法，包括：
获取N11接口采集的AMF网元和SMF网元之间的待处理数据；
根据TCP协议对所述待处理数据进行上下行关联，得到第一关联数据；
根据HTTP2协议对所述第一关联数据进行请求与响应关联，得到第二关联数据；
识别所述第二关联数据的消息类型，并根据所述消息类型获取对应的用户信息。
通过采用上述技术方案，本方案通过设置N11接口采集AMF网元和SMF网元之间的用户信息，具体的，在N11接口采集待处理数据后，待处理数据依次通过N11接口协议栈的TCP协议进行上下行关联、HTTP2进行请求与响应关联，得到第二关联数据，然后基于第二关联数据的消息类型的不同获取相应的用户信息，保证了用户信息能够及时获取以及维护，提高了系统的业务能力。
本申请在一较佳示例中可以进一步配置为：
所述获取N11接口采集的AMF网元和SMF网元之间的待处理数据之前，还包括：
获取所述AMF网元和所述SMF网元之间的接口数据；
判断所述接口数据对应的协议栈是否依次为以太网协议、IP协议、所述TCP协议、所述HTTP2协议；
若是，则将所述接口数据确定为所述待处理数据。
通过采用上述技术方案，本方案通过在获取到的接口数据中对其协议栈进行判断，进而过滤掉部分不符合N11接口采集到的数据，提高了N11接口的待处理数据的准确性，同时减少了后续运算数据量，进而提高了用户信息获取的效率。
本申请在一较佳示例中可以进一步配置为：
所述根据TCP协议对所述待处理数据进行上下行关联，得到第一关联数据，包括：
识别所述待处理数据的各TCP连接数据；
根据所述TCP连接数据的请求标识以及应答标识进行上下行关联，得到所述第一关联数据。
通过采用上述技术方案，本方案先识别待处理数据中包含的各TCP连接数据，对每组的TCP连接数据进行请求标识以及应答标识的确定，以进行上下行关联，得到第一关联数据，保证了TCP在应用层数据是明确且有序的。
本申请在一较佳示例中可以进一步配置为：
所述根据所述TCP连接数据的请求标识以及应答标识进行上下行关联，得到所述第一关联数据，包括：
根据所述TCP连接数据的所述请求标识以及所述应答标识进行上下行关联，得到初始第一关联数据；
判断所述初始第一关联数据是否为可靠数据；
若是所述可靠数据，则得到所述第一关联数据；
若不是所述可靠数据，则对所述初始第一关联数据进行数据修改，得到所述第一关联数据。
通过采用上述技术方案，本方案为了保证数据可靠传输，在进行上下关联后，判断初始第一关联数据是否是可靠数据，也就是说判断初始第一关联式数据是否存在重复包或者丢包等现象；当不是可靠数据时，及时对数据进行修改，保证数据的准确性。
本申请在一较佳示例中可以进一步配置为：
所述根据HTTP2协议对所述第一关联数据进行请求与响应关联，得到第二关联数据，包括：
根据所述HTTP2协议确定所述第一关联数据的目标帧对应的连接标识；其中，所述连接标识表征数据在当前TCP连接中的编号；
将所述第一关联数据中的连接标识相同的数据确定为同一请求以及响应，得到所述第二关联数据。
通过采用上述技术方案，本方案根据目标帧对应的连接标识进行同一请求以及响应的关联，对于每一组TCP连接数据来说，同一连接标识表示一个请求对应唯一响应，提高了数据关联的准确性。
本申请在一较佳示例中可以进一步配置为：
所述识别所述第二关联数据的消息类型，包括：
对所述第二关联数据进行特征识别，得到多个消息特征；
将多个所述消息特征与预设类型特征匹配信息进行匹配，确定所述消息类型。
通过采用上述技术方案，本方案为了能够完全甄别于其他的接口数据，且提高消息类型确定的准确性，先对第二关联数据进行特征识别，得到多个消息特征，将消息特征与系统内存储的预设类型特征匹配信息进行匹配，确定消息类型，以提高消息类型确定的准确性。
本申请在一较佳示例中可以进一步配置为：
所述根据所述消息类型获取对应的用户信息，包括：
根据所述消息类型确定待解码协议；其中，所述消息类型包括：创建用户上下文消息、更新用户上下文消息、释放用户上下文消息、传输N1/N2信令消息中的任意一种；
根据所述待解码协议对所述第二关联数据进行解析，得到所述用户信息。
通过采用上述技术方案，由于每种类型的待解码信息均不同，本方案先根据消息类型确定对应的待解码协议，然后基于该待解码协议进行第二关联数据的解析，能够提高解析的效率。
本申请在一较佳示例中可以进一步配置为：
所述用户信息获取方法，还包括：
根据所述用户信息，动态更新用户消息表。
通过采用上述技术方案，本方案根据得到用户信息实时更新用户消息表，以便得到用户信息能够得到动态更新，保证了用户信息的实时性以及准确性，进而为后续业务提供了有力支撑。
本申请目的二是提供一种用户信息获取装置，能够对用户信息进行及时的采集和维护，提高业务处理能力。
本申请的上述申请目的二是通过以下技术方案得以实现的：
一种用户信息获取装置，包括：
数据获取模块，用于获取N11接口采集的AMF网元和SMF网元之间的待处理数据；
第一关联数据获取模块，用于根据TCP协议对所述待处理数据进行上下行关联，得到第一关联数据；
第二关联数据获取模块，用于根据HTTP2协议对所述第一关联数据进行请求与响应关联，得到第二关联数据；
用户信息获取模块，用于识别所述第二关联数据的消息类型，并根据所述消息类型获取对应的用户信息。
通过采用上述技术方案，本方案通过设置N11接口采集AMF网元和SMF网元之间的用户信息，具体的，在N11接口采集待处理数据后，待处理数据依次通过N11接口协议栈的TCP协议进行上下行关联、HTTP2进行请求与响应关联，得到第二关联数据，然后基于第二关联数据的消息类型的不同获取相应的用户信息，保证了用户信息能够及时获取以及维护，提高了系统的业务能力。
本申请目的三是提供一种电子设备，能够对用户信息进行及时的采集和维护，以提高业务处理能力。
本申请的上述申请目的三是通过以下技术方案得以实现的：
一种电子设备，包括：
一个或者多个处理器；
存储器；
一个或多个应用程序，其中一个或多个应用程序被存储在存储器中并被配置为由一个或多个处理器执行，一个或多个程序配置用于：执行根据第一方面任一种可能的实现方式所示的一种用户信息获取方法。
通过采用上述技术方案，本方案通过设置N11接口采集AMF网元和SMF网元之间的用户信息，具体的，在N11接口采集待处理数据后，待处理数据依次通过N11接口协议栈的TCP协议进行上下行关联、HTTP2进行请求与响应关联，得到第二关联数据，然后基于第二关联数据的消息类型的不同获取相应的用户信息，保证了用户信息能够及时获取以及维护，提高了系统的业务能力。
本申请的上述申请目的四是通过以下技术方案得以实现的：
一种计算机可读存储介质，计算机可读存储介质上存储有计算机程序，计算机程序被处理器执行时实现如上用户信息获取方法的步骤。
通过采用上述技术方案，本方案通过设置N11接口采集AMF网元和SMF网元之间的用户信息，具体的，在N11接口采集待处理数据后，待处理数据依次通过N11接口协议栈的TCP协议进行上下行关联、HTTP2进行请求与响应关联，得到第二关联数据，然后基于第二关联数据的消息类型的不同获取相应的用户信息，保证了用户信息能够及时获取以及维护，提高了系统的业务能力。
综上所述，本申请包括以下至少一种有益技术效果：
1.能够对用户信息进行及时的采集和维护，提高业务能力；
2.用户信息获取效率更高，准确性更好。
附图说明
图1是本申请其中一实施例的用户信息获取方法的流程示意图；
图2为本申请实施例提供的一种第一关联数据建立的流程示意图；
图3为本申请实施例提供的一种第二关联数据获取的流程示意图；
图4为本申请实施例提供的一种用户信息获取的构架图；
图5是本申请其中一实施例的用户信息获取装置的结构框图；
图6是本申请其中一实施例的电子设备的结构框图。
具体实施方式
以下结合附图对本申请作进一步详细说明。
本具体实施例仅是对本申请的解释，其并不是对本申请的限制，本领域技术人员在阅读完本说明书后可以根据需要对本实施例做出没有创造性贡献的修改，但只要在本申请的范围内都受到专利法的保护。
为使本申请实施例的目的、技术方案和优点更加清楚，下面将结合本申请实施例中的附图，对本申请实施例中的技术方案进行清楚、完整地描述，显然，所描述的实施例是本申请一部分实施例，而不是全部的实施例。基于本申请中的实施例，本领域普通技术人员在没有作出创造性劳动前提下所获得的所有其他实施例，都属于本申请保护的范围。
另外，本文中术语“和/或”，仅是一种描述关联对象的关联关系，表示可以存在三种关系，例如，A和/或B，可以表示：单独存在A，同时存在A和B，单独存在B这三种情况。另外，本文中字符“/”，如无特殊说明，一般表示前后关联对象是一种“或”的关系。
下面结合说明书附图对本申请实施例作进一步详细描述。
本申请实施例提供了一种用户信息获取方法，由电子设备执行，该电子设备可以为服务器也可以为终端设备，其中，该服务器可以是独立的物理服务器，也可以是多个物理服务器构成的服务器集群或者分布式系统，还可以是提供云计算服务的云服务器。终端设备可以是智能手机、平板电脑、笔记本电脑、台式计算机等，但并不局限于此，该终端设备以及服务器可以通过有线或无线通信方式进行直接或间接地连接，本申请实施例在此不做限制，如图1所示，图1是本申请其中一实施例的用户信息获取方法的流程示意图，该方法包括：
S110、获取N11接口采集的AMF网元和SMF网元之间的待处理数据；
本实施例执行主体为电子设备，设置有各种接口进行数据交互，其中，设置有N11接口进行用户信息的抓取。本实施例中,N11接口属于SBI（Serial Bus Interface，串行总线接口）类型的接口，N11接口位于AMF（Access and Mobility Management Function，接入及移动性管理功能）网元和SMF（Session Management Function，会话管理功能）网元之间，待处理数据可以是在AMF网元或者SMF网元侧的网卡上进行分光得到。待处理数据可以包括：创建用户上下文消息的数据记为CreateSMContext的数据、更新用户上下文消息的数据记为UpdateSMContex的数据、释放用户上下文消息的数据记为ReleaseSMContex的数据、传输N1/N2信令消息记为N1N2MessageTransfer的数据。具体来说，在用户终端开机后，会进行数据交互，而设备接口会采集两个网元之间交互的数据，进而电子设备会得到N11接口的待处理数据。
本实施例不对获取的待处理数据的内容进行限定，可根据实际需求进行设置，只要是能够实现本实施例的目的即可。同时，本实施例不对获取N11接口采集的AMF网元和SMF网元之间的待处理数据的条件进行限定，在一种可实现的实施方式中，可以根据用户的采集指令进行数据采集，以得到待处理数据；在另一种可实现的实施方式中，可以定时定期进行数据采集，只要是能够实现本实施例的目的即可，用户可根据实际需求设置。
S120、根据TCP协议对待处理数据进行上下行关联，得到第一关联数据；
其中，N11接口属于SBI类型的接口，其协议栈自底向上依次为以太网协议、IP协议(Internet Protocol,网络之间互连的协议)、TCP协议（Transmission Control Protocol传输控制协议）、HTTP2协议（HyperText Transfer Protocol 2,超文本传输协议2）。本步骤的目的是进行上下行关联，也就是说确定待处理数据中的每一TCP连接中的所有响应数据以及请求数据，得到第一关联数据，其中，第一关联数据是将待处理数据中的数据按照TCP连接进行归类，每一类数据标识一组TCP连接，且每组TCP连接数据中存在多个请求数据以及响应数据，在TCP层面并不能对请求数据以及响应数据进行对应，进一步的进行对应的方式请参考步骤S130。
S130、根据HTTP2协议对第一关联数据进行请求与响应关联，得到第二关联数据；
本步骤的目的是基于HTTP2协议将第一关联数据中的响应数据以及请求数据进行关联，得到关联好的第二关联数据。第一关联数据中包括每一TCP连接对应的多个请求数据以及响应数据，本步骤的目的是将同一TCP连接中的请求数据与响应数据一一对应，以得到第二关联数据。
S140、识别第二关联数据的消息类型，并根据消息类型获取对应的用户信息。
可以理解的是，在不同阶段采集到的消息类型可能不相同，而不同消息类型需要处理的部分也不相同，因此本实施例中先识别第二关联数据的消息类型，然后根据消息类型从第二关联数据中得到用户信息，其中消息类型包括但是不限定于创建用户上下文消息、更新用户上下文消息、释放用户上下文消息、传输N1/N2信令消息。
进一步的，当得到用户信息后，还可以包括：
将用户信息发送至目标数据业务，来为目标数据业务提供用户信息。其中，目标数据业务包括但不限定于：用户上网行为识别、网络质量分析以及VoLTE/VoNR（Voice overLTE/ Voice Over NR，基于IMS的语音业务/高清通话）；当然，还可以作为5G核心网其他接口间数据关联的桥梁，为其他接口提供用户数据，通过接口将用户信息发送至其他不能获取用户信息的接口中，每个接口数据就可以携带用户信息。其中，网络质量分析：集采需求，对数据分析，根据用户位置上报是否及时来确定网元设备故障、用户量是否过多。
基于上述技术方案，本实施例通过设置N11接口采集AMF网元和SMF网元之间的用户信息，具体的，在N11接口采集待处理数据后，待处理数据依次通过N11接口协议栈的TCP协议进行上下行关联、HTTP2进行请求与响应关联，得到第二关联数据，然后基于第二关联数据的消息类型的不同获取相应的用户信息，保证了用户信息能够及时获取以及维护，提高了系统的业务能力。
基于上述实施例，在面对接口数据包括多种类型接口的数据的时候，为了减少数据分析量，减少系统负载压力，进一步的，获取N11接口采集的AMF网元和SMF网元之间的待处理数据之前，还包括：
获取AMF网元和SMF网元之间的接口数据；
判断接口数据对应的协议栈是否依次为以太网协议、IP协议、TCP协议、HTTP2协议；
若是，则将接口数据确定为待处理数据。
若否，则在设定条件下，获取下一接口数据，并执行判断的操作、。
其中，无论是AMF还是SMF进行分光，数据中可能存在其他接口数据情况的发生，接口数据包括N11接口数据还包括其他接口数据，本实施例需要进行数据预过滤，由于N11接口属于SBI类型的接口，其协议栈自底向上依次为以太网协议、IP协议、TCP协议、HTTP2协议。根据以太网协议的Type字段，判段报文第3层协议是否是IP协议；若不是IP协议，则停止数据处理流程，若是IP协议，根据IP协议的协议Protocol字段判断报文第4层协议是否是TCP协议；若不是TCP协议，则停止数据处理流程，若是TCP协议，根据TCP协议的源端口或目的端口判段应用层协议是否是HTTP2协议，若不是HTTP2协议，则停止数据处理流程，若是HTTP2协议，则将接口数据确定为待处理数据。通过上述方式滤除N1接口、N2接口的数据。
通过采用上述技术方案，本实施例通过在获取到的接口数据中对其协议栈进行判断，进而过滤掉部分不符合N11接口采集到的数据，提高了N11接口的待处理数据的准确性，同时减少了后续运算数据量，进而提高了用户信息获取的效率。
在一种可实现的实施方式中，提供一种第一关联数据建立的流程，以确保TCP应用层数据是明确且有序的，请参考图2，图2为本申请实施例提供的一种第一关联数据建立的流程示意图，包括：
S121、识别待处理数据的各TCP连接数据；
待处理数据中包括多组TCP连接数据。可以理解的是，每条TCP连接可以由三次握手开始，四次挥手结束，并通过五元组来唯一表示，其中，五元组包括源IP地址、目的IP地址、源端口号、目的端口号、IP协议的协议Protocol字段，以便得到每组TCP连接对应的TCP连接数据。可以理解的是，TCP协议是面向连接且可靠的字节流传输协议，握手的确定过程可以包括：判断TCP协议的标记Flag中是否具有SYN（synchronous，建立联机）标记，若有，则确定为握手成功；若没有，则确定没有握手。挥手的确定过程可以包括：判断TCP协议的标记Flag中是否带有FIN（finish，结束）标记，若有则确定为挥手成功，若没有则确定没有挥手。上下行关联可通过判断报文的五元组是否相同来进行。也就是说，在对于待处理数据先区别到多个握手数据、多个挥手数据，然后通过五元组来确定哪些握手数据以及挥手数据属于同一组TCP连接，将属于同一组TCP连接的数据作为TCP连接数据。例如，当通过挥手握手以及五元组确定后，待处理数据包括TCP连接数据1和TCP连接数据2，在TCP连接数据1中包括发送数据a、发送数据b、发送数据c，接收数据A、接收数据B、接收数据C；在TCP连接数据2中包括发送数据e、发送数据f、发送数据g、发送数据h，接收数据E、接收数据F、接收数据g。
S122、根据TCP连接数据的请求标识以及应答标识进行上下行关联，得到第一关联数据。
对于TCP连接中的发送数据以及接收数据通过其包括的请求标识或者应答标识来进行上下关联，得到第一关联数据。可以理解的是，接收数据可以是接收到对端的响应数据也可以是接收到对端的请求数据，发送数据可以是发送到对端的响应数据也可以是发送到对端的请求数据，本实施例不在进行限定，用户可根据实际需求进行设置，只要是能够实现本实施例的目的即可。例如对于发送数据i包括请求标识，则将其确定为请求数据；而对于发送数据j包括应答标识，则将其作为响应数据；对于接收数据k包括请求标识，则将其确定为请求数据；而对于接收数据l包括应答标识，则将其作为响应数据。
基于上述技术方案，本实施例先识别待处理数据中包含的各TCP连接数据，对每组的TCP连接数据进行请求标识以及应答标识的确定，以进行上下行关联，得到第一关联数据，保证了TCP协议在应用层数据是明确且有序的。
为了保证数据可靠性避免出现重复包以及丢包的现象的发生，进一步的，步骤S122，可以包括：根据TCP连接数据的请求标识以及应答标识进行上下行关联，得到初始第一关联数据；
判断初始第一关联数据是否为可靠数据；
若是可靠数据，则得到第一关联数据；
若不是可靠数据，则对初始第一关联数据进行数据修改，得到第一关联数据。
其中，可靠数据包括不丢包数据和/或没有重复数据包的数据。对于判断初始第一关联数据是否为可靠数据的方式，在一种可实现的实施方式中，可以依据请求标识以及应答标识进行判断，当存在标识重复的情况，证明存在重复数据包的情况，该数据为不可靠数据，当存在单个的应答标识，却不存在对应的请求标识时，确定存在丢包的情况，该数据为不可靠数据；在另一种可实现的实施方式中，可以是通过系统内存储的交互表确定是否存在丢包或者重复包的情况；当然还可能存在其他手段，本实施例不再进行限定，用户可根据实际需求进行设置，只要是能够实现本实施例的目的即可。本实施例为了保证数据可靠传输，在进行上下关联后判断初始第一关联数据是否是可靠数据，当不是可靠数据时，也就是说存在重复包的情况时，可以将重复的数据删除，以保证数据的准确性；当存在丢包的现象时可以进行标注，以便及时知道当前的数据情况。
基于上述技术方案，本实施例为了保证数据可靠传输，在进行上下关联后，判断初始第一关联数据是否是可靠数据，也就是说判断初始第一关联式数据是否存在重复包或者丢包等现象；当不是可靠数据时，及时对数据进行修改，保证数据的准确性。
在一种可实现的实施方式中，为了提高请求与响应关联的效率以及准确性，本实施例提供一种第二关联数据获取的方式，具体请参考图3，图3为本申请实施例提供的一种第二关联数据获取的流程示意图，包括：
S131、根据HTTP2协议确定第一关联数据的目标帧对应的连接标识；其中，连接标识表征数据在当前TCP连接中的编号；
S132、将第一关联数据中的连接标识相同的数据确定为同一请求以及响应，得到第二关联数据。
本实施例不对目标帧进行限定，可以包括头部帧、数据帧中的一种或者两种，用户根据实际需求设置。具体的，根据HTTP2协议的确定第一关联数据的头部帧对应的头部连接标识，将头部连接标识相同的数据确定为同一请求以及响应，得到第二关联数据；或，根据HTTP2协议的确定第一关联数据的数据帧对应的数据连接标识，将数据连接标识相同的数据确定为同一请求以及响应，得到第二关联数据；或，根据HTTP2协议的确定第一关联数据的头部帧、数据帧对应的头部连接标识、数据连接标识，将头部连接标识、数据连接标识均相同的数据确定为同一请求以及响应，得到第二关联数据。
例如，根据HTTP2的帧结构，处理后的应用层数据也就是第一关联数据逐帧切分，通过每帧头部的Type字段确定所属类型，再分别进行处理。例如，头部帧需要使用HPACK（header compression for HTTP/2，HTTP/2的头部压缩）算法对其进行解压缩；然后，从帧头中提取连接标识记为Stream Identifier，该字段表示当前传输的数据帧在同一条TCP连接中的编号,对于同一对请求和响应连接标识取值相同。HTTP2依靠这个字段在同一条TCP连接中实现并发访问。最后，结合数据包方向和同一连接标识，把HTTP2的请求与响应进行关联，得到第二关联数据。
基于采用上述技术方案，本实施例根据目标帧对应的连接标识进行同一请求以及响应的关联，对于每一组TCP连接数据来说，同一连接标识表示一个请求对应唯一响应，提高了数据关联的准确性。
基于上述任一实施例，可以理解的是，无论在AMF或SMF进行分光，其流量中都可能混有其他接口的数据。对于AMF，其报文中还会带有N1、N2、N8、N12、N14、N15、N22等接口的数据，进一步的，识别第二关联数据的消息类型，包括：
对第二关联数据进行特征识别，得到多个消息特征；
将多个消息特征与预设类型特征匹配信息进行匹配，确定消息类型。
其中，将上述接口任一消息也就是第二关联数据的特征归结为：所属网元、所属类别、请求方法、URL（Uniform Resource Locator，统一资源定位符）长度、和URL取值。其中，所属网元包括：SMF、AMF；所属类别包括：PDUSession、Communication；请求方法包括：POST、GET。
通过归纳并预置每个消息类型对于上述特征的具体取值，再逐一对比就可以唯一确定消息类型。以采集N11接口的4类消息为例，其分别涉及的特征取值即消息特征如表1所示。
表1消息的消息特征表
序号 消息名称 所属网元 所属类别 请求方法 URL长度 URL取值
1 Create SM Context SMF PDUSession POST 3 /nsmf-pdusession/v1/ sm-contexts
2 Update SM Context SMF PDUSession POST 5 /nsmf-pdusession/v1/sm-contexts/{smContextRef}/modify
3 Release SM Context SMF PDUSession POST 5 /nsmf-pdusession/v1/sm-contexts/{smContextRef}/release
4 N1N2MessageTransfer AMF Communication POST 5 /namf-comm/v1/ue-contexts/{ueContextId}/n1-n2-messages
基于上述技术方案，本实施例为了能够完全甄别于其他的接口数据，且提高消息类型确定的准确性，先对第二关联数据进行特征识别，得到多个消息特征，将消息特征与系统内存储的预设类型特征匹配信息进行匹配，确定消息类型，以提高消息类型确定的准确性。
本实施例提供一种具体的根据消息类型获取对应的用户信息的方式，包括：根据消息类型确定待解码协议；其中，消息类型包括：创建用户上下文消息、更新用户上下文消息、释放用户上下文消息、传输N1/N2信令消息中的任意一种；根据待解码协议对第二关联数据进行解析，得到用户信息。
可以理解的是，不同消息类型对应的待解码协议不同，在需要解析的4组消息中，每组消息包含的待解析的协议请参考表2。
表2消息包含的待解析协议表
序号 消息名称 待解析的协议
1 Create SM Context NAS-5GS、私有数据SMContextCreateData、SMContextCreatedData
2 Update SM Context NAS-5GS、NGAP、私有数据SmContextUpdateData、SmContextUpdatedData
3 Release SM Context NGAP、私有数据SmContextReleaseData、SmContextReleasedData
4 N1N2MessageTransfer NAS-5GS、NGAP、私有数据N1N2MessageTransferReqData、N1N2MessageTransferRspData
其中，Create SM Context 的待解析协议包括：NAS-5GS（Non-Access Stratum-5Gsystem，非接触层-5G系统）、私有数据SMContextCreateData、SMContextCreatedData；SMContextCreateData为用户创建数据。Update SM Context的待解析协议包括：NAS-5GS、NGAP（NG Application Protocol，应用层信令协议）、私有数据SmContextUpdateData、SmContextUpdatedData，其中，SmContextUpdatedData为用户更新数据。Release SMContext的待解析协议包括：NGAP、私有数据SmContextReleaseData、SmContextReleasedData，其中，SmContextReleasedData用户释放数据。N1N2MessageTransfer的待解析协议包括：NAS-5GS、NGAP、私有数据N1N2MessageTransferReqData、N1N2MessageTransferRspData，其中，N1N2MessageTransferRspData为请求/响应数据。
由于每类消息的作用和含义不同，因此可携带的关于用户的信息也不相同，具体请参考表3，表3示出了每类消息可获取的用户信息。
表3消息携带的用户信息表
序号 消息名称 用户信息
1 Create SM Context SUPI、GPSI、PEI、切片类型、切片码、接入网类型、国家码、网络码、TAC、CI、上行隧道、接入点名称
2 Update SM Context PEI、接入网类型、国家码、网络码、TAC、CI、上行隧道、下行隧道
3 Release SM Context TAC、CI
4 N1N2MessageTransfer SUPI、切片类型、切片码、上行隧道、用户IP地址、上行最大比特率、下行最大比特率
其中，对Create SM Context携带的用户信息进行进一步阐述，包括：SUPI（Subscription Permanent Identifier，用户永久标识）、GPSI（Generic PublicSubscription Identifier，通用公共用户标识）、PEI（Permanent Equipment Identifier，永久设备标识符）、切片类型、切片码、接入网类型、国家码、网络码、TAC （Type AllocationCode,类型分配码）、CI（Cell Identity，小区识别）。SUPI是用户标识，在完成存储后，当用户存在信息需求时，可以通过该识别码找到用户信息。
本实施例对四类消息进行进一步阐述。
对于Create SM Context消息，除表3涉及的用户信息字段之外，还有其他的字段，其作用是唯一标识该会话。从消息的Response报文帧头中提取Location域，再解析该域获得smContextRef。后续Update SM Context和Release SM Context消息，均需要携带该字段，从而标识该操作是针对之前哪个Create SM Context消息所涉及的用户。
对于Update SM Context消息，从URL中提取smContextRef字段，与之前记录下的Create SM Context中的smContextRef逐一对比，可以唯一确定当前操作是针对哪个用户，进而对该用户的信息进行更新。
对于Release SM Context消息，同Update SM Context消息。但该消息同时释放由Create SM Context创建的会话。
对于N1N2MessageTransfer消息，从URL中提取ueContextId，当该字段取SUPI的值时，与Create SM Context消息中的SUPI值相同，从而可以与Create SM Context消息进行关联，找到已创建的用户信息，对其进行更新。
基于上述技术方案，由于每种类型的待解码信息均不同，本实施例先根据消息类型确定对应的待解码协议，然后基于该待解码协议进行第二关联数据的解析，能够提高解析的效率。
进一步的，为了保证用户信息动态更新，用户信息获取方法，还包括：根据用户信息，动态更新用户消息表。
通过采用上述技术方案，本实施例根据得到用户信息实时更新用户消息表，以便得到用户信息能够得到动态更新，保证了用户信息的实时性以及准确性，进而为后续业务提供了有力支撑。
基于上述任一实施例，本实施例提供一种具体的用户消息获取方法，请参考图4，图4为本申请实施例提供的一种用户信息获取的构架图，其中，N11接口采集数据，服务器获取到采集到的待处理数据，执行数据接入、流表维护、上下行关联、协议预过滤；然后对上述数据进行，消息解码，可以包括消息类型识别、HTTP2解码关联、NAS-5GS解码、NGAP解码以及N11接口私有数据解码；然后进行用户信息获取，可以包括对三码（SUPI、GPSI、PEI）、位置（TAC、CI）、用户面上下行隧道（GTP Tunnel）和IP地址（IPv4/IPv6）等的获取；最终对获取的用户信息的持续维护，例如跟踪用户位置和上下行隧道的变化，实时刷新用户信息表。
本实施例通过采集分析5G核心网N11接口的数据，能够实时获取用户信息并跟踪其变化，进而构造用户信息数据库。该类数据进行数据业务处理，可用于网络质量分析、执行VoLTE/VoNR、用户上网行为识别或作为5G核心网其他接口间数据关联的桥梁，为开展其他业务打下坚实的数据基础。
下面对本申请实施例提供的一种用户信息获取装置进行介绍，下文描述的用户信息获取装置与上文描述的用户信息获取方法可相互对应参照，本实施例的用户信息获取装置设置在电子设备中，参考图5，图5是本申请其中一实施例的用户信息获取装置的结构框图，包括：
数据获取模块210，用于获取N11接口采集的AMF网元和SMF网元之间的待处理数据；
第一关联数据获取模块220，用于根据TCP协议对待处理数据进行上下行关联，得到第一关联数据；
第二关联数据获取模块230，用于根据HTTP2协议对第一关联数据进行请求与响应关联，得到第二关联数据；
用户信息获取模块240，用于识别第二关联数据的消息类型，并根据消息类型获取对应的用户信息。
基于上述技术方案，本实施例通过设置N11接口采集用户信息，具体的，在N11接口采集待处理数据后，待处理数据依次通过N11接口协议栈的TCP协议进行上下行关联、HTTP2进行请求与响应关联，得到第二关联数据，然后基于第二关联数据的消息类型的不同获取相应的用户信息，保证了用户信息能够及时获取以及维护，以提高业务能力。
优选的，还包括：
接口数据获取模块，用于获取AMF网元和SMF网元之间的接口数据；
判断模块，用于判断接口数据对应的协议栈是否依次为以太网协议、IP协议、TCP协议、HTTP2协议；
确定模块，用于若接口数据对应的协议栈依次为以太网协议、IP协议、TCP协议、HTTP2协议，则将接口数据确定为待处理数据。
优选的，第一关联数据获取模块220，包括：
识别单元，用于识别待处理数据的各TCP连接数据；
第一关联数据获取单元，用于根据TCP连接数据的请求标识以及应答标识进行上下行关联，得到第一关联数据。
优选的，第一关联数据获取单元包括：
初始第一关联数据获得子单元，用于根据TCP连接数据的请求标识以及应答标识进行上下行关联，得到初始第一关联数据；
判断子单元，用于判断初始第一关联数据是否为可靠数据；
第一关联数据获得子单元，用于若是可靠数据，则得到第一关联数据；
修改子单元，用于若不是可靠数据，则对初始第一关联数据进行数据修改，得到第一关联数据。
优选的，第二关联数据获取模块230，包括：
确定单元，用于根据HTTP2协议确定第一关联数据的目标帧对应的连接标识；其中，连接标识表征数据在当前TCP连接中的编号；
第二关联数据获取单元，用于将第一关联数据中的连接标识相同的数据确定为同一请求以及响应，得到第二关联数据。
优选的，用户信息获取模块240，包括：
特征识别单元，用于对第二关联数据进行特征识别，得到多个消息特征；
消息类型确定单元，用于将多个消息特征与预设类型特征匹配信息进行匹配，确定消息类型。
优选的，用户信息获取模块240，包括：
待解码协议确定单元，用于根据消息类型确定待解码协议；其中，消息类型包括：创建用户上下文消息、更新用户上下文消息、释放用户上下文消息、传输N1/N2信令消息中的任意一种；
用户信息获取单元，用于根据待解码协议对第二关联数据进行解析，得到用户信息。
优选的，还包括：
更新模块，用于根据用户信息，动态更新用户消息表。
由于装置部分的实施例与方法部分的实施例相互对应，因此装置部分的实施例请参见方法部分的实施例的描述，这里暂不赘述。
下面对本申请实施例提供的一种电子设备进行介绍，下文描述的电子设备与上文描述的用户信息获取方法可相互对应参照。
本申请实施例中提供了一种电子设备，如图6所示，图6所示的电子设备300包括：处理器301和存储器303。其中，处理器301和存储器303相连，如通过总线302相连。可选地，电子设备300还可以包括收发器304。需要说明的是，实际应用中收发器304不限于一个，该电子设备300的结构并不构成对本申请实施例的限定。
处理器301可以是CPU（Central Processing Unit，中央处理器），通用处理器，DSP（Digital Signal Processor，数据信号处理器），ASIC（Application SpecificIntegrated Circuit，专用集成电路），FPGA（Field Programmable Gate Array，现场可编程门阵列）或者其他可编程逻辑器件、晶体管逻辑器件、硬件部件或者其任意组合。其可以实现或执行结合本申请公开内容所描述的各种示例性的逻辑方框，模块和电路。处理器301也可以是实现计算功能的组合，例如包含一个或多个微处理器组合，DSP和微处理器的组合等。
总线302可包括一通路，在上述组件之间传送信息。总线302可以是PCI（Peripheral Component Interconnect，外设部件互连标准）总线或EISA（ExtendedIndustry Standard Architecture，扩展工业标准结构）总线等。总线302可以分为地址总线、数据总线、控制总线等。为便于表示，图6中仅用一条粗线表示，但并不表示仅有一根总线或一种类型的总线。
存储器303可以是ROM（Read Only Memory，只读存储器）或可存储静态信息和指令的其他类型的静态存储设备，RAM（Random Access Memory，随机存取存储器）或者可存储信息和指令的其他类型的动态存储设备，也可以是EEPROM（Electrically ErasableProgrammable Read Only Memory，电可擦可编程只读存储器）、CD-ROM（Compact DiscRead Only Memory，只读光盘）或其他光盘存储、光碟存储（包括压缩光碟、激光碟、光碟、数字通用光碟、蓝光光碟等）、磁盘存储介质或者其他磁存储设备、或者能够用于携带或存储具有指令或数据结构形式的期望的程序代码并能够由计算机存取的任何其他介质，但不限于此。
存储器303用于存储执行本申请方案的应用程序代码，并由处理器301来控制执行。处理器301用于执行存储器303中存储的应用程序代码，以实现前述方法实施例所示的内容。
其中，电子设备包括但不限于：移动电话、笔记本电脑、数字广播接收器、PDA（个人数字助理）、PAD（平板电脑）、PMP（便携式多媒体播放器）、车载终端（例如车载导航终端）等的移动终端以及诸如数字TV、台式计算机等的固定终端。图6示出的电子设备仅是一个示例，不应对本申请实施例的功能和使用范围带来任何限制。
下面对本申请实施例提供的一种计算机可读存储介质进行介绍，下文描述的计算机可读存储介质与上文描述的方法可相互对应参照。
本申请实施例提供了一种计算机可读存储介质，计算机可读存储介质上存储有计算机程序，计算机程序被处理器执行时实现如上用户信息获取方法的步骤。
基于上述技术方案，本实施例通过设置N11接口采集AMF网元和SMF网元之间的用户信息，具体的，在N11接口采集待处理数据后，待处理数据依次通过N11接口协议栈的TCP协议进行上下行关联、HTTP2进行请求与响应关联，得到第二关联数据，然后基于第二关联数据的消息类型的不同获取相应的用户信息，保证了用户信息能够及时获取以及维护，提高了系统的业务能力。
由于计算机可读存储介质部分的实施例与方法部分的实施例相互对应，因此计算机可读存储介质部分的实施例请参见方法部分的实施例的描述，这里暂不赘述。
应该理解的是，虽然附图的流程图中的各个步骤按照箭头的指示依次显示，但是这些步骤并不是必然按照箭头指示的顺序依次执行。除非本文中有明确的说明，这些步骤的执行并没有严格的顺序限制，其可以以其他的顺序执行。而且，附图的流程图中的至少一部分步骤可以包括多个子步骤或者多个阶段，这些子步骤或者阶段并不必然是在同一时刻执行完成，而是可以在不同的时刻执行，其执行顺序也不必然是依次进行，而是可以与其他步骤或者其他步骤的子步骤或者阶段的至少一部分轮流或者交替地执行。
以上仅是本申请的部分实施方式，应当指出，对于本技术领域的普通技术人员来说，在不脱离本申请原理的前提下，还可以做出若干改进和润饰，这些改进和润饰也应视为本申请的保护范围。

Claims (10)

1.一种用户信息获取方法，其特征在于，包括：
获取N11接口采集的AMF网元和SMF网元之间的待处理数据；
根据TCP协议对所述待处理数据进行上下行关联，得到第一关联数据；
根据HTTP2协议对所述第一关联数据进行请求与响应关联，得到第二关联数据；
识别所述第二关联数据的消息类型，并根据所述消息类型获取对应的用户信息。
2.根据权利要求1所述的用户信息获取方法，其特征在于，所述获取N11接口采集的AMF网元和SMF网元之间的待处理数据之前，还包括：
获取所述AMF网元和所述SMF网元之间的接口数据；
判断所述接口数据对应的协议栈是否依次为以太网协议、IP协议、所述TCP协议、所述HTTP2协议；
若是，则将所述接口数据确定为所述待处理数据。
3.根据权利要求1所述的用户信息获取方法，其特征在于，所述根据TCP协议对所述待处理数据进行上下行关联，得到第一关联数据，包括：
识别所述待处理数据的各TCP连接数据；
根据所述TCP连接数据的请求标识以及应答标识进行上下行关联，得到所述第一关联数据。
4.根据权利要求3所述的用户信息获取方法，其特征在于，所述根据所述TCP连接数据的请求标识以及应答标识进行上下行关联，得到所述第一关联数据，包括：
根据所述TCP连接数据的所述请求标识以及所述应答标识进行上下行关联，得到初始第一关联数据；
判断所述初始第一关联数据是否为可靠数据；
若是所述可靠数据，则得到所述第一关联数据；
若不是所述可靠数据，则对所述初始第一关联数据进行数据修改，得到所述第一关联数据。
5.根据权利要求1所述的用户信息获取方法，其特征在于，所述根据HTTP2协议对所述第一关联数据进行请求与响应关联，得到第二关联数据，包括：
根据所述HTTP2协议确定所述第一关联数据的目标帧对应的连接标识；其中，所述连接标识表征数据在当前TCP连接中的编号；
将所述第一关联数据中的连接标识相同的数据确定为同一请求以及响应，得到所述第二关联数据。
6.根据权利要求1所述的用户信息获取方法，其特征在于，所述识别所述第二关联数据的消息类型，包括：
对所述第二关联数据进行特征识别，得到多个消息特征；
将多个所述消息特征与预设类型特征匹配信息进行匹配，确定所述消息类型。
7.根据权利要求1所述的用户信息获取方法，其特征在于，所述根据所述消息类型获取对应的用户信息，包括：
根据所述消息类型确定待解码协议；其中，所述消息类型包括：创建用户上下文消息、更新用户上下文消息、释放用户上下文消息、传输N1/N2信令消息中的任意一种；
根据所述待解码协议对所述第二关联数据进行解析，得到所述用户信息。
8.根据权利要求1所述的用户信息获取方法，其特征在于，还包括：
根据所述用户信息，动态更新用户消息表。
9.一种用户信息获取装置，其特征在于，包括：
数据获取模块，用于获取N11接口采集的AMF网元和SMF网元之间的待处理数据；
第一关联数据获取模块，用于根据TCP协议对所述待处理数据进行上下行关联，得到第一关联数据；
第二关联数据获取模块，用于根据HTTP2协议对所述第一关联数据进行请求与响应关联，得到第二关联数据；
用户信息获取模块，用于识别所述第二关联数据的消息类型，并根据所述消息类型获取对应的用户信息。
10.一种电子设备，其特征在于，包括：
一个或者多个处理器；
存储器；
一个或多个应用程序，其中所述一个或多个应用程序被存储在所述存储器中并被配置为由所述一个或多个处理器执行，所述一个或多个程序配置用于：执行根据权利要求1～8任一项所述的用户信息获取方法。
CN202111515087.2A 2021-12-13 2021-12-13 一种用户信息获取方法、装置和电子设备 Active CN113923716B (zh)

Priority Applications (1)

Application Number Priority Date Filing Date Title
CN202111515087.2A CN113923716B (zh) 2021-12-13 2021-12-13 一种用户信息获取方法、装置和电子设备

Applications Claiming Priority (1)

Application Number Priority Date Filing Date Title
CN202111515087.2A CN113923716B (zh) 2021-12-13 2021-12-13 一种用户信息获取方法、装置和电子设备

Publications (2)

Publication Number Publication Date
CN113923716A true CN113923716A (zh) 2022-01-11
CN113923716B CN113923716B (zh) 2022-05-03

Family

ID=79249094

Family Applications (1)

Application Number Title Priority Date Filing Date
CN202111515087.2A Active CN113923716B (zh) 2021-12-13 2021-12-13 一种用户信息获取方法、装置和电子设备

Country Status (1)

Country Link
CN (1) CN113923716B (zh)

Citations (9)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN102301764A (zh) * 2011-07-01 2011-12-28 华为技术有限公司 终端分布信息获取方法、数据获取装置以及通信系统
CN111436057A (zh) * 2019-01-15 2020-07-21 华为技术有限公司 一种会话管理方法及装置
CN112312359A (zh) * 2019-07-23 2021-02-02 中兴通讯股份有限公司 一种实现信息关联的方法及装置
CN112672381A (zh) * 2021-01-13 2021-04-16 深圳市恒扬数据股份有限公司 一种数据关联方法、装置、终端设备及介质
CN112738791A (zh) * 2020-12-28 2021-04-30 恒安嘉新（北京）科技股份公司 基于5g核心网的用户信息关联回填方法、装置、设备和介质
US20210211960A1 (en) * 2017-01-09 2021-07-08 Lg Electronics Inc. Method for managing pdu session in wireless communication system and device for same
WO2021165856A1 (en) * 2020-02-17 2021-08-26 Telefonaktiebolaget Lm Ericsson (Publ) Partial support of access network information
CN113597022A (zh) * 2021-07-23 2021-11-02 恒安嘉新（北京）科技股份公司 接口间的用户标识关联方法、装置、计算机设备和介质
CN113596831A (zh) * 2020-04-14 2021-11-02 华为技术有限公司 一种切片认证中标识用户设备的通信方法和通信设备

Patent Citations (9)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN102301764A (zh) * 2011-07-01 2011-12-28 华为技术有限公司 终端分布信息获取方法、数据获取装置以及通信系统
US20210211960A1 (en) * 2017-01-09 2021-07-08 Lg Electronics Inc. Method for managing pdu session in wireless communication system and device for same
CN111436057A (zh) * 2019-01-15 2020-07-21 华为技术有限公司 一种会话管理方法及装置
CN112312359A (zh) * 2019-07-23 2021-02-02 中兴通讯股份有限公司 一种实现信息关联的方法及装置
WO2021165856A1 (en) * 2020-02-17 2021-08-26 Telefonaktiebolaget Lm Ericsson (Publ) Partial support of access network information
CN113596831A (zh) * 2020-04-14 2021-11-02 华为技术有限公司 一种切片认证中标识用户设备的通信方法和通信设备
CN112738791A (zh) * 2020-12-28 2021-04-30 恒安嘉新（北京）科技股份公司 基于5g核心网的用户信息关联回填方法、装置、设备和介质
CN112672381A (zh) * 2021-01-13 2021-04-16 深圳市恒扬数据股份有限公司 一种数据关联方法、装置、终端设备及介质
CN113597022A (zh) * 2021-07-23 2021-11-02 恒安嘉新（北京）科技股份公司 接口间的用户标识关联方法、装置、计算机设备和介质

Non-Patent Citations (1)

* Cited by examiner, † Cited by third party
Title
NOKIA等: "C4-195484 "Mobile Terminated Data Transfer for Control Plane CIoT 5GS Optimisation"", 《3GPP TSG_CT\WG4_PROTOCOLLARS_EX-CN4》 *

Also Published As

Publication number Publication date
CN113923716B (zh) 2022-05-03

Similar Documents

Publication Publication Date Title
US11425047B2 (en) Traffic analysis method, common service traffic attribution method, and corresponding computer system
US20200296181A1 (en) Data transmission method, apparatus and system
JP6686033B2 (ja) メッセージをプッシュするための方法および装置
WO2015165296A1 (zh) 协议类型的识别方法和装置
US20150312296A1 (en) Method and device for pushing multimedia resource and display terminal
WO2018018697A1 (zh) 伪基站垃圾短信鉴别方法及系统
CN103297270A (zh) 应用类型识别方法及网络设备
CN105302885B (zh) 一种全文数据的提取方法和装置
CN111931188B (zh) 登陆场景下漏洞测试方法及系统
CN107911398B (zh) 身份信息的认证方法、装置以及系统
CN110489474B (zh) 一种数据处理的方法、装置、介质和电子设备
CN108076149B (zh) 会话保持方法和装置
CN113923716B (zh) 一种用户信息获取方法、装置和电子设备
CN113055420B (zh) Https业务识别方法、装置及计算设备
US10506021B2 (en) Method and device for providing communication connection for a plurality of candidate applications in a mobile device
CN113395367A (zh) Https业务识别方法、装置、存储介质及电子设备
CN116055403A (zh) 报文数据的传输方法、装置和服务器
WO2023082605A1 (zh) Http报文的提取方法、装置、介质及设备
CN115297447A (zh) 一种长短信合并方法、系统、设备及存储介质
CN115865457A (zh) 一种网络攻击行为的识别方法、服务器及介质
CN112994849B (zh) 确定移动通信终端信息的方法、装置、设备及介质
CN111740996B (zh) 一种流量解析场景下快速拆分http请求与响应的方法
CN113383360B (zh) 内容推送方法、装置、服务端及存储介质
WO2014201789A1 (zh) 一种业务处理方法、装置及系统
CN109995731B (zh) 提高缓存吐出流量的方法、装置、计算设备及存储介质

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
GR01 Patent grant
GR01 Patent grant