WO1998009456A1

WO1998009456A1 - Wireless call processing

Info

Publication number: WO1998009456A1
Application number: PCT/US1997/014655
Authority: WO
Inventors: Denise L. Anderson; John C. Clark
Original assignee: Tollfree Cellular
Priority date: 1996-08-30
Filing date: 1997-08-20
Publication date: 1998-03-05
Also published as: AU4078097A

Abstract

Systems and methods are described for processing a wireless call signal in which a bill-receiving party different from the calling party is billed for wireless air time charges associated with a received wireless call signal. A translator is disclosed for incorporating a called party destination code into the received wireless call signal when the received wireless call signal has a preselected routing code. A processor is also disclosed for routing the call signal to the translator when the received wireless call signal has the preselected routing code. The translator and processor are preferably configured to translate wireless call signals encoded according to the signaling system 7 common channel signaling protocol.

Description

WIRELESS CALL PROCESSING Background of the Invention This invention relates to wireless call processing, including cellular, personal communication service (PCS) and enhanced specialized mobile radio (ESMR) call processing.

Wireless calls are processed and communicated over a network that includes linked switches, such as service switching points (SSPs) and/or mobile switching centers (MSCs) that route call traffic through the network, and service control points (SCPs) that provide routing instructions to the SSPs and MSCs. The network uses a common channel signaling (CCS) protocol to facilitate information exchange between the switches and the control points. Signaling System 7 (SS7) is a CCS protocol that includes a message transfer part (MTP) and an integrated services digital network subscriber user part (ISUP) . The ISUP supports the signaling functions required to provide voice and non-voice services n an integrated services digital network (ISDN) , and can be used m dedicated telephone and circuit switched data networks and in analog and mixed analog/digital networks . The services of the SS7 MTP are used to transfer between communicating ISUP-equipped entities signaling information that includes a routing label which identifies the message task; the MTP uses the routing label to route the message to the destination point. The U.S. national routing label has a length of 56 bits and consists of the destination point code (DPC) , the originating point code (OPC) , and the signaling link selection (SLS) fields.

As used herein a MSC is a mobile switch that has an air interface to wireless telephone users, and a SSP is a generic term for a switch that can access the SS7 network. A SSP or MSC in an SS7 network provides MTP capabilities, including basic SS7 message handling and signaling network management functions. Normally, SS7 messages travel between different SSPs or MSCs via signaling transfer points (STPs) , which are specialized packet switches used to route signaling messages.

Referring to Fig. 8, under the SS7 protocol, wireless calls are typically processed as follows. A wireless user 200 makes a call from a wireless phone. The user's wireless carrier receives the call at a mobile switch center (MSC) 202 that processes the call. If the call is directed to a local number, the MSC routes the call 204 directly to a local exchange carrier (LEC) end office 206 which completes the call to called party 208. If the call is a standard long distance number, the MSC routes the call through one or more interexchange offices (IXC) 210 in a public switch network to a LEC end office 212 which completes the call to called party 214. If the call is a toll free 1+800 number, the mobile switch center sends the call to LEC 206 which sends a routing inquiry via a signal transfer point (STP) 216, which routes the call information over the SS7 network to a service control point (SCP) 218. The SCP includes a real-time database that contains routing instructions downloaded from an 800 service management system

(SMS/800) 220, which is the main operations support system used to create and update 800 records. The SCP sends the 800 call routing information back through the SS7 network and the STP 216 to the LEC 206, which then completes the call to called party 214 over IXC 210 and LEC 212. The wireless carrier charges the wireless user for wireless air time regardless of whether the call is local, long distance or a 800 toll free call; for long distance calls, the wireless carrier also passes the long distance charges along to the wireless user. Summary of the Invention The invention concerns systems and methods for processing a wireless call signal received from a calling party and directed to a called party in which a bill- receiving party different from the calling party is billed for wireless air time charges associated with the received wireless call .

In one aspect, the invention features systems and methods for processing a wireless call signal in which a called party destination code is incorporated into the wireless signal when the received wireless call signal has a preselected routing code.

Embodiments may include one or more of the following features. A calling party identifier in the received wireless call signal may be replaced with an identifier for a bill-receiving party different from the calling party. A translator coupled to a service control point may incorporate the called party destination code into the wireless signal. A processor may route the call signal to the translator when the received wireless call signal has the preselected routing code; the processor is preferably coupled to a wireless switch, which preferably includes a switching circuit dedicated to handling wireless call signals having the preselected routing code. The processor preferably receives the wireless call signal from the calling party, incorporates an identifier for the wireless switch into the wireless call signal, and forwards the received call signal with the incorporated switch identifier to the translator when the received wireless call signal has the preselected routing code. The translator preferably includes a controller for determining the wireless switch from the received wireless call signal identifier received from the wireless switch. A database preferably stores called party destination codes for wireless call signals having the preselected routing code. The processor preferably incorporates one or more padding digits into the received wireless call signal for efficiency of processing associated with fixed-length called party numbers. The translator preferably removes the padding digits to determine the called party destination code. The translator is preferably configured to translate wireless call signals encoded according to the signaling system 7 protocol (e.g., the ISDN Subscriber User Part (ISUP) of the signaling system 7 protocol) .

Other features and advantages will become apparent from the following.

Brief Description of the Drawings Fig. 1 is a schematic diagram of a novel scheme for processing wireless calls using the SS7 protocol. Figs . 1A and IB are schematic views of information flow in the wireless call processing scheme of Fig. 1.

Figs. 2 and 2A are schematic views of information flow in the wireless call processing scheme of Fig. 1. Fig- 3 is a schematic diagram of a translator supported on a host SCP system and coupled to external support devices.

Fig. 4 is a schematic view of information flow in the translator of Fig. 3. Fig. 5 is a flow diagram of a method for processing an initial address message. Figs. 5A and 5B are schematic views of information flow in the translator of Fig. 3.

Fig. 6 is a diagrammatic view of a novel scheme for processing wireless calls using the SS7 protocol.

Fig. 7 is a schematic view of a novel scheme for processing wireless calls. Fig. 7A is a schematic view of the flow of billing charges in the wireless call processing scheme of Fig. 7. Fig. 8 is a schematic diagram of a conventional scheme for processing wireless calls using the SS7 protocol .

Description of the Preferred Embodiments In each of the following embodiments, service subscribers are assigned one or more characteristic toll free wireless numbers (identified by the prefix #800) that wireless users can call without being billed for the call; air time and other charges are instead billed to service subscribers. In the embodiments of Figs. 1-6, the service is implemented in part by configuring a mobile switch center (or service switching point) to handle #800 traffic and by configuring a service control point to return to the mobile switch center modified calling information that allows that call to be completed with and billed to the #800 service subscriber.

Referring to Fig. 1, a wireless carrier's mobile switch center 10 or other service switching point (SSP) , which is connected to, e.g., ILLUMINET (formerly, Independent Telecommunications Network, Inc.), has ANSI SS7 ISUP (ISDN Subscriber User Part) trunk signaling protocol capabilities and includes a dedicated loop back voice trunk group 12 and a routing processor for routing #800 traffic to the loop back voice trunk group. The MSC receives a wireless call from a wireless user 14 and processes the call as follows. When a #800 wireless call is received, MSC 10 analyzes the dialed digits, allocates to the call the dedicated SS7 trunk resource, and sends an ISUP initial address message (IAM) to a SCP 16 over a SS7 STP link 18. SCP 16 analyzes the destination point code (DPC) in the IAM ISUP message and routes the message internally to a translator 20 which handles #800 destination point codes. Translator 20 examines the "called number" parameter of the IAM message, extracts the final destination from a database, overwrites certain IAM parameters, allocates a call detail record (CDR) 22 for the call, and forwards a modified version of the IAM message back to MSC 10 over STP link 23.

Referring to Fig. 1A, the MSC (or SSP) 10 sends IAM1 to the SCP over the signaling path associated with the first segment 24 of the loop back trunk. The SCP returns IAM2 to the MSC/SSP using the signaling path for the second segment 26 of the loop back trunk. MSC/SSP 10 then sends IAM3 to the final end-office destination over public switch network 28. The IAM sent by MSC 10 (IAM1) is modified by translator 20 in SCP 16 into IAM2 , and IAM3 is the form of the message sent out over the network, along with voice signals 30. Other signaling protocols, such as the multi -frequency (MF) signaling protocol, may be substituted for IAM3. As shown m the table below, the initial address message (IAM) includes the called party number, the calling party number, and the charge (billing) number.

IAM PARAMETER IAM1 IAM2 IAM3

Called Party #800 Directory Termination Termination Number Number Directory Number Directory

Number

Calling Party Mobile MIN or Override MIN or Override Number Identification Automatic Number ANI Number (MIN) Identification (ANI)

Charge (Billing) MIN MIN or Billing Min or Billing Number Number Number

As shown in Fig. IB, MSC/SSP 10 routes #800 calls differently based on the origin of the call, even if the called party address (C'dPA) is the same. The called party address and calling party address (C'gPA) are frequently the same for calls received from the SCP. For example, an originating service MSC may only check to see if the calling party is allowed to make a call, in which case the called party address and the calling party address will be the same for calls returned to the MSC from the SCP. When the MSC receives the call from the SCP, the MSC routes the call into the network, or terminates the call locally, but the MSC does not send the call back to the SCP unless a different Advanced Intelligent Network (AIN) service is requested.

Referring back to Fig. 1, MSC 10 analyzes the returned destination number in IAM2 and uses the new routing information to complete the call. The MSC processes the modified IAM message as a new call. For example, if the destination is a local intra-LATA (local access transport area) number, the traffic is terminated at the LEC 32 or other certified local exchange provider. If the destination is an inter-LATA POTS (plain old telephone service) number, the traffic is routed to an interexchange carrier (IXC) 34 for completion. If the destination is a 1+800 number, the MSC sends the call to the LEC (or other local carrier) which queries the national SMS/800 system database 36 and delivers the call to the appropriate carrier (e.g., MCI 1+800 numbers to MCI and AT&T 1+800 numbers to AT&T) .

The loop back voice trunk stays up for tne duration of the call and normal ISUP trunk signaling messages associated with call set-up and tear-down are processed for the connection. These messages include (but are not limited to) address complete message (ACM) , suspend message (SUS) , release (REL) , and release complete (RLC) . As each message is propagated through the two segments of the call (from the MSC to the SCP and back) , the point codes are manipulated to continue "fooling" the MSC into treating the messages sent by the SCP as service switching point (SSP) messages. The call state and the call detail record are updated with each related message until the call is finished.

At the end of the call, the SCP forwards the CDR to a store-and- forward adjunct processor for storage until requested by an off-line billing center. MSC 10 also makes a call detail record for the call so that the wireless carrier can bill air time charges to the enhanced service provider bringing reverse-billed wireless service to the marketplace (Toll Free Cellular (TFC) ) . The off-line billing center creates billing records that are used by TFC to invoice the #800 service subscriber for the wireless air time and other charges. This makes the call free of any charges to the wireless user - a true toll and air time free call. The information flow between the mobile switch center (MSC) , the service control point (SCP) , and the public network interexchange carrier (IXC) is shown schematically for two different calling situations in Figs. 2 and 2A. The final destination of the call is not placed into the message until after the translator 20 running on the SCP is involved in the SS7 ISUP message flow and controls the way in which the call will be routed. All of the ISUP SS7 messages related to a #800 call are therefore routed through the SCP, allowing the translator to track the status of the call from beginning to end. As mentioned above, the messages processed by the translator include the initial address message (IAM) , the exit message (EXM) , the address complete message (ACM) , the answer message (ANM) , the release message (REL) , and the release complete message (RLC) .

Referring to Fig. 2, in a successful call set-up and release, the MSC receives the call from the calling party and sends an initial address message (IAM1) to SCP 16. The translator 20 (Fig. 1) in the SCP modifies the initial address message and sends IAM2 to the MSC, which forwards the message along as IAM3 to the final destination over the public switching network When an IXC is involved (38) , the LEC sends (via the MSC/SSP) to the SCP an EXM signal which is decoded and processed by translator 20; the SCP forwards the EXM signal to the MSC. When the final destination is ringing, the IXC sends ACM through the network to alert the calling party. When the call is answered (42) , the IXC sends ANM through the network to connect the calling party to the called party. When the calling party clears (44), the MSC sends REL through the network to the IXC to remove the switch path and disconnect the called party at the final destination; the MSC also sends a disconnect acknowledgement to the calling party. When the called party is disconnected (46) , RLC is sent through the network, and the MSC disconnects the calling party (48) .

Referring to Fig. 2A, in an unsuccessful call setup and release, the MSC receives the call from the calling party and sends an initial address message (IAM1) to SCP 16. The translator 20 (Fig. 1) in the SCP modifies the initial address message and sends IAM2 to the MSC, which forwards the message along as IAM3 to the final destination over the public switching network. When an IXC is involved (38) , the LEC sends EXM (via the MSC/SSP) to the SCP which is decoded and processed by translator 20; the SCP forwards the EXM signal to the MSC. When the final destination is ringing (40) , the IXC sends ACM through the network to alert the calling party. If the call cannot be accepted (50) , the IXC sends REL (with a cause indicator) back through the network. The MSC then sends an indication to the calling party that the call could not be accepted (52) ; this indication is terminated when the calling party hangs up When the switch path has been removed, the MSC sends RLC to the IXC to release the node (54) . The following information may be accessed by translator 20 from the associated database server: customer #800 information; originating point code information; market information; wireless carrier identification information; and customer and #800 number status information. Depending on the service purchased by the subscriber, the #800 number translation may vary. For example, the translated number may or may not vary by market, as shown in the table below.

#800 Number Market 1 Market 30 Market N

#800-225-2121 1-800-225-2121 1-800-225-2121 1-800-225-2121

#800-688-5000 1-415-364-9200 1-312-565-7272 1-718-368-5000

#800-1234 1-800-689-5300 1-800-456-1000 1-800-456-1000

#800-4547 1-209-626-8900 1-212-838-9090 1-718-334-8989

As shown in the table above, the #800 service subscriber may subscribe to a #800 number followed by 4 or 7 digits. The 4 -digit numbers can be re-used m different markets by the same or different customers, whereas the 7 -digit numbers can mirror the same customer's 1+800 number across one or more markets. Since the ISUP protocol requires 10-digit numbers, 4- digit #800 numbers (800-XXXX) must be padded with 3 additional digits. The padding can be added in front of the 800 (e.g., 005-800-XXXX with 005 as padding) or m the NXX field of the 10-digit number scheme (e.g., 800- 005-XXXX with 005 as padding) . The padding can represent a market code (e.g., in the 000 to 199 range) .

Referring to Fig. 3, translator 20, running on SCP 16 (INS host system) , includes the following software components: request broker 60, SS7 gateway 62, measurements 64, audit controller 66, call control 68, statistics transport 70, CDR transport 72, provisioning 74, proxy 76, database server 78, charge accumulator 80, ISUP processing 82, and error handlxng 84. Messages are usually distributed between components through broker 60, but when inter-component traffic is high and real time processing capacity is important, a component can reference another component to make direct calls rather than passing the call through the broker (e.g., the call control component can directly reference the database server in certain situations) . The request broker records the location of the component servers and the kind of message each server receives. When a component requires access to a particular server component, it routes a request message to the broker, which in turn determines the message type and forwards the message to the requested server component. Components may act as clients and servers. Message routing via the broker allows a component server to run the same process or a separate process without affecting how a client interacts with a server Components have a common interface, making it relatively easy to integrate a new component into the system. When the translator first starts up, each component registers with the broker to make its services available. When a component registers, it constructs a registration message that contains the type of service this component provides to the componen .

Incoming and outgoing ISUP messages are delivered to and from the translator from the SS7 front-end (ST- 2000) over the message transfer system (MTS) of the host system. Information passes into and out of translator 20 through gateway 62, which converts the format of received messages between the internal message format (parcels) and external message formats. Provisioning input and output is routed to the application over the host's pathway facility which monitors an RS 232 serial port 86 Billing and statistical data (in the form of call detail records) are delivered to external store-and- forward devices 88, 90 via x.25 link access protocol balanced (LAPB) ports. Other inputs and outputs are used to transfer data to and from storage disks 92, store CDRs to a file during link outages, and report errors to the host error reporting and alarm distribution (ERAD) system.

Referring to Fig. 4, an ISUP message received by the SCP is processed as follows. The SS7 message is received by gateway 62 from the SCP front end (100) . The gateway routes the message to broker 60, which forwards the message to ISUP processing 82 (102) . ISUP processing decodes the message and routes the decoded message back to the broker, which in turn routes the decoded message to call control 68 (104) . Call control modifies certain message parameters and returns the modified message to the broker, which forwards the message to ISUP processing 82 for encoding (106) . After the message is encoded, the message is sent to gateway 62 by the broker (108) , and finally to the SCP front end (110) . The call control also sends a call answered call detail parcel to the charge accumulator by the broker (112) Finally, all components return control to their respective callers and the translator returns control to the operating system and waits for the next input message.

Call control component 68 receives decoded ISUP parcels from ISUP processing component 82 and determines whether to send the parcels to the second leg of the voice trunk loop (using the ISUP processing component to encode and send the parcel) after modifying certain parcel fields or whether to send the parcels to charge accumulator 80. The call control component is implemented as a finite state machine. The call control component maintains records for each active call on any trunk (circuit identification code - CIC) connecting the SCP with any SSP/MSC in the database; these call records contain general data that identifies the call including the call state, which identifies the parcels that have been received. The call control component is driven by the receipt of parcels. For example, referring to Fig. 5, call control performs the following steps when an initial address message (IAM) is received. Call control extracts the originating point code (OPC) from the IAM (120) and accesses the database for that OPC to extract market, ANI override number, padding information, and wireless carrier of the SCP (122) . Call control extracts the called number from the IAM (124) , removes any padding from that number (126) , and uses the unpadded called digits and the market of the OPC to obtain from the database the destination number for the call (128) . If the IXC is needed to complete the call (130) , call control uses the destination number to obtain information from the database pertaining to the IXC carrier. Call control creates a " forward- IAM" parcel to be sent to the SS7 processing component by cloning the received IAM parcel (132) . If required, call control replaces or adds the billing number field in the forward- IAM parcel with the billing number (134) and replaces the calling party number with the ANI override number (136) . The call control also replaces the called number with the destination number and stores the carrier information (138) . Call control then sends the forward-IAM parcel to the SS7 processing component (140). Call control creates a new call parcel for the charge accumulator, stores the OPC and the CIC of the incoming trunk and stores the received digits for the calling party, the called party, the market, and the wireless carrier identification number (142) . Call control sends this parcel to the charge accumulator. Finally call control creates and stores a call record for the SPC/CIC combination for the call.

Figs. 5A and 5B, show the flow of ISUP messages through the different translator components. Fig. 5A shows the flow of information under normal conditions. Fig. 5B shows the flow of information when the called number is out of service (OOS) , or if the subscriber is suspended, in which case a REL message is sent from call control back to the originating MSC trunk with an appropriate reason code; an RLC is expected back from the trunk. If the calling number is not found in the translator database, the appropriate cause value is indicated in the REL parcel .

When an exit message (EXM) is received, call control updates the call state and sends a forward parcel to the SS7 processing component for transmission to the calling SSP/MSC. Call control then sends a carrier- connected parcel to the charge accumulator.

When an address complete called party connected parcel (ACM without cause value) is received, call control updates the call state and returns the ACM parcel to the SS7 processing component for transmission to the SSP/MSC. Call control then sends a "called party connected" parcel to the charge accumulator. When an address complete called party not connected parcel (ACM with cause value) is received, call control updates the call state and extracts the reason for connection failure from the parcel. Call control sends that reason in a connection failed parcel to the charge accumulator. Call control then returns the ACM parcel to the SS7 processing component for transmission to the calling SSP/MSC.

When an answer parcel (ANM) is received, call control updates the call state and returns the ACM parcel to the SS7 processing component for transmission to the calling SSP/MSC. Call control then sends a "call answered" parcel to the charge accumulator.

When a release parcel (REL) is received, call control updates the call state and sends a forward parcel to the SS7 processing component for transmission over the second leg to the SSP/MSC. Call control then sends a call disconnected parcel to the charge accumulator. If the release parcel came from the called party, call control also sends a "call ended" parcel to the charge accumulator.

When a release complete parcel (RLC) is received, call control updates the call state and sends a forward parcel to the SS7 processing component for transmission over the second leg to the SSP/MSC. If the release complete parcel came from the called party and no release parcel was received earlier from that party, call control also sends a call ended parcel to the charge accumulator. Finally, charge control removes the call record for the SCP/CIC combination. Call control also performs error checking.

The charge accumulator maintains in the database one call detail record for every call that is currently active on any trunk (switching circuit with an associated CIC) connecting the SCP with any SSP/MSC in the network. The charge accumulator is driven by the receipt of parcels from the call control component. For example, when a new call parcel is received, the charge accumulator determines whether a call detail record exists for the SCP/CIC combination. If a call detail record exists the charge accumulator packs the call detail record in a CDR parcel and sends this parcel to CDR transport component 62 for shipping to the billing center. The charge accumulator then removes the call detail record for this SPC/CIC combination. If a call detail record does not exist, the charge accumulator creates a new call detail record with non- initialized values and sets certain fields in this record. By accessing the database, the charge accumulator obtains the identification number of the CPU from the host operating system (OS) and the identification number of the SCP; the charge accumulator fills in these fields as well as the origination date and time. The charge accumulator then extracts from the parcel the OPC, CIC, market, wireless carrier, the received calling party number and the received called party number, and stores this information in the new call detail record. The charge accumulator accesses the data base to obtain the type and identification number for the OPC and stores this information in the CDR; the CDR is then saved and indexed under this SPC/CIC combination. If other parcels are received and a call detail record does not exist for the received SCP/CIC combination, the charge accumulator reports an error and ignores the input. Otherwise, the charge accumulator stores the received parcel information in the appropriate field of the call detail record. For example, when a terminator identified parcel is received, the charge accumulator extracts the billing number, ANI number, destination number, and the IXC carrier information, if required, and stores this information in the call detail record.

CDR transport component 72 receives call detail record (CDR) parcels from charge accumulator 80 in the internal parcel format. The CDR transport converts these records into a suitable external format for billing purposes. The converted records are temporarily stored in a local buffer, and later stored in adjunct external general store and forward processing units 88, 90.

Measurements component 64 receives parcels that increment application wide counters, including counters maintained by a provisioning platform 124 (Fig. 3), counters incremented by the translator, and counters derived from the first two counters.

The translator runs on provisioning platform 12 . All access to application data is provided through command line provisioning interface 64, including file transfer access for log and dump files from the host system to any client. All data sent to or received from the provisioning interface is in a simple stream via ASCII protocol. Log and dump files will contain some formatting information to identify name of file, start of file, line breaks, and end of file. Menus for selecting among basic provisioning functions (commanding, listing, dumping) are provided. The commanding interface itself is keyboard driven. Error handling component 84 logs abnormal conditions detected by call processing and service logic. The main types of detected errors are generic software errors, subscriber data inconsistency errors, and application detected errors. The error handling component gathers error information and issues reports for each error with an assigned severity level .

If services are required that are not offered by any of the local components, proxy component 76 is used to interface with external processes 126 (Fig. 3) . Information is stored in the following separate files: customer record; translation terminal record; adjacent SPC record; SCP record file; login-password file; and numbering plan area (NPA) validation file. Customer records consist of a customer identification number, a #800 number, a market identifier, a translation number, and an indication of the status of the #800 number and the customer in the identified market. Translation terminal records consist of data that can be placed in the response SS7 message, such as a destination number, billing number, carrier identification number and information for call handling. Adjacent SPC records include data that describes each MSC/SSP connected to the #800 translator; such data includes information concerning the interaction between the translator and the MSC/SSP, such as the signaling point code of the MSC/SSP, the market identification number for the MSC/SSP, a default ANI for the MSC/SSP, the identification number and the switch type of the MSC/SSP, the MSC/SSP protocol, the wireless carrier owner of the MSC/SSP, the IAM calling number padding scheme used for the MSC/SSP, and other call processing information. The SCP record file contains information about the SCP platform (e.g., an identifier for the SCP) and its position in the SS7 network (e.g., originating side signaling point code and terminating side signaling point code) ; this information is used for generating the call detail records and for generating routing information. The login-password record data (login password, security level) is used to identify and authenticate provisioning interface users. The NPA validation records are used by the provisioning part of the translator for validating the NPA parts of the called numbers that are being provisioned into the #800 translator database.

Other embodiments are within the scope of the claims.

Referring to Fig. 6, the wireless carrier processes #800 traffic using a gateway switch 150 (a service switching point that links the MSC to the network), which has ISUP handling capability. When a #800 wireless call is received the wireless carrier's mobile switch center 152 analyzes the dialed digits and routes the call to a trunk group that is directly connected to the gateway switch using, e.g., a T-l connection 154. The MSC can use m-band or out-of-band signaling. Gateway switch 150 allocates to the call a SS7 trunk resource 156 and sends an ISUP initial address message (IAM) to SCP 16 over SS7 STP links 158. SCP 16 analyzes the destination point code (DPC) in the SS7 ISUP message and routes the message internally to translator 20 which handles #800 destination point codes. As described above, translator 20 examines the IAM message called number parameter, extracts the real destination from a database, overwrites pertinent parameters of the IAM, allocates a call detail record (CDR) 160 for the call, and forwards the modified IAM message back to gateway switch 150. Gateway switch 150 analyzes the returned destination number and uses the new routing information to complete the call . The gateway switch processes the modified IAM message as a new call. For example, if the destination is a local intra-LATA (local access transport area) number, the traffic is terminated over LEC 32 or other certified local exchange provider. If the destination is an inter-LATA POTS (plain old telephone service) number, the traffic is routed to an interexchange carrier (IXC) 34 for completion. If the destination is a 1+800 number, the gateway switch sends the call to the LEC (or other local carrier) which queries national SMS/800 system database 36 and delivers the call to the appropriate carrier (e.g., MCI 1+800 numbers to MCI and AT&T 1+800 numbers to AT&T) .

Still other embodiments are within the scope of the claims.

Referring to Figs. 7 and 7A, in another wireless call processing scheme, a wireless switch l^C (e.g., a MSC) , which does not have ISUP handling capability, receives a wireless call from a wireless user 172 and processes the call as follows. When a #800 wireless call is received, the wireless switch passes the call to a point of presence (POP) 174 over a designated TI line. In this embodiment, POP 174 then forwards the call to a switch provider 176, which processes the call and translates the calling party number into a standard telephone number. If the translated number is an mtra- LATA number, the call is passed to the local PSTN and connected to the called party 178 If the translated number is an inter-LATA number, the call is routed to an IXC 180 for termination to a called party 182 outside the LATA. A call detail billing record is created for each call. As shown m Fig. 8A, the call records are used to generate subscriber bills 184 and to generate air time payments 186 for wireless carriers.

In prior wireless call processing schemes, a wireless user would be billed for air time charges regardless of whether the user dialed a 1+800 toll free number. The above-described invention, on the other hand, provides a wireless call processing scheme in which wireless users can call subscribers of a toll free wireless service using preselected wireless numbers whereby all charges associated with the call, including wireless air time charges, are billed to the service subscribers rather than to wireless users. In the particular aspect described in connection with the embodiment of Figs. 1-6, the invention makes advantageous use of an MSC s existing ISUP capabilities to switch wireless calls in a novel way that enables call detail records to be generated from ISUP call signals for use in billing #800 customers.

What is claimed is:

Claims

1. A system for processing a wireless call signal received from a calling party and directed to a called party, the system comprising a translator for incorporating a called party destination code into the wireless signal when the received wireless call signal has a preselected routing code.

2. The system of claim 1 wherein the translator replaces a calling party identifier in the received wireless call signal with an identifier for a bill- receiving party different from the calling party.

3. The system of claim 1 wherein the translator is coupled to a service control point .

4. The system of claim 1 further comprising a processor for routing the call signal to the translator when the received wireless call signal has the preselected routing code.

5. The system of claim 4 wherein the processor is coupled to a wireless switch.

6. The system of claim b wherein the wireless switch includes a switching circuit dedicated to handling wireless call signals having the preselected routing code .

7. The system of claim 4 wherein the processor receives the wireless call signal from the calling party, incorporates an identifier for the wireless switch into the wireless call signal, and forwards the received call signal with the incorporated switch identifier to the translator when the received wireless call signal has the preselected routing code, and the translator includes a controller for determining the wireless switch from the received wireless call signal identifier received from the wireless switch.

8. The system of claim 7 further comprising a database storing called party destination codes for wireless call signals having the preselected routing code .

9. The system of claim 7 wherein the processor incorporates one or more padding digits into the received wireless call signal for efficiency of processing associated with fixed-length called party numbers.

10. The system of claim 9 wherein the translator removes the padding digits to determine the called party destination code.

11. The system of claim 1 wherein the translator is configured to translate wireless call signals encoded according to the signaling system 7 protocol.

12. The system of claim 11 wherein the translator is configured to translate wireless call signals encoded according to the ISDN Subscriber User Part (ISUP) of the signaling system 7 protocol.

13. A method for processing a wireless call signal received from a calling party and directed to a called party, the method comprising the steps of receiving a wireless call signal from a calling party, determining a destination code for the called party based on the received wireless call signal when the received wireless call signal has a preselected routing code , and incorporating the called party destination code into the wireless call signal, whereby the call between the calling party and the called party is completed based on the called party destination code incorporated into the wireless call signal .

14. The method of claim 13 further comprising the step of replacing a calling party identifier in the received wireless call signal with an identifier for a bill -receiving party different from the calling party.

15. The method of claim 13 further comprising the step of routing the call signal to a translator for incorporating the called party destination code into the wireless call signal when the received wireless call signal has the preselected routing code.

16. The method of claim 15 further comprising the step of incorporating an identifier for the wireless switch into the wireless call signal and forwarding the received call signal with the incorporated switch identifier to the translator when the received wireless call signal has the preselected routing code.