WO2002062037A2 - Systeme et procede d'interception d'appels - Google Patents

Systeme et procede d'interception d'appels Download PDF

Info

Publication number
WO2002062037A2
WO2002062037A2 PCT/US2001/043350 US0143350W WO02062037A2 WO 2002062037 A2 WO2002062037 A2 WO 2002062037A2 US 0143350 W US0143350 W US 0143350W WO 02062037 A2 WO02062037 A2 WO 02062037A2
Authority
WO
WIPO (PCT)
Prior art keywords
protocol
intercept
call
call intercept
packet data
Prior art date
Application number
PCT/US2001/043350
Other languages
English (en)
Other versions
WO2002062037A3 (fr
Inventor
Jerry Mizell
Peter W. Wenzel
Bala Balachander
Rosemary Mcgowan
Lu Tian
Original Assignee
Nortel Networks Limited
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 Nortel Networks Limited filed Critical Nortel Networks Limited
Priority to AU2001297920A priority Critical patent/AU2001297920A1/en
Publication of WO2002062037A2 publication Critical patent/WO2002062037A2/fr
Publication of WO2002062037A3 publication Critical patent/WO2002062037A3/fr

Links

Classifications

    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L63/00—Network architectures or network communication protocols for network security
    • H04L63/10—Network architectures or network communication protocols for network security for controlling access to devices or network resources
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L63/00—Network architectures or network communication protocols for network security
    • H04L63/30—Network architectures or network communication protocols for network security for supporting lawful interception, monitoring or retaining of communications or communication related information
    • H04L63/304—Network architectures or network communication protocols for network security for supporting lawful interception, monitoring or retaining of communications or communication related information intercepting circuit switched data communications
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04M—TELEPHONIC COMMUNICATION
    • H04M3/00—Automatic or semi-automatic exchanges
    • H04M3/22—Arrangements for supervision, monitoring or testing
    • H04M3/2281—Call monitoring, e.g. for law enforcement purposes; Call tracing; Detection or prevention of malicious calls
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04W—WIRELESS COMMUNICATION NETWORKS
    • H04W12/00—Security arrangements; Authentication; Protecting privacy or anonymity
    • H04W12/03—Protecting confidentiality, e.g. by encryption
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04W—WIRELESS COMMUNICATION NETWORKS
    • H04W12/00—Security arrangements; Authentication; Protecting privacy or anonymity
    • H04W12/80—Arrangements enabling lawful interception [LI]
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04Q—SELECTING
    • H04Q2213/00—Indexing scheme relating to selecting arrangements in general and for multiplex systems
    • H04Q2213/13098—Mobile subscriber
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04Q—SELECTING
    • H04Q2213/00—Indexing scheme relating to selecting arrangements in general and for multiplex systems
    • H04Q2213/13372—Intercepting operator
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04Q—SELECTING
    • H04Q2213/00—Indexing scheme relating to selecting arrangements in general and for multiplex systems
    • H04Q2213/13389—LAN, internet

Definitions

  • This invention relates in general to the field of telecommunications and more specifically relates to a call intercept system and method.
  • LEAs Interested law enforcement agencies
  • TDMA time division multiple access
  • CDMA code division multiple access
  • GSM GSM
  • UMTS universal mobile telecommunications system
  • CDPD cellular digital packet data
  • LEAs from around the globe must be able to receive call intercept information from networks according to their jurisdictional requirements. As the number of interested LEAs increases, so does the burden imposed on each of the networks to provide the requested call interception for each of the LEAs. The difference from one packet data product and/or technology to the next only increases the complexity for implementing call intercept functionality. Moreover, each jurisdiction may have country-specific requirements for presenting subscriber information to the interested law enforcement agencies.
  • one aspect of the invention includes a call intercept method.
  • the method includes receiving a call intercept request from a delivery function using a first protocol layer common to a plurality of packet data networks.
  • the method also includes collecting call intercept information specific to a particular packet data network technology in response to the call intercept request and delivering to the delivery function call intercept information using the first protocol layer.
  • Another aspect of the invention includes an intercept access protocol for intercepting a call within a communications network.
  • the protocol includes a computer-readable medium and a common portion resident on the computer-readable medium.
  • the common portion is operable to receive from a requestor a call intercept request over a plurality of packet data networks, the common portion further operable to deliver call intercept information over the plurality of packet data networks.
  • the protocol also includes a technology-specific portion resident on the computer-readable medium which is operable to collect technology-specific call intercept information in response to the request.
  • the invention provides several important advantages. Various embodiments of the invention may have none, some, or all of these advantages.
  • the invention provides an interface between an access function in a telecommunications network to a delivery function in a call intercept surveillance network.
  • the interface provides for common functions that may be used in a plurality of telecommunications networks independent of technology and/or product type.
  • common transport protocols, provisioning, and delivery mechanisms may be used with a technology-specific protocol portion that provides for intercept and/or collection of technology and/or product-specific content.
  • Such an advantage may reduce the complexity and/or resources needed to provide call intercept information as requested by one or more law enforcement agencies.
  • Such an advantage may also provide the requested call intercept information, regardless of any country-specific requirements for subscriber information to be presented to a delivery function.
  • the invention may also provide a reliable link to ensure delivery of call intercept information to one or more law enforcement agencies.
  • the invention may also provide a secure link to ensure a desired level of data privacy to a delivery function. Call intercept information may then be filtered by one or more law enforcement agencies based on their allowed interrupt type.
  • FIGURE 1 is a block diagram of a surveillance network reference model incorporating teachings of the present invention
  • FIGURE 2 is an example of a protocol hierarchy that may be used for providing call intercept information in accordance with teachings of the present invention
  • FIGURE 3 illustrates a method for providing call intercept information in accordance with teachings of the present invention
  • FIGURE 4 is a block diagram of an example of a network employing GPRS technology that incorporates teachings of the present invention
  • FIGURE 5 is a block diagram of an example of a network employing CDPD technology that incorporates teachings of the present invention
  • FIGURE 6 is a block diagram of an example of a network employing CDMA lxRTT technology that incorporates teachings of the present invention
  • FIGURE 7 is a block diagram of an example of a network employing TDMA technology that incorporates teachings of the present invention.
  • FIGURE 8 is a graphic illustration of an example of stream control and data transfer that incorporates teachings of the present invention.
  • FIGURE 1 is a block diagram of a surveillance network reference model incorporating teachings of the present invention.
  • Network 5 includes at least one access function 14 that may reside in a telecommunications service provider network 11, and at least one law enforcement agency (LEA) 20.
  • LEA 20 may operate in one or more jurisdictions under a variety of country-specific regulations that telecommunications service providers will be required to provide support. For example, regulations will govern commercial GPRS network deployments for Germany and Australia, and the Communications Assistance for Law Enforcement Act (CALEA) will govern packet data network deployments in the United States.
  • CALEA Communications Assistance for Law Enforcement Act
  • TIA J-STD-025 Interim Standard for Lawfully Authorized Electronic Surveillance
  • TIA J-STD-025 provides for call intercept operations to be performed within a telecommunications network 11 using a variety of logical functions, including a service provider administration function 12 coupled to an access function 14 and delivery function 16.
  • Telecommunications network 11 may use any networking technology and/or protocol such as, but not limited to, cellular digital packet data (CDPD), time division multiple access (TDMA), call division multiple access (CDMA), Direct Asynchronous Data Service (DADS), General Packet Radio Services (GPRS) and Radio Transmission Technologies (e.g., lxRTT), and universal mobile telecommunications system (UMTS).
  • Access function 14 includes an intercept access point (IAP) 10 that provides the technical capability to obtain, or intercept, call-identifying information and/or call content requested from a LEA 20 (call intercept information).
  • IAP 10 may have its own database, or access another database within network 11, that includes activations, targets, or identifiers that it is to intercept.
  • Access function 14 is coupled to and provides call interception information via interface 15 to delivery function 16. Delivery function 16 may then be used to transport the call intercept information to a collection function in LEA 20 using an interface defined in the TIA J-STD-025 standard.
  • Interface 15 desirably incorporates transport protocols, provisioning and delivery mechanisms that are all common to a plurality of networking technologies and/or protocols, to deliver technology- specific content to delivery function 16.
  • the invention contemplates a variety of implementations for delivery function 16 in addition to that defined in the TIA J-STD-025 standard, whether or not delivery function 16 resides within LEA 20, telecommunications service provider network 11, or is a standalone element.
  • LEA 20 may obtain a number that is suspected to be used for illegal purposes, or a subscriber that may be suspected of illegal activities. This information may be in several forms, such as a number or private format or a International Mobile Subscriber Identity (IMS! format. Access function 14 then receives a call intercept request, which may include this number, along with other information, such as the number or address of the monitoring center for LEA 20. The call intercept request may then be provisioned. After interception, call intercept information is then returned to LEA 20 over interface 15 in response to the request. A number of different LEAs 20 may monitor a single subscriber or number, over one or more telecommunication networks 11.
  • IMS International Mobile Subscriber Identity
  • the present invention provides a call intercept method and system.
  • the present invention defines a method for transporting a call intercept request from delivery function 16 to access function 14 over at least one protocol layer in a protocol common to a plurality of networks.
  • the protocol layer is independent of network technology and/or product type.
  • Call intercept information may then be gathered by an application layer using a protocol layer specific to the technology and/or product type of a particular network, and then delivered to delivery function 16 using the protocol layer common to the plurality of networks for subsequent delivery to requesting LEA 20.
  • a call intercept request may include activation, deactivation, interrogation and update of the targets whose call content (CC) data or event-related information (IRI) needs to be intercepted for a requesting LEA 20.
  • Call intercept information is then returned in response to the request and identifies, among other things, a subscriber, the subscriber's location, and the packet data transferred to and/or from the subscriber.
  • call intercept information may include, but is not limited to, target identity, type of intercept data, and an intercept ID.
  • call intercept information may also include authenticating information, such as court order data.
  • Type of intercept data may include call control or Intercept Related Information (IRI), such as mobility events and session control, and CC data, such as user data traffic.
  • IRI Intercept Related Information
  • Intercept ID may be, for example, a tag used to correlate information from different IAPs 10.
  • the IRI and CC data may be delivered to delivery function 16. It may be desirable for IRI and CC data to be sent to delivery function 16 in the order of interception.
  • FIGURE 2 is an example of a protocol hierarchy that may be used for providing call intercept information in accordance with teachings of the present invention.
  • Protocol stack 200 includes a number of modules or layers and may provide common layers for functions such as administration and delivery for interface 15 and at least one technology specific layer for functions such as call interception. These modules or layers may reside in one or more nodes in telecommunications network 11.
  • Protocol stack 200 is illustrated as a hierarchical protocol stack and includes layers 202, 204, 206, 208, and 210.
  • Layer 210 includes portions 212, 214, and 216.
  • Layers 202, 204, 206, 208, and portions 212 and 214 include common protocols, and layer 216 is technology specific.
  • modules which provide the rules that govern various communications between LIAP 216, CAP 212 and CDP 214, may reside in memory in one or more elements or nodes in a telecommunications network.
  • all of the modules may reside in and be processed by a logic or other computing module that may reside in a mobile switching center (MSC) in a GPRS network.
  • MSC mobile switching center
  • Data and other information may be located within the memory, which may be various forms such as tables, variables, or databases.
  • Layer 202 provides physical and data link layer functionality and may be, for example, ATM or Ethernet (802.3) running over 10/100 Base T or OC 3.
  • Layer 204 forms a network layer such as IP.
  • Layer 206 may optionally be used in the network layer in a variety of embodiments, such as where tunneling is used to provide network layer security (e.g., IPSec) to secure interfaces between access function 14 and administration function 12 and delivery function 16. For example, in many applications, it is desirable to provide secure and/or high-priority path over an LP-based network.
  • Tunneling provides for encapsulating an encrypted data packet in an IP packet for secure transmission across the inherently insecure IP network. Two such tunneling protocols include IP Security (IPSec) and layer 2 tunneling protocol (L2TP). L2TP is used to provide, note-to-node communications in support of multiple, simultaneous tunnels in the core of the Internet or other IP -based network.
  • IPSec IP Security
  • L2TP layer 2 tunneling protocol
  • Layer 208 provides transport functionality and may include a variety of transport protocols, depending on the application. Layer 208 may employ, for example, Stream Control Transmission Protocol (SCTP) to provide reliable datagram transfer operating on top of an unreliable routed packet network such as IP. Stream Control Transmission Protocol (SCTP) is designed to transport PSTN signaling messages over connectionless packet networks such as JJ? and provides a reliable transport protocol that operates on top of EP and offers services such as, but not limited to, acknowledged user-free non-duplicated transfer of user data and sequenced delivery of user messages within multiple streams.
  • SCTP Stream Control Transmission Protocol
  • Layer 208 may alternatively use User Datagram Protocol (UDP) to deliver datagrams without acknowledgments or guaranteed delivery.
  • UDP User Datagram Protocol
  • TCP Transmission Control Protocol
  • Each of these protocols may be bundled with IP-layer software, depending on the desired configuration.
  • it may also be desirable to send to delivery function 16 IRI data using TCP, and CC data using UDP.
  • the Legal Interception Common Protocol layer (LICP) 210 provides a content layer that is independent of products and/or technologies such as GPRS and lxRTT.
  • LIAP 216 provides packet data and event interception interfaces at an IAP 10 for each of a variety of wireless data networks and performs application layer, technology-specific functions to obtain call intercept information.
  • LICP 210 and LIAP 216 may utilize a number of transmission orders, bit definitions, and other definitions for messages.
  • the Appendix illustrates a number of tables that may be used to illustrate examples for definitions of these messages. Selected tables include row headings that represent network octet order ranging from the value "1" to a value such as "n +13" or "5-n".
  • These tables also include column headings ranging between the value "8", the most significant bit of the octet, and "1", the least significant bit of the octet.
  • a value such as a hexadecimal 'f may be used as a flag (e.g., to indicate all target types for the interrogation requests, or where a bit in a message is not set.)
  • LICP includes a Common Administration Portion (CAP) 212 and a Common Delivery Portion (CDP) 214.
  • CAP 212 provides transport functionality in conjunction with layer 208, as well as performs administrative functions.
  • CAP 212 provides definitions for interface 15 for receiving and provisioning target information, and may receive messages from delivery function 16 such as activation, deactivation, interrogation, and reset request messages.
  • CAP 212 may also send messages to delivery function 16 such as activation, deactivation, interrogation, and reset response messages.
  • TABLE I illustrates one example for LICP Header information.
  • TABLES II and III illustrate examples of definitions that may be used for activation and deactivation request messages.
  • CDP 214 also provides transport functionality in conjunction with layer 208.
  • CDP 214 provides definitions for interface 15 for delivery of call intercept information such as IRI and CC messages. Because IRI and CC data are product- and/or technology- specific, each product and/or technology will typically have its own set of interceptable event that may be defined within an IRI and/or a CC message. These definitions for captured call information by product type and/or technology are provided by a product -specific portion of LIAP 216.
  • a GPRS network may include events such as ATTACH, DETACH, PDP Context Activate, as well as correlation Ids that may be collected by one or more IAPs 10.
  • IAPs 10 for a GPRS network may include, for example, a packet session LAP in a Serving GPRS Support Node (SGSN), and a location information call intercept IAP in a home location register (HLR) node.
  • SGSN Serving GPRS Support Node
  • HLR home location register
  • TABLE TV illustrates an example for an IRI message format that may be used by CDP 214.
  • An IRI message may be sent to delivery function 16 when a target experiences an event. Where SCTP is used for guaranteed delivery, this message may be unacknowledged.
  • One message may be sent per event, and may include information such as one or more observed identities, a direction type such as a direction of packet in relationship to target, a product type such as GPRS, CDPD, and an event type, which is product specific.
  • TABLE V illustrates an example that may be used for a CC message, which may be sent to delivery function 16 when a target receives or sends a data packet. Again, this CC message may be unacknowledged where SCTP is used for guaranteed delivery, and there may be one event per message.
  • the direction type and product type may rely on information element definitions.
  • Information elements may include, but are not limited to, target identity, information to intercept, cause, product type, number of activations, activation ID, direction type, and observed identity. Although each of these information elements may be formatted using a variety of methods, TABLES VI-XIII illustrate examples of information element definitions.
  • a target identity may include target types such as International Mobile Subscriber Identity (DVISI), International Mobile Station Equipment Identity (IMEI), Mobile Identification Number (MIN), Mobile Station ISDN Number (MSISDN), IP addresses, and Network Access Identifier (NAT).
  • DVISI International Mobile Subscriber Identity
  • IMEI International Mobile Station Equipment Identity
  • MIN Mobile Identification Number
  • MSISDN Mobile Station ISDN Number
  • IP addresses IP addresses
  • LIAP 216 provides packet data interception interfaces at an IAP 10 in response to a request received by CAP 212. It may be illustrative to describe LIAP 216 in terms of a specific technology such as GPRS. In this example, CAP 212 may fully satisfy requirements for provisioning GPRS targets at Serving GPRS Support Node (SGSN) or Gateway GPRS Support Node (GGSN) access nodes. LIAP 216 then collects the requested product-specific call intercept information. CDP 214 then packages the collected product-specific call intercept information into a product- independent call intercept information message (e.g., an IRI message and/or a CC message).
  • a product- independent call intercept information message e.g., an IRI message and/or a CC message
  • TABLE XIV illustrates GPRS event details and their specific fields that may be delivered (if available) to delivery function 16 in an IRI message. For example, a particular event is generated when a mobile unit sends a corresponding activation to the GSN. For example, GPRS Detach/Attach events are generated upon detach/attach, and an end user address, cell global identity (CGI), routing area ID, may be delivered if available to delivery function 16. In addition, a failed attach reason may also be delivered if available for a GPRS Attach event.
  • TABLES XV-XIX illustrate examples for GPRS Attach, GPRS Detach, GPRS PDP Context Activation, GPRS PDP Context Deactivation, and cell and/or routing area (RA) update.
  • TABLE XXJT illustrates GPRS specific fields that may be delivered to delivery function 16 in a CC message.
  • TABLES XXffl-XXXIII illustrate examples for information element definitions for GPRS specific information such as GPRS event type, access point name, routing area identifier, end user address, correlation number, SMS, cell global identity, failed attach reason, failed context activation reason, SMS event status, and packet data unit.
  • FIGURE 3 illustrates a method for providing call intercept information in accordance with the teachings of the present invention.
  • the method begins at step 302, where a call intercept request for a target entity is received from delivery function 16 over interface 15.
  • a call intercept request may be defined using a variety of methods. These methods may vary depending on jurisdiction and/or technology, among others.
  • the call intercept request may include a request to activate or deactivate, intercept a mobility event, intercept content, or intercept a mobility event and content.
  • the call intercept request may be provisioned by CAP 212.
  • CAP 212 receives a request to intercept information associated with a targeted subscriber such as one or more packets (content), event, or both.
  • CAP 212 provides provisioning for targets based on the technology of the underlying access network. For example, where IAP 10 resides in a GPRS network, CAP 212 may provide provisioning for GPRS targets at SGSN or GGSN access nodes.
  • Provisioning, or supplying call information service to a requester to meet required specifications may include, but is not limited to, a target of interception and a type of intercept.
  • each type of intercept may vary according to the requirements of LEA 20, it may be desirable for call intercept information to be delivered to delivery function 16 and allow delivery function 16 to filter the call intercept information according to the requirements for each LEA 20.
  • provisioning may also be required to be secure. For example, an operator may not need to have access to information and/or requests that pass over interface 15. Furthermore, only authorized operators may need to see reports, logs, or other information that relates to any call intercept request, or otherwise be able to identify users that may be subject to the call intercept request.
  • CAP 212 may receive an activation request message from LEA 20 (or, conversely, a deactivation request message).
  • An activation request message may include one or more multiple number target activations and may include, for example, a number of activations in the message, a target identity (e.g., target types such as 1MSI, MUST, IP address and target identity digits), an activation ID, information to be intercepted, and addresses for delivery function 16 (e.g., -an IP address for delivery function 16).
  • IAPs 10 may not require interception area identifiers, because IAP 10 may send a location area ID and a cell ID where data was intercepted to delivery function 16. IAPs 10 also need not receive a Lawful Identification Identifier such as warrant or order number.
  • IAP 10 may also be desirable for IAP 10 to receive a single activation request per target at a time from CAP 212, irrespective of the number, location, or type of LEA 20 that has requested interception of that target entity. It may be desirable for LEA 20 to utilize flow control such that subsequent activation requests are held until an activation response has been received.
  • an interrogate request message may also be sent to IAP 10.
  • LEA 20 may desire to audit the integrity of an interception database.
  • CAP 212 may send one or more interrogate response messages, which may also include the target information within LAP 10 needed to satisfy the received request for audit.
  • a reset request message may also be sent to IAP 10 when, for example, LEA 20 may experience a system reset, initialization, or reboot.
  • IAP 10 may discontinue all current interceptions in progress and may purge all activations in its local database, and then send a reset notification message to LEA 20.
  • IAP 10 may also send a reset notification message to LEA 20 when, for example, IAP 10 experiences a restart.
  • LEA 20 may take corrective action if needed such as re-sending all current activations where, for example, LAP 10 has purged all intercept activations from its database.
  • the call intercept request may activate, deactivate, interrogate, or update the target in response to the provisioning.
  • LIAP 216 may perform call interception using one of a variety of known methods to collect applicable IRI and/or CC data using product-specific identifiers for call data such as events, content, subscriber ID, location in step 308. This information is provided to CDP 214.
  • CDP 214 sends an I message to delivery function 16 when a target experiences an event, and a CC message when a target receives and/or sends a data packet.
  • CDP 214 may also copy or duplicate individual IP packets that belong to a user or subscriber.
  • One copy of the intercepted data is sent to its addressee, and the other copy may then be delivered to delivery function 16 in step 310 by CDP 214.
  • CDP 214 may deliver the call intercept information using variety of methods. For example, in some cases call intercept information may be delivered as it is intercepted, or in a requested order. Call intercept information may be sent in a single stream over one or more interfaces 15 to delivery function 16. Delivery function 16 may then separate uplink packets from downlink packets where required by LEAs 20.
  • CDP 214 may also perform additional functions. For example, where SCTP is used in layer 208, CDP 214 may also include logic that requests SCTP to use acknowledged transactions with the delivery function 16. If no acknowledgement is received for a requested packet, CDP 214 may then resend the entire packet, or a plurality of packets that may not have been received by delivery 16. In this way, SCTP may be for reliable signaling as well as a packet data transfer protocol that requires no resource reservation or allocation, and may perform the function of setting up and delivering datagrams to delivery function 16 with the assurance that those datagrams have been delivered to delivery function 16. That is, the same SCTP connection may be used for both stream control as well as to deliver datagram data streams.
  • the use of SCTP allows IRI and CC messages to be otherwise unacknowledged.
  • the accurate ordering of multiple messages such as, for example, an plurality of interrogate response messages may be guaranteed by, for example, the underlying SCTP protocol.
  • Responses and notifications may also include the use of timers or periodical re-sends until an acknowledgment is received. Acknowledgment may be successful or unsuccessful, and may include error or fault detection.
  • TABLE XXXIV illustrates primitives that may be used to communicate between the SCTP layer and SCTP-user layer. An example of this interaction using SCTP is discussed in further detail in conjunction with FIGURE 8.
  • the product-specific portion of LIAP 216 is also based on the technology of the underlying access network.
  • the product-specific portion of LIAP 216 may be similar or conform to the Digital cellular telecommunications system (Phase 2+); Lawful Interception; Stage 2 Technical Specification (GSM 03.33 Version 8.0.0 released 1999), hereinafter the "GSM 03.33 specification”.
  • Delivery function 16 may then filter, separate, or otherwise process the call intercept information according to applicable jurisdictional or LEA requirements using a variety of methods.
  • Product-specific events and details for technologies such as lxRTT may be derived from existing or future specifications and/or standards (e.g., TIA EIA/IS-802-2000 and TIA/EIA IS-835).
  • CAP 212 may fully satisfy requirements for provisioning lxRTT targets at PDSN access nodes. Events such as packet data service establishment, start of intercept with packet data service active, packet data service termination, and identifier changes may be supported by functionality within LICP 210.
  • FIGURES 4-7 are block diagrams illustrating examples of networks incorporating teachings of the present invention.
  • the invention contemplates the use of fewer or more nodes or elements within each of the illustrated networks, in a variety of configurations.
  • each of the networks includes at least one IAP represented by an LICP module 210 that resides in one of the elements in the network, and may include a plurality of IAPs or LICP modules 210 that each reside in one of the network elements.
  • each network has one or more interfaces to a delivery function.
  • FIGURE 4 is a block diagram of a network incorporating teachings of the present invention.
  • Network 400 illustrates the use of an access function 414 that may be used with GPRS or UMTS technology.
  • Access function 414 includes a mobile switching center (MSC) 432, which is coupled to a base station controller (BSC) 436.
  • Access function 414 also includes a Base Station System (BSS) 436, and a GGSN 440. Each of these elements is coupled to a SGSN 438.
  • access function 414 may also include a Short Message Service (SMS) service center 442.
  • SMS Short Message Service
  • two interfaces 415 couple access function 414 to delivery function 416, through which call intercept information may be requested (and delivered) by (and to) one or more LEAs 420.
  • call intercept information is specific to GPRS technology, and examples of definitions for call intercept information may be found in the Appendix.
  • an LICP module 210 may reside in MSC 432 and intercept voice information
  • an LICP module 210 may reside in HLR 434 and may intercept location information.
  • One or more LICP 210 modules may also, alternatively or in addition, reside in MSC 432 and/or HLR 434.
  • LICP 210 modules may also alternatively or in addition be desirable for LICP 210 modules to reside as illustrated in FIGURE 4 in elements such as SGSN 438 and or GGSN 440, although these modules may reside in any of the elements in network 400.
  • an LAP may reside in nodes such as, but not limited to, SGSN 438, GGSN 440, SMS 442 to collect packet data or mobility events.
  • SGSN 438 tracks individual mobile subscriber locations and performs security functions and access control, and is coupled to a BSS 436 through the Gb interface and/or to a UMTS Radio Access Network through an Iu interface.
  • SGSN 438 functionality includes GPRS attach and detach and Packet Data Protocol (PDP) Context Activation and Deactivation, and
  • GGSN 440 functionality includes PDP context activation and deactivation.
  • GGSN 440 interfaces with external Packet Data Networks (PDN) 402, and may be connected with one or more SGSNs 438 via an IP-based packet domain PLMN backbone network.
  • PDN Packet Data Networks
  • GPRS and UMTS subscriber information may be stored and maintained in Home Location Register (HLR) 414 to identify or verify a subscriber, or subscriber data related to features and services. Where roaming, data regarding a particular subscriber may be transferred to a Visitor Location Register (VLR) that may reside in MSC 432, where it is maintained during the period of roaming activity within the coverage area of that provider.
  • HLR Home Location Register
  • VLR Visitor Location Register
  • MSC 432 may receive location information over Gs, and may send paging requests to SGSN 438, allowing network coordination of paging. For example, when SGSN 438 receives a paging request over Gs interface for an attached mobile terminal, SGSN 438 may page the mobile terminal for packet services with IMSI as identifier in an area specified the routing areas corresponding to that MSC. After MSC 432 performs a combined PS attach, SGSN 438 may continue serving the Gs interface paging request.
  • SGSN 438 may obtain packet domain subscription data and routing information from HLR 434 via the Gr interface, whether the subscriber is roaming or not.
  • Functionality for SGSN 438 and GGSN 440 may be combined in a same physical node, or they may reside in different physical nodes.
  • SGSN 438 and GGSN 440 each contain IP and additional routing functionality such as operator selection, and may be interconnected with an interface Gn.
  • Gp interface which provides additional security functionality.
  • FIGURES 5-7 are block diagrams of additional examples of networks that may incorporate teachings of the present invention.
  • FIGURE 5 illustrates a network 500 with an access function 514 incorporating CDPD technology.
  • a Mobile Data Intermediate System (MDIS) 532 includes access function 514 .
  • MDIS Mobile Data Intermediate System
  • one interface 515 couples access function 514 to delivery function 516, through which call intercept information may be requested (and delivered) by (and to) one or more LEAs 520.
  • Call intercept information may be passed from access function 514 to delivery function 516 over call intercept interface 515, using the method and protocol stack 200 described in conjunction with FIGURES 2 and 3.
  • an LICP module 210 may reside in MDIS 532 to intercept packet data or location information. Ln other embodiments, LICP 210 modules may alternatively or in addition reside in any of the elements in network 400.
  • call intercept information is specific to CDPD technology, and the product-specific portion of LIAP 216 may be tailored using specific CDPD protocol, functionality, and technology to determine appropriate IRI and CC data and product-specific information element definitions.
  • CDC events include registration, cell-transfer, and roaming authentication.
  • FIGURE 6 illustrates a network 600 with an access function 614 incorporating CDMA (lxRTT) technology.
  • access function 614 includes an MSC 632, BSC 634, and packet data servicing node (PDSN) 636, which is coupled to PDN 602.
  • PDSN packet data servicing node
  • one interface 615 couples access function 614 to delivery function 616, through which call intercept information may be requested (and delivered) by (and to) one or more LEAs 620.
  • Call intercept information may be passed from access function 614 to delivery function 616 over call intercept interface 615, using the method and protocol stack 200 described in conjunction with FIGURES 2 and 3.
  • an LICP module 210 may reside in PDSN 636 to intercept voice and/or location information.
  • LICP 210 modules mayalternatively or inaddition reside in any of the elements in network 600.
  • call intercept information is specific to CDMA lxRTT technology, and the product-specific portion of LIAP 216 may be tailored using specific CDMA lxRTT protocol, functionality, and technology to determine appropriate IRI and CC data and product-specific information element definitions.
  • CDC events may include a circuit implementation that should provide functionality to intercept all relevant mobility events.
  • PDSN events include, for example, activation deactivation, and CCC delivery.
  • FIGURE 7 illustrates an example of another network that may incorporate the teachings of the present invention.
  • network 700 employs TDMA technology and includes an MSC 732 coupled to delivery function 716, PSTN 702 and BSC 734.
  • BSC 734 is coupled to base tranceiver station (BTS) 738.
  • MSC 732 is coupled to interworking function (IWF) 710 by MIT trunks 712, and coordinates the transfer of packet data to and from networks to which IWF 710 is coupled.
  • IWF interworking function
  • Call intercept information may be passed from access function 614 to delivery function 616 over call intercept interface 615, using the method and protocol stack 200 described in conjunction with FIGURES 2 and 3. Ln this embodiment it may be desirable for access function 714, and hence LICP 210 modules, to reside in IWF 710. In other embodiments, LICP 210 modules may also, alternatively or in addition, reside in other elements in network 700 such as MSC 732.
  • call intercept information is technology-specific, and the product- specific portion of LIAP 216 may be tailored using specific protocol, functionality, and technology to determine appropriate IRI and CC data and product-specific information element definitions.
  • CSD and data received from IWF 710 may be separately provisioned, and CDC and CCC data and or events may be delivered from access function 714 to delivery function 716 without passing through MSC 732.
  • Such an embodiment may provide an advantage over an embodiment where, for example, both access function 714 and delivery function 716 may reside in MSC 732, where MSC 732 may suffer from an overload in capacity and/or complexity.
  • CCC events may be acquired by tapping into MIT trunks 712, and CDP 214 may deliver packet data to delivery function 716. Furthermore, where MIT trunks are tapped, it may also be difficult to differentiate content and address. Moreover, provisioning and intercepting CDC information such as, but not including, identifying call endpoints such as dialed number and/or destination IP address may be more difficult where both functions reside in MSC 732.
  • FIGURE 8 is a graphic illustration of an example of reliable stream control and data transfer that incorporates teachings of the present invention.
  • SCTP protocol modules 812 and 814 and applications 822 and 824 may reside respectively on host computers 802 and 804.
  • host computers 802 and 804 may be any node that resides in any telecommunication system, an example may be illustrative.
  • host computer 802 may be an SGSN node in a telecommunications network
  • host computer 804 may be a delivery function 16 in a call intercept scenario as was described above.
  • application 822 may be, for example, a LICP module resident on the SGSN
  • application 824 may be, for example, a LICP module resident on delivery function 16.
  • Applications 822 and 824 interface with SCTP protocol modules 812 and 814.
  • applications 822 and 824 may interface with SCTP protocol modules 812 and 814 to provide setup or stream control functions.
  • applications 822 and 824 may be SCTP User Applications and interface with SCTP Transport Service, as described in the Network Working Group Request for Comments (RFC) 2960 (Stream Control Transmission Protocol Internet Draft), published October 2000 (the "SCTP Draft”).
  • RRC Network Working Group Request for Comments
  • applications 822 and 824 are operable to recognize, parse, and multiplex the datagram streams transmitted using the SCTP protocol modules 812 and 814 in order to provide delivery and acknowledgement of datagrams in addition to providing setup functionality.
  • An association may be established between SCTP protocol modules 812 and 814 so that computers 802 and 804 may communicate with one another.
  • This process may be described as stream control 835, and includes communication setup sequences and activation requests and responses.
  • an SCTP connection setup sequence 830 is first passed between SCTP protocol modules 812 and 814.
  • SCTP protocol module 814 transmitting an SCTP INIT signal to module 812
  • SCTP protocol module 812 transmitting an SCTP INIT acknowledgement (ACK) signal to module 814.
  • the method also includes SCTP protocol module 814 transmitting an SCTP COOKIE ECHO signal to module 812 and SCTP protocol module 812 transmitting an SCTP COOKIE ACK signal to module 814.
  • application 824 may transmit a signaling message such as an application setup request 832 to application 822.
  • the SCTP connection may be used to deliver that signaling message and the corresponding application setup response 834 from application 822.
  • application 822 After the association has been established using SCTP modules 812 and 814, application 822 then may use the same SCTP connection that was established for signaling messages to deliver an application data stream 845, which includes non- signaling application datagrams 840 - 844, to application 824.
  • stream control 835 may first include transmission of a signaling message such as a Call Intercept Activation Request to a LICP module resident on the SGSN.
  • the SCTP connection may then be used to deliver that signaling message and the corresponding response from the SGSN LICP.
  • the SGSN LICP may then deliver non-signaling application datagrams such as Call Content messages by using the same SCTP connection that was established for signaling messages.
  • the use of SCTP and its delivery assurances allows each of the applications to be simplified. Part of the simplification is the result of assured delivery of datagrams, which may remove the necessity of parsing the delivered data stream as would be required by the use of other protocols such as TCP.
  • Application simplification may also be achieved by multiplexing both control and application datagram transfer onto the same interface provided by the SCTP protocol.
  • the present invention provides a call intercept method and system.
  • the present invention defines a method for transporting a call intercept request from delivery function 16 to access function 14 over at least one protocol layer in a protocol common to a plurality of networks, some examples of which have been discussed in conjunction with FIGURES 5-7.
  • the protocol layer is independent of network technology and/or product type.
  • Call intercept information may then be gathered by an application layer using a protocol layer specific to the technology and/or product type of a particular network, and then delivered to delivery function 16 using the protocol layer common to the plurality of networks for subsequent delivery to requesting LEA 20.
  • the invention has been described using the J-STD-025 requirements and in terms of CALEA, the invention contemplates the use of a number of standards, technologies, and protocols that may be used in a variety of jurisdictions. Moreover, the invention also contemplates additional types of call intercept information that may be transferred to delivery function 16 in addition to the information defined in the Appendix for IRI and CC messages. Furthermore, the invention also contemplates the use of a variety of methods and approaches to insure reliability and/or security over interface 15 to delivery function 16.
  • a LICP header may include a version number.
  • LICP header may also include a source node ID, which in this example includes a network operator ID link, a network operator ED, a network element ED type and link, a message type and link, and a transaction ID.
  • the LICP header may also include a date and time of the provisioning request, response, or ERI/CC trigger event. Ln one embodiment of the invention, this date and time may be expressed as a local time at LAP 10. This date and time may include year, month, day, and a time stamp that includes hour, minute, seconds, hundreds of seconds, and thousands of seconds.
  • TABLES Il-a and Il-b illustrate examples of definitions that may be used for activation and deactivation request messages.
  • TABLE HI illustrates an example of definitions that may be used for an activation response message. Some of these tables include a Presence column that indicates whether inclusion of the parameter in a message is mandatory (M), optional (O), or conditional (C).
  • Information element (IE) details are described in further detail in conjunction with TABLES VI-XIII.
  • product LIAP definition is discussed in further detail in conjunction with TABLES XIV-XXXIII.
  • An interrogate request message may be formatted identically to the deactivation request message.
  • an interrogate response message format may be identical to the activation request message format illustrated in TABLE Ll-a.
  • Reset request and reset notification message formats may, in one embodiment, include a single row having a one-byte reset tag.
  • TABLES IV and V illustrate examples for an IRI message and a CC message that may be used by CDP 214 to send to delivery function 16 when a target receives or sends a data packet.
  • the direction type and product type may rely on information element (IE) definitions.
  • Information elements (EE) details are described in further detail in conjunction with TABLES VI-XIII.
  • product LIAP definition is discussed in further detail in conjunction with TABLES XIV-XXXHI.
  • IEs may include, but are not limited to, target identity, information to intercept, cause, product type, number of activations, activation ID, direction type, and observed identity. Although each of these LEs may be formatted using a variety of methods, TABLES VI-XIH illustrate examples of IE definitions that may be used, and examples therein.
  • TABLE VI illustrates an example of a target identity, which may include target types such as EVISL EMEI, MEM, MSISDN, IP addresses, and NAI.
  • a value such as hex 'f may be used as a flag to indicate that a particular bit is not set, or that all values such as product types apply.
  • Product type may include, but is not limited to, GPRS, CDPD, TDMA, Direct Asynchronous Data Service (DADS), lxRTT, UMTS, and CDMA.
  • Direction type may include no direction, or be identified as from the target or on an uplink or to the target, on a downlink.
  • Observed identity may include the same types as the target identity, and a target tag to identify whether the observed identity is or is not a target.
  • TABLE XIV illustrates GPRS event details and their specific fields that may be delivered (if available) to delivery function 16 in an IRI message. For example, a particular event is generated when a mobile unit sends a particular corresponding activation to the GSN. For example, GPRS Detach/Attach events are generated upon detach/attach, and an end user address, cell global identity (CGI), routing area ID, may be delivered if available to delivery function 16. In addition, a failed attach reason may also be delivered if available for a GPRS Attach event.
  • TABLES XV-XLX illustrate examples for GPRS Attach, GPRS Detach, GPRS PDP Context Activation, GPRS PDP Context Deactivation, and cell and/or routing area (RA) update.
  • a start interception with PDP Context Active ⁇ event may be generated if interception of a target is started and if the target has at least one PDP context active. Where more than one PDP contexts are open, an event record may be generated for each open context.
  • an SMS event may be generated in the SGSN when the SMS-center successfully or unsuccessfully acknowledges the SMS.
  • this event may be generated in the SGSN when a target successfully or unsuccessfully acknowledges the message.
  • TABLE XXII illustrates GPRS specific fields that may be delivered to delivery function 16 in a CC message.
  • XX ⁇ i-XXXrfl illustrate examples for information element definitions for GPRS specific information such as GPRS event type, access point name, routing area identifier, end user address, correlation number, SMS, cell global identity, failed attach reason, failed context activation reason, SMS event status, and packet data unit.
  • GPRS product types may include, for example, GPRS attach and detach, PDP context activation and deactivation, start of intercept with PDP context active, cell and or RA update, and SMS.
  • the access point may be a label or fully qualified domain name.
  • the syntax of the Access Point Name may follow a naming syntax defined in RFC 2181 (Clarifications to the DNS Specification), RFC 1035 (DOMAIN NAMES - IMPLEMENTATION AND SPECIFICATION), and/or the Digital cellular telecommunications system (Phase 2+); Numbering, addressing and identification Technical Specification (GSM 03.03 version 7.5.0 Release 1998), herein after the "GSM 3.03 specification”.
  • the RAI may be composed of the following elements:
  • LAI Location Area Identity
  • RAC Routing Area Code
  • the LAI may be composed of the following elements:
  • MCC Mobile Country Code
  • MNC Mobile Network Code
  • LAC Location Area Code
  • the End User Address may consist of the PDP Type Organization , PDP Type Number, and PDP Address as documented in Digital cellular telecommunications system (Phase 2+); General Packet Radio Service (GPRS); GPRS Tunnelling Protocol (GTP) across the Gn and Gp Interface Technical Specification (GSM 09.60 version 7.50 Release 1998), hereinafter the "GSM 9.60 specification”.
  • GPRS General Packet Radio Service
  • GTP GPRS Tunnelling Protocol
  • the Charging ID may be a unique four-octet value generated by the GGSN when a PDP context is activated. A Charging ID is generated for each activated context.
  • the Charging LD value 0 may be reserved and is not assigned by the GGSN.
  • the GGSN Address may be 4 octets for an IPv4 address or 16 octets for an Ipv6 address, It may not include an address type or an address length.
  • the CGI may be as defined in the GSM 3.03 specification.
  • the PDU may be variable length and may include the data payload.
  • TABLE XXXHI Packet Data Unit TABLE XXXIV illustrates primitives that may be used to communicate between the SCTP layer and SCTP-user layer.

Landscapes

  • Engineering & Computer Science (AREA)
  • Computer Security & Cryptography (AREA)
  • Signal Processing (AREA)
  • Computer Networks & Wireless Communication (AREA)
  • Technology Law (AREA)
  • Computer Hardware Design (AREA)
  • Computing Systems (AREA)
  • General Engineering & Computer Science (AREA)
  • Data Exchanges In Wide-Area Networks (AREA)
  • Mobile Radio Communication Systems (AREA)

Abstract

L'invention concerne un procédé d'interception d'appels. Ce procédé consiste à recevoir une demande d'interception d'appels provenant d'une fonction de distribution, via une première couche de protocole commune à une pluralité de réseaux de données par paquets. Ce procédé consiste également à collecter des informations d'interception d'appels spécifiques à une technologie particulière de réseaux de données par paquets en réponse à une demande d'interception d'appels, et à distribuer les informations d'interception d'appels à la fonction de distribution, via la première couche de protocole.
PCT/US2001/043350 2000-11-21 2001-11-20 Systeme et procede d'interception d'appels WO2002062037A2 (fr)

Priority Applications (1)

Application Number Priority Date Filing Date Title
AU2001297920A AU2001297920A1 (en) 2000-11-21 2001-11-20 Call intercept system and method

Applications Claiming Priority (2)

Application Number Priority Date Filing Date Title
US72172900A 2000-11-21 2000-11-21
US09/721,729 2000-11-21

Publications (2)

Publication Number Publication Date
WO2002062037A2 true WO2002062037A2 (fr) 2002-08-08
WO2002062037A3 WO2002062037A3 (fr) 2003-12-18

Family

ID=24899066

Family Applications (1)

Application Number Title Priority Date Filing Date
PCT/US2001/043350 WO2002062037A2 (fr) 2000-11-21 2001-11-20 Systeme et procede d'interception d'appels

Country Status (2)

Country Link
AU (1) AU2001297920A1 (fr)
WO (1) WO2002062037A2 (fr)

Cited By (4)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
WO2004105318A1 (fr) * 2003-05-21 2004-12-02 Siemens Aktiengesellschaft Unite centrale d'interception et d'evaluation
EP1829392A1 (fr) * 2004-12-16 2007-09-05 TELEFONAKTIEBOLAGET LM ERICSSON (publ) Interception legale avancee de sms
WO2011076984A1 (fr) * 2009-12-23 2011-06-30 Nokia Corporation Appareil, procédé et support de stockage lisible par ordinateur pour déterminer des éléments de protocole d'application en tant que types différents de contenu d'interception légale
WO2021126020A1 (fr) * 2019-12-16 2021-06-24 Telefonaktiebolaget Lm Ericsson (Publ) Gestion d'informations d'interceptions légales

Citations (2)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
WO2000028773A2 (fr) * 1998-11-05 2000-05-18 Adc Newnet, Inc. Systeme pour l'interception de communications sans fil
WO2000042742A1 (fr) * 1999-01-14 2000-07-20 Nokia Networks Oy Procede et systeme d'interception

Patent Citations (2)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
WO2000028773A2 (fr) * 1998-11-05 2000-05-18 Adc Newnet, Inc. Systeme pour l'interception de communications sans fil
WO2000042742A1 (fr) * 1999-01-14 2000-07-20 Nokia Networks Oy Procede et systeme d'interception

Non-Patent Citations (3)

* Cited by examiner, † Cited by third party
Title
"UNIVERSAL MOBILE TELECOMMUNICATIONS SYSTEM (UMTS);3G SECURITY; LAWFUL INTERCEPTION ARCHITECTURE AND FUNCTIONS (3G TS 33.107 VERSION 3.0.0 RELEASE 1999)" ETSI TS 133 107 V3.0.0, XX, XX, January 2000 (2000-01), XP002214517 *
HALSALL F: "THE OPEN SYSTEMS INTERCONNECTIONS (OSI) SEVEN-LAYER MODEL" , COMMUNICATIONS HANDBOOK, XX, XX, PAGE(S) 567-576 XP001068249 figures 41.3,41.4 paragraph [41.3] *
STEWART R ET AL: "RFC 2960: Stream Control Transmission Protocol" IETF RFC, 31 October 2000 (2000-10-31), XP002220549 *

Cited By (6)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
WO2004105318A1 (fr) * 2003-05-21 2004-12-02 Siemens Aktiengesellschaft Unite centrale d'interception et d'evaluation
EP1829392A1 (fr) * 2004-12-16 2007-09-05 TELEFONAKTIEBOLAGET LM ERICSSON (publ) Interception legale avancee de sms
EP1829392A4 (fr) * 2004-12-16 2012-07-18 Ericsson Telefon Ab L M Interception legale avancee de sms
WO2011076984A1 (fr) * 2009-12-23 2011-06-30 Nokia Corporation Appareil, procédé et support de stockage lisible par ordinateur pour déterminer des éléments de protocole d'application en tant que types différents de contenu d'interception légale
US9106603B2 (en) 2009-12-23 2015-08-11 Synchronics plc Apparatus, method and computer-readable storage mediums for determining application protocol elements as different types of lawful interception content
WO2021126020A1 (fr) * 2019-12-16 2021-06-24 Telefonaktiebolaget Lm Ericsson (Publ) Gestion d'informations d'interceptions légales

Also Published As

Publication number Publication date
WO2002062037A3 (fr) 2003-12-18
AU2001297920A1 (en) 2002-08-12

Similar Documents

Publication Publication Date Title
US7283521B1 (en) System and method for reporting communication related information in a packet mode communication
US6754834B2 (en) Technique for generating correlation number for use in lawful interception of telecommunications traffic
EP1523827B1 (fr) Information d'un systeme d'interception licite du systeme serveur servant une cible interceptee
EP1487160B1 (fr) Enregistrement d'usage de service pour communications de données mobiles
US20050128967A1 (en) Identifying services provided via IP and similar packet networks, and service usage records for such services
KR20080035818A (ko) 이동통신 시스템에서 패킷 데이터 감청을 위한 장치 및 방법
US20060262736A1 (en) System and method for associating IP services to mobile subscribers
EP2900004B1 (fr) Procédé et réseau de télécommunication mobile avec une plate-forme SAVi
EP2887742B1 (fr) Réseaux de télécommunications
US7356330B2 (en) System and method for assigning a personalized indicium to a mobile communications device
US7336941B1 (en) System and method for unified accounting for wireless communication networks
EP2887614B1 (fr) Réseaux de télécommunications
CA2532083A1 (fr) Authentification d'acces transparente dans des reseaux d'acces mobile 2gou 2.5g
WO2002062037A2 (fr) Systeme et procede d'interception d'appels
US20040120264A1 (en) Method for carrying out monitoring in packet-oriented telecommunication and data networks
EP1371243B1 (fr) Systeme et methode permettant d'identifier des utilisateurs de telephones mobiles
US20020131447A1 (en) System and method for wireless packet data content switch
EP1662829A1 (fr) Système et procédé pour l'allocation d'un numéro d'identification personnel (NIP) permanent à un dispositif de communication mobile
WO2000056097A1 (fr) Mise en correlation des evenements reseau et des identites d'abonne et d'equipement mobile
JP2001320416A (ja) 移動体パケット通信システムにおける品質情報測定方法及びシステム並びに品質情報提供方法及びシステム
CN101166134A (zh) 一种基于ip接入的业务去注册方法
JP2003298615A (ja) 従量制課金システム、サーバ及び方法
EP1340343A2 (fr) Systeme et procede de commutation d'un contenu de donnees radiotransmises par paquets

Legal Events

Date Code Title Description
AK Designated states

Kind code of ref document: A2

Designated state(s): AE AG AL AM AT AU AZ BA BB BG BR BY CA CH CN CO CR CU CZ DE DK DM DZ EC EE ES FI GB GD GE GH GM HR HU ID IL IN IS JP KE KG KP KR KZ LC LK LR LS LT LU LV MA MD MG MK MN MW MX MZ NO NZ PH PL PT RO RU SD SE SG SI SK SL TJ TM TR TT TZ UA UG US UZ VN YU ZA ZW

AL Designated countries for regional patents

Kind code of ref document: A2

Designated state(s): GH GM KE LS MW MZ SD SL SZ TZ UG ZM ZW AM AZ BY KG KZ MD RU TJ TM AT BE CH CY DE DK ES FI FR GB GR IE IT LU MC NL PT SE TR BF BJ CF CG CI CM GA GN GQ GW ML MR NE SN TD TG

DFPE Request for preliminary examination filed prior to expiration of 19th month from priority date (pct application filed before 20040101)
121 Ep: the epo has been informed by wipo that ep was designated in this application
REG Reference to national code

Ref country code: DE

Ref legal event code: 8642

122 Ep: pct application non-entry in european phase
NENP Non-entry into the national phase

Ref country code: JP

WWW Wipo information: withdrawn in national office

Country of ref document: JP