WO2012110527A1 - Intergiciel distribué pour dispositifs mobiles - Google Patents

Intergiciel distribué pour dispositifs mobiles Download PDF

Info

Publication number
WO2012110527A1
WO2012110527A1 PCT/EP2012/052533 EP2012052533W WO2012110527A1 WO 2012110527 A1 WO2012110527 A1 WO 2012110527A1 EP 2012052533 W EP2012052533 W EP 2012052533W WO 2012110527 A1 WO2012110527 A1 WO 2012110527A1
Authority
WO
WIPO (PCT)
Prior art keywords
server
mobile
user
application
network
Prior art date
Application number
PCT/EP2012/052533
Other languages
English (en)
Inventor
Jan CAUBERGHS
Eric BARIDEAU
Michel DE COSTER
Subamanian SAHASRANAMAM
Justin Morris
Srivathsan VASUDEVAN
Sathish SAHASRANAMAM
Original Assignee
Airborne Nv
Priority date (The priority date is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the date listed.)
Filing date
Publication date
Application filed by Airborne Nv filed Critical Airborne Nv
Publication of WO2012110527A1 publication Critical patent/WO2012110527A1/fr

Links

Classifications

    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L65/00—Network arrangements, protocols or services for supporting real-time applications in data packet communication
    • H04L65/10—Architectures or entities
    • H04L65/1059—End-user terminal functionalities specially adapted for real-time communication
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L65/00—Network arrangements, protocols or services for supporting real-time applications in data packet communication
    • H04L65/60—Network streaming of media packets
    • H04L65/61—Network streaming of media packets for supporting one-way streaming services, e.g. Internet radio
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L67/00—Network arrangements or protocols for supporting network services or applications
    • H04L67/01—Protocols
    • H04L67/04—Protocols specially adapted for terminals or networks with limited capabilities; specially adapted for terminal portability
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L67/00—Network arrangements or protocols for supporting network services or applications
    • H04L67/01—Protocols
    • H04L67/10—Protocols in which an application is distributed across nodes in the network

Definitions

  • the present invention relates to improvements in or relating to mobile telecommunications, and is more particularly concerned with mobile internet communications.
  • Mobile telephones are now well-known and mobile data, video and television services are becoming an essential part of consumers' lives and business processes.
  • 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.
  • a method of using applications on a smart device 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.
  • 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.
  • Figure 1 illustrates an implementation of the middleware platform in accordance with the present invention
  • FIG. 1 illustrates queued architecture
  • FIG. 3 illustrates the named queues
  • Figure 4 illustrates a drop and insert mechanism
  • Figure 5 illustrates a shunting mechanism
  • Figure 7 illustrates a protocol stack representation
  • FIG. 8 illustrates base station manager interaction
  • FIG. 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
  • FIG. 17 illustrates call flow for mail configuration
  • Figure 18 illustrates call flow for viewing mails
  • FIG. 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
  • Figure 34 illustrates P-CSCF discovery using PDP context activation signalling
  • FIG. 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
  • FIG. 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
  • Figure 64 illustrates uplink classification, traffic aggregation and forwarding. Description of the invention
  • 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.
  • 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.
  • 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.
  • “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.
  • 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.
  • 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.
  • 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.
  • 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.
  • ATicks 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.
  • FIG. 1 An implementation of the present invention is shown 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.
  • S-CSCF Serving Call Session Control Function
  • l-CSCF Interrogating Call Session Control Function
  • P-CSCF Proxy Call Session Control Function
  • UE User Equipment
  • 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:
  • a eel! identification (ID) obtaining application to extract the ceil ID o A eel! identification (ID) obtaining application to extract the ceil ID.
  • ID identification
  • 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:
  • 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.
  • 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.
  • 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.
  • TCP Transmission Control Protocol
  • UDP User Datagram Protocol
  • the processing is done based on the priority of the messages.
  • 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.
  • 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.
  • the Queue Manager performing weight analysis will also decide whether a message should be marked for dropping.
  • 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'.
  • FSM Finite State Machine
  • 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.
  • SMS Short Message Service
  • MMS Multimedia Message Service
  • 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.
  • 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'.
  • 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.
  • 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.
  • 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.
  • each FSM 310, 320, 330 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.
  • 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.
  • JME Java microcode execution
  • 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.
  • JME-JRAP examples can be IP compression.
  • 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.
  • 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.
  • FIG. 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.
  • GGSN Gateway GPRS Support Node
  • PEP Policy Enforcement Point
  • translation/mapping function 465 a translation/mapping function 465
  • UMTS Universal Mobile Telecommunications System
  • elements within the UE 410, P-CSCF 440 and GGSN 450 communicate with one another as indicated by the double- ended arrows.
  • the UMTS BS managers 430, 470 communicate with one another as indicated by arrow 480
  • the PEP 460 communicates with the PCF 445 as indicated by arrow 485.
  • 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.
  • QoS Quality of Service
  • 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.
  • 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.
  • Real-time Transport Protocol 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:
  • the IP is implemented in accordance with the PSEUDO
  • 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.
  • 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:
  • This module also manages:
  • Presence information is constructed based on filtering request and authorisation rules
  • Type of the presence attribute user, device or network specific
  • APIs provided by SIMPLE These APIs are provided in JAVA IP SIMPLE API.
  • 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.
  • 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 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.
  • FIG. 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.
  • IMS IP Multimedia Core Network Subsystem
  • 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.
  • 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.
  • Presence and availability services provide presence and availability information in the following ways:
  • the instant messaging services 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.
  • 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.
  • TOA Time of Arrival
  • E-OTD Enhanced-Observed Time Difference
  • GPS Global Positioning System
  • 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
  • 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.
  • the users 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.
  • 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.
  • ISDN Integrated Services Digital Network
  • the integration of mobile networks with Wireless LAN 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.
  • 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.
  • 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.
  • the platform enables constant monitoring of the movement of goods and hence optimisation of resources.
  • 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.
  • 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.
  • 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.
  • 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.
  • POP Lightweight corporate Post Office Protocol
  • POP3 Lightweight corporate Post Office Protocol
  • STREAMING CLIENT and presence service is used for the POP3 where the ADEB MIXE server POP3 as a JRAP application.
  • 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.
  • 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.
  • the server 610 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.
  • 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.
  • 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.
  • 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.
  • 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.
  • POP3 server 610 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.
  • 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.
  • the server 610 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.
  • the server 610 starts the listening and waiting function for the incoming message.
  • 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.
  • 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.
  • 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.
  • 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.
  • 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.
  • the POP3 server 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.
  • FIG. 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.
  • 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.
  • SMS centre SMS centre
  • 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.
  • MSC Mobile Switching Centre
  • the WLAN server 726 is connected to a plurality of WLANs
  • 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.
  • IM Instant Messenger
  • media delivery server 786 a media delivery server 786
  • iocation computer 788 a call supplementary services server 790
  • call supplementary services server 790 a Virtual Private Network ⁇ VPN)/SIP interoperability server 792.
  • VPN Virtual Private Network ⁇ VPN
  • FIG. 29 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.
  • 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.
  • OSA Open System Architecture
  • FIG. 29 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.
  • FIG. 31 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.
  • 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).
  • 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.
  • FIG. 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.
  • DHCP Dynamic Host Configuration Protocol
  • DNS Domain Name Server
  • 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.
  • 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.
  • 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.
  • 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.
  • SS7 Signalling Session #7
  • ISUP ISUP
  • 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.
  • FIG 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.
  • the request is forwarded through an i-CSCF (l-CSCF#1) to a well-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:
  • the present invention requires the use of a device scheduler that has includes a packet selection module and a burst formation module.
  • 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.
  • CID Caller ID
  • 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.
  • 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.
  • 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.
  • 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.
  • 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.
  • PDU Protocol Data Unit
  • the current element is mail boxed as inactive and proceeds to next element.
  • the mail box is reset.
  • a reference remembers the last allocated element for non real time service and BE.
  • the Vectors will be traversed again for the real time service connection.
  • 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.
  • the UL scheduler starts as the UL-MAP generated by the UL scheduler must be mapped to the DL sub frame.
  • 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.
  • 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.
  • 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.
  • the real time service connections parameters are:
  • 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.
  • the UGS connection parameters are:
  • 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.
  • 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.
  • bandwidth (BW) grant store After the bandwidth is granted by the bandwidth allocation algorithm, information about the grant is sent to bandwidth (BW) grant store.
  • 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.
  • 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.
  • 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.
  • a counter is kept representing the sub frame area.
  • the amount of data (bytes) is counted on every granting of BW request.
  • this is converted into an area of DEVICEA frame.
  • the frame mapping begins once the counter reaches full.
  • the handling of bursts comprises:
  • 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.
  • 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
  • the DL Scheduler has the following modules:
  • 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.
  • overheads such as headers, sub headers, CRC, encryption and burst overhead
  • the queues group the PDU to bursts and computes the cumulative burst sizes and the current frame area used.
  • 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.
  • 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.
  • 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.
  • NIC Network Interface Controller
  • 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.
  • RSSI Received Signal Strength Indication
  • CI R Carrier Interference to Noise Ratio
  • 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.
  • SDU Service Data Unit
  • 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.
  • a scheduler 1300 includes a downlink 1310;
  • 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.
  • 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.
  • 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.
  • ARQ DL queues 1360 are shown in addition to downlink 1310, DL queues 1320, and DL & UL scheduler 1330.
  • 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:
  • 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.
  • 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.
  • 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.
  • 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.
  • 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.
  • 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 .
  • a burst decoder 1620 is used before PDU verification and decoding 1630 and defragmentation and unpacking 1640.
  • burst decode 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 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.
  • 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.
  • 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.
  • the filled SDU buffer is sent to NIC or to the management layer.
  • 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:
  • 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.
  • 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.
  • DMA Direct Memory Access
  • 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.
  • 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.
  • WF Weighted Fairness algorithm
  • Scheduler and classifier use sequential searching which is ineffective for large data rates.
  • the platform algorithm requires:
  • the User provisioning API can be implemented as follows:
  • AddUser accounting flow Provide a access to memory which shall provide user data usage to be provded to the NMS system
  • the System API can be defined as follows:
  • Conv_Sub_init Callback api used to enqueue SDUs to the CPS in DL
  • CONV SUB dl classifier new Create a table of rule.
  • CONV SUB dl classifier del Delete a table of rule.
  • 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 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_enqueue Api called to enqueue the packet received from the TSEC in the buffer pool.
  • 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.
  • QoS Quality of Service
  • RF Radio Frequency
  • WLAN wireless local area network
  • 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.
  • DVR Digital Video Recorder
  • 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.
  • multi-tasking can be implemented where more than one user can work on the same data at the same time.
  • 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.
  • IP Internet Protocol
  • 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.

Abstract

L'invention concerne une plate-forme intergicielle à partir de laquelle un système d'exploitation de dispositif intelligent peut être téléchargé. Le système d'exploitation transforme des informations numériques en données radiofréquence et les relie au dispositif intelligent tant que ce dernier est actif. La plate-forme intergicielle utilise une technologie d'antémémoire virtuelle sans fil et d'écho radiofréquence. Dans un mode de réalisation, une architecture (800) de plate-forme intergicielle comprend un réseau d'accès unique (810) connecté à un réseau central IP STREAMING (820). Un utilisateur accède (830) au réseau central IP STREAMING (820) en fonction de l'invention via le réseau d'accès (810). Des éléments variés (840, 845, 850, 855, 860, 855, 860, 865, 870, 875, 880, 885) sont utilisés avec le réseau central IP STREAMING (820) pour obtenir les connexions nécessaires.
PCT/EP2012/052533 2011-02-14 2012-02-14 Intergiciel distribué pour dispositifs mobiles WO2012110527A1 (fr)

Applications Claiming Priority (2)

Application Number Priority Date Filing Date Title
EP11154333.6 2011-02-14
EP11154333 2011-02-14

Publications (1)

Publication Number Publication Date
WO2012110527A1 true WO2012110527A1 (fr) 2012-08-23

Family

ID=45841446

Family Applications (1)

Application Number Title Priority Date Filing Date
PCT/EP2012/052533 WO2012110527A1 (fr) 2011-02-14 2012-02-14 Intergiciel distribué pour dispositifs mobiles

Country Status (1)

Country Link
WO (1) WO2012110527A1 (fr)

Cited By (3)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US8965348B1 (en) 2014-06-04 2015-02-24 Grandios Technologies, Llc Sharing mobile applications between callers
US9395754B2 (en) 2014-06-04 2016-07-19 Grandios Technologies, Llc Optimizing memory for a wearable device
CN117201405A (zh) * 2023-11-07 2023-12-08 成都卓拙科技有限公司 一种网络包分流方法及装置、存储介质及电子设备

Citations (2)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US20030181193A1 (en) * 2002-02-15 2003-09-25 Lars Wilhelmsson Middleware services layer for platform system for mobile terminals
US20070130255A1 (en) * 2003-04-17 2007-06-07 Lionel Wolovitz Data access, replication or communication system comprising a distributed software application

Patent Citations (2)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US20030181193A1 (en) * 2002-02-15 2003-09-25 Lars Wilhelmsson Middleware services layer for platform system for mobile terminals
US20070130255A1 (en) * 2003-04-17 2007-06-07 Lionel Wolovitz Data access, replication or communication system comprising a distributed software application

Non-Patent Citations (1)

* Cited by examiner, † Cited by third party
Title
APPLE: "iPhone User Guide For iPhone OS 3.1 Software", APPLE USER GUIDES, 1 September 2009 (2009-09-01), Apple Inc, California, US, pages 1 - 217, XP055019969, Retrieved from the Internet <URL:http://manuals.info.apple.com/en_US/iPhone_iOS3.1_User_Guide.pdf> [retrieved on 20120221] *

Cited By (4)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US8965348B1 (en) 2014-06-04 2015-02-24 Grandios Technologies, Llc Sharing mobile applications between callers
US9395754B2 (en) 2014-06-04 2016-07-19 Grandios Technologies, Llc Optimizing memory for a wearable device
CN117201405A (zh) * 2023-11-07 2023-12-08 成都卓拙科技有限公司 一种网络包分流方法及装置、存储介质及电子设备
CN117201405B (zh) * 2023-11-07 2023-12-29 成都卓拙科技有限公司 一种网络包分流方法及装置、存储介质及电子设备

Similar Documents

Publication Publication Date Title
EP2619964B1 (fr) Systèmes et procédés destinés à un ims partagé
US9288276B2 (en) Application services infrastructure for next generation networks including a notification capability and related methods and computer program products
CN102210132B (zh) 使用现有授权架构和协议来支持sip会话策略的方法和系统
US7984492B2 (en) Methods and apparatus for policy enforcement in a wireless communication system
US7062253B2 (en) Method and system for real-time tiered rating of communication services
US20070223462A1 (en) Enhanced service delivery platform that provides a common framework for use by IMS and Web applications in delivering services
US9883000B2 (en) Server-push service in heterogeneous network environment
US20060072573A1 (en) System and method for service tagging for enhanced packet processing in a network environment
US20070100981A1 (en) Application services infrastructure for next generation networks including one or more IP multimedia subsystem elements and methods of providing the same
Munir et al. SIP-based IMS signaling analysis for wimax-3g interworking architectures
EP1619853A1 (fr) RTSP proxy étendue pour détecter des évènement dans des sessions de transmission en continu et les rapporter aux applications de transmission en continu
US8762559B2 (en) System and method for non-IMS application service access over IP multimedia subsystem
EP2627056B1 (fr) Procédé, passerelle, proxy et système pour la mise en oeuvre de services internet mobiles
US20080016248A1 (en) Method and apparatus for time synchronization of parameters
TW200818814A (en) Methods and apparatus for using electronic envelopes to configure parameters
US20220191664A1 (en) Optimization of services applied to data packet sessions
US11171719B2 (en) Facilitating dynamic satellite and mobility convergence for mobility backhaul in advanced networks
Ciubotaru et al. Advanced Network Programming–Principles and Techniques: Network Application Programming with Java
US20080298307A1 (en) Apparatus, Method and Computer Program for Seamless Session Transfer
CN101133673A (zh) 移动上行链路传输的调度技术
WO2012110527A1 (fr) Intergiciel distribué pour dispositifs mobiles
Hu et al. Broadband satellite multimedia
WO2022268137A1 (fr) Procédé de connexion tcp, système, dispositif de réseau et support de stockage
US11153801B2 (en) Facilitating dynamic multiple public land mobile network resource management in advanced networks
Simanta et al. Web services for handheld tactical systems

Legal Events

Date Code Title Description
121 Ep: the epo has been informed by wipo that ep was designated in this application

Ref document number: 12709024

Country of ref document: EP

Kind code of ref document: A1

NENP Non-entry into the national phase

Ref country code: DE

32PN Ep: public notification in the ep bulletin as address of the adressee cannot be established

Free format text: NOTING OF LOSS OF RIGHTS PURSUANT TO RULE 112(1) EPC (EPO FORM 1205A DATED 15.11.2013)

122 Ep: pct application non-entry in european phase

Ref document number: 12709024

Country of ref document: EP

Kind code of ref document: A1