IR 11)01011i0719111010 11111111111111101M
`11111111111110111111010
`
`(19) United States
`(12) Patent Application Publication (10) Pub. No.: US 2003/0217174 Al
`Nov. 20, 2003
`Dorenbosch et al.
`(43) Pub. Date:
`
`(54) ESTABLISHING AN IP SESSION BETWEEN
`A HOST USING SIP AND A DEVICE
`WITHOUT AN IP ADDRESS
`
`(75)
`
`Inventors: Jheroen P. Dorenbosch, Paradise, TX
`(US); Srinivas Miriyala, Fort Worth,
`TX (US)
`
`Correspondence Address:
`POSZ & BETHARDS, PLC
`11250 ROGER BACON DRIVE
`SUITE 10
`RESTON, VA 20190 (US)
`
`(73) Assignee: MOTOROLA, INC.
`
`(21) Appl. No.:
`
`10/147,586
`
`(22) Filed:
`
`May 15, 2002
`
`Publication Classification
`
`(51) Int. C1.7
`
` GO6F 15/16
`
`(52) U.S. Cl.
`
` 709/237; 709/226
`
`(57)
`
`ABSTRACT
`
`An apparatus and method for establishing an IP session
`between a host 105 using a session initiation protocol and a
`device or mobile station 103 without an IP address is
`described. The apparatus includes a network interface 405
`for receiving, via an IP connection, a session request that
`includes a host contact corresponding to the host and a
`device identifier corresponding to the device; a controller
`407 for parsing the session request to determine the device
`identifier; preparing a message for the device that includes
`the device identifier and the session request, and presenting
`the message to the network interface, the message to be
`delivered to the device via a non-IP connection and to result
`in the device obtaining a device IP address and sending an
`acknowledgment of the SIP session request that includes the
`device IP address.
`
`121
`
`139
`liAP OVER SMS
`
`103
`
`PDP CONTEXT
`
`1081
`TARGET MS
`[MS_IP_Add]
`
`1231
`SMS—GMSC
`SMS—IINMSC
`
`101
`125, \
`
`12 7-\
`
`109-N
`
`1111
`
`
`
`GGSN 1
`
`100
`
`135
`
`CONTACT1=sip:MS IP Add
`CONTACT2=sip:MSISDN @ SIR_name
`F_133
`
`DB
`
`'SIP INVITE
`h137
`
`113
`
`SIP h. 131
`REGISTRAR
`
`HOST
`
`1,—/05
`
`Apple Inc.
`Ex. 1011 - Page 1
`
`

`

`Patent Application Publication
`
` Jo I jaaqs
`
`17
`
`IV 17LILIZO/£00Z Sfl
`
`135
`
`121
`
`139
`--WAP OVER SMS
`
`103
`
`1231
`SMS—GMSC
`SMS—IWMSC
`
`107
`
`109-N
`
`101
`125 -\
`
`SM—SC
`
`127-\
`
`SIR
`
`CONTACT1=sip:MS IP Add
`CONTACT2=sip:MSTSDR@SIR2ame
`
`DB
`
`1"--133
`
` 1
`'SIP INVITE
`/77
`(- it
`
`SIP F 131
`
`
`REGISTRAR
`
`PDP CONTEXT
`141-i
`
`1081
`TARGET MS
`[MS_IP_Add]
`
`SGSN
`
`GGSN
`
`PACKET
`DATA NETWORK
`
`
`
`HOST 1,-105
`
`113
`
`100
`
`FIG. 1
`
`Apple Inc.
`Ex. 1011 - Page 2
`
`

`

`Patent Application Publication
`
` Jo z jaaqs
`
`17
`
`IV tLILIZO/£00Z Sfl
`
`103)
`TARGET MS
`203—Ki
`
`205
`
`109Th
`SGSN
`
`111Th
`GGSN
`
`131Th
`SIP REGISTRAR
`
`105-)
`HOST WITH PUSH APPLICATION
`
`ATTACH
`
`P
`
`ACTIVATE PDP CONTEXT [MS_IP_Add]
`
`REGISTER sip:carrier.com TO:userid ®carrier.com
`207
`_ CONTACT:MS IP ADD; EXPIRES=7200;Q=1.0
`CONTACT:MSISK® SIR name EXPIRES=*;q=0.1
`
`211
`
`209-)
`—1—*
`REGISTER sip:carrier.com TO:userid@ carrier.com
`_CONTACT:MS IP Add; EXPIRES=0
`CONTACT:MSISDN @SIR name; EXPIRES=*;q=0.1
`
`200 OK
`
`..„
`
`200 OK
`
`215--
`
`213)
`DEACTIVATE PDP CONTEXT [MS IP Add]
`
`217k
`
`DETACH
`
`200
`
`FIG.
`
`'""•••-..
`
`Apple Inc.
`Ex. 1011 - Page 3
`
`

`

`Patent Application Publication
`
` Jo c taaqs
`
`17
`
`IV 17LILIZO/£00Z Sfl
`
`1031
`TARGET MS
`
`109Th
`SGSN
`
`11/
`
`GGSN
`
`SMS—GMSC
`VIA SM—SC
`
`127Th
`SIR_name
`
`105
`
`HOST WITH
`initiator
`@host_name
`
`1311
`SIP REGISTRAR
`INVITE sip:userid@
`carrier.com
`CONTACT: initiator@
`host name
`I
`303
`
`INVITE sip:MSISDN@
`SIR_name
`
`305
`
`SMS MESSAGE
`FOR MSISDN
`)
`307
`
`SMS MESSAGE
`FOR MSISDN
`
`(INVITE MSISDN
`CONTACT: initiator@
`host_name
`
`)
`309
`
`311
`ACTIVATE PDP CONTEXT [MS IP Add] ) ---313
`200 OK
`TO:initiator@ host_na e CONTACT:MS_IP_Ad
`
`315
`
`SIP SESSION
`
`317
`ACTIVATE PDP CONTEXT [MS_IP_Add]
`
`319
`
`300
`
`FIG. 3
`
`Apple Inc.
`Ex. 1011 - Page 4
`
`

`

`Patent Application Publication Nov. 20, 2003 Sheet 4 of 4
`
`US 2003/0217174 Al
`
`127
`
`r
`
`403-)
`TO/FROM
`NETWORK
`
`405 -
`
`NETWORK
`
`INTERFACE INTERFACE 141E-all.
`
` 407
`CONTROLLER
`
`
`
`r411
`USER INTERFACE
`
`KEYBOARD DISPLAY
`413J
`
`415
`
`- 421
`
`- 424
`
`-427
`
`409-I MEMORY
`RECEIVING
`423-1 PARSING
`PREPARING
`PRESENTING
`FORWARDING
`OP. VAR
`
`425-•
`
`429-'
`
`SESSION
`I INITIATION
`L RELAY
`
`_J
`
`FIG. 4
`
`Apple Inc.
`Ex. 1011 - Page 5
`
`

`

`US 2003/0217174 Al
`
`Nov. 20, 2003
`
`1
`
`ESTABLISHING AN IP SESSION BETWEEN A
`HOST USING SIP AND A DEVICE WITHOUT AN IP
`ADDRESS
`
`FIELD OF THE INVENTION
`
`[0001] This invention relates in general to communication
`systems, and more specifically to a method and apparatus for
`establishing an IP (internet protocol) session between a host
`using SIP {session initiation protocol) and a device without
`an IP address.
`
`BACKGROUND OF THE INVENTION
`
`[0002] Communications systems are known and continue
`to evolve rapidly as is quite evident in wireless communi-
`cations systems. Systems have and are being deployed that
`allow packet data enabled mobile stations access to packet
`data networks such as the Internet or internet like networks
`that utilize IP addresses and packet data transport protocols
`such as IP.
`
`[0003] Business models are being developed and busi-
`nesses built based essentially on the ubiquitous access they
`are provided to a market place and consumers given these
`systems. However these businesses generally must rely on
`users initiating access to their services and thus are induced
`to pay for advertising on popular web sites such as Yahoo's
`site or popular Internet service provider sites. More recently
`various business models have proposed using push
`approaches or applications whereby, rather than waiting for
`consumers, they endeavor to initiate contact with the con-
`sumer and push information to the users regarding their
`services and wares. There are known session initiation
`protocols such as IETF SIP that allow a host to initiate
`contact with a client provided the client has an IP address.
`
`[0004] This is a problem with the popular version of IP
`addresses, known as IPv4 addresses because the address
`space is not large enough for everyone to have an IP address
`at all times. The industry has resorted to dynamic addresses
`to solve this problem whereby a given user shares a limited
`number of IP addresses with others and thus is assigned an
`IP address when and only so long as one is needed as
`determined by the user or the user's device. Future versions
`of the internet protocol are expected to use a much larger
`address space commonly referred to as IPv6 at which point
`everyone can have a so called static IP address. In the
`meantime and for legacy equipment, even after IPv6 has
`been adopted, hosts that wish to push content via an IP
`network to a user or consumer are faced with a problem of
`setting up an IP session with a user or specifically a device
`that does not have an IP address. This is particularly so in
`wireless systems that only recently have evolved to allow
`any form of Internet or packet based access.
`
`[0005] Clearly a need exists for methods and apparatus for
`establishing an IP session between a host using SIP and a
`device without an IP address. Preferably this will be trans-
`parent to the host using a session initiation protocol such as
`IETF SIP.
`
`BRIEF DESCRIPTION OF THE DRAWINGS
`
`[0006] The accompanying figures, where like reference
`numerals refer to identical or functionally similar elements
`throughout the separate views and which together with the
`
`detailed description below are incorporated in and form part
`of the specification, serve to further illustrate various
`embodiments and to explain various principles and advan-
`tages all in accordance with the present invention.
`
`[0007] FIG. 1 depicts, in a simplified and representative
`form, a system level diagram of a communications system
`that utilizes an apparatus according to the present invention;
`
`[0008] FIG. 2 depicts a ladder diagram illustrating a
`registration method for a mobile station according to the
`present invention;
`
`[0009] FIG. 3 depicts a ladder diagram illustrating a
`preferred method of establishing an IP session in accordance
`with the present invention; and
`
`[0010] FIG. 4 depicts a block diagram of the apparatus of
`FIG. 1 according to the present invention.
`
`DETAILED DESCRIPTION OF PREFERRED
`EMBODIMENT
`
`In overview form the present disclosure concerns
`[0011]
`communications systems that provide service to communi-
`cations units or more specifically users thereof operating
`therein. More particularly various inventive concepts and
`principles embodied in methods and apparatus for initiating
`or establishing an IP (Internet Protocol) session between a
`host and a device or mobile station such as a cellular phone
`or other wireless and mobile device with that does not have
`an IP address are disclosed and discussed. The communi-
`cations systems of particular interest are wireless and are
`those being deployed such as GPRS systems or those being
`planned that still employ IPv4 IP address spaces or those
`with Ipv6 spaces that must operate with legacy units or units
`without a static IP address or other systems using IP address-
`ing and allowing for mobility of the communications ser-
`vices users.
`
`[0012] As further discussed below various inventive prin-
`ciples and combinations
`thereof are advantageously
`employed to essentially induce the device or mobile station
`into setting up a PDP (packet data protocol) context that
`includes obtaining an IP address in a fashion that is trans-
`parent to the host and most of the communications system,
`thus alleviating various problems associated with known
`systems while still facilitating setting up sessions with or
`between hosts and mobile stations that were not attached to
`the packet data systems provided these principles or equiva-
`lents thereof are utilized.
`
`[0013] The instant disclosure is provided to further explain
`in an enabling fashion the best modes of making and using
`various embodiments in accordance with the present inven-
`tion. The disclosure is further offered to enhance an under-
`standing and appreciation for the inventive principles and
`advantages thereof, rather than to limit in any manner the
`invention. The invention is defined solely by the appended
`claims including any amendments made during the pen-
`dency of this application and all equivalents of those claims
`as issued.
`
`It is further understood that the use of relational
`[0014]
`terms, if any, such as first and second, top and bottom, and
`the like are used solely to distinguish one from another entity
`or action without necessarily requiring or implying any
`actual such relationship or order between such entities or
`
`Apple Inc.
`Ex. 1011 - Page 6
`
`

`

`US 2003/0217174 Al
`
`Nov. 20, 2003
`
`2
`
`actions. Much of the inventive functionality and many of the
`inventive principles are best implemented with or in soft-
`ware programs or instructions and integrated circuits (ICs)
`such as application specific ICs. It is expected that one of
`ordinary skill, notwithstanding possibly significant effort
`and many design choices motivated by, for example, avail-
`able time, current technology, and economic considerations,
`when guided by the concepts and principles disclosed herein
`will be readily capable of generating such software instruc-
`tions and programs and ICs with minimal experimentation.
`Therefore, in the interest of brevity and minimization of any
`risk of obscuring the principles and concepts according to
`the present invention, further discussion of such software
`and ICs, if any, will be limited to the essentials with respect
`to the principles and concepts within the preferred embodi-
`ments.
`[0015] Referring to FIG. 1 a simplified and representative
`form of a system level diagram of a communications system
`100 that provides services via a RAN (radio access network)
`101 for a device or MS (mobile station) 103 will be
`discussed and described. The RAN 101 is comprised of one
`or more base station controllers (not shown) that are coupled
`to one or more transceivers 107 (one depicted). The trans-
`ceivers 107 are coupled to two paths within the RAN, one
`providing packet data based communications services and
`one providing conventional cellular voice services for the
`mobile station 103. A multiplicity of devices or MS includ-
`ing device or MS 103, when it has an IP address 108
`[MS_IP_ADD], can be or is attached via the transceiver 107
`to one or more known Serving GPRS Support Nodes
`(SGSN)s 109 (one depicted), and from there to one or more
`known Gateway GPRS Support Nodes (GGSN)s 111 (one
`depicted), The GGSN 111 is suitable for coupling the MS to
`a packet data network 113 and from there to other sites on
`the network such as Host 105. The Serving GPRS Support
`Node (SGSN) is the node that is serving the MS (i.e., the Gb
`interface is supported by the SGSN). At GPRS attach, the
`SGSN establishes a mobility management context contain-
`ing information pertaining to e.g., mobility and security for
`the MS. At PDP Context Activation, the SGSN establishes
`a PDP (packet data protocol) context (includes an IP address
`for the MS among other info), to be used for routeing
`purposes, with the GGSN that the GPRS subscriber will be
`using. The SGSN and GGSN functionalities may be com-
`bined in the same physical node, or they may reside in
`different physical nodes. SGSN and GGSN contain IP route-
`ing functionality, and they may be interconnected with IP
`routers.
`[0016] The MS 103 or multiplicity of MS are also coupled
`via transceiver 107 to the other pathway that is part of the
`RAN 101, namely, one ore more Mobile Switching Centers
`(MSC) 123 (one depicted) at least one of which is coupled
`to and communicates with a known home location register
`(HLR) (not shown) that is typically a separate system entity.
`The MSC 123 enables, for example, a connection from the
`MS to the PSTN (public switched telephone network) to
`provide conventional cellular services. The RAN 01 also
`supports Short Message Services via one or more MSCs of
`the type SMS-GMSC (short message service-gateway
`mobile switching center) or SMS-IWMSC (short message
`service—inter working mobile switching center) 123 (one
`depicted) each as known. Short Message Service is coordi-
`nated by a SM-SC (short message service—service center)
`125 that is coupled to the MSC 103 and in known systems
`
`from there to the packet data network 113. As discussed and
`described so far the RAN is generally known and operates
`in a scheduled fashion with transceivers to provide radio
`wave based communications paths 121 between the RAN
`and the mobile station 103 that operate on or over or through
`the RAN. Examples of such RANs include the General
`Packet Radio Service (GPRS), General Specialized Mobile
`(GSM), Personal Communications Systems (PCS), and
`other cellular systems as well as various next generation
`(2.5G, 3G) systems being proposed, developed, and defined
`such as EDGE (Enhanced Data-rates for GSM (or Global)
`Evolution), UMTS (Universal Mobile Telecommunications
`System), or CDMA 2000 and WCDMA (Wideband Code
`Division Multiple Access) and future evolutions thereof.
`
`[0017] RANs were designed to support IP-based packet
`data applications that are initiated at the mobile station such
`as browsing the internet, accessing a bank account, or
`reading email. A PDP context, essentially an IP address or
`session including various associated parameters such data
`rates, security, etc., can be established using known RAN
`procedures by a PDP context activation procedure that is
`initiated by the mobile station. The GPRS procedures used
`for this purpose are described in 3G TS 23.060 V3.4.0
`(2000-07), a Technical Specification available from or
`through a Web site maintained by the 3rd Generation Part-
`nership Project; Technical Specification Group Services and
`System Aspects; General Packet Radio Service (GPRS);
`Service description; Stage 2 (published in 1999). This ref-
`erence will also provide various information regarding the
`SM-SC, SMS-GMSC, and SMS-IWMSC and is hereby
`incorporated herein in its entirety by reference.
`
`[0018] The mobile station's memory or possibly associ-
`ated equipment (generally referred to hereinafter collec-
`tively as the MS or device) can be programmed with a long
`lived or permanent IP address for the MS. However, moti-
`vated by the insufficient number of IP addresses, available
`for example, with an IPv4 address space, most systems in
`order to limit the number of IP addresses needed to support
`the large number of devices, the MS typically obtains a
`temporarily assigned (short-lived) IP address when it acti-
`vates the PDP context. Furthermore, the MS typically is
`programmed to de-activate the context as soon as it is no
`longer needed by an application running on the device,
`thereby releasing the short-lived or dynamic IP address for
`reuse by another MS. For example the MS 103 may activate
`a PDP context when the end-user starts to retrieve or send
`email and deactivate the context if all email has been
`retrieved or sent.
`
`[0019] When a MS uses a long-lived IP address, a host 105
`on the packet data network 113 can always reach the MS by
`sending an IP packet to the MS. Even when the MS does not
`have a PDP context when the IP packet is first sent, a
`standard RAN procedure further allows the Gateway 111 to
`request the establishment of a PDP context and thus to create
`an IP connection, provided the mobile has a known IP
`address. A procedure, known in GPRS and UMTS systems
`as Network Requested PDP Context Activation (NRCA), is
`typically triggered by sending a data packet to the gateway
`111 using the long-lived IP address of the target mobile
`station. The Gateway will then collaborate with RAN enti-
`ties, such as the mobile station, the SGSN, and the HLR, to
`activate the PDP context and to deliver the data packet.
`
`Apple Inc.
`Ex. 1011 - Page 7
`
`

`

`US 2003/0217174 Al
`
`Nov. 20, 2003
`
`3
`
`[0020] However, a MS that uses a short-lived IP addresses
`cannot be reached in this way when or while it does not have
`an active PDP context, thus IP address. After the MS has
`released the short-lived IP address, the host 105 would not
`know which IP address to use when sending IP packets to the
`MS, essentially the host would have no way of resolving the
`MS identity. This invention solves this problem by disclos-
`ing a method and apparatus that enables a host 105, using a
`Session Initiation Protocol, to initiate an IP session with a
`MS without an IP address. Session Initiation Protocols are
`known with an example being SIP: Session Initiation Pro-
`tocol available through the a website maintained by the
`(IETF) Internet Engineering Task Force; SIP WG identified
`as draft-ietf-sip-rfc2543bis-09.txt last published Feb. 27,
`2002. Using the principles and concepts disclosed here
`provides an advantage in that it is transparent to the host 105
`and the RAN 101 as so far discussed. In fact the host 105
`does not need to know whether the MS currently has an
`active PDP context.
`
`[0021] Suppose an application wants to push some infor-
`mation from the host 105 to the MS 103. The host 105 will
`use the Session Initiation Protocol (SIP) to initiate a session
`with the MS. SIP manages mobility in IP systems in a way
`that is similar to mobility management in cellular systems.
`Each IP user has a user name that looks like a typical URL:
`(sip:userid@domain A). For each domain there is a SIP
`registrar 131 with a database 133 that keeps track of the
`location of the user, just like an HLR will keep track of
`where a cellular phone can be used. When a user moves to
`a new location (userid@domain_new), the user sends a SIP
`registration to the registrar. The registration message con-
`tains a Contace135 where the user can be reached. The
`registrar 131 stores the contact in the database 133 (until it
`is cancelled or expired). It is also possible to provide a
`Contact to the registrar on behalf of the user.
`
`[0022] For the host or application on the host 105 to set up
`a session with a target or MS 103, the host 105 sends a SIP
`INVITE messages
`to
`that MS 103,
`for example
`(sip:userid@carrier.com). The SIP INVITE message will
`hereafter be referred to as SIP INVITE or simply INVITE.
`By the rules of the SIP protocol the message is first sent to
`the SIP registrar (sip:carrier.com). The message also con-
`tains the host contact or name or specifically host IP address
`and port number where a response is expected and the
`target's or MS 103 name. The registrar then looks up the
`Contact 135 for userid@carrier.com and either forwards the
`invite to the contact or returns the INVITE to the host with
`the Contact information so that the host or application can
`send the INVITE directly to the target. The later method is
`called 'redirection'. One more detail: a target can have more
`than one Contact 135 as indicated in the registrar. Contacts
`can be equal, in which case the INVITE is replicated and
`forwarded to each Contact simultaneously, or they can be
`ordered, in which case the contacts are tried one after the
`other, until one succeeds.
`
`If the target MS 103 has a static IP address or has
`[0023]
`an active PDP context 141 with an IP address, the MS will
`have registered with its SIP registrar and the registrar will
`contain the MS's IP address as a contact, namely sip:MS_I-
`P_Add. In this case a SIP INVITE and push data can be
`delivered using prior art solutions. The preferred embodi-
`ment is such that this prior art behavior is retained. If,
`however, the target MS is using a dynamic IP addresses and
`
`does not currently have an active PDP context (IP address),
`then contact 1 in FIG. 1 will not be found in the Registrar.
`The preferred embodiment however provides a special con-
`tact, Contact2 of the form shown MSISDN@SIR_name, in
`the MS's registrar and a novel entity, designated SIR (ses-
`sion initiation relay) 127 that is expected to be a separate
`entity but may be part of the RAN 101 or another system
`entity that together ensure that the MS will activate a PDP
`context to obtain an IP address, and thus receive the SIP
`INVITE.
`
`In summary Contact2 includes a phone number,
`[0024]
`MSISDN, for the particular MS and identifies the SIR 127
`as the location or target to receive the SIP INVITE 137. As
`explained earlier, the registrar 131 will either forward the
`INVITE to the SIR or, in the event that redirection is used,
`the host 105 will send the INVITE directly to the SIR. The
`SIR will parse the message to obtain the MS identifier and
`encapsulate the INVITE message in a WAP (wireless access
`protocol) formatted message that can be forwarded to the
`MS using Short Message Service message and processes,
`depicted as WAP over SMS 139 in FIG. 1. The balance of
`this disclosure will include a description of a registration
`method for a mobile station with reference to FIG. 2, a
`description of the preferred method of establishing an IP
`session with reference to FIG. 3, and a description of a block
`diagram of the SIR 127 with reference to FIG. 4.
`
`[0025] Referring to FIG. 2 a ladder diagram illustrating a
`registration method for a MS will be discussed and
`described. FIG. 2 shows an essentially standard session
`initiation protocol registration process excepting that a novel
`version of a contact, namely Contact2, being placed with the
`Registrar 131. There are several ways by which Contact2
`can be put into the MS's SIP registrar: The operator, service
`provider or user can send a single registration message to the
`user's
`registrar.
`It specifies Contact2
`for
`the MS
`(sip:MSISDN@SIR_name), and further specifies that the
`contact does not expire (Expires: *) and that the contact
`should be tried with low priority or rank order (q=0.1). If the
`MS later does a SIP registration it will add a second Contact,
`namely contactl that contains its IP address and has high
`rank order. As long as the MS remains registered, the
`registrar will first try to send an INVITE directly to the MS's
`IP address. The burden of Contact management can thus be
`placed on the MS. When the MS gets an IP address it
`registers with that address as Contact. Before it releases the
`IP address it registers again, cancels the Contact with the IP
`address, and
`thus effectively activates
`the Contact2
`(sip:MSISDN@SIR_name).
`
`[0026] The FIG. 2 ladder diagram illustrates this when the
`MS initiates and manages the SIP registration. The MS 103
`attaches to the SGSN 109 at 203 and activate a PDP context
`[MS_IP_Add] with the GGSN 111 at 205. At 207, via the
`GGSN and packet data network 113 the MS send a sip
`registration message to the MS's SIP Registrar 131, REG-
`ISTER sip:carrier.com, To: userid@carrier.com with two
`contacts one with an IP address, MS_IP_Add, reasonable
`expiration time of 7200 secs (2 hours), and high relative
`priority of 1 and the second special contact or Contact2,
`MSISDN@SIR_name, that never expires (* designates
`never expires in SIP) but has a low relative priority of 0.1.
`Note this Contact2 or special contact only needs to be sent
`upon the initial registration or whenever it has been can-
`celled or perhaps is in question. Furthermore it need not be
`
`Apple Inc.
`Ex. 1011 - Page 8
`
`

`

`US 2003/0217174 Al
`
`Nov. 20, 2003
`
`4
`
`sent at this time since the MS has an IP address noted by the
`contact with MSISDN (e.g. a telephone number that resolves
`to the target MS 103). In any event the registration is
`acknowledged by the Registrar at 209. Thereafter the MS
`may conduct whatever transaction it wishes via the packet
`date network, for example read email, browse the Web or
`even receive push material from the host 105. At some time
`later 211 the MS sends another registration message that
`indicates the IP address expires immediately (Expires=0)
`and reiterates the Contact2 or special contact with the
`MSISDN MS identifier. Note this re-iteration is not neces-
`sary if this contact information has been previously sent and
`not changed. In fact this contact need only be sent one time.
`In any event this registration message is acknowledged at
`213. Then the PDP context [MS_IP_Add] is deactivated at
`215 and the MS detaches at 217. The host 105 with the push
`application has been included in FIG. 2 only to make the
`point that it is not involved or even aware of the registration
`activities and thus they are transparent thereto.
`
`[0027] Referring to FIG. 3 a ladder diagram illustrating a
`preferred method of establishing an IP session when the MS
`does not have an IP address will be discussed and described.
`FIG. 3 illustrates a method of initiating an Internet Protocol
`(IP) session between a host 103 using a session initiation
`protocol and a device 103 without an IP address. The SIP
`registrar contains the special contact URL for the target MS.
`The contact can be put in the registrar in several ways, as
`discussed above. The contact is of the form sip:userid@host
`and is chosen such that each INVITE for the target MS 103
`is forwarded to the SIR instead. For this reason the contact
`uses the host name of the SIR. Furthermore, the SIR must be
`able to determine the identity of the target MS. For this
`reason the user name contains the MS's MSISDN. The URL
`thus looks like sip: MSISDN@SIR_name. The push appli-
`cation,
`at
`303
`at
`the
`host
`105
`designated
`initiator@host_name sends a SIP INVITE to the MS,
`addressed
`by
`the MS's
`known
`SIP
`name
`sip:userid@carrier.com so the INVITE is routed to the
`Registrar 131. Note that there are no new or non-standard
`requirements for the contents of the SIP INVITE; the push
`application does not need to be aware of the principles and
`concepts of the SIR operation.
`
`[0028] The SIP registrar 131, upon receiving the INVITE,
`checks for the contact address of sip:userid@carrier.com.
`Lets assume that there is only one contact address for that
`MS, namely sip: MSISDN@SIR_name. The Registrar then
`forwards the INVITE to the specified host, the SIR 127 at
`305. Note that the SIP registrar in not modified and is not
`aware of anything novel about the contact or the inventive
`concepts and principles discussed herein.
`
`[0029] The SIR, upon receiving the session request,
`including the host contact or initiator address and port
`number that corresponds to the host, or INVITE message,
`via an IP connection, will parse the requested URL
`(sip:MSISDN@SIR_name) to extract or determine the
`device identifier or MS's MSISDN. It will then prepare a
`message, including the session request, for the device,
`specifically an OTA-WSP PDU (Over The Air—Wireless
`Session Protocol Packet Data Unit). This message is then
`forwarded to the device or MS via a non-IP connection in a
`fashion that results in the device obtaining a device IP
`address and sending an acknowledgment of the session
`request that includes the device IP address.
`
`[0030] The SIR 127 uses a new combination of protocols
`to deliver or cause to be delivered the SIP INVITE message
`137 to the MS 103. The SIR uses concepts and processes
`developed by the Wireless Application Protocol Forum (Ref:
`"Wireless Application Protocol Architecture Specification".
`WAP Forum; WAP-210-WAPArch-20010712-a. Specifica-
`tion for the WAP protocols are available at www.wapforu-
`m.org). The WAP defines a push architecture that allows a
`proxy like the SIR 127 to send data to a terminal in an
`asynchronous manner. The SIR and the terminal communi-
`cate using the known Push OTA protocol, which utilizes
`WSP and/or HTTP (Hyper-text Transport Protocol, RFC
`2068) services. The Push OTA protocol is described in
`WAP-235-PushOTA-20010425-a. This invention uses a pro-
`tocol variant, which is referred to as "OTA-WSP ("Wireless
`Session Protocol". WAP Forum. WAP-230-WSP-20010705-
`a.). OTA-WSP is designed to be suitable for use with
`low-bandwidth bearers. In particular, it does not require an
`IP bearer.
`
`In the preferred embodiment, the SIR 127 uses
`[0031]
`OTA-WSP in a connectionless way to push or forward the
`SIP INVITE message to the MS. Connectionless push is
`always performed using the WAP wireless datagram proto-
`col WSP/WDP (WDP "Wireless Datagram Protocol". WAP
`Forum= WAP-259-WDP-20010614-a.). Using WSP/WDP
`the SIR 127 can forward the SIP INVITE to a WDP port on
`the MS. WSP/WDP allows the push content or here SIP
`INVITE to be delivered to an application on the MS, as
`identified by an Application-ID in the WSP/WDP message.
`In the preferred embodiment, the SIR and the MS use a
`common definition of a new application code to represent
`the IETF Session Initiation Protocol SIP. By using this
`application code as application-ID in a WSP/WDP message,
`the SIR 127 can make the MS 103 extract the push content
`and provide it as input to a SIP application running on the
`MS 103.
`
`[0032] For the purpose of delivery of the WSP/WDP
`message to the MS 103, the SIR 127 preferably uses the
`know Short Message Service protocol (SMS). The use of
`SMS
`is described
`in 3G TS 23.040 (available at
`www.3GPP.org—see above) and ETSI TS 100 901 V7.4.0
`(1999-12) Technical Specification Digital cellular telecom-
`munications system (Phase 2+); Technical realization of the
`Short Message Service (SMS); (GSM 03.40 version 7.4.0
`Release 1998) each of which are hereby incorporated herein
`in there entirety by reference. SMS is typically used and
`especially adapted to deliver short text messages from an
`external device to a MS that are to be displayed on the user
`interface of the MS and to send text messages from the MS
`to an external device.
`
`[0033] To send a Short Message (SM) to a MS, one
`typically contacts a Short Message—Service Center (SM-
`SC) 125. The SM-SC will forward the message via an
`appropriate SMS-GMSC or SMS IWMSC 123 for delivery
`OTA via a transceiver 107 to the MS 103. Standard methods
`exist to buffer a SM in case a MS is temporarily unavailable
`and to deliver a SM via a SGSN 109 in case the MS 103 is
`on an OTA packet data channel. In addition, known methods
`exist to deliver longer messages by fragmenting them into
`several short messages. As mentioned above, under normal
`use the payload of a SM that is sent to MS 103 will be
`displayed on the user interface of the MS. However, SMS
`allows the SIR to add information to the SMS header that
`
`Apple Inc.
`Ex. 1011 - Page 9
`
`

`

`US 2003/0217174 Al
`
`Nov. 20, 2003
`
`5
`
`prevents display of the payload, and instead routes the
`payload to an application on the MS. For the preferred
`embodiment, the SIR specifies the payload to be delivered to
`WSP/WDP (Alternatively the SIR can specify a payload like
`a SIP INVITE to be delivered directly to the SIP application
`but this may not be as widely supported by MSs).
`
`[0034] Large wireless systems may includ