US9271149B2 - Managing hidden security features in user equipment - Google Patents

Images

Classifications

• • H—ELECTRICITY
  • H04—ELECTRIC COMMUNICATION TECHNIQUE
  • H04W—WIRELESS COMMUNICATION NETWORKS
  • H04W12/00—Security arrangements; Authentication; Protecting privacy or anonymity
  • H04W12/06—Authentication
• • 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/1016—IP multimedia subsystem [IMS]
• • 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/1066—Session management
  • H04L65/1069—Session establishment or de-establishment
• • 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/40—Support for services or applications
  • H04L65/4061—Push-to services, e.g. push-to-talk or push-to-video
• • 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/80—Responding to QoS
• • H—ELECTRICITY
  • H04—ELECTRIC COMMUNICATION TECHNIQUE
  • H04W—WIRELESS COMMUNICATION NETWORKS
  • H04W12/00—Security arrangements; Authentication; Protecting privacy or anonymity
  • H04W12/06—Authentication
  • H04W12/069—Authentication using certificates or pre-shared keys
• • H—ELECTRICITY
  • H04—ELECTRIC COMMUNICATION TECHNIQUE
  • H04W—WIRELESS COMMUNICATION NETWORKS
  • H04W28/00—Network traffic management; Network resource management
  • H04W28/02—Traffic management, e.g. flow control or congestion control
  • H04W28/0215—Traffic management, e.g. flow control or congestion control based on user or device properties, e.g. MTC-capable devices
• • H—ELECTRICITY
  • H04—ELECTRIC COMMUNICATION TECHNIQUE
  • H04W—WIRELESS COMMUNICATION NETWORKS
  • H04W28/00—Network traffic management; Network resource management
  • H04W28/02—Traffic management, e.g. flow control or congestion control
  • H04W28/0268—Traffic management, e.g. flow control or congestion control using specific QoS parameters for wireless networks, e.g. QoS class identifier [QCI] or guaranteed bit rate [GBR]
• • H—ELECTRICITY
  • H04—ELECTRIC COMMUNICATION TECHNIQUE
  • H04W—WIRELESS COMMUNICATION NETWORKS
  • H04W4/00—Services specially adapted for wireless communication networks; Facilities therefor
  • H04W4/06—Selective distribution of broadcast services, e.g. multimedia broadcast multicast service [MBMS]; Services to user groups; One-way selective calling services
  • H04W4/10—Push-to-Talk [PTT] or Push-On-Call services
• • H—ELECTRICITY
  • H04—ELECTRIC COMMUNICATION TECHNIQUE
  • H04W—WIRELESS COMMUNICATION NETWORKS
  • H04W52/00—Power management, e.g. Transmission Power Control [TPC] or power classes
  • H04W52/02—Power saving arrangements
  • H04W52/0209—Power saving arrangements in terminal devices
  • H04W52/0261—Power saving arrangements in terminal devices managing power supply demand, e.g. depending on battery level
  • H04W52/0264—Power saving arrangements in terminal devices managing power supply demand, e.g. depending on battery level by selectively disabling software applications
• • H—ELECTRICITY
  • H04—ELECTRIC COMMUNICATION TECHNIQUE
  • H04M—TELEPHONIC COMMUNICATION
  • H04M7/00—Arrangements for interconnection between switching centres
  • H04M7/006—Networks other than PSTN/ISDN providing telephone service, e.g. Voice over Internet Protocol (VoIP), including next generation networks with a packet-switched transport layer
  • H04M7/0078—Security; Fraud detection; Fraud prevention
• • H—ELECTRICITY
  • H04—ELECTRIC COMMUNICATION TECHNIQUE
  • H04W—WIRELESS COMMUNICATION NETWORKS
  • H04W88/00—Devices specially adapted for wireless communication networks, e.g. terminals, base stations or access point devices
  • H04W88/02—Terminal devices
  • H04W88/06—Terminal devices adapted for operation in multiple networks or having at least two operational modes, e.g. multi-mode terminals
• • Y—GENERAL TAGGING OF NEW TECHNOLOGICAL DEVELOPMENTS; GENERAL TAGGING OF CROSS-SECTIONAL TECHNOLOGIES SPANNING OVER SEVERAL SECTIONS OF THE IPC; TECHNICAL SUBJECTS COVERED BY FORMER USPC CROSS-REFERENCE ART COLLECTIONS [XRACs] AND DIGESTS
  • Y02—TECHNOLOGIES OR APPLICATIONS FOR MITIGATION OR ADAPTATION AGAINST CLIMATE CHANGE
  • Y02D—CLIMATE CHANGE MITIGATION TECHNOLOGIES IN INFORMATION AND COMMUNICATION TECHNOLOGIES [ICT], I.E. INFORMATION AND COMMUNICATION TECHNOLOGIES AIMING AT THE REDUCTION OF THEIR OWN ENERGY USE
  • Y02D30/00—Reducing energy consumption in communication networks
  • Y02D30/70—Reducing energy consumption in communication networks in wireless communication networks

Definitions

• a push-to-talk (PTT) service provides direct one-to-one and/or one-to-many audio communication.
• PTT may include a mechanism that provides instantaneous communication between parties, and that utilizes a button to switch user equipment (UE) from a voice transmission mode to a voice reception mode.
• UE user equipment
• the operation of UEs in this manner may be similar to how walkie talkies operate.
• a PTT service may switch a UE from a full duplex mode, where both parties may hear each other simultaneously, to a half duplex mode, where a single party may speak at one time. Multiple parties to a conversation may also be included. Availabilities of parties may be checked before a call with the help of a presence function.
• the fourth generation (4G) cellular network includes an evolved packet system (EPS).
• the EPS may include a radio access network (e.g., referred to as a long term evolution (LTE) network), a wireless core network (e.g., referred to as an evolved packet core (EPC) network), an Internet protocol (IP) multimedia subsystem (IMS) network, and a packet data network (PDN).
• LTE long term evolution
• EPC evolved packet core
• IP Internet protocol
• IMS Internet protocol multimedia subsystem
• PDN packet data network
• the LTE network is often called an evolved universal terrestrial radio access network (E-UTRAN).
• E-UTRAN evolved universal terrestrial radio access network
• the EPC network is an all-IP packet-switched core network that supports high-speed wireless and wireline broadband access technologies.
• the EPC network allows UEs to access various services by connecting to the LTE network, an evolved high rate packet data (eHRPD) radio access network (RAN), and/or a wireless local area network (WLAN) RAN.
• the IMS network may include an architectural framework or network (e.g., a telecommunications network) for delivering IP multimedia services.
• the PDN may include a communications network that is based on packet switching.
• FIG. 1 is a diagram of an overview of an example implementation described herein;
• FIG. 2 is a diagram of an example environment in which systems and/or methods described herein may be implemented
• FIG. 3 is a diagram of example components of a device that may correspond to one or more of the devices of the environment depicted in FIG. 2 ;
• FIG. 4 is a flow chart of an example process for granting or denying access to exposed application programming interfaces (APIs);
• APIs application programming interfaces
• FIGS. 5A-5C are diagrams of an example relating to the example process shown in FIG. 4 ;
• FIG. 6 is a flow chart of an example process for establishing and conducting a PTT session with another UE based on exposed APIs.
• FIGS. 7A-7H are diagrams of an example relating to the example process shown in FIG. 6 .
• Current 4G PTT applications use a public Internet connection with no quality of service (QoS) for PTT services. Without QoS, a user's PTT experience may degrade when a network or a UE is busy and PTT traffic is queued up behind other traffic (e.g., email, video, Internet, etc. traffic).
• the user experience may be exemplified in what is called a “push to hear” delay, which measures how quickly a user hears a beep after pushing the PTT button and how quickly the user's voice reaches a called party.
• Current 4G PTT applications have push to hear delays of approximately 1.5 to 2 seconds, which creates a poor user experience.
• FIG. 1 is a diagram of an overview of an example implementation 100 described herein.
• a user may be associated with a UE connected to an EPS that includes a RAN, an EPC network, an IMS network, and a PDN.
• the UE may include a PTT application that enables the user to establish and conduct a PTT call (or session) via the EPS.
• a manufacturer of the UE may expose one or more hidden or unexposed APIs.
• the UE manufacturer may expose an IMS PDN API and a Discontinuous Receive (DRX) cycle API, as shown in FIG. 1 .
• the IMS PDN API may enable the UE to establish data routes to the IMS network and the PDN.
• the DRX cycle API may enable the UE to modify a DRX cycle timer that dictates when the UE checks a network for traffic.
• the UE may include a security application that restricts access to the exposed APIs, as further shown in FIG. 1 .
• the security application may provide secure access to the IMS PDN API and the DRX cycle API by the PTT application, and may prevent unauthorized applications from accessing the IMS PDN API and the DRX cycle API.
• the security application may include authentication credentials (e.g., a signature, a security token, a security key, or the like) that may be utilized to authenticate applications attempting to access the IMS PDN API and/or the DRX cycle API.
• the security application may request that a particular application attempting to access the IMS PDN API and/or the DRX cycle API provide a credential. If the credential provided by the particular application matches the credential of the security application, the security application may authenticate the particular application for accessing the IMS PDN API and/or the DRX cycle API.
• the PTT application When the PTT application is installed in the UE, the PTT application may be provided with a credential that matches the credential of the security application.
• the security application may authenticate the PTT application for accessing the IMS PDN API and/or the DRX cycle API, as shown in FIG. 1 .
• the security application may provide, to an operating system of the UE, a message indicating that the PTT application is authenticated for accessing the IMS PDN API and/or the DRX cycle API.
• the PTT application may request access to the IMS PDN API, and the IMS PDN API may check with the operating system to determine whether the PTT application is authenticated. Since the PTT application is authenticated, the IMS PDN API may grant the PTT application access to the IMS PDN API.
• the PTT may utilize the IMS PDN API to establish a data connection (e.g., set up data routes) with the PDN over the IMS network.
• the IMS network may permit the UE to utilize quality of service (QoS) with respect to PTT sessions.
• the QoS may include prioritizing PTT traffic over other types of traffic, such as, for example, email, video, and Internet traffic.
• the QoS may improve a call setup time for establishing a PTT session, and may improve a latency time associated with the PTT session.
• the PTT application may request access to the DRX cycle API, and the DRX cycle API may check with the operating system to determine whether the PTT application is authenticated. Since the PTT application is authenticated, the DRX cycle API may grant the PTT application access to the DRX cycle API. The PTT application may access the DRX cycle API in order to modify the DRX cycle timer provided in the DRX cycle API. In some implementations, the PTT application may decrease the DRX cycle timer so that the UE checks the EPS for traffic (e.g., PTT traffic) more frequently. This may enable the UE to more quickly receive PTT traffic from the EPS, such as an incoming PTT call, which may result in shorter call setup times (e.g., relative to public Internet-based PTT).
• traffic e.g., PTT traffic
• Such PTT enhancements may permit prioritization of PTT traffic over other types of traffic, such as email, video, Internet, etc. traffic. This may provide improved PTT call setup time and/or latency time over current 4G PTT implementations, which may improve the PTT user experience. For example, the PTT enhancements may provide push to hear delays of approximately less than one second.
• Implementations of the security application are described herein with respect to a PTT application and to particular APIs exposed for the purpose of enhancing the PTT application.
• the security application may be utilized to provide secure access to one or more exposed APIs of the UE, other than the particular exposed APIs described herein (e.g., the IMS PDN API and the DRX cycle API).
• the security application may be utilized to grant or deny the PTT application, and/or one or more other applications of the UE, access to any exposed API of the UE.
• the PTT application is described herein in terms of PTT voice calls, the PTT application may alternatively or additionally be utilized for PTT video calls.
• FIG. 2 is a diagram of an example environment 200 in which systems and/or methods described herein may be implemented.
• environment 200 may include a UE 210 and an EPS 215 that includes a LTE network 220 , an EPC network 230 , an IMS network 240 , and a PDN 250 .
• LTE network 220 may include an eNodeB (eNB) 222 .
• EPC network 230 may include a mobility management entity (MME) 232 , a serving gateway (SGW) 234 , a policy and charging rules function (PCRF) 236 , and a PDN gateway (PGW) 238 .
• MME mobility management entity
• SGW serving gateway
• PCRF policy and charging rules function
• PGW PDN gateway
• IMS network 240 may include a home subscriber server (HSS) 242 and a proxy call session control function (P-CSCF) 244 .
• HSS home subscriber server
• P-CSCF proxy call session control function
• Devices/networks of environment 200 may connect via wired connections, wireless connections, or a combination of wired and wireless connections.
• eNB 222 may connect with MME 232 over a S1-MME interface, and may connect with SGW 234 over a S1-U interface.
• MME 232 may connect with SGW 234 over a S11 interface, and may connect with HSS 242 over a S6 a interface.
• SGW 234 may connect with PGW 238 over a S5 interface.
• PCRF 236 may connect with PGW 238 over a Gx interface.
• PGW 238 may connect with PDN 250 over a SGi interface, and may connect with P-CSCF 244 .
• Other connections may also be utilized by EPS 215 .
• multiple MMEs 232 may connect with one another over S10 interfaces.
• UE 210 may include a device that is capable of communicating over LTE network 220 , EPC network 230 , and/or IMS network 240 .
• UE 210 may include a radiotelephone; a PCS terminal that may combine, for example, a cellular radiotelephone with data processing and data communications capabilities; a smart phone; a PDA that can include a radiotelephone, a pager, Internet/intranet access, etc.; a laptop computer; a tablet computer; a desktop computer; a workstation computer; a personal computer; a landline telephone; or another type of computation and communication device.
• EPS 215 may include is a core network architecture of the 3GPP LTE wireless communication standard.
• EPS 215 may include LTE network 220 , EPC network 230 , IMS network 240 , and PDN 250 .
• LTE network 220 may include a communications network that connects users (e.g., UE 210 ) to a service provider network.
• LTE network 220 may include a wireless local area network (WLAN) or another type of access network (e.g., an E-UTRAN or an eHRPD network).
• LTE network 220 may include a radio access network capable of providing a particular data rate, a particular latency, packet optimization, a particular capacity and coverage, etc.
• eNB 222 may include one or more computation and communication devices, such as a base station, that receive traffic from MME 232 and/or SGW 234 and transmit that traffic to UE 210 .
• eNB 222 may also include one or more devices that receive traffic from UE 210 and transmit that traffic to MME 232 and/or SGW 234 or to other UEs 210 .
• eNB 222 may combine the functionalities of a base station and a radio network controller (RNC) in 2G or 3G radio access networks.
• RNC radio network controller
• EPC network 230 may include an IP packet-switched core network that supports high-speed wireless and wireline broadband access technologies.
• EPC network 230 may provide packet-switched voice services (e.g., which are traditionally circuit-switched) using IMS network 240 and PDN 250 .
• MME 232 may include one or more computation and communication devices that may be responsible for idle mode tracking and paging procedures (e.g., including retransmissions) for UE 210 .
• MME 232 may be involved in a bearer activation/deactivation process (e.g., for UE 210 ) and may choose a SGW for UE 210 at an initial attach and at a time of intra-LTE handover.
• MME 232 may authenticate UE 210 .
• Non-access stratum (NAS) signaling may terminate at MME 232 , and MME 232 may generate and allocate temporary identities to UEs 210 .
• NAS Non-access stratum
• MME 232 may check authorization of UE 210 to utilize LTE network 220 and may enforce roaming restrictions for UE 210 .
• MME 232 may be a termination point in EPC network 230 for ciphering/integrity protection for NAS signaling and may handle security key management.
• MME 232 may provide a control plane function for mobility between LTE network 220 and other access networks with a S3 interface terminating at MME 232 .
• SGW 234 may include one or more devices that route and forward user data packets, may act as a mobility anchor for a user plane during inter-eNB handovers, and may act as an anchor for mobility between LTE and other 3GPP technologies. For idle state UEs 210 , SGW 234 may terminate a downlink data path and may trigger paging when downlink data arrives for UE 210 . SGW 234 may manage and store contexts associated with UE 210 (e.g., parameters of an IP bearer service, network internal routing information, etc.).
• contexts associated with UE 210 e.g., parameters of an IP bearer service, network internal routing information, etc.
• SGW 234 may include one or more traffic transfer devices (or network devices), such as a gateway, a router, a switch, a firewall, a network interface card (NIC), a hub, a bridge, a proxy server, an optical add-drop multiplexer (OADM), or some other type of device that processes and/or transfers traffic.
• traffic transfer devices such as a gateway, a router, a switch, a firewall, a network interface card (NIC), a hub, a bridge, a proxy server, an optical add-drop multiplexer (OADM), or some other type of device that processes and/or transfers traffic.
• PCRF 236 may include one or more computation and communication devices that provide policy control decision and flow based charging control functionalities.
• PCRF 236 may provide network control regarding service data flow detection, gating, QoS and flow based charging, etc.
• PCRF 236 may determine how a certain service data flow shall be treated, and may ensure that user plane traffic mapping and treatment is in accordance with a user's subscription profile.
• PGW 238 may include one or more devices that provide connectivity of UE 210 to external packet data networks by being a traffic exit/entry point for UE 210 .
• UE 210 may simultaneously connect to more than one PGW 238 for accessing multiple PDNs 250 .
• PGW 238 may perform policy enforcement, packet filtering for each user, charging support, lawful intercept, and packet screening.
• PGW 238 may also act as an anchor for mobility between 3GPP and non-3GPP technologies.
• PGW 238 may include one or more traffic transfer devices (or network devices), such as a gateway, a router, a switch, a firewall, a NIC, a hub, a bridge, a proxy server, an OADM, or some other type of device that processes and/or transfers traffic.
• IMS network 240 may include an architectural framework or network (e.g., a telecommunications network) for delivering IP multimedia services.
• IMS network 240 may include a standardized reference architecture that provides session control, a connection control and an applications services framework, and user and services data.
• HSS 242 may include one or more computation and communication devices that provide a master user database that supports devices of IMS network 240 that handle calls.
• HSS 242 may contain subscription-related information (e.g., user profiles), may perform authentication and authorization of a user, and may provide information about a user's location and IP information.
• P-CSCF 244 may include one or more computation and communication devices that function as a proxy server for UE 210 , where SIP signaling traffic to and from UE 210 may go through P-CSCF 244 .
• P-CSCF 244 may validate and then forward requests from UE 210 , and may process and forward responses to UE 210 .
• PDN 250 may include one or more data communications networks that are based on packet switching, as opposed to circuit switching that is used in public telephone networks. In some implementations, PDN 250 may be capable of communicating with UE 210 over IMS network 240 .
• the number of devices and/or networks shown in FIG. 2 is provided as an example. In practice, there may be additional devices and/or networks, fewer devices and/or networks, different devices and/or networks, or differently arranged devices and/or networks than those shown in FIG. 2 . Furthermore, two or more devices shown in FIG. 2 may be implemented within a single device, or a single device shown in FIG. 2 may be implemented as multiple, distributed devices. Additionally, one or more of the devices of environment 200 may perform one or more functions described as being performed by another one or more devices of environment 200 .
• FIG. 3 is a diagram of example components of a device 300 that may correspond to one or more of the devices of environment 200 .
• one or more of the devices of environment 200 may include one or more devices 300 or one or more components of device 300 .
• device 300 may include a bus 310 , a processor 320 , a memory 330 , an input component 340 , an output component 350 , and a communication interface 360 .
• Bus 310 may include a path that permits communication among the components of device 300 .
• Processor 320 may include a processor (e.g., a central processing unit, a graphics processing unit, an accelerated processing unit, etc.), a microprocessor, and/or any processing component (e.g., a field-programmable gate array (FPGA), an application-specific integrated circuit (ASIC), etc.) that interprets and/or executes instructions, and/or that is designed to implement a particular function.
• processor 320 may include multiple processor cores for parallel computing.
• Memory 330 may include a random access memory (RAM), a read only memory (ROM), and/or another type of dynamic or static storage component (e.g., a flash, magnetic, or optical memory) that stores information and/or instructions for use by processor 320 .
• RAM random access memory
• ROM read only memory
• static storage component e.g., a flash, magnetic, or optical memory
• Input component 340 may include a component that permits a user to input information to device 300 (e.g., a touch screen display, a keyboard, a keypad, a mouse, a button, a switch, etc.).
• Output component 350 may include a component that outputs information from device 300 (e.g., a display, a speaker, one or more light-emitting diodes (LEDs), etc.).
• LEDs light-emitting diodes
• Communication interface 360 may include a transceiver-like component, such as a transceiver and/or a separate receiver and transmitter, which enables device 300 to communicate with other devices, such as via a wired connection, a wireless connection, or a combination of wired and wireless connections.
• communication interface 360 may include an Ethernet interface, an optical interface, a coaxial interface, an infrared interface, a radio frequency (RF) interface, a universal serial bus (USB) interface, a high-definition multimedia interface (HDMI), or the like.
• RF radio frequency
• USB universal serial bus
• HDMI high-definition multimedia interface
• Device 300 may perform various operations described herein. Device 300 may perform these operations in response to processor 320 executing software instructions included in a computer-readable medium, such as memory 330 .
• a computer-readable medium may be defined as a non-transitory memory device.
• a memory device may include memory space within a single physical storage device or memory space spread across multiple physical storage devices.
• Software instructions may be read into memory 330 from another computer-readable medium or from another device via communication interface 360 . When executed, software instructions stored in memory 330 may cause processor 320 to perform one or more processes described herein. Additionally, or alternatively, hardwired circuitry may be used in place of or in combination with software instructions to perform one or more processes described herein. Thus, implementations described herein are not limited to any specific combination of hardware circuitry and software.
• device 300 may include additional components, fewer components, different components, or differently arranged components than those shown in FIG. 3 . Additionally, or alternatively, one or more components of device 300 may perform one or more functions described as being performed by another one or more components of device 300 .
• FIG. 4 is a flow chart of an example process 400 for granting or denying access to exposed APIs.
• one or more process blocks of FIG. 4 may be performed by UE 210 .
• one or more process blocks of FIG. 4 may be performed by another device or a group of devices separate from or including UE 210 .
• process 400 may include exposing an IMS PDN API and a DRX cycle API to a PTT application (block 410 ).
• UE 210 may include a PTT application that enables UE 210 to establish and conduct PTT sessions with other UEs 210 .
• UE 210 may include an IMS PDN API that enables UE 210 to establish a data connection with PDN 250 over IMS network 240 , as opposed to over the public Internet.
• the IMS PDN API may enable the PTT application to make a data connection with PDN 250 over IMS network 240 .
• UE 210 may include several hidden or unexposed APIs that may not be viewed or altered by applications provided in UE 210 .
• the IMS PDN API may be exposed by UE 210 so that the PTT application may utilize the IMS PDN API to establish a data connection with PDN 250 over IMS network 240 .
• UE 210 may include a DRX cycle API that controls a DRX cycle timer associated with UE 210 .
• the DRX cycle timer may include a timer that dictates when UE 210 checks a network for traffic (e.g., UE 210 may check a network for traffic after expiration of the DRX cycle timer).
• the DRX cycle API may be exposed by UE 210 so that the PTT application may modify the DRX cycle timer. For example, UE 210 may decrease the DRX cycle timer so that UE 210 checks EPS 215 for traffic (e.g., PTT traffic) more frequently. This may enable UE 210 to more quickly receive PTT traffic from EPS 215 .
• process 400 may include receiving, by a security application, a credential from the PTT application (block 420 ).
• UE 210 may include a security application that provides secure access to exposed APIs in UE 210 .
• the security application may provide secure access to the IMS PDN API and the DRX cycle API by the PTT application.
• the security application may prevent unauthorized applications from accessing the IMS PDN API and the DRX cycle API.
• the security application may include authentication credentials (e.g., a certificate, a signature, an authentication key, a security token, etc.) that may be utilized to authenticate applications attempting to access the IMS PDN API and/or the DRX cycle API.
• the security application may request that a particular application attempting to access the IMS PDN API and/or the DRX cycle API provide authentication credentials.
• the PTT application may be installed in UE 210 by a manufacturer of UE 210 , may be installed by a network service provider, or may be downloaded and installed in UE 210 by a user of UE 210 .
• the PTT application may be provided with authentication credentials (e.g., a signature), and may provide the authentication credentials to the security application.
• the security application may receive the authentication credentials (e.g., the signature).
• process 400 may include determine whether the credential received from the PTT application matches a credential associated with the security application (block 430 ).
• the security application may determine whether the authentication credentials received from the PTT application match the authentication credentials of the security application.
• the authentication credentials of the security application may include a first signature associated with a first certificate, a first private signing key, and/or a first public verification key.
• the authentication credentials of the PTT application may include a second signature associated with a second certificate, a second private signing key, and/or a second public verification key.
• the security application may determine whether the first signature matches the second signature.
• the security application may determine whether the first certificate matches the second certificate, whether the first private signing key matches the second private signing key, and/or whether the first public verification key matches the second public verification key.
• process 400 may include authenticating the PTT application for accessing the IMS PDN API and the DRX cycle API (block 440 ). For example, if the authentication credentials provided by the PTT application match the authentication credentials of the security application, the security application may authenticate the PTT application for accessing the IMS PDN API and/or the DRX cycle API. In some implementations, when the PTT application is installed in UE 210 , the PTT application may be provided with authentication credentials that match the authentication credentials of the security application. Therefore, the security application may authenticate the PTT application for accessing the IMS PDN API and/or the DRX cycle API.
• the PTT application may utilize and/or modify the IMS PDN API and the DRX cycle API.
• the PTT application may utilize the IMS PDN API to establish a data connection (e.g., set up data routes) with PDN 250 over IMS network 240 .
• the PTT application may utilize the data connection over IMS network 240 to implement a QoS framework for PTT traffic associated with the PTT application.
• the PTT application when the PTT application is installed in UE 210 or when UE 210 receives a tracking area update (TAU) (e.g., a TAU may be performed periodically or when UE 210 moves to another set of cells or tracking area) from EPS 215 , the PTT application may access the DRX cycle API in order to modify the DRX cycle API. For example, the PTT application may modify the DRX cycle timer provided in the DRX cycle API. In some implementations, the PTT application may decrease the DRX cycle timer so that UE 210 checks EPS 215 for traffic (e.g., PTT traffic) more frequently (e.g., every so many milliseconds, seconds, minutes, etc.). This may enable UE 210 to more quickly receive PTT traffic from EPS 215 , such as an incoming PTT call, which may result in shorter call setup times (e.g., relative to public Internet-based PTT).
• TAU tracking area update
• the PTT application may restore the DRX cycle timer to a configurable default value based on particular conditions. For example, the PTT application may restore the DRX cycle timer to the default value when UE 210 is connected to an access network other than LTE network 220 (e.g., when UE 210 connects to a wireless LAN (WLAN)). In such an example, the PTT application may modify the DRX cycle timer again when UE 210 reconnects to LTE network 220 .
• WLAN wireless LAN
• process 400 may include not authenticating the PTT application for accessing the IMS PDN API and the DRX cycle API (block 440 ). For example, if the authentication credentials provided by the PTT application fail to match the authentication credentials of the security application, the security application may not authenticate the PTT application for accessing the IMS PDN API and/or the DRX cycle API and may generate an error (e.g., a security exception error). In some implementations, another application of UE 210 may maliciously or not maliciously attempt to access the IMS PDN API and/or the DRX cycle API.
• the other application may not be provided with a credential that matches the credential of the security application. Prior to attempting to access the IMS PDN API and/or the DRX cycle API, the other application may provide the non-matching credential to the security application, and the security application may not authenticate the other application for accessing the IMS PDN API and/or the DRX cycle API.
• the security application may notify the operating system of UE 210 of the result of the authentications. For example, the security application may inform the operating system that the PTT application is authenticated for accessing the IMS PDN API and the DRX cycle API. In another example, the security application may inform the operating system that the other application is not authenticated for accessing the IMS PDN API and the DRX cycle API.
• process 400 may include additional blocks, fewer blocks, different blocks, or differently arranged blocks than those depicted in FIG. 4 . Additionally, or alternatively, two or more of the blocks of process 400 may be performed in parallel.
• FIGS. 5A-5C are diagrams of an example 500 relating to example process 400 shown in FIG. 4 .
• UE 210 includes unexposed APIs 505 that are hidden from a user of UE 210 and/or applications executing on UE 210 , as shown in FIG. 5A .
• Unexposed APIs 505 may include an IMS PDN API 510 that enables UE 210 to establish a data connection with PDN 250 over IMS network 240 , and a DRX cycle API 515 that controls a DRX cycle timer associated with UE 210 .
• IMS PDN API 510 that enables UE 210 to establish a data connection with PDN 250 over IMS network 240
• DRX cycle API 515 that controls a DRX cycle timer associated with UE 210 .
• IMS PDN API 510 and DRX cycle API 515 may be exposed to a PTT application 520 that enables UE 210 to establish and conduct PTT sessions with other UEs 210 .
• IMS PDN API 510 and DRX cycle API 515 may be exposed to PTT application 520 so that PTT application 520 may utilize and/or modify IMS PDN API 510 and/or DRX cycle API 515 .
• UE 210 may include a security application 525 that determines whether an application is authenticated for accessing IMS PDN API 510 and/or DRX cycle API 515 .
• Security application 525 may include a credential 530 that is utilized to authenticate applications attempting to access IMS PDN API 510 and/or DRX cycle API 515 .
• PTT application 520 may provide a credential 535 to security application 525 . Assume that security application 525 determines that credential 535 provided by PTT application 520 matches credential 530 of security application 525 .
• security application 525 may determine that PTT application 520 is authenticated for accessing IMS PDN API 510 and/or DRX cycle API 515 , as indicated by reference number 540 , and may provide this information to an operating system of UE 210 .
• PTT application 520 may provide an access request 545 to IMS PDN API 510 , and IMS PDN API 510 may check 550 , based on access request 545 , with the operating system to determine whether PTT application 520 is authenticated for accessing IMS PDN API 510 . Since PTT application 520 is authenticated, PTT application 520 may be granted access to IMS PDN API 510 , as indicated by reference number 555 . PTT application 520 may provide an access request 560 to DRX cycle API 515 , and DRX cycle API 515 may check 565 , based on access request 560 , with the operating system to determine whether PTT application 520 is authenticated for accessing DRX cycle API 515 . Since PTT application 520 is authenticated, PTT application 520 may be granted access to DRX cycle API 515 , as indicated by reference number 570 .
• another application of UE 210 may provide a credential 575 to security application 525 .
• security application 525 determines that credential 575 provided by the other application does not match credential 530 of security application 525 .
• security application 525 may determine that the other application is not authenticated for accessing IMS PDN API 510 and/or DRX cycle API 515 , as indicated by reference number 580 , and may provide this information to the operating system.
• the other application may provide an access request 585 to IMS PDN API 510 and/or DRX cycle API 515 .
• IMS PDN API 510 and/or DRX cycle API 515 may check 590 , based on access request 585 , with the operating system to determine whether the other application is authenticated for accessing IMS PDN API 510 and/or DRX cycle API 515 . Since the other application is not authenticated, the other application may be denied access to IMS PDN API 510 and/or DRX cycle API 515 , as indicated by reference number 595 .
• FIGS. 5A-5C are provided merely as an example. Other examples are possible and may differ from what was described with regard to FIGS. 5A-5C .
• FIG. 6 is a flow chart of an example process 600 for establishing and conducting a PTT session with another UE based on exposed APIs.
• one or more process blocks of FIG. 6 may be performed by UE 210 .
• one or more process blocks of FIG. 6 may be performed by another device or a group of devices separate from or including UE 210 .
• process 600 may include modifying a DRX cycle timer with a PTT application and via a DRX cycle API (block 610 ).
• the PTT application of UE 210 may access the DRX cycle API, and may modify the DRX cycle timer provided in the DRX cycle API.
• the security application may provide secure access to the DRX cycle API by the PTT application.
• the PTT application may decrease the DRX cycle timer so that UE 210 checks EPS 215 for traffic (e.g., PTT traffic) more frequently. This may enable UE 210 to more quickly receive PTT traffic from EPS 215 , such as an incoming PTT call, which may result in shorter call setup times (e.g., relative public Internet-based PTT).
• process 600 may include establishing, via an IMS PDN API and the PTT application, data routes with a network (block 620 ).
• the PTT application of UE 210 may access the IMS PDN API, and may utilize the IMS PDN API.
• the security application may provide secure access to the IMS PDN API by the PTT application.
• the PTT application may utilize the IMS PDN API to establish a data connection (e.g., set up data routes) with PDN 250 over IMS network 240 .
• IMS network 240 may permit UE 210 to utilize QoS with respect to PTT sessions. The QoS may improve a call setup time for establishing a PTT session, and may improve a latency time associated with the PTT session.
• process 600 may include establishing a QoS framework with the network for prioritizing PTT traffic (block 630 ).
• UE 210 may connect to PDN 250 over IMS network 240 and via LTE network 220 and EPC network 230 .
• the PTT application of UE 210 may establish a QoS framework with EPS 215 (e.g., with IMS network 240 ) that prioritizes PTT traffic associated with the PTT application.
• the PTT application may prioritize PTT traffic over best effort traffic (e.g., email traffic, video traffic, Internet traffic, etc.), as the PTT traffic traverses IMS network 240 and PDN 250 .
• best effort traffic e.g., email traffic, video traffic, Internet traffic, etc.
• the PTT application may utilize the data connection over IMS network 240 to implement a QoS framework for PTT traffic associated with the PTT application.
• QoS bearers may be defined in IMS network 240 and may be set up statically when UE 210 registers with IMS network 240 . In some implementations, the QoS bearers may be set up dynamically when UE 210 utilizes the PTT application to make a PTT call.
• the PTT traffic may be prioritized after guaranteed bit rate (GBR) conversational audio (e.g., voice-over-IP (VoIP) traffic); before non-GBR variable bit rate video traffic; before non-GBR standard video telephony, video streaming, and general best effort traffic; and before non-GBR machine-to-machine (M2M) traffic.
• GLR guaranteed bit rate
• VoIP voice-over-IP
• M2M machine-to-machine
• process 600 may include utilizing the PTT application and the modified DRX cycle timer to establish a PTT session with a UE (block 640 ).
• UE 210 may utilize the modified DRX cycle timer to check EPS 215 for traffic, such as a PTT call from another UE 210 .
• UE 210 may execute the PTT application based on receiving the PTT call.
• the PTT application may display information indicating that the other UE 210 is trying to establish a PTT session with UE 210 .
• a PTT session may be established between UE 210 and the other UE 210 . If the user does not accept the PTT call, a PTT session may not be established between UE 210 and the other UE 210 .
• the user may instruct UE 210 to execute the PTT application, and the user may utilize the PTT application to establish a PTT session with the other UE 210 .
• the PTT application may display a list of available PTT contacts associated with the user, and the user may select a PTT contact associated with the other UE 210 from the list.
• the PTT application may cause UE 210 to generate a PTT call destined for the other UE 210 .
• UE 210 may provide the PTT call to the other UE 210 via EPS 215 . If the PTT contact accepts the PTT call, a PTT session may be established between UE 210 and the other UE 210 . If the PTT contact does not accept the PTT call, a PTT session may not be established between UE 210 and the other UE 210 .
• process 600 may include prioritizing the PTT traffic during the PTT session based on the QoS framework (block 650 ). For example, during the PTT session, UE 210 may prioritize the PTT traffic over best effort traffic based on the QoS framework established with EPS 215 . In some implementations, during the PTT session, the other UE 210 may also prioritize the PTT traffic over any best effort traffic associated with the other UE 210 , based on the QoS framework established with EPS 215 .
• the PTT traffic in the PTT session with the other UE 210 , may be prioritized before non-GBR traffic, such as, for example, variable bit rate video traffic, standard video telephony traffic, video streaming traffic, general best effort traffic, and M2M traffic.
• non-GBR traffic such as, for example, variable bit rate video traffic, standard video telephony traffic, video streaming traffic, general best effort traffic, and M2M traffic.
• the combination of the reduced DRX cycle timer, the QoS framework for PTT traffic, and other enhancements may provide improved PTT call setup time and/or latency time over current 4G PTT implementations, which may improve the PTT user experience for the users of UE 210 and the other UE 210 .
• the combination may enable the user of UE 210 to experience push to hear delays of approximately less than one second during the PTT session with the other UE 210 .
• the combination may enable the user of the other UE 210 to experience push to hear delays of approximately less than one second during the PTT session with UE 210 .
• process 600 may include determining whether the PTT application is uninstalled (block 660 ).
• the security application may determine whether the PTT application is uninstalled (or removed) from UE 210 .
• the user of UE 210 may utilize an uninstall function of UE 210 to request that the PTT application be uninstalled.
• the uninstall function when implemented by the user, may perform operations to uninstall the PTT application from UE 210 .
• the operating system of UE 210 may notify the security application about any applications that are uninstalled from UE 210 , including the PTT application.
• process 600 may include ending the PTT session with the UE (block 670 ).
• the security application determines that the PTT application is not uninstalled, UE 210 may continue to use the PTT application.
• the user of UE 210 may eventually end the PTT session with the other UE 210 by selecting a mechanism (e.g., an end call button, icon, link, etc.) displayed by the PTT application during the PTT session.
• UE 210 may terminate the PTT session with the other UE 210 , and may display information associated with the PTT application to the user. In some implementations, UE 210 may display other information (e.g., data associated with best effort traffic, a home page, etc.) to the user when the PTT session is terminated. In some implementations, the user of the other UE 210 may end the PTT session with UE 210 .
• process 600 may include utilizing the IMS PDN API to remove the data routes with the network (block 680 ).
• the security application may utilize the IMS PDN API to remove any data routes set up by the PTT application via the IMS PDN API.
• the security application may utilize the IMS PDN API to remove any data connections (e.g., data routes) established with PDN 250 over IMS network 240 .
• the PTT application may utilize the IMS PDN API to establish another data connection (e.g., set up data routes) with PDN 250 over IMS network 240 .
• another data connection e.g., set up data routes
• process 600 may include utilizing the DRX cycle API to reset the DRX cycle timer to a default value (block 690 ).
• the security application may utilize the DRX cycle API to reset the DRX cycle timer to a default value.
• the security application may reset the DRX cycle timer to a configurable default value that may reduce battery usage in UE 210 .
• the default value of the DRX cycle timer may include a value that causes UE 210 to check EPS 215 for traffic less frequently, which may conserve battery usage in UE 210 .
• the security application may reset the DRX cycle timer to a configurable default value that may reduce battery usage in UE 210 .
• the default value of the DRX cycle timer may include a value that causes UE 210 to check EPS 215 for traffic less frequently, which may conserve battery usage in UE 210 .
• the security application may read a default DRX value that is being broadcasted by EPS 215 , and may use the default DRX value to change the DRX cycle timer of UE 210 to the default value.
• This may reset the DRX cycle timer of UE 210 to a default value which EPS 215 wants devices to use (e.g., when using the default value).
• the PTT application may decrease the DRX cycle timer so that UE 210 checks EPS 215 for traffic (e.g., PTT traffic) more frequently (e.g., every so many milliseconds, seconds, minutes, etc.).
• process 600 may include additional blocks, fewer blocks, different blocks, or differently arranged blocks than those depicted in FIG. 6 . Additionally, or alternatively, two or more of the blocks of process 600 may be performed in parallel.
• FIGS. 7A-7H are diagrams of an example 700 relating to example process 600 shown in FIG. 6 .
• UE 210 e.g., a smart phone 210
• smart phone 210 includes IMS PDN API 510 , DRX cycle API 515 , and PTT application 520 .
• PTT application 520 may access DRX cycle API 515 , and may instruct DRX cycle API 515 to modify the DRX cycle timer.
• DRX cycle API 515 may modify the DRX cycle timer based the instruction, and UE 210 may utilize modified DRX cycle timer 705 to check EPS 215 for traffic.
• modified DRX cycle timer 705 causes smart phone 210 to check EPS 215 for information more frequently than before the DRX cycle timer was modified.
• PTT application 520 may access IMS PDN API 510 , and may instruct IMS PDN API 510 to establish data routes in EPS 215 .
• IMS PDN API 510 may establish data routes with IMS network 240 and PDN 250 based on the instruction, as indicated by reference number 710 .
• PTT application 520 may determine, with EPS 215 , a QoS framework 715 that prioritizes PTT traffic.
• smart phone 210 may check EPS 215 for information (e.g., received calls, traffic, etc.) based on a modified DRX cycle timer 705 , as indicated by reference number 720 .
• a coworker of the user may be associated with a tablet computer 210 , and may utilize tablet computer 210 to access a PTT application provided in tablet computer 210 . Assume that the coworker utilizes the PTT application to generate a request 725 for a PTT session with the user and smart phone 210 .
• Tablet computer 210 may provide request 725 for the PTT session to EPS 215 , and EPS 215 may forward request 725 toward smart phone 210 utilizing the QoS framework.
• smart phone 210 may execute a PTT application provided in smart phone 210 and may stop displaying email message 715 .
• the PTT application may cause smart phone 210 to display information associated with request 725 , such as the coworker's name, the coworker's picture, a mechanism to accept or deny request 725 , etc.
• the user utilizes the displayed information to accept request 725 , and establish a PTT session with tablet computer 210 and the coworker, as indicated by reference number 730 in FIG. 7C .
• the PTT application may cause smart phone 210 to display a user interface 735 that includes a picture of coworker, a PTT button, and an end call button.
• the PTT application of smart phone 210 may prioritize PTT traffic associated with the PTT session, as indicated by reference number 740 .
• a delay time between when the user speaks and when the coworker hears the user's voice may be approximately less than one second, as indicated by reference number 760 .
• the coworker selects 765 the PTT button and begins talking to tablet computer 210 , as indicated by reference number 770 .
• the coworker's spoken voice may be provided by tablet computer 210 to smart phone 210 (e.g., via EPS 215 ), and may be heard by the user via smart phone 210 , as indicated by reference number 775 .
• a delay time between when the coworker speaks and when the user hears the coworker's voice may be approximately less than one second, as indicated by reference number 780 .
• Either the user or the coworker may end the PTT session by selecting the end call button.
• the end call button is selected, smart phone 210 and tablet computer 210 may end the PTT session, as indicated by reference number 785 in FIG. 7F .
• smart phone 210 may resume displaying email message 715 to the user, and tablet computer 210 may display a home page or some other information to the coworker.
• smart phone 210 may display a user interface 590 to the user, as shown in FIG. 7G .
• User interface 790 may ask whether the user wants to uninstall PTT application 520 .
• the user selects a Yes button of user interface 590 to indicate that the user wants to uninstall PTT application 520 .
• smart phone 210 may uninstall PTT application 520 from smart phone 210 .
• security application 525 may receive (e.g., from the operating system of smart phone 210 ) a notification indicating that PTT application 520 has been uninstalled from smart phone 210 . Based on the notification, security application 525 may instruct DRX cycle API 515 to reset the DRX cycle timer, as indicated by reference number 795 in FIG. 7H , and DRX cycle API 514 may reset the DRX cycle timer to a default value. Based on the notification, security application 525 may instruct IMS PDN API 510 to remove data routes established in EPS 215 , as indicated by reference number 797 in FIG. 7H , and IMS PDN API 510 may remove any data routes established with IMS network 240 and PDN 250 .
• FIGS. 7A-7H are provided merely as an example. Other examples are possible and may differ from what was described with regard to FIGS. 7A-7H .
• a component is intended to be broadly construed as hardware, firmware, or a combination of hardware and software.

Landscapes

• Engineering & Computer Science (AREA)
• Computer Networks & Wireless Communication (AREA)
• Signal Processing (AREA)
• Multimedia (AREA)
• Computer Security & Cryptography (AREA)
• Business, Economics & Management (AREA)
• General Business, Economics & Management (AREA)
• Mobile Radio Communication Systems (AREA)
• Telephonic Communication Services (AREA)

Abstract

Description

Claims (20)

Priority Applications (2)

Applications Claiming Priority (1)

Related Child Applications (1)

Publications (2)

Family

ID=52826063

Family Applications (2)

Family Applications After (1)

Country Status (1)

Families Citing this family (13)

Citations (35)

Family Cites Families (37)

• 2013
  • 2013-10-18 US US14/057,970 patent/US9271149B2/en active Active
• 2015
  • 2015-11-03 US US14/930,852 patent/US9578507B2/en active Active

Patent Citations (35)

Non-Patent Citations (1)

Also Published As

Similar Documents

Legal Events