Selecting data interfaces in a multi-homing communication device

ES 2 374 941 T3

DESCRIPTION

Selection of data interfaces in a multi-site communications device

Background of the invention

I. - Field

The present disclosure generally refers to network devices. More particularly, the disclosure relates to multi-site network devices.

II. - Description of related art

In recent years, the number of wireless handsets in use has increased dramatically. With the increasing demand for these mobile devices, manufacturers build these devices with the inclusion of numerous data services. This convergence of data services can make wireless devices powerful resources for networking data. However, due to the increase in data services provided by wireless devices, the number of malicious attacks on wireless devices has also increased. Thus, there is a growing concern to protect these devices from malicious attacks.

Cordless phones have evolved into multi-site devices that include many data interfaces through which cordless phones can accept and send data. At any time, on a particular cordless telephone, more than one of these data interfaces can be opened to direct the transfer of data over the Internet or other data network. The data protocol stack in the mobile device is for the most part transparent to the device's multiple data interfaces. Also, the data protocol stack can accept data from any of the data interfaces as long as the protocol address of the incoming data matches the protocol address of the phone. In this way, the cordless phone is open and vulnerable to many attacks from the Internet and other data networks.

For example, when a packet is received on a data interface at a multi-site device, the packet can be routed to an appropriate socket or application. In general, for a socket that binds using Transmission Control Protocol (TCP), a packet is routed to the socket based on four (4) tuples, for example source address (src_addr), source port (src_port), address destination (dst_addr), and destination port (dst_port). For a socket that connects using the User Datagram Protocol (UDP), a packet is routed to the socket based on two tuples, for example destination address (dst_addr) and destination port (dst_port). For other protocols, such as Internet Control Message Protocol (ICMP) or Non-Internet Protocol (IP) based protocols, other fields in the network and transport layer headers may be used.

Unfortunately, in a multi-site device, the parameters described above may not be able to uniquely identify a data interface for various reasons. For example, data interfaces in a multi-site device can be assigned duplicate private addresses. Similarly, multiple applications on the multi-site device may attempt to access the same service using different network data interfaces. In such scenarios, applications can bind to the same service access point (SAP), for example, the same port number in case of UDP or TCP. Thus, it may not be possible to correctly route a packet to the appropriate destination application.

A multi-site device can also be vulnerable to spurious attacks due to the different data interfaces available on the multi-site device. For example, in a typical multi-site device, an application installed inside can receive data from any network data interface while the data interface is open for data transfer and the data protocol addresses, for example IP address, number port, etc., match that of the application.

Aside from security considerations, data network providers are also concerned with billing and the use of various services and technologies available in mobile phones on data networks. For example, there is a certain associated cost associated with each new service and new technology that a data network provider provides and operators are typically interested in uncomplicated discrete billing of various services used by the mobile phone user. If an application on a mobile phone is limited to using certain data interfaces available on the mobile phone for data transfers, it may be easier for the operator network to track the billing and costs associated with the use of different technologies and services. differently, based on data interface usage.

Furthermore, in a multi-site network device the port space for network applications is usually shared among all the data interfaces available to the device. If an application is using a particular port number for data transfer on a particular data interface, no other application can use the same port number - even if the other application is using a completely different data interface. This can be an unnecessary limitation for a device that may need to run different services on different data interfaces but with the same port number. For example, him

ES 2 374 941 T3 network device may include two different web servers using the same port number, eg port eighty (80), but on different data interfaces. Most network devices do not allow this flexibility. Some implementations allow all data interfaces or a specific data interface, that is, one interface or all interfaces, to be bound to a port.

Noteworthy document US-B-6 473 404 describes a telecommunications switching system that employs multiprotocol routing optimization that uses predetermined and calibrated parameters according to a set of user priorities determining the selection of a telecommunications path for use in transmitting a data file to a remote destination. The switching system has a first memory to store the data file to be transferred, a second memory to store predetermined parameters such as cost data associated with each of the telecommunications paths, a third memory to store a set of user priorities regarding the transmission of data files, and means for measuring the value of variable parameters such as file transfer speed with each of the telecommunications paths. The processing means is operatively associated with the second and third memories and the variable parameter measuring means to determine which of the plurality of telecommunication paths should be used to transfer the data file according to the user priority set, the path parameters telecommunication settings, and calibrated variable parameters. The switching system further comprises input means for allowing a user to change user priorities in the third memory before transmitting a file.

Note US 2002/0046292 A1 which describes a client device that has access to multiple data communication networks when sending a message to a server. An included network management functionality evaluates on an individual message by means of a message base a number of factors and selects one of the networks over which the message is to be communicated to the server. The selection process implies that the network management functionality has to identify a particular selection rule that contains a network clause for each potentially usable communication network. The particular selection data comprising each network clause is evaluated in the context of message transmission to select for the message the particular network of networks to be used for communication.

Summary

According to the present invention, there is provided a method for transmitting and receiving data to and from a multi-site network device to a data network, as set forth in claim 1, a multi-site network device, as set forth in claim 12, and device computer-readable, as set forth in claim 32. Preferred embodiments of the invention are claimed in the dependent claims.

Brief description of the drawings

Aspects and related aspects of the embodiments described herein will become more apparent with reference to the following detailed description when taken in conjunction with the accompanying drawings in which:

Figure 1 is a general diagram illustrating a particular embodiment of a communication system;

Figure 2 is a general diagram illustrating a network stack;

Figure 3 is a flow chart illustrating a procedure for transmitting data;

Figure 4 is a flow chart illustrating a procedure for binding an application to a subset of available data interfaces;

Figure 5 is a flow chart illustrating a procedure for receiving data;

Figure 6 is a flow chart illustrating a procedure for determining whether a temporary routing scope conforms to an application routing scope.

Fig. 7 is a general diagram illustrating a first example of processing an incoming data packet;

Fig. 8 is a general diagram illustrating a second example of processing an incoming data packet.

Fig. 9 is a general diagram illustrating a third example of processing an incoming data packet.

Fig. 10 is a general diagram illustrating a fourth example of processing an incoming data packet.

Figure 11 is a flow chart illustrating a procedure for linking an application to one or more

ES 2 374 941 T3 interfaces in a wireless device.

Figure 12 is a diagram of a wireless device having a first graphical user data interface;

Figure 13 is a diagram of a wireless device having a second graphical user data interface;

Figure 14 is a diagram of a wireless device having a third graphical user data interface;

Figure 15 is a diagram of a wireless device having a fourth graphical user data interface;

Detailed description

Referring to Figure 1, an exemplary non-limiting communication system is shown and is generally designated 100. As shown, the system includes a first network device 102 and a second network device 104. In a particular embodiment, the first network device 102 and second network device 104 may communicate over one or more networks of a first data network 106, a second data network 108, a third data network 110, and a nth data network. In a particular embodiment, the data networks 106, 108, 110, 112 can be a global system for a mobile communication network (GSM), a general packet radiocommunication service (GPRS) network, a universal telecommunications system network mobile phones (UMTS), a code differentiation multiple access network (CDMA), a CDMA 2000 network, a CdMa optimized data evolution network (EVDO), a Bluetooth BT network, an 802.11a network, an 802.11b network , an 802.11g network, an 802.11i network, an 802.15 network, an 802.16 network, a broadband CDMA network (WCDMA), an orthogonal frequency code division multiplexing (OFCDM) network, a global positioning system (GPS) network, or a combination of them.

As shown in Figure 1, the first network device 102 may include a processor 114 and a memory 116 that is accessible to the processor 114. As shown, an application 118, a socket layer 119, and a routing module. 120 can be integrated, or stored, within memory and can be executed by processor 114. In a particular embodiment, socket layer 119 includes one or more sockets that can be used by an application to send and receive data. During its operation, the application 118 transmits a network policy 122 to the routing module 120 through the socket layer 119. In a particular embodiment, the network policy 122 can identify a set of data interfaces that can be used by an application to communicate with one or more of the networks 106, 108, 110, 112. In response to network policy 122, routing module 120 returns a routing scope 120 to socket layer 119 and the routing scope can be stored in socket layer 119 for a socket associated with application 118. In In a particular embodiment, the routing scope 124 includes a subset of data interfaces that comply with network policy. The subset of data interfaces are selected from the available data interfaces 132, 134, 136 on the first network device 102.

FIG. 1 indicates that the first network device 102 may include a first hardware port 126, a second hardware port 128, and an nth hardware port 130. Also, the network device 102 may include a first data interface 132. , a second data interface 134, and an nth data interface 136.

In a particular embodiment, each of the data interfaces 132, 134, 136 can be a global system for a mobile communication data interface (GSM), a general packet radio communication service (GPRS) data interface, a universal mobile telecommunications system (UMTS) data interface, a code differentiation multiple access (CDMA) data interface, a CDMA 2000 data interface, a CDMA optimized data evolution data interface (EVDO), a Bluetooth BT data interface, an 802.11a data interface, an 802.11b data interface, an 802.11g data interface, an 802.11i data interface, an 802.15 data interface, an 802.16 data interface, a wideband CDMA data interface (WCDMA), an orthogonal frequency code division multiplexing (OFCDM) data interface, a global positioning system data interface ( GPS), or a combination thereof. In a particular embodiment, each of the interfaces can be an Internet Protocol version 4 (Ipv4) data interface, an IP version 6 (Ipv6) data interface, or another network protocol data interface.

As illustrated in Figure 1, the first network device 102 also includes a transceiver 138 that is coupled to the processor 114 and an antenna 140. In a particular embodiment, the transceiver 138 transmits and receives data packets and facilitates communication with a or more of the networks 106, 108, 110, 112. In a particular embodiment, the second network device 104 may include one or more of the elements described together with the first network device 102.

In a particular embodiment, the network device 102, or the second network device 104, is a multi-site network element. Also, to support the great diversity of data services, the first network device 102 includes multiple network data interfaces 132, 134, 136. Each of the network interfaces 132, 134, 136 is capable of transferring data one time each data interface is configured to bind to an associated network 106, 108, 110, 112. In a particular embodiment, with multi-location, one or more of the data interfaces 132, 134, 136 and each active data interface 132, 134, 136 can be activated simultaneously

ES 2 374 941 T3 can provide access to a different physical or logical network 106, 108, 110, 112.

Furthermore, in a particular embodiment, each active data interface 132, 134, 136 includes a separate network address, eg, IP address for IP networks, assigned to it. Each of the network addresses can be globally unique or one or more of the network addresses can be duplicated if assigned from private space.

In a particular embodiment, the multi-site can allow the first network device 102 to access different networks that have different data technologies, for example CDMA, UMTS, GSM, etc. Likewise, the multi-site can allow the first network device 102 access the available networks 106, 108, 110, 112 based on the variable costs associated with the available networks 106, 108, 110, 112. In this way, the user, or applications within the first network device 102, are given more flexibility in terms of desired quality and cost effectiveness. Multi-site may also allow the first network device to access available networks 106, 108, 110, 112 based on the quality of services that the networks provide. A user may want a particular application to use a high quality network regardless of the cost associated with using the network. On the other hand, the user can order that an application does not exceed a particular cost and that it only uses networks below the cost without taking into account the quality of the network connection.

In a particular embodiment, the multi-site can allow a first network device 102 to access different types of networks, for example Ipv4, Ipv6, IPX, etc. Also, multi-site can allow applications within the first network device 102 to access various services provided by different physical / logical networks. For example, a particular operator can deploy different networks to provide different types of IP services, for example Internet, email, SMS, MMS, WAP, etc.

Figure 2 illustrates an exemplary non-limiting embodiment of a TCP / IP network stack, generally designated 200. As shown, network stack 200 includes a physical layer 202. A data interface layer 204 is positioned on top of the physical layer 204 includes a first data interface 206, a second data interface 208, a third data interface 210, and a nth data interface 212.

As depicted in Figure 2, an Internet Protocol (IP) layer (214) is positioned over the data interface layer 204. In an illustrative embodiment, the IP layer 214 includes one or more IPs, for example IP version 4 (Ipv4) 216 and IP version 6 (Ipv6) 218. Figure 2 further shows a transport layer 220 on top of the IP layer 214. Transport layer 220 can include one or more communication protocols, for example Transmission Control Protocol (TCP) or User Datagram Protocol (UDP) 224. Also, a socket layer 226 can be placed on top of the transport layer. 220. Similarly, one or more applications can be placed on the skirting layer 226.

Referring to Figure 3, a procedure for transmitting data from a network device to a data network is shown and begins at block 300. At block 300, an application within the network device transmits a network policy to a routing module within the network device. In a particular embodiment, the application and the routing module can be executed concurrently by a single processor. Alternatively, the application and the routing module. They can be run by different processors.

In a particular embodiment, the network policy identifies a set of data interfaces that satisfy one or more criteria specified in the network policy. For example, a network policy can specify the criteria as all UMTS data interfaces, or all Ipv4 data interfaces. Also, the network policy may specify a quality of service criteria, for example, a maximum delay value, a maximum jitter value, a bandwidth value, or a combination thereof. Similarly, the network policy may specify a maximum cost communication technology type, one or more operators, or a combination thereof. Before data transfer can be initiated by an application, the application can provide a particular data interface between a set of data interfaces that satisfies network policy.

In another particular embodiment, the decision of which data interface to propose can be made by the network management software of the data stack. Also, the decision can be made on the basis of most favored routing, eg based on the specified network policy. In a particular embodiment, each data interface can include its own access control list (ACL), which is essentially a list of rules. In addition, each data interface can evaluate access to it based on a network policy associated with an application. As part of the evaluation, a good ACL will either limit access to a data interface or revert to a non-zero priority number, for example 1-5, for this data interface. A non-zero priority number means that the data interface can be used with the given policy, and the priority number identifies the level of preference.

In an illustrative embodiment, a routing module may evaluate a network policy associated with an application and an ACL associated with each of the available data interfaces and select the data interface with the highest priority. In this way, the routing module can bind the application to the data interface with the highest priority in order to send the data. In a particular embodiment at any given time, many data interfaces can be opened for data transfer and each data interface can be linked to separate applications to allow side multi-site transmission to the wireless device. Yes

ES 2 374 941 T3 a particular data interface is opened, it can be caused to open for data communication.

Proceeding to block 302, a routing scope is received from the routing module. Also, at block 303, the routing scope can be stored in a socket layer for a socket associated with the application. In a particular embodiment, the routing scope indicates a subset of data interfaces that satisfy the network policy. Each data interface in the subset can include a priority number. In this way, the subset of data interfaces can be arranged in a hierarchy from the preferred data interface to a less preferred data interface. In an illustrative embodiment, the subset of data interfaces is selected from a set of available data interfaces on the network device.

In decision step 304, the network device determines whether the application is attempting to transmit data to a data network. If not, the procedure ends in state 306. If so, the procedure proceeds to decision step 308 and the network device determines whether the preferred data interface in the routing scope, that is, within the interface subset data linked to the application, is available. If the preferred data interface is available, the procedure proceeds to block 310 and the network device opens a channel on the preferred data interface. Conversely, if the preferred data interface is not available, the procedure proceeds to decision step 312 and the network device determines whether the next preferred data interface in the routing scope is available.

If a next preferred data interface is not available, the procedure proceeds to block 314 and an error message is displayed to the user of the network device, for example via a display screen on the network device. Otherwise, if a preferred data interface is available, the procedure proceeds to block 310 and the network device opens a channel through the data interface. In a particular embodiment, there may be many iterations before the error message is displayed. In other words, there may be multiple next preferred data interfaces in the data interface hierarchy. For example, the hierarchy of data interfaces may include a preferred data interface, a first next preferred data interface, a second next preferred data interface, a third next preferred data interface, and so on. In a particular embodiment, the network device can continue to verify a next available interface until all the interfaces within the routing range are exhausted.

Proceeding to block 316, the application transmits data over the available data interface. In decision step 318, the network device determines if the connection is dropped. If not, the procedure proceeds to decision step 320 and the network device determines whether the data transmission is complete. If so, the procedure ends in state 306. If the data transmission is not completed, the procedure returns to block 316 and continues as described.

Returning to decision step 318, if the connection drops, the procedure moves to decision step 322 and the network device determines if the next preferred data interface within the routing range is available. If not, the procedure ends in state 306. On the other hand, if the next preferred data interface is available, the procedure proceeds to decision step 324 and the network device determines whether the protocol for data transfer is connection-oriented. If the protocol is not connection-oriented, for example the protocol is a connectionless user datagram protocol (UDP), the procedure moves to block 326 and the application jumps seamlessly to the next available data interface without interrupting the connectivity. On the contrary, if the protocol is connection-oriented, for example the protocol is a Transmission Control Protocol (TCP), the procedure advances to block 328 and the application reconnects to the next available data interface. If the protocol is TCP, connectivity will be interrupted while the application reconnects through the new data interface. From block 326 or block 328, the procedure advances to decision step 320 and continues as described.

In a particular embodiment that uses the procedure described above, an application can specify a network policy for data transfer associated with the application. Network policy can limit the data interfaces over which the application sends and receives data. In the transmission path, a data interface is chosen for the application from the subset of appropriate data interfaces. In a particular embodiment, the data interface that is chosen can be the most favorable, that is, the one with the highest priority based on the network policy criteria, thus optimizing the transmission path. Also, in a particular embodiment, the application uses the selected transmission data interface until the data transfer is completed or the data interface is lost. If the data interface is lost, a new data interface is chosen from the subset of data interfaces, if available, based on priority. This allows data transmission to conform to network policy even if the highest priority data interface is lost.

Figure 4 represents a procedure for binding an application to a subset of data interfaces within a group of available data interfaces. Starting at block 400, a routing module receives a network policy from an application. At block 402, the routing module creates a routing scope based on network policy and available data interfaces. In a particular embodiment, the routing scope includes or points to a subset of available data interfaces that satisfy the network policy of the application. Moving to block 404, the routing module binds the application to the available data interfaces within the routing scope.

ES 2 374 941 T3

At block 406, the routing module returns the routing scope to the socket layer to store for the socket associated with the application. The procedure then ends in state 408.

Referring to Figure 5, a procedure for receiving data to a network device from a data network is shown and begins at block 500. At block 500, the network device receives a data packet at the IP layer of the data stack from a data interface. Moving to decision step 502, the network device determines whether the destination IP address of the data packet is the same as the IP address of the data interface assigned to the application. If not, the procedure proceeds to block 504 and the data packet is discarded. The procedure then ends in state 506.

If the destination IP address of the data packet is the same as the IP address of the data interface, the procedure moves to block 508 and the network device searches for a socket associated with the network packet. In decision step 510, the network device determines if the socket is found. If not, the procedure moves to block 504 and the data packet is discarded. The procedure then ends in state 506.

At decision step 510, if the socket is found, the procedure advances to block 512 and a routing scope associated with the application is retrieved. At block 514, a temporary routing scope is created for the data interface. In a particular embodiment, the temporary routing scope is created to determine the index of the input data interface and change the corresponding bit to 1 and keep any other bit n in the temporary routing scope as 0.

Moving to the decision stage, it is determined whether the temporary routing scope conforms to the routing scope associated with the application. Figure 6 illustrates a detailed embodiment for determining whether the temporary routing scope conforms to the routing scope associated with the application. If the temporary routing scope conforms to the routing scope of the application, the procedure moves to block 518 and the network device follows the transport layer processing of the data packet. The procedure is then terminated at state 506.

If the temporary routing scope does not conform to the routing scope of the application, the procedure moves to block 520 and the network device discards the data packet. Advancing to decision step 522, the network device determines whether the current communication protocol is TCP or UDP. If the current communication protocol is TCP, the procedure moves to block 524 and the network device sends a reset message (RST) to the peer device that transmits the data packet that is discarded at the network device. The procedure then ends in state 506.

In a particular embodiment, using the procedure described above, when a packet arrives through a data interface for some connection, it can be limited to the data interfaces allowed in the two-stage routing scope. For example, the first stage is a simple sanity check. This stage involves comparing the IP address of the data interface that the packet carries and the destination address of the packet. The only exception to this being that the destination address should not be a multicast or broadcast address. When the incoming packet passes the IP layer, the IP layer of the data interface is notified that the packet came in. If the destination IP address of the packet does not match that of the interface it was carrying then the packet is silently discarded. This limits packets to particular data interfaces with specific IP addresses and prevents any incoming packet errors.

Figure 6 illustrates a procedure for determining whether a temporary routing scope conforms to an application routing scope. Starting at block 600, a routing scope is received for an application. At block 602, a temporary routing scope is created. Then, at block 604, a bit-level "AND" operation is performed on the routing scope and the temporary routing scope. Moving to block 606, it is determined whether the result of the "AND" operation is zero. If the result is zero, the procedure moves to block 608 and the packet is discarded. The procedure then ends in state 610. On the other hand, if the result is not zero, the procedure moves to block 612 and the data packet is held. The procedure then ends in state 610.

In a particular embodiment, the routing scope contains information about which data interfaces are allowed to receive data for a particular application. The routing scope can be maintained as a bitmask of all available data interfaces. When a data interface satisfies the network policy for a particular application, the data interface is added to the routing scope associated with the particular application. For example, if a fifth data interface, which has an index five (5), satisfies the policy for the application, a bit number five (5) in the routing scope for the application is set to one (1) with in order to include the fifth data interface in the routing scope for the application.

In a particular embodiment, when the received data is limited, all the data interfaces that have priority greater than zero are included in the routing scope for the application. The procedure reviews the ACL for each data interface and includes all data interfaces in the routing scope for the application that satisfy the network policy for the application. In a particular embodiment, the routing scope may include one or more bits that are set to one (1) indicating that the

ES 2 374 941 T3 application associated with the routing scope receiving data through one or more data interfaces.

In a particular embodiment, if an application binds to a specific IP address, the routing scope can be limited to include the data interfaces with the requested IP address and also match the network policy. In another particular embodiment, the routing scope is created when an application creates a socket with a specific network policy. However, the routing scope can be updated periodically.

Figures 7 to 10 illustrate examples that conform to the procedures represented in Figure 5 and Figure

6. Figure 7 depicts an example where an incoming packet is received and includes a destination address (10.0.01) that is the same as the data interface address (10.0.01). Thus, the entry packet is accepted.

Figure 8 illustrates an example in which an incoming packet is received and includes a destination address (10.0.0.1) that is different from the incoming data interface address (10.0.0.2) on which the input package. In this way, the input packet is discarded.

Figure 9 illustrates an example where an input packet is received on a data interface that satisfies the network policy of an application and is accepted. As shown, the bit-level "AND" operation performed in the application routing scope and the temporary routing scope is non-zero. In this way, the incoming packet satisfies the network policy of the application.

Figure 10 illustrates an example where an incoming packet is received on a data interface that does not satisfy the network policy of an application. As shown, the bit-level "AND" operation performed in the application routing scope and the temporary routing scope is zero. In this way, the incoming packet violates the network policy of the application and the incoming packet is discarded.

In a particular embodiment, the dynamic nature of the state of data interfaces, and wireless network connections, can affect the routing scope that is associated with each application within a network device. For example, due to the mobility of the network device, the network device can traverse the coverage areas of various networks causing the corresponding network data interfaces to go up or down. Also due to mobility, the priority of a network, and an associated network data interface, may be increased or decreased depending on the type of network access that is available or the type of operator that is providing the service at a particular location in a particular moment.

Due to the dynamic nature of wireless communication, there can be a number of triggers that can cause the routing scopes associated with the applications within the network device to change.

In a particular embodiment, when a data interface goes up or down, it can affect the routing scope of several applications because the network policy associated with some applications and data interfaces are dynamically configured. For example, when a UMTS data interface is uploaded, the UMTS connects to a different access point name (APN) each time, and provides a different type of service. When such a data interface is uploaded and bound to a specific APN, this data interface can no longer match the network policy of one or more applications within the network device. Thus, raising a particular data interface can lower the routing scope for one or more applications.

Similarly, when a particular data interface is brought down, the routing scope associated with one or more applications can be expanded. In a particular embodiment, if a data interface is downloaded, it can still be included in a routing scope for an application and the application can potentially use this data interface after uploading it. Also, in a particular embodiment, some data interfaces, but not all data interfaces can be uploaded automatically to save costs. Additional data interfaces can be uploaded when required, for example by a user or an application.

In one embodiment, when a network node changes the network coverage area, the routing scope of one or more applications may change. For example, losing the coverage area of ​​a network can cause an associated data interface to be disabled until the data interface is enabled when the network device re-enters a coverage area. In a particular embodiment, a disabled data interface cannot be uploaded due to lack of network connectivity while a downloaded data interface can potentially be uploaded and used for communication when needed.

In another particular embodiment, some applications can be strongly linked to a single network data interface and this data interface is used to transmit and receive data. For such applications, the routing scope has only one bit set and this bit can be set when the interface is raised and reset to zero when the interface is lowered.

In a particular embodiment, the routing scope can also change when the network policy associated with the socket is changed. In such an embodiment, a new routing scope can be calculated for this

ES 2 374 941 T3 application according to the new network policy and the new routing scope can be propagated to the socket associated with the application. In another embodiment, if an application binds to a specific IP address, for example using a bind () API call, the routing scope can be limited to data interfaces that have the particular address to which the socket binds. . Due to mobility and network handover, the data interface IP address may change and the routing scope for the application may require updating to exclude the old data interface from the associated routing scope.

Also, in a particular embodiment, if a single network data interface is capable of serving several technological areas, for example CDMA, UMTS, etc. or network types, for example Ipv4, Ipv6, etc. and if such a data interface is transferred to a different technology area or type of service, the scope of routing that includes this data interface needs to be updated and re-evaluated in order to determine if the data interface continues to meet the policy of application network. In yet another particular embodiment, for the connected sockets, for example TCP sockets once the connection is established, for example using a call to the connect () API, the routing scope can be limited to only one interface that can connect to the address specified destination.

In another particular embodiment, a network policy specified by the application may or may not include a local loop data interface. Thus, a local loopback data interface can be considered a special case of interfaces limited through one or more network policies. A local loopback data interface may include a restriction that these packets received with a local loopback destination IP address should be received on the local loopback data interface. This verification can be carried out at the IP layer as a first stage of data interface restriction for incoming packets, for example during an address comparison. For the transport layer restriction, the bit corresponding to the local loop data interface can be set for the routing scope associated with each application or a special check can be carried out in the transport layer to process the scope. routing.

Referring to Figure 11, a procedure for binding an application to a port is shown and begins at block 1100. At block 1100, a routing module within a network device receives a request to bind a port to an application. . At block 1102, the routing module reviews all open or active applications. Moving to decision step 1104, the routing module determines whether any open or active application is bound to the same port that the requesting application is attempting to bind to. If not, the procedure advances to block 1106 and the routing module binds the requesting application to the port. The procedure then ends in state 1108.

On the other hand, in decision step 11104, if any open or active applications are bound to the same port that the requesting application is trying to bind to, the procedure proceeds to block 1100 and the routing module performs an "AND ”At the bit level about the routing scope of each open / active application and the routing scope of the requesting application. Advancing to decision step 1112, the routing module determines whether the result of any "AND" operation at the bit level is zero. If so, the procedure moves to block 1106 and the routing module binds the requesting application to the port that establishes the port in the socket associated with the requesting application. The procedure then ends in state 1108.

Returning to decision step 1112, if the result of the bit-level "AND" operation is different from zero, the procedure moves to block 1114 and the routing module does not bind the requesting application to the port. The procedure then ends in state 1108.

In a particular embodiment, when the routing scope of a socket changes due to one or more of the various reasons described above, the new routing scope can have an effect on the port space separation. For example, during the recalculation of a routing scope for an application, if one or more data interfaces are removed from the routing scope, no problem can arise as the port space remains separate and since none have been created. intersection between the routing scopes of the sockets. However, if one or more data interfaces are added to the routing scope, the addition of a data interface can create a conflict with the associated routing scopes of another application. If the port numbers used by applications with intersecting routing scopes are identical, the network connection stack will be unable to decide which application is to direct an incoming data packet arriving at one of the intersecting data interfaces.

In a particular embodiment, this potential conflict can be resolved based on the following approach: if the conflicting application is already actively transferring data over the conflicting <port number, data interface> pair, this application is left alone and avoided let the other application use this <port number, data interface> pair. If the conflicting application is not actively using the <port number, data interface> pair for data transfer, then the “port number, data interface> pair is overridden for the conflicting applications based on a configurable policy.

In a particular embodiment, disabling an application essentially means that the routing scope of the disabled application is temporarily reduced to exclude the conflicting data interface for the port number in question. This can be done by defining a set of pairs

ES 2 374 941 T3 <port number, data interface> blocked for each application, ie one routing scope blocked. In a particular embodiment, a blocked routing scope is one that is temporarily blocked due to a conflict with another application but not due to a network policy mismatch.

In a non-limiting exemplary embodiment, an entry in a blocked routing scope can be removed: (1) when the competent application closes, (2) when the competent application rebinds to another port space, (3) when the disabled application rebinds to a different port space, (4) when the policy of network of the disabled application changes, (5) when the network policy of the competent application changes or (6) when the routing scope of one or more applications changes due to the conditions defined above.

In a particular embodiment, conditions (2) and (5) above can cause the routing scopes for other applications within the network device to be blocked. Also, in a particular embodiment, conditions (3) and (4) can cause some entries to be removed from a blocked routing scope while other entries can be added due to new conflicts.

In a particular embodiment, the steps described above together with Figures 3, 4, 5, 6 and 11 can be embodied in the form of software that is stored in a memory, for example a random access memory (RAM), a memory of dynamic random access memory (DRAM), a static random access memory (SRAM), a read-only memory (ROM), a masked ROM, a programmable read-only memory (PROM), an erasable programmable read-only memory (EPROM) , an electronically erasable programmable read-only memory (EEPROM), a non-volatile random access memory (MVRAM), an ultra-fast memory, a hard disk drive, or other storage media. Each of these procedures can be stored individually or in combination with other steps of the procedure.

Likewise, in a particular embodiment, the steps of the procedure described above together with Figures 3, 4, 5, 6 and 11 can be executed by a processor, microprocessor, controller, microcontroller, application-specific integrated circuit (ASIC), processor digital signal (DSP), or other means of processing. Each of these process steps can be performed individually or in combination with other process steps.

Figure 12 illustrates a wireless device that is generally designated 1200. As shown, wireless device 1200 includes a display screen 1202 and a keypad 1204. Likewise, wireless device 1200 may include a microphone 1206 and a speaker 1208. A user can use microphone to speak 1206 and listen to incoming audio through speaker 1208. As indicated in FIG. 12, a signal strength indicator 1210, a voicemail indicator 1212, and a battery level indicator 1214 can be displayed on the display screen 1202.

As depicted in FIG. 12, in a non-limiting exemplary embodiment, the numeric keypad 1204 may include a direction button 1216 that the user can use to move a cursor or selection bar around the display screen 1202. Especially, the User can use direction button, for example up, down, left, right, or any diagonal direction. Likewise, in a particular embodiment, the numeric keypad 1204 may include a validation Ok button 1218, a Clear button for deletion 1220, and the termination "End" button 1222 for entering responses in response to the prompts presented on the display screen. 1202.

Figure 12 further illustrates a first exemplary graphical data user interface (GUI) 1250 that may be presented to a user by the display screen 1202 of the wireless device 1200. As shown the first GUI 1210 may include a header 1252 which includes the purpose of the first GUI 1250. As shown, in an illustrative embodiment, header 1252 is labeled "Edit Network Settings" Thus the user can assume that the first GUI 1250 can be used to edit network settings.

Figure 12 also indicates that the first GUI 1250 may include an indication menu 1254. In a particular embodiment, the application menu 1254 includes a list of applications that are installed on the wireless device 1200 that require network access. For example, application menu 1254 includes a first application, a second application, a third application, and a nth application. As shown, the first GUI 1250 also includes a selection bar 1256 that the user can scroll up and down within the application menu 1254 using the direction button 1216 on the numeric keypad 1204. The user can scroll the toolbar. selecting 1256 to an application, eg, the third application, and selecting the validation Ok button 1218 on the numeric keypad 1204 in order to access a second GUI 1300 shown in FIG. 13.

Figure 13 illustrates a second exemplary GUI designated 1300, which can be used to edit settings for an application, for example the third application selected using the first GUI 1250 (Figure 12). As depicted in Figure 13, the second GUI 1300 may include a header 1302 that indicates the purpose of the second GUI 1300. In an illustrative embodiment, the header 1302 of the second GUI 1300 is labeled "App.3 Edit Network Settings ”(App.3 Edit Network Settings). In this way the user can determine that the second GUI

0

ES 2 374 941 T3

1300 can be used to edit network settings for the third application.

In an alternative embodiment, if the user selects the first application in the first GUI 1250 (Figure 12), the header 1302 of the second GUI 1300 may be labeled "App.1 Edit Networks Settings." ).

As shown in Figure 13, the second GUI may include a network menu 1304 that includes a list of networks, or network data interfaces, that are available on the wireless device 1200. For example, the network menu 1304 includes a first network, a second network, a third network, and a nth network. The second GUI 1300 also includes a selection bar 1306 that a user can scroll up and down within the network menu 1304 using the direction button 1216 on the numeric keypad 1204. The user can scroll the selection bar 1306 to a network, for example the second application, and selecting and adding or removing a network or a list of approved networks for a particular application that is installed on the wireless device 1200.

As shown, the second GUI 1300 also includes a set priority programmable button 1312 that is displayed on the display screen 1202. In a particular embodiment, the user may select the set priority programmable button 1312 in order to establish a hierarchy network approved for use by a particular application within the 1200 wireless device. When the priority set soft button 1312 is selected, a third GUI 1400 may be presented to the user by display screen 1202. Alternatively, predefined ACLs may be used to describe network policy and assign priority to data networks.

Referring to Figure 14, the third GUI 1400 is shown. As shown in Figure 14, the third GUI 1400 may include a header 1402 that indicates the purpose of the third GUI 1400. For example, the third GUI header 1402 GUI is labeled “Network Priority - App3”. In this way, the user can determine that the third GUI 1400 can be used to edit the network priority for networks approved for use by the third application.

In an alternative embodiment, if the user selects the first application in the first GUI 1250 (Figure 12) and the user selects the set priority soft button 1312 in the second GUI 1300 (Figure 13), the header 1402 of the third GUI 1400 it may be labeled ““ “Network Priority - App1”.

As shown in FIG. 14, the third GUI 1400 may include a network priority menu 1404 that includes a list of networks, or network data interfaces, that are approved for use by the third application. Similarly, the network priority menu 1404 indicates the priority of each approved network or network data interface. For example, the network priority menu 1040 includes a third network with a first priority, a first network with a second priority, a fifth network with a third priority, and a fourth network with a fourth priority.

The third GUI 1400 also includes a selection bar 1406 that a user scrolls up and down within the network priority menu 1404 using the direction button 1216 on the numeric keypad 1204. The user can scroll the selection bar 1406 to a network 1204, for example, the first application, and select an up soft button 1408, or a down soft button 1410 in order to scroll the first network up or down. within the network priority menu 1404. In this way, the user can define the network priority that an application can use during data transfer.

Figure 15 illustrates a fourth GUI 1500 that can be presented to a user when an attempt to send a data packet to an application is prevented. As depicted in Figure 15, the fourth GUI 1500 may include a header 1502 that indicates the purpose of the fourth GUI 1500. For example, the fourth GUI 1500 header 1502 is labeled "Error Message." . Thus, the user can assume that the wireless device has encountered an error. Figure 15 further indicates that the fourth GUI 1500 may include an error message 1504 that can be presented to the user via the display screen 1202. In an exemplary non-limiting embodiment, the error message indicates "Incoming data packet dropped. Error logged ”. Incoming data packet discarded. Error logged. In this way, the user knows that an external device has tried to transmit a data packet to the wireless device, for example an application inside the wireless device, and that the data packet was discarded as suspicious. In a particular embodiment, the errors can be registered in a network device in the network from which the suspicious packet is received.

In a particular embodiment, each GUI 1250, 1300, 1400, 1500 described above is a standalone GUI. Alternatively, the GUIs 1250, 1300, 1400, 1500 described above are part of a single GUI that has multiple pages.

With the framework configuration described herein, the system and method for supporting data applications on a multi-site multi-mode communication device provides a way for applications on a network device to specify which data interface to use for connection. in data network. For example, a particular network data interface within a network device may provide access to a general network, eg, the Internet, while another network data interface may provide access to a private corporate intranet. In addition, the network device may include a first application for accessing email from the private corporate network and a second application client for

1

ES 2 374 941 T3 email to retrieve personal email on the Internet.

In a particular embodiment, the network device can include a "special" browser for access to a private Intranet and a "standard" browser for general Internet access. Also, the network device can include multiple GPS engines and each GPS engine can access location information from a particular network through a data interface specified by the GPS engine. Additionally, in a particular embodiment, a name resolver, for example a domain name system (DNS), that communicates with the network device can resolve a name, or an address, for a specific network since there could be addresses or duplicate names configured on two private networks.

Also, with the framework configuration described herein, the system and method can restrict the number of data interfaces over which an application can receive data. This provides a relatively higher level of security to the protocol stack and applications within the network device. Likewise, the system and method provide a way of restricting the incoming data so that the incoming data is thus communicated to a particular application based on the data interface, or data interfaces, over which the data is received. The system may use a network policy associated with each application in order to identify the data interfaces that are allowed for data transfer for each application.

Also, the system and procedure described herein may allow the application to bind to specific ports for one, more, or all of the data interfaces. For other protocol stacks, for example, different from TCP / YDP / IP, applications can be allowed to access services on a set of data interfaces.

One of skill in the art would further appreciate that the various illustrative steps of logic blocks, configurations, modules, circuits, and algorithms described in conjunction with the embodiments disclosed herein can be applied as electronic hardware, computer software, or combinations of both. To clearly illustrate this interchangeability of hardware and software, various illustrative components, blocks, configurations, modules, circuits, and steps have been described above generally in terms of their functionality. Whether such functionality applies as hardware or software depends on particular application and design limitations imposed on the overall system. The person skilled in the art can apply the described functionality in various ways for each particular application, but such implementation decisions should not be construed as leaving the scope of the present disclosure.

The steps of the procedures, or algorithms, described in conjunction with the embodiments depicted herein can be implemented directly in hardware, in a software module executed by a processor, or in a combination of the two. A software module can reside in rAm memory, flash memory, RAM memory, ROM memory, PROM memory, EPROM memory, EEPROM memory, registers, hard disk, a removable disk, a CD-ROM, or any other storage medium known in The technique. An exemplary storage medium is coupled to the processor so that the processor can read information from, and write information to, the storage medium. Alternatively, the storage medium can be integral with the processor. The processor and storage medium can reside in an ASIC. The ASIC can reside in a computing device or a user terminal. Alternatively, the processor and storage medium may reside as discrete components in a computing device or a user terminal.

The previous description of the disclosed embodiments is provided to enable any person skilled in the art to make or use the present disclosure. Various modifications of these embodiments will be readily apparent to one of ordinary skill in the art. Thus, the present invention is in accordance with the fullest scope consistent with the following claims.

2