Method, device and computer program product for wireless communication
By negotiating checksum capabilities and actions between RAN and UPF entities using PFCP sessions, the method optimizes packet forwarding performance and addresses the challenges of managing checksums in wireless communication networks, enhancing efficiency and reducing latency.
Patent Information
- Application Number
- PCT/CN2024/074131
- Authority / Receiving Office
- WO · WO
- Patent Type
- Applications
- Current Assignee / Owner
- Filing Date
- 2024-01-25
- Publication Date
- 2025-07-31
AI Technical Summary
The deployment of checksums in networks is still a topic of discussion, and there is a lack of mechanisms to efficiently manage checksum capabilities and actions between GTP-U entities in wireless communication networks, leading to difficulties in deploying zero checksums, which can impact performance and latency.
A method is introduced to negotiate and manage checksum capabilities and actions between Radio Access Network (RAN) nodes and User Plane Function (UPF) entities using Packet Forwarding Control Protocol (PFCP) sessions, allowing for enabling or disabling checksums, such as IPv6 UDP checksums, based on network policies and service requirements, to optimize packet forwarding performance.
This approach enhances packet forwarding performance by enabling dynamic management of checksums, particularly for ultra-low latency services, reducing computational overhead and improving network efficiency.
Smart Images

Figure CN2024074131_31072025_PF_FP_ABST
Abstract
Description
METHOD, DEVICE AND COMPUTER PROGRAM PRODUCT FOR WIRELESS COMMUNICATIONTECHNICAL FIELD
[0001] This document is directed generally to wireless communications, and in particular to 5th generation (5G) communications or 6th generation (6G) communications.BACKGROUND
[0002] Checksum in communication technology is a safeguard mechanism to ensure data accuracy during transmission. It involves calculating a unique value (checksum) based on the data content and appending it to the transmitted data. Upon reception, the recipient recalculates the checksum and compares it to the transmitted value. If they match, the data is considered intact; otherwise, errors may have occurred, requiring actions like data retransmission. Checksums are commonly used in networks and file transfers to enhance data reliability and prevent corruption. However, the deployments of checksum are still a topic of discussion.SUMMARY
[0003] This document relates to methods, systems, and computer program products for a wireless communication.
[0004] One aspect of the present disclosure relates to a wireless communication method. In an embodiment, the wireless communication method includes: transmitting, by a session management node to a first wireless communication node, a checksum action instruction based on at least one of: a checksum capability of the first wireless communication node, a first checksum action response from the first wireless communication node, a checksum capability of a second wireless communication node, or a second checksum action response from the second wireless communication node, to allow the first wireless communication node to perform one or more checksum actions with the second wireless communication node.
[0005] Various embodiments may preferably implement the following features:
[0006] Preferably, the checksum capability of the first wireless communication node or the checksum capability of the second wireless communication node comprises at least one of:
[0007] an Internet Protocol, IP, checksum capability,
[0008] an Internet Protocol version 4, IPv4, checksum capability,
[0009] a Transmission Control Protocol, TCP, checksum capability,
[0010] a User Datagram Protocol, UDP, checksum capability,
[0011] an IPv4 UDP checksum capability, or
[0012] an Internet Protocol version 6, IPv6, UDP checksum capability.
[0013] Preferably, the checksum capability of the first wireless communication node or the checksum capability of the second wireless communication node comprises a zero checksum capability.
[0014] Preferably, the checksum action instruction comprises at least one of:
[0015] enabling or disabling an IP checksum;
[0016] enabling or disabling an IPv4 checksum;
[0017] enabling or disabling a TCP checksum;
[0018] enabling or disabling a UDP checksum;
[0019] enabling or disabling an IPv4 UDP checksum; or
[0020] enabling or disabling an IPv6 UDP checksum.
[0021] Preferably, the checksum action instruction comprises at least one of:
[0022] enabling or disabling an IP zero checksum;
[0023] enabling or disabling an IPv4 zero checksum;
[0024] enabling or disabling a TCP zero checksum;
[0025] enabling or disabling a UDP zero checksum;
[0026] enabling or disabling an IPv4 UDP zero checksum; or
[0027] enabling or disabling an IPv6 UDP zero checksum.
[0028] Preferably, the wireless communication method further comprises: receiving, by the session management node from the first wireless communication node, the checksum capability of the first wireless communication node.
[0029] Preferably, the checksum capability of the first wireless communication node is received via a Packet Forwarding Control Protocol, PFCP, Association Setup Request or a PFCP Association Setup Response.
[0030] Preferably, the first checksum action response or the second checksum action response comprises information of at least one of:
[0031] a checksum capability of a sending wireless communication node;
[0032] one or more accepted checksum actions; or
[0033] one or more rejected checksum actions. In particular, the first checksum action response or the second checksum action response may comprise information of the checksum capability of the second wireless communication node;
[0034] Preferably, the first checksum action response is received in response to the session management node transmitting a first checksum action instruction to the first wireless communication node.
[0035] Preferably, the first checksum action instruction is transmitted based on the checksum capability of the first wireless communication node.
[0036] Preferably, at least one of the following applies:
[0037] the first checksum action instruction is transmitted via a PFCP session establishment request; or
[0038] the first checksum action response is received via a PFCP session establishment response.
[0039] Preferably, second checksum action response is received in response to the session management node transmitting a second checksum action instruction to the second wireless communication node.
[0040] Preferably, the second checksum action instruction is transmitted based on at least one of: the checksum capability of the first wireless communication node or the first checksum action response.
[0041] Preferably, the wireless communication method further comprises: receiving, by the session management node from the first wireless communication node, a checksum action response in response to the checksum action instruction, the checksum action response comprising information of at least one of:
[0042] one or more accepted checksum actions; or
[0043] one or more rejected checksum actions.
[0044] Preferably, at least one of the following applies:
[0045] the second checksum action instruction is transmitted via an N2 Packet Data Unit, PDU, session request;
[0046] the second checksum action response is received via an N2 PDU session request Acknowledgment, ACK;
[0047] the checksum action instruction is received via a PFCP session modification request; or
[0048] the checksum action response in response to the checksum action instruction is transmitted via a PFCP session modification response.
[0049] Preferably, the one or more checksum actions enables or disables one or more checksums or zero checksums for a corresponding session or a Quality of Service, QoS, flow.
[0050] Another aspect of the present disclosure relates to a wireless communication method. In an embodiment, the wireless communication method includes: receiving, by a first wireless communication node from a session management node, a checksum action instruction based on at least one of: a checksum capability of the first wireless communication node, a first checksum action response from the first wireless communication node, a checksum capability of a second wireless communication node, or a second checksum action response from the second wireless communication node, to perform one or more checksum actions with the second wireless communication node based on the checksum action instruction.
[0051] Various embodiments may preferably implement the following features:
[0052] Preferably, the checksum capability of the first wireless communication node or the checksum capability of the second wireless communication node comprises at least one of:
[0053] an Internet Protocol, IP, checksum capability,
[0054] an Internet Protocol version 4, IPv4, checksum capability,
[0055] a Transmission Control Protocol, TCP, checksum capability,
[0056] a User Datagram Protocol, UDP, checksum capability,
[0057] an IPv4 UDP checksum capability, or
[0058] an Internet Protocol version 6, IPv6, UDP checksum capability.
[0059] Preferably, the checksum capability of the first wireless communication node or the checksum capability of the second wireless communication node comprises a zero checksum capability.
[0060] Preferably, the checksum action instruction comprises at least one of:
[0061] enabling or disabling an IP checksum;
[0062] enabling or disabling an IPv4 checksum;
[0063] enabling or disabling a TCP checksum;
[0064] enabling or disabling a UDP checksum;
[0065] enabling or disabling an IPv4 UDP checksum; or
[0066] enabling or disabling an IPv6 UDP checksum.
[0067] Preferably, the checksum action instruction comprises at least one of:
[0068] enabling or disabling an IP zero checksum;
[0069] enabling or disabling an IPv4 zero checksum;
[0070] enabling or disabling a TCP zero checksum;
[0071] enabling or disabling a UDP zero checksum;
[0072] enabling or disabling an IPv4 UDP zero checksum; or
[0073] enabling or disabling an IPv6 UDP zero checksum.
[0074] Preferably, the wireless communication method further comprises: transmitting, by the first wireless communication node to the session management node, the checksum capability of the first wireless communication node.
[0075] Preferably, the checksum capability of the first wireless communication node is transmitted via a Packet Forwarding Control Protocol, PFCP, Association Setup Request or a PFCP Association Setup Response.
[0076] Preferably, the first checksum action response or the second checksum action response comprises information of at least one of:
[0077] a checksum capability of a sending wireless communication node;
[0078] one or more accepted checksum actions; or
[0079] one or more rejected checksum actions. In particular, the first checksum action response or the second checksum action response may comprise information of the checksum capability of the second wireless communication node;
[0080] Preferably, the first checksum action response is transmitted in response to the session management node transmitting a first checksum action instruction to the first wireless communication node.
[0081] Preferably, the first checksum action instruction is received based on the checksum capability of the first wireless communication node.
[0082] Preferably, the wireless communication method further comprises: transmitting, by the first wireless communication node to the session management node, a checksum action response in response to the checksum action instruction, the checksum action response comprising information of at least one of:
[0083] one or more accepted checksum actions; or
[0084] one or more rejected checksum actions.
[0085] Preferably, at least one of the following applies:
[0086] the first checksum action instruction is received via a PFCP session establishment request;
[0087] the first checksum action response is transmitted via a PFCP session establishment response;
[0088] the checksum action instruction is via a PFCP session modification request; or
[0089] the checksum action response in response to the checksum action instruction is transmitted via a PFCP session modification response.
[0090] Preferably, the one or more checksum actions enables or disables one or more checksums or zero checksums for a corresponding session or a Quality of Service, QoS, flow.
[0091] Another aspect of the present disclosure relates to a session management node. In an embodiment, the session management node includes a communication unit and a processor. The processor is configured to: transmit, via the communication unit to a first wireless communication node, a checksum action instruction based on at least one of: a checksum capability of the first wireless communication node, a first checksum action response from the first wireless communication node, a checksum capability of a second wireless communication node, or a second checksum action response from the second wireless communication node, to allow the first wireless communication node to perform one or more checksum actions with the second wireless communication node.
[0092] Another aspect of the present disclosure relates to a first wireless communication node. In an embodiment, the first wireless communication node includes a communication unit and a processor. The processor is configured to: receive, via the communication unit from a session management node, a checksum action instruction based on at least one of: a checksum capability of the first wireless communication node, a first checksum action response from the first wireless communication node, a checksum capability of a second wireless communication node, or a second checksum action response from a the second wireless communication node, to perform one or more checksum actions with the second wireless communication node based on the checksum action instruction.
[0093] The present disclosure relates to a computer program product comprising a computer-readable program medium code stored thereupon, the code, when executed by a processor, causing the processor to implement a wireless communication method recited in any one of foregoing methods.
[0094] The exemplary embodiments disclosed herein are directed to providing features that will become readily apparent by reference to the following description when taken in conjunction with the accompanying drawings. In accordance with various embodiments, exemplary systems, methods, devices and computer program products are disclosed herein. It is understood, however, that these embodiments are presented by way of example and not limitation, and it will be apparent to those of ordinary skill in the art who read the present disclosure that various modifications to the disclosed embodiments can be made while remaining within the scope of the present disclosure.
[0095] Thus, the present disclosure is not limited to the exemplary embodiments and applications described and illustrated herein. Additionally, the specific order and / or hierarchy of steps or operations in the methods disclosed herein are merely exemplary approaches. Based upon design preferences, the specific order or hierarchy of steps or operations of the disclosed methods or processes can be re-arranged while remaining within the scope of the present disclosure. Thus, those of ordinary skill in the art will understand that the methods and techniques disclosed herein present various steps or operations in a sample order, and the present disclosure is not limited to the specific order or hierarchy presented unless expressly stated otherwise.
[0096] The above and other aspects and their implementations are described in greater detail in the drawings, the descriptions, and the claims.BRIEF DESCRIPTION OF THE DRAWINGS
[0097] FIG. 1 shows a schematic diagram of a network according to an embodiment of the present disclosure.
[0098] FIGS. 2A and 2B show a schematic diagram of a procedure according to an embodiment of the present disclosure.
[0099] FIG. 3 shows a schematic diagram of a procedure according to an embodiment of the present disclosure.
[0100] FIG. 4 shows a schematic diagram of a procedure according to an embodiment of the present disclosure.
[0101] FIG. 5 shows an example of a schematic diagram of a wireless communication terminal according to an embodiment of the present disclosure.
[0102] FIG. 6 shows an example of a schematic diagram of a wireless communication node according to an embodiment of the present disclosure.
[0103] FIGS. 7 and 8 show flowcharts of wireless communication methods according to some embodiments of the present disclosure.DETAILED DESCRIPTION
[0104] In the paragraphs below, some aspects of the present disclosure are provided, but the present disclosure is not limited thereto. Besides, different aspects described below can be combined unless expressly stated otherwise.
[0105] In an Internet Protocol (IP) based communication, the checksum mechanism is a basic mechanism to ensure the datagram (data packet) integrity when transmitting datagrams. In some embodiments, the checksum applies to the IP datagram, the Transmission Control Protocol (TCP) datagram and the User Datagram Protocol (UDP) datagram.
[0106] In some embodiments, the IP checksum covers the IP header only but does not cover any data in the IP datagram, while the TCP checksum (or the UDP checksum) covers the TCP header (or the UDP header) and the TCP data (or the UDP data) . In some embodiments, with the UDP, the checksum is optional, while with the TCP, it is mandatory.
[0107] The checksum calculating requires additional computing resource in terms of forwarding packets. The UDP checksum is a typical example that causes significant computing resource consumption. Other checksums (e.g., IP checksum, TCP checksum) also have similar contribution to the computing resource consumption.
[0108] In some embodiments, to eliminate the performance decreasing due to the checksum calculating, using zero checksum for the IPv6 UDP (i.e., set the UPD checksum to zero) is allowed when using the IPv6 UDP for encapsulating a packet. However, the UDP zero checksum may not be applied by the sending GPRS Tunnelling Protocol -User Plane (GTP-U) entity (e.g., User Plane Function (UPF) , or Radio Access Network (RAN) node (also referred to as RAN in the present disclosure) ) unless it is ensured that the peer GTP-U entity (e.g., RAN node, or UPF) and the path in-between supports UDP zero checksum.
[0109] In some cases, except homogenous configuration to every GTP-U entity (e.g., the RAN node and the UPF) in the entire network, there is no mechanism to make one GTP-U entity know the peer GTP-U entity capability of supporting the UDP zero checksum, which results in difficulties in deployment of UPD zero checksum. Some embodiments of the present disclosure provide methods to solve the checksum issue on GTP-U protocol and other similar user plane protocol.
[0110] In the paragraphs below, some aspects of the present disclosure are provided, but the present disclosure is not limited thereto. Besides, different aspects described below can be combined unless expressly stated otherwise. In particular, aspects in any of the “Aspects” (e.g., Aspect 0) described below can be combined with aspects of any other “Aspect” (e.g., Aspect 1) described below and vice versa.
[0111] Aspect 0:
[0112] FIG. 1 shows the 5G architecture according to an embodiment of the present disclosure. In FIG. 1, there are the following network functions:
[0113] 1) User Equipment (UE) .
[0114] 2) RAN (Radio Access Network) . In 5G, it is a New Radio (NR) base station.
[0115] 3) AMF (Access and Mobility Management function) . This function includes the following functionalities: Registration management, Connection management, Reachability management and / or Mobility Management. This function also performs the access authentication and access authorization. The AMF is the Non-Access-Stratum (NAS) security termination and handles the Session Management (SM) NAS between the UE and the Session Management Function (SMF) , etc.
[0116] 4) SMF (Session Management Function) . This function includes the following functionalities: session establishment, modification and release, UE IP address allocation and management (including optional authorization functions) , selection and control of uplink (UP) function, downlink data notification, etc. The SMF controls the UPF via the N4 association.
[0117] 5) UPF (User Plane Function) . This function includes the following functionalities: serving as an anchor point for intra- / inter-radio access technology (RAT) mobility, packet routing and / or forwarding, traffic usage reporting, Quality of service (QoS) handling for the user plane, downlink packet buffering and / or downlink data notification triggering, etc. The UPF may be deployed as the I-UPF (Intermediate UPF) or the Packet Data Unit (PDU) Session Anchor (PSA) . The PSA / UPF is the UPF terminating the N6 interface towards the data network. The I-UPF provides the traffic forwarding between the RAN and PSA / UPF. The I-UPF may support the "ULCL" (Uplink classifier: offloading uplink traffic based on target IP address) and / or the “BP” (Branching point: offloading the uplink traffic based on source IP address) to offload some traffic to the local PSA / UPF.
[0118] 6) UDM (Unified Data Management Function) . The UDM provides various kinds of subscription data of a UE (e.g., to the AMF for access and mobility management, or to the SMF for PDU session management, etc. ) . The UDM also handles the AMF registration from the AMF to record the serving AMF of a UE, or handles the SMF registration from the SMF to record the PDU session information, etc.
[0119] 7) PCF (Policy Control Function) . The PCF provides QoS policy rules to control plane functions to enforce the rules. The PCF (s) transform (s) the Application Function (AF) requests into policies that apply to PDU Sessions. The PCF provides the AF influenced Traffic Steering Enforcement Control in Policy and Charging Control (PCC) rules to the SMF. Therefore, the SMF can establish the data path to offload the traffic to the local data network.
[0120] On the N3 interface between the RAN and the UPF, the GTP-U is used for packet forwarding. The GTP-U path between the RAN node and the UPF makes the two entities become GTP-U peers (i.e., entities implementing at least one side of the GTP-U protocol) . To ensure the GTP-U path wellness and detect the GTP-U path failure, each GTP-U entity shall periodically send GTP-U Echo message to its peer GTP-U entity.
[0121] Once a PDU session is established upon UE’s request, an end-to-end GTP tunnel is established for that PDU session, on that the GTP-U path between the RAN node and UPF.
[0122] FIGS. 2A and 2B illustrate the PDU Session Establishment procedure according to an embodiment of the present disclosure. In some embodiments, the PDU Session Establishment procedure results in the GTP-U tunnel being established for that PDU session.
[0123] After the UE registers to 5G network, the UE requests the PDU session establishment procedure. In some embodiments, the procedure may include at least one of the following operations.
[0124] 1. UE to AMF: NAS Message (e.g., including at least one of Single Network Slice Selection Assistance Information (s) (S-NSSAI (s) ) , UE Requested Data Network Name (DNN) , PDU Session ID, Request type and / or N1 SM container (PDU Session Establishment Request) ) .
[0125] The PDU Session Establishment Request is included in the NAS message and encapsulated in the N1 SM container. The NAS message sent by the UE is encapsulated by the RAN in a N2 message towards the AMF.
[0126] 2. The AMF selects a proper SMF (i.e., the anchor SMF) to serve the PDU session, based on the requested DNN, S-NSSAI, and the current UE location information.
[0127] 3. AMF to SMF: the Nsmf_PDUSession_CreateSMContext Request (e.g., including at least one of Subscription Permanent Identifier (SUPI) , selected DNN, UE requested DNN, S-NSSAI (s) , PDU Session ID, AMF ID, Request Type, N1 SM container (PDU Session Establishment Request) , User location information, Access Type, RAT Type, Permanent Equipment Identifier (PEI) and / or Generic Public Subscription Identifier (GPSI) ) .
[0128] The SUPI uniquely identifies the UE subscription. The AMF ID carries the Globally Unique AMF ID (GUAMI) uniquely identifying the AMF serving the UE.
[0129] 4. SMF to AMF: the Nsmf_PDUSession_CreateSMContext Response (Cause and / or SM Context ID) . The SM Context ID identifies the SM context created in the SMF for the UE.
[0130] 5. If the dynamic PCC is to be used for the PDU Session, the SMF selects a proper PCF to serve the PDU session.
[0131] 6. The SMF sends the Npcf_PolicyAssociation_Create Request to the PCF, to perform an SM Policy Association Establishment procedure to get the default PCC Rules for the PDU Session. Necessary parameters such as SUPI, PDU Session ID, DNN and / or S-NSSAI shall be provided in the request. Other parameters such as GPSI, UE IP address, UE External ID, RAT Type and / or Access Type, may also be provided in the request message.
[0132] 7. The PCF may interact with the AF to establish AF association. The AF association establishment allows the AF to dynamically influence the traffic model of the PDU session via the PCF (e.g., to setup new dedicated QoS flow, or modify the existing QoS flow) .
[0133] 8. The PCF sends the Npcf_PolicyAssociation_Create Response to the SMF to return the default PCC Rules for the PDU Session.
[0134] 9. The SMF selects an UPF acting as PDU Session Anchor (PSA) .
[0135] 10. The SMF sends a Packet Forwarding Control Protocol (PFCP) Session Establishment Request (which is also called N4 Session Establishment Request in 5G) to the UPF to request establish N4 session for this PDU Session, carrying a set of rules for packet detection and QoS enhancement to be installed in the UPF. The rules include Packet Detection Rule (PDR) , Forward Action Rule (FAR) , QoS Enhancement Rule (QER) and / or Usage Reporting Rule (URR) , etc.
[0136] If the SMF receives PCC rules from the PCF, the SMF maps the PCC rules to a set of QoS flows and generates a set of PDR, FAR, QER and / or URR rules accordingly to reflect the determined QoS flows.
[0137] The UPF installs these rules for this PDU session and uses these rules to filter the uplink and / or downlink traffic. The UPF performs the corresponding QoS enhancement to the filtered uplink and / or downlink traffic.
[0138] 11. The UPF acknowledges by sending a PFCP Session Establishment Response (which is also called N4 Session Establishment Response in 5G) .
[0139] 12. SMF to AMF: the Namf_Communication_N1N2MessageTransfer Request (e.g., including at least one of PDU Session ID, N2 SM information (PDU Session ID, QoS Flow Identifier (s) (e.g., including at least one of QFI (s) ) , QoS Profile (s) and / or N3 Core Network (CN) Tunnel Info) and / or N1 SM container (PDU Session Establishment Accept) ) .
[0140] The N2 SM information carries information that the AMF shall forward to the RAN, including the N3 CN Tunnel Info carrying UPF UL Fully Qualified Tunnel Endpoint Identifier (F-TEID) , the QFIs and / or QoS profiles used by the RAN to setup QoS flows.
[0141] One or multiple QoS profiles and the corresponding QFIs are be provided to the RAN, to allow the RAN to control the QoS flow and perform traffic detection and admission control at QoS flow level.
[0142] A typical QoS profile has the following parameters:
[0143] - QFI, used to uniquely identify one QoS flow in a PDU session;
[0144] - ARP, indicates the Allocation and Retention Priority of the QoS flow; and / or
[0145] - Guaranteed Bit Rate (GBR) QoS flow parameters, used by the RAN to control the QoS flow, such as Maximum Flow Bit Rate Downlink, Maximum Flow Bit Rate Uplink, Guaranteed Flow Bit Rate Downlink, Guaranteed Flow Bit Rate Uplink, Maximum Packet Loss Rate Downlink and / or Maximum Packet Loss Rate Uplink, etc.
[0146] The N1 SM container contains the PDU Session Establishment Accept that the AMF shall provide to the UE. Within the PDU Session Establishment Accept, following parameters are included: PDU session ID, PDU session type, UE IP address, one or multiple QoS rules, QoS Flow level QoS parameters associated to those QoS rule (s) , DNN and / or S-NSSAI, etc.
[0147] 13. AMF to RAN: the N2 PDU Session Request (N2 SM information, NAS message (PDU Session ID, N1 SM container (PDU Session Establishment Accept) ) ) . The AMF sends the NAS message containing PDU Session ID and PDU Session Establishment Accept targeted to the UE and the N2 SM information received from the SMF within the N2 PDU Session Request to the RAN.
[0148] 14. RAN to UE: the RAN may issue Access Network (AN) specific signaling exchange with the UE that is related with the information received from the SMF. For example, a Radio Resource Control (RRC) Connection Reconfiguration may take place with the UE establishing the necessary RAN resources related to the QoS Rules for the PDU Session request. The RAN forwards the NAS message (PDU Session ID, N1 SM container (PDU Session Establishment Accept) ) to the UE. The RAN also allocates AN N3 tunnel information for the PDU Session.
[0149] 15. RAN to AMF: the N2 PDU Session Response (PDU Session ID, Cause, N2 SM information (e.g., including at least one of PDU Session ID, AN Tunnel Info and / or List of accepted / rejected QFI (s) ) ) .
[0150] The AN Tunnel Info corresponds to the Access Network address of the N3 tunnel corresponding to the PDU Session.
[0151] 16. AMF to SMF: the Nsmf_PDUSession_UpdateSMContext Request (N2 SM information) .
[0152] The AMF forwards the N2 SM information received from the RAN to the SMF. If the list of rejected QFI (s) is included in N2 SM information, the SMF shall release the rejected QFI (s) associated QoS profiles.
[0153] 17. The SMF initiates an N4 Session Modification procedure with the UPF. The SMF provides RAN Tunnel Info to the UPF as well as the corresponding forwarding rules.
[0154] 18. The SMF sends the Nsmf_PDUSession_UpdateSMContext Response to the AMF.
[0155] 19. The UE initiates the uplink traffic transmission (e.g., towards its Application Server, or receives downlink traffic (e.g., from its Application Server) ) .
[0156] Some embodiments of the present disclosure below further provide mechanisms to negotiate the capability of supporting UDP zero checksum between the RAN node and the UPF (i.e., the two GTP-U entities on N3 interface) , and / or to enable or disable the UDP zero checksum on demand.
[0157] In some embodiments, a method to enable or disable a certain checksum (e.g., the IPv6 UDP checksum) is to configure all GTP-U entities in the entire network with homogenous support of the indicated checksum mechanism. In such a case, configurations for the entire network may be needed.
[0158] In some embodiments, another method to enable or disable a certain checksum is to allow the network node (e.g., the SMF) to fetch the checksum capability from the UPF and negotiate the checksum action with the RAN node in QoS flow assignment during the PDU session establishment procedure, or in the PDU session modification procedure.
[0159] Aspect 1:
[0160] FIG. 3 shows the PFCP association setup procedure wherein the SMF gets the UPF checksum capability from the UPF according to an embodiment of the present disclosure. In some embodiments, the UPF can report its checksum capability during the PFCP association setup procedure to the SMF. In some embodiments, the procedure may include at least one of the following operations.
[0161] In some embodiments, the PFCP association setup may be initiated by the SMF, as operations A1 and A2 described below.
[0162] A1. The SMF sends a message (e.g., the PFCP Association Setup Request) to the UPF, to setup the association with the UPF.
[0163] A2. The UPF transmits the “Checksum Capability” to the SMF to indicate the checksum capability of the UPF. In some embodiments, The UPF transmits the “Checksum Capability” to the SMF via a response (e.g., the PFCP Association Setup Response) responding the message in the operation A1.
[0164] In some embodiments, the checksum mechanism can be performed at different levels (e.g., the IP checksum (the IPv4 has the checksum while IPv6 does not) , the TCP checksum and / or the UDP checksum) . In some embodiments, the “Checksum Capability” in the operation A2, may include at least one of the following: (a) the IP checksum capability which may further comprise the IPv4 checksum capability, (b) the TCP checksum capability and / or (c) the UDP checksum capability. In some embodiments, the UDP checksum capability may further comprise the IPv4 UDP checksum capability and the IPv6 UDP checksum capability.
[0165] In some embodiments, the checksum capabilities described above may further indicate whether zero checksum is supported. For example, the “IP checksum capability” further indicates whether “IP zero checksum” is supported; the “IPv4 checksum capability” further indicates whether “IPv4 zero checksum” is supported; the “TCP checksum capability” further indicates whether “TCP zero checksum” is supported; the “UDP checksum capability” further indicates whether “UDP zero checksum” is supported; the “IPv4 UDP checksum capability” further indicates whether “IPv4 UDP zero checksum” is supported; and / or the “IPv6 UDP checksum capability” further indicates whether “IPv6 UDP zero checksum” is supported.
[0166] Or, in some embodiments, the PFCP association setup is initiated by the UPF, as operations B1 and B2 described below.
[0167] B1. The UPF sends a message (e.g., the PFCP Association Setup Request) to the SMF, to setup the association with the UPF. Within the request, it carries the “Checksum Capability” to indicate its own checksum capability.
[0168] In some embodiments, the “Checksum Capability” in operation B1 is substantially the same as the “Checksum Capability” described in the operation A2.
[0169] B2. The UPF responds with a response (e.g., the PFCP Association Setup Response) to the SMF.
[0170] Aspect 2:
[0171] In some embodiments, the SMF may determine to enable or disable the certain checksum based on the operator policy and / or the service requirement.
[0172] In some embodiments, enabling or disabling certain checksum may be applied to the entire PDU session. In some embodiments, for example, for ultra-low latency services which can be identified from the DNN or S-NSSAI, the SMF may determine to enable or disable the certain checksum. A typical example is that disabling the IPv6 UDP checksum (e.g., if it is used by the GTP-U protocol) may increase the packet forwarding performance significantly, which may contribute to the ultra-low latency service.
[0173] In other embodiment, enabling or disabling certain checksum may be applied to one or more specific QoS flows. For example, not the entire PDU session requires ultra-low latency, but the certain QoS flow (s) has such restricted low latency requirement. In this case, the certain checksum may be applied only to the impacted QoS flow (s) .
[0174] FIG. 4 illustrates the enhanced PDU session establishment procedure according to an embodiment of the present disclosure. In some embodiments, the SMF negotiates the checksum action with the UPF and the RAN node in the enhanced PDU session establishment procedure. In some embodiments, the procedure may include at least one of the following operations.
[0175] 1. The SMF receives a request from the AMF to create the SM context for a PDU session establishment. In some embodiments, this request may be substantially identical to the request in the operation 3 in Aspect 0 described above.
[0176] In some embodiments, in this operation, the SMF may determine to enable or disable the certain checksum based on the operator policy and / or the service requirement.
[0177] 2.The SMF makes the initial checksum action determination. In some embodiments, the SMF determines the initial checksum action (s) (also referred to as first checksum action (s) in the present disclosure) based on the checksum capability of the UPF. In some embodiments, the SMF may acquire the checksum capability of the UPF in a previous PFCP association setup procedure. In some embodiments, the SMF may acquire the checksum capability of the UPF by using the operation A2 or B1 in Aspect 1.
[0178] 3. The SMF sends a request (e.g., the PFCP Session Establishment Request) to the UPF to request establishing a PFCP session (e.g., the N4 session in term of 5G) for a corresponding PDU Session. In some embodiments, this request may be substantially identical to the request in operation 10 in Aspect 0 described above.
[0179] In some embodiments, in this operation, the SMF sends the “Checksum Action Instruction” (also referred to as first checksum action instruction in the present disclosure) to the UPF. In some embodiments, the SMF sends the “Checksum Action Instruction” via the request (e.g., the PFCP Session Establishment Request) . In some embodiments, the Checksum Action Instruction indicates which checksum needs to be enabled or disabled. In some embodiments, this initial Checksum Action Instruction is determined based on the UPF checksum capability that the SMF previously received. In some embodiments, this Checksum Action Instruction includes the initial checksum action (s) determined in the operation 2.
[0180] In some embodiments, the Checksum Action Instruction may comprise at least one of the following: (a) the IP checksum set to the value “enable” or “disable” , (b) the IPv4 checksum set to the value “enable” or “disable” , (c) the TCP checksum set to the value “enable” or “disable” , (d) the UDP checksum set to the value “enable” or “disable” , (e) the IPv4 UDP checksum set to the value “enable” or “disable” and / or (f) the IPv6 UDP checksum set to the value “enable” or “disable” .
[0181] In some embodiments, the Checksum Action Instruction may include at least one of:
[0182] enabling or disabling an IP checksum;
[0183] enabling or disabling an IPv4 checksum;
[0184] enabling or disabling a TCP checksum;
[0185] enabling or disabling a UDP checksum;
[0186] enabling or disabling an IPv4 UDP checksum; and / or
[0187] enabling or disabling an IPv6 UDP checksum.
[0188] In some embodiments, the Checksum Action Instruction may comprise at least one of the following: (a) the IP zero checksum set to the value “enable” or “disable” , (b) the IPv4 zero checksum set to the value “enable” or “disable” , (c) the TCP zero checksum set to the value “enable” or “disable” , (d) the UDP zero checksum set to the value “enable” or “disable” , (e) the IPv4 UDP zero checksum set to the value “enable” or “disable” and / or (f) the IPv6 UDP zero checksum set to the value “enable” or “disable” .
[0189] In some embodiments, the Checksum Action Instruction may include at least one of:
[0190] enabling or disabling an IP zero checksum;
[0191] enabling or disabling an IPv4 zero checksum;
[0192] enabling or disabling a TCP zero checksum;
[0193] enabling or disabling a UDP zero checksum;
[0194] enabling or disabling an IPv4 UDP zero checksum; and / or
[0195] enabling or disabling an IPv6 UDP zero checksum.
[0196] In some embodiments, one certain checksum action within the Checksum Action Instruction may be associated with the entire PFCP session, or merely associated with one or more dedicated QoS flows within the PFCP session. If one certain checksum action is associated with one or more QFIs (QoS flow identifiers) , the checksum action may be applied only to the indicated one or more QoS flows. If one checksum action is not associated with any QFI, the checksum action may be applied to the entire PFCP session (i.e., applied to the entire PDU session) .
[0197] 4. The UPF sends a response message (e.g., the PFCP Session Establishment Response) to the SMF. In some embodiments, this response message may be substantially identical to the response message in the operation 11 in Aspect 0 described above.
[0198] In some embodiments, the UPF may transmit a checksum action response (also referred to as first checksum action response in the present disclosure) including the “Accepted Checksum Action” and / or the “Rejected Checksum Action” to the SMF via the response message (e.g., the PFCP Session Establishment Response) . In some embodiments, the response message (e.g., the PFCP Session Establishment Response) may carry the “Accepted Checksum Action” if at least one indicated checksum action in the Checksum Action Instruction is accepted by the UPF. In some embodiments, the response message (e.g., the PFCP Session Establishment Response) may carry the “Rejected Checksum Action” if at least one indicated checksum action in the Checksum Action Instruction is rejected by the UPF.
[0199] In some embodiments, the “Accepted Checksum Action” may carry at least one checksum action indicated in the Checksum Action Instruction that is accepted by the UPF.
[0200] In some embodiments, the “Rejected Checksum Action” may carry at least one checksum action indicated in the “Required Checksum Action” that is rejected by the UPF.
[0201] 5. The SMF determines the updated checksum action (s) based on the response from the UPF in the operation 4. In some embodiments, the SMF determines the updated checksum action (s) (also referred to as second checksum action (s) in the present disclosure) based on the “Accepted Checksum Action” and / or the “Rejected Checksum Action” received from the UPF.
[0202] 6. The SMF sends a request message (e.g., the N2 PDU Session Request) for establishing a PDU session to the RAN node via the AMF. In some embodiments, this request message may be substantially identical to the request message in the operations 12 and 13 in Aspect 0 described above.
[0203] In some embodiments, in this operation, the SMF provides the updated “Checksum Action Instruction” (also referred to as second checksum action instruction in the present disclosure) to the RAN node. In some embodiments, the SMF transmits the updated “Checksum Action Instruction” via the request message (e.g., the N2 PDU Session Request) . In some embodiments, the updated “Checksum Action Instruction” includes the updated checksum action (s) updated in the operation 5. In some embodiments, the updated “Checksum Action Instruction” includes at least a part of checksum action (s) in the initial “Checksum Action Instruction” described in the operation 3.
[0204] In some embodiments, a certain checksum action within the updated Checksum Action Instruction may be associated with the entire PDU session, or merely associated with one or more dedicated QoS flows in the PDU session. In some embodiments, if one certain checksum action is associated with one or more QFIs (QoS flow identifiers) , the checksum action may be applied only to the indicated one or more QoS flows. In some embodiments, if one checksum action is not associated with any QFI, it means the checksum action may be applied to the entire PDU session.
[0205] 7. The RAN node sends a response message (e.g., the N2 PDU Session Request Ack) to the SMF. In some embodiments, this response message may be substantially identical to the response message in the operation 11 in Aspect 0 described above.
[0206] In some embodiments, the RAN node may transmit a checksum action response (also referred to as second checksum action response in the present disclosure) including the “Accepted Checksum Action” and / or the “Rejected Checksum Action” to the SMF via the response message (e.g., the N2 PDU Session Request Ack) . In some embodiments, the response message (e.g., the N2 PDU Session Request Ack) may carry the “Accepted Checksum Action” if at least one indicated checksum action in the updated Checksum Action Instruction is accepted by the RAN node. In some embodiments, the response message (e.g., the PFCP Session Establishment Response) may carry the “Rejected Checksum Action” if at least one indicated checksum action in the updated Checksum Action Instruction is rejected by the RAN node.
[0207] In some embodiments, the “Accepted Checksum Action” may carry at least one checksum action indicated in the Checksum Action Instruction that is accepted by the RAN node.
[0208] In some embodiments, the “Rejected Checksum Action” may carry at least one checksum action indicated in the “Required Checksum Action” that is rejected by the RAN node.
[0209] In some embodiments, the RAN additionally includes its checksum capability in the response message (e.g., the N2 PDU Session Request Ack) to the SMF. In some embodiments, the RAN checksum capability may be identical as the UPF checksum capability in Aspect 1.
[0210] 8. The SMF further determines the updated checksum action (s) , based on the response from the RAN node in the operation 7. In some embodiments, the SMF determines the updated checksum action (s) based on the “Accepted Checksum Action” and / or the “Rejected Checksum Action” received from the RAN node.
[0211] 9. The SMF sends a request message (e.g., the PFCP Session Modification Request) to the UPF to update the PFCP session based on the response from the RAN node. In some embodiments, this request message may be substantially identical to the request message in the operation 17 in Aspect 0 described above.
[0212] In some embodiments, in this operation, the SMF sends the updated “Checksum Action Instruction" to the UPF. In some embodiments, the SMF sends the updated “Checksum Action Instruction” via the request (e.g., the PFCP Session Modification Request) .
[0213] In some embodiments, this updated Checksum Action Instruction is determined based on at least one of: the checksum capability of the UPF, the first checksum action response received from the UPF, and / or the second checksum action response received from the RAN node. In some embodiments, this updated “Checksum Action Instruction” includes the updated checksum action (s) updated in the operation 8. In some embodiments, the updated “Checksum Action Instruction” includes at least a part of checksum action (s) in the updated “Checksum Action Instruction” described in the operation 5.
[0214] In some embodiments, a certain checksum action within the updated Checksum Action Instruction may be associated with the entire PDU session, or merely associated with one or more dedicated QoS flows in the PDU session. In some embodiments, if one certain checksum action is associated with one or more QFIs (QoS flow identifiers) , the checksum action may be applied only to the indicated one or more QoS flows. In some embodiments, if one checksum action is not associated with any QFI, it means the checksum action may be applied to the entire PDU session.
[0215] 10. The UPF sends a response message (e.g., the PFCP Session Modification Response) to the SMF. In some embodiments, this response message may be substantially identical to the response message in the operation 17 in Aspect 0 described above.
[0216] In some embodiments, the UPF may transmit a checksum action response (also referred to as first checksum action response in the present disclosure) including the “Accepted Checksum Action” and / or the “Rejected Checksum Action” to the SMF via the response message (e.g., the PFCP Session Modification Response) . In some embodiments, the response message (e.g., the PFCP Session Modification Response) may carry the “Accepted Checksum Action” if at least one indicated checksum action in the Checksum Action Instruction is accepted by the UPF. In some embodiments, the response message (e.g., the PFCP Session Modification Response) may carry the “Rejected Checksum Action” if at least one indicated checksum action in the Checksum Action Instruction is rejected by the UPF.
[0217] In some embodiments, the “Accepted Checksum Action” may carry at least one checksum action indicated in the Checksum Action Instruction that is accepted by the UPF.
[0218] In some embodiments, the “Rejected Checksum Action” may carry at least one checksum action indicated in the “Required Checksum Action” that is rejected by the UPF.
[0219] In some embodiments, the SMF first determines the initial checksum action (s) based on the previous retrieved the checksum capability of the UPF. In some embodiments, the SMF then provides the initial checksum action (s) to the UPF (e.g., in the operations 3-4) . In some embodiments, once the SMF gets the RAN node checksum capability (e.g., based on accepted / rejected checksum action (s) ) (e.g., via the operations 6-7) , the SMF may further determine the updated checksum action (s) based on the accepted / rejected checksum actions from the RAN. In some embodiments, the SMF may provide the updated checksum action (s) to the UPF (e.g., in the operations 9-10) . Through this 3-step checksum negotiation procedure, the final checksum action (s) may be determined and applied to both the UPF and the RAN node.
[0220] Similar as the PDU session establishment procedure, the SMF may also determine the checksum action instruction in the PDU session modification procedure. For example, the PFCP Session Establishment Request and the PFCP Session Establishment Response in the operations 3 and 4 may be replaced by using the PFCP Session Modification Request and the PFCP Session Modification Response, respectively.
[0221] An example is provided below to facilitate understanding, but the present disclosure is not limited thereto.
[0222] In the operation 2, the SMF obtains the checksum capability of the UPF, indicating the UPF supports “IPv4 zero checksum” , “TCP zero checksum” , “UDP zero checksum” , and “IPv4 UDP zero checksum” . Accordingly, in the operation 2, the SMF determines the initial checksum actions are “enabling IPv4 zero checksum” , “enabling TCP zero checksum” and “enabling UDP zero checksum” , and transmits them to the UPF via the “Checksum Action Instruction” in the operation 3.
[0223] In the operation 4, the SMF receives, from the UPF, “Accepted Checksum Action” including “enabling TCP zero checksum” and “enabling UDP zero checksum” and / or the “Rejected Checksum Action” including “enabling IPv4 zero checksum” . Accordingly, in the operation 5, the SMF determines the updated checksum actions to be “enabling TCP zero checksum” and “enabling UDP zero checksum” and transmits them to the RAN node via the “Checksum Action Instruction” in the operation 6.
[0224] In the operation 7, the SMF receives, from the RAN node, “Accepted Checksum Action” including “enabling TCP zero checksum” and / or the “Rejected Checksum Action” including “enabling UDP zero checksum” . Accordingly, in the operation 8, the SMF determines the updated checksum actions to be “enabling TCP zero checksum” and transmits it to the UPF via the “Checksum Action Instruction” in the operation 9.
[0225] In some embodiments of the present disclosure, a method of checksum handling, applied to a radio access network node, comprises at least one of:
[0226] receiving, checksum action instruction from a session management node; and / or
[0227] sending, result of checksum action instruction to the session management node.
[0228] In some embodiments, the checksum action instruction comprises at least one of:
[0229] at least one checksum and the associated action to enable or disable the indicated checksum; or
[0230] at least one zero checksum and the associated action to enable or disable the indicated zero checksum.
[0231] In some embodiments, one checksum is associated with one QoS flow identifier.
[0232] In some embodiments, receiving checksum action instruction from the session management node, comprises:
[0233] receiving N2 PDU session request from the session management node, wherein the message carries checksum action instruction.
[0234] In some embodiments, sending result of the checksum action to the session management node comprises:
[0235] sending N2 PDU session request ack to the session management node, wherein the message carries accepted checksum action and / or rejected checksum action.
[0236] In some embodiments of the present disclosure, a method of checksum handling, applied to a session management node, comprises at least one of:
[0237] receiving, checksum capability from the user plane node;
[0238] sending, checksum action instruction to the user plane node; and / or
[0239] receiving, result of checksum action instruction from the user plane node.
[0240] In some embodiments, the checksum capability comprises at least one of the following: IP checksum capability, IPv4 checksum capability, TCP checksum capability, UDP checksum capability, Ipv4 UDP checksum capability and / or Ipv6 checksum capability.
[0241] In some embodiments, the checksum capability indicates the zero checksum capability.
[0242] In some embodiments, the checksum action instruction at least one of comprises:
[0243] at least one checksum and the associated action to enable or disable the indicated checksum; and / or
[0244] at least one zero checksum and the associated action to enable or disable the indicated zero checksum.
[0245] In some embodiments, one checksum is associated with one QoS flow identifier.
[0246] In some embodiments, sending the checksum action instruction to the user plane node, comprises:
[0247] sending PFCP session establishment request or PFCP session modification request to the user plane node, wherein the request carries the checksum action instruction.
[0248] In some embodiments, receiving result of checksum action instruction from the user plane node comprises:
[0249] receiving PFCP session establishment response or PFCP session modification response from the user plane node, wherein the response carries accepted checksum action and / or rejected checksum action.
[0250] FIG. 5 relates to a diagram of a wireless communication terminal 30 according to an embodiment of the present disclosure. The wireless communication terminal 30 may be a tag, a mobile phone, a laptop, a tablet computer, an electronic book or a portable computer system and is not limited herein. The wireless communication terminal 30 may be used to implement UE described in this disclosure. The wireless communication terminal 30 may include a processor 300 such as a microprocessor or Application Specific Integrated Circuit (ASIC) , a storage unit 310 and a communication unit 320. The storage unit 310 may be any data storage device / memory that stores a program code 312, which is accessed and executed by the processor 300. Embodiments of the storage unit 310 include but are not limited to a subscriber identity module (SIM) , read-only memory (ROM) , flash memory, random-access memory (RAM) , hard-disk, and optical data storage device. The communication unit 320 may a transceiver and is used to transmit and receive signals (e.g., messages or packets) according to processing results of the processor 300. In an embodiment, the communication unit 320 transmits and receives the signals via at least one antenna 322 or via wiring.
[0251] In an embodiment, the storage unit 310 and the program code 312 may be omitted and the processor 300 may include a storage unit with stored program code.
[0252] The processor 300 may implement any one of the steps or operations in exemplified embodiments on the wireless communication terminal 30, e.g., by executing the program code 312.
[0253] The communication unit 320 may be a transceiver. The communication unit 320 may as an alternative or in addition be combining a transmitting unit and a receiving unit configured to transmit and to receive, respectively, signals to and from a wireless communication node.
[0254] In some embodiments, the wireless communication terminal 30 may be used to perform the operations of the UE described in this disclosure. In some embodiments, the processor 300 and the communication unit 320 collaboratively perform the operations described in this disclosure. For example, the processor 300 performs operations and transmit or receive signals, message, and / or information through the communication unit 320.
[0255] FIG. 6 relates to a diagram of a wireless communication node 40 according to an embodiment of the present disclosure. The wireless communication node 40 may be a satellite, a base station (BS) , a gNB, a network entity, a Domain Name System (DNS) server, a Mobility Management Entity (MME) , Serving Gateway (S-GW) , Packet Data Network (PDN) Gateway (P-GW) , a radio access network (RAN) , a next generation RAN (NG-RAN) , a data network, a core network, a communication node in the core network, or a Radio Network Controller (RNC) , and is not limited herein. In addition, the wireless communication node 40 may include (perform) at least one network function such as an access and mobility management function (AMF) , a session management function (SMF) , a user place function (UPF) , a policy control function (PCF) , an application function (AF) , etc. The wireless communication node 40 may be used to implement the RAN node, the SMF, or the UPF described in this disclosure. The wireless communication node 40 may include a processor 400 such as a microprocessor or ASIC, a storage unit 410 and a communication unit 420. The storage unit 410 may be any data storage device that stores a program code 412, which is accessed and executed by the processor 400. Examples of the storage unit 410 include but are not limited to a SIM, ROM, flash memory, RAM, hard-disk, and optical data storage device. The communication unit 420 may be a transceiver and is used to transmit and receive signals (e.g., messages or packets) according to processing results of the processor 400. In an embodiment, the communication unit 420 transmits and receives the signals via at least one antenna 422 or via wiring.
[0256] In an embodiment, the storage unit 410 and the program code 412 may be omitted. The processor 400 may include a storage unit with stored program code.
[0257] The processor 400 may implement any steps or operations described in exemplified embodiments on the wireless communication node 40, e.g., via executing the program code 412.
[0258] The communication unit 420 may be a transceiver. The communication unit 420 may as an alternative or in addition be combining a transmitting unit and a receiving unit configured to transmit and to receive, respectively, signals, messages, or information to and from a wireless communication node or a wireless communication terminal.
[0259] In some embodiments, the wireless communication node 40 may be used to perform the operations of the RAN node, the SMF, or the UPF described in this disclosure. In some embodiments, the processor 400 and the communication unit 420 collaboratively perform the operations described in this disclosure. For example, the processor 400 performs operations and transmit or receive signals through the communication unit 420.
[0260] A wireless communication method is also provided according to an embodiment of the present disclosure. In an embodiment, the wireless communication method may be performed by using a wireless communication node (e.g., the SMF) . In an embodiment, the wireless communication node may be implemented by using the wireless communication node 40 described in this disclosure, but is not limited thereto.
[0261] Referring to FIG. 7, in an embodiment, the wireless communication method includes: transmitting, by a session management node to a first wireless communication node, a checksum action instruction based on at least one of: a checksum capability of the first wireless communication node, a first checksum action response from the first wireless communication node, a checksum capability of a second wireless communication node, or a second checksum action response from the second wireless communication node, to allow the first wireless communication node to perform one or more checksum actions with the second wireless communication node.
[0262] Details in this regard can be ascertained with reference to the paragraphs above, and will not be repeated herein.
[0263] A wireless communication method is also provided according to an embodiment of the present disclosure. In an embodiment, the wireless communication method may be performed by using a wireless communication node (e.g., the RAN node or the UPF) . In an embodiment, the wireless communication node may be implemented by using the wireless communication node 40 described in this disclosure, but is not limited thereto.
[0264] Referring to FIG. 8, in an embodiment, the wireless communication method includes: receiving, by a first wireless communication node from a session management node, a checksum action instruction based on at least one of: a checksum capability of the first wireless communication node, a first checksum action response from the first wireless communication node, a checksum capability of a second wireless communication node, or a second checksum action response from the second wireless communication node, to perform one or more checksum actions with the second wireless communication node based on the checksum action instruction.
[0265] Details in this regard can be ascertained with reference to the paragraphs above, and will not be repeated herein.
[0266] In some embodiments, the wireless communication node used in the present disclosure may indicate the SMF, the RAN node or the UPF described above.
[0267] While various embodiments of the present disclosure have been described above, it should be understood that they have been presented by way of example only, and not by way of limitation. Likewise, the various diagrams may depict an example architectural or configuration, which are provided to enable persons of ordinary skill in the art to understand exemplary features and functions of the present disclosure. Such persons would understand, however, that the present disclosure is not restricted to the illustrated example architectures or configurations, but can be implemented using a variety of alternative architectures and configurations. Additionally, as would be understood by persons of ordinary skill in the art, one or more features of one embodiment can be combined with one or more features of another embodiment described herein. Thus, the breadth and scope of the present disclosure should not be limited by any one of the above-described exemplary embodiments.
[0268] It is understood that, in the present disclosure, the term “and / or” or symbol “ / ” may include any and all combinations of one or more of the associated listed items. For example, A and / or B and / or C includes any and all combinations of one or more of A, B, and C, including A, B, C, A and B, A and C, B and C, and a combination of A and B and C. Likewise, A / B / C includes any and all combinations of one or more of A, B, and C, including A, B, C, A and B, A and C, B and C, and a combination of A and B and C.
[0269] It is also understood that any reference to an element herein using a designation such as "first, " "second, " and so forth does not generally limit the quantity or order of those elements. Rather, these designations can be used herein as a convenient means of distinguishing between two or more elements or instances of an element. Thus, a reference to first and second elements does not mean that only two elements can be employed, or that the first element must precede the second element in some manner.
[0270] Additionally, a person having ordinary skill in the art would understand that information and signals can be represented using any one of a variety of different technologies and techniques. For example, data, instructions, commands, information, signals, bits and symbols, for example, which may be referenced in the above description can be represented by voltages, currents, electromagnetic waves, magnetic fields or particles, optical fields or particles, or any combination thereof.
[0271] A skilled person would further appreciate that any one of the various illustrative logical blocks, units, processors, means, circuits, methods and functions described in connection with the aspects disclosed herein can be implemented by electronic hardware (e.g., a digital implementation, an analog implementation, or a combination of the two) , firmware, various forms of program or design code incorporating instructions (which can be referred to herein, for convenience, as "software" or a "software unit” ) , or any combination of these techniques.
[0272] To clearly illustrate this interchangeability of hardware, firmware and software, various illustrative components, blocks, units, circuits, operations and steps have been described above generally in terms of their functionality. Whether such functionality is implemented as hardware, firmware or software, or a combination of these techniques, depends upon the particular application and design constraints imposed on the overall system. Skilled artisans can implement the described functionality in various ways for each particular application, but such implementation decisions do not cause a departure from the scope of the present disclosure. In accordance with various embodiments, a processor, device, component, circuit, structure, machine, unit, etc. can be configured to perform one or more of the functions described herein. The term “configured to” or “configured for” as used herein with respect to a specified operation or function refers to a processor, device, component, circuit, structure, machine, unit, etc. that is physically constructed, programmed and / or arranged to perform the specified operation or function.
[0273] Furthermore, a skilled person would understand that various illustrative logical blocks, units, devices, components and circuits described herein can be implemented within or performed by an integrated circuit (IC) that can include a general-purpose processor, a digital signal processor (DSP) , an application specific integrated circuit (ASIC) , a field programmable gate array (FPGA) or other programmable logic device, or any combination thereof. The logical blocks, units, and circuits can further include antennas and / or transceivers to communicate with various components within the network or within the device. A general-purpose processor can be a microprocessor, but in the alternative, the processor can be any conventional processor, controller, or state machine. A processor can also be implemented as a combination of computing devices, e.g., a combination of a DSP and a microprocessor, a plurality of microprocessors, one or more microprocessors in conjunction with a DSP core, or any other suitable configuration to perform the functions described herein. If implemented in software, the functions can be stored as one or more instructions or code on a computer-readable medium. Thus, the steps or operations of a method or algorithm disclosed herein can be implemented as software stored on a computer-readable medium.
[0274] Computer-readable media includes both computer storage media and communication media including any medium that can be enabled to transfer a computer program or code from one place to another. A storage media can be any available media that can be accessed by a computer. By way of example, and not limitation, such computer-readable media can include RAM, ROM, EEPROM, CD-ROM or other optical disk storage, magnetic disk storage or other magnetic storage devices, or any other medium that can be used to store desired program code in the form of instructions or data structures and that can be accessed by a computer.
[0275] In this document, the term "unit" as used herein, refers to software, firmware, hardware, and any combination of these elements for performing the associated functions described herein. Additionally, for purpose of discussion, the various units are described as discrete units; however, as would be apparent to one of ordinary skill in the art, two or more units may be combined to form a single unit that performs the associated functions according to embodiments of the present disclosure.
[0276] Additionally, memory or other storage, as well as communication components, may be employed in embodiments of the present disclosure. It will be appreciated that, for clarity purposes, the above description has described embodiments of the present disclosure with reference to different functional units and processors. However, it will be apparent that any suitable distribution of functionality between different functional units, processing logic elements or domains may be used without detracting from the present disclosure. For example, functionality illustrated to be performed by separate processing logic elements, or controllers, may be performed by the same processing logic element, or controller. Hence, references to specific functional units are only references to a suitable means for providing the described functionality, rather than indicative of a strict logical or physical structure or organization.
[0277] Various modifications to the implementations described in this disclosure will be readily apparent to those skilled in the art, and the general principles defined herein can be applied to other implementations without departing from the scope of the claims. Thus, the disclosure is not intended to be limited to the implementations shown herein, but is to be accorded the widest scope consistent with the novel features and principles disclosed herein, as recited in the claims below.
Claims
1.A wireless communication method comprising:transmitting, by a session management node to a first wireless communication node, a checksum action instruction based on at least one of: a checksum capability of the first wireless communication node, a first checksum action response from the first wireless communication node, a checksum capability of a second wireless communication node, or a second checksum action response from the second wireless communication node, to allow the first wireless communication node to perform one or more checksum actions with the second wireless communication node.2.The wireless communication method of claim 1, wherein the checksum capability of the first wireless communication node or the checksum capability of the second wireless communication node comprises at least one of:an Internet Protocol, IP, checksum capability,an Internet Protocol version 4, IPv4, checksum capability,a Transmission Control Protocol, TCP, checksum capability,a User Datagram Protocol, UDP, checksum capability,an IPv4 UDP checksum capability, oran Internet Protocol version 6, IPv6, UDP checksum capability.3.The wireless communication method of claim 1 or 2, wherein the checksum capability of the first wireless communication node or the checksum capability of the second wireless communication node comprises a zero checksum capability.4.The wireless communication method of any of claims 1 to 3, wherein the checksum action instruction comprises at least one of:enabling or disabling an IP checksum;enabling or disabling an IPv4 checksum;enabling or disabling a TCP checksum;enabling or disabling a UDP checksum;enabling or disabling an IPv4 UDP checksum; orenabling or disabling an IPv6 UDP checksum.5.The wireless communication method of any of claims 1 to 4, wherein the checksum action instruction comprises at least one of:enabling or disabling an IP zero checksum;enabling or disabling an IPv4 zero checksum;enabling or disabling a TCP zero checksum;enabling or disabling a UDP zero checksum;enabling or disabling an IPv4 UDP zero checksum; orenabling or disabling an IPv6 UDP zero checksum.6.The wireless communication method of any of claims 1 to 5 further comprising:receiving, by the session management node from the first wireless communication node, the checksum capability of the first wireless communication node.7.The wireless communication method of claim 6, wherein the checksum capability of the first wireless communication node is received via a Packet Forwarding Control Protocol, PFCP, Association Setup Request or a PFCP Association Setup Response.8.The wireless communication method of any of claims 1 to 7, wherein the first checksum action response or the second checksum action response comprising information of at least one of:a checksum capability of a sending wireless communication node;one or more accepted checksum actions; orone or more rejected checksum actions.9.The wireless communication method of any of claims 1 to 8, wherein the first checksum action response is received in response to the session management node transmitting a first checksum action instruction to the first wireless communication node.10.The wireless communication method of claim 9, wherein the first checksum action instruction is transmitted based on the checksum capability of the first wireless communication node.11.The wireless communication method of claim 9 or 10, wherein at least one of the following applies:the first checksum action instruction is transmitted via a PFCP session establishment request; orthe first checksum action response is received via a PFCP session establishment response.12.The wireless communication method of any of claims 1 to 11, wherein the second checksum action response is received in response to the session management node transmitting a second checksum action instruction to the second wireless communication node.13.The wireless communication method of claim 12, wherein the second checksum action instruction is transmitted based on at least one of: the checksum capability of the first wireless communication node or the first checksum action response.14.The wireless communication method of any of claims 1 to 13 further comprising:receiving, by the session management node from the first wireless communication node, a checksum action response in response to the checksum action instruction, the checksum action response comprising information of at least one of:one or more accepted checksum actions; orone or more rejected checksum actions.15.The wireless communication method of any of claims 12 to 14, wherein at least one of the following applies:the second checksum action instruction is transmitted via an N2 Packet Data Unit, PDU, session request;the second checksum action response is received via an N2 PDU session request Acknowledgment, ACK;the checksum action instruction is received via a PFCP session modification request; orthe checksum action response in response to the checksum action instruction is transmitted via a PFCP session modification response.16.The wireless communication method of any of claims 1 to 15, wherein the one or more checksum actions enables or disables one or more checksums or zero checksums for a corresponding session or a Quality of Service, QoS, flow.17.A wireless communication method comprising:receiving, by a first wireless communication node from a session management node, a checksum action instruction based on at least one of: a checksum capability of the first wireless communication node, a first checksum action response from the first wireless communication node, a checksum capability of a second wireless communication node, or a second checksum action response from the second wireless communication node, to perform one or more checksum actions with the second wireless communication node based on the checksum action instruction.18.The wireless communication method of claim 17, wherein the checksum capability of the first wireless communication node or the checksum capability of the second wireless communication node comprises at least one of:an Internet Protocol, IP, checksum capability,an Internet Protocol version 4, IPv4, checksum capability,a Transmission Control Protocol, TCP, checksum capability,a User Datagram Protocol, UDP, checksum capability,an IPv4 UDP checksum capability, oran Internet Protocol version 6, IPv6, UDP checksum capability.19.The wireless communication method of claim 17 or 18, wherein the checksum capability of the first wireless communication node or the checksum capability of the second wireless communication node comprises a zero checksum capability.20.The wireless communication method of any of claims 17 to 19, wherein the checksum action instruction comprises at least one of:enabling or disabling an IP checksum;enabling or disabling an IPv4 checksum;enabling or disabling a TCP checksum;enabling or disabling a UDP checksum;enabling or disabling an IPv4 UDP checksum; orenabling or disabling an IPv6 UDP checksum.21.The wireless communication method of any of claims 17 to 20, wherein the checksum action instruction comprises at least one of:enabling or disabling an IP zero checksum;enabling or disabling an IPv4 zero checksum;enabling or disabling a TCP zero checksum;enabling or disabling a UDP zero checksum;enabling or disabling an IPv4 UDP zero checksum; orenabling or disabling an IPv6 UDP zero checksum.22.The wireless communication method of any of claims 17 to 21 further comprising:transmitting, by the first wireless communication node to the session management node, the checksum capability of the first wireless communication node.23.The wireless communication method of claim 22, wherein the checksum capability of the first wireless communication node is transmitted via a Packet Forwarding Control Protocol, PFCP, Association Setup Request or a PFCP Association Setup Response.24.The wireless communication method of any of claims 17 to 23, wherein the first checksum action response or the second checksum action response comprising information of at least one of:a checksum capability of a sending wireless communication node;one or more accepted checksum actions; orone or more rejected checksum actions.25.The wireless communication method of any of claims 17 to 24, wherein the first checksum action response is transmitted in response to the session management node transmitting a first checksum action instruction to the first wireless communication node.26.The wireless communication method of claim 25, wherein the first checksum action instruction is received based on the checksum capability of the first wireless communication node.27.The wireless communication method of any of claims 17 to 26 further comprising:transmitting, by the first wireless communication node to the session management node, a checksum action response in response to the checksum action instruction, the checksum action response comprising information of at least one of:one or more accepted checksum actions; orone or more rejected checksum actions.28.The wireless communication method of any of claims 25 to 27, wherein at least one of the following applies:the first checksum action instruction is received via a PFCP session establishment request;the first checksum action response is transmitted via a PFCP session establishment response;the checksum action instruction is via a PFCP session modification request; orthe checksum action response in response to the checksum action instruction is transmitted via a PFCP session modification response.29.The wireless communication method of any of claims 17 to 28, wherein the one or more checksum actions enables or disables one or more checksums or zero checksums for a corresponding session or a Quality of Service, QoS, flow.30.A session management node, comprising:a communication unit; anda processor configured to:transmit, via the communication unit to a first wireless communication node, a checksum action instruction based on at least one of: a checksum capability of the first wireless communication node, a first checksum action response from the first wireless communication node, a checksum capability of a second wireless communication node, or a second checksum action response from the second wireless communication node, to allow the first wireless communication node to perform one or more checksum actions with the second wireless communication node.31.The first wireless communication node of claim 30, wherein the processor is further configured to perform a wireless communication method of any of claims 2 to 16.32.A first wireless communication node, comprising:a communication unit; anda processor configured to:receive, via the communication unit from a session management node, a checksum action instruction based on at least one of: a checksum capability of the first wireless communication node, a first checksum action response from the first wireless communication node, a checksum capability of a second wireless communication node, or a second checksum action response from a the second wireless communication node, to perform one or more checksum actions with the second wireless communication node based on the checksum action instruction.33.The first wireless communication node of claim 32, wherein the processor is further configured to perform a wireless communication method of any of claims 18 to 29.34.A computer program product comprising a computer-readable program medium code stored thereupon, the code, when executed by a processor, causing the processor to implement a wireless communication method recited in any of claims 1 to 29.
Citation Information
Patent Citations
Methods, systems, and computer readable media for verifying session management function (SMF) registration requests
CN116420391A
Method, apparatus and computer program product for wireless communication
CN116420420A
Broadcast service recovery of multicast / broadcast service upon radio access node failure or restart
CN116582823A
Persistent checksum data validation
US20170060674A1