KR100841793B1 - Communication network - Google Patents

Abstract

A gateway node for use in a communication network is provided. The gateway node receives a request for a service, determines if the service can be provided, and generates a message as an indication of why the service cannot be provided if the service cannot be provided. To the service requester.

Gateway node, service request, application, communication message.

Description

Communication network {COMMUNICATION NETWORK}

The present invention relates to communication networks, and in particular, but not limited to, denying access to services.

A communication system is a facility that enables communication between two or more entities, such as user terminal equipment and / or network entities and other nodes associated with the communication system. The communication may include, for example, voice communication, electronic mail (email), text messages, data, multimedia, and the like. Communication may be provided by a wired and / or wireless communication interface. A feature of wireless communication systems is that they provide mobility to users of the system.

An example of a communication system that provides wireless communication is a public land mobile network (PLMN). An example of a wired system is a public switched telephone network (PSTN).

Communication systems typically operate in accordance with certain standards or specifications describing what the various elements of the system allow to do and how this should be achieved. For example, the standard or specification may define whether the user, or more specifically, the user equipment is provided with a circuit switched server, a packet switched server, or both. In addition, communication protocols and / or parameters that should be used for the connection are typically defined. For example, the manner in which communication is performed between user equipment and communication network elements is typically based on certain communication protocols. In other words, in order for communication user equipment to communicate through the system, a particular set of "rules" on which communication can be based needs to be defined.

The introduction of third generation (3G) communication systems will greatly increase the likelihood of accessing services on the Internet through mobile user equipment (UE) as well as other types of user equipment.

Various user equipment is known to those skilled in the art, such as computers (fixed or portable), mobile phones, personal data assistants (PDAs) or organizers, etc., which can be used to access the Internet to obtain services. Mobile user equipment, often referred to as a mobile station, may be defined as a means capable of communicating with another device, such as a base station or any other station of a mobile communication network, over an air interface.

The term "service" as used above and below will be understood to encompass any service or product used, desired by the user, requested or provided to the user. The term will include services provided or complementary. In particular, but not limited to, the term "service" includes Internet protocol multimedia IM services, conferencing, telephoning, gaming, presence, e-commerce and messaging, for example instant messaging. something to do.

General Packet Radio Service (GPRS) is a packet-based system that can be used in third generation standards environments or in conjunction with the Global System for Mobile Communications (GSM) standard. An intelligent service delivery (ICD) system is used to make the GPRS system service aware. ICD allows the definition of services. Each service is defined by a set of flow specifications. Each flow specification consists of, for example, an uplink IP (Internet Protocol) address or subnet and port number. For several application layer protocols such as Hyper Text Transfer Protocol (HTTP) and Wireless Application Protocol (WAP) used in GPRS systems, the ICD system allows the definition of flow specifications identified based on Uniform Resource Locater (URL). .

One of the core network elements used in ICD systems is GGSN (Gateway GPRS Support Node). GGSN is a gateway between a GPRS system and public or private data networks. In other words, all traffic between the GPRS system and public / private data networks can be analyzed in the GGSN. In the ICD system, GGSN is a serviceware that means supporting both service exchange and differential charging. This is based on the flow specifications used to classify the traffic. In addition, each flow specification includes parameters that control charging, so that the GGSN may charge differentially for each traffic flow based on a matching flow specification. The service exchange enables access to different public or private data networks under the same packet data protocal context.

However, this presents several problems. In particular, each flow specification is linked to one service. Part of the ICD system is the ability to allow or deny access to services. The mobile subscriber can subscribe or unsubscribe services. The GGSN is responsible for determining whether a mobile subscriber is authorized to use certain services. When the PDP context is activated, the GGSN receives a user profile from a subscription manager, a RADIUS server, etc., which lists all the services the mobile subscriber is authorized to use. If the mobile subscriber is not authorized to use the service, access to this service is denied. There is a second situation where access to the service is denied. If the mobile subscriber is a prepaid customer, the service may be denied because the mobile subscriber does not have enough funds to use the service.

Denial of service is easy to perform. GGSN simply discards all packets that meet the rejected flow specification. However, there is a problem that the mobile subscriber does not receive the appropriate notification as to why the flow specification was rejected. In terms of mobile subscribers, denial of service may be associated with problems in the network. Thus, the mobile subscriber can think that all the problems are network related and can make a reservation about whether to continue to subscribe to the service or to invest more money into his prepaid account.

Currently the ICD system proposes that traffic is redirected to another location instead of blocking traffic to a denied surface. Afterwards, the new location will notify the user why the service is denied. The new location may also provide a way to solve the problem. For example, if rejected because they were not subscribed to the service, the new location may provide a link to a subscription management system that allows the mobile subscriber to renew his subscriptions. If the service is denied because the prepaid account does not have sufficient funds, the new location may provide a link to a management system that allows the mobile subscriber to transfer funds to their prepaid account.

However, this solution is protocol dependent. If the denied service is WAP (or HTTP) based, the new location may be just a WAP (or HTTP) portal. The WAP (or HTTP) browser shows the information received from the page. However, this only works for WAP or HTTP based services. If the service uses some other protocol, the new location will not be able to use the WAP or HTTP protocol. In other words, the new location must use the same protocol as the originally denied service. For example, if a user attempts to access an email, the new location will not be able to return to the WAP or HTTP page. The e-mail application on the phone did not request a WAP or HTTP page and therefore could not accept it.

A further problem is that the proposed ICD solution works only in cases where the TCP (Transmission Control Protocol) connection has not yet been opened when the service is denied. After the TCP connection is opened, the prepaid account can be emptied. In addition, if the denied service is defined as a URL, the URL may not be part of the first TCP packets. Thus, in this case, the TCP connection can already be opened before the GGSN can determine that the service should be denied.

Embodiments of the present invention seek to address or alleviate at least some of the above problems.

According to one aspect of the present invention, there is provided a gateway node for use in a communication system, the node receiving a request for a service, determining whether the service can be provided, and if the service cannot be provided, A message is generated and sent to the service requester as an indication of why the service cannot be provided, and the node indicates the provider of the requested service as a source of the message.

According to another aspect of the present invention, there is provided a method comprising determining at a gateway node whether a requested service can be provided; If a service cannot be provided, sending a message to a service requester, wherein the message indicates a reason why the service is not provided and indicates a provider of the requested service as a source of the message; And discarding the traffic received from the requester at the gateway node.

According to a further aspect of the invention, there is provided a method, comprising: determining whether a requested service can be provided; If a service cannot be provided, providing a communication method comprising sending a push or ICMP message to a service requester, wherein the message indicates a cause for which the service is not provided and the source of the message; And indicates a provider of the requested service, wherein the message is sent by a node different from the provider of the requested service.

According to another aspect of the present invention, there is provided a method comprising: determining whether a requested service can be provided; If a service cannot be provided, generating a message indicating why the service is not provided and an address of a provider of the requested service; And transmitting the message to a service requester, wherein the message is sent from an address different from the address of the provider of the requested service.

In order to better understand the present invention, reference will be made only to the accompanying drawings by way of example with respect to how the present invention is effectively performed.

1 illustrates a schematic system in which embodiments of the present invention may be performed.

2 is a signal flowchart of a first embodiment of the present invention.

3 is a signal flow diagram of a second embodiment of the present invention.

Reference is made to FIG. 1, which schematically illustrates a system in which embodiments of the present invention may be performed. Embodiments of the present invention will be described in a GPRS system environment. However, embodiments of the present invention can be applied to any other communication system, which is not particularly limited to packet based systems. Embodiments of the present invention may also have applications in circuit switched systems. Embodiments of the present invention are particularly applicable to IP systems.

The system includes user equipment 2. The user equipment 2 can take any suitable form as described above. The user equipment 2 communicates with a radio access network (RAN) 8 via a wireless connection. Such a wireless connection may be at any suitable frequency such as, for example, a radio frequency. The radio access network 8 generally consists of a base station entity (often referred to as Node B). For the purposes of this document, the term "base station" will be used, which is intended to cover any suitable entity. The radio access network 8 also includes a control element. According to the standard, the control element will be referred to as a radio network controller (RNC) in the case of a UMTS (Universal Mobile Communication System) or a base station controller (BSC) in the case of a GSM system. The term "controller" is intended to cover any such control entity. In various configurations, the control function is provided separately from the base station, and one control entity can control multiple base stations. In other embodiments of the present invention, each base station may include some of the control functions. The radio access network 8 is in communication with the core network.

The core network 10 illustrated in FIG. 1 is a packet switched core network. The core network includes at least one serving GPRS support node (SGSN) used to switch packet switched transactions, and at least one GGSN 4 which acts as a switch at the point where the core network 10 is connected to external packet switched networks. ). Core network 10 also includes an HLR 12 (home location register) or similar entity. The HLR or similar entity stores subscription information that defines the services to which the user subscribes. Subscription information may be included in the HLR, in another database, or in a combination of the HLR and another database. Other databases may be outside the core network. In the embodiments to be described below, the subscription manager is described as including subscription information.

The GGSN 4 is connected with the application 14. This is schematic and is intended to show that the application 14 is provided by a separate network. However, the application is provided as part of the same network and may be provided as part of an IP multimedia subsystem or any other suitable network.

GGSN 4 is also connected to OCS (Online Billing System) 16. OCS 16 is seen to be external to core network 10. In alternative embodiments of the invention, the OCS 16 may be in the core network. OCS 16 may be coupled with billing system 18.

Reference is made to FIG. 2 showing signaling in a first embodiment of the present invention. The embodiment shown in FIG. 2 uses an existing IP Control Protocol (ICMP) (Internet Control Message Protocol) to notify the user equipment whether the destination traffic is blocked. In this way, an application at the user equipment attempting to use the service will receive a notification that the requested destination cannot be reached.

Steps S1a and S1b are interrelated and can be regarded as part of the same step. In step S1b, the PDP context is set up between the user equipment and the GGSN. In the setup of the PDP context, subscriber information is sent to the GGSN 4. In the embodiment shown in FIG. 2, subscriber manager 13 is shown as providing subscriber information to GGSN 4. However, as described in connection with FIG. 1, subscriber information may come from any suitable source. The subscriber information includes information about which service the user has subscribed to.

In step S2, the user equipment 2 sends a PDP request to the GGSN 4. The PDP request is for a specific destination, which is the application 14 in the embodiment of FIG. It should be understood that all packets should be routed through the GGSN.

In step S3, the GGSN performs traffic analysis. The packet will conform to a certain flow specification (F). The flow specification (F) is part of the service (S). From the information received locally from the subscriber manager 13 and stored locally in the GGSN, the GGSN 4 will determine if the service S has been denied to the mobile subscriber. As mentioned above, there are two reasons for denying service to a user. The first is when the user does not have enough funds, and the second is when the server does not subscribe to the service. If the user has not subscribed to the service, the GGSN may determine this from the information received from the service manager.

If the user is a prepaid user, the GGSN 4 needs to obtain information from the OCS 16 indicating whether there is sufficient funds for the particular service. This is schematically shown by the dashed line between the GGSN 4 and the OCS 16 and is referenced by S4. This can be done in a number of ways. The GGSN may request information from the OCS 16 as to whether there is sufficient funds for the requested service, which the OCS makes. Alternatively, the GGSN may be provided with information from the OCS about the funds available to the user, and the GGSN will make a determination as to whether the user has sufficient funds. Thus, step S4 is followed by an initial analysis of the service after the PDP context is set up, when the PDP request is received, to determine whether the user subscribed to the service or at any other suitable time. May occur.

If a service can be provided, the PDP request is forwarded to the application at step S5, and at step S6, data is sent from the application to the user equipment.

However, if it is determined that the service cannot be provided because the user does not have sufficient funds or the user has not subscribed to the service, the subsequent step will be (S7). However, packets received from user equipment will be discarded by the GGSN 4.

In step S7, the GGSN will send an ICMP message to the user equipment. When the GGSN sends an ICMP message, the GGSN will use the actual destination IP address as the source IP address. In this way, the user equipment thinks that the ICMP message was sent from the actual destination (i.e., the application) and that the GGSN is transparent to the user equipment. In other words, GGSN acts as a transparent proxy. ICMP packet S7 may include information indicating the reason for the denial of service, for example, insufficient funds or no service subscription. ICMP packets will have code values with different meanings associated with different code values.

In step S8, the application included in the user equipment will notify the user that the mobile subscriber cannot access the destination address. The application generates an error message, which is defined by the ICMP message to be displayed on the mobile station's display.

If packets sent from the user equipment are discarded without the ICMP messaging described above, the application and the user equipment can resend the packet because the user equipment assumes that the packet was lost due to some network problem. This consumes expensive radio resources even if the mobile subscriber cannot access the service, and the user will consume radio resources unnecessarily. In embodiments of the invention where retransmission control performed at the user equipment takes into account ICMP errors, the use of radio resources will be improved.

Embodiments of the present invention may only request changes in the GGSN implementation. ICMP is part of the standard IP protocol stack, so no changes are required at the user equipment. This implementation depends on the protocol used to access the service.

The GGSN may be modified to send an ICMP message to an unreachable destination (which is defined in the IETF standard, RFC 792, incorporated herein by reference). The code used in the message will have either a protocol unreachable value (code value 2) or a port unreachable value (code value 3). If the service is accessed via a protocol that does not use a port number, the first code value will be used. In other words, TCP or user datagram protocol (UDP) are not used. In embodiments of the present invention, the GGSN will act as a proxy host. The GGSN will use the destination IP address as the source address of the ICMP message.

In some embodiments of the invention, the GGSN may also use alternative code values. According to RFC 1812 (another IETF standard included herein for reference), if administrative filtering prevents access to a destination, the router may use a code value 13 for which communication is administratively prohibited. have.

In one embodiment of the present invention, the UE implementation can be changed. In this embodiment, a new code value and / or a new ICMP message type may be provided. In this proposal, two new code values will be provided for two cases where a denial of service occurs. The first code value will be for non-subscription, and the second code value is for when there is insufficient funds to access the service.

Embodiments of the present invention can be used as follows, in case the traffic associated with the rejected service is directed to a new location, as is already known, conventional solutions will be used. If the traffic cannot be redirected, embodiments of the present invention will be used.

Reference is made to FIG. 3 showing the signal flow in the second embodiment of the present invention. To simplify the signal flow, only user equipment and GGSN 4 are shown. In the embodiment shown in FIG. 3, a WAP push message is used to notify the user equipment whether traffic to a destination (eg, an application (not shown in FIG. 3 for clarity)) has been blocked. do. In this way, applications contained in user equipment attempting to use the service will receive a notification that the requested destination cannot be reached.

In step Tl, a PDP context is set up between the user equipment 2 and the GGSN 4. As in the embodiment shown in FIG. 2, the GGSN may receive information regarding user equipment subscriptions.

In step T2, the user equipment will begin sending packets, eg a PDP request, to the GGSN 4. This PDP request T2 is for the application. Naturally, the GGSN will receive a PDP request T2 because all packets need to go through the GGSN.

In step T3, the GGSN performs traffic analysis. This is as described in connection with the embodiment shown in FIG. 2. The packet conforms to a certain flow specification (F). The flow specification (F) is part of the service (S). The GGSN will note that the service S has been rejected from the mobile subscriber because there is insufficient funds if the user has not subscribed to the service or if the user is a prepaid user. The GGSN will then discard the packet received from the user equipment.

The GGSN generates a push message sent to the user equipment in step T4. In step T5, the push message is displayed at the user equipment.

Push messages are similar to HTTP messages. It contains a message body that can use any MIME content type. Thus, the push message may comprise an information message that is shown to the end user of the user equipment. This information message may indicate why the request failed, for example, the user had insufficient funds or did not subscribe to the service at hand.

There are a number of different ways that GGSN can send push messages to user equipment. It should be understood that the structure of push messages is defined in the WAP standard.

The Push-OTA specification (via air) (WAP Forum) describes how GGSN or any other network element can send Push messages to user equipment. The primitive used is Po-Unit-Push. This primitive is performed using WSP (Wireless Session Protocol). The wireless session protocol supports unacknowledged push services without existing WSP sessions. The push service in the WSP causes the GGSN to send push data to the client whenever the PDP context is active. Unacknowledged data push from the session can be used to send one way messages on an unreliable transport. The push-OTA primitive Po-Unit-Push maps to the WSP primitive S-Unit-Push.

Connectionless WSP transport primitives are mapped to the WDP protocol (wireless datagram protocol). The corresponding WDP primitive is T-Dunitdata.req. GGSN supports WDP over IP, and WDP packets are sent in UDP packets. Connectionless push uses port number 2948 on user equipment.

Detailed encoding of push messages is provided in the WAP specifications. Push messages include both headers and body parts. The body is the content of the push message, which matches the HTTP entity body. Thus, GGSN records an information message regarding the cause of the denial of service. In other words, the information message may indicate that the service was denied because the user had insufficient funds or that the service was denied because the user did not subscribe to a particular service. In addition, the push body may include a link to the portal, where the mobile subscriber may modify his status (by subscribing to a service or funding a prepaid account) to enable the service. Can be.

GGSN also uses a connected mode WSP to deliver push messages. Connectionless push messages are not reliable because the user equipment does not confirm that the push message has been received. Linked mode WSPs address this problem. On the other hand, the connectionless push requests sending only one UDP packet to the user equipment and thus does not request any status information. Moreover, if the user equipment attempts to access the denied service again, the GGSN may resend the push message.

In another solution, particularly where the user equipment is unable to receive an unconfirmed connectionless push message on port 2948, the push message may be delivered by a push proxy gateway (PPG), which is part of the WAP push architecture. The PPG knows the capabilities of the user equipment and can deliver push messages via SMS (Short Message Service) if practically no other alternatives are available.

If a PPG is deployed, the GGSN will first send a push message to the PPG, which will then deliver the message to the user equipment. In other words, step T4 of FIG. 3 will be replaced by two steps where the GGSN sends a push message to the PPG and the PPG sends a push message to the user equipment. GGSN and PPG communicate using the PAP protocol (push access protocol) defined in the WAP standards. PAP is performed over HTTP. When a push message needs to be delivered to the user equipment, the GGSN uses the transmission procedure described in the PAP specification.

Embodiments of the present invention have the advantage that the solution is not application specific. Additionally, embodiments of the present invention can be used during a connection, in other words, messages can be delivered at any time. The push message can include user friendly message and URL links. URL links may allow a user to subscribe to the service at hand or to recharge his or her account.

The GGSN may send any of the following WAP push notifications to the mobile subscriber. These notifications can be sent during the following times:

Notification when a PDP context is created (eg, to inform about new services when a mobile subscriber is logged in the network);

Notification when the PDP context is deleted (e.g. to indicate how much money the prepaid user has left in the prepaid account or how many services the user has used).

This functionality can also be performed in OCS.

When the service is accessed for the first time during the PDP context, a notification is sent (eg to inform the service usage cost).

When the mobile subscriber roaming state is changed, a notification is sent.

When a PDP context cannot be created for some reason, a notification is sent to inform the user of the reason for the failure (this notification uses PPG, since there is no open PDP context and a push message cannot be delivered to the UE). ).

Push messages can also support SL (Service Loading) functionality. SL is also defined in the WAP standards. When the UE receives a Push message containing the SL, it will automatically load the URL from the application server. The URL is part of the SL Push message. In other words, it is possible to redirect the mobile subscriber to another location with the SL. While prior art configurations modify existing sessions, SL-based redirection opens new sessions. In embodiments of the present invention, SL based redirection does not depend on the type of service since a new session is started. The SL based solution used in the embodiments of the present invention will not require proxy functionality in GGSN.

It is to be understood that embodiments of the invention may be modified.

For example, in some embodiments, SGSN may provide all or some of the functions shown by the GGSN embodying the present invention. In the current specifications, since GGSN looks at a packet, there are advantages to using GGSN. Second, the GGSN used may be the user's home network GGSN. In alternative embodiments, other nodes equivalent to GGSN may be used. In some embodiments of the invention, the functionality provided by the GGSN in the described embodiments may be provided by two or more nodes.

In other embodiments of the present invention, at least some of the functions provided by the GGSN may be provided by a traffic analyzer and / or a content analyzer. The traffic analyzer and / or content analyzer determines the service and may provide similar functions. In some embodiments of the invention, the traffic analyzer and / or content analyzer may be used in conjunction with the GGSN to provide the functions described in connection with the GGSN shown in FIGS. 2 and 3. Radius servers may also be used to provide at least some of the functions provided by the GGSN shown in FIGS. 2 and 3.

Embodiments of the present invention may be used for any cause for denial of service in addition to the two reasons described above.

As mentioned above, embodiments of the present invention can be used in circuit switched systems. In particular, both WAP and ICMP are applicable in circuit switched environments. One difference from the described embodiment is the network element used (eg, GGSN would be replaced with a generic gateway node). Embodiments of the present invention also apply to other wireless networks, where WAP is available (eg, CDMA network). If the UE supports WAP push, for example, the solution will also be used in WLAN and fixed data networks. ICMP works on any IP network.

Claims (16)

A gateway node for use in a communication network, The gateway node is: Receive a request for a service, Determine whether the service can be provided, and If a service cannot be provided, a message with an indication of why the service cannot be provided is generated and sent to the service requester, The gateway node indicates the source of the message as a provider of the requested service. 2. The gateway node of claim 1 wherein the message is one of a WAP push message, a WAP SL message and an ICMP message. The gateway node according to claim 1 or 2, wherein the message includes information defining a link to a location where a cause of the failure to provide the service can be eliminated. The gateway node according to claim 1 or 2, wherein the indication includes at least one of code values and explanatory text. The gateway node of claim 1 or 2, wherein the gateway node comprises at least one of a GGSN, a traffic analyzer, and a content analyzer. The gateway node according to claim 1 or 2, wherein if the service cannot be provided, the gateway node discards packets from the requestor. The gateway node according to claim 1 or 2, wherein the gateway node performs traffic analysis on the traffic received from the requestor. 8. The gateway node of claim 7, wherein the gateway node determines whether a portion of the traffic meets a flow specification. The gateway node according to claim 1 or 2, wherein the message indicates that the service was not provided because of insufficient funds or because the requester did not subscribe to the requested service. The gateway node according to claim 1 or 2, wherein the message is passed through a gateway. 11. The gateway node of claim 10 wherein the message is one of a WAP push message, a WAP SL message, and an ICMP message, wherein the gateway comprises a push proxy gateway. delete The method according to claim 1 or 2, wherein the gateway node is Notification when a PDP context is created; Notification when the PDP context has been deleted; Notification when a service is accessed for the first time during a PDP context; Notification when the roaming state of the requester has changed; And During notification when a PDP context cannot be created And send one or more to the requestor. Determining, at the gateway node, whether the requested service can be provided; If a service cannot be provided, sending a message to a service requester indicating why the service is not provided; And Discarding traffic received from the requestor at the gateway node, wherein the message indicates a provider of the requested service as a source of the message. Determining whether the requested service can be provided; If a service cannot be provided, sending a push or ICMP message to a service requester indicating why the service is not provided, the message indicating a provider of the requested service as a source of the message; The message is transmitted by a node different from the provider of the requested service. Determining whether the requested service can be provided; If a service cannot be provided, generating a message indicating why the service is not provided and an address of a provider of the requested service; And Sending the message to a service requester, wherein the message is sent from an address different from the address of the provider of the requested service.

Images