Header enhancements for secure hypertext transfer protocol
By enhancing the CP and UP functions and using the PFCP protocol to insert custom headers in HTTPS mode, the problem that the CUPS architecture cannot support HTTPS header enhancement is solved, and mobile user information can be inserted into SSL/TLS messages to meet the security inspection requirements of Internet services.
Patent Information
- Application Number
- CN202080102813.5
- Authority / Receiving Office
- CN · China
- Patent Type
- Patents(China)
- Current Assignee / Owner
- Filing Date
- 2020-07-20
- Publication Date
- 2026-08-25
- Estimated Expiration
- 2040-07-20
AI Technical Summary
The existing CUPS architecture cannot effectively support HTTPS header enhancement, which prevents the UP function from inserting mobile user information into SSL/TLS messages and thus fails to meet the security inspection requirements of Internet services.
By enhancing the CP and UP functions, header enhancement instructions are provided in the PFCP session establishment or modification process using the PFCP protocol. These instructions instruct the UP function to insert custom headers in HTTPS mode, including setting header type, field names and values, and carrying this information in the SSL/TLS handshake message.
It enables the efficient insertion of mobile user information into HTTP headers under HTTPS mode, meeting the security inspection requirements of Internet services and improving the flexibility and adaptability of the CUPS architecture.
Smart Images

Figure CN115812291B_ABST
Abstract
Description
Technical Field
[0001] This patent document generally relates to wireless communication. Background Technology
[0002] Mobile communication technology is propelling the world towards an increasingly interconnected and networked society. The rapid growth of mobile communications and technological advancements have led to greater demands for capacity and connectivity. Other factors, such as energy consumption, device cost, spectrum efficiency, and latency, are also important for meeting the needs of various communication scenarios. Various technologies are being discussed, including new methods for providing higher quality service, longer battery life, and improved performance. Summary of the Invention
[0003] This patent document specifically describes methods, apparatus, and systems for enhancing CP and UP functions to support header enhancement for HTTPS.
[0004] In one aspect, a data communication method includes sending a session message from a first communication component to a second communication component, the session message instructing the second communication component to detect one or more messages from a user equipment based on a communication security protocol, wherein the session message includes detection information for the communication security protocol.
[0005] In another aspect, a data communication method includes sending a session message from a first communication component to a second communication component, instructing the second communication component to insert one or more customized headers into one or more messages from a user equipment based on a communication security protocol, wherein the session message includes header enhancement information associated with one or more messages from the user equipment based on the communication security protocol.
[0006] In another aspect, a data communication method includes receiving detection information for a communication security protocol from a first communication component by a second communication component, and detecting one or more messages based on the communication security protocol from a user equipment by the second communication component.
[0007] In another aspect, a data communication method includes: receiving header enhancement information associated with a message based on a communication security protocol from a first communication component by a second communication component; detecting one or more messages based on the communication security protocol from a user equipment by the second communication component; and inserting one or more header field names and values indicated by the header enhancement information into one or more messages by the second communication component.
[0008] These and other aspects are described in this patent document. Attached Figure Description
[0009] Figure 1An example of a Control and User Plane Separation (CUPS) architecture is shown, where the Control Plane (CP) functions include SGW-C / PGW-C / TDF-C, and the User Plane (UP) functions include SGW-U / PGW-U / TDF-U.
[0010] Figure 2 An example of a CUPS architecture in a 5G system is shown, where the CP function is SMF (Session Management Function) and the UP function is UPF (User Plane Function).
[0011] Figure 3 Examples of Packet Forwarding Control Protocol (PFCP) session establishment procedures for HTTP header enhancement are shown, based on some example embodiments of the disclosed technology, using CP and / or UP functions.
[0012] Figure 4 Examples of enhancements to the CP and / or UP functions based on some example embodiments of the disclosed technology are shown to support header enhancements for HTTPS (HTTP over SSL / TLS).
[0013] Figure 5 Examples of data communication methods based on some embodiments of the disclosed technology are shown.
[0014] Figure 6 Another example of a data communication method based on some embodiments of the disclosed technology is shown.
[0015] Figure 7 Another example of a data communication method based on some embodiments of the disclosed technology is shown.
[0016] Figure 8 Another example of a data communication method based on some embodiments of the disclosed technology is shown.
[0017] Figure 9 An example of a wireless communication system 900 to which one or more embodiments of the present technology may be applied is shown.
[0018] Figure 10 This is a block diagram representation of a wireless base station that can be applied to one or more embodiments of the present technology. Detailed Implementation
[0019] Examples of fifth-generation (5G) wireless protocols are used to describe certain characteristics. However, the applicability of the disclosed technologies is not limited to 5G wireless systems.
[0020] In example telecommunications systems, a single network entity performs Packet Data Network (PDN) / Packet Data Unit (PDU) session management and user plane service routing / forwarding, such as the Gateway General Packet Radio Service (GPRS) Support Node (GGSN) in 3G systems and the PDN Gateway (PGW) in 4G systems. While this model provides simplicity for network entity programming, it may not meet the requirements of dynamic and flexible service routing introduced in various deployment scenarios. For example, Mobile Edge Computing (MEC) typically requires services that are routed locally, while Internet services typically require services that are routed to upper-layer application servers via a core network service routing entity.
[0021] To support various service routing requirements, the Control and User Plane Separation (CUPS) was introduced starting with 4G. In the CUPS architecture, the Control Plane (CP) provides PDN / PDU session management functions, while the User Plane (UP) provides user plane service routing / forwarding functions.
[0022] Internet services should be subject to security checks by Internet service providers. To this end, the CUPS architecture is required to support header enhancement features, including a process for inserting critical information about the mobile user (such as IMSI or MSISDN) into the HTTP header when the mobile user browses a specific website using Hypertext Transfer Protocol (HTTP) mode.
[0023] In procedures associated with the CUPS architecture, the CP function provides the UP function with header enhancement information elements (header enhancement IEs) during the Packet Forwarding Control Protocol (PFCP) session establishment or modification process. The header enhancement IE indicates the header type (e.g., set to HTTP) and a list of header field names and their values. Therefore, when an outgoing HTTP request to the indicated website is detected, the UP function inserts the indicated mobile user information into the corresponding HTTP header or a custom HTTP header. As a result, the web server receiving the HTTP request from the mobile user examines the HTTP header and extracts the mobile user information (e.g., IMSI) for further use, such as tracking the indicated mobile user's web browsing history.
[0024] In one example implementation, the CUPS architecture, which supports header enhancements for HTTP, does not support extended header enhancements for HTTP such as HTTPS (Hypertext Transfer Protocol Secure). Because HTTP messages are encapsulated in secure Secure Sockets Layer (SSL) / Transport Layer Security (TLS) messages, and the UP function cannot decrypt HTTP messages from SSL / TLS messages, it is impossible for the UP function to insert mobile user information into the HTTP header of an HTTP message within an SSL / TLS message.
[0025] However, CUPS procedures implemented based on some embodiments of the disclosed technology can enhance CP and / or UP functions to support header enhancements for HTTPS.
[0026] Figure 1 An example of a Control and User Plane Separation (CUPS) architecture is shown, where the Control Plane (CP) functions include SGW-C, PGW-C, and TDF-C, and the User Plane (UP) functions include SGW-U, PGW-U, and TDF-U.
[0027] The CUPS architecture implemented based on some embodiments of the disclosed technology may include multiple network entities, including a Serving Gateway (SGW), a PDN Gateway (PGN), and a Traffic Detection Function (TDF).
[0028] The SGW terminates the user plane interface toward the E-UTRAN and provides a mobile anchor during handover between eNodeBs. The SGW-C (SGW Control Plane) controls the SGW-U (SGW User Plane) via the Sxa interface.
[0029] The PDN GW is a gateway that terminates the SGi interface toward the PDN (Packet Data Network). The PGW assigns IP addresses to the UE and provides IP service routing and forwarding functions. The PGW-C (PGW Control Plane) controls the PGW-U (PGW User Plane) through the Sxb interface.
[0030] TDF provides the ability to inspect service flows for specific services and applications. TDF-C (TDF Control Plane) controls TDF-U (TDF User Plane) through the Sxc interface.
[0031] Figure 2 An example of a CUPS architecture in a 5G system is shown, where the CP function is SMF (Session Management Function) and the UP function is UPF (User Plane Function).
[0032] The CUPS architecture implemented based on some embodiments of the disclosed technology may include multiple network functions, including Session Management Function (SMF) and User Plane Function (UPF).
[0033] SMF provides a variety of functions, including session establishment, modification and release, UE IP address allocation and management (including optional authorization functions), UP function selection and control, and downlink data notification. SMF controls UPF through N4 association.
[0034] UPF includes a variety of functions, including serving as an anchor point for intra / inter-Radio Access Technology (RAT) mobility, packet routing and forwarding, service usage reporting, user plane QoS processing, and downlink packet buffering and downlink data notification triggering.
[0035] In the CUPS architecture, CP and UP functions are general concepts. The CP function covers SGW-C / PGW-C / TDF-C in 4G systems and SMF in 5G systems, while the UP function covers SGW-U / PGW-U / TDF-U in 4G systems and UPF in 5G systems.
[0036] The CP function uses the PFCP protocol to control the UP function. For example, the PFCP protocol is used to establish PFCP associations between the CP function and the UP function and to manage PFCP sessions for the UE.
[0037] In order for the UP function to perform header enhancements for HTTP, the CP function provides header enhancement instructions to the UP function during the PFCP session initiation procedure or PFCP session modification procedure.
[0038] Figure 3 Examples of Packet Forwarding Control Protocol (PFCP) session establishment procedures for HTTP header enhancement are shown, based on some example embodiments of the disclosed technology, using CP and / or UP functions.
[0039] During the PFCP session establishment / modification process, the CP function provides the UPF with the necessary information to instruct the UP function to perform header enhancements for HTTP.
[0040] The CP function is triggered to establish a PFCP session to the UP function. In some implementations, the CP function is triggered by a PDN connection establishment request message from the MME (for 4G) or a PDU session establishment request message from the AMF (for 5G).
[0041] The CP function selects the appropriate UP function based on the Access Point Name (APN) / Data Network Name (DNN) and other information.
[0042] The CP function sends a PFCP session establishment request to the selected UP function, carrying the Packet Detection Rule (PDR), QoS Enforcement Rule (QER), Forwarding Action Rule (FAR), and Usage Reporting Rule (URR).
[0043] PDR defines message filters used for service data streams to, for example, filter out uplink / downlink traffic from / to a specific application (e.g., HTTP messages to a specific website).
[0044] In PDR, there can be one or more Service Data Flow (SDF) filters to express message filters for a specific service data flow.
[0045] QER is associated with at least one PDR and defines how to control the QoS of the detected service flow.
[0046] FAR is associated with at least one PDR and defines how detected service flows are routed and forwarded. For example, Mobile Edge Computing (MEC) services may need to be routed to a local server.
[0047] If header enhancement is required, one or more header enhancement IEs are included in the FAR to instruct the UP function to add specific headers (such as HTTP headers) to the detected service flow (such as HTTP messages). The header enhancement IE may include at least one of the following: header type, header field name, and header field value.
[0048] A URR is associated with at least one PDR and defines how to report the volume / time usage of detected service flows and how to report that usage to the CP function.
[0049] In some example implementations, in order to perform header enhancement for HTTP, the CP function can provide appropriate PDR, which can filter out outgoing HTTP requests from the UE to the web server.
[0050] In some example implementations, in order to perform header enhancements for HTTP, the CP function can also provide appropriate header enhancement IEs within the FAR associated with the PDR by setting the header type to HTTP and indicating the names and values of the header fields to be added.
[0051] When the CP function receives a PFCP session establishment request, the UP function installs the received rules (i.e., PDR / QER / FAR / URR) for this PFCP session.
[0052] The UP function sends a PFCP session establishment response message back to the CP function.
[0053] The CP function responds to the triggering entity for establishing a PDN connection / PDU session by sending a PDN connection / PDU session establishment response message.
[0054] The UP function begins detecting uplink / downlink traffic from / to the UE and attempts to match received IP packets with (multiple) PDRs. If an incoming IP packet matches a PDR, the corresponding QER / URR / FAR is executed.
[0055] Subsequently, the UE initiates an uplink service to the server. In this example, the UE sends an HTTP request to a dedicated web server.
[0056] The UP function checks uplink traffic from the UE to detect if it matches one of the installed PDRs. In this example, the uplink traffic (e.g., an HTTP request from the UE) matches the PDR that is detecting HTTP requests from the UE.
[0057] The UP function performs header enhancements for HTTP, that is, adds the indicated header fields and their values to the HTTP header of the outgoing HTTP request (such as custom HTTP headers).
[0058] The UP function forwards the modified IP packets, and thus the inserted header fields (e.g., header field names and corresponding values) are sent to the remote server.
[0059] like Figure 3 As shown, when a UE requests HTTP content from a web server using HTTP mode, the HTTP messages between the UE and the web server are sent in plaintext. Therefore, the UPF can extract the HTTP message from the incoming IP packet and parse the HTTP message to add the required field(s) names and(s) their values to the HTTP header.
[0060] If the UE requests an HTTP context from a web server using HTTPS mode, the HTTP message is encrypted within the SSL / TLS message. Therefore, the UPF may not unpack the SSL / TLS message to extract the HTTP message, rendering header enhancements for HTTPS impractical.
[0061] Figure 4 Examples of enhancements to the CP and / or UP functions based on some example embodiments of the disclosed technology are shown to support header enhancements for HTTPS (HTTP over SSL / TLS).
[0062] During the PFCP session establishment / modification process, the CP function provides the UPF with the necessary information to instruct the UP function to perform header enhancements for HTTPS.
[0063] In some embodiments of the disclosed technology, header enhancement for HTTPS may include the operations discussed below.
[0064] Operation 1. The CP function is triggered to establish a PFCP session to the UP function. In some implementations, the CP function is triggered by a PDN connection establishment request message from the MME (for 4G) or a PDU session establishment request message from the AMF (for 5G).
[0065] The CP function selects the appropriate UP function based on the Data Network Name (DNN) and other information.
[0066] Operation 2. The CP function sends a PFCP session establishment request to the selected UP function, carrying PDR, QER, FAR and URR.
[0067] In some example implementations, in order to perform header enhancements for HTTPS (HTTP over SSL / TLS), the CP function can provide an appropriate PDR, which provides at least one PDI (Packet Detection Information) to filter out SSL / TLS packets from the UE's outgoing packets.
[0068] In some example implementations, to perform header enhancements for HTTPS, the CP function can provide at least one FAR associated with a given PDR. Within the FAR, one or more header enhancement IEs are included. In one example, the header type of a given header enhancement IE is set to "TLS" or "SSL / TLS". In another example, the header type of a given header enhancement IE is set to "HTTPS". The header field names and header field values of a given header enhancement IE carry the names and values of the header fields to be inserted.
[0069] In order for the UP function to know that the PDR's objective is to detect SSL / TLS messages from the UE, the CP function provides at least one of the following indications related to HTTPS header enhancement.
[0070] In the implementation, the TLS indication (or HTTPS indication) in the PDR or SDF filter is configured to indicate that SSL / TLS (or HTTPS) is being used by the current service data stream. By checking the TLS indication (or HTTPS indication) in the PDR or SDF filter, the UP function knows that the current service data stream is using SSL / TLS (HTTPS).
[0071] In another implementation, the SDF filter uses a known port (i.e., 443) for the SSL / TLS protocol. The destination port of the SDF filter is set to this known port to indicate that SSL / TLS is used by the current service data stream. By checking if the destination port matches the known SSL / TLS port, the UP function can identify the current service data stream's use of the SSL / TLS protocol.
[0072] In another implementation, the SDF filter uses a pre-configured SSL / TLS port (e.g., a port other than 443) known to the CP and UP functions. The destination port of the SDF filter is set to the pre-configured SSL / TLS port, thereby indicating that SSL / TLS is used by the current service data flow. By checking whether the destination port matches the pre-configured SSL / TLS port, the UP function can identify the current service data flow's use of the SSL / TLS protocol.
[0073] In another implementation, within FAR, the header type of the header enhancement IE is set to one of the values of TLS, SSL / TLS, and HTTPS. By examining the specific value of the header type, the UP function can identify the current business data flow's use of the SSL / TLS protocol.
[0074] Using one of the above indications, the UP function can identify the use of SSL / TLS in the service data stream identified by the PDR, and therefore can attempt to parse the SSL / TLS message encapsulated in the received TCP message.
[0075] Operation 3. When receiving a PFCP session establishment request from the CP function, the UP function installs the received PDR / QER / FAR / URR for the PFCP session.
[0076] Operation 4. The UP function sends a PFCP session establishment response message back to the CP function.
[0077] Operation 5. The CP function responds to the triggering entity for PDN connection / PDU session establishment by sending a PDN connection / PDU session establishment response message.
[0078] Operation 6. The UP function begins detecting uplink / downlink traffic from / to the UE and attempts to match received IP packets with (multiple) PDRs. If an incoming IP packet matches a PDR, the corresponding QER / URR / FAR should be executed.
[0079] Operation 7. Subsequently, the UE initiates an uplink service to the server. In this example, the UE sends an SSL / TLS connection request to a dedicated web server.
[0080] When HTTPS is used with the target web server, an SSL / TLS connection is first established between the UE and the web server using the SSL / TLS handshake protocol. After a successful SSL / TLS handshake, all exchanged HTTP messages are encrypted within the SSL / TLS message. Because the SSL / TLS handshake message is exchanged in plaintext, it allows the UP function to incorporate additional information into the SSL / TLS handshake message, such as carrying the names and values of multiple header fields required by the CP function. Therefore, the web server can extract the inserted header fields and their values from the SSL / TLS handshake message.
[0081] Operation 8.UP function checks the uplink traffic from the UE and detects whether it can match one of the installed PDRs.
[0082] In some implementations, the UP function can detect whether an uplink traffic (SSL / TLS message from the UE) matches the PDR of the SSL / TLS message from the UE that is being detected. If so, the UP function performs operation 9, as will be discussed below. Otherwise, the UP function can skip operation 9.
[0083] Operation 9.UP performs header enhancements for HTTPS (HTTP over SSL / TLS).
[0084] In some implementations, if the received SSL / TLS message from the UE carries an initial SSL / TLS handshake message, such as "Hello Client", the UP function inserts an additional SSL / TLS extension into the received SSL / TLS message and puts the names and values of (multiple) header fields required by the CP function into the additional SSL / TLS extension.
[0085] The SSL / TLS handshake protocol limits the SSL / TLS extensions that can be used to carry custom information. Therefore, intermediate nodes in the SSL / TLS message transmission path have the possibility of inserting additional SSL / TLS extensions to carry service-specific parameters. After inserting the additional SSL / TLS extension, the intermediate node updates the length of the SSL / TLS message.
[0086] Operation 10.UP sends a modified SSL / TLS message forward. The modified SSL / TLS message eventually reaches the target server, where the target server extracts the header field names and values from the additional SSL / TLS extensions.
[0087] like Figure 4 As shown, the CP function instructs the UP function to inspect SSL / TLS messages and provide (multiple) header field names and (multiple) their values. Therefore, the UP function monitors uplink SSL / TLS messages from the UE. If the uplink SSL / TLS message carries an initial SSL / TLS handshake message from the UE, i.e., a "Hello Client" message, the UP function will then insert additional SSL / TLS extensions into the SSL / TLS handshake message to carry the required (multiple) header field names and (multiple) their values.
[0088] In some embodiments of the disclosed technology, the CP function can provide a PDR for detecting SSL / TLS messages from / to the UE, and can provide a FAR associated with the PDR. The FAR includes a header enhancement IE, which includes a header type set to HTTPS (or SSL / TLS), and the required header field(s) name and(s) value(s).
[0089] In some embodiments of the disclosed technology, the CP function may also carry SSL / TLS indication information to notify the UP function that SSL / TLS will be used on the service data stream identified by the PDR.
[0090] The SSL / TLS indication information can be one of the following: an explicit indication that the SSL / TLS protocol is being used on this service stream (e.g., "SSL / TLS is being used"). This indication can be carried in the PDR or in the SDF (Service Stream) filter; or in the SDF filter, the destination port is set to a known port (i.e., 443) used by the web server for the SSL / TLS protocol; or in the SDF filter, the destination port is set to a pre-configured port used by the web server for the SSL / TLS protocol (e.g., a pre-configured port other than 443). By checking this pre-configured destination port, the UP function knows that the SSL / TLS protocol is being used; or in the header enhancement IE of the FAR associated with the indicated PDR, the header type is set to one of the values of TLS, SSL / TLS, and HTTPS.
[0091] In some embodiments of the disclosed technology, the UP function may install the PDR and associated FAR provided by the CP function; determine that SSL / TLS is used on the service data stream identified by the PDR; and begin monitoring uplink traffic from the UE. If the uplink traffic is detected as an SSL / TLS handshake message, the UP function inserts additional extensions into the received SSL / TLS message.
[0092] In some embodiments of the disclosed technology, the digital communication method may include sending TLS (or HTTPS) detection information to the UP function to instruct the UP function to detect SSL / TLS (or HTTPS) messages from the UE.
[0093] In some implementations, TLS (HTTPS) detection information is one of the TLS indications (or HTTPS indications) in the PDR or SDF filter.
[0094] In some implementations, the TLS (HTTPS) detection information is one of the known ports for the SSL / TLS protocol in the SDF filter, or one of the pre-configured SSL / TLS ports (e.g., ports other than 443) known for the CP and UP functions in the SDF filter.
[0095] In some implementations, the TLS (HTTPS) detection information is a header type of the header enhancement IE that is set to one of the values of TLS, SSL / TLS, and HTTPS.
[0096] In some embodiments of the disclosed technology, the digital communication method may include sending HTTPS header enhancement information to the UP function, instructing the UP function to insert a custom header into the SSL / TLS message from the UE.
[0097] In some implementations, HTTPS header enhancement information is the header type of the header enhancement IE set to one of TLS, SSL / TLS, and HTTPS values, as well as the name and value of the header field to be inserted.
[0098] In some embodiments of the disclosed technology, the digital communication method may include receiving TLS (or HTTPS) detection information from the CP function, and detecting SSL / TLS (or HTTPS) messages from the UE.
[0099] In some implementations, TLS (HTTPS) detection information is one of the TLS indications (or HTTPS indications) in the PDR or SDF filter.
[0100] In some implementations, the TLS (HTTPS) detection information is one of the known ports for the SSL / TLS protocol in the SDF filter, or one of the pre-configured SSL / TLS ports (e.g., ports other than 443) known for the CP and UP functions in the SDF filter.
[0101] In some implementations, the TLS (HTTPS) detection information is a header type of the header enhancement IE that is set to one of the values of TLS, SSL / TLS, and HTTPS.
[0102] In some embodiments of the disclosed technology, the digital communication method may include receiving HTTPS header enhancement information from a CP function and inserting the required header field names and values into the detected SSL / TLS message.
[0103] In some implementations, HTTPS header enhancement information is the header type of the header enhancement IE set to one of TLS, SSL / TLS, and HTTPS values, as well as the name and value of the header field to be inserted.
[0104] In some implementations, inserting the required header field names and values into the detected SSL / TLS message may include detecting that the uplink IP packet from the UE is an SSL / TLS packet carrying an SSL / TLS handshake message, inserting an additional SSL / TLS extension into the SSL / TLS handshake message, and inserting the required header field names and values into the inserted SSL / TLS extension.
[0105] In some implementations, the SSL / TLS handshake message is an SSL / TLS handshake message from the client, such as "Hello, client".
[0106] Figure 5 Examples of data communication methods based on some exemplary embodiments of the disclosed technology are shown.
[0107] In some embodiments of the disclosed technology, the data communication method 500 includes, at 510, a session message sent by a first communication component to a second communication component, instructing the second communication component to detect one or more messages from a user equipment based on a communication security protocol, wherein the session message includes detection information for the communication security protocol.
[0108] In the context of this patent document, the term "first communication component" can be used to indicate the CP function, while the term "second communication component" can be used to indicate the UP function.
[0109] Figure 6 Another example of a data communication method based on some example embodiments of the disclosed technology is shown.
[0110] In some embodiments of the disclosed technology, the data communication method 600 includes, at 610, a first communication component sending a session message to a second communication component instructing the second communication component to insert one or more custom headers into one or more messages from a user equipment based on a communication security protocol, wherein the session message includes header enhancement information associated with one or more messages from the user equipment based on the communication security protocol.
[0111] Figure 7Another example of a data communication method based on some example embodiments of the disclosed technology is shown.
[0112] In some embodiments of the disclosed technology, the data communication method 700 includes, at 710, receiving detection information for a communication security protocol from a first communication component by a second communication component, and at 720, detecting one or more messages based on the communication security protocol from a user equipment by the second communication component.
[0113] Figure 8 Another example of a data communication method based on some example embodiments of the disclosed technology is shown.
[0114] In some embodiments of the disclosed technology, the data communication method 800 includes: at 810, receiving header enhancement information associated with a message based on a communication security protocol from a first communication component by a second communication component; at 820, detecting one or more messages based on a communication security protocol from a user equipment by the second communication component; and at 830, inserting one or more header field names and values indicated by the header enhancement information into one or more messages by the second communication component.
[0115] Figure 9 An example of a wireless communication system 900 in which one or more embodiments of the present technology can be applied is shown. The wireless communication system 900 may include one or more base stations (BS) 905a, 905b, one or more wireless devices 910a, 910b, 910c, 910d, and a core network 925. Base stations 905a, 905b may provide wireless services to wireless devices 910a, 910b, 910c, and 910d in one or more wireless sectors. In some embodiments, base stations 905a, 905b include directional antennas to generate two or more directional beams, thereby providing wireless coverage in different sectors.
[0116] The core network 925 can communicate with one or more base stations 905a, 905b. The core network 925 provides connectivity with other wireless and wired communication systems. The core network may include one or more service subscription databases to store information related to subscribed wireless devices 910a, 910b, 910c, and 910d. The first base station 905a can provide wireless services based on a first wireless access technology, while the second base station 905b can provide wireless services based on a second wireless access technology. Depending on the deployment scenario, base stations 905a and 905b can be co-located or installed separately in the field. Wireless devices 910a, 910b, 910c, and 910d can support a variety of different wireless access technologies. The technologies and embodiments described herein can be implemented by base stations of the wireless devices described herein.
[0117] Figure 10 This is a block diagram representation of a portion of a wireless base station to which one or more embodiments of the present invention may be applied. Wireless device 1005 (such as a base station or wireless device (or UE)) may include processor electronics 1010, such as a microprocessor implementing one or more of the wireless technologies presented in this document. Wireless device 1005 may include transceiver electronics 1015 for transmitting and / or receiving wireless signals via one or more communication interfaces, such as antenna 1020. Wireless device 1005 may include other communication interfaces for transmitting and receiving data. Wireless device 1005 may include one or more memories (not explicitly shown) configured to store information such as data and / or instructions. In some embodiments, processor electronics 1010 may include at least a portion of transceiver electronics 1015. In some embodiments, wireless device 1005 is used to implement at least some of the disclosed technologies, modules, or functions. In some embodiments, wireless device 1005 may be configured to perform the methods described in this document.
[0118] It should be understood that this document discloses techniques that can be implemented in various embodiments to establish and manage multicast sessions in various scenarios. The disclosed and other embodiments, modules, and functional operations described in this document can be implemented in digital electronic circuit systems, or in computer software, firmware, or hardware that includes the structures disclosed in this document and their structural equivalents, or combinations thereof. The disclosed and other embodiments can be implemented as one or more computer program products, i.e., one or more modules of computer program instructions encoded on a computer-readable medium for execution by a data processing apparatus or for controlling the operation of a data processing apparatus. The computer-readable medium can be a machine-readable storage device, a machine-readable storage substrate, a memory device, a composition of substances that implement machine-readable propagation signals, or combinations thereof. The term "data processing apparatus" includes all means, devices, and machines for processing data, including, for example, a programmable processor, a computer, or multiple processors or computers. In addition to hardware, the apparatus may include code that creates an execution environment for the computer program in question, such as code constituting processor firmware, a protocol stack, a database management system, an operating system, or combinations thereof. The transmitted signal is an artificially generated signal, such as an electrical signal, optical signal, or electromagnetic signal generated by a machine to encode information for transmission to a suitable receiver device.
[0119] Computer programs (also known as programs, software, software applications, scripts, or code) can be written in any programming language, including compiled or interpreted languages, and can be deployed in any form, including as standalone programs or as modules, components, subroutines, or other units suitable for use in a computing environment. A computer program does not necessarily correspond to a file in a file system. A program can be stored as a portion of a file that holds other programs or data (e.g., one or more scripts stored in a markup language document), as a single file dedicated to the program in question, or as multiple coordinating files (e.g., a file storing portions of one or more modules, subroutines, or code). A computer program can be deployed to execute on a single computer or on multiple computers located at a single site or distributed across multiple sites and interconnected via a communication network.
[0120] The processes and logic flows described herein can be executed by one or more programmable processors, which execute one or more computer programs to perform functions by manipulating input data and generating outputs. The processes and logic flows can also be executed by a dedicated logic circuit system, and the device can be implemented as a dedicated logic circuit system, such as an FPGA (Field Programmable Gate Array) or an ASIC (Application Specific Integrated Circuit).
[0121] As an example, processors suitable for executing computer programs include both general-purpose microprocessors and special-purpose microprocessors, as well as any one or more processors in any type of digital computer. Generally, a processor receives instructions and data from read-only memory or random access memory, or both. The fundamental elements of a computer are a processor for executing instructions and one or more memory devices for storing instructions and data. Generally, a computer will also include one or more mass storage devices (e.g., magnetic disks, magneto-optical disks, or optical disks) for storing data, or operatively coupled to receive data from or transfer data to or from such mass storage devices, or both. However, a computer does not require such devices. Computer-readable media suitable for storing computer program instructions and data include all forms of non-volatile memory, media, and memory devices, including, as examples, semiconductor memory devices (e.g., EPROM, EEPROM, and flash memory devices); magnetic disks (e.g., internal hard disks or removable disks); magneto-optical disks; and CD-ROMs and DVD-ROMs. The processor and memory may be supplemented or incorporated into a dedicated logic circuit system.
[0122] Some embodiments may preferably implement one or more of the following solutions listed in the terms format. The following terms are supported and further described in the examples above and throughout this document. As used in the following terms and claims, a wireless terminal may be a user equipment, a mobile station, or any other wireless terminal including a fixed node such as a base station. A network node includes a base station, including a Next Generation Node B (gNB), an Enhanced Node B (eNB), or any other device operating as a base station. A resource range may refer to a range of time-frequency resources or blocks.
[0123] Clause 1. A data communication method comprising: sending a session message from a first communication component to a second communication component, instructing the second communication component to detect one or more messages from a user equipment based on a communication security protocol, wherein the session message includes detection information for the communication security protocol. In some embodiments, the first communication component includes a CP function, and the second communication component includes a UP function.
[0124] Clause 2. The method according to Clause 1, wherein the communication security protocol includes at least one of Secure Sockets Layer (SSL), Transport Layer Security (TLS), or Secure Hypertext Transfer Protocol (HTTPS).
[0125] Clause 3. The method according to any one of Clauses 1 to 2, wherein the detection information includes an indication of at least one of a message detection rule or a service flow filter for at least one of Transport Layer Security (TLS) or Secure Hypertext Transfer Protocol (HTTPS). In some implementations, the message detection rule may indicate a PDR, and the service flow filter may indicate an SDF filter.
[0126] Clause 4. The method of Clause 3, wherein the message detection rules include message detection information configured to filter out one or more outgoing SSL or TLS messages from the user equipment.
[0127] Clause 5. The method of Clause 3, wherein the service data flow filter is associated with the message inspection rules.
[0128] Clause 6. The method according to any one of Clauses 1 to 2, wherein the detection information includes at least one of a known port for the SSL or TLS protocol in the service data stream filter, or a pre-configured port for the SSL or TLS protocol in the service data stream filter known to the first and second communication components.
[0129] Clause 7. The method according to any one of Clauses 1 to 2, wherein the detection information includes a value set to the header type of a header enhancement information element corresponding to at least one of TLS, SSL / TLS, or HTTPS. In some implementations, the header enhancement information element may indicate a header enhancement IE.
[0130] Clause 8. In accordance with the method of Clause 7, wherein the header enhancement information element is included in the forwarding action rule (FAR).
[0131] Clause 9. A data communication method comprising sending a session message from a first communication component to a second communication component, instructing the second communication component to insert one or more custom headers into one or more messages from a user equipment based on a communication security protocol, wherein the session message includes header enhancement information associated with the one or more messages from the user equipment based on the communication security protocol.
[0132] Clause 10. The method pursuant to Clause 9, wherein the communication security protocol includes at least one of Secure Sockets Layer (SSL), Transport Layer Security (TLS), or Secure Hypertext Transfer Protocol (HTTPS).
[0133] Clause 11. The method according to any one of Clauses 9 to 10, wherein the header enhancement information includes a value set to the header type of a header enhancement information element corresponding to at least one of TLS, SSL / TLS, or HTTPS.
[0134] Clause 12. The method of Clause 11, wherein the header enhancement information element is included in the forwarding action rule (FAR).
[0135] Clause 13. The method according to any one of Clauses 9 to 10, wherein the header enhancement information includes the name and value of a header field to be inserted into one or more messages from the user equipment.
[0136] Clause 14. The method according to any one of Clauses 1 to 13 further includes a triggering entity that receives a packet data network connection establishment request or a packet data unit session establishment request by the first communication component, and a packet data network connection establishment response or a packet data unit session establishment response that is sent by the first communication component.
[0137] Clause 15. A data communication method comprising receiving detection information for a communication security protocol from a first communication component by a second communication component, and detecting one or more messages based on the communication security protocol from a user equipment by the second communication component.
[0138] Clause 16. The method pursuant to Clause 15, wherein the communication security protocol includes at least one of Secure Sockets Layer (SSL), Transport Layer Security (TLS), or Secure Hypertext Transfer Protocol (HTTPS).
[0139] Clause 17. The method according to any one of Clauses 15 to 16, wherein the detection information includes at least one of a message detection rule or a service data stream filter, which is an indication for at least one of Transport Layer Security (TLS) or Secure Hypertext Transfer Protocol (HTTPS).
[0140] Clause 18. The method of Clause 17, wherein detecting one or more messages from a user equipment based on detection information includes determining that one or more messages use at least one of Transport Layer Security (TLS) or Secure Hypertext Transfer Protocol (HTTPS) by examining indications in message detection rules or service data stream filters.
[0141] Clause 19. The method according to any one of Clauses 15 to 16, wherein the detection information includes at least one of a known port for the SSL or TLS protocol in the service data stream filter, or a pre-configured port for the SSL or TLS protocol in the service data stream filter known to the first and second communication components.
[0142] Clause 20. The method pursuant to Clause 15, wherein detecting one or more messages from a user equipment based on detection information includes determining whether a destination port matches a known port used for an SSL or TLS protocol, and, when determining that a destination port matches a known port used for an SSL or TLS protocol, determining that the current service data stream uses an SSL or TLS protocol.
[0143] Clause 21. The method according to any one of Clauses 15 to 16, wherein the detection information includes a value set to the header type of a header enhancement information element corresponding to at least one of TLS, SSL / TLS, or HTTPS.
[0144] Clause 22. The method according to Clause 21, wherein detecting one or more messages from a user equipment includes determining that the current service data stream uses the SSL or TLS protocol when determining that the header type of a header enhancement information element is set to a value corresponding to at least one of TLS, SSL / TLS, or HTTPS.
[0145] Clause 23. The method pursuant to any one of Clauses 15 to 22 may also include parsing the encapsulated SSL or TLS message of one or more messages.
[0146] Clause 24. The method according to Clause 15 further includes, upon receiving a Message Forwarding Control Protocol (PFCP) session establishment request from the first communication component, having the second communication component install at least one of a Message Detection Rule (PDR), a QoS Enforcement Rule (QER), a Forwarding Action Rule (FAR), or a Usage Reporting Rule (URR).
[0147] Clause 25. The method pursuant to Clause 24 also includes sending a Message Forwarding Control Protocol (PFCP) session establishment response by a second communication component.
[0148] Clause 26. A data communication method comprising: receiving header enhancement information associated with a message based on a communication security protocol from a first communication component by a second communication component; detecting one or more messages based on the communication security protocol from a user equipment by the second communication component; and inserting one or more header field names and values indicated by the header enhancement information into one or more messages by the second communication component.
[0149] Clause 27. The method pursuant to Clause 26, wherein the communication security protocol includes at least one of Secure Sockets Layer (SSL), Transport Layer Security (TLS), or Secure Hypertext Transfer Protocol (HTTPS).
[0150] Clause 28. The method according to any one of Clauses 26 to 27, wherein the header enhancement information includes a value set to the header type of a header enhancement information element corresponding to at least one of TLS, SSL / TLS, or HTTPS.
[0151] Clause 29. The method of any one of Clauses 26 to 27, wherein the header enhancement information includes the name and value of one or more header fields to be inserted into the message.
[0152] Clause 30. The method of any one of Clauses 26 to 27, wherein inserting one or more header field names and values indicated by the header enhancement information into one or more messages includes detecting that one or more uplink IP packets from the user equipment are SSL or TLS packets carrying Secure Sockets Layer (SSL) or Transport Layer Security (TLS) handshake messages; and inserting additional SSL or TLS extensions into the SSL or TLS handshake messages, while placing one or more header field names and values indicated by the header enhancement information in the inserted SSL or TLS extensions.
[0153] Clause 31. The method pursuant to Clause 30, wherein the SSL or TLS handshake message includes an SSL or TLS handshake message from the client that initiated the handshake procedure.
[0154] Clause 32. The method pursuant to Clause 30 further includes, when it is determined that the SSL or TLS handshake messages are exchanged in plaintext, the second communication component inserts additional information into the SSL or TLS handshake messages.
[0155] Clause 33. The method of Clause 32, wherein the additional information includes one or more header field names and values.
[0156] Clause 34. The method according to any one of Clauses 1 to 33, wherein the first communication component includes control plane (CP) functionality and the second communication component includes user plane (UP) functionality.
[0157] Clause 35. An apparatus for wireless communication, comprising a memory and a processor, wherein the processor reads code from the memory and implements the method according to any one of Clauses 1 to 34.
[0158] Clause 36. A computer-readable program storage medium having code stored thereon, which, when executed by a processor, causes the processor to perform the method according to any one of Clauses 1 to 34.
[0159] Although this patent document contains numerous details, these details should not be construed as limiting the scope of any invention or what may be claimed, but rather as descriptions of features characteristic of particular embodiments of a particular invention. Certain features described in this patent document in the context of separate embodiments may also be implemented in combination in a single embodiment. Conversely, various features described in the context of a single embodiment may also be implemented separately or in any suitable sub-combination in multiple embodiments. Moreover, although these features may be described above as functioning in certain combinations, and even initially claimed in this way, in some cases one or more features from a claimed combination may be excluded from that combination, and the claimed combination may be for sub-combinations or variations thereof.
[0160] Similarly, although the operations are depicted in a specific order in the accompanying drawings, this should not be construed as requiring these operations to be performed in the specific order shown or in a sequential order, or to perform all of the operations shown, in order to achieve the desired result. Furthermore, the separation of various system components in the embodiments described in this patent document should not be construed as requiring such separation in all embodiments.
[0161] Only a few implementation methods and examples have been described, and other implementations, enhancements and variations may be made based on what is described and shown in this patent document.
Claims
1. A data communication method, comprising: A first communication component sends a session message to a second communication component, the session message instructing the second communication component to perform an operation, including: detecting a handshake message from a user equipment based on a communication security protocol including at least one of Secure Sockets Layer (SSL), Transport Layer Security (TLS), or Secure Hypertext Transfer Protocol (HTTPS); identifying at least one header field name and its corresponding value based on the session message; inserting the at least one header field name and its corresponding value as an additional extension of the communication security protocol into the handshake message; and forwarding the modified handshake message including the additional extension to a server, wherein the session message includes detection information indicating the use of the communication security protocol and header enhancement information including the at least one header field name and its corresponding value; The detection information includes indications for message detection rules and service data flow filters for indicating at least one of Transport Layer Security (TLS) or Secure Hypertext Transfer Protocol (HTTPS), wherein the message detection rules include message detection information configured to filter out one or more outgoing SSL or TLS messages from the user equipment.
2. The method of claim 1, wherein the service data stream filter is associated with the packet detection rule.
3. The method of claim 1, wherein the detection information includes at least one of a known port for SSL or TLS protocol in the service data stream filter, or a pre-configured port for SSL or TLS protocol in the service data stream filter known to the first and second communication components.
4. The method of claim 1, wherein the detection information includes a value set to the header type of a header enhancement information element corresponding to at least one of TLS, SSL / TLS, or HTTPS.
5. The method of claim 4, wherein the header enhancement information element is included in the forwarding action rule (FAR).
6. The method according to any one of claims 1 to 5, further comprising: The triggering entity that receives the packet data network connection establishment request or packet data unit session establishment request from the first communication component; as well as The first communication component sends a packet data network connection establishment response or a packet data unit session establishment response.
7. The method according to any one of claims 1 to 5, wherein the first communication component includes a control plane (CP) function, and the second communication component includes a user plane (UP) function.
8. A data communication method, comprising: The second communication component receives a session message from the first communication component. The session message includes detection information indicating the use of a communication security protocol including at least one of Secure Sockets Layer (SSL), Transport Layer Security (TLS), or Secure Hypertext Transfer Protocol (HTTPS), and header enhancement information including at least one header field name and corresponding value. The second communication component detects handshake messages from the user equipment based on the communication security protocol; Identify the name and corresponding value of at least one header field from the session message; The second communication component inserts the name of at least one header field and its corresponding value as an additional extension of the communication security protocol into the handshake message; as well as The modified handshake message, including the additional extensions, is forwarded to the server; The detection information includes indications for message detection rules and service data flow filters for indicating at least one of Transport Layer Security (TLS) or Secure Hypertext Transfer Protocol (HTTPS), wherein the message detection rules include message detection information configured to filter out one or more outgoing SSL or TLS messages from the user equipment.
9. The method of claim 8, wherein detecting the handshake message from the user equipment based on the detection information includes determining, by checking an indication in the message detection rule or the service data stream filter, that the handshake message uses at least one of the transport layer security TLS or the secure hypertext transfer protocol HTTPS.
10. The method of claim 8, wherein the detection information includes at least one of a known port for SSL or TLS protocol in the service data stream filter, or a pre-configured port for SSL or TLS protocol in the service data stream filter known to the first and second communication components.
11. The method of claim 8, wherein detecting the handshake message from the user equipment based on the detection information comprises: Determine whether the destination port matches a known port used for the SSL or TLS protocol; as well as When the destination port is determined to match a known port used for the SSL or TLS protocol, it is determined that the current service data stream uses the SSL or TLS protocol.
12. The method of claim 8, wherein the detection information includes a value set to the header type of a header enhancement information element corresponding to at least one of TLS, SSL / TLS, or HTTPS.
13. The method of claim 12, wherein detecting the handshake message from the user equipment comprises determining that the current service data stream uses the SSL or TLS protocol when the header type of the header enhancement information element is set to a value corresponding to at least one of TLS, SSL / TLS, or HTTPS.
14. The method according to any one of claims 8 to 13, further comprising parsing the encapsulated SSL or TLS message of the handshake message.
15. The method of claim 8 further comprises, upon receiving a Message Forwarding Control Protocol (PFCP) session establishment request from the first communication component, the second communication component installs at least one of a Message Detection Rule (PDR), a QoS Enforcement Rule (QER), a Forwarding Action Rule (FAR), or a Usage Reporting Rule (URR).
16. The method of claim 15, further comprising sending a Message Forwarding Control Protocol (PFCP) session establishment response by the second communication component.
17. The method according to any one of claims 8 to 13 and 15 to 16, wherein the first communication component includes a control plane (CP) function, and the second communication component includes a user plane (UP) function.
18. An apparatus for wireless communication, comprising a memory and a processor, wherein the processor reads code from the memory and executes the method according to any one of claims 1 to 17.
19. A computer-readable program storage medium having code stored thereon, said code, when executed by a processor, causing the processor to perform the method according to any one of claims 1 to 17.