(19) United States
`(12) Patent Application Publication (10) Pub. No.: US 2006/0034202 A1
`(43) Pub. Date:
`Feb. 16, 2006
`Kuure et al.
`
`US 200600342O2A1
`
`(54) TRANSMITTING DATA TO A GROUP OF
`RECEIVING DEVICES
`
`(75) Inventors: Pekka Kuure, Espoo (FI); Markku
`Vimpari, Oulu (FI)
`
`Correspondence Address:
`SQUIRE, SANDERS & DEMPSEY L.L.P.
`14TH FLOOR
`8000 TOWERS CRESCENT
`TYSONS CORNER, VA 22182 (US)
`
`(73) Assignee: Nokia Corporation
`(21) Appl. No.:
`10/965,258
`(22) Filed:
`Oct. 15, 2004
`(30)
`Foreign Application Priority Data
`
`Aug. 12, 2004 (FI)............................................. 20041075
`
`
`
`50
`
`Publication Classification
`
`(51) Int. Cl.
`(2006.01)
`H04O 7/20
`(52) U.S. Cl. .............................................................. 370/312
`
`ABSTRACT
`(57)
`A data transmission method transmits data to a group of
`receiving communication devices in a communication Sys
`tem comprising at least one cellular network. The method
`includes defining, by an application Server Situated beyond
`a cellular network, a group of receiving communication
`devices in the cellular network, the application Server having
`no visibility to locations of receiving devices in the cellular
`network. The method also includes receiving, in a broadcast/
`multicast network entity configured to provide broadcast and
`multicast Services in the cellular network, data to be trans
`mitted from the application Server to the group. The method
`also includes transmitting the data from the broadcast/
`multicast network entity to the group using broadcast and/or
`multicast transmission. Furthermore, a network entity in a
`cellular network and a communication System are provided
`configured to implement the method.
`
`Content
`provider
`
`62
`
`Exhibit 1022
`Page 01 of 10
`
`

`

`Patent Application Publication Feb. 16, 2006 Sheet 1 of 2
`
`US 2006/0034202 A1
`
`50
`
`BM-SC
`
`Content
`provider
`
`62
`
`46
`
`GGSN
`
`42
`
`SGSN
`
`HLR
`
`44
`
`Fig. 1
`
`Exhibit 1022
`Page 02 of 10
`
`

`

`Patent Application Publication Feb. 16, 2006 Sheet 2 of 2
`
`US 2006/0034202 A1
`
`
`
`Exhibit 1022
`Page 03 of 10
`
`

`

`US 2006/0034202 A1
`
`Feb. 16, 2006
`
`TRANSMITTING DATA TO A GROUP OF
`RECEIVING DEVICES
`
`FIELD OF THE INVENTION
`0001. The invention relates to communication systems,
`and more particularly to transmitting data to a group of
`receiving communication devices in a cellular network of a
`communication System.
`
`BACKGROUND OF THE INVENTION
`0002. A communication system can be seen as a facility
`that enables communication Sessions between two or more
`entities Such as a communication device and/or other nodes
`asSociated with the communication System. Subscribers,
`Such as the users or end-users, to a communication System
`may be offered and provided numerous Services, Such as
`two-way or multi-way calls, data communication or multi
`media Services or simply an access to a network, Such as the
`Internet. The services may be offered by an operator of a
`network of the communication System or by an external
`Service provider.
`0.003
`Examples of communication systems may include
`fixed line communication Systems, Such as a public Switched
`telephone network (PSTN), wireless communication sys
`tems, such as a public land mobile network (PLMN), e.g.
`global System for mobile communications (GSM), general
`packet radio service (GPRS), universal mobile telecommu
`nications system (UMTS), other wireless networks, such as
`a wireless local area network (WLAN), and so on, and/or
`other communication networks, Such as an Internet Protocol
`(IP) network and/or other packet switched data networks.
`Various communication Systems may simultaneously be
`concerned in a connection.
`0004 Any appropriate communication device may be
`used for accessing a communication System. Examples of
`communication devices may comprise, but are not limited
`to, wireless devices, e.g. user equipment (UE), a mobile
`Station (MS), a cellular phone, a personal digital assistant
`(PDA) or the like, or other terminals, Such as a personal
`computer (PC), or any other equipment operable according
`to a Suitable network protocol, Such as a wireleSS applica
`tions protocol (WAP) or a hypertext transfer protocol
`(HTTP). The communication device may support, in addi
`tion to call and network acceSS functions, other Services,
`Such as short message Service (SMS), multimedia message
`service (MMS), electronic mail (email), Web service inter
`face (WSI) messaging and Voice mail.
`0005. A user of a wireless communication device may
`access a communication network via a radio acceSS network
`(RAN), which is typically controlled by an appropriate
`controller network element, Such as radio network controller
`(RNC). Examples of radio access networks may comprise
`the UMTS terrestrial radio access network (UTRAN) and
`the GSM/EDGE radio access network (GERAN).
`0006. Application servers operating beyond the Gi inter
`face may provide data transfer Services to an individual as
`point-to-point or one-to-one Services or group(s) of indi
`viduals as point-to-multipoint or one-to-many Services. Such
`groups may be large in number of individuals comprised in
`the group. In the GPRS, the Gi may be defined as the
`interface between a gateway GPRS support node (GGSN)
`
`and an external public data network (PDN), such as the
`Internet. Thus, the application Server operates beyond cel
`lular networks and has no visibility to cellular specific
`addressing. An application Server may use Uniform
`Resource Identifiers (URIs) and IP addresses to address
`members of a group. When distributing a data Stream to a
`group, an application Server may multiply the incoming data
`Stream to obtain copies of the data Stream for each member
`of the group. The application Server may then Send the
`copies of the data Stream via the Gi interface to a cellular
`network and leave a responsibility of the data transfer
`thereafter to the cellular network.
`0007. The solution described above may work well when
`groups are relatively Small or physically Scattered. However,
`as a size of the group becomes greater or when a lot of
`members are located in a Small geographical area, problems
`may arise. It is then more likely that too many members are
`located in close proximity with each other and might have to
`be served by a single transceiver network element using the
`Same physical radio resources for many members of the
`group. A particular cell may be congested and data may not
`be delivered to all members. In addition to congestion
`problem in Some particular cells, also other problems may be
`faced as many identical data Streams are conveyed to many
`recipients within a single cellular network.
`0008. The way of transferring group data described above
`may not be efficient from a System resource point of view.
`In particular, with a great number of participants it may also
`appear to be impossible.
`0009. A direct one-to-one and one-to-many voice com
`munication System named as Push to talk over Cellular
`(PoC) has been developed. The PoC service is based on
`half-duplex Voice over IP (VoIP) technology in cellular
`networks, e.g. the GSM/GPRS network. The PoC uses an
`“always-on' connection, which allows a subscriber to have
`a direct access to the Service after the Subscription to the
`Service without additional measures, Such as dial-up. The
`PoC enables a subscriber to listen to group traffic. Call can
`be started to both individuals and groups with a simple
`action, Such as a push of a key. The call connection is
`established automatically and the receiver does not need to
`answer the call. In the network, a controlling Server takes
`care of Session management and floor control, Such as
`multiplying the speech (i.e. the VoIP) for all members of a
`grOup.
`0010 Furthermore, a cellular system may include a mul
`timedia broadcastlmulticast service (MBMS) server, which
`is able to broadcast or multicast information to multiple
`participants over a geographical area. An MBMS Server is
`not able to form groups, but provides information of differ
`ent multicasting groups to participants. It is a responsibility
`of the participants to Subscribe and join to a multicast Service
`in order to receive the data. A reference architecture to
`support MBMS is defined by the Third Generation Partner
`ship Project (3GPP) in TS 23.246 V.6.3.0 (2004-06) “Tech
`nical Specification Group Services and System Aspects,
`Multimedia Broadcast/Multicast Service (MBMS); architec
`ture and functional description (Release 6)”, FIG. 1.
`0011. It might be desired to distribute data to a number of
`participants within an environment that comprises both
`application Servers and broadcast/multicast Service Servers,
`such as MBMS servers, within a cellular network system.
`
`Exhibit 1022
`Page 04 of 10
`
`

`

`US 2006/0034202 A1
`
`Feb. 16, 2006
`
`However, linking the application ServerS Situated beyond the
`cellular network and the MBMS servers situated in the
`cellular network may be difficult.
`0012. It shall be appreciated that these issues are not
`limited to any particular communication environment, but
`may occur in any appropriate communication System.
`
`SUMMARY OF THE INVENTION
`0013 Embodiments of the invention aim to address one
`or Several of the above problems or issues.
`0.014.
`In accordance with an aspect of the invention, there
`is provided a method for transmitting data to a group of
`receiving communication devices in a communication SyS
`tem comprising at least one cellular network. The method
`comprises defining, by an application Server Situated beyond
`a cellular network, a group of receiving communication
`devices in the cellular network, the application Server having
`no visibility to locations of receiving devices in the cellular
`network. The method further comprises receiving, in a
`broadcast/multicast network entity configured to provide
`broadcast and multicast Services in the cellular network, data
`to be transmitted from the application Server to the group.
`The method further comprises transmitting the data from the
`broadcast/multicast network entity to the group using broad
`cast and/or multicast transmission.
`0.015. In accordance with another aspect of the invention,
`there is provided a broadcast/multicast network entity in a
`cellular network. The network entity is configured to receive
`data to be transmitted from an application Server Situated
`beyond the cellular network and having no visibility to
`locations of receiving devices in the cellular network. The
`network entity is also configured to transmit the data to a
`group of communication devices in the cellular network
`using broadcast and/or multicast transmission, the group
`being defined by the application Server.
`0016. In accordance with another aspect of the invention,
`there is provided a communication System. The communi
`cation System comprises an application Server Situated
`beyond a cellular network and having no visibility to loca
`tions of receiving devices in the cellular network, the
`application Server configured to define a group of receiving
`devices in the cellular network. The communication System
`further comprises a broadcast/multicast network entity in the
`cellular network, the broadcastlmulticast network entity
`configured to receive data to be transmitted from the appli
`cation Server and to transmit the data to communication
`devices in the cellular network using broadcast and/or
`multicast transmission.
`0017 Various other aspects and embodiments shall be
`described in the following detailed description and in the
`attached claims.
`
`BRIEF DESCRIPTION OF THE DRAWINGS
`0018. The invention will now be described in further
`detail, by way of example only, with reference to the
`following examples and accompanying drawings, in which:
`0.019
`FIG. 1 shows an example of an arrangement in
`which the embodiments of the invention may be imple
`mented; and
`
`0020 FIG. 2 shows a signaling chart illustrating an
`embodiment of the invention.
`
`DETAILED DESCRIPTION OF PREFERRED
`EMBODIMENTS
`Reference is made to FIG. 1 showing an example
`0021
`of a network architecture in which the embodiments of the
`invention may be implemented. In FIG. 1, a public data
`network (PDN) 10 is provided for offering data services. An
`example of the PDN 10 may comprise, but is not limited to,
`the Internet Protocol (IP) Multimedia Subsystem (IMS). The
`IMS uses the Session Initiation Protocol (SIP), which is an
`application layer control protocol defined by the Internet
`Engineering Task Force (IETF) for creating, modifying and
`terminating Sessions with one or more participants. The SIP
`is defined in the document RFC 3261 “SIP: Session Initia
`tion Protocol'. The embodiments are mainly described refer
`ring to the IMS, but the same idea may be implemented with
`other communication Systems as well.
`0022. In a SIP-controlled network, Uniform Resource
`Identifiers (URIs) are used to identify different types of
`actors in the network. Typically a URI points to a registered
`user identity of an individual user. A URI may identify also
`Services, Such as Voicemail Server or conference factory
`URI, conferencing instances, Such as chat rooms or Voice
`over-IP (VOIP) conferencing instances, or other types of
`resources. In addition, a URI may point to a resource list,
`which may be a list of individual URIs, or in other words,
`a group of URIs. A URI pointing to a resource list shall be
`called in this specification also a group URI. Resource lists
`may be used in many applications, Such as for one-to-many
`messaging, and So on. For example, a Server in a network
`may maintain resource lists of e.g. one operator. A request
`addressed to Such a resource list may be routed to the Server,
`which may forward the request to individual contacts behind
`the resource list.
`0023 Data services, such as IMS services, can be pro
`vided with mobile communication devices via a mobile
`communication System. A mobile communication System is
`typically arranged to Serve a plurality of mobile communi
`cation devices usually via a wireleSS interface between the
`communication device and at least one transceiver network
`element of the communication System, Such as a base
`transceiver station (BTS) or a Node B. The mobile commu
`nication System may logically be divided between a radio
`access network (RAN) and a core network (CN).
`0024.
`In the arrangement of FIG. 1, a communication
`device 22 is arranged to access the core network via the
`UTRAN 20 as an access network. The communication
`device 22 is arranged to transmit Signals to and receive
`Signals from a transceiver network element (not shown) via
`a wireleSS interface between the communication device and
`the transceiver network element of the radio access network.
`Correspondingly, the transceiver network element is able to
`transmit Signals to and receive signals from the communi
`cation device via the wireleSS interface. In the arrangement
`of FIG. 1, the communication device 32 is shown to access
`the core network via the access network GERAN 30.
`0025. It shall be appreciated that, although for clarity
`reasons FIG. 1 shows only two exemplifying radio access
`networks, a typical communication network System usually
`includes a number of radio access networks. It shall also be
`
`Exhibit 1022
`Page 05 of 10
`
`

`

`US 2006/0034202 A1
`
`Feb. 16, 2006
`
`appreciated that although only two communication devices
`are shown in FIG. 1 for clarity, a number of user equipment
`and/or other communication devices may be in Simultaneous
`communication with transceiver network elements of a
`communication System.
`0026. An access network, Such as a radio access network
`(RAN), is typically controlled by appropriate controlling
`network elements, such as a radio network controller (RNC).
`These controllers are not shown in FIG. 1 in order to
`enhance clarity. A controller may be assigned for each
`transceiver network element or a controller can control a
`plurality of transceiver network elements, for example in the
`radio access network level. It shall be appreciated that the
`name, location and number of the network controllers
`depend on the System.
`0027. The core network (CN) entities typically include
`various Switching and other control entities and gateways for
`enabling the communication via a number of radio acceSS
`networks and also for interfacing a Single communication
`System with one or more communication Systems, Such as
`with other cellular Systems and/or fixed line communication
`systems. In the 3GPP systems, the radio access network
`controller is typically connected to an appropriate core
`network entity or entities Such as, but not limited to, a
`Serving general packet radio Service Support node (SGSN)
`42. The radio access network controller is in communication
`with the SGSN via an appropriate interface, for example on
`an Iu or Gb interface. The SGSN may communicate with a
`Subscriber information database, Such as a home location
`register (HLR) 44. The SGSN 42 also typically communi
`cates with a gateway GPRS Support node (GGSN) 46. This
`interface may be, for example, a Gn/Gp interface.
`0028. In a 3GPP network, a packet data session is estab
`lished to carry traffic flows over the network. Such a packet
`data Session is often referred to as a packet data protocol
`(PDP) context. A PDP context may include a radio bearer
`provided between the communication device and the radio
`network controller, a radio access bearer provided between
`the communication device, the radio network controller and
`the SGSN, and Switched packet data channels provided
`between the SGSN and the GGSN. Each PDP context
`usually provides a communication pathway between a par
`ticular communication device and the GGSN and, once
`established, can typically carry multiple flows. Each flow
`normally represents, for example, a particular Service and/or
`a media component of a particular service. The PDP context
`therefore often represents a logical communication pathway
`for one or more flow across the network. To implement the
`PDP context between a communication device and the
`SGSN, radio access bearers (RAB), i.e. logical and physical
`channels, need to be established which commonly allow for
`data transfer for the communication device.
`0029 Furthermore, FIG. 1 shows an application server
`50 connected to one or more data networks such as, but not
`limited to, the exemplifying PDN 10. It shall be appreciated
`that a number of application Servers may be connected to
`each data network. In the FIG. 1 embodiment, the mobile
`communication devices 22, 32 may connect to the applica
`tion server 50 via the radio access network 20, 30 and the
`public data network 10. In an embodiment the application
`server 50 may locate in an operator intranet and not behind
`a public data network 10. For example, a PoC server may
`locate in a private network Side.
`
`0030) Furthermore, FIG. 1 shows a broadcast multicast
`service centre (BM-SC) 60, which provides functions for
`MBMS service provisioning and delivery. The BM-SC 60
`may serve as an entry point for MBMS transmissions of a
`content provider 62 providing broadcast or multicast data to
`communication devices situated in a geographical area
`served by the BM-SC 60. As was explained above, the
`BM-SC 60 is not able to form groups, but may provide
`information of different multicasting groups to communica
`tion devices in the area. In embodiments of the invention,
`clients in the communication devices 22, 32 may get avail
`able multicast address(es) from application servers 50 via
`SIP/SDP media negotiation. The clients of the communica
`tion devices 22, 32 may try to join the multicast address(es)
`if available at the area of the communication devices 22, 32.
`Thus, no user interaction is needed in a way comparable to
`a normal operation, for example, in relation to a PoC
`application. In a normal PoC operation, it is a responsibility
`of users of listening communication devices to Subscribe and
`join to a multicast Service in order to receive the data. The
`BM-SC 60 may be used to authorize and initiate MBMS
`bearer Services within a cellular network and can be used to
`Schedule and deliver MBMS transmissions.
`0031. According to embodiments of the present inven
`tion, an application Server Situated beyond a cellular net
`work is able to provide data to a group of communication
`devices Situated in the cellular network. Mechanisms and
`procedures are described enabling data distribution to large
`groups also in situations where conventional mechanisms of,
`for example, data multiplication and point-to-point transfer
`may be inefficient or even impossible.
`0032. The group may be a pre-defined group or an open
`group, Such as the Internet relay chat (IRC) channels. In an
`embodiment, the application server 50 may invite members
`to join the group. In an open group embodiment, the
`application Server, Such as the PoC Server, knows the mem
`bers at any given moment, but is also possible that either
`new members are dynamically joined or current members
`leave the group. In an embodiment, the application Server
`may include the multicast address into a media negotiation
`answer when other members join the group when respond
`ing to a group join request from Successive members.
`0033 FIG. 2 shows a signalling chart illustrating an
`exemplifying embodiment. The signals shown in FIG. 2 are
`named on a functional level for illustrating a function or
`purpose of each Signal. Actual Structure of Signals may be
`different or more complex. The Structure of the Signals may
`also depend on Signalling protocol and other Such aspects.
`0034) In step 200, an application server (AS) 50 receives
`an invitation message from a communication device (UEA)
`22 to distribute data. The application server 50 identifies a
`need to distribute data to a group, which appears to be big
`in size. The application server 50 may determine the size of
`the group in various ways. In an embodiment, the applica
`tion server 50 may determine the size of the group by
`parsing the Syntax of a group URI provided by the UE-A. AS
`an example, a group URI may be used for corporate level
`announcements. In an embodiment, the application Server 50
`may know how many members are currently connected to
`the group or how many members will be invited to the
`group. The application Server 50 may have this knowledge
`based on a pre-configured group member list, for example.
`
`Exhibit 1022
`Page 06 of 10
`
`

`

`US 2006/0034202 A1
`
`Feb. 16, 2006
`
`In an embodiment, the request to use multicasting may be
`received from a user. For example, a user client in the
`communication device of the user can have Such an optional
`feature selection. The application server 50 having identified
`the need to distribute data to a big group notices that usage
`of multicast/broadcast may be beneficial and decides to use
`a multicast/broadcast mechanism according to an embodi
`ment of the invention instead of a conventional procedure.
`0035) In step 202, the application server 50 contacts an
`entity responsible of providing MBMS services. This ele
`ment may be e.g. a BM-SC 60, which provides functions for
`service provisioning and delivery. The application server 50
`may reserve resources from the BM-SC 60, for example, by
`a MBMS request message, in order to be able to use the
`MBMS. The application server 50 may negotiate parameters
`related to data transfer Such as Starting times, Stopping times,
`quality of Service (QoS) and So on.
`0036). In step 204, the application server 50 may get an IP
`multicast address from the BM-SC 60 in a response accept
`ing the request for MBMS.
`0037. In steps 206 and 208, the application server 50 may
`send invitations to join a group, such as SIP INVITE
`messages, to all intended members of the group. The invi
`tation messages may include the IP multicast address as the
`source address (e.g. in the c-line of the SIP Service Descrip
`tion Protocol (SDP)). In addition, the invitation message
`may comprise a normal multi-unicast group media descrip
`tion. In addition, the application Server 50 can include, in the
`invitation message, other parameters related to the multicast
`group created, Such as QoS, Starting/stopping time and So
`on. These other parameters may be included, for example, as
`SDP attributes.
`0.038. In step 210, a first intended member of the group,
`UE-B32, having received the invitation message (step 206)
`from the application server 50 reads from the invitation
`message that the intended address is an IP multicast address.
`The intended member UE-B 32 or its application accepts the
`invitation message as proposed and decides to Subscribe to
`MBMS. The UE-B 32 joins the multicast group whose
`address was included in the invitation message by replying
`to application server 50 with a response, such as 200 OK,
`carrying the IP multicast address indicating that the UE-B 32
`has accepted the invitation as proposed. The application
`server 50 will know that the UE-B 32 will be listening to the
`multicast group.
`0039. In step 212, the UE-B 32 may subscribe to MBMS
`Service and become a member of the multicast group by
`Sending a joining message, Such as an IGMP JOIN message,
`to the BM-SC 60. The BM-SC 60 may accept the request,
`for example, by an MBMS accept message, shown in Step
`216. The UE-B 32 is now able to receive the data distributed
`by the application server 50.
`0040. In an embodiment, UE-B 32 may first verify
`whether the IP multicast address offered by the application
`server 50 is available in the area where the UE-B 32 is
`listening. If the UE-B 32 finds that the IP multicast address
`can be heard, the UE-B 32 may respond the application
`server 50. The UE-B may send the joining message at the
`same time when verifying the availability of the IP multicast
`address or Separately before or after having responded to the
`application server 50. Thus, the order of steps 210 and 212
`may change and the Steps may be divided in further Sub
`StepS.
`
`0041. In step 214, a second intended member of the
`group, UE-C 34, having received the invitation message
`(step 208) from the application server 50 reads from the
`invitation message that the other offered address is an IP
`multicast address. The UE-C 34 decides not to Subscribe to
`the group using the MBMS. The UE-C 34 replies to the
`application server 50 with a response, such as 200 OK,
`which contains only the unicast media address of the UE-C
`34, the proposed multicast address being omitted from the
`response. The application server 50 will know from the 200
`OKsent by the UE-C that the UE-C 34 is not listening to the
`multicast group. However, the application Server 50 may
`send data to the UE-C 34 in a conventional way, for example
`by using point-to-point data transfer.
`0042. The application server 50 has now knowledge on
`group members that will listen to multicast group and the
`application server 50 is able to start delivery of data to
`MBMS as shown in steps 218-228 of FIG. 2. In steps 218
`and 220, the application server 50 informs a media source,
`Such as UE-A22, of a created multicast/broadcast Session. In
`step 222, the UE-A22 sends media or data to be distributed
`to the application server 50. In step 224, the application
`server sends the media further to the BM-SC 60. In step 226,
`the application server 50 delivers the media directly to those
`members who are not listening to the multicast group,
`namely the UE-C 34 in FIG. 2. For example, the application
`server 50 may use point-to-point data transfer. In step 228,
`the BM-SC 60 delivers the data using MBMS to those
`members who are listening to the multicast group, namely
`the UE-B 34 in FIG. 2.
`0043. In an embodiment, there may be no direct signal
`ling between the application server 50 and the BM-SC 60,
`instead, the communication device 22 originating the group
`session may obtain a multicast address from the BM-SC 60
`and Signal the multicast address to the application Server 50
`as one of the two media addresses. The application server 50
`may then use that address in the offering the application
`Server Sends to other group members 32.
`0044) In an embodiment, once data is delivered, the
`multicast Sessions can be deactivated by the application
`Server and by individual members using, for example,
`procedures related to the MBMS functionality. For example,
`MBMS procedures defined in 3GPP TS 23.246 V.6.3.0
`(2004-06) or other appropriate procedures may be used. In
`an embodiment, the bearer is not released after a data burst,
`but only when the Session (group) is closed.
`0.045. In the MBMS, as defined in 3GPP TS 23.246
`V.6.3.0 (2004-06), signalling between a GGSN and a BM
`SC is exchanged at a Gmb reference point including user
`specific MBMS signalling and MBMS service specific sig
`nalling. The Gmb represents a network side boundary of the
`MBMS bearer service from a control plane perspective.
`0046) The MBMS service specific Gmb signalling may
`comprise following signalling. The GGSN may establish a
`MBMS bearer context and register at the BM-SC. The
`GGSN or the BM-SC may release the MBMS bearer context
`and de-register the GGSN from the BM-SC. The BM-SC
`may indicate Session Start and Stop to the GGSN including
`Session attributes like QoS or multicast area.
`0047 The user specific Gmb signalling may comprise the
`following signalling. The BM-SC may authorise the user
`
`Exhibit 1022
`Page 07 of 10
`
`

`

`US 2006/0034202 A1
`
`Feb. 16, 2006
`
`specific MBMS multicast service activation at the GGSN.
`The GGSN may report to the BM-SC a successful user
`specific MBMS multicast activation. The GGSN may report
`to the BM-SC when a user specific MBMS multicast service
`is released or deactivated (e.g. when the radio contact is
`lost).
`0048. The BM-SC may initiate the deactivation of a user
`specific MBMS multicast service when the MBMS service
`is terminated at the application layer.
`0049 Reception of an MBMS multicast service may be
`enabled by procedures described in 3GPP TS 23.246 V.6.3.0
`(2004-06) paragraph 4.4.1. These procedures may comprise
`Subscription, Service announcement, joining, Session Start,
`MBMS notification, data transfer, Session Stop and leaving.
`A part of these functions performed in the BM-SC are not
`used in embodiments of the invention. Instead, in embodi
`ments of the invention, the application Server beyond cel
`lular networks may perform Similar procedures.
`0050 A subscription establishes a relationship between a
`user and a Service provider. The Subscription allows the user
`to receive related MBMS multicast service.
`0051 Service announcement and discovery mechanisms,
`e.g. SMS, cell broadcast and so on, in the MBMS may allow
`a user to obtain information about available MBMS ser
`vices. For purposes of the invention, for example when the
`application server is a PoC server, conventional MBMS
`Service announcement mechanisms may not provide
`announcement quickly and/or effectively enough. For
`example, calling or creating a group may be time critical, but
`in a conventional MBMS service announcement, it is not
`known to the BM-SC, which communication devices are
`listening cell broadcasts. Furthermore, using the SMS for
`Sending an announcement in embodiments of the invention
`may be too slow.
`0.052
`In embodiments of the invention, the application
`Server may provide at least in part Service announcement
`and discovery mechanisms. In an embodiment, the applica
`tion Server knows the multicast address and may embed a
`Service announcement in a message Sent from the applica
`tion Server to the communication devices, Such as an invi
`tation message, e.g. SIP INVITE.
`0053. In an embodiment, the communication devices
`may discover, by means of the Service announcement
`mechanism of the MBMS, if the multicast address offered by
`the application server 50 is available in that particular
`location or area. In an embodiment, a communication device
`first verifies whether the multicast address offered by the
`application Server can be heard in the area. If the commu
`nication device finds that the multicast address can be heard,
`the communication device may respond the application
`server, for example by a SIP message, e.g. "200 OK, IP
`multicast'.
`0.054 By joining, a subscriber or user becomes a member
`of a multicast group. The user indicates to the network that
`he/she is willing to receive multicast mode data of a specific
`Service. In an embodiment, after the user has accepted an
`invitation from the application Server, the user joins the
`multicast group proposed by the application Server. Thus, a
`group of