Method and device for efficient policy enforcement using network tokens for services-user-plane approach

Method and equipment for efficient strategy implementation using network tokens for service-user plane methods

METHOD AND DEVICE FOR EFFICIENT POLICY ENFORCEMENT USING NETWORK TOKENS FOR SERVICES-USER-PLANE APPROACH

This patent application claims to enjoy the priority and rights of the following applications: Provisional Application No. 62/120,159 filed in the United States Patent and Trademark Office on February 24, 2015, and filed in the United States on May 14, 2015 Provisional Application No. 62/161,768 of the Patent and Trademark Office and Non-Provisional Application No. 14/866,425 filed with the United States Patent and Trademark Office on September 25, 2015.

In a nutshell, one aspect is about network tokens, and more specifically, about the uplink and downlink network tokens associated with the uplink and downlink user plane data streams. Obtain, provide, and use to facilitate the implementation of network policies (for example, verifying that the device is only accessing authorized application services) and/or packet redirection.

Some client devices may have network access rights, but their network access rights may be limited to a set of application services. Internet service providers can use policies to impose such restrictions. In one instance, a specific application service provides The donor can sponsor the network access of the client device. The client device may be limited by the application service executed by the application service provider on its server. In another example, a client device with network access may be part of a contract that allows special charging or handling of data (e.g., bit rate or quality of service) associated with a given application service. For example, a client device may have a cellular subscription via a cellular provider, and the cellular provider may wish to impose one or more constraints on the client device. In one instance, a company that is currently considered a social media provider rather than a hive provider will play the role of a hive provider in the future. In this example, the client device may have a subscription to the company. As part of its customized agreement, client devices can gain access to the Internet, but may be restricted to use the companys social media sites, excluding other social media sites. By way of another example, the client device may have a subscription to a streaming media service provider. In this example, as part of the agreement, the client device can obtain access to the Internet through various cellular providers (for example, mobile network service providers). However, the access rights may be subject to the agreement (between the streaming media service provider and the users of the various cellular providers and/or client devices) to use the media service providers website to obtain all streaming media services. . By way of another example, for certain access point names (APIs), only certain traffic (for example, control plane signal delivery and/or user plane message).

It can be combined with application services to formulate network policies to ensure that the client device does not violate any agreement, is provided with access to the agreed application service, and/or is provided with an agreed service level. The network can target the data in the packet Such a strategy is implemented by using uplink (UL) packets sent from the client device to, for example, an application server on a network (for example, the Internet). The network can additionally implement these policies for downlink (DL) packets sent from the application server to the client device.

Currently, the implementation of policies for application services occurs at the gateway to the network. An example of such a gateway is a packet data network gateway (P-GW), which acts as a core network (e.g., Evolved Packet Core (EPC)) and a packet data network (PDN) such as the Internet Between the gateways. One problem is that policy implementation (for example, the implementation of a service access policy) may require the P-GW to verify all UL and DL packets sent between the client device and the application server. In addition, each UL packet and DL packet may need to be diverted to its destination address via a specific bearer or data stream. The destination address can include two parts: the first code part and the post part.

The network strategy can be implemented by verifying UL and DL packets at the P-GW. Implementation can ensure that client devices only send packets to and/or receive packets from authorized application services. The verification may include verifying the destination address or the destination address and port number of the packet passing through the P-GW. Verification can additionally include verifying the source address of each packet. Verifying the source address of each packet may be useful for anti-spoofing (for example, by preventing packets from unauthorized client devices from deceiving the network by appearing to be from authorized client devices. Packet redirection may be required to ensure that the agreement is reached Quality of service (QoS).

The current practice incurs a lot of management burden and increases the forwarding delay caused by the processing delay. Current practice usually uses packet inspection (for example, deep packet inspection, shallow packet inspection) and traffic flow templates (TFT) and services Data flow (SDF) template to achieve. The P-GW checks the header of each packet to confirm that the packet conforms to the TFT/SDF template defined for the service.

Figure 1 is the SDF template 102 when detecting the downlink part 104 of the service data stream and mapping this part to a bearer such as the Internet Protocol Connected Access Network (IP-CAN) bearer 106 shown. An illustration of the prior art in action. Figure 1 is based on 3GPP Technical Specification (TS) 23.203, Figure 6.4.

The SDF template 102 is established to verify and map downlink packets. However, the use of a set of packet screening programs (see, for example, the packet screening program af in the SDF template 102) requires the use of tables and table viewing procedures. The use of such tables and procedures affects efficiency because the use requires memory storage space and processor resources to execute these procedures. In addition, time and resources are wasted because each packet must be filtered by multiple filters before any given packet is applied to a filter that meets all the requirements of the filter.

Therefore, the use of packet inspection and TFT/SDF templates (for either or both of uplink packets and downlink packets) at the P-GW is problematic, for example, because their use incurs a lot of administrative burden (For example, processing resources and memory resources for memory inspection and pattern matching) and increase the forwarding delay caused by the processing delay. In addition, it is difficult to perform subtle policy control (for example, for each service), because additional policy control will incur additional management burden and processing delay, because additional filtering rules implemented for TFT/SDF templates are needed to test packets . In addition, for sponsored connections, the use of the TFT/SDF template is not scalable. The increase in the number of sponsors for different services (there may be thousands of services in the coming years) will mean an increase in the time required to filter packets through a correspondingly increased number of TFT/SDF templates. add. Again, this will incur additional administrative burden and processing delays.

What is needed is an alternative to supplement and/or enhance packet inspection and improve the efficiency of uplink and downlink network policy implementation.

According to the first aspect, a method can be operated at the device. The method may include initiating a connection via the device with an application server, the application server being associated with one or more application services. In response to initiating the connection, the device can obtain the network token. The network token may be associated with the first stream in the set of one or more streams, associated with the first application service in the one or more application services, and sent to the device via one or more user plane messages. The method may also include sending the network token along with the same or multiple uplink (UL) packets from the device to the application server in the user plane.

According to an additional aspect, the network token can be obtained from one of the application server and/or the gateway device. The network token can be obtained through the gateway device of the core network. It can be based on the device subscription profile of the device and/or the policy of the first application service. It can reflect the strategy implemented by the core network for devices. The mode of initiating a connection may include sending a connection request, and the connection request includes an explicit request for a network token. It can include sending packets that represent implicit requests for network tokens.

According to some aspects, the implicit request can be expressed by sending the first packet to the application server. Initiating the connection may include sending a packet for requesting confirmation from the application server, where the confirmation transmits the network token to the device. The network token can be transmitted from the device to the packet data network (PDN) gateway (P-GW) in the user plane shim header. User plane cushion The header can be located above the Internet Protocol (IP) layer. The network token can be transmitted from the device to the packet data network (PDN) gateway (P-GW) in the Internet Protocol (IP) extension header as defined in IP version 6 (IPv6). It can be transmitted from the device to the access node in the Packet Data Convergence Protocol (PDCP) layer, and replicated in the access node to the General Packet Radio Service (GPRS) Tunneling Protocol (GTP) for the user plane (GTP-U) ) Layer (GTP-U) layer, and in the GTP-U layer from the access node to the packet data network (PDN) gateway (P-GW).

According to one aspect, a device including a network communication interface and a processing circuit configured to communicate via a wireless network can perform the above-mentioned method. The processing circuit is coupled to the network communication interface.

According to another aspect, a method can be operated at a gateway device in the network. The method may include: receiving the first data packet via the user plane at the gateway device. The method may also include: determining whether a network token is requested by evaluating the first data packet, and if the network token is requested, obtaining the network token. Network tokens can be customized profiles based on equipment maintained by the network. The method may also require (entail): if the network token is requested, the first data packet is used to include the network token; and the first data packet and the network token are sent to the destination.

According to an additional aspect, the first data packet can be sent to the application server, and the network token is an uplink network token. The first data packet can be sent to the application server, and the network token is a downlink network token. The first data packet can be sent to the device, and the network token is the downlink network token. If the first data packet is sent to the device and the network symbol Is a downlink network token, the method may also include: receiving a second data packet including the downlink network token from the device at the gateway device; and combining the second data packet with the downlink network token The waymark is sent to the application server. According to some aspects, the network token is an uplink network token and a downlink network token, and the uplink network token is different from the downlink network token. The gateway device can be a packet data network (PDN) gateway (P-GW). The first packet can include an explicit request for network tokens or can indicate an implicit request for network tokens. According to some aspects, the determination of whether a network token is requested may be based on whether the application server to which the first packet is to be sent or the application server from which the first packet is to be received requires the network token.

Obtaining the network token can be achieved by obtaining the network token from the gateway device. The network token can be obtained by using a function with a set of input parameters. The input parameters include: the known key of the gateway device, the class index, the source Internet Protocol (IP) address, the source port number, and the destination IP address, destination port number, protocol identifier (ID), application ID, priority and/or quality of service class identifier (QCI). The class index defines the fields used for network token retrieval. The network token can be a concatenation of the class index and the output of the function.

According to one aspect, a gateway device including a network communication interface and a processing circuit configured to communicate via a wireless network can perform the above-mentioned method. The processing circuit is coupled to the network communication interface.

According to another aspect, the method operable at the gateway device may include: in response to a request for the first network token sent from the device to the application server, obtaining the first network token from the gateway device , The application server is associated with one or more application services. The method may include receiving at the gateway device A data packet from the device, the data packet including at least the destination address prefix corresponding to the application server, and the data packet including the second network token. The method may also include: verifying the second network token; if the verification is unsuccessful, discarding the data packet; and if the verification is successful, sending the data packet to the application server. Data packets can be received in user plane messages. The gateway device can be a packet data network (PDN) gateway (P-GW). Verifying the second network token may include: obtaining a copy of the first network token according to the first function using the input parameters obtained from the data packet and a key known by the gateway device. Verifying the second network token may also include comparing the copy of the first network token with the second network token, where if the copy of the first network token is equal to the second network token, The verification is successful.

According to some aspects, the second network token may be transmitted from the device to the gateway device in a cushion header separate from the IP header. The second network token may be transmitted from the device to the gateway device in an IP extension header defined in Internet Protocol (IP) version 6 (IPv6). According to some aspects, the second network token can be transmitted from the device to the access node in the Packet Data Convergence Protocol (PDCP) layer, and copied in the access node to the general packet for the user plane (GTP-U) Radio Service (GPRS) Tunneling Protocol (GTP) layer (GTP-U) layer, and is transmitted from the access node to the gateway device in the GTP-U layer.

According to one aspect, a gateway device including a network communication interface and a processing circuit configured to communicate via a wireless network can perform the above-mentioned method. The processing circuit is coupled to the network communication interface.

According to another aspect, the method operable at the application server may include: sending via an application server associated with one or more application services Used to initiate a request for the first application service with the device. The method may also include: obtaining a network token in response to sending a request for initiating the first application service. The network token can be associated with the first stream in the set of one or more streams, associated with the first application service, and sent to the device via one or more user plane messages. The method may also include: sending the network token together with one or more downlink (DL) packets sent from the application server to the device in the user plane. The network token can be obtained through the gateway device of the core network. It can be based on the device subscription profile of the device and/or the policy of the first application service. It can reflect the strategy implemented by the core network for devices. The request for initiating the first application service may include an explicit request for the network token or may include sending a packet indicating an implicit request for the network token.

According to one aspect, an application server including a network communication interface and a processing circuit configured to communicate via a wireless network can execute the above method. The processing circuit is coupled to the network communication interface.

<p>102SDF template</p><p>104Downlink part</p><p>106Internet Protocol Connection Access Network (IP-CAN) bearer</p><p>200Operating environment</p><p>202Client Equipment</p><p>204Client Equipment</p><p>206Access Node</p><p>208Radio Access Network (RAN)</p><p>210Core Network (CN)</p><p>212Mobile Management Entity (MME)</p><p>216Service Gateway (S-GW)</p><p>218Home User Server (HSS)</p><p>220Packet Data Gateway (P-GW)</p><p>222Packet Data Network (PDN)</p><p>224Server</p><p>226Server</p><p>228Server</p><p>230Server</p><p>300Uplink operation</p><p>302Equipment</p><p>304Access Node</p><p>306Service Gateway (S-GW)</p><p>308Service Gateway (S-GW)</p><p>310Packet Data Network (PDN)</p><p>312Application/Application Service</p><p>314IP Stream</p><p>316Traffic Flow Template (TFT)</p><p>318Carrier</p><p>320Processing circuit/functional unit/module</p><p>322Traffic steering circuit/functional unit/module</p><p>324Service Data Flow (SDF) Template</p><p>400Downlink operation</p><p>402Equipment</p><p>404Access Node</p><p>406Service Gateway (S-GW)</p><p>408P-GW</p><p>410PDN</p><p>414Downlink IP flow</p><p>416Traffic Flow Template (TFT)</p><p>418Carrier</p><p>420Decision and processing circuit/module/equipment</p><p>422Encryption-checksum traffic steering circuit/module/equipment</p><p>424Service Data Flow (SDF) Template</p><p>Form 424a</p><p>428Cache</p><p>500Dialing process</p><p>502Equipment</p><p>504Access Node</p><p>506MME</p><p>508S-GW</p><p>510P-GW</p><p>512Strategy and Charging Rules Function (PCRF)</p><p>514Home User Server (HSS)</p><p>515Application Server</p><p>516Application Server</p><p>518Send</p><p>520obtained</p><p>522obtained</p><p>524embedded/included</p><p>530Send</p><p>532Check</p><p>534Send</p><p>600Dialing process</p><p>602Equipment</p><p>604Access Node</p><p>606MME</p><p>608S-GW</p><p>610P-GW</p><p>612Strategy and Charging Rules Function (PCRF)</p><p>614Home User Server (HSS)</p><p>616Application Server</p><p>618Send</p><p>620obtained</p><p>622obtained</p><p>624embedded</p><p>626obtained</p><p>628Storage</p><p>630Storage</p><p>632send</p><p>634Check</p><p>636Send</p><p>700Dial Flow Chart</p><p>702Equipment</p><p>704Access Node</p><p>706MME</p><p>708S-GW</p><p>710P-GW</p><p>712Policy and Charging Rules Function (PCRF) Equipment</p><p>714Home User Server (HSS)</p><p>716Application Server</p><p>718Send</p><p>720Equipment</p><p>722obtained</p><p>724embedded</p><p>726obtained</p><p>728Storage</p><p>730 initiated</p><p>732Check</p><p>733 released</p><p>734Send</p><p>736Check</p><p>738Send</p><p>740Send</p><p>742Check</p><p>744Send</p><p>800Dialing process</p><p>802Equipment</p><p>804Access Node</p><p>806MME</p><p>808S-GW</p><p>810P-GW</p><p>812Policy and charging rules function (PCRF) equipment</p><p>814Home User Server (HSS)</p><p>816Application Server</p><p>818send</p><p>820Equipment</p><p>822obtained</p><p>823obtained</p><p>824embedded/included</p><p>826Send</p><p>828Send</p><p>830Check</p><p>832Send</p><p>834includes</p><p>836Check</p><p>838Send</p><p>840Send</p><p>842Check</p><p>844Send</p><p>902Client Equipment</p><p>904Access Node</p><p>906Gateway equipment</p><p>908Application Server</p><p>910Physical (PHY) layer</p><p>912Media Access Control (MAC) layer</p><p>914Radio Link Control (RLC) layer</p><p>916Packet Data Convergence Protocol (PDCP) layer</p><p>918Internet Protocol (IP) layer</p><p>920Cushion</p><p>922Cushion</p><p>924IP layer</p><p>926Floor</p><p>930Physical (PHY) layer</p><p>932Media Access Control (MAC) layer</p><p>934Radio Link Control (RLC) layer</p><p>936Packet Data Convergence Protocol (PDCP) layer</p><p>940Ethernet layer</p><p>942MAC layer</p><p>944IP layer</p><p>946User Data Packet Protocol (UDP) layer</p><p>948GTP-U layer</p><p>952Floor</p><p>954Floor</p><p>956Floor</p><p>958IP layer</p><p>960Network Symbol</p><p>1002Client Equipment</p><p>1004Access node</p><p>1006Gateway equipment</p><p>1008Application Server</p><p>1016PDCP layer</p><p>1026PDCP layer</p><p>1036PDCP layer</p><p>1048GTP-U layer</p><p>1060Network Symbol</p><p>1102Client Equipment</p><p>1104Access Node</p><p>1106Gateway equipment</p><p>1108Application Server</p><p>1110Physical (PHY) layer</p><p>1112Media Access Control (MAC) layer</p><p>1114Radio Link Control (RLC) layer</p><p>1116Packet Data Convergence Protocol (PDCP) layer</p><p>1118Internet Protocol (IP) layer</p><p>1124IP layer</p><p>1158IP layer</p><p>1160Downlink network symbol</p><p>1202Client Equipment</p><p>1204Access Node</p><p>1206Gateway equipment</p><p>1208Application Server</p><p>1210Physical (PHY) layer</p><p>1212Media Access Control (MAC) layer</p><p>1214Radio Link Control (RLC) layer</p><p>1216Packet Data Convergence Protocol (PDCP) layer</p><p>1218Internet Protocol (IP) layer</p><p>1220Cushion</p><p>1224IP layer</p><p>1250Floor</p><p>1258IP layer</p><p>1260Downlink network symbol</p><p>1300Equipment</p><p>1302Network communication interface circuit</p><p>1304Processing circuit</p><p>1306Storage device</p><p>1308The first input/output module/circuit/functional unit</p><p>1310Receiver/Transmitter Module/Circuit/Function Unit</p><p>1312Network symbol processing module/circuit/functional unit</p><p>1314Network symbol extraction/embedded module/circuit/functional unit</p><p>1316Encryption verification/verification module/circuit/functional unit</p><p>1320Network Symbol Disposition Command</p><p>1322Network token extraction/embedding instruction</p><p>1324Encryption Verification/Verification Command</p><p>1326Key Storage and Command</p><p>1334Communication bus</p><p>1400Method</p><p>1402Initiated</p><p>1404obtained</p><p>1406includes</p><p>1500Method</p><p>1502Receive</p><p>1504obtained</p><p>1506Check</p><p>1508includes</p><p>1510Send</p><p>1600Gateway equipment</p><p>1602Network communication interface circuit</p><p>1604Processing circuit</p><p>1606Storage device</p><p>1608First input/output circuit/functional unit/module</p><p>1610Second input/output circuit/functional unit/module</p><p>1612Network symbol acquisition/check circuit/functional unit/module</p><p>1614Key acquisition circuit/functional unit/module</p><p>1616Decision and processing circuit/functional unit/module</p><p>1618Encryption-authentication and traffic redirection circuit/functional unit/module</p><p>1620Network token acquisition/verification command</p><p>1622Key Obtaining Command</p><p>1624Decision and processing instructions</p><p>1626Encryption-Verification and Traffic Diversion Command</p><p>1630Encryption verification/verification module/circuit/functional unit</p><p>1632Key Storage and Command</p><p>1634Communication bus</p><p>1700Method</p><p>1702Receive</p><p>1704Decision</p><p>1706obtained</p><p>1708includes</p><p>1710Send</p><p>1800Method</p><p>1802Receive</p><p>1804obtained</p><p>1806obtained</p><p>1808Storage</p><p>1810includes</p><p>1812Send</p><p>1814Receive</p><p>1816Verification</p><p>1818Verification</p><p>1820Verification</p><p>1900Method</p><p>1902obtained</p><p>1904Receive</p><p>1906Check</p><p>1908Check</p><p>1910Decision</p><p>1912Discard</p><p>1914Discard</p><p>1916Sent</p><p>2000Application Server</p><p>2002Network communication interface circuit</p><p>2004Processing circuit</p><p>2006Storage device</p><p>2008The first input/output module/circuit/functional unit</p><p>2010Receiver/Transmitter Module/Circuit/Function Unit</p><p>2012Network symbol processing module/circuit/functional unit</p><p>2014Network symbol extraction/embedded module/circuit function unit</p><p>2016Encryption verification/verification storage device</p><p>2020Network token disposal command</p><p>2022Network token extraction/embedding instruction</p><p>2024Network token extraction/embedding instruction</p><p>2026Key Storage and Command</p><p>2034Key Storage and Command</p><p>2100Method</p><p>2102Decision</p><p>2104Send</p><p>2106Waiting</p><p>2108obtained</p>

Figure 1 is the role of the SDF template in detecting the downlink part of the service data stream and mapping this part to a bearer such as the Internet Protocol Connected Access Network (IP-CAN) bearer shown Prior art illustration.

Figure 2 illustrates an exemplary operating environment.

Figure 3 illustrates exemplary uplink operation in accordance with aspects described herein.

Figure 4 illustrates exemplary downlink operation in accordance with aspects described herein.

5 is a diagram illustrating an exemplary dialing process for obtaining, providing, and using network tokens combined with one or more user plane messages according to the aspect described herein.

Fig. 6 illustrates an exemplary dialing process for obtaining, providing, and using network tokens combined with one or more user plane messages according to the aspect described herein.

FIG. 7 illustrates an exemplary dialing process for obtaining, providing, and using network tokens combined with one or more user plane messages according to the aspect described herein.

8 is a diagram illustrating two network tokens (for example, uplink network token and downlink network token) combined with one or more user plane messages according to the aspect described herein Exemplary dialing procedures for obtaining, providing, and using.

Fig. 9 is an exemplary illustration of a user-level protocol stack of a system according to one aspect described herein.

Fig. 10 is an exemplary illustration of a user-level protocol stack according to another aspect of the system described herein.

Fig. 11 is an exemplary illustration of a user-level protocol stack according to another aspect of the system described herein.

Fig. 12 is an exemplary illustration of a user-level protocol stack according to another aspect of the system described herein.

Figure 13 is a block diagram illustrating an exemplary device configured to use network tokens to support network policy enforcement and/or packet diversion in accordance with the aspects described herein.

FIG. 14 is an exemplary method by which a device (for example, a chip assembly, a client device) can initiate a request for communication with an application server, and use a network token in conjunction with the communication.

FIG. 15 is an exemplary method by which a device (for example, a chip assembly, a client device) can respond to a request for initiating a communication, and use a network token in conjunction with the communication.

Figure 16 is a block diagram illustrating an exemplary gateway device configured to use network tokens to support network policy enforcement and/or packet diversion according to the aspects described herein.

FIG. 17 illustrates an exemplary method that can be operated at a gateway device (for example, P-GW) according to the aspect described herein, and the method is used to detect a pair of network symbols from the device via a user plane message The request to record, obtain the network token, and provide the network token to the requesting device via the application server.

FIG. 18 illustrates an exemplary method that can be operated at a gateway device (eg, P-GW) according to the aspect described herein, and the method is transmitted at the gateway device (eg, P-GW) via a user plane message Set up and use network tokens.

Figure 19 illustrates an exemplary method that can be operated at a gateway device (e.g., P-GW) according to the aspect described herein, which is combined with the use of network tokens to verify network tokens (e.g., , Network token verification), used for network strategy implementation and/or packet redirection.

Figure 20 is a block diagram illustrating an exemplary application server configured to support downlink token verification and packet mapping.

FIG. 21 is a flowchart of an exemplary method of setting a network token at an application server according to the aspect described herein.

In the following description, reference is made to the accompanying drawings, which illustrate specific embodiments in which the content of this case can be practiced by way of explanation. These examples It is intended to describe the content of this case in detail so that persons with ordinary knowledge in the field to which the present invention belongs can practice the present invention. Other embodiments can be used and changes can be made to the disclosed embodiments without departing from the scope of protection of the content of the case. The following detailed description should not be regarded as limiting, and the scope of protection of the present invention is only limited by the accompanying claims.

In this article, the term "device" can be used to refer to chip components and/or client devices, such as mobile devices, mobile phones, mobile communication devices, mobile computing devices, digital tablet devices, smart phones, user devices, users Equipment, terminals and other equipment. As used herein, the term "obtained" can mean to obtain from one device locally or obtain from another device.

Overview

In a nutshell, the aspects described in this article involve the acquisition, provision, and use of uplink network tokens and downlink network tokens. The network token can be transmitted with the packet in the user plane. Uplink network tokens or downlink network tokens can be embedded in one or more packets or otherwise included in one or more packets, and used for network policy enforcement and/or traffic Turn (for example, the turn of one or more user plane messages).

The request for network tokens can be explicit or implicit. The explicit request may be included in, for example, a connection request made from the device to the application server or a connection request made from the application server to the device. The application server may be associated with one or more application services. If the request is explicit, it can be transmitted with one or more packets including the connection request. The packet from the device to the application server or the packet from the application server to the device is moving from its source to its destination On the way through the Packet Data Gateway (P-GW). At the P-GW, the packet can be inspected/reviewed/analyzed to determine whether the packet explicitly includes (or implicitly indicates) a request for network tokens.

If, for example, the request for the network token is included in the connection request, the P-GW can use the encryption function, the unshared key known by the P-GW, and the parameters that can be obtained from the packet and the parameters associated with the service. The network token. However, the P-GW may not directly send the network token just obtained to the entity that requested the network token. Instead, it may use the packet carrying the connection request (and the request for the network token) to embed or otherwise include the network token, and send the packet (and the network token just obtained) to its destination For example, the destination identified from the destination address (or at least the destination address prefix) in the packet header. At the destination, the processing circuit prepares a response to the connection request (for example, a connection response), and includes the network token in the packet containing the connection response, or uses the packet to include the network token. Packets can be sent via the user plane to the source of the request network token and the initiator of the connection request. Thereafter, when the source has additional packets to be sent to the destination, the source may include (or use the one or more additional packets to include) a copy of the network token in one or more additional packets.

Uplink network tokens and/or downlink network tokens can be used by the P-GW to implement network policies. According to the aspect described herein, a packet including a previously obtained copy of the original network token can be received at the P-GW. The previously obtained copy of the original network token can be an uplink network token or a downlink network token. The P-GW can verify the previously obtained copy of the original network token. The verification process may include obtaining a copy of the original network token. make With the same encryption function, the same unshared key known by P-GW, and the same other parameters that can be obtained from the packet, the copied network token can be obtained in the same way as the original network token. The newly received packet associated with the copy of the original network token is different from the packet associated with the original network token; however, there are parameters that can be obtained from the newly received packet and those obtained from the original packet The same parameters. These common parameters can be used in the encryption function to obtain the copied network token. If the copied network token is equal to the copy of the original network token, the copy of the original network token just received can be regarded as a successful verification. Upon successful verification, the packet can be sent to its destination. If the verification is unsuccessful, the packet can be discarded.

Exemplary operating environment

FIG. 2 illustrates an exemplary operating environment 200. In such an exemplary operating environment 200, one or more client devices 202, 204 (e.g., client device A, client device B) may interact with an access node 206 (e.g., node B, evolved node B, Access point (AP)) for wireless communication. The access node 206 may be included in a radio access network (RAN) 208 (e.g., an evolved universal terrestrial radio access network (E-UTRAN)). As known to those with ordinary knowledge in the field of the present invention, the RAN 208 usually includes more than one access node 206. The figure only shows one access node 206 to reduce clutter.

In a non-limiting example of a cellular communication system (for example, 4G, LTE, LTE-A), the RAN 208 can transfer control plane signal transmission and user plane information to the core network (CN) 210 (for example, evolutionary packet Core (EPC)). In the diagram of FIG. 2, the dotted line represents the control signal path, and the solid line represents the user data message path. The control plane communicates control signals (e.g., User plane signal transmission). The user plane conveys user data (for example, user plane messages). The implementation of the aspect described herein utilizes the user plane; there is no need to control plane signal transmission. Because there is no need for control plane signal transmission, for most of the network functions are not affected. The modification of the user plane protocol stacking of the client device and the P-GW can be implemented in association with the aspects described herein. For example, the network token setting procedure may require modification of the protocol stack. In other words, when a client device initiates a connection request with an indication of a request for a network token, the gateway device obtains the network token and embeds the network token in the connection request or uses the connection request in other ways To include the network token (for example, in a packet with a connection request). The aspect described herein provides several alternatives for embedding network tokens (for example, TCP, IP, underlayment, etc.), and describes corresponding exemplary modifications to the protocol stack to realize the embedding of network tokens.

The CN 210 may include a mobility management entity (MME) 212, a service gateway (S-GW) 216, a home user server (HSS) 218, and a packet data network gateway (P-GW) 220. The P-GW 220 can communicate with a packet data network (PDN) 222 (for example, the Internet). More specifically, the P-GW 220 can communicate with the servers 224, 226, 228, 230 (for example, application servers) in the PDN 222. The servers 224, 226, 228, 230 may be associated with service providers, such as service providers that provide sales services, information services, data streaming video services, and social media services.

Figure 3 illustrates exemplary uplink operations 300 in accordance with aspects described herein. For convenience, this exemplary uplink operation 300 is presented in the context of a long-term evolution (LTE) system. This example is not intended to be a reference to any aspect described herein Impose any restrictions on the scope of protection.

Figure 3 shows equipment 302 (for example, chip assembly, client device, user device, user equipment, terminal, mobile device), access node 304 (for example, evolutionary node B), service gateway (S -GW) 306, packet gateway (P-GW) 308, and packet data network (PDN) 310 (for example, the Internet).

The exemplary uplink operation 300 of FIG. 3 is now described. The IP flow 314 (for example, the application/application service 312 from the device 302) is applied to the packet screening program (not shown) included in the traffic flow template (TFT) 316. The number of IP streams 314 illustrated is exemplary and not intended to be limiting.

The packet screening program of the TFT 316 filters the IP flow into the bearer 318 (for example, the evolutionary packet system (EPS) bearer). For demonstration purposes, three bearers 318 (e.g., bearer 1, bearer N-1, and bearer N) are shown. In one aspect, the bearer can be shared by multiple applications/application services. Each bearer can be associated with a unique set of parameters.

The IP flow 314 may be mapped to, for example, a preset bearer or to one or more dedicated bearers. The preset bearer can usually have a non-guaranteed bit rate, and the dedicated bearer can usually have a guaranteed or non-guaranteed bit rate. The bearer 318 may pass through the access node 304 and the S-GW 306. The aspects of the access node 304 and the S-GW 306 are not described herein, and are known to those with ordinary knowledge in the field of the present invention.

In one aspect, the IP stream 314 from the bearer 318 can be passed to the decision and processing circuit/functional unit/module 320. The decision and processing circuit/functional unit/module 320 can cause the UL packet received from the bearer 318 to be transferred to the Canadian Secret-verification and traffic diversion circuit/functional unit/module 322 or service data flow (SDF) template 324 and packet screening program (not shown) included therein. Traffic diversion covers the diversion of signal transmission-related packets and/or user data message-related packets (for example, guidance, guidance).

The UL packet including the network token can be passed to the encryption-verification and traffic diversion circuit/functional unit/module 322. The implementation of one or more policies associated with the network token can be performed when the network token is successfully verified.

The UL packet that does not include the network token can be passed to the SDF template 324 via the decision and processing circuit/functional unit/module 320. The use of the packet screening program of the SDF template 324 may require more processing and memory resources than the use of encryption-authentication and traffic diversion circuits/functional units/modules 322. In order to use the packet filter of the SDF template 324 to perform filtering, for example, the P-GW 308 must maintain a separate table entry table for each SDF.

Therefore, the use of network tokens (and the subsequent use of encryption-authentication and traffic diversion circuits/functional units/modules 322) saves resources and reduces delays. In one aspect, encrypted network tokens (for example, software tokens) can be used to supplement/enhance packet inspection. One advantage of this aspect includes scalability. That is, there is no need to maintain table entries or states on the fast path (also known as the fast path). Another advantage of this aspect includes low latency. That is, a single encryption operation (for example, a cryptographic hash such as SHA-1, SHA-2, or SHA-3 (where SHA stands for Secure Hash Algorithm), or Advanced Encryption Standard (AES), either can be executed Faster or can be determined as appropriate) may be sufficient for access control. In addition, the time required to perform an encryption operation on the network token should be independent of the number of application services that the P-GW can serve. Instead, loop through The time required for the packet screening program of the SDF template depends on the number of application services that the P-GW can serve; increasing the number of application services increases the number of packet screening programs. Therefore, the use of encrypted network tokens is beneficial for policy implementation and/or user-plane information redirection.

Yet another advantage may include flexibility. That is, the encrypted network token can be obtained based on various metadata. This kind of metadata is not limited to the parameters filtered by the TFT/SDF template. In addition, various policies (for example, authentication policies and/or group-based authorization) can be applied to network tokens. Yet another advantage may include resilience to distributed denial of service (DDoS) attacks. That is, any packet that includes incorrect/inappropriate/untrusted encrypted network tokens will be discarded before being sent to the server (for example, the servers 124, 126, 128, 130 in FIG. 1), thereby Prevent the server from being overwhelmed by the group. Yet another advantage may lie in the feature of relocation. The realization of this advantage can be understood by defining/mapping filter rules (or rule groups) at the first gateway device to the corresponding key, and then sharing the key with the second gateway device. Therefore, during the switching between the first gateway and the second gateway, this aspect allows the relocation of the SDF screening program through the transmission/common use of the key. This eliminates the need to send all data related to the filter rules (or rule sets) associated with a given SDF filter. Therefore, the advantage of relocation releases processing resources. For other purposes, these released processing resources can be used to transmit all data in other ways.

Figure 4 illustrates exemplary downlink operations 400 in accordance with aspects described herein. For convenience, this example is presented in the context of a long-term evolution (LTE) system. This example is not intended to impose any restrictions on the scope of protection of any aspect described herein.

Figure 4 shows equipment 402 (for example, chip assembly, client equipment, user equipment, user equipment, terminal, mobile equipment), access node 404 (for example, evolutionary node B), service gateway (S -GW) 406, P-GW 408 and PDN 410 (for example, the Internet).

The downlink operation in FIG. 4 will now be described. The downlink IP flow 414 (for example, from the application server, application, and application service resident in the PDN 410) can be applied to the decision and processing circuit/module/device 420 of the P-GW 408. The number of illustrated downlink IP flows 414 is exemplary and not intended to be limiting. The decision and processing circuit/module/device 420 can make the downlink packet received from the downlink IP flow 414 pass to the encryption-checksum traffic diversion circuit/module/device 422 or pass it to the service data flow (SDF) ) Template 424 and its packet screening program (not shown).

The downlink packet in which the DL network token is embedded or otherwise includes the DL network token can be passed to the encryption-check and traffic diversion circuit/module/device 422. In one aspect, the DL network token and application identifier (App ID) may be embedded in a single downlink packet or otherwise included in a single downlink packet. App ID can be used to determine application access policies. The application access policy can be retrieved from the application server. In some embodiments, the application server may be an application server that initiates a request for communication with the device, or the application server may be an application server that the device tries to initiate communication with; however, the third application server is also Is acceptable. In some aspects, the application access policy can be retrieved from the application function unit (AF) of the application server. In other aspects, the application access policy can be retrieved from the user profile database (SPR) associated with the policy and charging rule function server or device. slightly.

In one aspect, the application access strategy may include quality of service (QoF) parameters, which include, for example, service priority, maximum bandwidth, guaranteed bandwidth, and/or maximum delay. This information can be used by the encryption-checksum traffic diversion circuit/module/device 422 or some other circuit/module/device to select the data stream or bearer for the downlink packet associated with the DL network token.

Downlink packets in the downlink IP flow 414 that do not have DL network tokens embedded therein or which do not include network tokens in other ways can be determined and processed by the circuit/module/device 420 or other circuits/modules/ The device (not shown) is passed to the SDF template 424.

A packet screening program (not shown) can be included in the SDF template 424. The use of the packet screening program of the SDF template 424 may require more processing and memory resources than the use of the encryption-check and traffic diversion circuit/module/device 422. In order to perform filtering using the packet filter of the SDF template 424, the P-GW 408 may need to maintain a table 424a with a separate table entry for each SDF. Each table entry may require identification of multiple parameters, such as but not limited to application ID, maximum bit rate (MBR), and access point name-aggregated maximum bit rate (APN-AMBR).

The packet screening program of the SDF template 424 functions to filter the IP flow to the bearer 418 (for example, the Evolutionary Packet System (EPS) or IP-CAN bearer). For demonstration purposes, only three bearers 418 are shown. In one aspect, the bearer can be shared by multiple applications/application services. Each bearer can be associated with a unique set of parameters.

The downlink IP flow 414 can be mapped to, for example, a preset bearer or mapping Shoot to one or more dedicated bearers. The preset bearer can usually have a non-guaranteed bit rate, and the dedicated bearer can usually have a guaranteed or non-guaranteed bit rate. The bearer may go through the S-GW 406 and the access node 404. The aspects of the access node 404 and the S-GW 406 are not described here, and are known to those with ordinary knowledge in the field of the present invention.

Data flow

In the aspect described herein, the IP stream, data stream, or stream need not be limited to the bearer as shown in the exemplary illustration of FIG. 2. The client device can operate or execute one or more applications. Each client application can be mapped to an application service that operates or executes on the application server. The application server may be associated with one or more application services. Therefore, the flow can be defined based on the application operating in the device and operating on the application server. The flow can be defined as the path taken by the packet between the application executed at the client device and the application service executed at the application server. Although the flow can be associated with an application operating on the client device, the flow need not identify the client device. Network tokens can be used to identify one or more streams. Therefore, network tokens can be associated with multiple streams.

A stream can be mapped to multiple services running on the same server in the network. For example, the client device can use a service provided by a provider on the server. The server usually has an IP address. However, the service can host multiple applications on the server. These multiple applications may include, for example, mapping applications, information search applications, and social networking applications. These multiple applications therefore have the same destination IP address. Therefore, from the perspective of the gateway (for example, P-GW) of the core network, the multiple applications can be regarded as a single stream instead of multiple streams. Therefore, a single stream can be mapped to multiple services.

A stream can be associated with multiple services. In addition, network tokens can be associated with multiple services, and multiple application service providers can perform these services. For example, the client device may have multiple sponsors (e.g., multiple service providers). In the aspect described in this article, the gateway device can obtain network tokens associated with multiple application service providers. Therefore, a single token can be mapped to one or more application services, which in turn are associated with one or more flows.

In the several examples provided in this article, the network token can be obtained based on the application identifier (App ID). However, the acquisition of network tokens is not limited to these examples. Other parameters and/or combinations of parameters can be used to obtain network tokens. App ID can be associated with one or more servers. For example, a given service provider may have different data centers in different geographic locations (each data center has its own server). In such cases, the App ID will be associated with more than one server. The token can beneficially use the App ID instead of the server IP address. The gateway device can verify that the packet associated with the network token is heading to the server of a given service provider, even if the network token does not specify the IP address of the destination server.

Symbol setting and use-exemplary system-level dialing process

The examples described in this article can be applied to the initial PDN connection request procedure (a preset bearer can be set during this period) and a dedicated bearer setup procedure (one or more dedicated bearers can be set up during this period).

FIG. 5 is an exemplary dialing process 500 for obtaining, providing, and using network tokens combined with one or more user plane messages according to the aspect described herein. As mentioned, the dialing process can be implemented in the user plane. picture 5 Including equipment 502 (for example, chip components, client equipment), access node 504 (for example, eNB), MME 506, S-GW 508, P-GW 510, policy and charging rules function (PCRF) 512 equipment, attribution Representation of user server (HSS) 514 and application server 515.

In the exemplary dialing process of FIG. 5, the device 502 may send 518 a connection request to the application server 516. The connection request may include an identifier, such as an application identifier (App ID). The connection request can convert the core network to the P-GW 510. The P-GW 510 may be a gateway for policy enforcement. The P-GW 510 can also be used to detect explicit or implicit requests for network tokens.

According to one aspect, the access node 504 (e.g., evolutionary node B) may be agnostic. That is, the access node 504 may not know that the device has sent a connection request to the application server 516 in the user plane, where the connection request explicitly includes a request for a network token or represents a request for a network token. Implicit request. According to this aspect, the exchange of requests and network tokens can be transparent to the unknowable access node 504.

A decision is made at the P-GW 510 as to whether the packet including the connection request sent from the device includes an explicit request for the network token or indicates an implicit request for the network token. If the decision concludes that there is a need for the network token, the P-GW 510 can perform actions including the following operations: obtain the information required to obtain the network token; obtain the network token; and use The packet including the connection request from the device 502 to embed/include the network token. As used herein, the term "obtained" can mean to obtain locally or from another device.

According to one aspect, the P-GW 510 may be based on the data associated with the packet Enter the hash of the parameter to get the 522 network token. In such a situation, it may not be necessary to obtain additional information related to the packet. If additional information is needed, the P-GW 510 can obtain 520 the profile of the device 502 from the PCRF 512. The PCRF 512 may obtain the customized profile of the device from a customized profile library (SPR) coupled with the PCRF 512. Other ways of obtaining the profile of the device 502 may be acceptable.

P-GW 510 can obtain 522 network tokens. According to one aspect, the network token can be obtained based on the hash of the input parameters associated with the packet. According to one aspect, the network token can be obtained based on information associated with the connection request and/or the device profile. According to an example, the network token can be obtained as follows: network token=CI|HMAC(K_P-GW,CI|IP_C|IP_S|P_C|P_S|Proto|App ID|...), where: CI is the class index that defines the field used for token acquisition, HMAC is the keyed hash message authentication code, K_P-GWIs the key of P-GW, IP_CIs the IP address of the client (for example, device), P_CIs the client port number, IP_SIs the IP address of the server (for example, the destination or application server), P_SIs the server port number, Proto is the protocol number or identifier, and App ID is the application identifier. Additional or alternative parameters may include priority order and/or quality of service category identifier (QCI). Other formulas for obtaining network tokens may be acceptable.

The P-GW 510 can embed/include 524 network tokens by using the packet including the connection request. The P-GW may then send 526 a connection request including the network token obtained by the P-GW 510 to the application server 516. The connection request may include an application identifier (App ID).

Application server 516 can then send 528 connection back to device 502 answer. The connection response may include network tokens. Thereafter, the device 502 may utilize one or more uplink data packets configured for data transmission to the application server 516 to include the network token. In some aspects, the device 502 may use each uplink data packet destined to the application server 516 to include the network token.

Regarding implementation, the device 502 may send 530 uplink data packets to the application server 516. Uplink data packets can include network tokens. Uplink data packets including network tokens can convert the core network to P-GW 510. As mentioned, P-GW 510 may be a gateway for policy enforcement.

When the P-GW 510 receives the uplink data packet sent from the device 502, the P-GW 510 can verify 532 the network token included in the uplink data packet. According to one aspect, verification can be achieved by retrieving the token (ie, obtaining a copy of the verification token or the original network token) and combining the retrieved token with the one embedded in the uplink data packet Network tokens are compared. If the verification is successful, the P-GW 510 can discard the embedded network token and can send 534 the uplink data packet to the application server 516. If the verification is unsuccessful, the P-GW can discard the uplink data packet and the embedded network token.

The key known by the P-GW 510 can be used in the encryption function to obtain the original network token and the check token (for example, a copy of the original network token). In one example, the P-GW 510 may obtain the network token according to the application access policy retrieved from the application function unit (AF). In one aspect, the access policy can associate the flow with the application. Network token can also be based on App ID Obtain, for example, if the App ID is included in the request for the network token. In some scenarios, the network token can include encrypted information. The decryption can be achieved by using an encryption function that makes the key known to the P-GW 510 as its input in one example. By way of example, the successful decryption of the network token can obtain a value, which can be associated with the UL packet including the network token to indicate the destination address or the destination address prefix of the server and/or application service , And/or the source address of the client device and/or access node from which the UL packet originated. In one aspect, the ability to obtain, for example, the destination address or destination address prefix of the server and/or application service from the network token may mean that the packet associated with the token is authorized to be sent to the destination , And can also mean that the SDF template (and its associated packet screening program) is not required. Therefore, packet inspection can be avoided.

The aspect of using the user plane as described herein can be equally well applied to the uplink direction and the downlink direction.

FIG. 6 illustrates an exemplary dialing process 600 for obtaining, providing, and using network tokens combined with one or more user plane messages according to the aspect described herein. As mentioned, the dialing process can be implemented in the user plane. Figure 6 includes equipment 602 (for example, chip component, client equipment), access node 604 (for example, eNB), MME 606, S-GW 608, P-GW 610, policy and charging rules function (PCRF) 612 equipment, Representation of Home Subscriber Server (HSS) 614 and Application Server 616. According to the exemplary dialing process 600, the downlink (DL) network token can be issued to the application server 616 via the P-GW 610 via the implicit or explicit request of the device 602 to use the DL network token.

In the exemplary dialing procedure of FIG. 6, the device 602 passes through the P-GW 610 Send 618 a request for initiating an application service with the application server 616. The request may be accompanied by or may include an application identifier (App ID). As those with ordinary knowledge in the field to which the present invention pertains will understand, the request provided from the device 602 to the application server 616 is different from any type of connection request used to establish or re-establish a connection between the device and the network. Should be confused with it. In the former case, the device is requesting service from the application server (the service can even be a connectionless service), while in the latter case, the device is requesting a connection to the network.

In one aspect, the request for initiating an application service represents an implicit request to use a downlink (DL) network token. The implicit request to use the downlink network token can be identified by sending the initial packet from the device 702 to the application server 716 via the P-GW 710. In one example, the implicit request may be triggered by the service provider's policy, which requires the packet from the application server to carry the DL network token. The identification of this type of policy can be obtained, for example, by performing group inspection on the packets provided by the service by the P-GW and determining that the service requires a DL network token to implement a predefined network policy. Other ways to indicate implicit requests to use downlink network tokens are acceptable.

In one aspect, the request for initiating the application service may include an explicit request to use the DL network token in the transmission from the application server to the device. In one aspect, the explicit request may be included in the first packet sent to the application server 716; however, this is not a requirement.

The use of DL network tokens can occur when the application service is initialized or when the application service is modified.

In one aspect, in response to receiving an explicit or implicit request to use the DL network token, the P-GW 610 may obtain 620 the device profile from the PCRF 612. P-GW 610 can use the following formula as an example to obtain 622 DL network token: DL network token=KeyID|CI|policy ID|H(KP-GW, policy ID|IPS|IPC|PS|PC |Proto|App ID|...), where: KeyID is the identifier (that is, K_P-GW), CI is the class index that defines the field used to obtain the token or the input parameter list used to obtain the token, and the policy ID is the policy identifier that defines the flow processing strategy (for example, QoS policy, which maps the flow to the bearer, As well as other aspects of stream processing strategies understood by those with ordinary knowledge in the field of the present invention), H is a secure hash function (or, hash message authentication code (HMAC) can be used), K_P-GWIs the key of P-GW, IP_CIs the IP address of the client (for example, device), P_CIs the client port number, IP_SIs the server IP address, P_SIs the server port number, Proto is the protocol number, and App ID is the application identifier. The policy ID included in the downlink token can be used to map the downlink packet to a given bearer. Alternatively, it is possible to use KeyID for the policy ID; in this case, the policy ID value may not be required when calculating the DL network token.

Once obtained, the DL network token can be embedded 624 in the packet or otherwise included in the packet that has a request for initiating application services.

Optionally, the P-GW 610 can obtain 626 a connection identifier (connection ID or Conn ID), which can be used to identify the connection initiated by the device. In one aspect, the connection ID can be obtained as follows: Connection ID=KeyID|CI|HMAC(K'_P-GW,IP_S|IP_C|P_S|P_C|Proto). Where: K'_P-GWIt may be a key that is known to the P-GW and is different from the key used to obtain the DL network token. The connection ID can be stored 628 in the cache memory in the P-GW 610.

The request for initiating an application service including the embedded/included DL network token obtained by the P-GW 610 may be sent 630 to the application server 616. The request for initiating an application service may include an application identifier (App ID), a DL network token, and a connection ID (if obtained).

The application server 616 may send 632 the application service response including the DL network token (for example, a copy of the DL network token) and the connection ID (if obtained) to the device 602 via the P-GW 610.

When P-GW 610 receives a packet with a DL network token embedded in it, P-GW 610 can verify 634 the DL network token, for example, by using the combination with the above to obtain the original network token. The same formula obtains the token from the data contained in the packet. That is, the P-GW 610 can use the data from the packet received from the application server 616 instead of using the data received from the device 602 to retrieve the original DL network token. As those skilled in the art of the present invention will understand, not all the data in the packet received from the device 602 will be the same as the data in the packet received from the application server 616. However, as will also be understood by those with ordinary knowledge in the art to which the present invention pertains, in one aspect, public data included in both the packet received from the device 602 and the packet received from the application server 616 can be used Re-obtain the original DL network token (also referred to as the check token in this article). Combine the original DL as above As described in the exemplary acquisition of network tokens, such public information can include CI, IP_S, IP_C, P_S, P_C, Proto and/or App ID. This list is meant to be an example, not a limitation.

In such an aspect, the verification can be completed by comparing the retrieved DL network token with the DL network token embedded in the packet received from the application server 616.

If the verification is successful, the application service response from the application server 616 can be sent 636 to the device 602. In one aspect, the P-GW 610 can use the response to embed the DL network token, or cause the DL network token to be embedded or otherwise attached. In another aspect, the P-GW 610 may discard the DL network token (not shown) before the response is sent 636 to the device 602. If the verification is unsuccessful, the P-GW 610 may discard the response (not shown).

Thereafter, the application server 616 can embed/include a copy of the DL network token in one or more packets sent from the application server 616 to the device 602 via the P-GW 610 (which communicates with the obtained DL network token) The communication period is related). In some aspects, the application server 616 may embed/include a copy of the DL network token in each packet sent from the application server 616 to the device 602 via the P-GW 610 (which is related to the acquisition of the DL network token). Related to the communication period).

FIG. 7 is an exemplary dialing flowchart 700 illustrating the acquisition, provision, and use of network tokens combined with one or more user plane messages according to the aspect described herein. As mentioned, the dialing process can be implemented in the user plane. Figure 7 includes equipment 702 (for example, chip component, client equipment), access node 704 (for example, eNB), MME 706, S-GW 708, P-GW 710, policy and charging rules function (PCRF) 712 equipment, Home user server Server (HSS) 714 and application server 716. According to the exemplary dialing flowchart 700, the downlink (DL) network token can be issued to the application server 716 via the implicit or explicit request to use the DL network token via the P-GW 710 Application server 716.

In the exemplary dialing process of FIG. 7, the application server 716 sends 718 via the P-GW 710 a request for initiating an application service with the device 720. The request may be accompanied by or may include an application identifier (App ID). As those with ordinary knowledge in the field of the present invention will understand, the request provided from the application server 716 to the device 702 is different from any type of connection request used to establish or re-establish a connection between the application server and the network. And should not be confused with it. In the former case, the application server is requesting to provide the application service to the device (the service can be a connectionless service), while in the latter case, the application server is requesting a connection to the network.

In one aspect, the request for initiating an application service represents an implicit request to use a downlink (DL) network token. The implicit request to use the downlink token can be recognized by sending the initial packet from the application server 716 to the device 702 via the P-GW 710. In one example, the implicit request may be triggered by the service provider's policy, which requires the packet from the application server to carry the DL network token. The identification of such a strategy can be obtained, for example, by performing packet inspection on the packets provided by the service by the P-GW and determining that the service requires a DL network token to implement a predefined network strategy. Other ways to indicate implicit requests to use downlink network tokens are acceptable.

In one aspect, the request for initiating the application service can be from The transmission from the application server to the device includes an explicit request to use the DL network token. In one aspect, the explicit request may be included in the first packet sent to the device 702; however, this is not a requirement.

The use of DL network tokens can occur when the application service is initialized or when the application service is modified.

In one aspect, in response to receiving an explicit or implicit request to use the DL network token, the P-GW 710 can obtain the 720 device profile from the PCRF 712. P-GW 710 can use the following formula as an example to obtain 722 DL network token: DL network token=KeyID|CI|Policy ID|H(K_P-GW, Policy ID|IP_S|IP_C|P_S|P_C|Proto|App ID|...), where: KeyID is the identifier for the key obtained by token (that is, K_P-GW), CI is the class index that defines the field used to obtain the token or the input parameter list used to obtain the token, and the policy ID is the policy identifier that defines the flow processing strategy (for example, QoS policy, which maps the flow to the bearer, As well as other aspects of stream processing strategies understood by those with ordinary knowledge in the field of the present invention), H is a secure hash function (or, hash message authentication code (HMAC) can be used), K_P-GWIs the key of P-GW, IP_CIs the IP address of the client (for example, device), P_CIs the client port number, IP_SIs the server IP address, P_SIs the server port number, Proto is the protocol number, and App ID is the application identifier. The policy ID included in the downlink token can be used to map the downlink packet to a given bearer. Alternatively, it is possible to use KeyID for the policy ID; in this case, the policy ID value may not be required when calculating the DL network token.

Once obtained, the DL network token can be embedded 724 into the packet or In other ways, it is included in a package that has a request for initiating an application service.

Optionally, the P-GW 710 can obtain 726 a connection identifier (connection ID or Conn ID), which can be used to identify the connection initiated by the server. In one aspect, the connection ID can be obtained as follows: connection ID=KeyID|CI|HMAC(K'_P-GW,IP_S|IP_C|P_S|P_C|Proto) where: K'_P-GWIt may be a key that is known to the P-GW and is different from the key used to obtain the DL network token. The connection ID can be stored 728 in the cache memory in the P-GW 710.

A request for initiating an application service including the embedded/included DL network token obtained by the P-GW 710 may be sent 720 to the device 702. The request for initiating an application service may include an application identifier (App ID), a DL network token, and a connection ID (if obtained).

When the device 702 receives a request for initiating an application service including an embedded DL network token, the device 702 can verify 732 the request. Optionally, the device 702 may issue 733 another token for authentication.

The device 702 can grant the DL network token to the application server 716 by sending 734 the application service response including the DL network token to the application server 716 via the P-GW 710. The device 702 may embed or otherwise include the DL network token in the application service response. If the connection ID is sent to the device 702, the device 702 may also embed or include the connection ID in the application service response in other ways.

If the connection ID is obtained 726 and stored 728, when the P-GW 710 receives from the device 702, the connection ID and DL are embedded or otherwise attached. In the case of a packet with a network symbol, the P-GW 710 can verify 736 the connection ID. In one aspect, because the DL network token is used to check and map packets along the downlink direction, the P-GW 710 may not check the DL network token at this time; however, as mentioned, The P-GW 710 can verify 736 the connection ID.

The verification of the connection ID can be completed, for example, by using the same formula as described above in connection with obtaining the original connection ID to retrieve the original connection ID from the data contained in the packet. That is, the P-GW 710 can use the data from the packet received from the device 702 instead of using the data received from the application server 716 to retrieve the original connection ID. As those with ordinary knowledge in the field of the present invention will understand, not all the data in the packet received from the device 702 will be the same as the data in the packet received from the application server 716. However, as will be understood by those with ordinary knowledge in the field of the present invention, in one aspect, only the public data included in both the packet received from the device 702 and the packet received from the application server 716 are included. It will be used to retrieve the original connection ID (also referred to as the second connection ID or check connection ID in this article). As described above in conjunction with the exemplary acquisition of the original connection ID, such public information may include CI, IP_C, IP_S, P_C, P_SAnd/or Proto. This list is exemplary, not limiting. In such an aspect, the verification can be completed by comparing the re-acquired connection ID with the connection ID embedded in the packet received from the device 702.

If the verification is successful, or if the optional step of verifying the connection ID is not performed, the application service response from the device 702 can be sent 738 to the application server 716. In one aspect, the P-GW 710 can use the application service response to embed the DL network token, so that the DL network token is embedded, or attached in other ways write. In this way, the application server 716 is provided with the DL network token. If the optional verification of the connection ID is unsuccessful, the P-GW 710 may discard the application service response (not shown).

Thereafter, the application server 716 can embed a copy of the DL network token into each packet sent 740 from the application server 716 to the device 702 via the P-GW 710 (which is related to the communication period for obtaining the DL network token). related). The P-GW 710 can use the DL network token to verify 742 data packets. If the verification is successful, the P-GW 710 can send 744 the data packet to the device 702. If the verification is unsuccessful, the P-GW 710 can discard (not shown) the data packet.

FIG. 8 is a diagram illustrating two network tokens (for example, uplink network token and downlink network token) combined with one or more user plane messages according to the aspect described herein Exemplary dialing process 800 for obtaining, providing, and using of. The dialing process 800 of FIG. 8 can be implemented in the user plane. The following explanation is related to the acquisition, provision, and implementation of both the uplink token and the downlink token.

Figure 8 includes equipment 802 (for example, chip component, client equipment), access node 804 (for example, eNB), MME 806, S-GW 808, P-GW 810, policy and charging rules function (PCRF) 812 equipment, Representation of Home Subscriber Server (HSS) 814 and Application Server 816.

In the exemplary dialing process of FIG. 8, the device 802 may send 818 a connection request to the application server 816. The connection request may include an identifier, such as an application identifier (App ID). The connection request can convert the core network to P-GW 810. P-GW 810 may be a gateway for policy enforcement. P-GW 810 can also be used to detect explicit or implicit requests for network tokens.

According to one aspect, the access node 804 (e.g., evolutionary node B) may be agnostic. That is, the access node 804 may not know that the device has sent a connection request to the application server 816 in the user plane, where the connection request explicitly includes a request for a network token or represents a request for a network token. Implicit request. According to this aspect, the exchange of requests and network tokens can be transparent to the unknowable access node 804.

A decision may be made at the P-GW 810 as to whether the packet including the connection request sent from the device includes an explicit request for the network token or represents an implicit request for the network token. If the decision concludes that there is a need for network tokens, the P-GW 810 can perform actions including the following operations: obtain the information required for obtaining UL network tokens and DL network tokens; obtain UL network token and DL network token; and using the packet including the connection request from the device 820 to embed/include the UL network token and DL network token. As used herein, the term "obtained" can mean to obtain locally or from another device.

According to one aspect, the P-GW 810 can obtain the 822 UL network token based on the hash of the input parameters associated with the packet. In this type of situation, it may not be necessary to obtain additional information related to the packet. According to one aspect, if additional information is needed, the P-GW 810 can obtain the profile of the 820 device 802 from the PCRF 812. The PCRF 812 may obtain the subscription profile of the device from a subscription profile library (SPR) coupled with the PCRF 812. Other ways of obtaining the profile of the device 802 may be acceptable. In a similar way, P-GW 810 can obtain 823 DL network tokens.

The P-GW 810 can use the packet including the connection request to embed/ Including 824 UL network symbol and DL network symbol. The P-GW 810 may then send 826 a connection request including the UL network token and the DL network token obtained by the P-GW 810 to the application server 816. The connection request may include an application identifier (App ID).

The application server 816 can then send 828 a connection response to the device 802 via the P-GW 810. The connection response may include the UL network token, and may also include the DL network token. If the DL network token is included in the connection response, the P-GW 810 can verify 830 the DL network token included in the connection response. According to one aspect, it is possible to obtain a copy of the original DL network token (that is, to obtain the DL check token) and to re-obtain the original DL token and embed/include the DL network token in the connection response Remember to compare for verification. If the verification is successful, the P-GW 810 can discard the DL network token and send 832 the connection response together with the UL network token to the device 802. If the verification is unsuccessful, the P-GW 810 may discard the connection request and the embedded/included DL network token and UL network token. Thereafter, the device 802 may utilize one or more uplink data packets configured for data transmission to the application server 816 to include the 834 UL network token. In some aspects, the device 802 may use each uplink data packet destined to the application server 816 to include 834 network tokens.

The application server 816 may retain the DL network token (for example, a copy of the DL network token). Thereafter, the application server 816 may send 840 the DL network token along with one or more downlink data packets configured for data transmission to the device 802. In some aspects, the application server 816 may utilize every downlink data packet destined for the device 802 to include the DL network token.

Regarding the implementation in the uplink direction, the device 802 may send 834 uplink data packets to the application server 816 via the P-GW 810. Uplink data packets may include UL network tokens. The uplink data packet including the UL network token can convert the core network to the P-GW 810. As mentioned, P-GW 810 may be a gateway for policy enforcement.

When the P-GW 810 receives the UL data packet sent from the device 802, the P-GW 810 can verify 836 the UL network token included in the uplink data packet. According to one aspect, calibration can be performed by reacquiring the token (that is, obtaining the UL verification network token) and comparing the reacquired token with the network token embedded in the uplink data packet. Test. If the verification is successful, the P-GW 810 can discard the embedded network token and can send 838 the uplink data packet to the application server 816. If the verification is unsuccessful, the P-GW can discard the uplink data packet and the embedded UL network token.

Regarding implementation in the downlink direction, the application server 816 can send 840 a downlink data packet to the device 802 via the P-GW 810. The downlink data packet may include a device ID to indicate the device to which the packet is directed. Downlink data packets can include DL network tokens. The DL network token may have been obtained from the device 802 explicitly or implicitly by the P-GW 810 in response to a request to use the received downlink token. The P-GW 810 may have provided the DL network token to the application server 816 in the user plane. The P-GW 810 can verify 842 the DL network token included in the downlink data packet. According to one aspect, it is possible to obtain a copy of the original DL network token (that is, to obtain the DL check token) and to combine the retrieved original DL token with the DL network embedded in the downlink data packet Symbols are compared for verification. If the verification is successful, The P-GW 810 can discard the embedded DL network token and send 844 the downlink data packet to the device 802. If the verification is unsuccessful, the P-GW can discard the downlink data packet and the embedded DL network token.

In this aspect, the P-GW 810 may be able to efficiently direct the IP flow in the downlink direction and in the uplink direction. Because the P-GW 810 obtains the original DL network token, the P-GW 810 may be able to verify the DL network token received using the packet from the application server 816. This is a useful and efficient alternative to downlink packet inspection using TFT/SDF.

For example, the key known by the P-GW 810 can be used in the encryption function to obtain the original DL network token and verify the DL network token. In one example, the P-GW 810 may obtain the network token according to the application access policy retrieved from the application function unit (AF). In one aspect, the access policy can associate the flow with the application. The network token can also be obtained based on the App ID or Device ID. In some aspects, the DL network token may include encrypted information. The decryption can be realized by using an encryption function that makes the key known by the P-GW 810 as its input in one example. By way of example, the successful decryption of the DL network token can obtain a value that can be associated with the DL packet including the DL network token to indicate the device and/or access node that is the destination of the DL packet Destination address or destination address prefix. In one aspect, the ability to obtain, for example, the device address from the DL network token can mean that the packet associated with the DL network token is authorized to be sent to the destination, and can also mean that no packet inspection is required . Therefore, packet inspection can be avoided.

Network tokens, that is, both DL network tokens and UL network tokens, can be valid only under certain conditions. For example, in some aspects, the network token It can change periodically. In another aspect, the network token may suffer expiration based on the predetermined time since the network token is obtained. The network token may no longer be valid when the predetermined time expires. In some aspects, based on the key used to obtain the network token (K_P-GW) Restrictions imposed by the network token may be subject to expiration. For example, the key used to obtain the network token can be replaced by a new key (K''_P-GW) Instead. Existing key (e.g. K'_P-GW) With a new and different key (for example, K''_P-GWThe replacement of) may be caused by, for example, the expiration of the predetermined time of the existing key, the key identifier, or some other event. When the existing network token is determined to be no longer valid, or when it is no longer expected to be used as a network token, the P-GW can obtain a new network token to replace the currently used network token.

The decision to obtain a new network token may depend on, for example, the P-GW. However, the decision can be made by other entities. For example, in one aspect, the device may decide that a new network token is needed. In another aspect, the application server can determine that a new network token is needed. In some aspects, an entity different from the entity that initiated the use of the network token can initiate the use of a new network token, even if the currently used network token is valid. In any aspect, as described in this article, the new network token settings can be performed first. Those with ordinary knowledge in the field of the present invention will understand that at least one parameter (among the multiple parameters used to obtain the network token) may be required to be changed to prevent the new network token from being the same as the existing network token .

In one aspect, obtaining the network token may include verifying the application identifier (App ID) and the application access policy associated with the device. The App ID can be included in a previously received packet, where the previously received packet is used to obtain the network token. App ID can be used to determine application access policies. answer The access policy can be retrieved from the application server. In one aspect, the application access policy can be retrieved from the application function unit (AF) of the application server. In another aspect, the application access policy can be retrieved from the user profile database (SPR) in the application server. In one aspect, the application access policy may include quality of service (QoS) parameters, which include service priority, maximum bandwidth, guaranteed bandwidth, and/or maximum delay.

Symbol usage/implementation-exemplary system-level protocol stacking

Now presents the state of use and implementation in combination with the above-mentioned network tokens.

The use of network tokens can be described by referring to the movement of network tokens in the user plane protocol stack of client devices, access nodes, gateway devices, and application servers. Illustrated here are two diagrams illustrating an exemplary set of stacks of user plane agreements. Each diagram is different from the next diagram in the description of the network token movement in the protocol stack. The many layers represented in the protocol stack and the interconnections among the layers are well known. These layers will be briefly described with reference to the illustration of FIG. 5. For each exemplary figure, their description will not be repeated to avoid repetition and improve the conciseness of the case. One of these figures includes a cushion layer, which can be viewed as a layer for network token movement in combination with the corresponding aspect illustrated therein.

FIG. 9 is an exemplary illustration of a user plane agreement stack 900 of the system according to one aspect described herein. FIG. 9 illustrates a client device 902, an access node 904, a gateway device 906, and an application server 908. In the exemplary illustration of FIG. 9, the protocol stack of the client device 902 from the lowest layer up may include: a physical (PHY) layer 910, a medium access control (MAC) layer 912, and a radio Link Control (RLC) layer 914, Packet Data Convergence Protocol (PDCP) layer 916, and Internet Protocol (IP) layer 918. In one aspect, the network token may be carried in the IP extension header defined in Internet Protocol (IP) version 6 (IPv6).

In one aspect, the cushion layer 920 may be added to the user plane protocol stack of the client device 902, and the corresponding cushion layer 922 may be added to the protocol stack of the gateway device 906. According to the aspect described herein, the cushion 920 and the corresponding cushion 922 facilitate the movement of the network token from the client device 902 to the gateway device 906. In one aspect, the underlayer 920 is located below the IP layer 918 of the client device 902 and above the MAC layer 912. In this aspect, the corresponding underlayer 922 is located below the IP layer 924 of the gateway device 906 and above the General Packet Radio Service (GPRS) Tunneling Protocol (GTP) layer (GTP-U) for the user plane . As known to those with ordinary knowledge in the field of the present invention, GPT-U provides a service for carrying user data packets in a GPRS backbone network.

The aspect shown in FIG. 9 can facilitate the movement of the network token 960 from the client device 902 to the gateway device 906 without the access node 904 for any processing. Alternative methods are acceptable. By way of example, as described above, the client device 902 may receive the network token 960 from the application server 908 via user plane messaging. According to one aspect of the use of the network token, the client device 902 may include the network token in the packet destined to the application server 908. As shown in FIG. 9, the network token 960 may be carried in the cushion header of the cushion 920 to the gateway device 906. The network token 960 can be carried in the underlay header separate from the IP header.

If the verification of the network token at the gateway device 906 is successful, the gateway device 906 may forward the packet to the application server 908 after discarding the network token. If the verification of the network token 960 at the gateway device 906 is unsuccessful, the gateway device 906 can discard the packet and the network token. According to the aspect shown, no changes are required at the application server 908 to support application access based on network tokens.

For complete description, the layers of the user plane protocol stack of the access node 904, the gateway device 906, and the application server 908 will now be briefly described. In the exemplary illustration of FIG. 9, the protocol stack of the access node 904 may include a physical (PHY) layer 930, a medium access control (MAC) layer 932, a radio link control (RLC) layer 934, and Packet Data Convergence Protocol (PDCP) layers 936, which are associated with similarly named layers (910, 912, 914, and 916) of the client device 902, respectively. In the exemplary illustration of FIG. 9, the protocol stack of the access node 904 may additionally include from the lowest layer upwards: Ethernet layer 940, MAC layer 942, IP layer 944, and user data packet protocol (UDP) Layer 946 and GTP-U layer 948. These respective layers are combined with similarly named layers of the gateway device 906 (1250, 952, 954, 956, and 926). In the exemplary illustration of FIG. 9, the client device IP layer 918 is combined with the IP layer 924 of the gateway device 906, and the IP layer 924 of the gateway device 906 is combined with the IP layer 958 of the application server 908.

FIG. 10 is an exemplary diagram of a user plane agreement stack 1000 according to another aspect of the system described herein. FIG. 10 illustrates a client device 1002, an access node 1004, a gateway device 1006, and an application server 1008.

The aspect shown in FIG. 10 can facilitate the movement of the network token 1060 from the client device 1002 to the gateway device 1006 via the access node 1004. In this aspect, no underlayer is required. By way of example, as described above, the customer The client device 1002 can receive the network token 1060 from the application server 1008 via user plane messaging. According to one aspect of the use of the network token, the client device 1002 may include the network token 1060 in the packet whose destination is the application server 1008. The packet including the network token 1060 may be carried in the PDCP layer 1016 header of the PDCP layer 1036 from the user client device 1002 to the access node 1004. The access node 1004 can copy the network token found in the PDCP header to the GTP-U header. The packet including the network token 1060 can then be carried in the GTP-U layer 1048 from the access node 1004 to the GTP-U layer 1026 of the gateway device 1006. That is, in one aspect, the network token can be carried in the General Packet Radio Service (GPRS) Tunneling Protocol (GTP) header. In an exemplary aspect, the network token originally sent from the application server 1008 to the client device 1002 may have been created at the gateway device 1006 using a key known by the gateway device. In such a situation, the access node 1004 will not be able to verify the network token (because it does not have the key required for verification). Therefore, the exemplary use of the access node 1004 shown in FIG. 10 is to copy network tokens from one header to another, thereby passing through the existing PDCP layer 1036 header and GTP-U layer 1048 header The network token is forwarded from the client device 1002 to the gateway device 1006. Once the network token reaches the gateway device, if the verification of the network token at the gateway device 1006 is successful, the gateway device 1006 can forward the packet to the application server 1008 after discarding the network token. If the verification of the network token 1060 at the gateway device 1006 is unsuccessful, the gateway device 1006 can discard the packet and the network token. According to the aspect shown, no changes are required at the application server 1008 to support token-based application access.

Client device 1002 not described in Figure 10, access node 1004, the layers of the user plane protocol stack of the gateway device 1006 and the application server 1008 will not be described again, because their descriptions are the same as or similar to the descriptions of the similarly named layers in FIG. 9.

FIG. 11 is an exemplary diagram of a user plane agreement stack 1100 according to another aspect of the system described herein. The user plane protocol stack 1100 of FIG. 11 uses IP headers for token embedding and transmission. FIG. 11 illustrates a client device 1102, an access node 1104, a gateway device 1106, and an application server 1108. In the exemplary illustration of FIG. 11, the protocol stack of the client device 1102 may include a physical (PHY) layer 1110, a medium access control (MAC) layer 1112, a radio link control (RLC) layer 1114, from the lowest layer upwards. Packet Data Convergence Protocol (PDCP) layer 1116 and Internet Protocol (IP) layer 1118.

In one aspect, the header of the IP layer 1118 can facilitate the movement of the network tokens according to the aspect described herein between the client device 1102, the gateway device 1106, and the application server 1108. Both IPv4 and IPv6 can adopt the aspect described in this article.

The aspect shown in FIG. 11 can facilitate the movement of the downlink network token 1160 between the gateway device 1106 and the client device 1102 without the access node 1104 for any processing. By way of example, during the implementation operation, the client device 1102 may receive the downlink network token 1160 from the application server 1108 via the network device 1106 in one or more user plane messages. According to one aspect of the use of the downlink network token, the application server 1108 may include a copy of the given downlink network token in the packet destined for the client device 1102. As shown in Figure 11, the IP headers in the IP layers 1118, 1124, and 1158 can be (for example, embedded in the downlink packet) downlink The road network symbol 1160 is carried to the gateway device 1106. If the verification of the downlink network token at the gateway device 1106 is successful, the gateway device 1106 can forward the packet to the client device 1102. Before forwarding the packet including the verified downlink network token, the gateway device 1106 may or may not discard the network token. If the verification of the downlink network token 1160 at the gateway device 1106 is unsuccessful, the gateway device 1106 can discard the packet and the network token. According to the illustrated aspect, there is no need to make changes at the application server 1108 to support the DL token-based policy enforcement agreement.

Regarding the delivery of the packet including the DL token, in one aspect, the DL token may be embedded in an IP header, such as an IP version 4 (IPv4) header or an IP version 6 (IPv6) header. The IP header in IPv4 can be an IPv4 option field. Regarding the IP option field, in order to use the exemplary IPv4 option field, a new option number may need to be defined in the Internet Engineering Task Force (IETF). The IP header in IPv6 may be an IP extension header. Regarding the IP extension header, in order to use the exemplary IPv6 extension header, a code such as the next header code needs to be defined in the Internet Engineering Task Force (IETE). In one aspect, the DL token can be embedded in the Transmission Control Protocol (TCP) header. The DL symbol can be embedded in the option field of the TCP header. In one aspect, the DL token can be embedded in the Transport Layer Security (TLS) record header. Regarding TLS records, for an exemplary TLS record protocol, a new record type may need to be defined in the Internet Engineering Task Force (IETE). In one aspect, the DL token can be embedded in the underlying header between the IP header and the Transmission Control Protocol/User Datagram Protocol (TCP/UDP) header. In another aspect, the DL token can be embedded in the Hypertext Transfer Protocol (HTTP) header. HTTP headers can be HTTP trials ( eXperimental) or extension (eXtension) header. HTTP test or extension headers can use X tags for insecure HTTP connections.

The protocol stack layers of the client device 1102, the access node 1104, the gateway device 1106, and the application server 1108 described in conjunction with FIG. 11 will not be described again, because their descriptions are similarly named as those in FIG. 9 The layers are the same or similar.

FIG. 12 is an exemplary illustration of a user plane agreement stack 1200 of the system according to the aspect described herein. In the user plane protocol stack 1200 of FIG. 12, cushion layers 1220, 1222, 1223 are added for network token transmission. FIG. 12 illustrates a client device 1202, an access node 1204, a gateway device 1206, and an application server 1208.

The aspect shown in FIG. 12 can facilitate the movement of the downlink network token 1260 from the application server 1208 to the client device 1202 via the gateway device 1206. In some aspects, the downlink network token may be transmitted from the application server 1208 to the gateway device 1206, but not to the client device 1202. By way of example, the application server 1208 may receive the downlink network token 1260 from the gateway device 1206 via user plane messaging.

In the exemplary illustration of FIG. 12, the protocol stack of the client device 1202 may include a physical (PHY) layer 1210, a medium access control (MAC) layer 1212, a radio link control (RLC) layer 1214, Packet Data Convergence Protocol (PDCP) layer 1216, Internet Protocol (IP) layer 1218 and underlayer 1220.

In one aspect, the cushion layer 1220 can be added to the protocol stack of the client device 1202, and the corresponding cushion layer 1222 can be added to the gateway device In the protocol stack of 1206, another corresponding underlayer 1223 can be added to the protocol stack of the application server 1208. The cushion layer 1220, the corresponding cushion layer 1222, and the corresponding cushion layer 1223 can facilitate the movement of the network token according to the aspect described herein between the client device 1202, the gateway device 1206, and the application server 1208. In one aspect, the cushion layer 1220 is located above the IP layer 1218 of the client device 1202. In this aspect, the corresponding cushion layer 1222 is located above the IP layer 1224 of the gateway device 1206, and the corresponding cushion layer 1223 is located above the IP layer 1258 of the application server 1208.

The solution shown in FIG. 12 can facilitate the movement of the downlink network token 1260 between the application server 1208 and the gateway device 1206. If the downlink network token needs to be transmitted to the client device 1202, the aspect shown in FIG. 12 provides such transmission without the access node 1204 for any processing.

By way of example, during the implementation operation, the gateway device 1206 may receive the downlink network token from the application server 1208 in one or more user plane messages. The underlayer can carry the downlink network token 1260 to the gateway device 1206.

If the downlink network token 1260 is successfully verified at the gateway device 1206, the gateway device 1206 may forward the packet associated with the downlink network token 1260 to the client device 1202. The gateway device may discard the downlink network token 1260 before forwarding the packet to the client device 1202. If the verification of the downlink network token 1260 at the gateway device 1206 is unsuccessful, the gateway device 1206 can discard the packet and the downlink network token 1260.

The user plane protocol stack of the client device 1202, the access node 1204, the gateway device 1206, and the application server 1208 not described in conjunction with FIG. 12 The stacked layers will not be described again because their descriptions are the same as or similar to those similarly named layers in FIG. 9.

Exemplary equipment

Figure 13 is a block diagram illustrating an exemplary device 1300 configured to use network tokens to support network policy enforcement and/or packet diversion in accordance with the aspects described herein. As used herein, the term "device" may describe chip components and/or end user equipment, such as client equipment (eg, mobile equipment, user equipment, user equipment). In one example, the device 1300 may include a network communication interface circuit 1302, a processing circuit 1304, and a storage device 1306. The network communication interface circuit 1302 is used to communicate via a wireless network, and the processing circuit 1304 is coupled to the network communication The interface circuit 1302 and the storage device 1306 are coupled to the processing circuit 1304. This list is non-limiting.

The network communication interface circuit 1302 for communicating via the wireless network may include a first input/output module/circuit/function unit 1308 for performing input/output operations with the user. The network communication interface circuit 1302 may include a receiver/transmitter module/circuit/functional unit 1310 for wireless communication with the access node. This list is non-limiting.

The processing circuit 1304 may include or implement one or more processors, dedicated processors, hardware and/or software modules, etc., which are configured to support token-based application access. For example, the network token handling module/circuit/functional unit 1312 can be configured to obtain tokens based on unshared keys or shared keys that can be stored in the storage device 1306. By way of another example, the network token extraction/embedding module/circuit/functional unit 1314 can be configured to extract the network token from the uplink packet from the device and/or send it to the gateway device Under The network symbol is embedded (including) in the uplink packet. By way of another example, the encryption verification/verification module/circuit/functional unit 1316 can be configured to verify/verify using, for example, the network token received by the packet. This list is non-limiting.

The storage device 1306 can be configured to include network token handling instructions 1320, network token extraction/embedding instructions 1322, encryption verification/verification instructions 1324, and shared and non-shared key storage and instructions 1326. This list is non-limiting.

The communication between the network communication interface circuit 1302, the processing circuit 1304, the storage device 1306, and other components (not shown) of the device 1300 can be via the communication bus 1334.

Methods that can be operated at the device

FIG. 14 is an exemplary method 1400 through which a device (eg, chip component, client device) can initiate a request for communication with an application server associated with one or more application services, and use it in conjunction with the communication Network symbol. Network tokens can be used for network policy enforcement and data packet redirection (for example, to redirect packets related to user data messages). The network token can be used to verify and map the application service transmission between the application server and the device. The method 1400 can operate at a device. The method 1400 can be applied to a situation where a device initiates a request to use a network token. The network token may be an uplink (UL) network token, a downlink (DL) network token, or both UL network token and DL network token.

In one aspect, the device can use user plane messaging to initiate a connection between 1402 and an application server, which is connected to one or more App service association.

In response to initiating the connection, the device can obtain 1404 network tokens from the application server. The network token can be associated with the first stream in the set of one or more streams. The network token may be associated with the first application service among the one or more application services. The network token can be provided to the device via one or more user plane messages.

After receiving the network token, the device can use one or more uplink (UL) packets that are subsequently sent from the device to the application server in the user plane to include 1406 the network token. According to some aspects, the device can utilize each uplink (UL) packet that is subsequently sent from the device to the application server in the user plane to include the network token.

The network token can be obtained through the gateway device (for example, P-GW) of the core network. That is, according to some aspects, the application server provides the network token to the device; however, the application server does not obtain the network token. According to the aspect described in this article, the network token can be obtained through the gateway device and sent to the application server. This can allow network tokens to be delivered from the application server to the device in the user plane. Network tokens can be embedded or otherwise included in the packet. In some aspects, the network tokens can be distributed in one or more packets.

According to some aspects, the network token reflects the strategy implemented by the core network for the device. According to some aspects, the gateway device in the core network can obtain the network token based on the device customized profile of the device maintained by the core network and/or the policy of the first application service.

Equipment customized profiles can be stored in the customized profile library (SPR) . PCRF can communicate with SPR. In other words, the PCRF can request the user and/or device subscription profile from the SPR. The network token can reflect the strategy implemented by the core network for customized profiles. For example, the policy may include specific QoS requirements for voice traffic or real-time media traffic.

According to various aspects described herein, initiating a connection may include sending a connection request, and the connection request may include an explicit request for a network token. According to other aspects, initiating a connection may include sending a packet that represents an implicit request for a network token.

To ensure that the network token is received in response to an explicit or implicit request for the network token, the procedure for initiating the connection may include sending a packet for requesting confirmation from the application server, where the confirmation is the network token. The road sign is transmitted to the device. Therefore, according to one aspect, the network token can be included in the confirmation packet received by the device. For example, the packet can be a Transmission Control Protocol Synchronization (TCP SYN) packet. According to this aspect, the network token received by the device can be included in the TCP SYN acknowledgment (ACK) packet received by the device.

There are several ways to identify implicit requests for network tokens. According to one aspect, the implicit request can be identified through, for example, a strategy of identifying a service provider that requires packets from a given application server to carry a network token (for example, a DL network token). According to one aspect, when the device tries to connect with the application server for the first time, it can recognize the implicit request. In this type of situation, the P-GW can decide to make an implicit request when it detects the first packet from the device (eg, chip component, client device) to the application server. According to another aspect, implicit requests can be included in In the transmission of the packet, the packet includes the destination address or the destination address prefix of the application server that requires the network token (where the P-GW recognizes that the destination application server needs to use the network token). By way of another example, the implicit request for the first network token can be established based on the application identifier (App ID) included in the packet sent from the device (where the P-GW recognizes the application service, application The server or application associated with the application identifier requires the use of network tokens). In some aspects, new signal delivery (for example, in the control plane) may not be required to implement explicit and/or implicit use of network tokens.

Once the device receives the network token, there may be several ways to transmit the network token to the P-GW for implementation purposes in association with the uplink data packet. According to one aspect, the network token can be transmitted from the device to the packet data network (PDN) gateway (P-GW) in the user plane cushion header. The user plane cushion header can be located above the Internet Protocol (IP) layer. Alternatively, the user plane cushion header can be located below the Internet Protocol (IP) layer. According to another aspect, the network token can be transmitted from the device to the packet data network (PDN) gateway (P- GW). According to another aspect, the network token can be sent from the device to the access node in the Packet Data Convergence Protocol (PDCP) layer. The network token can then be copied in the access node to the General Packet Radio Service (GPRS) Tunneling Protocol (GTP) layer (GTP-U) header for the user plane. The network token can then be transmitted from the access node to the packet data network (PDN) gateway (P-GW) in the GTP-U layer.

In one aspect, network tokens can be associated with bearers and/or data streams. Network tokens can be restricted to application servers, application services and/or devices . In one aspect, the request for initiating an application service may include an application identifier (App ID) to identify the application server or application service that is the destination of the request. In this type of aspect, or in any other aspect, network tokens can be restricted to application servers, App IDs, and devices. As used herein, the term "constraint" (such as "symbols are'constrained' to parameters") indicates that a function including but not limited to named binding parameters can be used to obtain a symbol (ie, a DL symbol). It will be understood that the function is not limited to named parameters. By way of example, the DL token can be bound to the application server and the device (that is, the token is specific to the identified application server and the identified device); however, the equation for obtaining the DL token can include Parameters other than those that specifically identify the application server and/or device. It will be understood that the parameters quoted here, combined with examples of equations used to obtain network tokens, are not intended to be exhaustive or limiting.

A function with a set of input parameters can be used to obtain the DL token. The input parameters can include, for example, a key, a policy identifier, a source Internet Protocol (IP) address, a source port number, a destination IP address, and a destination. Port number, protocol identifier (ID), App ID, priority order and/or service quality category identifier (QCI). In one example, the DL token may include the function and concatenation result of some of the parameters and/or other parameters just listed. These parameters, for example, identify the key identifier ( KeyID). The DL token may include a class index (CI) that defines a field for token retrieval or a list of input parameters for token retrieval. In some aspects, the key (e.g. K_P-GW, Figure 4 and Figure 5) may only be known to the gateway device.

In one aspect, the key identifier can be defined for token acquisition Key. The key identifier can be changed periodically or according to instructions from the P-GW. Only the gateway device can know the key. In some aspects, the P-GW may have multiple keys for token acquisition. If the P-GW changes the token to obtain the key, the two keys can be valid at the same time. Therefore, the key identifier can be used to avoid the immediate withdrawal of the token in such scenarios.

The class index (CI) can define a field for token acquisition or a list of input parameters for token acquisition.

In one aspect, the DL token may be a concatenation of the key identifier, the class index (CI), the policy identifier, and the output of the function used in conjunction with the acquisition of the DL token. In some aspects, the function may be a secure hash function, such as a secure hash algorithm (SHA) such as SHA-1, SHA-2, or SHA-3. In other embodiments, the function may be a Hash Message Authentication Code (HMAC) function. In another embodiment, the function may be a message authentication code (MAC) acquisition function. The MAC acquisition function may include a cipher block chain message authentication code (CBC-MAC) function, a cipher-based MAC (CMAC) function, or a Galois message authentication code (GMAC) function.

The P-GW can also obtain a connection identifier, which can be used by the P-GW to identify the device or application server that initiates an explicit or implicit request for the DL token. The connection ID can be obtained before, during, or after the DL token is obtained. The connection ID can be reserved by the P-GW and can be used only for the P-GW. The connection ID can be stored in the temporary storage device of the P-GW (for example, the cache memory 428, FIG. 4). Cache memory can be a suitable storage location, because the connection ID is only available during the period when the application server or device is exchanging packets in conjunction with a given exchange. Once the service between the server and the device is applied The service is terminated, or after a predetermined amount of time or some other triggering event, the connection ID can be removed from the storage device in the P-GW (for example, rewritten or erased from the cache memory of the P-GW) .

The P-GW can use the DL token to implement a downlink traffic strategy including a downlink strategy related to user plane messages. The implementation can be performed by, for example, verifying the DL token in a given packet received from the application server and using the information obtained from the DL token to forward the packet to a suitable device. The packet that is forwarded to the appropriate device may or may not include the DL token. The P-GW can also verify the connection ID (if obtained previously).

The network token can be a secure method for verifying and mapping application service transmission between the application server and the device on the network. The use of network tokens for such purposes provides greater security than simply adding the application server ID to the packet. In addition, as mentioned above, the network token can include a secure hash used for verification, an index used to determine how the secure hash is used for verification, and/or an index used to determine how to process the packet after it has been verified. One or more of the strategies.

As an optional step, the device can establish or initiate a connection with the second application server. Thereafter, the device may optionally obtain a second network token that is different from the first network token from the second application server. The first application server and the second application server may be associated with application services or destination IP addresses. Additionally or alternatively, the first application server and the second application server may be associated with the first application service and the second application service.

FIG. 15 is an exemplary method 1500 through which a device (for example, a chip component, a client device) can respond to a communication request for initiating a communication request. Should, and use network tokens in conjunction with this communication. The request for initiating communication may include a request for using network tokens. The method 1500 can operate at the device. The method 1500 may be applicable to the following situations: the application server has initiated a request for initiating a communication and/or a request for using a network token.

A request for initiating communication (for example, a request for initiating an application service) may come from an application server. Requests such as application service requests may include explicit requests for the use of network tokens. Alternatively, the request to use the network token can be implicit. The request may include an application identifier (App ID) to identify the application server or service that initiated the request.

In one aspect, the device may receive 1502 a request for initiating an application service from the application server. The device can obtain 1504 network tokens. In one aspect, the network token can be obtained from a gateway (e.g., P-GW). The device may verify 1506 a request for initiating an application service (for example, based on an IP address, device ID, or application credentials).

The device may grant the network token to the application server by embedding or otherwise including 1508 the network token in the response to the request for initiating the application service. Network tokens can be embedded in packets that include responses to requests for initiating application services. In one aspect, the network token may be distributed in a plurality of packets, and the plurality of packets may include, for example, some or all responses to requests for initiating application services.

The device can then send 1510 a response including the embedded network token to the application server. In this way, the application server can be provided with a network token, and a copy of the network token can be embedded or otherwise included in one or more of the devices sent from the application server to the device in the downlink direction. many Packets. In some aspects, the application server may embed or otherwise include a copy of the network token in every packet sent from the application server to the device in the downlink direction.

In some aspects, the network token may be a downlink network token. The network token can be received at the device from the gateway device (e.g., P-GW). In some aspects, the DL token may be embedded or otherwise included in the packet received from the gateway device. The packet can be sent in the user plane.

Network tokens can be restricted to application servers and devices or can be restricted to application servers, application services and devices. In one aspect, DL tokens can be associated with bearers or data streams. The DL symbol can be used to check the downlink packet and to map the downlink packet received in the downlink stream to the bearer.

Regardless of whether the device or the application server initiates the request for establishing communication, the request may be a transport layer request or an application layer request. The packet in the initial request can be a Transmission Control Protocol Synchronization (TCP SYN) packet. If the packet in the initial request is a TCP SYN packet, the first network symbol can be carried in the TCP SYN acknowledgement (ACK) packet to the device or application server.

The request to use the network token can be an explicit request or an implicit request. Explicit requests can be embedded in requests sent from or to the application server in the user plane. Implicit requests can be identified, for example, by sending an initial message from the application server to the device (or vice versa). That is, the system can be prepared to recognize the need to use network tokens whenever a new communication service is created. By way of another example, initiating the service may include sending a packet indicating an implicit request for the first network token, wherein the implicit The request can be identified as the transmission of the first packet directed to the application server (or directed to the device). By way of another example, initiating a service may include sending a packet representing an implicit request for a network token, where the implicit request can be identified as including the destination of the application server that requires the network token. Address or at least the transmission of packets with the first code of the destination address (where, for example, the P-GW recognizes that the destination application server needs to use a network token). By way of another example, establishing or initiating a service may include sending a packet representing an implicit request for the first network token, which may be identified based on the application identifier (App ID) included in the packet Implicit request. In some aspects, no new signaling (for example, in the control plane) may be required to implement the explicit and/or implicit use of token requests via user-plane messaging.

In one aspect, the network token can be received in the user plane cushion header. The user plane underlayer may be located above the Internet protocol (IP) layer in the user plane protocol stack. Alternatively, the user plane underlayer may be located below the Internet protocol (IP) layer in the user plane protocol stack.

In one aspect, the network token may be embedded in the IP header, such as the IP version 4 (IPv4) header or the IP version 6 (IPv6) header. The IP header in IPv4 can be an IP option field. The IP header in IPv6 may be an IP extension header.

In one aspect, the network token can be embedded in the Transmission Control Protocol (TCP) header, and the network token can be embedded in the option field of the TCP header.

In one aspect, network tokens can be embedded in the transport layer security (TLS) in the record header.

In one aspect, the network token can be embedded in the underlying header between the IP header and the Transmission Control Protocol/User Datagram Protocol (TCP/UDP) header.

In another aspect, the network token can be embedded in the Hypertext Transfer Protocol (HTTP) header. The HTTP header can be an HTTP trial (eXperimental) or an extension (eXtension) header.

Exemplary gateway device

FIG. 16 is a block diagram illustrating an exemplary gateway device 1600 configured to use network tokens to support network policy enforcement and/or packet diversion according to the aspects described herein. In one example, the exemplary gateway device 1600 may include a network communication interface circuit 1602 for communicating via a wireless network, a processing circuit 1604 coupled to the network communication interface circuit 1602, and a storage device 1606 coupled to the processing circuit 1604 (For example, magnetic equipment and/or optical equipment used to store data). This list is non-limiting.

The network communication interface circuit 1602 for communicating via the wireless network may include a first input/output circuit/functional unit/module 1608 for communicating with the service gateway and a second input/output circuit/functional unit/module 1608 for communicating with the packet data network. Input/output circuit/functional unit/module 1610. The first input/output circuit/functional unit/module 1608 can handle multiple IP flows established on multiple bearers. The second input/output circuit/functional unit/module 1610 can handle multiple IP streams from multiple servers on the packet data network. This list is non-limiting.

The processing circuit 1604 may include or implement one or more processors, dedicated processors, hardware and/or software modules, etc., which are configured to support symbol-based Remember the application access. For example, the network token acquisition/verification circuit/functional unit/module 1612 can be configured to obtain tokens based on a key that can be stored in the storage device 1606. Only the gateway device can know the key. By way of another example, the key obtaining circuit/functional unit/module 1614 can be configured to obtain access-specific information based on, for example, a key that can be stored in the storage device 1606 and an identifier of a given access node. The key of the node. By way of another example, the decision and processing circuit/functional unit/module 1616 may be configured to determine the uplink packets received from the EPS bearer (or more generally, received from the device) and/or Whether the downlink packet received from the application server includes a network token, and if it does, it can also be configured to pass the received token to the encryption-verification and traffic diversion circuit/functional unit/module 1618. By way of another example, the encryption verification/verification module/circuit/functional unit 1630 can be configured to verify/verify the network token received from, for example, a device or an application server. The decision and processing circuit/functional unit/module 1616 can also be configured to pass the received packet that does not include the network token to the service data flow filter group (not shown). This list is non-limiting.

The storage device 1606 may be configured to include network token acquisition/verification instructions 1620, key acquisition instructions 1622, decision and processing instructions 1624, encryption-verification and traffic steering instructions 1626, and shared and non-shared key storage and instructions. This list is non-limiting.

The communication between the network communication interface circuit 1602, the processing circuit 1604, the storage device 1606, and other components (not shown) of the exemplary gateway device 1600 may be through the communication bus 1634.

Methods that can be operated at the gateway device

FIG. 17 illustrates an exemplary method 1700 that can be operated at a gateway device (for example, P-GW) according to the aspect described herein, and the method is used to detect a user plane message transmitted via a user plane from the device. For the request of the path token, the network token is obtained, and the network token is provided to the requesting device via the application server.

According to one aspect, a method operable at a gateway device (eg, P-GW) in the network may include receiving 1702 data packets at the gateway device via the user plane. The gateway device may then perform steps for determining 1704 whether the network token is requested (eg, explicitly or implicitly). If the network token is requested, the gateway device can obtain 1706 the network token. The network token can be based on a customized profile of the equipment maintained by the network.

According to one aspect, the network token can be obtained from the gateway device at the local end. According to the aspect described herein, the network token can be obtained through the gateway device based on the device customized profile maintained by the core network associated with the gateway device. The equipment subscription profile can be stored in a subscription profile library (SPR). The network token can reflect the strategy implemented by the core network for the device. In other words, the network token does not need to reflect the strategy of the application server. The network token can be obtained and used by the gateway device on behalf of the network and for the purpose of the network.

Once the gateway device obtains the network token, the gateway device can perform the steps required to use the data packet to include the 1708 network token. The gateway device can then send 1710 the data packet and network token to the destination.

In some aspects, the data packet is to be sent to the application server, and the network token is the uplink network token. In some aspects, the data packet is to be sent to the application server, and the network token is the downlink network token remember. In some aspects, the data packet is to be sent to the device, and the network token is the downlink network token. In some aspects, when the data packet is to be sent to the device and the network token is a downlink network token, the method may also include: receiving a second packet including the downlink network token from the device , And send the second packet and the downlink network token to the application server. In this latter aspect, the application server may have requested the downlink network token; the requested downlink network token will be sent from the gateway to the device; the gateway will then receive from the device including the downlink A data packet of the downlink network token; and the gateway sends the copy of the downlink network token to the application server that originally requested the downlink network token. In other aspects, the network token may be an uplink network token and a downlink network token, where the uplink network token is different from the downlink network token. In this aspect, the network device can obtain the uplink network token and the downlink network token and send both to the destination.

As noted above, the gateway device can be a packet data network (PDN) gateway (P-GW).

The step of determining whether the network token is requested may depend on whether the packet includes an explicit request for the network token or whether the packet represents (for example, represents) an implicit request for the network token. According to some aspects, determining whether a network token is requested is based on determining whether the application server to which the packet is to be sent requires a network token. If the application server to which the packet is to be sent requires a network token, the gateway device can obtain the network token. Other tests used to determine implicit indications of the need for network tokens are acceptable.

If the network token is requested, the gateway device can obtain the network token remember. According to one aspect, obtaining the network token is achieved by obtaining the network token at the gateway device. The network token can be obtained by using a function with a set of input parameters. The set of input parameters includes: the known key of the gateway device, class index, source Internet Protocol (IP) address, source port number, and destination IP address, destination port number, protocol identifier (ID), application ID, priority and/or quality of service class identifier (QCI). The class index can define the fields used for network token retrieval.

According to an example provided above and repeated below for convenience, the network token can be obtained as follows: Network token=CI|HMAC(K_P-GW,CI|IP_C|IP_S|P_C|P_S|Proto|App ID|...), where: CI is the class index that defines the field used for token acquisition, HMAC is the key hash message authentication code, K_P-GWIs the key of P-GW, IP_CIs the IP address of the client (for example, device), P_CIs the client port number, IP_SIs the IP address of the server (for example, the destination or application server), P_SIs the server port number, Proto is the protocol number or identifier, and App ID is the application identifier. Additional or alternative parameters may include priority order and/or quality of service category identifier (QCI).

As shown in the above example, the network token can be a concatenation of the class index and the output of the exemplary function. According to some aspects, the function may be a Hash Message Authentication Code (HMAC) function. According to some aspects, the function may be a message authentication code (MAC) acquisition function. The MAC acquisition function includes the cipher block chain message authentication code (CBC-MAC) function, the cipher-based MAC (CMAC) function or the Galois message authentication code (GMAC) function. Other formulas for obtaining network tokens may be acceptable.

FIG. 18 illustrates an exemplary method 1800 that can be operated at a gateway device (eg, P-GW) according to this aspect herein, the method is transmitted at the gateway device (eg, P-GW) via a user plane message Set up and use network tokens.

In one aspect, the method of setting the network token may include: receiving 1802 a request for network service (for example, the first packet) at the gateway device. Requests for network services can explicitly include or implicitly represent requests for network tokens. Requests for network services can be received from the client device (e.g., in the uplink data stream) or from the application server (e.g., in the downlink data stream). In response to a request for a network token, the gateway device can obtain 1804 an uplink network token, a downlink network token, or an uplink network token and a downlink network suitable for the request. Symbol of both.

Optionally, the gateway device may also obtain 1806 a connection identifier, which may identify the client device or application server that initiated the connection associated with the network token. If obtained, the connection identifier can optionally be stored 1808 at the gateway device. For example, the storage can be in the cache memory of the gateway device.

The gateway device may embed or otherwise include the network token 1810 in the packet to be sent to the device or application server. In one aspect, the packet can be associated with a request for an application service. The gateway device may send 1812 the request for the application service including the embedded and/or included network token to the device or the application server.

Subsequently, the gateway device may receive 1814 a packet including a previously obtained (for example, a previously obtained copy) network token. Continue to the pair of application services A non-limiting example of a request (for example, a service initiation request), the received packet may be associated with a service initiation response. The gateway device can verify the received packet by verifying the 1816 network token. Optionally, if obtained previously, the gateway device can verify the 1818 connection ID. If the network token is verified, the gateway device can send 1820 the initial response to its destination. In some aspects, the gateway device can use the initial response to include the network token. In other aspects, the gateway device can discard the network token so that the network token is not included in the initial response when the initial response is sent to its destination.

In some aspects, the network token can be bound to the device (eg, chip component, client device) and application server, or it can be bound to the device, App ID, and application server.

FIG. 19 illustrates an exemplary method 1900 that can be operated at a gateway device (eg, P-GW) according to the aspect described herein. The combination of the use of the mark is used to verify the network mark. According to some aspects, certain characteristics may indicate that the gateway device may be able to use the network token included in the data packet for policy enforcement and/or packet redirection. In one example, a flag can be set to indicate that the packet includes a network token for policy enforcement and/or packet redirection.

According to one aspect, the method may include: at the gateway device, obtaining the 1902 first network token in response to a request for the first network token. The request for the first network token can be sent from the device to an application server associated with one or more application services. Receive 1904 data packets from the device at the gateway device. The data packet may at least include the destination address prefix corresponding to the application server. The data packet may include the second network token.

The method can continue by verifying 1906 the second network token. According to one aspect, verifying 1906 the second network token may include using input parameters obtained from the packet and a key known to the gateway device to obtain a copy of the first network token from the first function. The first network token is obtained in advance and sent to the application server for subsequent delivery to the device. Once the device receives the first network token, the device uses the uplink packet sent to the same application server to include a copy of the first network token. The second network token included in the received uplink packet under consideration should be a copy of the first network token. If two network tokens are obtained using the same function, the same key known by the gateway device, and the same common parameters extracted from different packets sent from the same device to the gateway device, the second network token Will be the same as the copy of the first network token.

Optionally, if the connection identifier is obtained in combination with the acquisition of the original network token and stored at the gateway device, the circuit/module/functional unit at the gateway device can verify 1908 the connection identifier .

A decision 1910 may be made as to whether the verification (for example, verification of the second network token and optional connection identifier) is successful. If the verification is unsuccessful, the method can continue by discarding the 1912 packet and its associated second network token. If the verification is successful, the method can continue by optionally discarding 1914 the second network token and sending 1916 the packet to the application server.

Exemplary application server

FIG. 20 is a block diagram illustrating an exemplary application server 2000 configured to support downlink token verification and packet mapping. In one example, the application server 2000 may include network communication for communication via a wireless network The interface circuit 2002, the processing circuit 2004 coupled to the network communication interface circuit 2002, and the storage device 2006 coupled to the processing circuit 2004. This list is non-limiting.

The network communication interface circuit 2002 for communicating via the wireless network may include a first input/output module/circuit/functional unit 2008 for communicating with the P-GW via the S-GW. The network communication interface circuit 2002 may include a receiver/transmitter module/circuit/functional unit 2010 for wireless communication with the device. This list is non-limiting.

The processing circuit 2004 may include or implement one or more processors, dedicated processors, hardware and/or software modules, etc., which are configured to support token-based application access. For example, the network token handling module/circuit/functional unit 2012 can be configured to obtain tokens based on a non-shared key or a shared key that can be stored in the storage device 2006. By way of another example, the network token extraction/embedding module/circuit function unit 2014 can be configured to extract the network token from the uplink packet from the device and/or to forward it to the gateway device. The network token is embedded (including) in the packet. By way of another example, the encryption verification/verification storage device 2016 may be configured to verify/verify the network token received from, for example, a device. This list is non-limiting.

The storage device 2006 can be configured as a network token handling command 2020, a network token extraction/embedding command 2022, an encryption verification/verification command 2024, and a shared and non-shared key storage and command 2026. This list is non-limiting.

The communication between the network communication interface circuit 2002, the processing circuit 2004, the storage device 2006 and other components (not shown) of the application server 2000 can be through the communication bus 2034.

Methods that can be operated at the application server

FIG. 21 is a flowchart of an exemplary method 2100 for setting a network token at an application server according to the aspect described herein.

According to one aspect, a decision 2102 can be made as to whether the application server will initiate a request for providing application services to a device (eg, chip assembly, client device). If the application server will initiate the request, the application server can send a 2104 request, which includes the request sent in the user plane, explicitly includes or implicitly represents the network token (for example, DL network token) Note) the used request packet. The application server can then wait 2106 to obtain the network token. Returning to 2102, if it is determined that the application server will not initiate a request, the application server can wait for 2106 to obtain, for example, an explicit or implicit network token sent from the slave device (eg, chip component, client device) The network token sent by the request.

The application server can then obtain 2108 network tokens. According to the aspect described herein, the gateway device associated with the core network may have obtained the network token based on the customized profile of the device maintained by the core network. The equipment subscription profile can be stored in a subscription profile library (SPR). SPR can be coupled to PCRF. The network token can reflect the strategy implemented by the core network for the device. In other words, the network token does not need to reflect the strategy of the application server. The network token can be obtained and used by the gateway device on behalf of the network and for the purpose of the network.

Upon obtaining (for example, receiving) the network token, the application server may embed or otherwise include a copy of the DL network token in at least some packets sent to the device, where, for example, the network token is DL network symbol about the connection with the device. In some aspects, the application server can connect the DL network A copy of the waymark is embedded or otherwise included in every packet sent to the device.

In some aspects, sending the DL token with the packet sent from the application server to the device may include including the DL token in the following: Internet Protocol (IP) IP version 4 (IPv4) header Or IP version 6 (IPv6) header, where the symbols in the IPv4 header can be in the IP option field, and the symbols in IPv6 can be in the IP extension header; Transmission Control Protocol (TCP) header; security Socket Layer (SSL) header; Transport Layer Security (TLS) record header; the pad between the Internet Protocol (IP) header and the Transmission Control Protocol/User Datagram Protocol (TCP/UDP) header Layer header; and/or Hypertext Transfer Protocol (HTTP) header.

In an aspect where the DL token is requested by the application server, the DL token can be obtained from the packet including the response sent from the device. In another aspect, the DL token can be obtained from a request sent from the device for initiating an application service.

Unless otherwise specified, the specific implementations shown and described are only examples, and should not be construed as the only way to realize the content of this case. It is obvious to a person with ordinary knowledge in the field of the present invention that the various examples in the content of this case can be practiced through several other subdivision solutions.

Described in this articleOne or more of the components, actions, features, and/or functional units and shown in the drawings can be rearranged and/or combined into a single component, action, feature or functional unit, or combined with several components , Actions, features or functions. You can also add additional components, components, actions, and/ Or functional unit without departing from the invention. The algorithms described in this article can also be efficiently implemented using software and/or embedded in hardware.

In the description, in order to avoid making the content of the case unclear in unnecessary details, components, circuits, functional units and modules may be shown in block diagram form. On the contrary, unless otherwise specified, the specific implementations shown and described are only exemplary, and should not be construed as the only way for realizing the content of this case. In addition, the block definitions and logical subdivisions between the blocks are exemplary examples of specific implementations. It is obvious to a person with ordinary knowledge in the field of the present invention that the content of this case can be practiced through many other subdivision solutions. For the most part, details regarding time considerations, etc. have been omitted, where such details are not necessary for obtaining a complete understanding of the content of the case, and are within the ability of a person with ordinary knowledge in the field of the present invention.

In addition, it should be noted that the embodiments can be described as a program illustrated as a flowchart, a flow block diagram, a structure diagram, or a block diagram. Although the flowchart can describe the operations as a sequential procedure, many operations can be performed in parallel or simultaneously. In addition, the order of these operations can be rearranged. When the operation of the program is completed, the program is also terminated. Programs can correspond to methods, functions, procedures, subroutines, subroutines, etc. When a program corresponds to a function, its termination corresponds to the return of the function that called the function or the main function.

Those with ordinary knowledge in the field to which the present invention pertains should understand that information and signals can be represented using any of a variety of different technologies and methods. For example, the data, instructions, commands, information, signals, bits, symbols, and chips mentioned throughout this specification can be represented by voltage, current, electromagnetic waves, magnetic fields or particles, light fields or particles, or any combination thereof. Some pictures can be The signal is shown as a single signal for clarity of presentation and description. Those with ordinary knowledge in the field to which the present invention pertains will understand that a signal can represent a signal bus, where the bus can have various bit widths, and the content of this case can be implemented on any number of data signals including a single data signal.

It should be understood that references to elements in this document using labels such as "first", "second", etc. generally do not limit the number or order of those elements, unless such restrictions are explicitly stated. Rather, this article uses these identifiers as a convenient way to distinguish between two or more elements or instances of an element. Therefore, mentioning the first and second elements does not mean that only two elements can be used there or that the first element must precede the second element in some way. In addition, unless otherwise stated, a set of elements may include one or more elements.

Moreover, the storage medium may refer to one or more devices used to store data, including read-only memory (ROM), random access memory (RAM), magnetic disk storage media, optical storage media, flash storage devices, and/ Or other machine-readable media, and processor-readable media and/or computer-readable media for storing information. The terms "machine readable media", "computer readable media" and/or "processor readable media" may include, but are not limited to, non-transitory media such as portable or fixed storage devices, optical storage devices, and Various other media capable of storing, containing or carrying (multiple) instructions and/or data. Therefore, the various methods described herein can be stored in a "machine readable medium", a "computer readable medium" and/or a "processor readable medium" in whole or in part by one or more The instructions and/or data executed by the processor, machine and/or equipment are implemented.

In addition, the embodiments can be implemented by hardware, software, firmware, intermediary software, microcode, or any combination thereof. When implemented by software, firmware, intermediary software, or microcode, the code or code fragments used to perform the necessary tasks can be stored in a machine-readable medium such as a storage medium or other storage device. The processor can perform the necessary tasks. Code fragments can represent procedures, functions, subroutines, programs, routines, subroutines, modules, software packages, software components, or any combination of instructions, data structures, or program statements. A code segment can be coupled to another code segment or hardware circuit through transmission and/or information, data, arguments, parameters, or memory content. Information, arguments, parameters, data, etc. can be transferred, forwarded or sent by any appropriate means including memory sharing, message transfer, token transfer, network transmission, and communication.

The various illustrative logical blocks, elements, circuits, modules, functional units and/or components described in conjunction with the examples disclosed herein can utilize general-purpose processors, digital signal processors (DSP), Special application integrated circuits (ASIC), field programmable gate arrays (FPGA) or other programmable logic components, individual gates or transistor logic devices, discrete hardware components or any combination thereof are implemented or executed. A general-purpose processor may be a microprocessor, but in the alternative, the processor may be any conventional processor, controller, microcontroller, or state machine. The processor can also be implemented as a combination of computing components, for example, a combination of a DSP and a microprocessor, multiple microprocessors, one or more microprocessors combined with a DSP core, or any other such configuration. A general-purpose processor configured to execute the embodiments described herein is considered a dedicated processor for implementing such embodiments. Similarly, when configured to use When implementing the embodiments described herein, a general-purpose computer is regarded as a dedicated computer.

The methods or algorithms described in combination with the examples disclosed herein can be directly included in the hardware, software modules executed by the processor, or a combination of the two in the form of processing units, program instructions, or other instructions, and can be included in In a single device or distributed among multiple devices. The software module can be located in RAM memory, flash memory, ROM memory, EPROM memory, EEPROM memory, scratchpad, hard disk, removable disk, CD-ROM, or known in the field of the present invention Any other form of storage media. The storage medium may be coupled to the processor, so that the processor can read information from the storage medium and write information to the storage medium. Alternatively, the storage medium may be an integral part of the processor.

Those with ordinary knowledge in the field to which the present invention pertains will also realize that the various illustrative logic blocks, circuits, functional units, modules, and algorithm steps described in combination with the embodiments disclosed herein can be implemented as electronic hardware and computer software. Or a combination of the two. In order to clearly illustrate this interchangeability of hardware and software, various exemplary elements, components, blocks, circuits, functions, modules, and steps have been described above generally around their functions. Whether such functions are implemented as hardware, software, or a combination thereof depends on the specific application and design choices imposed on the entire system.

The various features of the invention described herein can be implemented in different systems without departing from the invention. It should be noted that the foregoing embodiments are only examples and should not be construed as limiting the present invention. The description of the embodiments is intended to be illustrative, and not to limit the scope of protection of the claim. Therefore, the present teaching can be easily applied to other types of devices, and has general knowledge in the field to which the present invention belongs. For the ordinary knowledgeable person, many alternatives, modifications and variations will be obvious.