WO2012110527A1 - Distributed middleware for mobile devices - Google Patents

Abstract

Described herein is a middleware platform from which an operating system for a smart device can be downloaded. The operating system transforms digital information into radio frequency data and links the radio frequency data with the smart device as long as the smart device is active. The middleware platform uses wireless virtual cache and radio frequency echo technology. In one embodiment, architecture (800) for the middleware platform comprises a single access network (810) is shown connected to an IP STREAMING core network (820). A user (830) accesses the IP STREAMING core network (820) in accordance with the present invention via the access network (810). Various elements (840, 845, 850, 855, 860, 855, 860, 865, 870, 875, 880, 885) are provided within the IP STREAMING core network (820) for providing the necessary connections.

Description

DISTRIBUTED MIDDLEWARE FOR MOBILE DEVICES

Field of the invention

The present invention relates to improvements in or relating to mobile telecommunications, and is more particularly concerned with mobile internet communications.

Background to the invention

Mobile telephones are now well-known and mobile data, video and television services are becoming an essential part of consumers' lives and business processes. In addition, mobile subscriptions are growing rapidly and the demand for bandwidth due to downloading of data and video is rising. Mobile machine-to-machine connections are also increasing.

Smart phones, tablet computers and other downloadable applications increase the use of data and the content on mobile devices. The proliferation of high-speed internet-centric mobile devices has been made possible by good global 3G network coverage. (3G or 3^rd generation is the term applied to standards for mobile telephones and mobile telecommunications services that meet the specifications of the International Telecommunication Union.) Application services include wide area wireless voice telephone, mobile internet access, video calls and mobile television all within a mobile environment.

Applications (also called "Apps") for smart phones, tablets and other mobile devices are being downloaded with games leading the way. However, the use of mobile shopping, social networking, utilities and productivity tools continues to grow and attract increasing amounts of money, and such cheap apps are the main competitors of traditional software vendors.

Mobile application developers have built more than 300000 apps in the last three years and the more successful apps and associated services deliver a good combination of user experience and value. App stores are becoming more popular and consumers already have a wide choice of stores. However, consumers will tend to seek out the stores that make it easy for them to discover new applications that are of interest to them and make it easy to pay for these applications when required.

At present, nearly every operating system has its own application store and a number of handset vendors and wireless carriers are also planning to tap into this potentially lucrative revenue stream. As a result, apps developers will need to consider carefully which platform to support but also in which store to promote their apps. This is particular relevant as each of the current outlets for apps require different coding which creates substantial amount of work for smaller developers who wish to reach a wider audience.

With the projected doubling of worldwide data traffic each year over the next three years, operators and competing non-operator services are increasingly turning to new traffic-shaping solutions to increase the broadband capacity and speed of mobile networks to engage the end-consumer and to keep costs for each service and/or application as competitive as possible. As the users of smart phones and tablets spend more time on the internet, the traffic that each user generates will increase substantially with the average mobile broadband connection being projected to generate 7GB of traffic, the equivalent 3500 MP3 music files each month. ln addition to the domestic use of apps, the business sector is also increasing its use of mobile data traffic in the form of enterprise mobile apps. Such apps can be used for inventory enquiries; tracking of fleet vehicles, assets and personnel; reai-time location of multiple devices; and automated !ocation-based alerts.

Moreover, mobile access to distributed applications and services raises new issues as traditional "middleware" used for such distributed applications fails in such complex and heterogeneous environments.

Summary of the invention

It is therefore an object of the present invention to provide a system that addresses the specific issues relating to dynamic mobile environments.

It is another object of the present invention to provide an operating system that increases the processing power and memory capability of mobile devices.

In accordance with a first aspect of the present invention, there is provided a method of using applications on a smart device, the method comprising: a) downloading an operating system onto the smart device; b) transforming digital information relating to an application into radio frequency data using the operating system; and c) creating a link between the radio frequency data and the smart device as long as the smart device is active.

The smart device may be a mobile smart phone or other mobile device that can download and process applications, for example, a laptop or tablet.

The operating system controls the radio frequency data on a constant basis to adjust stgnai power and strength. Ideally, the operating system only refreshes data that has changed. ln accordance with second aspect of the present invention, there is provided a smart device having an operating system that transforms digital information relating to an application into radio frequency data and creates a link between the radio frequency data and the smart device as long as the smart device is active.

in accordance with a third aspect of the present invention, there is provided an applications platform from which an operating system can be downloaded onto a smart device for transforming digital information into radio frequency data and linking the transformed radio frequency data with the smart device.

The applications platform may utilise wireless virtual cache and radio frequency echo technology.

Brief description of the drawings

For a better understanding of the present invention, reference will now be made, by way of example only, to the accompanying drawings in which:-

Figure 1 illustrates an implementation of the middleware platform in accordance with the present invention;

Figure 2 illustrates queued architecture;

Figure 3 illustrates the named queues;

Figure 4 illustrates a drop and insert mechanism; Figure 5 illustrates a shunting mechanism;

Figure 6 illustrates the overall process;

Figure 7 illustrates a protocol stack representation;

Figure 8 illustrates base station manager interaction;

Figure 9 illustrates call flow in base station manager;

Figure 10 illustrates the ADEP server;

Figure 11 illustrates the ADEP application server;

Figure 12 illustrates an example of a sanjayan application;

Figure 13 illustrates wireless LAN integration; Figure 14 illustrates call flow diameter based authentication; Figure 15 illustrates ad space server;

Figure 16 illustrates a POP3 client and server system;

Figure 17 illustrates call flow for mail configuration;

Figure 18 illustrates call flow for viewing mails;

Figure 19 illustrates POP3 interaction;

Figures 20 to 27 illustrate POP3 client function; Figure 28 illustrates network architecture for the platform in accordance with the present invention;

Figure 29 illustrates a first deployment of the present invention;

Figure 30 illustrates a second deployment of the present invention;

Figure 31 illustrates a third deployment of the present invention;

Figure 32 illustrates a fourth deployment of the present invention;

Figure 33 illustrates P-CSCF discovery using DHCP and

DNS;

Figure 34 illustrates P-CSCF discovery using PDP context activation signalling;

Figure 35 illustrates MO network signalling;

Figure 36 illustrates MT network signalling;

Figure 37 illustrates MT network authentication;

Figure 38 illustrates registration and authentication procedures;

Figure 39 illustrates de-registration procedures; Figure 40 illustrates signalling between a home network and a visited network;

Figure 41 illustrates home network signalling;

Figure 42 illustrates PC to CS signalling; Figure 43 illustrates end-to-end negotiation signalling;

Figure 44 illustrates session handling signalling;

Figure 45 illustrates BGCF base call routing signalling to PSTN based networks;

Figure 46 illustrates termination signalling for roaming subscribers;

Figure 47 illustrates termination signalling;

Figure 48 illustrates multimedia signalling flow;

Figure 49 illustrates SDP parameters negotiation signalling; Figure 50 illustrates user registration and de-registration;

Figure 51 illustrates signalling paths for originating, home and terminating networks;

Figure 52 illustrates a DL UL scheduler;

Figure 53 illustrates RF data architecture in accordance with the present invention;

Figure 54 illustrates RF data process flow;

Figure 55 illustrates a scheduler;

Figure 56 illustrates a receiver downlink;

Figure 57 illustrates fragmentation/packing in accordance with the present invention;

Figure 58 illustrates downlink ARQ process;

Figure 59 illustrates a linked list;

Figure 60 illustrates PDU build and encoding;

Figure 61 illustrates PDU verification and decoding;

Figure 62 illustrates defragmentation and unpacking;

Figure 63 illustrates uplink ARQ process; and

Figure 64 illustrates uplink classification, traffic aggregation and forwarding. Description of the invention

The present invention will be described with respect to particular embodiments and with reference to certain drawings but the invention is not limited thereto. The drawings described are only schematic and are non-limiting. In the drawings, the size of some of the elements may be exaggerated and not drawn on scale for illustrative purposes.

The surge in demand for data means that mobile operators are carrying the content of other providers' traffic and the combination of cost and traffic volume pressures will increase the need for network sharing and outsourcing. Whilst there are still challenges as how apps are distributed, there is no slow down in attempts to enter and capitalise the market.

Grid computing is one way of harnessing computing resources across different organisations and geographies. It is more suited to organisations with large amounts of data being requested by users, such as, rich data traffic which is subject to stringent performance and security requirements. The core advantage of this is its scalability or the ability to spread the processing load among many components. In addition, it is possible to enable and simplify collaboration among a wider audience.

By way of explanation, grid computing is a term referring to the combination of computer resources from multiple administrative domains to reach a common goal. The grid can be thought of as a distributed system with non-interactive workloads that involve a large number of files. What distinguishes grid computing from conventional high performance computing systems, such as, cluster computing, is that grids tend to be more loosely coupled, heterogeneous, and geographically dispersed. Although a grid can be dedicated to a specialised application, it is more common that a single grid will be used for a variety of different purposes. Grids are often constructed with the aid of general-purpose grid software libraries known as "middleware" and can be considered to be a form of distributed computing whereby a "super virtual computer" is composed of many networked loosely coupled computers acting together to perform very large tasks. Furthermore, "distributed" or "grid" computing, in general, is a special type of parallel computing that relies on complete computers connected to a network. This is in contrast to the traditional notion of a supercomputer, which has many processors connected by a local high-speed computer bus.

Another way of harnessing computing resources is cloud computing. Cloud computing relates to systems that provide computation, software, and data access services without requiring end- user knowledge of or dependence on the physical location of the system and configuration. It typically involves over-the-internet provision of dynamically scalable resources. It is a by-product and consequence of the ease-of-access to remote computing sites provided by the internet. Cloud computing frequently takes the form of web-based tools or applications that users can access and use through a web browser as if it was a program installed locally on their own computer. Companies can scale up to massive capacities using cloud computing in an instant without having to invest in new infrastructure, and consumers use what they need on the internet and pay only for what they use.

In grid computing, collaborative apps can be available at any time and at any location and provide freedom for collaboration between mobile application developers. The heavy processing will be in the grid with only a small amount of data being pushed to mobile devices.

Mobile computing affects the design of middleware, and, using middleware to build distributed systems frees developers from the implementation of low-level details related to the network, such as, concurrency control, transaction management and network communication so that they can concentrate on the application requirements. Mobile access to distributed appiications and services raises new issues and the main problem is associated with wireless technology itself. The bandwidth provided tends to be orders of magnitude lower than that in wired networks, signal loss is frequent and the noise level is influenced by external conditions. In addition, mobile devices tend to be characterised by limited resources in terms of processing, memory, display and storage. Such devices are equipped with smart batteries which limit their autonomy and affect both wireless transmission and access to services that require a high computational load. Moreover, user mobility causes problems associated with signal loss during movement as well as problems with address management caused by users traversing different administrative domains and the need to adapt services to the position of the user.

The present invention provides a comprehensive platform that addresses the issues specific to extremely dynamic mobile environments, for example, the requirements demanded by rich content real-time multi-channel distribution in a mobile telecommunications system. This platform is achieved by extending the processing power and memory capacity of mobile devices, including mobile phones and tablets, by a factor of 10 without the requirement for any additional infrastructure by utilising a wireless virtual cache through advance echo technology.

The platform comprises a pseudo grid-based middleware platform that allows distributed systems to be built whilst freeing the developers to concentrate on the application requirements. The platform can be developed to run on all smart phones and tablets using simple scripting routines whilst ensuring optimised bandwidth usage, radio usage and limits power usage.

The middleware platform in accordance with the present invention has two layers, namely, Core Switching and Signalling Servers (CoSigS) and Application Launching and Delivery Platform (ADEP). CoSigS provides signalling and media switching functions that interface to CAMEL Signalling gateway. A CAMEL signalling gateway is partitionware, that is, an intelligent network (IN) component providing a Service Control Function (SCF). It is network aware, radio aware, power aware and based on high availability architecture; and its functions can reside in a single system or can be distributed in multiple systems as it can automatically optimise its performance based on policies and statistics of network, radio and application/media type. CoSigS provides an object oriented O&M System which provides control and trace of each and every event and function of CoSigS. Operators can use the CoSigS to configure parameters, view individual subscriber based transactions, network statistics, load analysis, signalling analysis, fraud detection, law full interception and can raise automatic trouble tickets.

An Automatic Trouble Ticketing System (ATicks) can detect faults and immediately alert the technician with enough trace information for fault localisation and facilitate correction. After the correction it facilitates automatic re-launch of service. It also takes care of alerting the subscribers and/or other elements in the networks in case a system is under fault and being rectified. ATicks can adapt to the operator lifecycle for trouble management.

An implementation of the present invention is shown in Figure 1. In Figure 1 , a system 100 is shown that comprises: an advanced craft terminal 110; a Home Subscriber Server (HSS) 120; an application server 130; servers 140, 150, 160 providing Servicing Call Session Control Function (S-CSCF), Interrogating Call Session Control Function (l-CSCF) and Proxy Call Session Control Function (P-CSCF) respectively; and User Equipment (UE) 170.

ADEP has two parts: a mobile part and a server part. The mobile part provides application execution and protocol processing capability to the mobile device. ADEP Microcode Execution Environment (MiXE) for the mobile device enables remote download of a Just Required Appiication Part (JRAP). ADEP MiXE can request an application to be downloaded for the mobile device user and as soon as the application is processed by the user, the application being deleted from the mobile device and all data associated with the application is carried to the ADEP server for processing. This has enormous benefits:

• A user can have unlimited application in his mobile without storing the application in the local memory.

• The appiication downloaded is not the full appiication but a minimum part of application which is essential for the mobile user eg:

o A form or an input screen,

o A location data extracting program from the Global Positioning System (GPS) chip,

o A eel! identification (ID) obtaining application to extract the ceil ID. In this case, as soon as the cell ID is obtained from the mobile phone, the application is deleted and the ceil ID is passed to the ADEP server to process it and to give further appiication screens or background processing screens.

ADEP mobile part has been designed with following awareness architectures:

1. Power Aware:

The processing of messages and processing of the media and data is optimised using single stack and non buffered algorithm. This algorithm segregates real-time and non real-time processing functions and processes in clock based batch routines. When a set of messages is received, instead of processing each and every message, all the important parts of the message are framed in a "Compressed Processing rail frame" and processed later once distributed. 2. Bandwidth aware:

The messages to be transmitted support mandatory parameters transmission, IP compression, piggybacked messages support. Piggybacked messages can stuff more than one message in an IP packet in order to reduce acknowledgements, and will reduce IP/Transmission Control Protocol (TCP)/User Datagram Protocol (UDP) overhead of additional headers.

3. Radio Aware:

The processing is done based on the priority of the messages. In the case where one of the radio connections is lost, the radio aware module will stop the transmission functions and start working on those processing blocks which do not need to be transmitted. This optimises processing, saves a lot of time and reduces thread correction.

The architecture of the middleware platform ensures optimised bandwidth usage, radio usage and limits power usage.

The ADEP architecture has the following key software design features and implementation details pertaining to message handling of ADEP.

Weight Analysis

The weight analysis calculates the load already handled by queues and also determines if and when a queue is capable of accepting incoming messages to be processed.

Mark for Dropping

The Queue Manager performing weight analysis will also decide whether a message should be marked for dropping.

Queued Architecture

All the incoming messages are pumped into custom named queues after a thorough weight analysis for concurrent lightweight processing. An illustration of the queued architecture 200 is shown in Figure 2. The queued architecture 200 comprises a weight analysis module 210 which receives incoming messages 220 and sorts them into named queues 230 as will be described in more detail with reference to Figure 3. A Finite State Machine (FSM) 240 processes each queue and inserts them back as processed named queues 230'.

Figure 3 illustrates the named queues in more detail. The named queues 230 may comprise, for example, a Short Message Service (SMS) queue 250, a streaming client queue 260, and a Multimedia Message Service (MMS) queue 270.

Drop and Insert

The messages are dropped form the named queues as shown in Figure 3 into the FSM for further processing and then inserted back into the queues as shown in Figure 4. In Figure 4, an SMS queue 250 is shown which is dropped into the FSM 240 for processing and then inserted back into the processed named queue (Figure 3) as a processed SMS queue 250'.

Shunting

The messages from one named queue 230 can be shifted to another named queue 250, 260, 270 without any treatment by a protocol stack or FSM. Shunting happens to bypass a process (not shown) or to treat a high priority message by inserting the message in a high priority queue and/or to avoid race conditions. This is shown in Figure 5.

There are three types of queuing:

Enforced Priority Scheduling

Every queue will be given a priority. A queue will be processed for a fixed time regardless of its load. Even if a queue has no data, the process will wait for a fixed time.

Weighted Priority Scheduling

This is the same as for Enforced Priority Scheduling, but a queue wili be processed only if the queue is not empty. Weighted Fair priority Scheduling

Depending upon the load on each queue, the ratio of processing time between queues will be varied automatically.

Process

All messages waiting in queue may be dropped for processing and different named queues may take different routes, thus performing concurrent lightweight processing. This consumes as little time as possible. Messages in a high priority queue pre-empt messages in the low priority queues. This is shown in Figure 6.

In Figure 6, a process 300 is shown in which three FSMs

310, 320, 330 available for processing items in the named queue 230. In this example, the SMS queue 250 and the MMS queue 270 are passed to FSM 310 with the streaming client queue 260 being passed to FSM 330. FSM 310 inserts the processed SMS queue 250' and passes the MMS queue 270 to FSMs 320, 330 for further processing. FSM 330 inserts the processed streaming client queue 260' and raises the priority of the MMS queue 270 as a priority queue 340.

After processing a message, each FSM 310, 320, 330 has to decide the next Drop or Shunt for that message and marks this in the message. Each FSM can decide on which named queue into which a message should be inserted. There are two types of FSMs, namely, mono-process and multi-process FSMs.

In the mono-process FSM, only one message can be handled at time. Other messages must wait until the previous message has been completely processed. In the multi-process FSM, a thread will be spawned for every new message in the queue. The number of threads is limited by the system in an associated state configuration table. FSM will maintain state for a flow of protocol messages. Each message is associated with a flow identification. Marking its previous state and variables in the state configuration table can do this. A state configuration table may be implemented by way of an FSM bucket. Figure 7 illustrates a protocol stack representation. The function of the extensible mark-up language (XML) parser is to parse the XML messages which comes along with the internet protocol (IP) message, the IP Message having the XML are Notify, Message. The XML parser is also available as an application programming interface (API) in Java IP Simple API where user defined application can be used. The XML parser can parse XML contents and also create new XML messages. The Session Description Protocol (SDP) parser parses the SDP parameters, which is used for understanding the User Equipment (UE) capabilities and subsequently negotiating for call establishment. SDP parser receives SDP parameters and passes to the IP STREAMING SDP engine, which in turn works on IP STREAMING call control and negotiation. SDP parser APIs are available in Java and C based IP SIMPLE API for the usage third party application. SDP Parser uses a cache in the memory database (MemDB) where new SDP parameters can be added.

Java microcode execution (JME) and execute IPIets, Java based applets and will support over the air configuration, over the application configuration. The ADEP server can push application on demand and the application, after usage or in accordance with the application SLA, can be deleted. The user of the UE can, on demand, invoke application and close application. JME can make the user access to any number of application independent of memory, processing power, algorithms, codecs and at the same time will manage data produced out of these application. JME will also give application continuity in the case where the application loses connection, the battery drains and/or a change of mobile phone. In these cases, when the user restarts the application, the application will resume from that part where the user left the application. JME also provides JRAP.

One of JME-JRAP examples can be IP compression. In case of a Compressed IP message the JME can request an IP Compression JRAP. The IP compression program can be obtained from the ADEP sever and the message would be uncompressed. The IP compression program obtained can stay in the mobile device if the user will use it frequently or if the operator can provision the life duration of any such programs. All these features strictly follow IP rules.

As an overview of IP compression, IP compression would reduce complex call setup delay thereby reducing bandwidth stealing caused by in-call signalling. The PSEUDO GRIDS defined compression endpoints are UE and first !P-Proxy, namely, P-CSCF. The IP Compression module has two internal module identifiers, a decompressor and a compressor. The identifier would first see if the message is IP compressed or not. If it is not compressed, it will pass directly to IP Kernel, otherwise it wiil uncompress it. IP kernel uses the IP compression API if the message it transmits needs to be compressed.

Figure 8 illustrates a PSEUDO GRID 400 that comprises:

UE 410 having a SIP client 415, an IP Base Station (BS) manager 420, a translation/mapping function 425 and a Universal Mobile Telecommunications System (UMTS) BS manager 430; and P-CSCF 440 having a Policy Control Function (PCF) 445. Also shown in Figure 8 is a Gateway GPRS Support Node (GGSN) 450 having an IP BS manager 455 including a Policy Enforcement Point (PEP) 460, a translation/mapping function 465, and a UMTS BS manager 470. [GPRS is an abbreviation for General Packet Radio Service.]

As shown, elements within the UE 410, P-CSCF 440 and GGSN 450 communicate with one another as indicated by the double- ended arrows. In addition, the UMTS BS managers 430, 470 communicate with one another as indicated by arrow 480, and the PEP 460 communicates with the PCF 445 as indicated by arrow 485. Moreover, the UE 410 communicates with the P-CSCF 440 using SIP/SDP signalling as shown by arrow 490. Each IP BS manager 420, 455 is responsible for Quality of Service (QoS) negotiation; this gives the binding information to the GGSN 450 to authorise the QoS and to facilitate reservation of bandwidth. It obtains the authorisation token from the Invite message sent by SECURITY SERVER and includes it in binding information to reserve the QoS in the GGSN 450. Each IP BS manager 420, 455 is used to control the external IP bearer service to provide IP QoS End-to-end, each communicating with the associated UMTS BS manager 430, 470 through the associated translation/mapping function 425, 465. Each IP BS manager 420, 455 uses standard IP mechanisms to manage the IP bearer service. As shown, an IP BS Manager may exist both in the UE 410 and the GGSN 450. IP BS Manager is the SLA enforcement point for Service-based Local SLA control., as well as for negotiation of codecs with the PEP 460 and obtains the SLA from PCF. This is shown in Figure 9 in the form of a state diagram.

In Figure 9, the interaction between the UE 410, the P- CSCF 440 and a S-CSCF 495 is shown which is self-explanatory.

Returning to Figure 6, Real-time Transport Protocol (RTP) provides end-to-end network transport functions suitable for applications transmitting real-time data, such as audio, video or simulation data, over multicast or unicast network services. The RTP function is compliant with RFC 1889. The function provides support for AMR, G.71 , G.721 and G.723 codecs. The fixed play-out scheme is also present, though no sender-receiver loss concealment technique has been deployed. The RTP stack has the RTP state engine with API, speech codecs (these can be implemented in C, for example), multi Stream threading, timer implementation and first in, first out (FIFO) queue implementation.

A call control module is responsible for operating the IP protocol stack and anaiysing the SDP, and implements all the basic supplementary services for IP based calls. It uses the IP protocol stack and makes decision based on SDP parameters. The call control module provides functions for codec negotiation, QoS negotiation, media negotiation, call forwarding, call information display, and multiple call establishments. The call control module provides an API so that the call functions can be controlled by a third party application. IP STREAMING Call control uses the APIs to control the IP STREAMING IP module. APIs are provided by Call control and can be implemented in JAVA in an IP SIMPLE API.

IP STREAMING IP module is a state machine, which is controlled by the Call control Module. IP STREAMING IP module is based on the PSEUDO GRIDS TS 24.228 Specification (2003 03). SIP, is an application-layer control (signalling) protocol for creating, modifying, and terminating sessions with one or more participants. These sessions include Internet telephone calls, multimedia distribution, and multimedia conferences. IP invitations used to create sessions carry session descriptions that allow participants to agree on a set of compatible media types. IP makes use of elements called proxy servers to help route requests to the current location of the user, authenticate and authorise users for services, implement provider call-routing policies, and provide features to users. IP also provides a registration function that allows users to upload their current locations for use by proxy servers:

• User identities storage and binding

• Mobile Originating with Service-based Local SLA

• Mobile Termination, with Service-based Local SLA

• Mobile-to-Mobile session establishment

· Support for Subscribe and Notify procedures

• Support for Message

• Support for QoS authorisation

• Mobile originated sessions requesting the establishment of QoS preconditions and coordination · Registration signalling

• Mobile initiated de-registration • UE subscription for the registration state event package

• Registration error conditions

• Re-registration

· User not registered, user not allowed to roam / user unknown

• Registration failure - user authentication failure

• Invite based Signalling flows for session initiation

• Mobile origination, roaming

· Mobile termination, located in home network

• Mobile-to-mobiie session hold and resume procedure

• Mobile-initiated hold and resume of a mobile-PSTN session

• Registration signalling

· UE subscription for the registration state event package

The IP is implemented in accordance with the PSEUDO

GRIDS.

IP security module provides IP security for IP based Transaction which includes usage of TCP based SSL and Usage of IPSEC, The IP Security maintains private a public key for the sake of encryption.

MD5 encryption provides various Digest algorithms based on Base 64 including MD5 Digest algorithm. Apart from normal authorisation schemes, functions for EAP and CHAP are available.

IP STREAMING has recommended SIMPLE Protocol for presence management. SIMPLE protocol is used to simply implement presence client, which will inter-operate with the SIMPLE Presence and Availability server. SIMPLE is based on IP. The SIMPLE Module is implemented as follows:

• IETF SIMPLE • PSEUDO GRIDS Presence Stage 1 specification: TS 22.141

• PSEUDO GRIDS Presence Stage 2 specification: TS 23.141

Following Functions are been handled by the SIMPLE protocol:

• Publishing

• Subscription and Notification

• Presence Document

· Authorisation

• Watcher information

This module also manages:

Radio interface

• Number/size of messages over the air should be at minimum

• Mobile terminals

• Memory, power consumption, processing power is limited

• Publishing

· Standardised mechanism

• Publishing from multiple PUAs

• Merge the information and resolve conflicts

• Keep all the PUAs aware of each other's publishing

• Efficient publishing

· Full state update within each publish transaction is not necessarily needed

• Update only the information that has changed

Filtering

• Subscriber indicates rules for the information to be received • Presence information is constructed based on filtering request and authorisation rules

Efficiency

• Partial notification: notification contains only the information that has changed status

• Dynamic compression mechanism

Content indirection

• Subscriber indicates whether it supports

• PA performs CI if needed taking into account subscriber's preferences

Anonymous subscription

• Subscriber's ID is not revealed to the present identity Multiple types of presence attributes

• Type of the presence attribute: user, device or network specific

• Unique identity for all attributes

Multiple instances

• The same attribute is shown for different subscribers with different values

Location information

• Standardised mechanism to express location information and related privacy restrictions

APIs provided by SIMPLE. These APIs are provided in JAVA IP SIMPLE API.

STREAMING CLIENT Client

. PSEUDO GRIDS

• PSEUDO GRIDS 2

• STREAMING CLIENT client uses !P based SIMPLE Protocol

· STREAMING CLIENT module does Text Based

Instant Messaging • Sharing Media files

• Mobile to Mobile Data/File sharing

• Conferencing

• Multiple STREAMING CLIENT sessions

· Voice conference ( STREAMING CLIENT initiates IP

Invite procedure in case of a Voice/Video chat or conference)

Media Manager is responsible for starting media based session as per the IP STREAMING IP Instructions, and will advertise the codec, frame size and file format it supports for playing and transmitting. Media Manager interfaces with the media hardware to play and record media, as well as inter-operating with IP and Call Control module for its functionality. Media Manager also provides an API for third party applications.

LBS-LSA Location based services interface and interoperate with SIMPLE for notification of presence information. The SIMPLE protocol decides if the Location has to be advertised or not. LBS has algorithms such as TOA, OTD and AGPS. LBS obtains its coordinates from the location and positioning hardware and/or vendor software. With respect to TOA and OTD, it behaves like a (Serving Mobile Location Centre) SMLC Client. LBS will use Vendor specific hardware for the purpose.

MemDB is a memory database based on the system memory, flash or inbuilt RAM in the mobile equipment MemDB can be accessed by any application through its API to create tables, add records, delete records, index records, create primary key, create record set, create snap shot. MemDB APIs are similar to SQL structure inside a MemDB function making it easy for users to access database. The capacity of the MemDB is directly proportional to the memory space allocated by the vendor. The data stored in the MemDB will be stored permanently. MemDB can also compact the table and compress the records when the records are not in use. The performance of the MemDB is based on the processor/controller usage.

The US!M/IS STREAMING CLIENT interface is implemented in accordance with PSEUDO GRIDS TS 33.203 IP STREAMING specification. ISSTREAMING CLIENT interface is used to store IP STREAMING based ISSTREAMING CLIENT application, algorithms and data. In case ISSTREAMING CLIENT is not available, USSTREAMING CLIENT will be used to store ISSTREAMING CLIENT application, algorithms and data. UMTS AKA is used for the authentication. A challenge response protocol and the authentication protocol (AUC) are used when the APPLICATION SERVER challenges the UE after a registration. A quintet containing the challenge is sent from the APPLICATION SERVER to the serving network. The quintet contains the expected response (XRES) and also a message authentication code (MAC). The UE calculates MAC, XMAC, and compares this with the received MAC, and, if they match, the UE is authenticated the APPLICATION SERVER. The AKA-protocol is a secure protocol developed for UMTS and the same concept/principles will be reused for the IP Multimedia core network subsystem, where it is called IP STREAMING AKA.

The ISSTREAMING CLIENT includes:

• The IMPI;

• At least one IMPU;

• Home Network Domain Name;

· Support for sequence number checking in the context of the IP STREAMING Domain;

• The same framework for algorithms as specified for the USSTREAMING CLIENT applies for the ISIM;

• An authentication Key.

o The ISSTREAMING CLIENT will give the CK to the UE o SAS in the MT shall be deleted in case the UE is switched off.

Session information will be stored in the MEM DB as part of configuration data to be used while registration. This application will use the iSIM/USSTREAMING CLIENT interface driver to access the ISSTREAMING CLIENT Application. ISSTREAMING CLIENT applications are available separately with this module, which can be loaded into the ISIM/US1M.

Java IP SIMPLE API provides API to access all the modules described. These APIs are used internally by various modules and also provided for external access. A profile is stored in the mobile, called API ALLOW. RCD. This file can be used by the Vendor to specify those APIs, which can be accessed by the third party. Those APIs, which is not mentioned in this file, will not be allowed by the third-party to access.

Figure 10 illustrates an ADEP platform 500 which includes an ADEP application server 510 which is connected to HSS 520, a configuration module 530, an IP Multimedia Subsystem (or IP Multimedia Core Network Subsystem) (IMS) CSCF module 540, and to a plurality of external applications 550, 560, 570. Although only three such external application servers are shown, it will be appreciated that any number of external application servers may be connected to the ADEP application server in accordance with a particular implementation.

The ADEP application server 500 comprises an REL5/REL6 Application server. These application servers have the following application functionalities: ADEP server connects to the CSCF through the internet software consortium (ISC) interface in accordance with 24.228 and it accesses HSS 520 through the SH interface associated with MMS; and ADEP server connect to the external application servers 550, 560, 570 and can act as the bridge between non IP STREAMING System and IP STREAMING System. As mentioned above, the ADEP piatform 500 comprises the IP application server 510, APIs for external applications and applications on it for rolling out services for both retail consumers as well as corporate customers. A wide variety of applications can be integrated to the system. The system offers the following standard features. Applications include IP multimedia services like Push-to-Talk, Instant Messaging, Remote monitoring etc. as shown in Figure 11.

The above suite of products enables the 2.5G and 3G network to provide extensive range of services to the mobile users. Some of the services are given below:

Presence and availability services provide presence and availability information in the following ways:

• Event based presence information

• Instance based presence information · Location based presence information

• Traffic based presence information

• Collaborative presence and IM

• Application based presence (shows those application you have subscribed to location services, director services, POP3 services, VoIP Services etc.)

The instant messaging services (IMS) provide a platform to exchange messages between the mobiie devices or between a mobile device and a PC. The users can add and delete their Chat buddies from the mobile phones and can use buddies to provide them the required information at regular intervals or on the click of a button. The STREAMING CLIENT service enables Multiparty conference, multi lingual chat, offline messages when you mobile was switched off, presence even based STREAMING CLIENT (if the target user is not in IM, the message is sent to SMS or MSN or Yahoo). The STREAMING CLIENT User can save the conversation and save it and mail it to a user through SMTP service. The storage server enables a mobile user to optimise radio bandwidth and can browse his personal computer, store STREAMING CLIENT chat sessions, store the photograph, access a file and mail it to another user. The mobile user can request a file to be downloaded to his PC through storage server enabled browser. The file downloaded will be directly downloaded to his PC through the internet connection of the PC thus saving the mobile bandwidth. The mobile user can now browse the downloaded file in is PC and at his ease or he can send it as a mail to another user. The storage server can host J RAP based application for Streaming Client which he can access any time, it can be an extended storage for his mobile device.

Location services (SANJAYAN) could provide location information on mobile user using methods such as Cell ID, Time of Arrival (TOA), Enhanced-Observed Time Difference (E-OTD), Global Positioning System (GPS) etc. The location information collected in such manner can be used by any application. The location service Application server which is integrated into the middleware platform of the present invention can provide information on location of the mobile devices. This can be used in applications such as

· Sales force tracking

• Proactive mobile service

o As you reach the airport, airport information starts appearing.

o As you reach 101 California street , a parking lot is allocated for you

o Advertise based on people location

o Push an application based on location

• Vehicle tracking

o Track speed

o Track routes and optimise route

• Emergency services o People in case of emergency can broadcast their location others

o Find the hospitals near you

• Presence based service

o Create SLA based on location

o When you are at office you can contacted by mail only

o When you are at home you can be contacted by your landiine

SANJAYAN will constantly broadcast your location "based on user and network privacy policies" and this is collected by the network and your location is computed and based on this various application for which you have subscribed will be alerted with your location. The application based on the SANJAYAN credential will be allowed to contact you. SANJAYAN also supports remote download of application on your mobile device or handset and after you use the application, the application and its associated data will be automatically erased. This facility is provided by ADEP. An example of a SANJAYAN application is shown in Figure 12.

Voice over IP calls can be provided on GPRS and 3G phones on click of a button, providing easy-to-use and effective communication tool. This service uses IP STREAMING IP as signalling protocol to communicate to the CSCF engines. This service is in accordance with 24.228.

A push-to-talk service can be implemented using 3G/GPRS handsets, for example, as a Walkie Talkie. The push-to-talk client is the mobile phone client that communicates with the push-to-talk application server. The phone can establish a voice connection to the application server and also accept a call from the application server. The push-to- talk client allows creation groups of contacts based on an event criterion such as location, cell ID or any other parameter defined by the operator and visible in the network. The User can make a call to a group created and approved by the push-to-talk provisioning engine under operator policies. The client sends an INVITE message (with Group as the ID) which will be forwarded to the push-to-talk application server and thereafter to the called party.

The push-to-ta!k server engine receives INVITE from the calling or broadcasting user. It analyses extracts the "to" called party ID from the message and identifies all the users allocated to that group, in case the group is a dynamic group (users on a specific location ID), the engine computes dynamic user list from the event and instance database. After obtaining the user list the push-to-ta!k engine would establish calls and media path. The media arriving from the calling user is multicast to ail the users in the list.

While making a push-to-talk call, the users can be configured listen only listen and talk. If a listening user in the group is not reachable or if the call establishment to the listening user fails, the message is stored in the server.

in the over all scenario, push-to-talk is implemented using IP. Appropriate IFCs are set for push-to-talk users to forward all messages related to the push-to-talk server. The push-to-talk server will function as a third party applications server.

A directory service lists down the applications and privileges that a user is eligible for and lists available applications.

The functionality of the signalling and media gateway provides the bridging of call setup procedures between IP and circuit switched networks like PSTN and the bridging of media formats.

The codec translation functionality provides translation from one form of codec to other form between the IP and other wired and/or wireless networks. This service is used when two UE have different set of codecs, and the application server can ask the codecs translation application server to bridge the 2 codecs. Integrated Services Digital Network (ISDN) supplementary services can also be provided by the application server which performs network based services such as Call forwarding, Call hunting, Call queuing, legal interception, Number portability, Voice mail service, Call waiting, call back service and call transfer service.

The integration of mobile networks with Wireless LAN (WLAN) allows users to take advantage of best features of both networks. The application server will help the WLAN network to get authenticated and also share the ADEP services. The WLAN and IP STREAMING network can seamlessly interoperate with respect to services. The application server can act as a proxy to all WLAN events. In the call flow charts shown in Figures 13 and 14, the application server acts as a PSEUDO GRIDS AAA Proxy and it contacts HSS where the HSS behaves as PSEUDO GRIDS AAA Server. There is no difference in HSS as the protocol between the AAA Proxy and HSS is Radius or Diameter. Call flow RADIUS based authentication is shown in Figure 13 and call flow DIAMETER based authentication is shown in Figure 14.

Event/Instance based services are services that are invoked upon an event triggered on the mobile terminal. For example, pressing of a number in 9 dial pad could invoke an application that sends a information asking for a taxi in the nearest cab company. The applications may also be invoked based on an instance on the mobile terminal. For example, an application provides information to the user as soon as he/she enters into a particular cell in which eat outs or shopping malls are present in the vicinity.

The application download service has a repository of mobile application execution service applications which can downloaded on demand to a mobile and the mobile will execute these services through Java micro execution code. This service enables user to on demand, create services, subscribe to services and execute applications. The ADEP server transmits JRAP to the ADEP Mobile part. This ADEP server provides MiXE environment to broker mobile based application and data to the UE.

Alerts provides a mechanism to provide continuous push of information such as stock quotes, cricket scores, etc. that are of use and interest to the users.

SMS STREAMING CLIENT interoperability server provides a service which will enable two-way transaction between STREAMING CLIENT and SMS server. User will be able to use STREAMING CLIENT to send a message to the STREAMING CLIENT user and vice versa.

STREAMING CLIENT and Third party messenger service can provide seamless connectivity. With the STREAMING CLIENT provided by the ADEP server, a user can start chatting with Jabber based STREAMING CLIENT and presence servers, MSN, YAHOO, ICQ (licence required from the third party STREAMING CLIENT provider) STREAMING CLIENT server and have seamless connectivity.

Various application scenarios are possible with a wide variety of compelling applications which can be enabled for retail and corporate end-users using ADEP servers. These applications can significantly enhance productivity and ease of information flow for the end-users. Some of the applications of our products are given below:

Logistics and Fleet Management

The platform enables constant monitoring of the movement of goods and hence optimisation of resources.

Sales Personnel Tracking

Sales personnel carrying mobile phone running the application can be tracked continuously. This enables organisation to optimise and dynamically plan the travel and increase effectiveness of the sales force.

Corporate Information Exchange

Middleware products allow corporate back-end systems to be connected to the system. This allows easy and fast retrieval of information for executives on the move, irrespective of the location and time. Various information services can also be provided over mobile devices increasing the reach and effectiveness.

Access to Public Facilities

A variety of information services can be provided over the mobile providing valuable directions and assistance to mobile users. Some of the applications include calling a taxi, locating nearest hotels, hospitals, bank ATM's, weather information, flight information etc.

While showing information, this application server can render images, music, video based on the operator configuration, these images can be advertisements and commercials, while the operator gives the information free to the users. For example, news or stock values can be shown to the user at the top of the screen and, below, an advertisement can be shown as illustrated in Figure 15. Applications like these can ensure revenue to the service providers.

Lightweight corporate Post Office Protocol (POP) applications, such as POP3, are available in the mobile device as part of the email client, but there are certain constraints in the POP3 applications. These constraints tend to reduce the available memory for storing all the mails, and long connection times to download mails where there are multiple POP3 high connection times and losses due to connectivity. For this purpose, a lightweight corporate POP3 application is been introduced. Here, STREAMING CLIENT and presence service is used for the POP3 where the ADEB MIXE server POP3 as a JRAP application. In addition, the products can be used in critical environment like Emergency Contact by extracting the user location from the network.

A POP3 implementation 600 is shown in Figure 16 and comprises POP3 application server 610 connected to a plurality of web servers 620, 630, 640, for example, and third party external Simple Mail Transfer Protocol (SMTP) servers, and to a plurality of clients or users 650, 660 via an IP STREAMING core network 670. The POP3 application server 610 acts as a bridge between clients or users 650, 660 and third party external SMTP servers 620, 630, 640.

Figures 17 and 18 show call flows for mail configuration and mail viewing respectively. In Figure 17, when a client or user 650, 660 wants his/her mail details, he/she contacts the POP3 server 610, which in turn, contacts the appropriate web server 620, 630, 640 to obtain the required information. Then, the POP3 server 610 will send the response to client or user 650, 660 with the details received from the appropriate web server 620, 630, 640 and store details as well as in server database.

When the client or user 650, 660 is connected to the POP3 server 610, the server 610 will check if the client or user 650, 660 is configured for any e-mail accounts. If the client is not configured for any e-mail accounts, the server 610 will send the configuration form to the client or user 650, 660. The client or user 650, 660 completes the details and sends the completed form back to server 610. When server 610 receives the configuration for the e-mail account, the server 610 checks the format of all the fields in the configuration form. If it is OK, the server 610 contacts the third party web server 620, 630. 640 to check the user and password are valid. If all the fields are correct, the server 610 sends the response to the particular client or user 650, 660 and stores all the details of the client or user in the server database. If the details of the configuration form are invalid, the web server 620, 630, 640 rejects the POP3 request and the POP3 server 610 sends an error response back to the client or user 650, 660 with a reason for the rejection.

After the client or user 650, 660 has already configured his

POP3 account successfully, if the client or user wants to check his/her mail, all he/she has to do is click the POP3 service in the client side and immediately a send request is triggered. When the server 610 receives the request as shown in Figure 18, the server 610 get the user details from database and will contact to the third party web server 620, 630, 640 to download the required information if necessary. Then, the server 610 checks the mail details, for example, for any new mails or un-viewed mails, from the downloaded information and database, generates mail lists, sends the mail lists back to the client or user, and stores the all mails in the database. The client or user 650, 660 selects the particular mail from mail lists and sends back it to the server 610 which reads the particular mail from the database and generates a show card and sends it back to the client or user 650, 660.

If the client or user 650, 660 sends the request to compose a new mail or to reply to the mail, the server 610 checks the format of the message. If the format is wrong, the server 610 sends the error response with details. If format is correct, then the server 610 checks the user ID and password are valid by contacting the appropriate web server 620, 630, 640 and sends the mail to that web server. If the user ID is invalid or any error occurred in the transmission of the mail from POP3 server 610 to the appropriate web server 620, 630, 640, the POP3 server 610 sends an error response back to the client or user with error details. If the user ID is valid, the POP3 server 610 sends the confirmation response.

When POP3 server 610 receives the request to delete a mail from mail list, first the POP3 server 610 contacts the appropriate third party web server to delete the particular mail. If the mail is successfully deleted, then the POP3 server 610 deletes the mail from its database then generates or modifies the mail list for the client or user and sends the modified mail list back to client or user. If the mail is not successfully deleted, the POP3 server 610 sends the error message.

If the client or user 650, 660 wants to modify an existing account, he/she selects that particular account from the list and sends it to the server 610. Whenever the server 610 receives the modify account request, the server 610 gets the details for the mail account to be modified and sends it to the client or user who requested the modification. The client or user 650, 660 then sends the modified details then the P0P3 server 610 which carries out he same processing steps as for the configuration procedure described with reference to Figure 17.

TCON is the main class of the POP3 server 610 as shown in Figure 9. When started, the server 610 first will create the instance of POP3 function class 612 as indicated by arrow 614. POP3 function class comprises a number of functions, each function having a specific job, for example, writing to a database, reading from the database, listening and waiting for an incoming message, checking the message format etc. The second step of the server 610 is creating a database connection 616 as indicated by arrow 618. When a database connection 616 is created, the server 610 starts the listening and waiting function for the incoming message. When any message is received from the web server 620 via an internet connection 680, the server 610 creates a new instance of a process thread 682 and gives the message reference to the process thread. The server 610 then waits for another message.

The process thread 682 first checks the message format, and, if is correct, it then parses and checks the show card format is also correct before carrying out the server procedure. The process thread functionality is divided in to three modules: one module is the process thread itself; and the other modules are mail gateway class 684 and show card generator class 686. The mail gateway class 684 is used to contact the web server 620 and to transfer and download the mail information to and from web server 620. All mail gateway functions (SMTP, POP3) are done in the class. Show card generator class 686 is fully used for generating the show card messages. It gets the inputs from other two modules 682, 684 and generates the message and gives it to the send thread 688. The send thread 688 sends the data to the IP STREAMING core network 670.

The database architecture is designed to have a POP3 main table, a user configuration table and a username inbox table. The user configuration table and username inbox table are dynamically created for each user. The table is username + configuration and username + inbox. Various configuration commands are implemented, for example, to configure the mail account, check the configuration is correct and to use the show card to view the account.

A POP3 client functional specification is as described with reference to Figures 20 to 27. The Client contains the main menu (Figure 20). The main menu contains the list of services provided by the ADEP mobile part. When the 3G application services is selected from the list, the services, and the status of the services for the user is shown in the discover list (Figure 21). The list contains the services with status and availability of the services and control pane! item. To subscribe to the service, click the POP3 service item in the discover service menu. It will automatically subscribe the user for the particular service and change the status of the service as subscribed.

To activate the POP3 service, the POP3 mail settings need to be configured by clicking the control panel. The control panel menu will show up. Now clicking on the POP3 item in the list (Figure 22) starts the configuration procedure. After finishing the configuration procedure, clicking on the service from the discovery services list it will automatically start the service.

Discover services item is used to discover the service and show the discover service menu. Clicking on the POP3 in the control panel will show a form containing the options for creating the new account or modify the existing accounts (Figure 23). Clicking on a new account will show the configuration main form and clicking on an existing account provides the fist of ail existing accounts.

If there is no existing account, it will directly show the configure main form (Figure 24). The configure form contains the Name, e-Mail ID, username, password, SMTP address, POP3 address fields and also contains two option buttons for secure authenticated password and mail attachment. After the configuration has finished, clicking 'OK' will send the request to the POP3 server to configure the mail. The POP3 server contacts the mail server with the received details. All mail inputs are valid and correctly executed in the mail server, the mail server will send the response form with a confirmation. Otherwise, the mail server will send the error response with details.

After successful configuration of the POP3 mail, clicking on the POP3 from in the discovery service list sends a start command to the POP3 server, the POP3 server does all the processing for the mail, including downloading new mails and sends the show cards with list of all mails and new mails. If the user subscribes to SPA while configuring the POP3 account., the POP3 server asks for the user name and password for authentication. If the user name password is correct, then the mail list form is shown (Figure 25). If the user has not subscribed to the SPA, then the user can directly go to the mail list. Clicking on the new mail option shows a new mails list, or clicking on the all mail option shows all mails in the list, new and old. To view a particular mail (Figure 26), it needs to be selected from the list. Clicking on the view button shows the mail in view form.

To delete a particular mail, select it and click the delete button. To compose a new mail, click on the compose button to see the compose screen. The compose screen as the following fields To, cc, bcc, Subject, text body (Figure 27). Click ok to send the mail and it will go back to mail list. Cancel will go back to the mail list. Click exit to exit the mail box.

While you are viewing a particular mail if you want to reply.

In this case, click the reply button to send the reply mail to that particular ID. The reply all button is used for sending a reply to all the mail ID including cc, bcc in that particular mail. The view more button is for going back to your mail box list to view your other mails. Exit button is to exit from the mail box to main menu. Configuration commands are provided for the creation of a fresh account. Figure 28 illustrates a network architecture 700 where a middleware platform 710 in accordance with the present invention can be deployed end to end with applications. In addition to the middleware piatform 710, the architecture 700 comprises a mobile communications network 740 and a WLAN network 760. The middleware platform 710 is also connected to a plurality of servers 780 via a CSCF 712.

The middleware platform 710 also includes an SMS centre (SMSC) 714, a signalling gateway 716, a media gateway 718, a COPS policy database 720, HSS 722, operator terminal 724, WLAN server 726 and a switch 728 connected as shown. The switch 728 interfaces with the mobile communications network 740, and in particular, a Mobile Switching Centre (MSC) 742 and a GGSN 744, both of which are connected to a base station or communications tower 746. Mobile users 748, 750 receive signals from and transmit to the base station 746.

The WLAN server 726 is connected to a plurality of WLANs

762, 764, 766, which in turn, are connected to a plurality of mobile devices 768, 770, 772.

The servers 780 may comprise a presence server 782, an Instant Messenger (IM) server 784, a media delivery server 786, a iocation computer 788, a call supplementary services server 790 and a Virtual Private Network {VPN)/SIP interoperability server 792.

Both CoSigs and ADEP in the network are depicted in Figure 28. The components in the architecture have the following features:

CSCF 712

• Call processing

• Security server

• Network IP server

• Multi-variant IP stack

o IP STREAMING - REL 5

o IETF IP 3261 , 2543 o Charging gateway

o Simple/Instant Messenger Support o Diameter and Radius Support

• MGCP Support

• In built SLA definition/control function

• SH, CX, DX, ISC, MH, MG, GO interface

• SNMP and O&M Interface

Signalling Gateway 716

• IP - SS7-ISUP interface

• IP - SS7-TUP (PSTN) interface

• IP - SS7-BTUP interface

• IP - SS7-Belcore (ansi)

• MGCP and trunk selection

• ISDN supplementary service support

WLAN Server 726

• Full interoperability server to 3G and GPRS

• AAA client for WLAN

• QoS based media manager

• Signalling route manager

• Roaming and device interchange

• Virtual SSTREAMING CLIENT and SLA based

• Application resumption

Media Gateway 718

• Multi-discipline media collaboration

• Codec bridging/translation

• Built in DIFFSERV for QoS preservation

• Built in RTP and RTCP

• ROHC, IP compression, PPP support

• T1/E1 CAT-5 support

• Video, voice and high speed data support • SLA enforcement point

PDF or P-CSCF 720

• Pseudo grids IP STREAMING based HSS and AAA server

· Diameter and LDAP support

• MAP and CAP interface {VLR and SCF)

• Sh, CX and DX interface

• Application interface

HSS 722

· IP STREAMING PDF TS-29.207 (IETF cops)

• Network policies

• Route optimisation policies]

• Content policies

• Charging policies

· User policies

• Security policies

• Access policies

A first deployment of the present invention is shown in Figure 29. An architecture 800 is shown in which a single access network 810 is shown connected to an IP STREAMING Core network 820. However, it will be appreciated that more than one access network can be connected to the IP STREAMING Core network 820. A user 830 accesses the IP STREAMING Core network 820 in accordance with the present invention via the access network 810. The access network 8 0 connects to a GGSN 840 within the IP STREAMING Core network 820.

Also within the IP STREAMING Core network 820 are: a P- CSCF 845; an l-CSCF 850; an S-CSCF 855; a STREAMING CLIENT service switching function 860; and Open System Architecture (OSA) service capability 865; an OSA application server 870; HSS 875; IP application server 880; and a presence and IM server 885 connected as shown. A second deployment of the present invention in which an IP STREAMING Core network 820' similar to IP STREAMING Core network 820 shown in Figure 29, is shown. Elements that have been described with reference to Figure 29 have identical reference numerals and additional elements that are the same are labelled with the same reference numeral followed by a ""' (a prime). In this case, two GGSN or two access networks 840, 840' are connected to a single P-CSCF 845 so that they share the same IP STREAMING core network.

In a third deployment of the present invention, as shown in Figure 31 , another variation of the IP STREAMING Core network 820" having two GGSNs 840, 840' are connected to respective SECURITY SERVERS or P-CSCFs 845, 845' and share the same Serving and AAA Network with applications. As before, elements that have been described with reference to Figure 29 have identical reference numerals and additional elements that are the same are labelled with the same reference numeral followed by a ""' (a prime).

In a fourth deployment of the present invention, two access networks 900 are shown in Figure 32 that each have individual IP STREAMING Core network defined by respective GGSNs 905, 905'; P- CSCFs 910, 910'; l-CSCFs 920, 920'; S-CSCFs 930, 930'; STREAMING CLIENT switching functions 940, 940'; HSS 950, 950'; IP application servers 960, 960'; presence and IP servers 970, 970'; OSA application servers 980, 980'; and OSA service capability servers 990, 990' which share a router 995 for application sharing, roaming and even load sharing..

The middleware platform of the present invention and its components full comply with IP STREAMING PSEUDO GRIDS specification 2003 - 09 version. Figure 33 illustrates P-CSCF discovery using Dynamic Host Configuration Protocol (DHCP) and Domain Name Server (DNS) and Figure 34 illustrates P-CSCF discovery using Packet Data Protocol (PDP) Context Activation signalling. In Figure 35, signalling in a Mobile Originating (MO) Network between UE, Serving GPRS Support Node (SGSN), GGSN and P-CSCF (PDF) is shown. The present invention supports GO interface and Diameter interface. A third party DIFFSERV or MPLS router can be used in case the GGSN is not supported with the DIFFSERV. Virtual PDP context authorisation will be done using the third party DIFFSERV or MPLS.

Figure 36 illustrates signalling between P-CSCF (PDF), GGSN, SGSN and UE in a Mobile Termination (MT) Network. QoS is supported using GO interface as well as SBLP based QoS provisioning. The security server can generate Authentication token and pass it to PDF in order to approve any binding information from UE to PEP (or GGSN) and PEP (or GGSN) to PDF as shown in Figure 37.

Mobile user registration procedures and APPLICATION SERVER support diameter based authentication and APPLICATION SERVER and service discovery procedure are supported by the present invention as illustrated in Figure 38.

The present invention supports network based de- registration for both home and roaming users as well as roaming authentication, roaming barring, roaming based service and QoS authorisation. This is shown in Figure 39. In addition, CSCF discovery procedure and CSCF downloads IFCs dynamically and routes messages based on application service as shown in Figure 40. HSS provides IFC creation and development function which an be used to author IFC based on various states. These IFCs can be downloaded on demand and can be changed on state of the call or the HSS intervention.

The present invention also supports resource negation based on SDP parameters of the UE. In case of unavailability of resource, the session is abandoned. T he negotiation takes place at every CSCF node as shown in Figure 41 . Bridging PS to CS based signalling is also supported, the platform being capable of converting any IP based Originated calls to Signalling Session #7 (SS7) [ISDN User Part (ISUP)] based signalling procedures and vice versa. This is shown in Figure 42. Here, MGW refers to the Media Gateway and MGCF refers to the Media Gateway Control Function.

End to end negotiation for resources between CS and PS networks are also supported as shown in Figure 43. MGCF supports full H248 interaction. Session origination which performs an analysis of the destination address is also supported as shown in Figure 44. The session origination determines if it belongs to a subscriber of a different operator. The originating network operator does not desire to keep their configuration hidden, so it forwards the request to a well-known entry point in the destination operator's network, l-CSCF. l-CSCF queries the HSS for current location information, and finds the S-CSCF assigned to the subscriber S-CSCF#2, and forwards the request to S-CSCF#2. The terminating network operator does not desire to keep their configuration hidden, so the l-CSCF does not insert itself into the signalling path for future exchanges.

Figure 45 illustrates Breakout Gateway Control Function (BGCF) based call routing to Public Switched Telephone Network (PSTN) based networks. Figure 46 illustrates a termination procedure which applies to roaming subscribers when the home network operator does not desire to keep its internal configuration hidden from the visited network. The UE is located in a visited network, and determines the P-CSCF via the P-CSCF discovery procedure. During registration, the home network allocates the S-CSCF. Figure 47 shows the following functions in MGCF in the STREAMING CLIENT CN subsystem, which is an IP endpoint that initiates and receives requests on behalf of the CS Networks and MGW. Other nodes consider the signalling as if it came from an S-CSCF. The MGCF incorporates the network security functionality of the S-CSCF. Agreements between network operators may allow CS Networks termination in a network other than the originator's home network. This may be done, for example, to avoid long distance or international tariffs.

Figure 48 illustrates multimedia signalling flow for the addition of another media where the originator and terminator are both roaming and operated by different networks. Both networks are without I- CSCF providing configuration independence. The UE has already established an STREAMING CLIENT session carrying voice and is generating an INVITE request to add video media to the already established STREAMING CLIENT session.

Figure 49 illustrates full Media and SDP parameters negotiation and supports media bridging. Figure 50 illustrates User registration and de-registration when the user is roaming.

Figure 51 illustrates APPLICATION SERVER Supports THIG and can Hide the network based on operator policies. When the originating network operator desires to keep their configuration hidden, the request is forwarded through an i-CSCF (l-CSCF#1) to a weil-known entry point in the destination operator's network, l-CSCF#2. I-CSCF#2 queries the HSS for current location information, and finds the S-CSCF assigned to the subscriber (S-CSCF#2), and forwards the request to S- CSCF#2. The terminating network operator does not desire to keep their configuration hidden, so l-CSCF#2 does not insert itself into the signalling path for future exchanges.

The present invention supports other ISDN supplementary services such as:

· Call forwarding

• Call Queuing

• Call waiting

• Call hunting

• Call legal interception

· Number portability

• Voice Mail • Call conference

• Call conference with multiple codecs

• Call forwarding to PSTN network

• Call diversion to PSTN network

The present invention requires the use of a device scheduler that has includes a packet selection module and a burst formation module.

There are two types of scheduler that are implemented in the present invention, namely, a UL Scheduler and a DL Scheduler. The scheduler operates such that incoming packets from the line Design are dealt by the DL Scheduler. The incoming packets are time stamped by the line Design interface. The packet has a header and an address. This IP Address will allow a look up of associated Caller ID (CID). Multiple IPs can map onto one CID.

For the management of incoming traffic, an initial policing is done for all the packets with associated CIDs. An Average throughput Rate QoS parameter is associated for each CID. A traffic shaping module queues the packets if the traffic rate of the service is below the average throughput rate. All the packets for connection that exceed the average throughput rate are disDesigned. As per the defined traffic throughput and the average throughput time, every packet that is queued causes an update in the time which specifies the previous traffic policing and the current traffic that has to be scheduled.

The system utilises FIFO scheduling. Every element in a queue represents a scheduling time date in the number of frames from the current frame and each element has a representation to a Vector of elements for which the first packet in the queue has a scheduling time. From the time stamp at the LINE DESIGN INTERFACE and the maximum jitter QoS parameter, the calculation of the Scheduling time is done. The packet selection starts with traversing the array from zero position (the dead line of the frame currently being allotted). This array points to a first element of Vectors which represents a CID for which the first packet in the queue has the current dead line. Allocation of packet is made if the queue is below the minimum rate. The minimum rate is determined by the traffic shaping module method. If the queue is above the minimum rate, the scheduling is shifted to the next element after posting a mail box. Otherwise, the next packet is analysed and allocated if the packet is identical, or the element is removed from this Vector and inserted in the appropriate Vectors down the array if the packet is not identical. The allocation of the first packet in the next element is done in the similar way and this process continues till no elements exist in the current array position.

in a first case, the packet selection algorithm can continue to the next array element which points to the next Vectors of elements for which the first packet in each queue has a dead line. The packets are allocated and the process continues till the end of the array. If the frame is full before the array ends, then the packets with earliest scheduling time has been allocated.

In a second case, the packet selection algorithm can go to the next array element. The allocation can only be done for queues which have the appropriate MCR. The disadvantage of this is there is a higher risk of packets being dropped when a large burst arrives with the same scheduling time. The advantage is that a higher overall system bandwidth is achieved by making use of radio characteristics.

However, the combination of both these cases would be optimal.

The system uses Vector based forwarding and Scheduling. A Vector is created for scheduling queue respectively and within the list the non real time service and BE connections are ordered by their QoS priority level parameters. For the UGS allocation is done by calendar scheduling method.

The traversing begins at the primary element and goes down the linked list. A Traffic shaping module algorithm is used at each element and packets are selected according to the optimal Protocol Data Unit (PDU) size. As the rate is reached, the current element is mail boxed as inactive and proceeds to next element. For every new frame, the mail box is reset. As the sub frame becomes full when the packet selection is stopped, a reference remembers the last allocated element for non real time service and BE. In the next frame, the Vectors will be traversed again for the real time service connection. At each priority level, the algorithm checks for the reference location when reaching the non real time service and BE connections. The algorithm jumps to the reference location if the reference is set for a connection within the priority level. Otherwise, the level will be moved one by one and hence fair treatment can be meted out to the lower level connections without creating a priority inversion.

Initially, the UL scheduler starts as the UL-MAP generated by the UL scheduler must be mapped to the DL sub frame. When the UL sub frame is fully allocated, the DL scheduler can be run as shown in Figure 52.

The UL scheduler 1000 includes a UL packet Scheduler 1010. During the connection negotiation and set up, an element is created which contains all the QoS parameters relevant to the connection and other parameters.

As shown, a UL Packet Selector 1020 interfaces with a grant management module 1030 which both provide inputs for a burst creation module 1040.

The UL scheduler 1000 also includes a DL scheduler 1050 which includes a DL packet selection module 1055 which interfaces with a fragmentation/packing module1060. The fragmentation/packing module 1030 interfaces with a queues module 1065, which in turn, interfaces with the DL packet selection module 1055 and a DL burst module 1070. The DL burst module 1070 also interfaces with the DL packet selection module 1055 as shown, and provides an output to an air interface layer 1080.

For real time service connections two instances of this element are created.

i. One with mail box for connection reaching defined traffic throughput traffic rate.

ii. One with a mail box for connection reaching average throughput traffic rate.

UGS elements + First instance of real time service elements are inserted to represent a calendar of scheduling times in an array. Elements of non real time service and BE and second instance of real time service instance are inserted in large Vectors which follows the order as real time service, non real time service, BE. The bandwidth allocation algorithm deals with the array which represents the scheduling time calendar for the allocation of defined traffic throughput rate to UGS and real time service connections. Then it deals with second Vectors for allocation up to maximum rate for all connections. As the defined traffic throughput rate is equal to the maximum reserved rate no need arise for the second UGS element. The management layer determines the ranging channel size and fed to the UL scheduler as input.

For the FIFO scheduling, the real time service connections parameters are:

• Defined traffic throughput rate

• Average throughput rate

• Maximum latency

• Maximum jitter

The incoming bandwidth requests are placed at a position in the array using the calendar array. Grants scheduling is allowed till this rescheduling time and should not occur after this. If the scheduling time misses for the first time, the grant is rescheduled to position. If the second scheduling time misses, the grant is disDesigned.

For fixed grant scheduling, the UGS connection parameters are:

• Defined traffic throughput rate

• Maximum latency

• Maximum jitter

Bandwidth grants are placed in specific intervals as specified by the UGI using a calendar array. Scheduling of grants is allowed when interval falls within the maximum jitter distance of the current frame. A higher grant is temporarily given when the slip indicator bit is set.

For non real time service, remaining rtPDS and BE allocation, the bandwidth allocation algorithm goes to here linked lists representing each connection type after granting UGS and real time service requests up to minimum rate. The non real time service and BE connections are ordered by priority level.

After the bandwidth is granted by the bandwidth allocation algorithm, information about the grant is sent to bandwidth (BW) grant store.

For interface to frame mapping, two input parameters are utilised that comprise two dimensional arrays, burst sizes and SSlDs. These are passed to the frame mapping. The UL MAP is generated by the frame mapping as PDU. The reference and length is returned to the DL scheduler.

For traffic shaping module update, the SS can receive a minimal amount of excess grant because of grid granularity and it is not counted hen updating the traffic shaping module. The traffic shaping module is updated during the traffic shaping traffic shaping module and not in the policing stage traffic shaping module. For grant management, the formed BW grants are grouped in to queues per SS by the BW grant store. The queues of multiple individual grants per SS will form the basis for each burst to be mapped in to the DEVICEA UL sub frame in the frame mapping algorithm. Also the BW grant store computes the current frame allocation.

For DEVICE Sub frame allocation, a counter is kept representing the sub frame area. The amount of data (bytes) is counted on every granting of BW request. According to the modulation/coding type for SS, this is converted into an area of DEVICEA frame. The frame mapping begins once the counter reaches full.

The handling of bursts comprises:

• Taking groups of BW grants from burst queues made at BW grant store

• Determination of place in the two dimensional DEVICEA frame

• Generation of the information for the UL MAP

• Generation of PDU of this information and passing to DL Scheduler.

The frame coordinates can be determined as the burst sizes are known. The area occupied in slots on the frame can be computed, hence the burst dimensions are known in slots and bytes.

In order to do UL allocation, mapping is done from top left corner sequentially, across the end of the row and further from the next row down.

The SDU PDU interface is used to pass the UL map as

PDU to DL Scheduler.

The DL Scheduler has the following modules:

DL packet selection 1055:

The packets to be transmitted are selected. The information regarding the selected packets is transmitted to the fragmentation and packing algorithm. The packet selection algorithm is similar to the UL packet selection algorithm.

Fragmentation and packing 1060:

This creates the output PDU and computes overheads such as headers, sub headers, CRC, encryption and burst overhead, and sends the CID reference/length of the created PDU to PDU store.

Queues 1065:

The queues group the PDU to bursts and computes the cumulative burst sizes and the current frame area used.

DL burst 1070:

If the threshold is exceeded, the accumulated PDUs are mapped by the DL Frame mapping. This identifies the largest free rectangular space left and passes this information to the DL packet section which selects NRT packets to fill these places. This process continues till the allocation is done fully. Upon reaching completion DL frame mapping passes PDU reference/length database and burst coordinate to the AIR Interfacesical layer 1080.

The RF Data Architecture is shown in Figure 53 and the RF Data process flow 1100 is shown in Figure 54. In Figure 54, a Virtual Local Area Network (VLAN) 1 1 10, IP 1120 and Asynchronous Transfer Mode (ATM) 1 130 provide inputs for a classifier 1 140. The classifier 40 flows to a convergence sub layer 1150, which comprises a payload header suppression layer 1 160 and a common part sub layer 1 170. This then flows to a security sub layer 1180.

The scheduler receives the packets from the CS layer where each and every queue represent a CID and for scheduling it takes inputs such as Queue parameters and length, SS information and traffic shaping policy. The Ethernet connection or a PCI based Ethernet connection layer parameters can be accessed independent of the platform RF DATA-CPS implementation. This is shown in Figure 55. In Figure 55, the scheduler 1200 has a downlink 210 from a Network Interface Controller (NIC) and distribution to line design; DL queues 1220; Automatic Repeat-reQuest (ARQ) DL queues 1230; DL & UL scheduler 1240; and fragmentation and packing 1250. As shown, the downlink 120, the DL queues 1220 and the ARQ DL queues 1230 feed into the DL & UL scheduler 1240, which in turn, feeds into the fragmentation and packing 1250. The fragmentation and packing feeds back to the DL queues 1220.

The size of the burst inside the DEVICE frame and the location of the burst such as slot offset, sub channel offset, number of slots and number of sub channels are determined by the scheduler. Knowing the modulation type, the number of bytes that can be transmitted in a burst can be known. Every CID has associated service flow ID information. Fragmentation is done if the number of bytes required to fit a frame is less than the actual bytes. Also the location of the data is not to be used by the platform RF DATA any more but the same has to be transparently forwarded to the AIR Interfacesical layer. The scheduler can decide the packing rate and fragmentation rate depending upon the AIR Interfacesical symbols available and also based on the Received Signal Strength Indication (RSSI) and Carrier Interference to Noise Ratio (CI R) values.

Downlink Receiver (RX) from Network Interface Design 1200' is shown in Figure 56. This forms part of the scheduler described with reference to Figure 55 above. Elements that have previously been described have identical reference numerals. Classification of IP destination port/address to Device CID is done from the packets coming from the NIC and hence offloading the line Design processor. Each and every flow is associated with a separate CID queue and for each and every CID queue the service flow association decides the rate at which the packets are modulated and coded. The data when arrives from the Network interface Design, shall be subjected to classification based on quintupies and additional fields can also be provided for classification. After classification separate queues are provided for each CID.

The packets are received in the buffer, where the buffer represents circular queues for each CID. The first two parameters - Service Data Unit (SDU) buffer start reference and SDL⁾ buffer length are combined by storing a reference to the end of the SDU buffer in the queue. For the scheduler input parameters such as CID QoS parameters, service flow parameters, time stamp are used. A status array per queue has both Number of packets in the queue and number of bytes in the queue.

The scheduler passes the location and size of the burst to the AIR INTERFACE which is used to build the actual burst to be transmitted. If the scheduler decides the PDU parameters, such as, size and source CID, then the target CID n the fragmentation/packing input information. Alternatively if the burst information is passed to the fragmentation/packing block, then a simple priority based scheme can be used to select the CID within a group of CIDs to remove from. The parameters like ARQ block size and ARQ enabled yes/no are assumed to be given in per CID/SS context. This is shown in Figure 57.

In Figure 57, a scheduler 1300 includes a downlink 1310;

DL queues 1320; DL & UL scheduler 1330; fragmentation and packing 1340; and PDU build and encoding 1350. Downlink 1310, DL queues 1320, DL & UL scheduler 1330, and fragmentation and packing 1340 operate in a similar way to downlink 1210, DL queues 1220; DL & UL scheduler 1240, and fragmentation and packing 1250 described above with reference to Figures 55 and 56.

The fragmentation/packing block decides the size of the PDU within a burst. The PDU buffer where the PDU to be assembled from the SDU queue is created, in order to keep the performance high and better throughput of the system, only references can be passed to data instead of building the complete PDU in the memory. The PDUs are created without having another copy of the SDU instead a reference based data structure which points the original copy. The rest of the PDU building process is independent of the issue of handling the ARQ traffic. A packing sub header is generated if the SDU is smaller than the PDU aimed size. A fragmentation sub header is inserted if the SDU is bigger than the PDU. In order for the code to check for the data to be inserted in PDU, a reference and length field of the fragment is added to the PDU build array. The process s carried on till all PDU spaces are filled. For all added fragment, ARQ storage array is updated. The Fragmentation/packing block output is given to the PDU builder. The PDU builder builds the actual PDU from the set of references including the encryption.

The Downlink ARQ process 1300' is shown in Figure 58. Elements described above with reference to Figure 57 have identical reference numerals. In addition to downlink 1310, DL queues 1320, and DL & UL scheduler 1330, ARQ DL queues 1360 are shown. The ARQ process has to detect timeouts on transmitted fragments and also handle ARQ feedback information from incoming acknowledgements. A Fragment descriptor is generated for each fragment that is generated and added to PDU array build. A fragment function based on the assumption that ARQ timeout value is set the same for all CIDs serviced in the system. Modification is possible to accommodate multiple timeouts of ARQ. The fragment function is:

Fragment (CID, ^* Fragment, Size of (&Fragment)) The fragment descriptor is added to the tail of one ARQ double linked list shared among all CIDs after initial Transmission and moved back to the tail of the linked list after the retransmission. At regular time interval the linked list head in checked by the ARQ block. If the last time transmitted parameter of the head of the linked list is timed out, the fragment is again retransmitted and added to the tail of the linked list. Once all the blocks in a fragment are acknowledged, it can be removed fs;om the linked list. The blocks 1400 are shown in Figure 59.

in Figure 59, blocks relating to SDU reference 1410, length 1420, ARQ blocks 1430, fragment state 1440, BSN/FSN 1450, first transmit 1460 and last retransmit 1470 are shown. These blocks pass, as indicated by arrow 1475 to a 'fail' block 1480 which interfaces with a head block 1490 via block 1485.

For every block sequence number, a reference to the fragment descriptor is stored in array in which each entry correspond a BSN for this particular CID. The BSN can be referenced on receipt of positive acknowledgement. In order to make sure the number of unacknowledged blocks in descriptor to be accurate, the ARW block variable should be lowered. When the number of unacknowledged ARQ becomes zero, the complete fragment is acknowledged, which means that it can be deleted from the double linked list.

Similar method is used for referencing the buffer in which the SDU is stored on entering the platform RF DATA CPS layer. The buffer allocation code uses buffer reference counter and it is set to 1 when a SDU arrives. It is also incremented by 1 for every generated fragment. As the SDU gets fully fragmented, the reference counter is decremented by 1. The ARQ mechanism knows the acknowledgement of the complete fragment. The fragment descriptor is removed from the double linked list and also lowers the reference count of the SDU buffer by 1. The reference counter reaches 0, when all the fragments generated by the SDU are acknowledged, and hence buffer can be reallocated.

The PDU build and encoding 1500 is shown in Figure 60. From fragmentation and packing 1510, the PDU build and encoding 1520 passes to PDU verification and decoding 1530. The fragmentation and packing 1510 and PDU build and encoding 1520 are the same as the fragmentation and packing 1340 and PDU verification and decoding 1350 in Figure 57. The main task of this block is to AIR Interfacesically build the PDU from the array of source reference and length fields obtained as input from the fragmentation/packing block. This block also adds HCS, CRC and encryption to the PDU before outputting a fully format PDU. Output from the PDU build block is a reference and length indicator to a buffer containing the fully formatted and encrypted PDU.

PDU verification and decoding 1600 is shown in Figure 61 . From a frame after disassembly and FEC decoding 1610, a burst decoder 1620 is used before PDU verification and decoding 1630 and defragmentation and unpacking 1640. When a burst arrives, it is subject to a module called burst decode. This process gets the PDU from the burst. The PDUs are subjected to Defragmentation and unpacking based on the information present in the platform RF DATA sub header. The SDU are obtained and sent to upper layers for uplink classification.

Defragmentation and Unpacking 1700 is shown in Figure

62. From the PDU verification and decoding 1710, defragmentation and unpacking 1720 is performed to provide the ARQ UL queues 1730 and uplink classification 1740 before aggregation of UL traffic for transmission to NIC 1750. The defragmentation/unpacking block disassembles PDU in to sub headers and fragments to build SDUs. All the sub headers are extracted to the management entity. For every fragment, the sequence number and length is determined, depending upon the sub header type. The sub header type can be ARQ enabled or disabled fragmentation and packing, no sub header. From the SN, the payload received is determined as in-sequence or out-of-sequence.

For In Sequence, the validity of the buffer allocation scheme for the fragment received is checked. The header with first fragment without a buffer is allocated a fixed buffer of 8kB. On receipt of the continuing fragment, the new fragment is added to the data stored in the allotted buffer. A combined reference towards the end of the data allocated in a fixed 8kB buffer is used. On receipt of the last fragment, the filled SDU buffer is sent to NIC or to the management layer.

For Out Of Sequence, depending upon the fragment type field, the incoming fragments of non ARQ enabled connections are processed. Out Of Sequence fragments for ARQ enabled connections are first checked whether the SN is within the ARQ window. If it is out of scope it is disDesigned, else the fragment is placed in the ARQ array.

The Uplink ARQ Process 1800 is shown in Figure 63. Defragmentation and unpacking 1810 is performed to provide the ARQ UL queues 1820 and uplink classification 1830. The defragmentation and unpacking 1810, ARQ UL queues 1820 and uplink classification 1830 are the same as those described with reference to Figure 62 above.

The uplink ARQ process uses a Fragment description array in which each entry represents a single BSN. The fragment descriptor has:

• A reference to the start of the block inside the received PDU

• Starting or ending indication in the fragment

• The length of the block, in case the block ends a fragment

• The timer value when the block was received.

All the ARQ enabled connection based out of bound sequence fragments are received and stored in ARQ array. An entry is made in the array for every BSN with a reference to start of the block and a timestamp. Indicator byte indicates the start or end of the new SDU. Data reference value is made to null for blocks that are not received, if the ARQ block enters the uplink process that had been obtained correctly before, the old block is removed and the new block is entered in to the array.

On reception of In Sequence fragment, the UL defragmentation/unpacking checks the ARQ array if the reception of the fragment has filled up a hoie in the ARQ array as the ARQ array can be used to build the SDU. Block by block checking is done if the entry in the ARQ array is valid. If it is valid the entry in the ARQ array is used to Direct Memory Access (DMA) the data to the SDU buffer. If the indicator shows SDU is complete, then the buffer is forwarded as normal SDU. A new buffer is allocated if the indicator shows that the ARQ block forms the start of a new SDU. Post DMA transfer, the entry in the array is annulled and the PDU reference count lowered by 1.

Uplink Classification, traffic aggregation/forwarding 1900 is shown in Figure 64. Uplink classification 1910 before aggregation of UL traffic for transmission to NIC 1 19200 are the same as uplink classification 1740 before aggregation of UL traffic for transmission to NIC 1750 described above with reference to Figure 62. Upon the reception of SDU, the SDU is forwarded to NIC or management plane and this is based on simple classification step on the CID. The Ethernet interface lies between the NIC and the line Design for the downlink, carrying the payload.

The Complete Process flow is summarised below. From the air interface, the burst is decoded before being passed to PDU verification and decoding. The burst is then defragmented and unpacked before being passed to uplink classification. The defragmented and unpacked burst is also passed to the ARQ UL. From the uplink classification, the burst is passed to aggregation of UL traffic and transmitted to NIC. From the downlink from the NIC, it is distributed to the Line Design. From there it is passed to the DL and UL schedulers, and the DL queue. From the schedulers, it passes to the fragmentation and packing, to the PDU build and encoding, PDU verification and decoding, burst build and then to the air interface. The ARQ DL and DL queue interface with the schedulers and the fragmentation and packing interfaces with the DL queue in both directions.

Algorithms used in the UDEVICE implementation include: 1. QoS implementation used the Weighted Fairness algorithm (WF) queuing mechanism for all the traffic type BE, EDF coding is not implemented properly. In the current implementation Best Effort (BE) queuing support enabled. EDF algorithm is not properly implemented. During UGS, symbol, RSSI statistics and CINR statistics is not taken into account.

2. Scheduler and classifier use sequential searching which is ineffective for large data rates.

3. While storing buffers, linked list are used with very poor location sort algorithm. All queues are staticaliy allocated, without understanding the bandwidth needs and scalability.

4. Mail box messaging scheme has been implemented in the management message delivery implementation

The platform algorithm requires:

· Scheduler algorithm requires multi-tasking and real time application support in the system

• Dynamic traffic rule enforcement algorithm has to be implemented

• Efficient memory management algorithm

• Hash Tables instead of redundant searches etc

• EDF scheduler

Symbol based bandwidth allocation for performance optimization.

Storing of buffers should be done without memory fragmentation problems.

The User provisioning API can be implemented as follows:

Add burst profile(System profile , coordinates and MCR)

Adds the FDD or TDD burst profile in the system to be given to the AIR

Interfacesical layer

Add Zone profile(Zones, segments and size)

Adds the zone information to the DEVICE layer to be given the AIR Interfacesical layer Add DEViCEAddressfadds IP address of the authentication subsystem)

ADDSSHDEVICE( Add the hdevice tuple for each SS in Group)

Add service flowid (Text file which has various service flow id parameters)

Add Connection id (add management connection id)

Add SS preamble info( adds the Peramble information)

AddUser(adds user, serviceflow association, System profile)

AddUser accounting flow(Provide a access to memory which shall provide user data usage to be provded to the NMS system)

Add AIR INTERFACE(add AIR Interfacesical layer capability)

Createconnection(userid, ip address, Service flow ID) returns connection id

Create reg record (deviceid, hdevice tuple)

Changeconnection priority(Connection id)

Changeuser Scedule(Connectionid, new scheduling scheme)

The System API can be defined as follows:

API Name and Parameters Details

Conv_Sub_init Callback api used to enqueue SDUs to the CPS in DL

CONV_SUB_free Free CS structures.

CONV SUB dl classifier new Create a table of rule.

CONV SUB dl classifier del Delete a table of rule.

CO N V_S U B_d l_ru le_n e w Create a new rule. Rule identifier, rule priority, flow handle id, PHS rule id, filter

CONV_ SUB_dl_classifier_rule_add Add a rule to a table of rules.

The rule position within the table of rule is fixed by its priority. If a rule of same priority already exists in the linked list, the new rule is added just after it in the list.

CONV SUB dl rule delete Delete an existing rule.

CONV SUB dl classifier rule delete Delete a rule from a table of rules.

CONV_SUB_di_build_packet Updates value and length to SDU before passing it to the CPS, and calls header compression algorithm.

CONV_SUB dl_process_packet Main CS downlink api.

Read through a table of rules and apply them to the received packet including potential calls to header compression algorithm. Iso returns the state of the flow handle connection and the new length and value to the built SDU.

C 0 N V_S U B_u l_p races s_packet Classifies the SDU pointed to by incoming data.

CO N V_S U B_D L_l nterf ace Api interfacing between tsec queues and the main CS downlink api SXBM_ CON V_S U B_d l_process__pa cket Api called to start CS downlink processing when one or more packets have been received

C0NV_SUB_UL_1NIT Api interfacing between tsec queues and the main CS donwlink

CO N V_S U B_„RX_packet Api called to check whether packets have been received from the network interface via TSEC.

CONV_SUB_enqueue Api called to enqueue the packet received from the TSEC in the buffer pool.

CONV_SUB_Test Api called to setup the flow handles required for CS test

RX_SDU This api handles the to describe classification SDU packets such as IPV4 IPV6 ETHERNET and the PHS rules.

TX_SDU This api handles the TX of SDUs for classification

Service discovery plays a primary roie because it allows the user to access the list of available services, including the use of distributed directory services.

The streaming of multimedia flows over wireless channels requires ultra-fast processing and strict Quality of Service (QoS) requirements. The dynamic processing power of the platform combined with Wireless Virtual Cache and Radio Frequency (RF) Echo Technology that require very little additional infrastructure makes it the most generic middleware platform. In addition, it uses wireless local area network

(WLAN) computer communication in the 2.4GHz and 5GHz frequency bands, allowing the delivery of seamless video streaming and/or television (TV) broadcasts on 3G mobile networks as well as full multichannel broadcasting with the possibility of Digital Video Recorder (DVR) capability.

For the first time, mobile devices can run many applications at the same time and users can listen to audio, share files, and chat with others all at the same time. In addition, multi-tasking can be implemented where more than one user can work on the same data at the same time. Apart from providing the best streaming of audio and video, data from devices such as cameras, GPS, audio, video, and sensors can be handled all at once and also these resources can be shared with many other applications at the same time.

The functionality of the present invention also provides translation from one form of codec to another between the Internet Protocol (IP) and other wired and/or wireless networks. This service is used when two devices have different sets of codecs. The application server can ask the codecs translation application server to bring the two codecs.

Applications developed using the platform offer Chaumian mix security with the grid security model implemented as a decentralised distributed Chaumian mix system that enable client applications to seamlessly direct traffic through an anonymous network at the transport layer.

Examples of potential application fields for the middleware of the present invention include:

Mobile TV broadcasts for sports coverage

Mobile video conferencing

Games

Retail - multi-channel marketing

Mobile application stores

Mobile advertising - brand marketing

Mobile banking and mobile money transfers

Mobile social networks

Mobile coupons

Location-based services

Although the present invention has been described with reference to specific embodiments, it will be appreciated that these are non-limiting and that other embodiments may fail within the scope of the claims.

Claims

1. A method of using applications on a smart device, the method comprising:

a) downloading an operating system onto the smart device;

b) transforming digital information relating to an application into radio frequency data using the operating system; and

c) creating a link between the radio frequency data and the smart device as long as the smart device is active.

2. A method according to claim 1 , wherein the operating system controls the radio frequency data on a constant basis to adjust signal power and strength.

3. A method according to claim 1 or 2, wherein the operating system only refreshes data that has changed.

4. A smart device having an operating system that transforms digital information relating to an application into radio frequency data and creates a link between the radio frequency data and the smart device as long as the smart device is active.

5. An applications platform from which an operating system can be downloaded onto a smart device for transforming digital information into radio frequency data and linking the transformed radio frequency data with the smart device.

6. An applications platform according to claim 5, further comprising wireless virtual cache and radio frequency echo technology.