Call initiation for legacy mobile circuit switched domain wireless systems

[0001] This application relates to co-pending U.S. provisional patent application Serial No. 60/362,607, filed Mar. 8, 2002, and entitled Call Invocation to an Idle MS on Another MSCE, the contents of which are incorporated by reference.

[0002] The present invention relates to the handling of legacy circuit-switched domain calls in a packet-switched telecommunications protocol and, more particularly, to call initiation in the mobile network where interworking between the circuit-switched and packet-switched network is performed.

[0003] In circuit-switched (CS) mobile telecommunications systems, a mobile station (MS) sends a signal or message, which is picked up by a base transmitting station (BTS) and then routed by a base station controller (BSC). The signal or message is forwarded by the BSC to an associated mobile switching center (MSC), for routing to the appropriate destination, for example, a public switched telephone network (PSTN) or other telecommunications node or network).

[0004] To increase multimedia and Internet capabilities, and for other reasons, most mobile telecommunications systems are being migrated from use of a circuit-switched core network to use of a packet-switched (PS) protocol network. Systems using a PS network nevertheless typically needs support for handling calls routed through non-PN systems (for example, PSTN). Ideally, support for existing mobile stations (MS's), for example, call initiation, call termination, in a PS signaling network environment will operate in a manner transparent to the user. Furthermore, ideally, such support should also permit supporting new features and capabilities. However, end users are often stymied by a lack of standardization to enable such migration from circuit-switched networks to packet-switched mobile networks to continue.

[0005] Therefore, what is needed is call initiation between a circuit switched network and a PS network for communicating with a mobile station.

[0006] The present invention provides a first network employing circuit control protocol. A second and third network employs packet data control protocol. A packet call control entity has an interworking engine. The interworking engine is employable to receive communication from the first network and forward the communication to the third network, through employment of a conversion of the circuit control protocol to the packet data control protocol.

[0007] For a more complete understanding of the present invention, and the advantages thereof, reference is now made to the following description taken in conjunction with the accompanying drawings, in which:

[0008] FIG. 1 is a functional block diagram depicting a PS network, having a Legacy Mobile Station Domain Support (LMSDS), in communication with another PS network having a LMSDS;

[0009] FIG. 2 is a block diagram depicting a protocol stack for reference point zz of FIG. 1; and

[0010] FIGS. 3A and 3B illustrate a nodal analysis depicting an example of call initiation by a mobile station.

[0011] Turning now to FIG. 1, a system for handling circuit-switched operations in a telecommunications system having a PS network is depicted. In the following discussion, numerous specific details are set forth to provide a thorough understanding of the present invention. However, it will be obvious to those skilled in the art that the present invention can be practiced without such specific details. In other instances, well-known elements have been illustrated in schematic or block diagram form in order not to obscure the present invention in unnecessary detail. Additionally, for the most part, details concerning CDMA systems and the like have been omitted inasmuch as such details are not considered necessary to obtain a complete understanding of the present invention, and are considered to be within the skills of persons of ordinary skill in the relevant art.

[0012] It is further noted that, unless indicated otherwise, all functions described herein are performed by a processor such as a computer or electronic data processor in accordance with code such as computer program code, software, and/or integrated circuits that are coded to perform such functions.

[0013] FIG. 1 illustrates first and second PS networks 1 and 2 in communication with one another across reference points yy and zz. Network 1 includes Legacy Mobile Station Domain Support (LMSDS) 11, which includes a home location register emulator (HLRe) 15 and a PS call control entity, such as a mobile switching control emulator (MSCe) 17. An LMSDS can be generally defined as support for allowing a standardized conversion between circuit-switched data and packet-switched data for the transmission on a mobile network.

[0014] In FIG. 1, for forward and backward compatibility purposes (for example, to allow PS performance in telecommunications services without sacrificing the requirement for the transparent handling of legacy circuit-switched MS calls), the functionality of a circuit-switched MSC is divided into two functionally distinct entities. One functionally distinct entity is the MSCe 17, which is responsible for call signaling, both for packet and non-packet communications. Signaling can be generally defined as the determination of the routing path from one entity to another entity. Another functionally distinct entity is the MGW 7, which is responsible for the transmission of the bearer traffic. Bearer traffic can be generally defined as the data that is routed by the signaling. The MSCe 17 is the control entity that converts non-PS call signaling (for example, PSTN) to PS call signaling (and vice-versa), and controls the call routing through the PS network 1 and interacts with the MGW 47 of the network 2.

[0015] The division of functions into separate functional entities separated by a PS protocol interface facilitates the use of open standards for managing traffic and signals in a PS environment, such as Megaco, SIP, IOS, and circuit-switched signal protocols such as SS7. The present invention facilitates specific functionality within the MSCe, between the MSCe and the MGW and among other MSCe's on other networks. In FIG. 1, network 2 has the LMSDS 12, which includes an HLRe 31, and an MSCe 45, which controls its MGW 47.

[0016] The MGW 7 has an interface between the packet environment of the PS network 1 and the circuit switched environment of the PSTN 44 for bearer traffic, when equipped with circuit capabilities. The MGW 7 can provide vocoding and/or transcoding functions to the bearer traffic. The MGW 7 can also provide modem functions to convert digital byte streams to and from audio modem tones placed on circuits, and can provide the capability to terminate Point-to-Point Protocol (PPP) connections. It also provides policy enforcement relative to its activities and resources.

[0017] The MGW 7 supports the bearer aspects and bearer switching fabric, tone, announcement and bridging capabilities. In addition, the MGW 7 supports the PS bearer for actual call delivery to other LMSDS's across reference point/interface yy and provides bearer support for connectivity to the PSTN 44. The MGW 7 can use PS protocol signaling from the MSCe 17 for tones and announcements control, for bearer establishment and bridging control functions. In FIG. 1, the LMSDS 11 is employable to provide support for the following interfaces; MGW to radio access network (RAN) voice bearer (27), MGW to RAN circuit data bearer (27), MGW to PSTN Bearer (34), MSCe 17 to MGW 7 signaling (39), and MGW to MGW PS bearer (yy). An access network, such as access network 42 or 43, can comprise a base station, and can be part of the RAN.

[0018] The MGW 7 also can have the following capabilities: It terminates bearer channels from the PSTN 44 on interface 34, bearer channels from the radio network on interfaces 27 and media streams from a packet network on interface yy; it supports voice and circuit data media streams on these network terminations; it provides switching of the bearer channels by connecting media streams from one set of network terminations to another set of network terminations; and it converts media in one type of network termination to the format required in another type of network termination.

[0019] The MGW 7 has the ability to connect to the PS protocol environment of another PS network, for example, network 2, as well as the circuit-based environment of the PSTN 44. Therefore, the resources provided by the MGW 7, including transcoding resources, can be used to support bearer channels that are contained entirely within the PS environment.

[0020] For call initiation from network 1 and network 2, the MSCe 17 and MSCe 45 generally cooperate to find the called party and create a path. The MGW 7, on the other hand, supports conversion of a non-PS traffic bearer to a PS traffic bearer and transports the PS traffic bearer to the final destination and vice versa. In other words, the MGW 7 performs the actual encapsulation between circuit-switched data to packet-switched data, and the MSCe 15 performs the mapping of the routing information between circuit-switched data and packet-switched data. To perform its functions, the MSCe 17 can be capable of communicating with the PSTN network using circuit-switched communications protocols and with an MGW 7 and MGW 47 (for example, through employment of a device control protocol, such as the Megaco protocol), and with Home Location RegistersNisiting Location Registers (for example, using TIA/EIA-41 protocols).

[0021] The LMSDS 11 includes network entities HLRe 15, which functions as a home location register emulator, and MSCe 17, which functions as a mobile switching control emulator. Network 1, with its included network entities, and their associated reference points, comprises a wireless PS network. Network 2, with its included network entities, and their associated reference points, also comprises a wireless PS network. The entities HLRe's 15, 41, MSCe's 17, 45 and MGW's 7,47, and reference points/interfaces 38,39, yy, and zz can employ communication protocols based on existing open-standards.

[0022] The MSCe 17 and MSCe 45 further have an interworking function or interworking engine. Generally, the interworking engine is employable as a command center mapping of routing information within the MSCe when transmitting data from a circuit-switched network to a packet-switched network. For the purposes of mapping, there can be an interworking engine in the MSCe's of both network 1 and network 2.

[0023] The network architecture model depicted in FIG. 1 is a functional block diagram. As used herein, a network entity represents a group of functions, not necessarily a physical device. The physical realization is an implementation issue. A manufacturer can choose a physical implementation of network entities, either individually or in combination, as long as the implementation meets the functional requirements. Sometimes, for practical reasons, the functional network entity is a physical device. The Mobile Station (MS) is an example of a functional entity that is also a physical device.

[0024] As used herein, a reference point is a conceptual point that divides two groups of functions. It is not necessarily a physical interface. A reference point can become a physical interface when the network entities on either side of it are contained in different physical devices. A reference point or interface could be standardized, but not necessarily. A reference point exists when two network entities are interconnected through one signaling or bearer stream point. Reference points identify that a logical relationship exists between two network entities. An interface is generally defined across a specific reference point by defining the protocol and data exchanged between the entities. One or more interfaces can be defined for each reference point in the LMSDS system. The points/interfaces 38, 39, yy, zz can employ communications protocols based on existing open-standards.

[0025] The LMSDS system 11 comprises a collection of the network entities, the HLRe 15 and the MSCe 17. The LMSDS system 11 can support interfaces using open-standards signal communications protocols at the indicated reference points. These can be the ANSI-41 network signaling, PSTN signaling, media gateway signaling, radio access network signaling, and LMSDS system signaling.

[0026] The LMSDS system 11 has the capability of processing mobility management and call control messages from the ANSI-41 network and mobile stations for mobile originated and mobile terminated calls. It controls the establishment of voice bearers between access network 42 and MGW 7, and between access network 43 and MGW 47. The LMSDS 11 and LMSDS 12 also are responsible for establishment of voice bearers between MGW 7 and PSTN 44 and emulate the functionality of the HLRe's 15 and 41, respectively. If requested, the LMSDS 11 performs authentication of mobile stations, and performs call delivery to another LMSDS 12 of network 2 across reference point zz, using an open-standards PS protocol, such as SIP.

[0027] The LMSDS systems 11 and 12 perform the call control, mobility management and service management functions to provide support for non-PS (that is, legacy) mobile station networks. The LMSDS systems 11 and 12 are responsible for the control of call origination and call termination of both the circuit and packet switched networks. The LMSDS 11 and 12 terminate the user-network signaling and convert it into the appropriate network-network signaling. The LMSDS 11 and 12 also control the connections for bearer channels in MGW 7 and connections to a base station controller (BSC) (not shown) in the access network 42.

[0028] The MSCe 17 is responsible for one or more call control functions. The MSCe 17 uses PS signaling to control the MGW 7 across reference point 39 and to allow the MGW 7 to communicate with MGW 47 of network 2 across reference point/interface yy. The MSCe 17 translates a received E.164 number into an IP address when IP bearer is to be used.

[0029] The HLRe 15 is a network entity that supports non-PS Terminals (legacy MS's) in a PS network. The HLRe 15 can have a PS signaling interface. The HLRe 15 supports roaming to the other PS networks. The HLRe 15 also manages the subscriber profile for both voice services (for example, Call Forwarding, Three Way Calling, Message Waiting Notification) and data services (for example, Priority). Subscriber profile information can be accessed from the HLRe 15 or can be downloaded to a serving system as needed.

[0030] The HLRe 15 manages subscriber location and/or accessibility information. This includes updating the dynamic subscriber information database with current domain information (for example, MSCe address) and with MS status information (for example, SMS pending flag). The HLRe 15 also interacts with the location database to update or retrieve current location information.

[0031] The LMSDS 11 supports the following interfaces or reference points. The MGW to radio access network circuit data bearer (27) is supported. The MGW to PSTN bearer (34), MSCe 17 to MGW 7 signaling (38) and media gateway to media gateway PS bearer (yy) interface or reference points are also supported.

[0032] The MGW 7 is employable to provide one or more packet signal switching capabilities. In FIG. 1, the MGW can receive bearer channels from the PSTN on interface 34, bearer channels from the radio network on interfaces 27 and media streams from a packet network on interface yy. The MGW 7 also supports voice and circuit data media streams on these network terminations, provides switching of the bearer channels by connecting media streams from one set of network terminations to another set of network terminations, and converts media in one type of network termination to the format required in another type of network termination.

[0033] Open-standards signal communications protocols can be used across its reference points/interfaces. These include, for example, the media gateway control protocol (Megaco) and SIP, a packet-switched data control protocol. Using these standardized reference point/interfaces allow the interworking function to communicate with the PSTN and the MGW of the first mobile network with the entities of the second mobile network in a standardized manner using packet switched protocol.

[0034] Media gateway control protocol, also known as H.248 or Megaco, is an open-standards protocol for handling the signaling and session management needed during a multimedia conference. Megaco can be used to communicate signals between the MSCe and the MGW.

[0035] Session initiation protocol (SIP) is a request-response PS protocol that establishes call parameters at either end of the communication, and handles call transfer and termination. SIP can be employed when communicating between the MSCe 17 and the MSCe 45; that is, from the first mobile network to the second mobile network, along interface zz. SIP is an open-standards PS protocol and participants are identified by SIP URLs. Requests can be sent through any transport protocol, such as UDP, SCTP or TCP. SIP determines the end system to be used for the session, the communication media and media parameters, and the called party's desire to engage in the communication. Once these are assured, SIP establishes call parameters at either end of the communication, and handles call transfer and termination. SIP is also used for initiating an interactive user session that involves multimedia elements such as video, voice, chat, gaming, and virtual reality.

[0036] Like HTTP or SMTP, SIP works in the Application layer of the Open Systems Interconnection (OSI) communications model. The Application layer is the level responsible for ensuring that communication is possible. SIP can establish multimedia sessions or Internet telephony calls, and modify or terminate them. The protocol can also invite participants to unicast or multicast sessions that do not necessarily involve the initiator. Because the SIP supports name mapping and redirection services, it makes it possible for users to initiate and receive communications and services from any location, and for networks to identify the users wherever they are.

[0037] Interface yy is a PS bearer interface between MGWs operating using IP. Interface 39 is used for the MGW 7 to communicate to the MSCe 17. Interface 39 provides PS signaling, control bearer resource assignment and bridging from the MSCe 17 to the MGW 7.

[0038] Turning now to FIG. 2, illustrated is an OSI protocol stack for interface zz. Generally, the interworking engine of the MSCe 17 allows for the communication of signals from the interface 13 through the interface zz. Interface zz provides PS signaling control employed by the interface yy. This interface is between MSCes. Interface zz is a signaling interface that is based on SIP-T as defined in IETF-2 and IETF-3. SIP can be employ either TCP as defined in IETF-5, UDP as defined in IETF-6 or SCTP as defined in IETF-4. IP as defined in IETF-7 is used as the network protocol. In FIG. 2, layer 1 represents the physical layer of the OSI protocol stack, and can be a wire, or can be wireless. Layer 2 represents data link layer. Layer 3 represents the network layer. It is within the layer 3 that the SIP is employed.

[0039] Turning now to FIG. 3, disclosed is an example of call initiation and employment of the MSCe 17 and the MGW 7 to initiate a call from a circuit-switched network to a mobile network using IP routing information. In FIG. 3, the dotted arrows illustrate an interface that uses the open-code Megaco or SIP, thereby allowing for the standardization of communication between the PSTN and the mobile network for packet-switched data. In onehe interworking engine of the MSCe is employed to determine the series of call signals to allow communication between the PSTN and network 2, a mobile network, using packet-switched routing protocols. Generally, the interworking engine encapsulates and maps circuit-switched calls from the PSTN and then forwards them to network 2, a mobile network, in packet-switched format.

[0040] In flow 301, a call origination and the dialed MS address digits (that is, directory numbers) are received by the originating MSCe 17 from the PSTN 44 through employment of a circuit control protocol, such as SS7. In flow 302, the originating MSCe 17 sends a LOCREQ to HLRe 15 associated with the MSCe 17. This association can be made through parsing the dialed address digits.

[0041] In flow 303, if the dialed MS address digits are assigned to a legitimate subscriber, the HLRe 15 sends a ROUTREQ to the VLR (not shown in FIG. 1) where the MS is registered. In flow 304, the VLR then forwards the ROUTREQ to the current serving MSCe 45. In FIG. 3, the MS has roamed within the domain in the Serving VLR and the MS reported its new location to that VLR through employment of the new serving MSCe 45. In FIG. 3, the Serving VLR can or can not report this change in location to the HLRe. In response to the ROUTREQ, the serving MSCe 45 consults an internal data structure to determine if the called MS is already engaged in a call on this MSCe 45.

[0042] In flow 305, the serving MSCe 45 allocates a TLDN (Temporary Local Directory Number) and returns this information to the VLR in the ROUTREQ. The serving MSCe 45 also states the timer TLDNAT (TLDN Acknowledgment Timer). In flow 306, the VLR sends the ROUTREQ to the HLRe.

[0043] In flow 307, when the ROUTREQ is received by the HLRe, it returns a LOCREQ to the originating MSCe 17. The LOCREQ includes routing information in the form of the TerminationList parameter, along with an indication of the reason for extending the incoming call in the DMD_RedirectionIndicator parameter. Then, the originating MSCe 17 translates the TLDN to an IP address.

[0044] In flow 308, the MSCe 17 establishes a context with an originating MGW 7as defined in IETF RFC (Megaco), a standardized protocol language. The Megaco message comprises two ADD commands. The first ADD command establishes a termination to the PSTN communication channel (for example, DSO on a T1 or E1 line) that corresponds to the incoming IAM (Initial Address Message) with a mode set to Receive Only. The termination is set to this mode for fraud prevention. The second ADD command establishes a termination for a bearer channel using RTP.

[0045] In flow 309, the originating MGW 7 replies to the Megaco message, also using Megaco. The reply IETF-8 message contains the local SDP from the originating MGW 7. The local SDP contains an IP address, a UDP Port number, and a list of Codes that the originating MGW 7 supports for sending and receiving.

[0046] In flow 310, the originating MSCe 17 sends an INVITE IETF-2 message to the Serving MSCe 45 containing the IAM message and the SPD for the originating MGW. The serving MSCe 45 employs the TLDN to make the association with the MSID received in the ROUTREQ message. In flow 311, after receiving an INVITE message, the serving MSCe 45 sends a PAGING REQUEST message to the BS (not shown in FIG. 1) to initiate a mobile terminated call setup scenario.

[0047] In flow 312, the BS constructs the Paging Response message, places it in the Complete Layer 3 Information message, and sends the message to the Serving MSCe 45. The BS can request the serving MSCe 45 to allocate a preferred terrestrial circuit. In flow 313, after receiving an INVITE message, the serving MSCe 45 establishes a context with a Serving MGW. The serving MSCe 45 can execute flow 311 and flow 313 substantially simultaneously (that is, they are parallel operations). The Megaco message comprises two ADD commands. The first ADD command establishes a termination to the BS communication channel (for example, DS0 on a T1 or E1 line with a mode set to sendrecv). The second ADD command establishes a termination for a bearer channel using RTP. The SDP-0 contains the IP address and UDP Port number for which the serving MGW is to send the RTP packages. The SDP-O also contains a list of Codes used for Codec negotiation.

[0048] In flow 314, the serving MGW replies to the Megaco message. The Reply message contains the local SDP for the serving MGW. The local SDP contains the RTP IP address, the RTP UDP Port number, and a list of Codes that is supported by both the originating MGW and the serving MGW. The list of Codecs can be in preferential order as per RFC 3261, an Internet standard. The Codes list can contain one or more Codes according to RFC 3261.

[0049] In flow 315, the serving MSCe 45 sends the originating MSCe 17 a 183 Session Progress IET-1 message containing SDP-S. In flow 316, the originating MSCe 17 sends a PRACK IETF-10 message to the serving MSC in response to the 183 Session Progress message. In flow 317, the serving MSCe 45 sends a 200 OK message to the originating MSCe 17 acknowledging the PRACK message. In flow 318, upon receiving the 183 Session Progress message, the originating MSCe 17 sends the originating MGW a Modify IETF-8 message to provide the RTP termination with the IP address and UDP port number to which to send RTP packages.

[0050] In flow 319, the originating MGW 7 selects the first Codec in the list supplied by SDP-S for the RTP bearer channel. If the first Code in the list is no longer available, the Reply message will contain an updated SDP-O, and Codec negotiation between the Originating MGW and the Serving MSCe continue (these steps are not shown in FIGS. 3A or 3B). The originating MGW sends a Reply message to the originating MSCe 17.

[0051] In flow 320, if the BS requested a preferred terrestrial circuit in the PAGING RESPONSE message (flow 312) and the serving MSCe 45 can support the terrestrial circuit, the serving MSCe 45 sends the serving MGW a Megaco message to change the established context. The Megaco message comprises a SUBTRACT command for removing the termination to the BS and an ADD command to establish a termination to the BS communication channel using the BS requested preferred terrestrial circuit.

[0052] In flow 321, the serving MGW acknowledges the Megaco message with a Reply message. In flow 322, the serving MSCe 45 sends an Assignment Request message to the BS to request assignment of radio resources after receiving a PAGING RESPONSE message (flow 312). In flow 323, after the radio traffic channel and circuit have both been established, the BS sends the ASSIGNMENT COMPLETE message to the serving MSCe 45. In flow 324, after sending the 183 Session Progress message (flow 315), the serving MSCe 45 sends an 18 (for example, 180 ringing) IETF-1 message to the originating MSCe 17.

[0053] In flow 325, the originating MSCe 17 sends an ACM (Address Complete Message) to the PSTN. In flow 326, the originating MSCe 17 sends a modify command to the originating MGW. The modify command modifies the PSTN communication channel to allow for both sending and receiving. In flow 327, the originating MGW acknowledges the Modify message with a Reply message.

[0054] In flow 328, the BS sends a CONNECT message to the serving MSCe 45 to indicate that the call has been answered at the MS. At this point, the call is considered stable in the conservation state. Although, in f FIG. 3, the CONNECT message can be received by the serving MSCe 45 anytime after flow 323.

[0055] In flow 329, after receiving the CONNECT message for the MS, the serving MSCe 45 sends a 200 OK message to the originating MSCe 17. The message acknowledges that the INVITE of flow 310 has succeeded.

[0056] In flow 330, the originating MSCe 17 sends an ANM (Answer Message) to the PSTN.

[0057] In flow 331, the originating MSCe 17 sends an ACK (acknowledgment message) to the serving MSCe 45. The ACK message is sent to confirm the reception of the final response (that is, 200 OK).

[0058] It is understood that the present invention can take many forms and embodiments. Accordingly, several variations can be made in the foregoing without departing from the spirit or the scope of the invention.

[0059] Having thus described the present invention by reference to certain of its preferred embodiments, it is noted that the embodiments disclosed are illustrative rather than limiting in nature and that a wide range of variations, modifications, changes, and substitutions are contemplated in the foregoing disclosure and, in some instances, some features of the present invention can be employed without a corresponding use of the other features. Many such variations and modifications can be considered obvious and desirable by those skilled in the art based upon a review of the foregoing description of preferred embodiments. Accordingly, it is appropriate that the appended claims be construed broadly and in a manner consistent with the scope of the invention.