Note: Descriptions are shown in the official language in which they were submitted.
CA 02613478 2007-12-24
WO 2007/002604
PCT/US2006/024840
System and Method of Device Discovery and Control in IP Multimedia
Subsystem Networks
Background
Field of the Invention
[0001] The invention generally relates to IP Multimedia Subsystem (IMS)
networks and,
more specifically, to IMS users that use (perhaps multiple) discovered user
endpoint devices.
Discussion of Related Art
[0002] Commonly deployed wireless communication networks, usually referred
to as 2.5G
networks, support both voice and data services. Typically, mobile handsets are
connected to a
Base Transceiver Station (BTS) using a Radio Access Network (RAN) that uses a
modulation
scheme such as CDMA (Code Division Multiple Access) or GSM (Global System for
Mobile
communications). The BTSs are connected via fixed links to one or more Base
Station
Controllers (BSCs), and the BSCs are aggregated into switches called Mobile
Switching Centers
(MSCs). The MSC is connected to the Public Land Mobile Network/Public Switched
Telephone
Network (PLMN/PS'TN), typically through a gateway switch called the Gateway
Mobile
Switching Center (GMSC). Sometimes the term "core network" is used to
collectively describe
the MSC, GMSC and associated network elements. Voice traffic uses the so
called circuit-
switched paradigm of communications in which circuits are assigned, i.e.,
dedicated, to a call for
its entire duration; the voice traffic is carried using Time Division
Multiplexing (TDM)
switching technology. Signaling traffic uses Signaling System 7 (SS7)
typically as out of band
circuits.
[0003] With the advent of Internet Protocol (IP) networking, IP data
service is offered to
wireless clients by an overlay data network in which a packet control function
(PCF) is
introduced at the BSC level to connect BSCs to an IP-routed network. The PCF
is responsible
for packetization of RAN traffic. On the inbound side (core network to RAN)
the PCF takes IP
packets and reorganizes them for transmission as frames over the radio
transport protocol. On
the outbound side (RAN to core network) the PCF packetizes radio protocol
frames to IP
1
CA 02613478 2007-12-24
WO 2007/002604
PCT/US2006/024840
packets. Data connections are handled by this overlay network and the MSC is
used primarily to
handle circuit-switched voice calls.
[0004] The development of Voice over IP (VolP) technology has resulted in
the MSC being
re-designed to handle packet-switched voice traffic along with existing
circuit-switched traffic.
This new architecture is called a soft switch network. The legacy switch is
disaggregated into a
control and multiplicity of media gateway (MGW) components. The control
component
(sometimes called the soft switch) uses an open control protocol called the
Media Gateway
Control Protocol (MGCP) to manage the MGW. The MGW itself has the ability to
accept both
packet and circuit-switched traffic and convert one to the other, under the
control of the soft
switch. It is thus possible in 2.5G networks to carry both circuit-switched
and packet-switched
traffic.
[0005] It is widely believed that wireless communications will soon be
dominated by
multimedia services. This has resulted in new RAN technologies and the
resulting networks are
called 3G networks. The transition of 2.5G to 3G networks emphasizes packet
traffic and new
architectures have been proposed to handle multimedia sessions, such as
Quality of Service
(QoS).
[0006] A defining characteristic of 2.5G/3G multimedia services is that
since the handset can
send or receive IP data packets at any time, the IP context of the handset is
maintained as long as
the handset is powered on and connected to the network. This is in contrast to
traditional
telephony where the state of a connection is maintained only while a telephone
call is in
progress.
[0007] In particular, in 3G networks the services are to be provided by so-
called Application
Servers. Consequently the connection between the service logic and the
application server is a
"stateful" connection that needs to be maintained for the duration of the
service being used.
Hence a very large number of stateful connections need to be maintained
between the application
server complex, hosted in the application domain, and the service logic
complex hosted in the
service logic domain, in a network servicing a large number of subscribers.
Such stateful
connections that cross administrative domains have high networking costs and
are difficult to
maintain operationally.
2
CA 02613478 2007-12-24
WO 2007/002604
PCT/US2006/024840
[0008] Typical of proposals for 3G network architecture is the IP
Multimedia Subsystem
(IMS) architecture, shown in Fig. 1. IMS is independent of the type of access
network; that is, it
applies both to wireless and landline networks. Examples of access networks
include various
flavors of Wi-Fi networks, GPRS, and HSDPA networks. IMS uses Session
Initiation Protocol
(SIP) for control and signaling messages. SIP is an 1P-based signaling
protocol designed for
multimedia communications. The IMS architecture introduces several control
functions, i.e.,
functional entities, to manage the network. The legacy circuit-switched
traffic is handled by an
Inter-working Function called the BGCF (Breakout gateway control function).
The MGW is
controlled by a new function called the Media Gateway Control Function (MGCF),
and the
media processing functions are performed by the Media Resource Function
Processor (MRFP),
which is controlled by the Media Resource Control Function (MRCF).
[0009] The basic call server called the Call State Control Function (CSCF)
is logically
partitioned into three functional entities, the Proxy, Interrogating and
Serving CSCF.
[0010] The Proxy Call State Control Function (P-CSCF) is the first contact
point for the
handset, also referred to herein as the User Entity (UE,) within MS and
provides the following
functions:
1. Forward SIP register request received from the UE
2. Forward SIP messages received from the UE to the SIP server
3. Forward the SIP request or response to the UE
4. Detect and handle an emergency session establishment request
5. Generate Call Detail Records (CDRs)
6. Maintain Security Association between itself and each UE
7. Perform SIP message compression/decompression
8. Authorize bearer resources and QoS management
3
CA 02613478 2007-12-24
WO 2007/002604
PCT/US2006/024840
[0011] The Interrogating CSCF (I-CSCF) is mainly the contact point within
an operator's
network for all INIS connections destined to a subscriber of that network
operator, or a roaming
subscriber currently located within that network operator's service area. It
provides the
following functions:
1. Assign a S-CSCF to a user performing SIP registration
2. Route a SIP request received from another network towards the S-CSCF
3. Obtain from Home Subscriber Server (HSS) the Address of the S-CSCF
4. Forward the SIP request or response to the S-CSCF as determined above
5. Generate Call Detail Records
[0012] The Serving CSCF (S-CSCF) actually handles the session states in the
network and
provides the following functions:
1. Behave as SIP Registrar: accept registration requests and make its
information
available through the location server
2. Session control for the registered endpoints' sessions
3. Behave as a SIP Proxy Server: accept requests and service them internally
or
forward them on
4. Behave as a SIP User Agent: terminate and independently generate SIP
transactions
5. Interact with application servers for the support of Services via the liVIS
Service
Control (ISC) interface
6. Provide endpoints with service event related information
7. Forward SIP message to the correct CSCF
8. Forward the SIP request or response to a BGCF for call routing to the PSTN
or
CS Domain
4
CA 02613478 2007-12-24
WO 2007/002604
PCT/US2006/024840
9. Generate Call Detail Records
[0013] The P-CSCF is the first point of contact for a UE (handset) in an
IMS network. The
I-CSCF then helps in establishing which S-CSCF "owns" the UE.
[0014] Figure 2 is a signaling diagram, showing the call flow for a UE when
it first
establishes contact with an INIS network. The UE sends a "register" request to
the proxy (201,
202). Assuming the proxy determines that the UE is registering from a visiting
domain, it
queries the DNS to find the I-CSCF in the UE's home domain (203). The proxy
then sends the
registration information to the I-CSCF (204). The HSS checks if the user is
already registered
and sends the address of the S-CSCF in response (205, 206). An authentication
process now
ensues in which the UE is challenged to provide valid authentication vectors
(207-211). Once
the authentication procedure is completed (212-218), the S-CSCF informs the
HSS that the UE is
registered (219-225).
[0015] The HSS provides initial filter codes (IFCs) to the S-CSCF. The IFC,
in effect, maps
the service codes with various application servers (ASs). Thus, if the UE
later issues a service
request or if the service is otherwise triggered the mapped AS will be
invoked. The IFC is
effectively the "call model" for the UE. These call models are static objects
downloaded during
registration from the HSS. Every UE in the domain of the S-CSCF will, if they
have the services
enabled at all, have the same application servers (ASS) mapped to the same
services. For
example, push-to-talk service for each and every UE having such service will
point to the same
AS or point to an AS with identical service logic to provide the identical
push-to-talk
functionality.
[0016] Registered UEs may use services by initiating a new session
establishment procedure
depicted in Figure 3. The Figure shows a session establishment request
originating with a S-
CSCF (called O-SCSCF) or I-CSCF (called O-ICSCF). This request is routed to
the
"terminating" S-CSCF (T-SCSCF), which consults the callee's service profile
(301). Based on
the service profile of the originating registered user, the T-SCSCF sends an
]MS service control
request (ISC) to the corresponding application server (T-AS) that can handle
this service request
(302). The T-AS provides the service to the callee and terminates the session
(303) and the S-
CSCF terminates the application activation process (304).
CA 02613478 2007-12-24
WO 2007/002604
PCT/US2006/024840
[0017] As an illustrative example, consider the case of voice mail in which
callers to a
certain user may leave a voice message if the called user does not respond to
the call. This voice
mail service is provided by an application server (AS) dedicated to this
service and having
service logic to provide such functionality. The S-CSCF transfers control to
the voice mail
application server when a certain service point trigger (SPT) occurs, i.e., an
event occurs that
causes a trigger within the SPT to "fire." The IFCs that provide trigger
points to the service
logic of the S-CSCF are downloaded into the S-CSCF during user registration at
session
initiation time and remain fixed for the duration of the session. The service
profile described
above that is consulted by the T-SCSCF is a static object in the sense that
the information
contained in it is defined once at the time of service inception.
[0018] The coverage area of a service provider is typically partitioned
into geographical
regions called cells. Each cell is served by a BTS, i.e., the BTS radiates
energy within a cell.
Allocating frequencies to cells in a judicious manner allows re-use of
frequencies and, hence, to
more efficient use of the operator's spectrum allocation. As a mobile handset
roams across cell
boundaries, its reception of the signal being radiated by the BTS varies. A
crucial component of
wireless communication networks is the ability to hand off a moving handset
from one BTS to a
neighboring BTS. Various handoff algorithms are known in the literature.
Broadly speaking, all
handoff technologies fall into one of two types: hard handoff, and soft
handoff.
[0019] In hard handoffs the connection between the current BTS and the
handset is severed
and a new connection is established between a new BTS and the handset while a
telephone call is
ongoing. The decision to sever the old connection and start a new connection
is based on a pre-
determined threshold value of the received signal. In soft handoff
technologies the signal
strength from two (or more) BTS are compared and the one that has the higher
value is selected.
The main advantage that handoffs provide is that ongoing calls remain
connected as the handset
roams in the coverage area. Since the region in which a BTS radiates is
limited, a handset that
roams out of the range of a BTS will lose connection with the BTS and hence
any ongoing call
will be dropped. Handoffs ensure that the handset remains connected to some
BTS and any
ongoing calls do not get dropped.
[0020] As the bandwidth provided by wireless networks increases, it is now
possible to send
and receive multimedia information to handsets. Thus, handsets are no longer
used only to make
6
CA 02613478 2007-12-24
WO 2007/002604
PCT/US2006/024840
and receive telephone calls. Rather handsets are envisioned to send and
receive multimedia
information such as video clips, audio files, etc. Handsets have become
general purpose
computing and communication devices. Wireless networks are now expected to
provide
broadcast content, video telephony, multimedia conferencing, video streaming
services, file
upload and download services, and interactive multimedia services.
[0021] However, the availability of network coverage supporting multimedia
services is
highly uneven. In some areas several networks may be available simultaneously
that could be
used by a handset, whereas in other regions there may be insufficient coverage
to support a given
network service. For example, at a given location one may have several short-
range Wi-Fi or
WiMax networks, or lxRTT EVDO, that could provide multimedia services to a
handset
(assuming that the handset is capable of supporting multiple modulation
schemes).
[0022] A handset, however, has an inherent disadvantage since its form
factor is generally
not suitable for long term use as a display device. The small size of the
handset display screen is
not amenable to long duration sessions or sessions in which the handset is
jointly viewed by
several users. In such cases it would be desirable to view the multimedia
services on a larger
LCD or a TV display device. Many such devices support LAN connections directly
or indirectly
via commercially available media plugs. Moreover, such devices may also
support short range
wireless networks such as Wi-Fi and WiMax.
[0023] The wireless world is increasingly becoming a world of multiple
networks. Some are
short range and others support longer ranges of coverage. The information-
carrying capacity of
these networks varies widely from network to network. Handsets increasingly
support multiple
wireless connections, including both short range networks such as Bluetooth
and Wi-Fi, and long
range cellular networks.
Summaty
[0024] The invention provides systems and methods for implementing digital
home networks
having a control point located on a wide area network. The control point may
be implemented
on a serving node connected to the wide area network, and have the capability
of working in
conjunction with one or more control point proxies that are located in
handsets connected to a 3G
wireless network, or in remote control units located within the home. The
control point and
7
CA 02613478 2007-12-24
WO 2007/002604
PCT/US2006/024840
control point proxies cooperatively negotiate media delivery from a user-
selected media server,
such as a home stereo or DVD player, to a user-selected media renderer, such
as a TV display or
the display on a handset. The control point proxies also include VCR controls
for controlling the
presentation of the selected media delivery.
[0025] In general, in one aspect, the invention features a method of
controlling and
delivering media content from a media server (MS) to a media renderer (MR)
utilizing a wide
area IMS network for control. The method involves: provisioning a serving node
in the IMS
network with control point (CP) logic that includes logic to negotiate media
content delivery
with at least one of an MS and an MR; provisioning a user endpoint (UE) device
of the IMS
network with control point proxy (CPP) logic that includes (i) logic to
negotiate media content
delivery with at least one of an MS and an MR, (ii) logic to cooperate with CP
logic to negotiate
media content delivery between an MS and an MR, and (iii) VCR controls to
control a
presentation of content provided by the MS and rendered by the MR; in response
to a media
content delivery request, determining a network context of the UE and a
network connectivity of
the MS and MR; invoking the CPP logic and the CP logic to cooperatively
negotiate media
content delivery between an MS and an MR if one of the MS and MR are not in
communication
with the UE via a local wireless network; and once media content delivery is
negotiated,
controlling a presentation of delivery via the VCR controls on the UE.
[0026] Other aspects include one or more of the following features. The
CPP logic is
invoked to negotiate media content delivery between an MS and an MR if the MS
and MR are
both in communication with the UE via a local wireless network. The local
wireless network is a
Wi-Fi network, a WiMax network, or a Bluetooth network. The CP logic is
invoked to negotiate
media content delivery between an MS and an MR if neither the MS nor the MR
are in
communication the UE via the local wireless network. The UE may be implemented
on a
handset, and the handset may include a display that is used as the media
rendering device. At
least one of the MS and the MR is on a 3G network and in communication with
the serving node.
The UE is in communication with the MR or with both the MS and the MR via a
local wireless
network. The CP logic negotiates service delivery from the MS, the MS being on
a 3G network,
the CPP logic in the UE negotiates delivery on the MR, and the CP logic and
CPP logic execute
synchronization logic to complete the negotiation of delivery from the MS to
the MR. The UE
communicates its network context to the serving node and the serving node
informs the UE of
8
CA 02613478 2014-01-22
78623-28
the serving node's capabilities for negotiation with devices local to the UE.
The CP logic is
configured to serve multiple unrelated devices running CPP logic; these
devices can be
handsets and remote control units. The principal CPP can depend on the
location of the user;
for example, the user may use the CPP logic in the handset when the user is
remote from the
MR and use the CPP logic in a remote control unit when the user is local to
the MR. If one of
the MS and MR are remote from the UE, the CPP logic provides information about
invoked
VCR controls to the CP logic on the serving node to allow the CP logic to
control the remote
MS or MR. The MS and the MR may both be a part of a digital home network. The
UE may
discover local devices that can act as an MS or an MR by using Universal Plug
and Play
(UPnP) protocols. The MS and/or MR may announce their presence to the UE using
at least
one of UPnP protocols, Jini technology, RFID, and Bluetooth. When the CP/CPP
is
negotiating delivery of media content, it may negotiate of out-of-band media
transfer between
the MS and the MR.
[0026a] According to an aspect, there is provided a method of
controlling and
delivering media content from a media server (MS) to a media renderer (MR)
utilizing a wide
area network for control, comprising the acts of: provisioning a serving node
in the network
with control point (CP) logic that includes logic to negotiate media content
delivery with at
least one of the MS and the MR, wherein the CP logic, MS, and MR resides
outside of a user
endpoint (UE) and the CP logic resides in the signaling domain and serves as a
first proxy;
provisioning the UE of the network with control point proxy (CPP) logic that
includes (i)
logic to negotiate media content delivery with at least one of the MS and the
MR, (ii) logic to
cooperate with CP logic to negotiate media content delivery between the MS and
the MR, and
(iii) video cassette recorder (VCR) controls to control a presentation of
content provided by
the MS and rendered by the MR, wherein the CPP logic resides in the UE and
serves as a
second proxy; in response to a media content delivery request, determining a
network context
of the UE and a network connectivity of the MS and MR; invoking the CPP logic
and the CP
logic to cooperatively negotiate media content delivery between the MS and the
MR if one of
the MS and MR are not in communication with the UE via a local wireless
network; and once
media content delivery is negotiated, controlling a presentation of delivery
via the VCR
controls on the UE.
9
CA 02613478 2014-01-22
78623-28
Brief Description of the Figures
[0027] Figure 1 depicts a prior art IMS network.
[0028] Figures 2 and 3 are signal diagrams for a prior art IMS
network.
[0029] Figure 4 is a block diagram showing the principal elements of
the described
method.
[0030] Figure 5 depicts logic for providing per user (or group) call
models.
[0031] Figure 6 depicts internal architecture of a certain embodiment
of the invention.
[0032] Figure 7 depicts logic for providing dynamic call models.
[0033] Figure 8 is a simplified network diagram to illustrate the
interaction between
a UE, a CSCF and an application server.
[0034] Figure 9 is a simplified network diagram to illustrate the
interaction between
a UE, a CSCF, a dynamic network topology database (or ME database) and policy
database.
[0035] Figure 10 depicts utilization of multiple access networks in a
session having an
AVS structure.
9a
CA 02613478 2007-12-24
WO 2007/002604
PCT/US2006/024840
[0036] Figure 11 depicts out-of-band mediation by a control point to use a
potentially non-
IMS service in an IN'S context.
[0037] Figure 12 depicts out-of-band mediation by a control point and a
control point proxy
to use a potentially non-IMS service in an IMS context.
[0038] Figure 13 is a flowchart illustrating how devices and services are
discovered and
associated by the UE.
[0039] Figure 14 is call flow diagram depicting the discovery of a device
by a UE.
[0040] Figure 15 is a call flow diagram depicting the discovery of a device
by a UE and
subsequent handoff to the device.
[0041] Figure 16 is a call flow diagram depicting the discovery of a device
by a UE and the
establishment of a relay session to stream content to the device.
[0042] Figure 17 is a call flow diagram depicting discovery of a device by
a UE and
subsequent streaming of trans-coded information to the device.
Detailed Description
[0043] Preferred embodiments of the invention permit MS user sessions to
utilize devices
that are discovered by the UE during the course of an MS session. The
embodiments provide
for the discovery of available devices, and for choosing whether to add a
discovered device to
the EVIS session. The choice can be made to depend on physical and/or
technical factors, such as
whether the INIS session involves the use of content that could benefit from
the incorporation of
the associated device into the EVIS session. For example, if the user is
receiving video, and a
large-screen TV set is discovered, it would be beneficial for the user to view
the video on the
large screen of the discovered TV set rather than on the small screen of a
handset. In addition,
the decision to include the discovered device can be made to depend on a set
of policies that
involve business relationships (such as of the user to owner/operator of the
available devices)
and cost. The described embodiments allow the signaling channel to remain
intact (i.e., it is not
generally handed over to an associated device) allowing for a consistent
service experience (i.e.,
the application logic can remain in the domain of the original service
provider).
CA 02613478 2007-12-24
WO 2007/002604
PCT/US2006/024840
[0044] Figure 4 depicts relevant portions of an IMS network according to
preferred
embodiments of the invention. The relevant portions include UE 402, P-CSCF
404, I-CSCF 406,
serving node 408, HSS 422, and call model database 416.
[0045] The UE, P-CSCF 404, I-CSCF 406, and HSS are essentially
conventional, though the
content of HSS 422 is not, as described below. However, in certain
embodiments, the UE may
have unconventional agent logic, namely PA logic 424, and search module 426,
each of which is
discussed in more detail below. All of these entities communicate using known
and defined
protocols.
[0046] Serving node 408, in preferred embodiments, includes S-CSCF logic
410 that is
largely conventional though it includes certain modifications, discussed
below. Serving node
408 also includes ME server logic 412 (more below) to store users' dynamic
network topologies
and other information, and provisioning logic 414 more below. (Alternatively,
the ME server
logic and the provisioning logic may each be a separate physical entity like
an AS.) The ME
server and provisioning logic essentially are co-located special purpose
servers within node 408.
The serving node 408, and particularly provisioning logic 414, communicates
with a call model
database 416. This database 416 (not the HSS as is the conventional case) is
used to provide the
call model information for a given user (more below).
[0047] Though not shown in Figure 4, serving node 408 communicates with
application
servers (ASS) that include service logic for various services, e.g., voice
mail, push-to-talk, etc.
The UEs use predefined codes within service requests to identify the service
of interest and/or
these services can be triggered in known specified ways via SPTs (as is the
conventional case).
[0048] Figure 5 depicts the logic flow for provisioning a S-CSCF with
distinct call models
for each user. Under preferred embodiments, the HSS provides initial filter
codes (IFC) during
UE registration (as is the conventional case). However, under certain
embodiments of the
invention, this IFC is programmed in an unusual way. All the service point
triggers (SPTs) for
each service are mapped to provisioning logic 414 (i.e., not to ASs
corresponding to the actual
service codes as is the conventional case.)
[0049] The logic flow starts in 500 and proceeds to 502 in which the first
service request is
received after registration. Because of the default IFC, this service request
will not trigger an AS
11
CA 02613478 2007-12-24
WO 2007/002604
PCT/US2006/024840
corresponding to that service, and instead will trigger activation 504 of the
provisioning logic
414. The provisioning logic 414 will then access 506 the call model database
416. One of the
input parameters will identify the user. The call model database 416 will
retrieve a call model
for that particular user. This call model will include the AS identifiers for
the various services
for that user. The database 416 will provide 508 the call model information to
the provisioning
logic 414 which in turn will provide it to the S-CSCF logic 410 within serving
node 408. The S-
CSCF 410 will construct a new set of filter codes, i.e., NFC, and thus a new
call model, for that
user (and will trigger the service requested initially using the NFC). The NFC
will have SPTs
identifying the corresponding ASs. This approach allows for dynamic
construction of the NFCs
(e.g., post registration) and allows the call model (e.g., NFC with associated
SPTs) to be
constructed uniquely for each user.
[0050] The above logic allows each user to have a call model and NFC that
can differ from
all other call models served by that S-CSCF. This functionality may be used in
many ways.
Per-user differentiated call models is useful though not strictly necessary to
practice preferred
embodiments of the invention.
[0051] This form of per user call model customization, in which different
users may invoke
different service logic functionality for the same given service request, is
not provided in a
conventional IMS network. In conventional IMS arrangements, the HSS provides
static call
models at UE registration. Each user gets the same ASs within their IFC and
thus the same
service experience (for services they are authorized to use). Moreover, the
above approach
allows for full portability of call models. No matter where a UE exists in the
IMS network, that
LTE's call model may be constructed and used for that UE's service experience.
[0052] Figure 6 depicts serving node 408 once multiple users have
registered and been
provisioned with their corresponding call models 602a. .n. Note, the different
call models can
point to different ASs for a given service, and they are not merely multiple
instances of the same
IFacall model. Multimedia network manager 606 receives service requests 608
from the IMS
network and provides service responses 610 to the EVIS network. It also routes
received requests
to the appropriate internal entities as shown. ME server logic and Network Map
policy manager
412 are responsible for receiving information (more below) indicating that the
user's UE
environment has changed with new capabilities or devices, and for building
information
12
CA 02613478 2007-12-24
WO 2007/002604
PCT/US2006/024840
structures and models to reflect these capabilities. In certain embodiments it
also includes logic
to implement specified policies on whether and how to utilize such
capabilities. Provisioned
Service logic 414 is responsible for interacting with external or internal
databases (e.g., database
416 of Figure 4). Media resource manager 612 is responsible for managing other
resources (e.g.,
transcoders) that may be involved with a given service. Multimedia service
manager 604 is
responsible for receiving requests from network manager 606 and for
interacting with the other
components to construct and build the per-user call model 602. In simple cases
this may involve
creating call models with the help of the provisioning logic 414 and call
model database 416. In
other cases the call model construction will be dynamic (more below) using new
devices and
capabilities (as well as associated policies), and in these instances the
manager 604 will involve
ME logic 412, media resource manager 612 as well as handoff control
application server 614.
[0053] The term handoff as used herein denotes the transfer of a service
delivery from one
network and/or device to another network and/or device. The handoff does not
involve the
dropping of an access network connection. This meaning contrasts with the
meaning of the term
that often appears in the prior art (referred to in the background section
above), in which handoff
means the dropping of a first connection in favor of a second connection based
on the relative
signal strengths of the two connections.
[0054] The context of an end user may change. For example, as a user roams,
his or her
context may change. Alternatively, even in non-roaming situations, the user
context may change
as new devices and capabilities emerge or become activated.
[0055] At any given moment, the user may be in close proximity to any
number of devices
that are capable of acting as a UE for a certain service (application). For
example, the user may
be near a TV that could be used to display multimedia content. Or the user may
be in close
proximity to a personal computer that could be used to receive multimedia
information from a
network connection, provided network connectivity and authorization to use
such a device in this
manner could be obtained.
[0056] The described methods allow a roaming user to discover (directly or
indirectly)
several kinds of information and invoke several kinds of corresponding
relevant policies to
consider when and how to use such capabilities and devices:
13
CA 02613478 2007-12-24
WO 2007/002604
PCT/US2006/024840
1. New endpoint devices (UEs or UE devices) that could be used to receive
multimedia
information;
2. New network connections that terminate and emanate from the UE devices;
3. New device capabilities;
4. Policies that govern use of newly discovered devices and new network
connections; and
5. Policies that are implemented by the service provider that control what
devices could be
used for which type of services under what sort of conditions.
[0057] Policies may reside either in the UE or in a designated server in
the network. In a
preferred embodiment, the policies reside in the network.
[0058] An increasing number of mobile handsets support short-range wireless
technologies
such as Bluetooth and Wi-Fi. According to certain embodiments, a "dynamic
profile" is
constructed, in part, by logic that executes in the handset. This logic may be
executed
continuously, periodically at some network determined time interval, or on
demand when the
user requests a particular service. When executed, the logic senses (or
otherwise discovers) the
presence of associated devices in the immediate vicinity of the handset using
a short-range
wireless technology such as Wi-Fi.
[0059] Horne and personal networking systems increasingly feature the
ability to discover
new devices using so-called discovery protocols. One such example is the
Universal Plug and
Play (UPnP) protocol that allows the dynamic discovery of devices. According
to certain
embodiments, dynamic device discovery and service discovery framework within a
user's
personal or home area network is performed. For example, UPnP may be used to
create a
dynamic profile of the immediate environment of the handset (i.e., user)
service environment.
The dynamic device discovery mechanism is used to help create a personalized
user area
network map, which will serve as input to the switching/delivery logic.
[0060] Associated devices may announce their presence by a variety of means
such as but
not limited to Universal Plug and Play Devices (UPnP), Jini discoverable
devices, RFID devices,
and Bluetooth enabled devices.
14
CA 02613478 2007-12-24
WO 2007/002604
PCT/US2006/024840
[0061] Any method of broadcasting the capability of devices can be used.
The sensing logic
in the handset receives such broadcast information and assembles it to
construct a dynamic
profile of the user's immediate context. Since this context changes as the
user roams, the
dynamic profile changes to reflect the current vicinity of the handset. The
dynamic profile is
communicated to the serving node 408. For example, this information may be
communicated as
parameters (e.g., by overloading information elements [lEs] of Session
Description Protocol
(SDP) messages) in conjunction with a special service request dedicated to
communicating
potential UE devices.
[0062] A personal agent (PA) having PA logic 424 executes in UE (handset)
402 and
includes the sensing logic to discover such other potential UEs or associated
devices (more
below). The dynamic profile of the user's immediate environment is
communicated to the ME
logic 412. This is done by having the ME server invoked in response to the
special service
request from the UE for communicating such discovered devices and
capabilities. The ME
service will construct topologies and maps to identify the potential UEs,
other networks, etc., to
reflect the new devices and capabilities discovered or sensed in the UE's
vicinity that could
potentially be used by a given user.
[0063] In certain embodiments, the handset's User Agent profile (UAProf) or
Composite
Capabilities/Preference Profiles (CC/PP) representing device capabilities and
user preferences is
used to personalize the multimedia service delivery framework. Serving node
408 will gather
the UAProf or CC/PP from the endpoint devices to guide control of not only the
rendering and
trans-coding of content to be delivered to that device, but also the
generation of the call agent as
well as the decision to execute that service agent within the network or at
the endpoint.
[0064] The personal agent supports an automated network and service
discovery mechanism,
such as the industry standard Universal Plug and Play (UpnP) framework, to
establish
association with and control of those networked devices. The networked devices
that the PA can
be associated with through the discovery procedure can be connected to the
mobile handset via
wireless connectivity, such as Bluetooth, Jini, self-identifying label
technologies such as RFID,
or Wi-Fi, or via wired connectivity, such as USB or IEEE 1394 links.
[0065] In certain embodiments, the static user profile downloaded by the
HSS into the S-
CSCF at registration time is provisioned by the network operator to contain
the address of the
CA 02613478 2007-12-24
WO 2007/002604
PCT/US2006/024840
ME server. Thus, every communication of the dynamic profile originating from
the UE and
received by the S-CSCF causes a SPT trigger to fire, and control is
transferred to the
corresponding ME server. In this fashion the serving node 408 and more
particularly the ME
server 412 becomes aware of the immediate context of the UE (handset).
[0066] Once the ME server has the information in the dynamic profile, it
consults a database
of policies described by the service operator. These policy descriptions may
be co-located with
the ME logic and even the S-CSCF logic (see, e.g., Figure 6). These policies
prescribe certain
actions that depend on the data contained in the dynamic profile. For example,
a policy can
require that if the UE sensing logic discovers a Wi-Fi connection in its
immediate vicinity, then
this discovered network should be used for originating session requests.
Specific logic
associated with this policy is then executed to send directions to the PA to
enforce this directive
at the UE level. When evoked, the policy decision only changes the behavior of
those UEs that
come under the control of a particular Mobile Virtual Network Operator (MVNO)
(A MVNO is
an operator that use the radio spectrum license-holder's underlying network
facilities to offer
services to the consumer. MVNOs do not typically own network infrastructure or
spectrum
license). Another MVNO may, in general, have a completely different set of
policies. Policies
may not only be specified by the MVNO but also by end users, provided the
network interfaces
allow the users to specify actions that should be taken when certain events
and situations are
discovered in the UE's environment. Such user specified policies may over-ride
policies
specified by the MVNO.
[0067] Figure 7 is a flow diagram illustrating the customization of service
logic. The logic
starts in step 700 and proceeds to step 702 in which the PA logic 424 on the
UE discovers or
senses its immediate environment or context and constructs a message
specifying this dynamic
context. This message may include information about, new devices that could be
used to receive
multimedia information, new network connections that terminate and emanate
from such
devices, and new device capabilities. The PA on the UE sends the message to S-
CSCF (704) and
the message either causes an SPT trigger or it does not, depending on how the
IFC or NFC is
constructed (706). If the Message is triggering event, the logic proceeds to
step 708 in which
control is transferred to the ME server; otherwise the logic terminates (799).
The ME server
updates its internal database to reflect the information communicated in the
message from the PA
in the UE (710). The ME server then applies any relevant policies that will
determine, for
16
CA 02613478 2007-12-24
WO 2007/002604
PCT/US2006/024840
example, whether and how to utilize newly discovered devices and capabilities
(712), and the
logic determines whether any action is specified by the policy (714). If so,
the specified action
is initiated (716). This can be done by customizing the PA logic 424 on the UE
or by
customizing the AS logic. For example, in a typical embodiment, S-CSCF logic
410 will be
modified to initiate or trigger the specified actions after the ME logic has
updated its models
accordingly and perhaps after a new dynamic call model is instructed for that
particular user to
reflect new devices and capabilities.
[0068] In an alternative embodiment S-CSCF logic 410 is not hosted within a
serving node
408 as shown in Figure 4; that is, the S-CSCF 410 is not constrained to be
hosted by the MVNO
domain. In this embodiment the S-CSCF remains hosted in the ]MS serving domain
of the
network operator and is a separate entity, as in a conventional IMS network,
and the ME server
and provisioning logic are configured as ASs, though, as explained above, they
do not provide
conventional IMS services and instead are used in the construction of dynamic
call models.
[0069] The interactions between the CSCF and an AS are summarized in Figure
8. As
outlined above, in IMS networks, all services are provided by application
servers (ASs). In
Figure 8, the network is simplified (for descriptive purposes) to show only
one AS 802, but in
practice there will be multiple ASs. Service requests are sent (directly or
indirectly) from a LTE
402 (see also Figure 4) to a S-CSCF 410 (see also Figure 4). The S-CSCF uses
its internal call
model (see, e.g., 602 of Figure 6) to invoke a corresponding application
server.
[0070] In preferred embodiments, the call model 602 (Fig. 6) (i.e., state
machine) executing
in the S-CSCF 410 for this UE is modified to take into consideration the newly
discovered
devices and network connections as described herein. This newly discovered
information is
stored in the ME server 412. The discovery is done by sensing logic resident
in the UE and may
be communicated to the ME server periodically, or when discovered, or at pre-
designated
intervals. As discussed above, this communication may be done, for example, by
overloading the
information elements of the SDP. The interaction between the ME server 412 and
the CSCF 410
is shown in Figure 9. As described above, the CSCF 410 is invoked with
messages (or
overloaded messages) that include information about discovered devices,
network connections,
new capabilities, etc. The CSCF 410 then invokes the ME server 412 which in
turn consults the
policy database 902.
17
CA 02613478 2007-12-24
WO 2007/002604
PCT/US2006/024840
[0071] In one scenario, a subscriber wanting to view multimedia content
from an Internet
server on his handset initiates an IMS request to serving node 408. The
request emanates from
the UE to the P-CSCF and onwards to the S-CSCF as explained above in
connection with Figure
1. From the S-CSCF it is routed to the ME (acting as an Application server) so
as to perform per
subscriber customization, as explained in connection with Figure 4. This
request then causes a
connection to be made to the serving node 408 (explained in more detail later)
and an MS
session is established between serving node 408 and the UE using the access
network to which
the P-CSCF is attached. This IMS session is uniquely identified by an IMS
Charging ID (ICID)
assigned by the P-CSCF.
[0072] As shown in Figure 10, PPP (Point to Point Protocol) session 1002
has its own unique
identifier called the Transport Charging ID (TCID) 1006 assigned by the device
(Packet data
Gateway or Packet Control Function in the BSC) from which the PPP session
emanates. TCID
1006 and ICID 1008 together uniquely identify the multimedia session in which
the SIP/IMS
signaling is embedded within the 1P/PPP connection.
[0073] The ME function 412 creates or modifies a computational entity
called an AVS
(Audio Video Session)1004 to model and control (in part) the actual access
network connections
for a given user. The call model 602a, discussed previously, is constructed
first, based on the
resources and policies. The AVS, on the other hand, represents what is
actually going on, or
intended to take place, or actually takes place (i.e., dynamically modifying
to context). That is,
the AVS represents the actual connections registered or to be registered in
response to a given
service request. If each access network connection is considered to be a
"session", then the AVS
is a form of meta-session, or a super-session incorporating the access network
sessions. Each
AVS is uniquely identified by a AVID (Audio Video session ED) that is a
function of the
underlying TCID and the ICID.
[0074] An AVS is a representation of every access network that the UE
encounters while
roaming. For each new access network this representation creates a new "leg"
(called Incoming
Call Leg ¨ICL 1012, 1014). Each ICL has associated with it a TCID and an ICID
(generated by
other network elements) that together uniquely identify the session
corresponding to that access
network. Since the AVS 1004 has access to registration information of the UE,
it knows that
various ICLs (and hence various TCID+ICID combinations) really belong to the
same UE, and
18
CA 02613478 2007-12-24
WO 2007/002604
PCT/US2006/024840
hence, for each UE, the AVS representation captures all the access networks
that the handset
encounters. And since some access networks may support circuit-switched (CS)
transport mode
whereas others may support packet-switched (PS) transport modes, ICLs may be
CS or PS
supporting ICLs.
[0075] Network policies (see Figure 9) will generally govern the co-
existence of ICLs within
a single AVS. For example, current telecomm networks do not support the idea
of a UE being
associated with more than one circuit-switched network. This translates into
an AVS constraint:
"only one ICL may exist for CS sessions." Another example of a constraint is
provided by
current so-called Class B handsets in which both a CS and PS protocol stack
are available but
only one such stack can execute at any time. Yet another example is provided
by Class B + Wi-
Fi handsets in which a CS session and a Wi-Fi session, or a Wi-Fi and a PS
session can coexist.
In a Class A handset that supports CS, PS and Wi-Fi contemporaneously, all
three sessions can
be active together. Such constraints, emanating from the network or the
handset, translate into
constraints on the type and number of ICLs can be supported by an AVS. The
policies can be
contained in the policy database, and as with the construction of call models,
the policies may be
accessed when modifying AVSs.
[0076] In one example, a class B UE is engaged in a PS session watching
Mobile TV. The
UE roams into a Wi-Fi zone and a handoff happens, after which the MobileTV
feed uses the Wi-
Fi network. The previous PS session is idle and could be cleared. However,
keeping it around
serves a useful purpose. For example, suppose a voice call arrives for this
UE. Since the CS
stack is not executing in the UE, the call will normally be routed to voice
mail without the user
being informed of the call. But suppose a serving node 408 is informed of the
arrival of this call
(as explained below), and then uses the PS session to present a dialog box
giving the user a
choice to take the voice call. This example shows the usefulness of having
more than one session
(more than one ICL) active. Policies governing a given service will dictate
whether or not to
keep a leg active. Moreover, sometimes a leg may be unavoidably dropped, for
example via lack
of sufficient use, or because of signal issues.
[0077] As stated above, the serving node 408 includes one AVS per user. As
shown in
Figure 10, an AVS 1004 can include multiple ICLs 1012, 1014 and an OCL or OGL
1010
(outgoing call leg). The AVS also includes a control point 1016. As explained
below, the
19
CA 02613478 2007-12-24
WO 2007/002604
PCT/US2006/024840
control point (CP) may be used to provide mediation between some form of
service or server and
the LIE. Not shown in Figure 10 is that each leg may have effectuation
routines to perform or
effectuate routine functions on a given access network, such as responding to
"are you alive"
messages. When the serving node 408 (e.g., via the ME logic) manipulates the
AVS it
corresponds to actions in the "real world." For example, adding an ICL means
getting registered
on that access network.
[0078] Figure 11 illustrates how certain components, particularly the CP
1016 interact with
other entities. It also shows how to incorporate non-1MS (legacy) services
into a network, or to
"marry" multiple networks. As explained below, the CP 1016 within AVS 1004,
can perform
out of band mediation so that a media server (MS) 1104 somewhere in the
network can deliver
content to a media renderer (MR) program 1106 on the UE, which receives and
presents such
content.
[0079] CP 1016 is connected to the MS 1102, which in turn establishes a
connection to the
serving node 408 (using network server specific protocols). The connection
between the CP and
the MS is internal to the ME 412. The connection between the MS and the
serving node 408 is
an Outgoing Leg 1010 of the AVS. That is, AVS 1004 models this connection as
outgoing leg
component 1010. CP 1016 is also connected to MR 1104, which preferable may
reside in the
UE. The connection between the CP and the MR is an Incoming Leg, e.g., 1012.
That is, AVS
1004 models this connection as incoming leg component 1012 or 1014. Thus, in a
session
having multiple MRs there are multiple Incoming Legs for a single AVS, as
shown in Figure 10.
[0080] Continuing with the example above, the CP negotiates multimedia
content delivery
with the MS and instructs the MS to deliver content to an address
corresponding to the MR on
the UE. The instructions provided during such mediation will conform to the
environment,
context, and capabilities of the UE. CP 1016 also negotiates media rendering
with the MR itself
in each Incoming Leg of the AVS. That is, the CP effectively instructs the MR
to start expecting
content from the MS, and to present such. Again, the instructions provided
during such
mediation will conform to the environment, context, and capabilities of the
UE.
[0081] When an access network connection is discovered by the UE sensing
logic and
communicated to ME server 412, and if the policy database 902 (Figure 9)
permits its use, the
newly discovered access network connection is modeled and included into the
current AVS as an
CA 02613478 2007-12-24
WO 2007/002604
PCT/US2006/024840
Incoming Leg. Each access network available to a UE corresponds to an Incoming
Leg of an
AVS and the connection between the CP and MS corresponds to the Outgoing Leg
of the AVS.
[0082] Thus, if the UE has sensed three different access networks and
policy allows all three,
then there are three distinct access network connections between the UE and
the S-CSCF. In
such a situation, there are signaling and bearer channels in each access
network that can be
utilized. It is a matter of policy that decides which signaling channel within
an access network is
to be used and which channels within an access network is to be used for
bearer traffic. In the
case when coverage of an access network is lost (for example, due to roaming
of the UE), the
corresponding access network connection and the associated AVS Incoming Leg is
"cleared"
under S-CSCF serving logic control by the P-CSCF.
[0083] As mentioned above, many new kinds of access networks, such as Wi-Fi
and WiMax,
are being deployed. The proposed EVIS specifications allow the UE to connect
to an access
network. Preferred embodiments of the present invention allow the UE to remain
in
simultaneous connection (or potential use) with multiple access networks and
the choice of
which access network to deliver a particular service to the UE is to be made
by policies resident
in the ME function in the serving node of the network. That is, the AVS
facilitates control of
multiple access networks (both signaling and bearer) and allows choices to be
made (by the
system and perhaps the user) as to which network to use in a given context and
time.
[0084] In conjunction with deployments of various kinds of access networks,
handset
manufacturers are also producing handsets that support multiple radio access
technologies.
Examples of such handsets today are those that support Wi-Fi and GSM/CDMA
cellular
networks. In such handsets, known as Class A handsets, both the circuit-
switched session of the
GSM/CDMA network and the packet-switched session of Wi-Fi can co-exist and be
active
simultaneously. Moreover, there are numerous proposals for voice call handoffs
between
cellular (GSM/CDMA) and Wi-Fi networks.
[0085] Using the described embodiments, a Class A handset can have multiple
packet
sessions and a circuit-switched session simultaneously active in the handset.
In the terminology
explained above, the corresponding AVS may have multiple Incoming Legs
corresponding to
one circuit-switched and multiple packet-switched sessions. Another type of
handset, called a
Class B, handset only supports either a circuit-switched session or a packet
session at any given
21
CA 02613478 2007-12-24
WO 2007/002604
PCT/US2006/024840
time. If the handset roams into a Wi-Fi area from a cellular area, the circuit-
switched session is
replaced by a new packet-switched session supported by the new Wi-Fi network
in a Class B
handset; in a Class A handset the circuit-switched session can be allowed to
persist. This
corresponds to removing one Incoming Leg of the AVS (representing the circuit-
switched
cellular connection) and adding another Incoming Leg (representing the Wi-Fi
connection) to the
underlying AVS for Class B handsets. In the case of Class A handsets in which
the circuit-
switched session is not cleared, the situation corresponds to simply adding
another Incoming Leg
to the AVS session.
[0086] The following scenarios for Class A and B handsets are possible:
1. Two subscribers A and B are in a voice call. The AVS corresponding to this
call for A's
UE may have an Incoming Leg (circuit-switched) for A. The AVS for B's UE has
an
incoming leg ("packet-switched") for B. Thus, A is engaged in a circuit-
switched call
and 'B' is engaged in a packet-switched call; the two parties in the call are
using different
access technologies. This example extends to multiparty calls.
2. Two subscribers A and B are in a voice call. Both users are assumed to be
using packet-
switched sessions (i.e., packet-switched [PS] modulation over the cellular
spectrum).
Under roaming conditions, at some point in this call, assume that both roam
into new
access networks that offer the resources (e.g., bandwidth) to support a video
telephony
sessions between A and B. These new access networks will correspond to new
Incoming
Legs added to the AVSs, along with new media renderers, and the policy in ME
will
dictate the use of the new access networks to support the video call. The new
media
renderers for the video telephony will be OCLs for each of the AVSs ¨ i.e.,
AVS for A
and an AVS for B.
3. Two subscribers A and B are in a voice call. Assume that A is in a circuit-
switched
session and that B is in a packet-switched session. Now assume that A roams
into a new
access network such as Wi-Fi that supports video telephony. This new access
network
corresponds to a new Incoming Leg of the underlying AVS for A. The AVS under
policy
control may now be, as in use case number 2 above, converted into a video
telephony
session. An OCL may be added to correspond to a new OCL for the MR for the
delivery
of video telephony.
22
CA 02613478 2007-12-24
WO 2007/002604
PCT/US2006/024840
4. Two subscribers A and B are in a circuit-switched voice call. A now wishes
to send a
multimedia message including images to 'B.' Assume that both A and B had
previously
roamed into new access networks that correspond to packet-switched sessions
(Incoming
Legs) in the underlying AVS for each. These packet-switched sessions can be
used to
deliver the multimedia object from A to B.
[0087] Scenarios 1-4 show that by having access to multiple access networks
under mobility
situations, the described embodiments allow services that use a combination of
packet and
circuit-switched access network technologies.
[0088] As explained above, mechanisms to utilize non-IMS, legacy services
within an IMS
context are provided. To do this, the system logically separates the control
and bearer parts of
the legacy service. The control component of the service is handled by IMS,
and the bearer
component may remain independent of IMS. The control point (CP) 1016, referred
to earlier, is
the mechanism used to allow "out of band" media transport under control of
IMS. Under
preferred embodiments every AVS 1004 has an associated CP 1016, for example,
logically
within the AVS. More specifically, each AVS is designated to have an "Outgoing
Leg" (OCL)
1010 that contains a CP. The CP has capability to transact with an Application
Server (AS)
using a standard protocol, such as RTSP, and it has the capability to transact
with programs in
the UE called Media Renders (MRs), again using standard protocols such as ST,
or
SOAP/MTP. The CP itself may be considered an Application Server (AS) by the S-
CSCF (i.e.,
interacted with as if it were an AS).
[0089] Now consider a UE requesting Mobile TV service. This request
emanates from the
UE (on an ICL) and is forwarded by the S-CSCF to the CP 1016 acting as an AS
(in standard
IMS fashion). Since the CP acting as an AS has access to IMS charging and
authentication
mechanisms, the first objective of re-using IMS infrastructure for legacy
services is fulfilled.
Once the charging and various other bookkeeping functions have been finished,
the CP contacts
the MobileTV server (e.g., illustrated as Content Server 1018 in Figure 10)
using RTSP protocol.
Alternatively, the CP could pass control to another Application Server that
now contacts the
MobileTV server using RTSP", i.e., there is a chain of Application Servers as
in standard IMS.
(Chaining of application servers is a known technique). The CP instructs the
MobileTV server to
initiate sending media to the UE (at a designed lP address) and instructs the
MR in the UE to
23
CA 02613478 2007-12-24
WO 2007/002604
PCT/US2006/024840
render the incoming media. (See Figure 11.) This media transfer from the MS to
the MR may
use an out-of-band (non IMS) transport such as RTP/UDP/IP. In some situations,
other
approaches to deliver media will be needed. For example, the MobileTV server
may not support
the capability of receiving a service request from client A and initiating
service to a client at a
different address. In this case the MobileTV server will be asked to send the
media to the CP' s
address and it will be forwarded to the UE by the CP, a process called re-
NATting).
[0090] The communication between the CP and the UE for setting up media
rendering and
for other functions uses valuable spectrum. In order to reduce such spectrum-
consuming
communications, the relationship between an MR and a media server can be fixed
a priori and
pre-provisioned. Thus the CP always picks a pre-designated MR for a particular
media server.
[0091] In a preferred embodiment, wireless spectrum-consuming
communications between
the CP, media servers and media renderers are reduced by introducing a CP
Proxy (CPP) that
resides in the UE. This architecture is illustrated in Figure 12.
[0092] As indicated above, UPnP architecture includes three functional
entities: control point
(CP), media server (MS), and media renderer (MR). These may be implemented in
different
physical devices. In a digital home environment, for example, the MS and MR
typically reside
in a TV set and the CP in a remote control unit.
[0093] It is assumed that the MS and MR entities represent abstractions
that capture the
essence of media servers and media renderers. The abstractions allow
programmers to write
general-purpose software that deals with the properties of these entities
without having to deal
with their inner workings. The handling of these inner workings is left to the
implementation of
the media server and the media renderer themselves. Thus, by way of example,
if a program
desires to issue a "suspend" command to an MS, it may use the MS's defined
interface to issue
that command. It is left to the MS to implement the "suspend" command.
[0094] Communications between the CP and an MS and MR use the SOAP/HTTP
protocols.
Direct communication between an MS and an MR is referred to as "out of band,"
since is up to
the MS and MR to select the protocol. One such protocol is RTSP/RTP.
24
CA 02613478 2007-12-24
WO 2007/002604
PCT/US2006/024840
[0095] In one example, the MS implements a video player, the MR implements
an LCD
display, and the CP implements a remote control unit. The CP queries the MS
for a contents
directory and presents that on the display unit, allowing content to be
selected for rendering. The
commands between the CP and MS, and between the CP and MR use SOAP/HTTP. The
communication between MS and MR could use RTSP/RTP.
[0096] In a wireless network in which the CP implements a handset, and the
MS and MR
implement a non-mobile media server and media renderer, the wireless network
could be used to
carry a control protocol between the these three entities, akin to SOAP/HTTP
(but perhaps a
more secure version). However, this approach suffers from the disadvantage
that the control
messages between the CP and the MS, and the CP and the MR use the limited
capacity of the
wireless network.
[0097] In certain embodiments, the UPnP architecture is extended into a
wide area network
environment. One approach, illustrated in Figure 12, reduces control message
traffic over the
wireless network by moving CP 1016 into a network element and running one or
more CPPs
1202 in one or more handset(s). This architecture has two advantages. First,
the communication
between CP 1016 and MS 1102 need no longer use the wireless network. Second,
when CPP
1202 is in close proximity to MR 1104, the handset (CPP) can use an available
Personal Area
Network (PAN), such as Wi-Fi, to communicate with the MR. Since the wide area
wireless
network uses expensive spectrum, these advantages can afford considerable cost
savings.
[0098] In this architecture, the CP and the CPPs need a synchronization
protocol.
Communication between the CP and the CPP could be optimized by using off-peak
times to
communicate and by making the CPP as independent of the CP as possible.
[0099] Moving the control point into the wide area network enables a user
to connect to
services provided by MSs that are not located in the home, such as foreign
television stations. In
addition, MSs, whether in the home or not, can now be rendered on MRs outside
the home, such
as on the handset itself, or on an MR that is in proximity to the handset
running the CPP when
the handset is outside the home, as described above.
[0100] CP 1016 running in the SN can support multiple CPPs. For example,
there can be a
CPP implemented in a handset, and also in a remote control unit. When the user
is inside the
CA 02613478 2007-12-24
WO 2007/002604
PCT/US2006/024840
home, he may prefer to use the remote control unit as the CPP since it may
have a better form
factor for VCR-type controls. On the other hand, when the user is outside the
home, he invokes
the CPP on the handset in order to maintain connection and control with the
home network.
[0101] The above techniques are illustrated by the following communication
sequence. A
subscriber requests a media service to be rendered on a home Wi-Fi-enabled
display device.
CPP 1202 communicates with CP 1016 via internal interface 1204 using the wide
area wireless
network. Subsequent communication between CP 1016 and MS 1102, or between CPP
1202 and
MR 1104 need not use the wireless network. Upon receiving confirmation from CP
1016, CPP
1202 instructs MR 1104 to negotiate an out-of-band service request with MS
1102.
[0102] In the case where the UE is in the proximity of both the desired MS
and the desired
MR and can communicate with them via a PAN, such as Wi-Fi, the CPP in the UE
negotiates the
association between the MS and MR. In this case there is no need to involve
the CP in the SN,
since this would involve unnecessary use of wireless bandwidth. Conversely,
when the UE is
not in the proximity of either the desired MS or the desired MR, the CP
handles the negotiation
and association of both the MR and MS, using fixed communication links instead
of wireless
links.
[0103] Thus, in a wide area networking extension of UPnP, moving the CP
into a network
element, such as the serving node of an IMS session, and placing the CPP into
the handset
optimizes usage of the wireless spectrum usage.
[0104] This architecture also allows normal telephony to be integrated with
UPnP-based
media services. As used herein, normal telephony includes supplementary
features such as call
diversion, three-way calling, and voicemail.
[0105] In an alternative architecture, the CP does not migrate to the core
network, but
continues to reside in the handset. In this peer-to-peer style architecture,
there is no core network
element, but the peer-to-peer signaling uses the valuable and limited
resources of the wireless
spectrum. The network-based architecture, as indicated above, consumes less
wireless spectrum.
[0106] CPP 1202 has local service logic that decides what MR to pick for a
particular media
server. In other words, the CP-MR negotiation is transformed into CPP-MR
negotiation (which
26
CA 02613478 2007-12-24
WO 2007/002604
PCT/US2006/024840
is local to a UE and hence does not use spectrum). Moreover, the CPP policies
and logic can be
updated periodically from the network-resident CP at opportune times.
[0107] In yet another embodiment, the concept of MVNO-customized logic may
be applied
to so-called hybrid networks. In general a hybrid network is a combination of
two or more
individual networks. Examples of digital broadcast networks for joint use are
DVB-H (Digital
Video Broadcast ¨ Handheld), and Media FLO (Forward Link Only). In a hybrid
network, the
broadcast network provides a high capacity but one-way transport for
multimedia (video) traffic,
while the UMTS (Universal Mobile Telecommunications System) network (or other
network)
may provide lower capacity two-way transport for interactive services. In such
hybrid networks,
the UMTS network is used for control and signaling purposes for the services
offered by the
broadcast component network. In this fashion, the UMTS network supplements the
digital
broadcast network by providing a control network or a network for user
interactivity functions.
Conversely, the broadcast network may supplement a UMTS (or other) network by
providing
certain broadcast functionality.
[0108] Since the PA runs in mobile handset environment, the handset has a
direct logical
service interface to the Internet Wide Area Network (WAN) via the 2G/3G
wireless network.
From the UPnP device architecture perspective, the PA serves as an Internet
Gateway Device
(IGD). An IGD is an "edge" interconnect device between a residential Local
Area Network
(LAN) and the Wide Area Network (WAN), providing connectivity to the Internet.
The IGD
typically runs in the local network environment, e.g., on a PC in the WLAN
environment.
[0109] In the search process described below, the discovery, registration,
and use of an
associated device corresponds to the setting up of a new incoming leg of the
AVS session. The
ME server then determines whether there is an advantage to be gained from
switching the media
rendering from the renderer in the handset to a renderer in a discovered
device. The CPP can
then offer a choice to the user as to whether to switch to the new renderer,
or the switch can be
performed automatically.
[0110] A UPnP service manager (SM) is provided in the PA to organize the
services
discovered, as shown in Figure 13. The UPnP service manager performs
device/service search
and also listens to advertisements being sent out by new devices. Figure 13
illustrates exemplary
logic for the service manager. The service manager logic starts (1302) when
the PA detects the
27
CA 02613478 2007-12-24
WO 2007/002604
PCT/US2006/024840
presence of a PAN. The service manager consults a directory of services that
are potentially
available on the PAN (1304). If the UE is seeking to use a service, and it
finds the service
present in the directory, the service manager joins the PAN (1306) and
broadcasts a search
message (1308). When the PA receives responses from the services on the PAN,
it determines
whether the user is authorized to use the desired service, and whether the
service is still available
(1310). If the answer is yes, the process for associating the PA with the new
service takes place
(1312, 1314, 1316, 1318, and 1320). If the UE is seeking to provide a service
in the PAN, and
the service is not already present in the PAN (1304), the service manager
joins the network
(1322) and broadcasts an advertising message (1324). In response, it may
receive messages from
the devices on the PAN (1326), and then proceed to associate itself with PAN
(1314, 1316, 1318,
and 1320).
[0111] Two functions enable the discovery process: search module 426 (see
Figure 4)
running in PA logic 424, and the advertisement module, running in a device to
be added to the
network.
Search Module
[0112] Search module 426 is a UDP-based function in the PA that broadcasts
search
messages whenever the user wants to search for new devices. It communicates
with the user
interface of the service manager and updates a list (in the PA logic 424) of
discovered devices on
the service manager when it finds a new device. It determines whether or not
the device is new
by matching its Universally Unique Identifier (ULTID) against those of the
devices already
discovered. Each device has a unique UUID.
[0113] Search Module 426 consists of the following procedures:
[0114] Discovery: The discovery protocol allows control point proxies, such
as the PA, to
search for devices of interest in the network. A search is carried out by
multicasting a search
message with a pattern equal to a type or identifier for a device or service.
Responses from
service providers/devices contain discovery messages that are essentially
identical to those
advertised by newly connected devices. In other words, the responses to the
outgoing discovery
messages from the PA are similar to the messages the service providers/devices
are themselves
28
CA 02613478 2007-12-24
WO 2007/002604
PCT/US2006/024840
unicasting as their own advertising messages, as described below. The former
are unicast while
the latter are multicast. Below is a format of a Search message:
M-SEARCH * HTTP/1.1
HOST: 239.255.255.250:1900
MAN: ssdp: discover
MX: seconds to delay response
ST: search target
[0115] Response: In a response, the discovered device sends a message to
the M-SEARCH
source IP address and port that sent the discovery request to the multicast
channel. This response
follows the same pattern as listed for NOTIFY with "ssdp: alive" (see below in
the description of
the advertising module) except that a search target (ST) header is used
instead of the new target
(NT) header. The format is as follows:
HTTP/1.1 200 OK
CACHE-CONTROL: max-age = seconds until advertisement expires
DATE: when response was generated
EXT:
LOCATION: URL for UPnP description for root device
SERVER: OS / version, UPnP / 1.0, product / version
ST: search target
USN: advertisement UUI
[0116] Description: After the PA has discovered a device, the PA still
knows very little about
the device. In order to learn more about the device and its capabilities, or
to interact with the
29
CA 02613478 2007-12-24
WO 2007/002604
PCT/US2006/024840
device, the PA retrieves the device's description from the URL provided by the
device in the
discovery message. The PA sends the following request header to the discovered
device:
GET path to description HTTP/1.1
HOST: host for description: port for description
ACCEPT- LANGUAGE: language preferred by control point.
[0117] By default the 'Host' and 'Accept' header fields in the request
headers are sent,
following normal conventions, such as from HTML. Once the socket is created,
where the
HostName and RemotePort properties are set to the values specified in the
LTRL, the request
header block is then sent to the discovered device, which consists of the
command (GET) and the
other header fields defined above. A sample of a device description in the XML
format is
shown:
<serviceList>
<service>
<serviceType>Telephony</serviceType>
<SCPDURL>URL to service description</SCPDURL>
<controlLTRL>URL for controkkontrolLTRL>
<eventSubLTRL>URL for eventing</eventSubURL>
</service>
</serviceList>
CA 02613478 2007-12-24
WO 2007/002604
PCT/US2006/024840
Advertisement Module
[0118] When a device is added to the network, it advertises its services to
control points by
multicasting discovery messages to a standard address and port at regular time
intervals. Serving
as an UPnP control point, the PA listens to this port to detect when new
capabilities are available
on the network. Each advertisement message contains information specific to
the embedded
device or service as well as information about its enclosing device. Messages
should include the
duration until the advertisements expire. If the device becomes unavailable,
the device will
either explicitly cancel its advertisements, or wait for the advertisements to
expire on their own.
[0119] The advertisement module in the PA listens for advertisement
messages. It is also a
UDP-based application that listens on port 1900 (as given in the UPnP
specifications). It
communicates with the user interface of the service manager and updates the
list of discovered
devices on the service manager when it finds a new device. It determines
whether or not the
device is new by matching its UM against those of the devices already
discovered.
[0120] The service manager is needed because more than one service may be
present in the
Personal Area Network (PAN) and the manager provides an easy and intuitive way
for the user
to manage all the discovered services/devices. In addition, the service
manager is responsible for
communicating the updated PAN neighborhood configuration (i.e., context) of
the mobile
handset to serving node 408. The discovered device and service will be
reported to the serving
node 408 in a SIP message which includes an SDP extension header. The service
manager
enables the mobile handset user to accomplish this.
[0121] When a new device is added to the list in the service manager a
timer is started whose
value depends on the cache-expiry value sent by the device. Once this timer
expires, the
device/service is removed from the list. However, if an advertisement message
is received from
that device the timer is restarted.
[0122] The format of the multicast message is as follows: values in italics
are placeholders
for actual values.
NOTIFY * HTTP/1.1
HOST: 239.255.255.250:1900
31
CA 02613478 2007-12-24
WO 2007/002604
PCT/US2006/024840
CACHE-CONTROL: max-age = seconds until advertisement expires
LOCATION: URL for UPnP description for root device
NT: search target
NTS: ssdp: alive
SERVER: OS / version, UPnP / 1.0, product / version
USN: advertisement ULTBD
UPnP Device Discovery
[0123] The following case illustrates by way of example a session that
involves the PA client
discovering an associated device via UPnP Discovery mechanisms. In this
example, the new
device to be associated with the PA client is powered on and starts
advertising its service and
device descriptions. For example, the new device might be a PC with IGD
software, whose
display will be used as a media renderer.
[0124] As depicted by 1401a, 1401b, and 1402 in Figure 14, when a device is
added to the
network, the device is allowed to advertise its presence on the network using
Simple Service
Discovery Protocol (SSDP). The UPnP discovery procedure operates transparently
on top of
various wireless or wired PANs or Home Area Networks (HANs), such as
Bluetooth, Wi-Fi,
USB, etc. When a control point such as the PA INIS/SIP mobile client is added,
the control point
is similarly allowed to generate a multicast search for devices. In either
case, the message
exchange consists of a brief description of the device that includes the UPnP
device type, the
device ID, and a URL to the full device description. The message formats are
as described
above.
[0125] Next, as depicted by steps 1403-1406 in Figure 14, the UE obtains
more information
about a specific device by retrieving the full description from the URL with
HTTP GET. The
full description is composed of a device description and a service
description. The device and
service descriptions are XML documents and are constructed by the device
vendor with the aid
of the device and service template schemas. The service description contains
details of the
32
CA 02613478 2007-12-24
WO 2007/002604
PCT/US2006/024840
hosted API commands, which are called actions, along with parameters, which
are called
arguments.
[0126] As shown by 1407 in Figure 14, once the device and service
descriptions of a
particular media device in the PAN/HAN have been retrieved, the PA IMS/SIP
mobile client has
established an association with that device, completing the UPnP device
discovery process.
Associated Device Discovery and Handoff Session via UPnP
[0127] The following case illustrates a session that involves the PA client
discovering an
associated device via UPnP Discovery mechanisms, and the serving node
triggering a handoff
procedure from the PA client to the associated device to initiate a real time
streaming protocol
(RTSP) streaming session. In this example, an IMS/SIP session has been
established between the
PA and the Media Server Control AS in the serving node.
[0128] As depicted by 1501-1507 in Figure 15, the discovery and association
of the new
device proceeds as described above. Next, as shown by 1508a, 1508b, and 1508c,
the PA
IMS/SIP mobile client, located in the user's home network, includes the newly
associated device
information in the SIP RE-INVITE message it sends to Handoff Control
Application Server (AS)
module 614 (within serving node 408). In this message, the mobile station (MS)
or UE includes
its original SIP user identifier into the from-field of the SIP header. It
also includes its new IP
address into both the Contact field of the SIP header, in order to inform the
corresponding host
where it wants to receive future SIP messages, and also into the c
(Connection) field of the SDP
header that contains a description of the session, in order to redirect the
data traffic flow towards
its new location.
[0129] As depicted by 1509 in Figure 15, the information about the newly
discovered device
is added to the ME framework database entry associated with the mobile device.
In addition, as
depicted by 10 in Figure 15, the new device discovery/association event may
trigger a handoff
control decision to be executed in the Handoff Control Application Server
module 614. This
decision is driven by policy logic in policy database 902 (see Figure 9). The
policy logic
includes rules that depend on technical specifications of the discovered
device that determine
whether the discovered device, if associated with the ongoing ]MS session,
would add value to
33
CA 02613478 2007-12-24
WO 2007/002604
PCT/US2006/024840
the user. The policy logic may also include business-based rules that reflect
the relationship of
the user to the owner/operator of a discovered device.
[0130] As depicted by 1511a, 1511b, and 1511c in Figure 15, if a handoff
event is triggered,
the response from the serving node towards the PA mobile client includes the
handoff control
information.
[0131] As depicted by 1512 and 1513 in Figure 15, the PA IMS/S1P mobile
client issues a
SOAP remote procedure call to the media renderer (i.e., the device that
renders the media) to
initiate a RTSP streaming session. Services (i.e., media renderer) keep state
tables updated so
that control points can obtain meaningful values. When state variables change,
events are
broadcast over the home IP network to all interested control points, which may
include multiple
handsets having PAs and CPPs in a home environment.
[0132] As depicted by 1514 and 1515 in Figure 15, the media renderer
initiates the RTSP
signaling transactions to establish a streaming session with the media server.
As depicted by
1516 in Figure 15, the PA mobile client sends a SOAP remote procedure call to
the media
renderer to PLAY the multimedia stream.
[0133] As depicted by 1517 in Figure 15, the media renderer sends the RTSP
Play command
to the streaming media server to start the media stream. This stream is out-of-
band transport of
the media stream from the media server to the media renderer.
[0134] As depicted by 1518a, 1158b, and 1518c in Figure 15, the user may
optionally decide
to disengage the serving node from controlling the media server and allow the
media control to
be handled directly from the media renderer. In this case, the PA mobile
client sends a SIP RE-
lNYFIE message towards the media server control application in the serving
node to disengage.
Associated Device Discovery and Relay Session via LTPnP
[0135] The following case illustrates a session that involves the PA client
discovering an
associated device via LTI3nP discovery mechanisms, and the serving node
triggering a relay
procedure to allow RTSP streaming content to be relayed from the PA client to
the associated
device. In this case, the media transport takes place over the 2G/3G network
to the handset, and
from the handset it is relayed to a discovered associated device using a
WLAN/PAN.
34
CA 02613478 2007-12-24
WO 2007/002604
PCT/US2006/024840
[0136] In this example, the PA acts as a SIP UE and an ItvIS/SEP session
has been established
between the PA and the Media Server Control AS in the serving node.
[0137] As depicted by 1601 to 1609 in Figure 16, the steps involving
discovery are as
described above in connection with Figure 15.
[0138] As depicted by 1610 in Figure 16, the new device
discovery/association event triggers
an action to have the PA relay the content to the newly associated device.
[0139] As depicted by 1611a, 1611b, and 1611c in Figure 16, the response
from the serving
node towards the PA client includes the relay control information.
[0140] As depicted by 1612 and 1613 in Figure 16, the PA client issues a
SOAP remote
procedure call to the associated device, which, in this case, is a media
renderer, to establish a
LTPnP LAN connection.
[0141] As depicted by 1614 and 1615 in Figure 16, the PA client, serving as
an UPnP media
server device initiates the RTSP signaling transactions to establish a
streaming session.
[0142] As depicted by 1616 in Figure 16, the associated device operating as
an LTPnP media
renderer sends a SOAP remote procedure call to the PA client to initiate the
PLAY action to start
the multimedia stream.
[0143] As depicted by 1617 in Figure 16, the PA client sends the RTSP PLAY
command to
the multimedia server to start the media stream.
[0144] As depicted by 1618a, 1618b, and 1618c in Figure 16, the user may
optionally decide
to disengage the serving node from controlling the media server and allow the
media control to
be handled directly from the media renderer. In this case, the PA client sends
a SIP RE-INVITE
message towards the media server control application in the ASN to disengage.
Dynamic Media Resource Control
[0145] This case illustrates a session that involves the PA client
discovering an associated
device via LTPnP Discovery mechanisms, and the serving node triggering a
handoff procedure to
allow RTSP streaming content to be relayed from the PA client to the
associated device. In
CA 02613478 2007-12-24
WO 2007/002604
PCT/US2006/024840
addition, the serving node also determines that the content to be delivered to
the newly
associated device via the PA (relay) requires trans-coding and directs a Media
Resource Control
Function (MRCF) to establish the trans-coding session. Transcoding can
involve, for example,
changing the spatial or and/or color resolution of a video stream to take
advantage of higher
resolution viewing capability on a discovered device.
[0146] As described in detail below, in this case the MRCF responds to the
INVITE request
with a 200 OK message indicating the selected media in the SDP. The MRCF will
also reserve
the requested local resources at that time and return the appropriate resource
identifiers in the
200 response.
[0147] In one embodiment, the Media Server Control AS controls a trans-
coding session and
is aware of MRCF capabilities. The MRCF accepts INVITE requests sent from the
AS, via the
S-CSCF, to dynamically set up the trans-coding configuration. The INVLUE sent
to the MRCF
contains sufficient information to support the RTSP session that requires
trans-coding. The
MRCF always grants the requests from the AS, unless it has reached its
resource limits.
[0148] It is assumed that the PA is acting as a SIP UE and that an IMS/SIP
session has been
established between the PA and the Media Server Control AS in the serving
node.
[0149] Figure 17 illustrates the steps involved in setting up the MRCF to
provide trans-
coding for a mobile originated session, where the MRCF is receiving directions
from the AS
operating as a back-to-back user agent (B2BUA). In other words, the AS can
initiate
calls/sessions itself. In Figure 17, the number enclosed within the square
brackets, i.e., the "[x]"
notation, is an indicator of a particular SIP dialog.
[0150] As depicted by 1701 in Figure 17, the media renderer device is
discovered by the PA,
as described in detail above.
[0151] After the Handoff Control AS has triggered a PA relay action, an
RTSP streaming
session is initiated from the mobile handset (1702-1719). The Media Server
Control AS is aware
of the different codec requirements between the PA client in the mobile
handset and the newly
associated device by retrieving the ME framework parameters reported by the PA
when the
newly terminal device is discovered and associated.
36
CA 02613478 2007-12-24
WO 2007/002604
PCT/US2006/024840
[0152] The Media Server Control AS serves as a B2BUA and interacts with the
originating
UE as usual to establish the dialog. The Media Server Control AS interacts
with the MRCF
using a third party control model, as defined in lETF RFC 3264.
[0153] The Media Server Control AS requests trans-coding facilities from
the MRCF (1720).
The request includes the appropriate trans-coding requirements and resources
to be established.
A separate dialog is established from the Media Server Control AS to the MRCF
for the PA
client.
[0154] The offer/answer model is used for SDP negotiation between the Media
Server
Control AS/S-CSCF and the MRCF.
[0155] The MRCF should always grant the requests from the AS (unless there
is a resource
problem). The MRCF responds to the INVITE request (1721, 1722) with a 200
response
indicating the selected codec in the SDP (1723, 1724). The MRCF will also
reserve the
requested local resources at that time.
[0156] The media from the PA LTE is connected at the trans-coding resource
at the Media
Resource Function Processor (MRFP).
[0157] The selected codec is included by the Media Server Control AS in the
183 response to
the LTE. (not on Fig.)
[0158] The receipt of the ACK at the MRCF (1725, 1726) triggers the start
of the trans-
coding session (1727-1730).
[0159] It will be further appreciated that the scope of the present
invention is not limited to
the above-described embodiments but rather is defined by the appended claims,
and that these
claims will encompass modifications and improvements to what has been
described.
[0160] This application is related to U.S. Patent Application No.
11/370,793, filed March 8,
2006, entitled "Digital Home Networks Having a Control Point Located on a Wide
Area
Network"; U.S. Patent Application No. 11/166,407, filed on June 24, 2006,
entitled "Method and
System for Provisioning IMS Networks with Virtual Service Organizations Having
Distinct
Service Logic; and U.S. Patent Application No. 11/282,924 filed November 18,
2005, entitled
37
CA 02613478 2007-12-24
WO 2007/002604
PCT/US2006/024840
"lMS Networks with AVS Sessions with Multiple Access Networks", the entire
contents of
which are incorporated herein by reference.
[0161] What is claimed:
38
