WO2015010576A1 - Session management method, application function entity, policy server and protocol converter - Google Patents

Abstract

Disclosed are a session management method, an application function entity, a policy server and a protocol converter, which relate to the field of communications. The method comprises: when an AF entity is establishing an AF session with a policy server, the AF entity sending a first HTTP request message to the policy server, wherein AF session identification information is sent to the policy server by the AF entity through the first HTTP request message, or the AF session identification information is allocated by the policy server and is sent to the AF entity through a response of the first HTTP request message; when the policy server notifies the AF entity of a bearing layer event of the above-mentioned AF session, the policy server sending a second HTTP request message which carries the AF session identification information to the AF entity; and the AF entity returning a response of the second HTTP request message to the policy server.

Description

 Session management method, application functional entity, policy server and protocol converter

 The present invention relates to the field of communications, and in particular, to a session management method, an application function entity, a policy server, and a protocol converter.

Background technique

 Figure 1 is the Policy and Charging Control (PCC) defined by the 3rd Generation Partnership Project (3GPP).

 The Policy and Charging Rules Function (PCRF) is used to formulate QoS and charging policies for network resources. The PCRF formulates the control policy, and needs to combine the service information received from the AF, the user subscription information received from the User Profile Repository (SPR), the policy configured by the operator, and the like. The PCRF sends the control policy for the service to the Policy and Charging Enforcement Function (PCEF) or the Bearer Binding and Event Report Function (BBERF). At the same time, the PCRF can subscribe to the bearer layer related events to the PCEF and/or BBERF to be aware of the event when the bearer layer occurs, and to change the control strategy. In addition, the PCEF and the Traffic Detection Function (TDF) can perform application detection and control functions based on the PCC rules (PCEF) or ADC rules (TDF) issued by the PCRF.

With the development of the mobile Internet, operators need to communicate with third-party data application providers to provide QoS for services provided by third-party data application providers. Due to the Diameter protocol currently used by the RX interface supported by PCC, for most third-party data application providers, they are better at developing based on SOAP and REST protocols. Currently, the industry research PCC architecture supports the Rx interface based on the SOAP/REST protocol. Two schemes are proposed, one is that PCRF supports SOAP or REST protocol, and the other is to directly set up a network element called Protocol Converter (PC) in PCRF and AF for SOAP or REST protocol. Convert to Diameter. Currently the SOAP protocol supports the XML language, while the REST protocol supports both XML and JSON languages. The Rx interface needs to support two-way communication, that is, the AF provides service information to the PCRF, and the PCRF needs to provide a Traffic Plane Event to the AF in real time. However, the SOAP or REST protocols are based on the Hypertext Transfer Protocol (HTTP).

HTTP is a stateless protocol. The client requests a URL, the server responds, sends back the response content, and connects to the port. It cannot implement two-way communication. In order to realize the active push information of the server to the client, the following three solutions are proposed in the industry:

 1. Polling: The browser keeps requesting to get the latest data, which is simulated as push. The determination of this scheme is that the delay is large and the signaling overhead is large.

 2. Streaming: After the server receives the HTTP request from the client and returns the confirmation message, the connection between the server and the client is not disconnected. Through the connection server, the server can continuously send data to the client. The downside of this approach is that the connection needs to be maintained, taking up resources on the server and client. Its proxy support is not good because the proxy may cache data.

 3. Long-Polling: The browser sends a request. After the server receives the connection, it suspends the connection until it has data to send to the client. After the data is sent, the connection is disconnected. When the client receives the data, it requests the server to take the data again. The downside of this approach is that the connection needs to be maintained, taking up resources from the server and client.

 Considering the special application of PCC, third-party data applications need to provide services to a large number of users. Therefore, if Streaming or Long-Polling is adopted, a large number of transmission control protocols should be maintained between the third-party data application server and the PCRF or PC ( Transmission Control Protocol (TCP) connection.

 In addition, the related protocol also stipulates that the same client and server can only maintain a maximum of 2 HTTP TCP connections. If more than 2 HTTP TCP connections are maintained, the protocol is inconsistent with the related protocols, resulting in interoperability problems.

The related art also proposes that multiple HTTP requests can be encapsulated into one TCP connection (becoming HTTP Pipelining), and Long-Polling is used to implement the server to actively provide data to the client. However, this scheme requires the client to send a new request after Long-Polling is completed, which will cause a delay. Summary of the invention

 Embodiments of the present invention provide a session management method, an application function entity, a policy server, and a protocol converter, which reduce the use of network resources while realizing two-way communication, and can ensure real-time performance. A session management method, including:

 When the application function (AF) entity establishes an AF session with the policy server, the AF entity sends a first hypertext transfer protocol (HTTP) request message to the policy server;

 The AF entity sends the AF session identification information to the policy server by using the first HTTP request message; or the AF entity obtains the response from the response of the first HTTP request message returned by the policy server. The AF session identification information allocated by the policy server for the AF session;

 Receiving, by the AF entity, a second HTTP request message sent to the AF entity when the policy server notifies the AF entity of the bearer layer event of the AF session, where the second HTTP request message carries the AF Session identification information;

 The AF entity returns a response to the second HTTP request message to the policy server. Preferably, the policy server is a Policy and Charging Rules Function (PCRF) entity or a Protocol Translator (PC).

 Preferably, when the AF entity modifies or terminates the AF session, the AF entity sends a third HTTP request message to the policy server, where the third HTTP request message carries the AF session identifier information;

 The AF entity receives an answer to the third HTTP request message returned by the policy server.

 Preferably, the AF session identification information is a globally unique identifier.

 Preferably, the AF session identification information is represented by any combination of the following:

 The service session identifier and the IP address of the UE;

Service session identifier, IP address of the UE, and IP domain identifier; Service session identifier, UE's IP address, and packet data network (PDN) identity; service session identity and user identity. Preferably, the AF entity supports both an HTTP client and an HTTP server, and the policy server supports both an HTTP client and an HTTP server. Preferably, the sending, by the AF entity, the first HTTP request message or the third HTTP request message to the policy server includes:

 When the AF entity and the policy server already have a first Transmission Control Protocol (TCP) connection, the AF entity sends the first HTTP request message to the policy server by using the first TCP connection or Third HTTP request message;

 When the AF entity and the policy server do not establish the first TCP connection, the AF first establishes a first TCP connection with the policy server, and then sends the first HTTP request message or the third HTTP request. Message.

 Preferably, after the AF entity receives the response of the first HTTP request message or the third HTTP request message sent by the policy server, the AF entity reserves the relationship between the AF entity and the policy server. First TCP connection; or

 After receiving the response of the first HTTP request message or the third HTTP request message sent by the policy server, the AF entity disconnects the first TCP between the AF entity and the policy server. connection. A session management method, including:

 The policy server receives a first hypertext transfer protocol (HTTP) request message that is sent by the application function (AF) entity and carries the AF session identifier information, and returns a response of the first HTTP request message to the AF entity; or, receives the AF The first HTTP request message sent by the entity, the AF session identifier information is allocated to the AF session, and the response of the first HTTP request message carrying the AF session identifier information is returned to the AF entity;

Sending a second HTTP request message to the AF entity, the second HTTP request message carrying the AF session identification information, and receiving the AF, when notifying the AF entity of the bearer layer event of the AF session The response of the second HTTP request message returned by the entity. Preferably, the policy server is a Policy and Charging Rules Function (PCRF) entity or a protocol converter (PC). Preferably, the sending, by the policy server, the second HTTP request message to the AF entity includes:

 When the policy server and the AF entity have a second TCP connection, the policy server sends the second HTTP request message to the AF entity by using the second TCP connection; the policy server and the When the AF entity does not establish a second TCP connection, the policy server first establishes a second TCP connection with the AF entity, and then sends the second HTTP request message. Preferably, the method further includes:

 After receiving the response of the second HTTP request message sent by the AF entity, the policy server retains the second TCP connection between the policy server and the AF entity; or

 After receiving the response of the second HTTP request message sent by the AF entity, the policy server disconnects the second TCP connection between the policy server and the AF entity. Preferably, the policy server is a PC, and after the policy server receives the first HTTP request message, the method further includes: the PC sending a Diameter Authentication Authorization Request (AAR) message to the PCRF entity, requesting to establish a diameter session. The AAR message carries a diameter session identifier, and the PC maintains a correspondence between the AF session identifier information and the diameter session identifier. Preferably, the method further includes: the policy server receiving a third HTTP request message that is sent by the AF entity to the PC and carrying the AF session identifier information, where the PC sends a Diameter AAR message to the PCRF entity. Or a Diameter Session Termination Request (STR) message, the AAR or STR message carrying the diameter session identifier. Preferably, when the policy server is a PC, the policy server sends a second HTTP request message to the AF entity, including:

 The PCRF entity sends a diameter re-authentication request carrying the diameter session identifier to the PC

(RAR), when terminating a session request (ASR) or a session termination response (STA) message, the PC sends the second HTTP request message carrying the AF session identification information to the AF entity. An AF entity, including:

 a first unit, configured to: when the AF entity establishes an AF session with the policy server, send a first hypertext transfer protocol (HTTP) request message to the policy server, and receive a first HTTP request returned by the policy server Response to the message;

 The first unit is configured to: carry the AF session identifier information in the first HTTP request message, or obtain the AF session identifier information from the response of the first HTTP request message returned by the policy server;

 a second unit, configured to: receive a second HTTP request message carrying the AF session identification information, when the policy server notifies the AF entity of the bearer layer event of the AF session, and send the The policy server returns a response to the second HTTP request message. Preferably, the AF entity further includes:

 a third unit, configured to: when the AF entity modifies or terminates the AF session, sending a third HTTP request message to the policy server, where the third HTTP request message carries the AF session identifier information, And receiving a response of the third HTTP request message returned by the policy server.

 Preferably, the first unit is configured to: when the AF entity and the policy server already have a first Transmission Control Protocol (TCP) connection, use the first TCP connection to the policy server Sending the first HTTP request message, when the first TCP connection is not established between the AF and the policy server, first establishing a first TCP connection with the policy server, and then sending the first HTTP request message;

 The third unit is configured to: when the AF entity and the policy server already have a first TCP connection, send the third HTTP request message to the policy server by using the first TCP connection, When the first TCP connection is not established between the AF and the policy server, first establishing a first TCP connection with the policy server, and then sending the third HTTP request message.

Preferably, the first unit is further configured to: after receiving the response of the first HTTP request message sent by the policy server, retain the first between the AF entity and the policy server a TCP connection, or disconnecting the first TCP connection between the AF entity and the policy server; The third unit is further configured to: after receiving the response of the third HTTP request message sent by the policy server, retain the first TCP connection between the AF entity and the policy server, or Disconnecting the first TCP connection between the AF entity and the policy server.

 Preferably, the second unit is configured to: receive the second HTTP request message by using a second TCP connection between the policy server and the AF entity, and use the second TCP connection Returning a response to the second HTTP request message to the policy server. A policy server, including:

 a first unit, configured to: receive, by the application function (AF) entity, a first hypertext transfer protocol (HTTP) request message carrying AF session identification information, and return the first HTTP request message to the AF entity Receiving; or receiving a first HTTP request message sent by the AF entity, assigning AF session identification information to the AF session, and returning, to the AF entity, a response of the first HTTP request message carrying the AF session identification information;

 a second unit, configured to: when notifying the AF entity of the bearer layer event of the AF session, sending a second HTTP request message to the AF entity, where the second HTTP request message carries the AF session Identification information, and receiving a response of the second HTTP request message returned by the AF entity.

 Preferably, the first unit is configured to: receive the first HTTP request message by using a first TCP connection between the AF entity and the policy server, and use the first TCP connection to The AF entity returns a response to the first HTTP request message.

 Preferably, the second unit is configured to: when the policy server and the AF have a second TCP connection, send the second HTTP request message to the AF by using the second TCP connection. ;

 When the policy server does not establish a second TCP connection with the AF, first establish a second TCP connection with the AF, and then send the second HTTP request message.

 Preferably, the second unit is configured to: after receiving the response of the second HTTP request message sent by the AF entity, retain the second TCP between the policy server and the AF entity Connecting, or disconnecting the second TCP connection between the policy server and the AF.

Preferably, the policy server is a policy and charging rule function (PCRF) entity or protocol transfer. Converter (PC) A protocol converter, which includes:

 The first unit is configured to: receive, in an application function (AF) session establishment process, a first hypertext transfer protocol (HTTP) request message that carries the AF session identifier information sent by the AF entity, to the policy and charging rule function a (PCRF) entity sends a Diameter Authentication Authorization Request (AAR) message, requesting to establish a diameter session, the AAR message carrying a diameter session identifier, and maintaining a correspondence between the AF session identifier information and the diameter session identifier; or, receiving a first hypertext transfer protocol (HTTP) request message sent by the AF entity, assigning AF session identification information to the AF session, and sending a Diameter Authentication Authorization Request (AAR) message to the Policy and Charging Rules Function (PCRF) entity, requesting to establish a diameter session, the AAR message carrying a diameter session identifier, and maintaining a correspondence between the AF session identifier information and the diameter session identifier;

 a second unit, configured to: receive, in an AF session modification or termination process, a third HTTP request message that is sent by the AF entity and that carries the AF session identification information, and send, to the PCRF entity, the path session identifier that carries the diameter Diameter AAR or Diameter Session End Request (STR) message;

 And a third unit, configured to: receive a diameter re-authentication request (RAR), a termination session request (ASR), or a session termination response (STA) that is sent by the PCRF entity and that carries the diameter session identifier in a bearer layer event reporting process. a message, and sending the second HTTP request message carrying the AF session identification information to the AF.

The embodiment of the present invention further provides a computer program, including program instructions, when the program instruction is executed by an application function entity, so that the application function entity can execute the above method.

 The embodiment of the invention further provides a computer program, comprising program instructions, when the program instruction is executed by the policy server, so that the policy server can execute the above method.

 Embodiments of the present invention also provide a carrier carrying any of the above computer programs.

The technical solution of the embodiment of the present application solves the problem that the AF and the PCRF or the PC can perform bidirectional information transmission based on HTTP real-time. BRIEF abstract

 1 is a PCC architecture diagram of a related art;

 2 is a PCC architecture diagram of a prior art deployment PC;

 3 is a flowchart of establishing an AF session according to Embodiment 1 of the present invention;

 4 is a flowchart of an AF session modification according to Embodiment 1 of the present invention;

 FIG. 5 is a flowchart of an AF session termination according to Embodiment 1 of the present invention; FIG.

 6 is a flowchart of event reporting according to Embodiment 1 of the present invention;

 7 is a flowchart of an IP-CAN session termination according to Embodiment 1 of the present invention;

 8 is a flowchart of establishing an AF session according to Embodiment 2 of the present invention;

 9 is a flowchart of an AF session modification according to Embodiment 2 of the present invention;

 10 is a flowchart of an AF session termination according to Embodiment 2 of the present invention;

 11 is a flowchart of event reporting according to Embodiment 2 of the present invention;

 FIG. 12 is a flowchart of IP-CAN session termination according to Embodiment 2 of the present invention.

Preferred embodiment of the invention

 Embodiments of the present invention will be described in detail below with reference to the accompanying drawings. It should be noted that, in the case of non-conflict, the features of the embodiments and the embodiments of the present application may be arbitrarily combined with each other.

Example 1

 This embodiment provides a session management method, including:

 When the AF entity establishes an AF session with the policy server, the AF entity sends a first HTTP request message to the policy server;

 The AF entity carries the AF session identification information in the first HTTP request message to notify the policy server, and the policy server returns a response of the first HTTP request message to the AF entity; or, after the policy server receives the first HTTP request message, Assigning AF session identification information to the AF session, and transmitting the AF session identification information to the AF entity in response to the first HTTP request message;

Policy server when the policy server notifies the AF entity of the bearer layer event of the above AF session Sending a second HTTP request message to the AF entity, where the second HTTP request message carries the AF session identifier information, and the AF entity returns a response of the second HTTP request message to the policy server. The policy server can be a PCRF entity or a PC.

 The AF session identification information involved in the above method is a globally unique identifier, or a combination of a service session identifier and other information. The combination of the service session identifier and other information may be represented by any combination of the following: a service session identifier and an IP address of the UE, where the service session identifier is capable of uniquely identifying the IP address of the same UE. The identity of the AF session;

 a service session identifier, an IP address of the UE, and an IP domain identifier, where the service session identifier is an identifier that can uniquely identify the AF session in the case of an IP address and an IP domain identifier of the same UE; An address and a packet data network PDN identifier, where the service session identifier is an identifier service session identifier and a user identifier that can uniquely identify the AF session in the case of an IP address and a PDN identifier of the same UE, where the service session identifier The identifier of the AF session is uniquely identified in the case of the same UE's IP address and user identity.

 In addition, on the basis of the foregoing method, when the AF entity and the policy server modify or terminate the AF session, the AF entity sends a third HTTP request message to the policy server, where the third HTTP request message carries the AF session identifier information. The Policy Server will return a response to the third HTTP request message.

 The implementation process of the above method will be described in detail below in conjunction with the application scenario.

 First, take the PCC architecture shown in Figure 1 as an example to illustrate that the Rx interface between the AF entity and the PCRF entity (that is, the policy server) supports the SOAP or REST protocol session flow.

 FIG. 3 is a flow chart of session management during the initial provision of session information (ie, during the establishment of the AF session), including the following steps 301 to 303:

 Step 301. The user equipment UE is attached to the network, initiates an attach procedure, or the UE initiates another PDN connection establishment process, and the UE interacts with the AF entity to perform media negotiation. The AF entity determines business related information.

Step 302. The AF entity initiates an AF session establishment process to the PCRF entity to establish an AF session. For AF session identification information and business information. The AF session identification information may be assigned to the AF entity by the PCRF entity at this time by the AF entity or in an interaction before this.

 In this step, the AF entity sends a first HTTP request message to the PCRF, where the first HTTP request message carries the AF session identification information and the service information. In addition, the first HTTP request message can also carry an explicit AF session establishment indication. The AF entity's own Uniform Resource Locator (URL) (denoted as URL 1) can also be carried in the message. The AF entity may construct a PCRF URL for addressing the PCRF according to the UE's IP address, user identification (if any), PDN information, and domain identification information.

 The AF session identifier information may be a globally unique identifier for the AF session, or may be a combination of the service session identifier and other information that uniquely identifies the AF session. In this embodiment, the AF session identifier information is a service. When combining a session ID with other information, you can use any of the following combinations:

 1) a service session identifier and an IP address of the UE, where the service session identifier is an identifier that can uniquely identify the AF session in the case of an IP address of the same UE;

 2) a service session identifier, an IP address of the UE, and an IP domain identifier, where the service session identifier is an identifier that can uniquely identify the AF session in the case of an IP address and an IP domain identifier of the same UE;

 3) a service session identifier, an IP address of the UE, and a PDN identifier of the packet data network, where the service session identifier is an identifier that can uniquely identify the AF session in the case of an IP address and a PDN identifier of the same UE.

 4) a service session identifier, a user identifier, where the service session identifier is an identifier that can uniquely identify the session of the AF in the case of an IP address and a user identifier of the same UE.

 Step 303. The PCRF entity saves the service information provided by the AF entity, and the PCRF entity returns a response of the first HTTP request message to the AF entity.

 In the above process, for the processing of the TCP connection between the AF entity and the PCRF entity, the following two schemes can be used:

1) Use the HTTP persistent connection mechanism. When the step 302 is performed, if the AF entity has a TCP connection with the PCRF (referred to as the first TCP connection in this embodiment), the AF entity uses The existing first TCP connection sends a first HTTP request message to the PCRF. If the first TCP connection does not exist, the AF and the PCRF first establish a first TCP connection, and then send the first HTTP request message. After the step 303 is performed, the first TCP connection is not disconnected.

 2) Do not use the HTTP persistent connection mechanism. When step 302 is performed, the AF entity establishes a first TCP connection with the PCRF entity, and then sends a first HTTP request message. After performing step 303, the first TCP connection is disconnected.

 In the above process, the AF session identification information used to identify the AF session is assigned by the AF entity (if the AF session identification information is an independent global unique identifier, the AF session identification information is allocated by the AF; if the AF session identification information is a service session A combination of identification and other information, then the business session identifier is assigned to the AF). Of course, related information can also be assigned by the PCRF entity. If the AF session identification information is an independent globally unique identifier, it can also be assigned by the PCRF entity. That is, in step 302, the AF sends the first HTTP request message to the PCRF entity to carry only the service information (the service information includes the UE IP address, the IP domain identifier (optional), the user identifier (optional), and the PDN identifier (optional)) In step 303, the PCRF entity allocates a global AF session identifier to the AF session according to the service information, and sends the AF session identifier to the AF entity in the response of the first HTTP request message. If the AF session identification information is a combination of the service session identifier and other information, the service session identifier may also be assigned by the PCRF entity. That is, in step 302, the AF entity sends the first HTTP request message to the PCRF entity to carry only the service information (the service information includes the UE IP address, the IP domain identifier (optional), the user identifier (optional), and the PDN identifier (optional). In step 303, the PCRF entity allocates a service session identifier to the AF session according to the service information, and sends other information in the combination of the service session identifier and the AF session identifier information to the AF entity in the response of the first HTTP request message ( That is, AF session identification information).

 The AF may aggregate multiple pieces of information requesting to establish an AF session in an HTTP request message (for example, carrying service information corresponding to multiple AF sessions and AF session identification information (if AF session identification information is assigned by AF)), and the PCRF entity responds in HTTP The message may also aggregate the response information of the multiple AF sessions that are requested to be established (for example, the AF session identification information allocated by the PCRF entity for each AF session (if the AF session identification information is allocated by the P entity CRF)).

Figure 4 shows the session management process during the session information update process (that is, during the AF session modification process). The figure includes the following steps 401 to 403:

 Step 401. The UE interacts with the AF entity to perform media renegotiation. AF determines business related information.

 Step 402: The AF entity initiates an AF session modification process to the PCRF entity (ie, modifies the AF session established in FIG. 3) to provide updated service information.

 In this step, the AF entity sends a third HTTP request message to the PCRF entity, carrying the updated media description information and the AF session identification information defined in FIG. In addition, the third HTTP request message can also carry an explicit AF session modification indication.

 Step 403. The PCRF entity determines the previously saved service information according to the AF session identification information, and performs corresponding update. The PCRF entity returns a response to the third HTTP request message to the AF entity.

 In the above process, for the processing of the TCP connection between the AF entity and the PCRF entity, the following two schemes can be used:

 1) Use the HTTP persistent connection mechanism. That is, when step 402 is performed, AF uses the existing TCP connection (i.e., the first TCP connection) to send a third HTTP request message to the PCRF entity. After performing step 403, the first TCP connection is also not broken.

 2) Do not use the HTTP persistent connection mechanism. When step 402 is performed, the AF entity sends a third HTTP request message after establishing a first TCP connection with the PCRF entity. After performing step 403, the first TCP connection is broken.

 The AF may aggregate multiple information for modifying the AF session in an HTTP request message (for example, carrying service information corresponding to multiple AF sessions and AF session identification information), and the PCRF entity may aggregate multiple requests for modification in the HTTP response message. The response information of the AF session.

Figure 5 is a flow chart of session management during the termination of the AF session, including the following steps 501 to 503: Step 501. The UE interacts with the AF entity to terminate the session.

 Step 502. The AF entity initiates an AF session termination process to the PCRF entity, and terminates the establishment of FIG.

AF session.

The specific implementation of the step is: the AF entity sends a third HTTP request message to the PCRF entity, Carrying the session termination indication and the AF session identification information defined in FIG. The third HTTP request message may also carry an explicit AF session termination indication.

 Step 503. The PCRF entity determines the previously saved service information according to the AF session identification information, and deletes it. The PCRF entity returns a response to the third HTTP request message to the AF entity.

 In the above process, for the processing of the TCP connection between the AF entity and the PCRF entity, the following two schemes can be used:

 1) Use the HTTP persistent connection mechanism. When step 502 is performed, the AF entity sends a third HTTP request message to the PCRF entity using the existing TCP connection (ie, the first TCP connection). After performing step 503, the first TCP connection is also not broken.

 2) Do not use the HTTP persistent connection mechanism. When step 502 is performed, the AF entity sends a third HTTP request message after establishing a first TCP connection with the PCRF entity. After performing step 503, the first TCP connection is broken.

 The AF entity may aggregate information of multiple request termination AF sessions in an HTTP request message (for example, carrying service information corresponding to multiple AF sessions and AF session identification information), and the PCRF entity may also aggregate the request termination in the HTTP response message. Response information for AF sessions.

FIG. 6 is a flowchart of session management in a bearer layer event reporting process, including the following steps 601 to

603:

 Step 601. The PCRF entity perceives a bearer layer event, such as an IP-CAN type change.

 Step 602: The PCRF entity reports the bearer layer event related to the AF session established in Figure 3 to the AF entity.

 In this step, the PCRF entity sends a second HTTP request message to the AF entity, where the bearer layer event and the AF session identification information defined in Embodiment 1 are carried. The URL used to locate the AF entity in the second HTTP message is the URL1 provided by the AF entity in FIG.

 Step 603. The AF entity determines an application layer session corresponding to the UE according to the AF session identification information, and learns a bearer layer event corresponding to the application layer session. Thereby performing related processing. The AF entity returns a response to the second HTTP request message to the PCRF entity.

In the above process, for the processing of the TCP connection between the PCRF entity and the AF entity, Use the following two options:

 1) Use the HTTP persistent connection mechanism. When step 602 is performed, if a TCP connection (ie, a second TCP connection) already exists between the PCRF entity and the AF entity, the PCRF entity sends the second HTTP request to the AF entity by using the existing TCP connection (ie, the second TCP connection). The message, if there is no TCP connection between the PCRF entity and the AF entity, the PCRF entity sends a second TCP request message after establishing a second TCP connection with the AF entity. After performing step 603, the second TCP connection is also not broken.

 2) Do not use the HTTP persistent connection mechanism. When step 602 is performed, the PCRF establishes a second TCP connection with the AF and sends a second HTTP request message. After performing step 603, the second TCP connection is broken.

 The PCRF entity may aggregate event information of multiple AF sessions in an HTTP request message (for example, carrying event information corresponding to multiple AF sessions and AF session identification information), and the AF entity may also aggregate multiple AF session events in the HTTP response message. Evaluated response information.

 Figure 7 is a flow chart of session management during the IP-CAN session termination process (the PCRF entity notifies the AF entity that the IP-CAN session termination can be considered as a special bearer layer event report), and includes the following steps 701 to 703:

 Step 701. The PCRF entity perceives the termination of the IP-CAN session.

 Step 702. The PCRF entity notifies the AF entity of the loss of the transmission resource associated with the AF session established in FIG.

 In this step, the PCRF entity sends a second HTTP request message to the AF entity, carrying the request session termination indication and the AF session identification information defined in FIG. The URL used to address the AF entity in the second HTTP request message is URL1 provided by the AF entity in FIG.

 Step 703. The AF entity determines an application layer session corresponding to the UE according to the AF session identifier information, and learns that the transmission resource corresponding to the application layer session is lost. Thereby performing related processing. The AF entity returns a response to the second HTTP request message to the PCRF entity.

 In the above process, for the processing of the TCP connection between the PCRF entity and the AF entity, the following two schemes can be used:

1) Use the HTTP persistent connection mechanism. When performing step 702, if the PCRF is real The physical connection with the AF entity already exists (ie, the second TCP connection), and the PCRF entity sends the second HTTP request message to the AF entity by using the existing TCP connection (ie, the second TCP connection), if the PCRF entity and the AF entity If there is no TCP connection, the PCRF entity sends a second HTTP request message after establishing a second TCP connection with the AF entity. After performing step 703, the second TCP connection is also not broken.

 2) Do not use the HTTP persistent connection mechanism. When step 702 is performed, the PCRF entity sends a second TCP request message after establishing a second TCP connection with the AF entity. After performing step 703, the second TCP connection is broken.

 The PCRF can aggregate the transmission resource loss event information of multiple AF sessions in an HTTP request message (for example, carrying event information corresponding to multiple AF sessions and AF session identification information), and the AF entity can also aggregate multiple AFs in the HTTP response message. The response information reported by the session event.

The following takes the PCC architecture shown in Figure 2 as an example to illustrate the session flow between the AF entity and the PCRF entity.

 FIG. 8 is a flow chart of session management during the initial provision of session information (ie, during the establishment of the AF session), including the following steps 801 to 805:

 Step 801. The user equipment UE attaches to the network, initiates an attach procedure, or after the UE initiates another PDN connection establishment process, the UE interacts with the AF to perform media negotiation, and the AF entity determines service related information.

 Step 802. The AF entity initiates an AF session establishment process to the PC, requesting to establish an AF session, providing

AF session identification information and business information. The AF session identification information may be assigned by the AF entity at this time or by a PC in an earlier interaction.

In this step, the AF entity sends a first HTTP request message to the PCRF entity, where the first HTTP request message carries the AF session identification information and the service information. The PC saves the AF session identification information and service information therein. In addition, the first HTTP message may also carry an explicit AF session establishment indication. AF's own Uniform Resource Locator (URL) (denoted as URL2) can also be carried in the message. The AF entity may construct a URL of the PC for addressing the PC based on the IP address of the UE, the user identification (if present), the PDN information, and the domain identification information. The AF session identifier information may be a globally unique identifier for separately identifying the AF session, or may be a combination of the service session identifier and other information to uniquely identify the AF session. In this embodiment, the AF session identifier information is When a combination of a service session identifier and other information, the AF session identification information may be represented by any combination of the following:

 1) a service session identifier and an IP address of the UE, where the service session identifier is an identifier that can uniquely identify the session of the AF in the case of an IP address of the same UE;

 2) a service session identifier, an IP address of the UE, and an IP domain identifier, where the service session identifier is an identifier that can uniquely identify the AF session in the case of an IP address and an IP domain identifier of the same UE;

 3) a service session identifier, an IP address of the UE, and a PDN identifier of the packet data network, where the service session identifier is an identifier that can uniquely identify the AF session in the case of an IP address and a PDN identifier of the same UE.

 4) a service session identifier, a user identifier, where the service session identifier is an identifier that can uniquely identify the AF session in the case of an IP address and a user identifier of the same UE.

 Step 803. The PC initiates an AF session establishment procedure to the PCRF entity to request an AF session to provide service information.

 In this step, the AF entity sends a Diameter Authentication and Authorization Request (AAR) message to the PCRF entity, and the AAR message carries the AF session identification information, the Diameter session identifier, and the media information description. And, the PC saves the correspondence between the Diameter session identifier and the AF session identification information in step 802. The PC may not directly save the AF session identification information, but may save the correspondence between the Diameter session identifier and the AF session identification information in step 802. (For example, the PC can push out the Diameter session identifier according to the AF session identification information according to a fixed algorithm, so that when the PC receives the Diameter session identifier in the future, the corresponding AF session identification information can be pushed out according to the algorithm.). In addition, the PC also stores the correspondence between URL2 and the Diameter session ID.

 Step 804. The PCRF entity saves the service information, and the PCRF entity returns a Diameter AAA message to the PC.

Step 805. The PC returns a response of the first HTTP request message to the AF entity entity. In the above process, for the processing of the TCP connection between the AF entity and the PC, the following two schemes can be used:

 1) Use the HTTP persistent connection mechanism. When the step 802 is performed, if the AF entity has a TCP connection with the PC (that is, the first TCP connection), the AF entity sends the first HTTP request message to the PC by using the existing TCP connection, and if there is no TCP connection, the AF entity The first HTTP request message is sent after establishing a TCP connection (ie, the first TCP connection) with the PC. After performing step 805, the first TCP connection is also not broken.

 2) Do not use the HTTP persistent connection mechanism. When step 802 is performed, the AF entity sends a first HTTP request message after establishing a first TCP connection with the PC. After performing step 805, the first TCP connection is broken.

 In the above process, the AF session identification information used to identify the AF session is assigned by the AF entity. (If the AF session identification information is an independent global unique identifier, the AF session identifier is assigned by the AF; if the AF session identification information is a service When the session identifier and other information are combined, then the service session identifier is assigned to the AF). Of course, relevant information can also be assigned by the PC. (1) If the AF session identification information is an independent globally unique identifier, then the globally unique identifier can also be assigned by the PC. In step 802, the AF entity sends the first HTTP request message to the PC to carry only the service information (the service information includes the UE IP address, the IP domain identifier (optional), the user identifier (optional), and the PDN identifier (optional)) In step 803, the PC allocates a global AF session identifier to the AF session according to the service information, and the PC saves the correspondence between the Diameter session identifier and the AF session identifier assigned by the PC. In step 805, the PC returns an AF session identifier to the AF in response to the first HTTP request message. (2) If the AF session identification information is a combination of the service session identifier and other information, the service session identifier can also be assigned by the PC. In step 802, the AF entity sends the first HTTP request message to the PCRF entity to carry only the service information. The service information includes the UE IP address, the IP domain identifier (optional), the user identifier (optional), and the PDN identifier (optional). In step 803, the PC allocates a service session identifier to the AF session according to the service information, and the PC saves the correspondence between the Diameter session identifier and the service session identifier and other information combination (ie, AF session identifier information). In step 805, the PC returns other information (i.e., AF session identification information) in the combination of the service session identifier and the AF session identifier information to the AF entity in response to the first HTTP request message.

The AF entity can aggregate multiple requests to establish an AF session information in an HTTP request message. (For example, carrying service information corresponding to multiple AF sessions and AF session identification information (if AF session identification information is assigned by AF)), the PC may also aggregate response information of multiple AF sessions requested in the HTTP response message (such as PC). AF session identification information assigned to each AF session (if the AF session identification information is assigned by the PC).

 FIG. 9 is a flow chart of the session management process during the session information update process, that is, during the AF session modification process, and includes the following steps 901 to 905:

 Step 901. The UE interacts with the AF entity to perform media renegotiation, and the AF entity determines service related information.

 Step 902. The AF entity initiates an AF session modification process to the PC to modify the AF session established in FIG. 8 to provide AF session identification information and service information.

 In this step, the AF entity sends a third HTTP request message to the PC, where the third HTTP request message carries the AF session identification information and the media information description defined in FIG. Furthermore, the third HTTP request message may also carry an explicit AF session modification indication. The PC determines the previously saved service information based on the AF session identification information and updates it.

 Step 903. The PC determines a corresponding Diameter session according to the AF session identification information. The PC initiates an AF session modification process to the PCRF to provide service information.

 In this step, the AF sends a Diameter AAR message to the PCRF entity, where the AAR message carries the corresponding Diameter session entity identifier and media information description.

 Step 904. The PCRF entity saves the service information and updates according to the Diameter session identifier, and the PCRF entity returns a Diameter Authentication 4 (Authentication and Authorization Answer, AAA for short message) message to the PC;

 Step 905. The PC returns a response of the third HTTP request message to the AF entity.

 In the above process, for the processing of the TCP connection between the AF entity and the PC, the following two schemes can be used:

 1) Use the HTTP persistent connection mechanism. AF entity uses existing TCP connection

(ie, the first TCP connection) sends a third HTTP request message to the PC.

2) Do not use the HTTP persistent connection mechanism. When step 902 is performed, the AF entity first sends a third HTTP request message after establishing a first TCP connection with the PC. After performing step 905, The first TCP connection is broken.

 The AF may aggregate multiple information for modifying the AF session in an HTTP request message (for example, carrying service information corresponding to multiple AF sessions and AF session identification information), and the PC may aggregate the multiple AFs requested to be modified in the HTTP response message. The response information of the session.

Figure 10 is a flowchart of session management during the termination of the AF session, including the following steps 1001 to 1005:

 Step 1001. The UE interacts with the AF entity to terminate the session.

 Step 1002. The AF entity initiates an AF session termination process to the PC to terminate the AF session established in FIG. In this step, the AF entity sends a third HTTP request message to the PC, where the third HTTP request message carries the AF session identification information and the session termination indication defined in FIG.

 Step 1003: The PC determines a corresponding Diameter session according to the AF session identification information. The PC initiates an AF session termination process to the PCRF entity.

 In this step, the AF entity sends a Diameter Session Termination Request (STR) message to the PCRF, and the STR message carries the corresponding Diameter session identifier.

 Step 1004. The PCRF entity determines that the service information is saved and deletes according to the Diameter session identifier, and the PCRF entity returns a Session Termination Answer (STA) message to the PC.

 Step 1005. The PC deletes the corresponding service information, and the PC returns a response of the third HTTP request message to the AF entity.

 In the above process, for the processing of the TCP connection between the AF entity and the PC, the following two schemes can be used:

 1) Use the HTTP persistent connection mechanism. The AF entity sends a third HTTP request message to the PC using the existing TCP connection (ie, the first TCP connection).

2) Do not use the HTTP persistent connection mechanism. When step 1002 is performed, the AF entity first sends a third HTTP connection message after establishing a first TCP connection with the PC. After performing step 1005, The first TCP connection is broken.

 The AF may aggregate information of multiple request termination AF sessions in an HTTP request message (for example, carrying service information corresponding to multiple AF sessions and AF session identification information), and the PC may aggregate multiple AFs that are requested to be terminated in the HTTP response message. The response information of the session.

Figure 11 is a flow chart of session management during the bearer layer event reporting process, including the following steps 1101 to 1105:

 Step 1101. The PCRF entity perceives a bearer layer event, such as an IP-CAN type change.

 Step 1102: The PCRF entity reports the AF session-related bearer layer event established in Figure 8 to the PC. In this step, the PCRF entity sends a Diameter re-authentication request to the AF entity.

(Re-Authentication Request, RAR for short) message, carrying the bearer layer event and the Diameter session identifier defined in step 803.

 Step 1103: The PC determines the AF session identification information according to the Diameter session identifier. The PC reports the bearer layer event to the AF.

 In this step, the PC sends a second HTTP request message to the AF entity, where the bearer layer event and the corresponding AF session identifier information are carried. The URL used to address the AF in the second HTTP request message is URL2 provided by AF in FIG.

 Step 1104: The AF entity determines an application layer session corresponding to the UE according to the AF session identifier information, and learns the bearer layer event corresponding to the application layer session. Thereby performing related processing. The AF returns a response to the second HTTP request message to the PC.

 Step 1105. The PC returns a Diameter Re-Authentication Answer (RAA) message to the PCRF entity.

 In the above process, for the processing of the TCP connection between the PC and the AF entity, the following two schemes can be used:

 1) Use the HTTP persistent connection mechanism. When performing step 1103, if PC and

If the AF entity already has a TCP connection (ie, a second TCP connection), the PC sends an second HTTP request message to the AF by using the existing TCP connection. If there is no TCP connection, the PC first sends a second TCP connection with the AF and then sends the second HTTP connection message. The second HTTP request message. After performing step 1104, the second TCP connection It does not disconnect.

 2) Do not use the HTTP persistent connection mechanism. When step 1103 is performed, the PC first sends a second TCP request message after establishing a second TCP connection with the AF entity. After performing step 1104, the second TCP connection is broken.

 The PC may aggregate event information of multiple AF sessions in an HTTP request message (for example, carrying event information corresponding to multiple AF sessions and AF session identification information), and the AF may also aggregate multiple AF session events in the HTTP response message. Answer the message.

Figure 12 is a flowchart of the session management in the IP-CAN termination process (the PCRF entity notifies the AF entity that the IP-CAN session termination can be considered as a special bearer layer event report), and includes the following steps 1201 to 1205:

 Step 1201. The PCRF entity perceives the termination of the IP-CAN session.

 Step 1202: The PCRF entity sends a Diameter Termination Session Request (ASR) message to the PC, where the Diameter session identifier is carried;

 Step 1203. The PC returns a Diameter termination session response to the PCRF entity (Abort Session

Answer, referred to as ASA) message.

 Step 1204. The PC sends a Diameter STR message to the PCRF entity, carrying the Diameter session identifier.

 Step 1205. The PCRF entity returns a Diameter STA message to the PC.

 Step 1206. The PC determines corresponding AF session identification information according to the Diameter session message. The PC notifies the AF entity that the transmission resources associated with the AF session established in Figure 8 are lost. This step can be triggered by step 1202 or step 1205.

 In this step, the PC sends a second HTTP request message to the AF entity, where the request carries the session termination indication and the corresponding AF session identification information. The URL for addressing AF in the second HTTP message is URL1 provided by AF in FIG.

Step 1207: The AF entity determines an application layer session corresponding to the UE according to the AF session identifier information, and learns that the transmission resource corresponding to the application layer session is lost. Thereby performing related processing. The AF entity returns a response to the second HTTP request message to the PC. In the above process, for the processing of the TCP connection between the PC and the AF entity, the following two schemes can be used:

 1) Use the HTTP persistent connection mechanism. When the step 1106 is performed, if the PC and the AF entity already have a TCP connection (ie, a second TCP connection), the PC sends an second HTTP request message to the AF entity by using the existing TCP connection. If there is no TCP connection, the PC first Sending a second HTTP request message after establishing a second TCP connection with the AF. After performing step 1107, the second TCP connection is also not broken.

 2) Do not use the HTTP persistent connection mechanism. When step 1106 is performed, the PC first sends a second TCP connection message after establishing a second TCP connection with the AF. After performing step 1107, the second TCP connection is broken.

 The PC may aggregate the transmission resource loss event information of multiple AF sessions in an HTTP request message (for example, carrying event information corresponding to multiple AF sessions and AF session identification information), and the AF may also aggregate multiple AF sessions in the HTTP response message. The response information reported by the event.

 Optionally, in the foregoing step 302 and in step 802, the content of the first HTTP request message sent by the AF entity to the PCRF entity and the PC respectively is described in the XML language as follows (Example 1):

<AAR command>

 <Framed-IP-Address Framed-IP-Address=" ... ">< Framed-IP-Address>

 <Framed-IPv6-Prefix Framed-IPv6-Prefix=" ... ' ' >< Fr amed-ΙΡνό -Prefix>

 <Subscriptions-Id Subscriptions-ID="... "></Subscription-Id>

 <Called-Station-Id Called-Station-ID="... "></Called-Station-Id>

 <Service-Session-Id Service-Session-ID="... "></Service-Session-Id>

 <IP-Domain-Id IP-Domain-ID="... ">< IP-Domain-Id>

 <AF-Application-Identifier AF-Application-Identifier=" ... "></AF-Application-Identifier> <Media-Component-Description>

 <Media-Component-Number

 Media- Component-Number= ' ' ... ' ' >< Media- Component-Number>

 <Media-Sub-Component>

 <Flow-Number Flow-Number= ' ' ... ' ' >< Flow-Number>

 <Flow-Description Flow-Description=" ... ">< Flow-Description>

 <Flow-Status Flow-Status="... ">< Flow-Status>

 <Flow-Usage Flow-Usage=" ... ">< Flow-Usage>

 <Max- equested-Bandwidth-UL

 Max-equested-Bandwidth-UL=" ... ">< Max- eqeusted-Bandwidth>

<Max- equested-Bandwidth-DL Max-equested-Bandwidth-DL=" ... ">< Max- equested-Bandwidth-DL>

 <AF- Signalling-Protocol AF-Signalling-Protocol=" ... "></AF-Signalling-Protocol> < Media-Sub-Component>

 <AF-Application-Identifier AF-Application-Identifier=" ... "></AF-Application-Identifier> <Media-Type Media-Type=" ... ">< Media-Type>

 <Max- equested-Bandwidth-UL

Max-equested-Bandwidth-UL=" ... ">< Max- eqeusted-Bandwidth-UL>

 <Max- equested-Bandwidth-DL

Max-equested-Bandwidth-DL=" ... ">< Max- equested-Bandwidth-DL>

 <Min-Requested-Bandwidth-UL

 Min-Requested-Bandwidth-UL=" ... ">< Min-Reqeusted-Bandwidth-UL>

 <Min-Requested-Bandwidth-DL

Min-Requested-Bandwidth-DL=" ... ">< Min-Requested-Bandwidth-DL>

 <Flow-Status Flow-Status="... ">< Flow-Status>

 <Reservation-Priority Reservation-Priority^" ... ">< Reservation-Priority>

<RS-Bandwidth RS-Bandwidth="... ">< RS-Bandwidth>

 <RR-Bandwidth RR-Bandwidth=" ... ">< RR-Bandwidth>

 <Codec-Data Codec-Data="... "></Codec-Data>

 < Media-Component-Description>

 <Service-Info-Status Service-Info-Status=" ... "></Service-Info-Status>

 <AF-Charging-Identifier AF-Charging-Identifier=" ... "></AF-Charging-Identifier>

 <SIP-Forking-Indication SIP-Forking-Indication="... "></SIP-Forking-Indication>

<Specific-Action Specific-Action= ^M ... "></Specifici-Action>

 </AAR command>

 In step 302 and in step 802, the contents of the first HTTP request message sent by the AF entity to the PCRF entity and the PC, respectively, are described in the JSON language as follows (Example 2):

{ "AAR":

 {

 "Framed-IP-Address": "Valuel",

 , ' Framed-IPv6 -Prefix": "Value2 ' ' ,

 "Subscription-Id": "Value3",

 "Called- Station-Id": "Value4",

 "Service-Session-Id": "Value5",

 "IP-Domain-Id": "Value6",

 "AF-Application-Identifier": "Value7",

 "Media-Component-Description":

 {

 "Optional": "YES"

 "Media-Component-Number": "Value8",

"AF-Application-Identifier": "Value9", "Media-Type": "ValuelO",

 "Max-equested-Bandwidth-UL": "Valuel l",

 "Max-equested-Bandwidth-DL": "Valuel2",

 "Min-Requested-Bandwidth-UL": "Valuel3",

 "Min-Requested-Bandwidth-DL": "Valuel4"

 "Flow-Status": "Value 15

 "Reservation-Priority": "Valuel6",

 "RS-Bandwidth": "Valuel7",

 "RR-Bandwidth": "Valuel8",

 "Codec-Data": "Valuel9",

 "Media-Sub-Component":

 {

 "Flow-Number": "Value20",

 "Flow-Status": "Value21",

 "Flow-Usage": "Value22",

 "Max-Requested-Bandwidth-UL": "Value23

 "Max-Requested-Bandwidth-DL": "Value24",

 "AF-Signal-Protocol": "Value25",

 "Flow-Description": "Value26",

}

 "Service-Info- Status": "Value27"

 "AF-Charging-Identifier": "Value28"

 "SIP-Forking-Indication": "Value29"

 " Specific- Action": "Value30"

 }

 }

 The Framed-IP-Address and the Framed-IPv6-Prefix are respectively used to carry the IPv4 address and IPv6 address of the UE. (The UE only uses one address to access the service at the same time, so the two AVPs are not carried at the same time). Service-Session-Id is used to carry the service session identifier. The IP-Domain-Id is used to carry the IP domain identifier, and the Called-Station-Id is used to carry the PDN identifier. The Subscription-Id is used to carry the user ID.

In step 402 and in step 902, the contents of the third HTTP request message sent by the AF entity to the PCRF entity and the PC respectively are described in XML language as follows, similar to Example 1, and the JSON language description is similar to Example 2 as follows. If the Service-Session-Id of step 302 or step 802 is a globally unique identifier (ie, an AF session identifier), then Framed-IP-Address, Framed-IPv6-Prefix, Called-Station-Id, Subscription-Id, IP-Domain- Parameters such as Id are not carried; if step 302 or If the Service-Session-Id of step 802 is not a globally unique identifier, the same parameters as in step 302 and step 802 are carried to uniquely identify the AF session.

 In step 502 and in step 1002, the contents of the third HTTP request message sent by the AF entity to the PCRF entity and the PC, respectively, are described in XML language as follows (Example 3):

 <ST command>

 <Framed-IP-Address Framed-IP-Address= " ... ">< F ramed-IP-Address>

 <Framed-IPv6-Prefix Framed-IPv6-Prefix= " ... ">< F ramed-IPv6-Prefix>

 <Subscriptions-Id Subscriptions-ID= " ... "></Subscription-Id>

 <Called-Station-Id Called-Station-ID=" ... "></Called-Station-Id>

 <Service-Session-Id Service-Session-ID= " ... "></Service-Session-Id>

 <IP-Domain-Id IP-Domain-ID="■■■ ">< IP-Domain-Id>

 <Termination-Cause Termination-Cause ="■■ . "></Termination-Cause >

 </STA command>

 In step 502 and in step 1002, the contents of the third HTTP request message sent by the AF entity to the PCRF entity and the PC respectively are described in the JSON language as follows (Example 4)

 { "STR":

 {

 "Framed-IP-Address": "Valuel",

 , ' Framed-IPv6 -Prefix": "Value2 ' ' ,

 "Subscription-Id": "Value3",

 "Called- Station-Id": "Value4",

 "Service-Session-Id": "Value5",

 "IP-Domain-Id": "Value6",

 "Termination-Cause": "Value7",

 }

 }

 If the Service-Session-Id of step 302 or step 802 is a globally unique identifier (ie, an AF session identifier), then Framed-IP-Address, Framed-IPv6-Prefix, Called-Station-Id, Subscription-Id, IP-Domain- The parameters such as Id are not carried; if the Service-Session-Id of step 302 or step 802 is not a globally unique identifier, the same parameters as in step 302 and step 802 are carried to uniquely identify the AF session.

In step 602 and in step 1103, the content of the second HTTP request message sent by the PCRF entity to the AF entity and the PC to the AF entity is described in the XML language as follows (Example 5): <RAR command> <Framed-IP-Address Framed-IP-Address=" ... "><Framed-IP-Address>

 <Framed-IPv6-Prefix Framed-IPv6-Prefix=" ... ' ' >< Fr amed-ΙΡνό -Prefix>

 <Subscriptions-Id Subscriptions-ID="... "></Subscription-Id>

 <Called-Station-Id Called-Station-ID="... "></Called-Station-Id>

 <Service-Session-Id Service-Session-ID="... "></Service-Session-Id>

 <IP-Domain-Id IP-Domain-ID="... ">< IP-Domain-Id>

<Specific-Action Specific-Action= ^M ... "></Specific-Action>

 <Abort-Cause Abort-Cause:"... "></Abort-Cause>

 <Access-Network-Charging-Identifier Access-Network-Charging-Identifier "></ Access-Network-Charging-Identifier >

 <Access-Network-Charging-Address Access-Network-Charging-Address ="... "></

Access-Network-Charging-Address>

 <Flows >

 <Media-Component-Number

 Media- Component-Number= ' ' ... ' ' >< Media- Component-Number>

 <Flow-Number Flow-Number= ' ' ... ' ' >< Flow-Number>

 <Final-Unit- Action Final-Unit- Action^" ... ">< Final-Unit-Action>

 < Flows>

 <IP-CAN-Type IP-CAN-Type=" ... ">< IP-CAN-Type>

 <RAT-Type RAT-Type>=" ... ">< RAT-Type>

 < RAR command>

 In step 602 and in step 1103, the contents of the second HTTP request message sent by the PCRF entity to the AF entity and the PC to the AF entity are described in the JSON language as follows (Example 6):

 { "RAR":

 {

 "Framed-IP-Address": "Valuel",

 , ' Framed-IPv6 -Prefix": "Value2 ' ' ,

 "Subscription-Id": "Value3",

 "Called- Station-Id": "Value4",

 "Service-Session-Id": "Value5",

 "IP-Domain-Id": "Value6",

 "Specific-Action": "Value7",

 "Abort-Cause": "Value8",

 "Access-Network-Charging-Identifier": "Value9",

 "Access-Network-Charging-Address": "ValuelO",

 "Flows":

 {

 "Media-Component-Number": "Valuel 1",

 "Flow-Number": "Valuel2",

" Final-Unit- Action": "Valuel3", }

 "IP-CAN-Type": "Valuel4",

 "RAT-Type": "Valuel5",

 }

 }

 If the Service-Session-Id of step 302 or step 802 is a globally unique identifier (ie, an AF session identifier), then Framed-IP-Address, Framed-IPv6-Prefix, Called-Station-Id, Subscription-Id, IP-Domain- The parameters such as Id are not carried; if the Service-Session-Id of step 302 or step 802 is not a globally unique identifier, the same parameters as in step 302 and step 802 are carried to uniquely identify the AF session.

In step 702 and in step 1103, the contents of the second HTTP request message sent by the PCRF entity to the AF entity and the PC to the AF entity are described in the XML language as follows (Example 7):

<ST command>

 <Framed-IP-Address Framed-IP-Address=" ... ">< Framed-IP-Address>

 <Framed-IPv6-Prefix Framed-IPv6-Prefix=" ... ' ' >< Fr amed-ΙΡνό -Prefix>

 <Subscriptions-Id Subscriptions-ID="... "></Subscription-Id>

 <Called-Station-Id Called-Station-ID="... "></Called-Station-Id>

 <Service-Session-Id Service-Session-ID="... "></Service-Session-Id>

 <IP-Domain-Id IP-Domain-ID="... ">< IP-Domain-Id>

 <Abort-Cause Abort-Cause:"... "></Abort-Cause>

 </ST command>

 In step 702 and in step 1103, the contents of the second HTTP request message sent by the PCRF entity to the AF entity and the PC to the AF entity are described in the JSON language as follows (Example 8):

 { "RAR":

 {

 "Framed-IP-Address": "Valuel",

 , ' Framed-IPv6 -Prefix": "Value2 ' ' ,

 "Subscription-Id": "Value3",

 "Called- Station-Id": "Value4",

 "Service-Session-Id": "Value5",

 "IP-Domain-Id": "Value6",

 "Abort-Cause": "Value7",

 }

 }

If the Service-Session-Id of step 302 or step 802 is a globally unique identifier (ie, an AF session) ID), Framed-IP-Address, Framed-IPv6-Prefix, Called-Station-Id, Subscription-Id, IP-Domain-Id, etc. are not carried; if the Service-Session-Id of step 302 or step 802 is not global The unique identifier then carries the same parameters as in steps 302 and 802 to uniquely identify the AF session.

Example 2

 The embodiment provides an application function (AF) entity, which supports both an HTTP client and an HTTP server, and can implement various functions of the AF in the above embodiment 1. The AF entity includes at least the following units.

 The first unit is configured to: when the AF entity establishes an AF session with the policy server, send a first HTTP request message to the policy server, and receive a response of the first HTTP request message returned by the policy server;

 The first unit carries the AF session identifier information in the first HTTP request message; or obtains the AF session identifier information from the response of the first HTTP request message returned by the policy server;

 The second unit is configured to: when receiving the bearer layer event of the AF session, the policy server sends the second HTTP request message carrying the AF session identifier information to the policy server Returning a response to the second HTTP request message.

 On the basis of the foregoing architecture, the AF entity may further include: a third unit, where the unit sends a third HTTP request message to the policy server when the AF and the policy server modify or terminate the AF session, where The third HTTP request message carries the AF session identification information, and receives a response of the third HTTP request message returned by the policy server.

It should be noted that, in the processing of the TCP connection between the AF entity and the policy server in this embodiment, the HTTP persistent connection mechanism may or may not be used. For example, in the first unit, when the AF entity and the policy server already have a TCP connection (ie, the first TCP connection), the first HTTP request message is sent by using the first TCP connection, and the first AF request message is not between the AF and the policy server. When a TCP connection is established, the first unit first establishes a first TCP connection with the policy server, and then sends a first HTTP request message. Similarly, in the third unit, there is already a TCP connection between the AF entity and the policy server. (ie, the first TCP connection), the first TCP connection message is sent by using the first TCP connection, and when the AF connection is not established between the AF and the policy server, the third unit first establishes a first TCP connection with the policy server, and then sends The third HTTP request message.

 The first unit is configured to: after receiving the response of the first HTTP request message sent by the policy server, the first TCP connection between the AF and the policy server may be disconnected. Similarly, after receiving the response of the third HTTP request message sent by the policy server, the third unit may also reserve or disconnect the first TCP connection between the AF and the policy server. It should be noted that the foregoing second unit is configured to: when receiving the second HTTP request message sent by the policy server, receive the second TCP connection between the policy server and the AF entity, correspondingly, The second unit also responds with a second TCP connection returning a second HTTP request message to the policy server.

 For the session management process between the foregoing AF entity and the policy server, refer to the corresponding content in the foregoing Embodiment 1, and details are not described herein again.

Embodiment 3 This embodiment provides a policy server that supports both an HTTP client and an HTTP server, and implements various functions of the policy server in Embodiment 1 above, and includes at least a first unit and a second unit. The first unit is configured to: receive a first HTTP request message that is sent by the AF entity and that carries the AF session identification information, and return a response of the first HTTP request message to the AF entity; or receive the first HTTP request message sent by the AF entity. And assigning AF session identification information to the AF session, and returning, to the AF entity, a response of the first HTTP request message carrying the AF session identification information.

 Preferably, the first unit is configured to: when receiving the first HTTP request message, receive the first TCP connection between the AF entity and the policy server, and correspondingly, use the first TCP connection. Returning the response of the first HTTP request message to the AF entity.

The second unit is configured to: when notifying the AF entity of the bearer layer event of the AF session, send a second HTTP request message to the AF entity, where the second HTTP request message carries the AF session identifier information, and receives the AF entity return The response of the second HTTP request message. Preferably, when the second unit sends the second HTTP request message, when the second TCP connection exists between the policy server and the AF, the second HTTP connection message is sent to the AF by using the second TCP connection, and the policy is When the second TCP connection is not established between the server and the AF, the second TCP connection is established with the AF, and the second HTTP request message is sent.

 It should be noted that, after receiving the response of the second HTTP request message sent by the AF entity, the foregoing second unit may reserve or disconnect the second TCP connection between the policy server and the AF entity.

 In practical applications, the foregoing policy server may be a PCRF entity or a PC. For the session management process between the PCRF entity or the PC and the AF entity, refer to the corresponding content in the foregoing Embodiment 1, and details are not described herein again.

Example 4

 The embodiment provides a protocol converter, which can be used as the policy server in the foregoing embodiment 1 for session management. The protocol converter includes at least the following units:

 The first unit is configured to: during the establishment of the AF session, the receiving AF entity sends the carried

The first HTTP request message of the AF session identification information is sent to the PCRF entity to send a Diameter Authentication 4 Authorization Request (AAR) message carrying a Diameter session identifier to request to establish a diameter session, and maintain the AF session identification information and the Diameter session identifier. Or the first HTTP request message sent by the AF entity, the AF session identification information is allocated to the AF session, and the Diameter authentication authorization request carrying the Diameter session identifier is sent to the PCRF entity. (AAR) message, requesting to establish a diameter session, and maintaining the correspondence between the AF session identification information and the Diameter session identifier.

 The second unit is configured to: receive a third HTTP request message that is sent by the AF entity and that carries the AF session identifier information, and send a Diameter AAR or Diameter STR message carrying the Diameter session identifier to the PCRF entity during the AF session modification or termination process. ;

The third unit is configured to: receive a Diameter RAR, ASR or STA message that is sent by the PCRF entity and carry the Diameter session identifier, and send a second HTTP request carrying the AF session identifier information to the AF, in the bearer layer event reporting process. Message. The embodiment of the present invention further provides a computer program, including program instructions, when the program instruction is executed by an application function entity, so that the application function entity can execute the above method.

 The embodiment of the invention further provides a computer program, comprising program instructions, when the program instruction is executed by the policy server, so that the policy server can execute the above method.

 Embodiments of the present invention also provide a carrier carrying any of the above computer programs.

In summary, the above embodiment solves the problem that the AF entity and the PCRF entity or the PC can perform bidirectional information transmission based on HTTP real time.

One of ordinary skill in the art will appreciate that all or a portion of the above steps may be accomplished by a program instructing the associated hardware, such as a read-only memory, a magnetic disk, or an optical disk. Alternatively, all or part of the steps of the above embodiments may also be implemented using one or more integrated circuits. Correspondingly, each module/unit in the above embodiment may be implemented in the form of hardware or in the form of a software function module. This application is not limited to any specific form of combination of hardware and software.

The above description is only a preferred embodiment of the present invention and is not intended to limit the scope of protection of the present invention. Any modifications, equivalent substitutions, improvements, etc., made within the spirit and scope of the present invention are intended to be included within the scope of the present invention.

Industrial applicability

 The embodiment of the invention solves the problem that the AF entity and the PCRF entity or the PC can perform two-way information transmission based on HTTP real-time.

Claims

claims 1. A session management method, the method includes: When the application function (AF) entity establishes an AF session with the policy server, the AF entity sends a first Hypertext Transfer Protocol (HTTP) request message to the policy server; Wherein, the AF entity sends the AF session identification information to the policy server through the first HTTP request message; or, the AF entity obtains the AF session identification information from the response of the first HTTP request message returned by the policy server. AF session identification information assigned by the policy server to the AF session; When the AF entity receives the second HTTP request message sent to the AF entity by the policy server notifying the AF entity of the bearer layer event of the AF session, the second HTTP request message carries the AF Session identification information; The AF entity returns a response to the second HTTP request message to the policy server. 2. The method of claim 1, wherein, The policy server is a policy and charging rule function (PCRF) entity or a protocol converter (PC). 3. The method according to claim 1 or 2, wherein, When the AF entity modifies or terminates the AF session, the AF entity sends a third HTTP request message to the policy server, where the third HTTP request message carries the AF session identification information; The AF entity receives the response to the third HTTP request message returned by the policy server. 4. The method according to claim 1 or 2, wherein the AF session identification information is a globally unique identification. 5. The method according to claim 1 or 2, wherein the AF session identification information is represented by any combination of the following: Service session identifier and UE’s IP address; Service session identifier, UE’s IP address and IP domain identifier; The service session identifier, the UE's IP address and the packet data network (PDN) identifier; the service session identifier and the user identifier. 6. The method of claim 1 or 2, wherein the AF entity supports both an HTTP client and an HTTP server, and the policy server supports both an HTTP client and an HTTP server. 7. The method of claim 3, wherein the AF entity sends the first HTTP request message or the third HTTP request message to the policy server, including: When the AF entity has a first Transmission Control Protocol (TCP) connection with the policy server, the AF entity uses the first TCP connection to send the first HTTP request message or the first HTTP request message to the policy server. The third HTTP request message; When the first TCP connection is not established between the AF entity and the policy server, the AF first establishes the first TCP connection with the policy server, and then sends the first HTTP request message or the third HTTP request. information. 8. The method of claim 7, wherein, After receiving the first HTTP request message or the response to the third HTTP request message sent by the policy server, the AF entity retains the first TCP connection between the AF entity and the policy server. ; or After receiving the first HTTP request message or the response to the third HTTP request message sent by the policy server, the AF entity disconnects the first TCP between the AF entity and the policy server. connect. 9. A session management method, the method includes: The policy server receives the first Hypertext Transfer Protocol (HTTP) request message carrying the AF session identification information sent by the application function (AF) entity, and returns a response to the first HTTP request message to the AF entity; or, receives the AF The first HTTP request message sent by the entity allocates AF session identification information to the AF session, and returns a response to the first HTTP request message carrying the AF session identification information to the AF entity; When notifying the AF entity of the bearer layer event of the AF session, sending a second HTTP request message to the AF entity, where the second HTTP request message carries the AF session identification information, and receiving the AF The response to the second HTTP request message returned by the entity. 10. The method of claim 9, wherein the policy server is a Policy and Charging Rules Function (PCRF) entity or a Protocol Converter (PC). 11. The method according to claim 9 or 10, wherein sending the second HTTP request message by the policy server to the AF entity includes: When the policy server and the AF entity already have a second TCP connection, the policy server uses the second TCP connection to send the second HTTP request message to the AF entity; the policy server and the When the AF entity does not establish the second TCP connection, the policy server first establishes the second TCP connection with the AF entity, and then sends the second HTTP request message. 12. The method of claim 11, further comprising: After the policy server receives the response to the second HTTP request message sent by the AF entity, retain the second TCP connection between the policy server and the AF entity; or After receiving the response to the second HTTP request message sent by the AF entity, the policy server disconnects the second TCP connection between the policy server and the AF entity. 13. The method of claim 10, wherein the policy server is a PC, and after the policy server receives the first HTTP request message, the method further includes: the PC sends a diameter authentication authorization request to the PCRF entity. (AAR) message, requesting the establishment of a Diameter session, the AAR message carries a Diameter session identifier, and the PC maintains the corresponding relationship between the AF session identifier information and the Diameter session identifier. 14. The method of claim 13, further comprising: the policy server receiving a third HTTP request message carrying the AF session identification information sent by the AF entity to the PC, and the PC sends a request to the PCRF The entity sends a Diameter AAR message or a Diameter Session Termination Request (STR) message, where the AAR or STR message carries the Diameter session identifier. 15. The method of claim 10, wherein when the policy server is a PC, the policy server sends a second HTTP request message to the AF entity, including: When the PCRF entity sends a Diameter re-authentication request (RAR), session termination request (ASR) or session termination response (STA) message carrying the Diameter session identifier to the PC, the PC sends a Diameter re-authentication request (RAR) carrying the Diameter session identifier to the AF entity. the second HTTP request message containing the AF session identification information. 16. An application function (AF) entity, including: The first unit is configured to: when the AF entity establishes an AF session with the policy server, send a first Hypertext Transfer Protocol (HTTP) request message to the policy server and receive the first HTTP request returned by the policy server. response to the message; Wherein, the first unit is configured to: carry AF session identification information in the first HTTP request message, or obtain AF session identification information from the response of the first HTTP request message returned by the policy server; The second unit is configured to: receive a second HTTP request message carrying the AF session identification information sent by the policy server when notifying the AF entity of the bearer layer event of the AF session, and send the request message to the AF entity. The policy server returns a response to the second HTTP request message. 17. The AF entity as claimed in claim 16, further comprising: The third unit is configured to: when the AF entity modifies or terminates the AF session, sends a third HTTP request message to the policy server, where the third HTTP request message carries the AF session identification information, and receiving a response to the third HTTP request message returned by the policy server. 18. The AF entity as claimed in claim 17, wherein, The first unit is configured to: when the AF entity and the policy server already have a first Transmission Control Protocol (TCP) connection, use the first TCP connection to send the third transmission control protocol (TCP) connection to the policy server. An HTTP request message. When the first TCP connection is not established between the AF and the policy server, it first establishes the first TCP connection with the policy server and then sends the first HTTP request message; The third unit is set to: The AF entity and the policy server already exist. When a TCP connection is established, the first TCP connection is used to send the third HTTP request message to the policy server. When the first TCP connection is not established between the AF and the policy server, the AF first communicates with the policy server. The server establishes the first TCP connection and then sends the third HTTP request message. 19. The AF entity as claimed in claim 18, wherein, The first unit is further configured to: after receiving a response to the first HTTP request message sent by the policy server, retain the first TCP connection between the AF entity and the policy server, or Disconnect the first TCP connection between the AF entity and the policy server; The third unit is further configured to: after receiving a response to the third HTTP request message sent by the policy server, The first TCP connection between the AF entity and the policy server is retained, or the first TCP connection between the AF entity and the policy server is disconnected. 20. The AF entity according to any one of claims 16 to 19, wherein, The second unit is configured to: use a second TCP connection between the policy server and the AF entity to receive the second HTTP request message, and use the second TCP connection to send a request to the policy The server returns a response to the second HTTP request message. 21. A policy server, including: The first unit is configured to: receive a first Hypertext Transfer Protocol (HTTP) request message carrying AF session identification information sent by an application function (AF) entity, and return the first HTTP request message to the AF entity. Respond; or, receive the first HTTP request message sent by the AF entity, allocate AF session identification information to the AF session, and return to the AF entity a response to the first HTTP request message carrying the AF session identification information; The second unit is configured to: when notifying the AF entity of the bearer layer event of the AF session, send a second HTTP request message to the AF entity, where the second HTTP request message carries the AF session identification information, and receiving a response to the second HTTP request message returned by the AF entity. 22. The policy server of claim 21, wherein, The first unit is configured to: use the first TCP connection between the AF entity and the policy server to receive the first HTTP request message, and use the first TCP connection to send the message to the policy server. The AF entity returns a response to the first HTTP request message. 23. The policy server of claim 21, wherein, The second unit is configured to: when the policy server and the AF already have a second TCP connection, use the second TCP connection to send the second HTTP request message to the AF; the policy When the server has not established a second TCP connection with the AF, it first establishes a second TCP connection with the AF, and then sends the second HTTP request message. 24. The policy server of claim 23, wherein, The second unit is configured to: after receiving the response to the second HTTP request message sent by the AF entity, retain the second TCP connection between the policy server and the AF entity, or disconnect it. The second TCP connection between the folio policy server and the AF. 25. The policy server according to any one of claims 21 to 24, wherein, The policy server is a policy and charging rule function (PCRF) entity or a protocol converter (PC). 26. A protocol converter, including: The first unit is configured to: during the application function (AF) session establishment process, receive the first Hypertext Transfer Protocol (HTTP) request message carrying the AF session identification information sent by the AF entity, and send the request message to the policy and charging rule function. (PCRF) entity sends a Diameter Authentication Authorization Request (AAR) message to request the establishment of a Diameter session, the AAR message carries the Diameter session identifier, and maintains the corresponding relationship between the AF session identifier information and the Diameter session identifier; or, receive The first Hypertext Transfer Protocol (HTTP) request message sent by the AF entity allocates AF session identification information to the AF session, and sends an Authentication Authorization Request (AAR) message to the Policy and Charging Rules Function (PCRF) entity to request establishment. Diameter session, the AAR message carries the Diameter session identifier, and maintains the corresponding relationship between the AF session identifier information and the Diameter session identifier; The second unit is configured to: during the AF session modification or termination process, receive a third HTTP request message carrying the AF session identification information sent by the AF entity, and send a third HTTP request message carrying the diameter session identification information to the PCRF entity. Diameter AAR or Diameter Session Termination Request (STR) message; and The third unit is configured to: receive the PCRF entity during the bearer layer event reporting process Send a Diameter re-authentication request (RAR), session termination request (ASR) or session termination response (STA) message carrying the Diameter session identifier, and send the first message carrying the AF session identifier information to the AF. Two HTTP request messages. 27. A computer program, including program instructions. When the program instructions are executed by an application function entity, the application function entity can execute the method described in any one of claims 1-8. 28. A computer program, including program instructions. When the program instructions are executed by a policy server, the policy server can execute the method described in any one of claims 9-15. 29. A carrier carrying the computer program according to claim 27 or 28.