One document matched: draft-liu-distributed-mobility-02.xml
<?xml version="1.0" encoding="UTF-8"?>
<!DOCTYPE rfc SYSTEM "rfc2629.dtd" [
<!ENTITY rfc2119 PUBLIC ''
'http://xml.resource.org/public/rfc/bibxml/reference.RFC.2119.xml'>
]>
<?xml-stylesheet type='text/xsl' href='rfc2629.xslt' ?>
<?rfc toc="yes"?>
<?rfc symrefs="yes"?>
<?rfc sortrefs="yes"?>
<?rfc iprnotified="no"?>
<?rfc strict="yes"?>
<?rfc compact="yes" ?>
<?rfc subcompact="yes" ?>
<rfc category="info" ipr="trust200902" docName="draft-liu-distributed-mobility-02">
<front>
<title abbrev="DMM"> Distributed mobility management </title>
<author initials="D."surname="Liu"fullname="Dapeng Liu"><organization>China Mobile</organization><address>
<postal>
<street>Unit2, 28 Xuanwumenxi Ave,Xuanwu District</street><city>Beijing 100053</city><country>China</country></postal>
<email>liudapeng@chinamobile.com</email></address>
</author>
<author initials="Z."surname="Cao"fullname="Zhen Cao"><organization>China Mobile</organization><address>
<postal>
<street>Unit2, 28 Xuanwumenxi Ave,Xuanwu District</street><city>Beijing 100053</city><country>China</country></postal>
<email>caozhen@chinamobile.com</email></address>
</author>
<author initials="P.S."surname="Seite"fullname="Pierrick Seite"><organization>France Telecom - Orange</organization><address>
<postal>
<street>4, rue du clos courtel, BP 91226</street><city>Cesson-Sevigne 35512</city><country>France</country></postal>
<email>pierrick.seite@orange-ftgroup.com</email></address>
</author>
<author fullname="H Anthony Chan" initials="H" surname="Chan">
<organization>Huawei Technologies</organization>
<address>
<postal>
<street>1700 Alma Ave</street>
<city>Plano, TX 75075</city>
<country>USA</country>
</postal>
<email>anthonychan@huawei.com</email>
</address>
</author>
<date month="July"year="2010"/><area></area><workgroup></workgroup>
<abstract><t> Current mobility solutions generally introduce an anchor point in the
network, e.g., HA in MIPv6, LMA in PMIPv6, GGSN in 3GPP. The anchor
point is used to maintain the mapping between the stable IP address
(e.g., Home address in MIPv6) and the current routable IP address (e.g.,
CoA in MIPv6). However, one of the trend
in mobile network evolution is to "flatten" mobility architecture by
confining mobility support in the access network, e.g. at the access
routers level, keeping the rest of the network unaware of the
mobility events and their support. This document discusses the
deployment of current IP mobility mechanisms in such a flat architecture.
</t>
</abstract>
</front>
<middle>
<section anchor="intro" title="Introduction">
<t>
Most existing IP mobility solutions are derived from Mobile IP
<xref target="RFC3775"/> principles where a given mobility anchor (e.g. the Home
Agent (HA) in Mobile IP or the Local Mobility Agent (LMA) in Proxy
Mobile IPv6 <xref target="RFC5213"/> maintains Mobile Nodes (MNs) bindings. Data
traffic is then encapsulated between the MN or its Access Router
(e.g. the Mobile Access Gateway (MAG) in PMIPv6) and its mobility
agent. These approaches lead to the implementation of centralised
architectures where both MN context and traffic encapsulation need to
be maintained at a central network entity, the mobility anchor.
</t>
<t>
Such centralised approach provides the ability to route
MN traffic whatever MN's localisation while maintaining IP session continuity during handovers.
However, when hundreds of thousands of MNs are communicating in a given
cellular network, a centralized mobility anchoring point causes well-known
bottlenecks and single point of failure issues, which requires costly
network dimensioning and engineering to be fixed. In addition,
tunnelling encapsulations impact the overall network efficiency since
they require the maintenance of MN's specific contexts in each tunnel
end nodes and they incur delays in packet processing and transport
functions.
</t>
<t>
It is however well established that a huge amount of mobile
communications are set up while the user is not physically moving,
i.e. its MN stays in the same radio cell. For example, the user is
being communicating at home, in his office, at a cafe... Applying
the aforementioned centralised principles leads then to aggregate
user's contexts and traffic at a central node in the network for the
sake of mobility support whereas the MN remains motionless. As this
leads to the introduced scalability and performances issues,
alternative approaches may consider a way to better adapt mobility
support in the network to cope with MN's movements and its ongoing
traffic flows' requirements. Typically, one of the trend in the
evolution of mobile networks is to go to a flat architecture with the
distribution of network functions, including mobility functions, close to the access gateways.
This document discusses the deployment of current IP mobility mechanisms (Mobile IPv6 and proxy Mobile IPv6)
in such a flat architecture by dynamically distributing the mobility handling functions among terminals and access
routers. The goal is twofold:
<vspace blankLines="1" />
<list style = 'symbols'>
<t>
confining the mobility support at the access routers level,
keeping the rest of the network unaware of mobility events and
their support.
</t>
<t>
dynamically adapting mobility support to each of the MN's needs by
applying traffic redirection only to MNs' flows that are already
established when an IP handover occurs;
</t>
</list>
</t>
</section>
<section title="Conventions used in this document">
<t>
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL","SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document
are to be interpreted as described in <xref target="RFC2119" />.
</t>
</section>
<section title="Motivation for flattening mobile network architecture">
<section anchor="flatARCH" title="General considerations">
<t>
Development of new mobile services and usages (e.g., video
streaming, mobile Internet) has led to huge increase of data traffic on the
mobile network, thus giving much pressure to the mobile operator's
core network. In order to address scalability and performance issues
with current centralized architecture, one of the trends in network
evolution is to leverage on local content delivery network (CDN)
where IP communications with local services are routed directly to
the CDN without going through the IP core network. For the same
reason, it is now preferable to offload the traffic that are not
generated by mobile services from the IP core of the mobile network (e.g.
Internet traffic should be offloaded). On the other hand, IP
communications with mobile services are routed via a centralized
anchor point (e.g., the PGW in 3GPP/EPS mobile network). In
current proposals for network evolution, a local traffic anchor (i.e.
a local gateway, L-GW), usually located near the access router, is in
charge of offloading the traffic (e.g. Internet and local traffic).
</t>
<t>
The generic mobile architecture with offload capabilities is depicted
in <xref target="figureCDN"/>; it illustrates the following use-cases:
</t>
<t>
<list style = 'symbols'>
<t>
Mobile node MN1 is attached to access router AR1 and consumes service delivered by the local
CDN. So, the corresponding IP flows are routed directly from AR1
to the CDN.
</t>
<t>
MN2 is attached to AR1 and has an IP communication with CN. So,
the corresponding IP flows are routed to the packet data network PDN, via a
centralized traffic anchor.
</t>
<t>
MN3 is attached to AR2. MN3 has an IP communication with CN and
get access to the Internet. The IP flow corresponding to Internet
traffic is offloaded to the local Internet access via the L-PGW,
whereas the IP communication with CN is routed via the centralized
traffic anchor.
</t>
</list>
</t>
<figure anchor="figureCDN" title="Deployment of Local content delivery and IP traffic offload in a centralized mobility architecture">
<artwork align="center">
<![CDATA[
+----+
,-'' |CN |. +----------+
,' +----+ \---------| central |
/ Packet \ | anchor |
| Data | +----------+
\ Network ,' |
`. _, |
`-..____,,' *****************
* IP network * __...._
* * ,' `-.
+---------+ +----+ +----+ / Internet \
| Local |__ |L-GW| |L-GW|--- | Access |
| Content | +----+ +----+ \ ,'
| Delivery| * * `-._ _,'
| Network | ****************** `'''
+---------+ || ||
+----+ +----+
|AR1 | |AR2 |
+----+ +----+
| | |
| | |
MN1 MN2 MN3
]]>
</artwork>
</figure>
</section>
<section title="IP Flow Mobility support in flat architectures">
<t>
When the host can simultaneously connect to different access systems, IP flow mobility is considered
by operator as a flexible way to route traffic according network access and applications specific contraints.
For example, a given IP flow (e.g. video streaming), initially routed through one access,
could be selectively offloaded to another access while maintaining other traffic (e.g. traffic with specific QoS
requirements) on the primary access. This kind of traffic management is specified in <xref target="TR23.261"/>
when considering centralized architecture. This section discusses deployment of IP mobility mechanisms
in flat mobile architectures as specified in <xref target="figureCDN"/>.
</t>
<t>
Existing mobility solutions generally introduce a mobility anchor in
the network; examples are HA in MIPv6, LMA in PMIPv6, and GGSN/PGW in 3GPP. The
mobility anchor is used to maintain the mapping between the stable IP
address (e.g., Home address in MIPv6) and the current routable IP
address (e.g., CoA in MIPv6). In the centralized architecture, the
mobility anchor point is usually located at the top of the
architecture. Yet in a flat architecture, such as the one depicted in <xref target="figureCDN"/>,
the traffic anchor point can be much lower (e.g. located in the access
system) compared with centralized architecture. So, for the sake of
routing optimization the mobility anchor should also be located
closer to the traffic anchoring point, otherwise the traffic could not break out
locally. Actually, routing optimization issue will become more severe in the
flat architecture if traditional mobility protocol is used. The
mobility tunnel needs to be connected back to the mobility anchor
where the mobile node attaches (and gets the IP address allocation).
Then all IP traffic of that mobile node will be routed through the
mobility anchor. Despite the well-known scalability issues brought
by centralized approaches, a central mobility anchor in a flat
architecture leads to non-optimal routing for local and offloaded
traffic: the data path goes through the central mobility anchor point
before being routing back to the local traffic anchoring point (e.g.
L-GW). Such non-optimal routing may degrade the user experience due to the latency caused
by the long route to the destination.
So, in a mobile architecture distributing the traffic anchoring, as depicted on <xref target="figureCDN"/>,
the mobility anchoring function shall also be distributed to provide efficient IP session continuity for both local and centralized traffic.
<xref target="figureDistributedMA"/> shows an example of distributed IP mobility architecture. In this example mobility anchors are deployed
both in the centralized traffic anchoring point and in the access routers to manage respectively mobility of centralized and local traffic.
<figure anchor="figureDistributedMA" title="Distributed Mobility Anchoring">
<artwork align="center">
<![CDATA[
+----+
,-'' |CN |. +-----------+
,' +----+ \---------| Mobility | Mobility
/ Packet \ |anchor (MA)| Anchor
| Data | +-----------+ for centralized
\ Network ,' | traffic
`. _, |
`-..____,,' *****************
* IP network * __...._
* * ,' `-.
+---------+ +----+ +----+ / Local \
| Local |__ |L-GW| |L-GW|--- | content |
| Content | | | | | | |
| Delivery| +----+ +----+ \ ,'
| Network | ****************** `''''''`'''
+---------+ || ||
+----+ +----+ mobility
|AR1 | |AR2 | anchors
|+MA |+MA | for local
+----+ +----+ traffic
| |
3GPP | |WiFi
+-----MN1----+
]]>
</artwork>
</figure>
</t>
</section>
<section title="Dynamic mobility anchoring">
<t>
Applying the centralized mobility management principles leads to
aggregate user's contexts and traffic at a central node in the
network whereas the MN remains stationary. However, once attached to
the new access router, the mobile node can again acquire a routable
global IPv6 address to be used for any new communication flow it sets
up. Hence, a flow based mobility support may be restricted to
provide traffic indirection to host's flows that are already ongoing
during host's handovers between access routers. Any new flow being
set up uses the new host's global address acquired on the new link
available after the handover.
</t>
<t>
When a multiple-interfaces node moves an IP flow between access
routers of different access technologies, such a simple approach can
also apply. Flow mobility management should then be required only to
support the necessary traffic indirection from the mobility anchor on
which the flow has been initially set up to the access router to which the
host is currently attached.
</t>
<t>
Hence, any given IP flow can be considered as implicitly anchored on
the current MN's access router when being set up. So, it leads to deploy
mobility anchors in access routers. While the MN is
attached to its initial access router, the IP flow is delivered as
for any standard IPv6 node. The mobility anchoring at the access
router then allow to manage traffic indirection if the MN moves to a
new access router (and for subsequent movements while the IP flow
remains active), maintaining the flow communication until it ends up.
</t>
</section>
</section>
<section title="Requirements">
<t>
This section gives the requirements for mobility management support in
flat architectures.
</t>
<t>
<vspace blankLines="1" />
<list style='symbols'>
<t>
To ensure the IP traffic offload in the flat architecture and still
maintain the service continuity, the mobility anchoring should close to the
local gateway(access router),i.e. confining mobility support to the access routers level,
keeping the rest of the network unaware of mobility events. For example, the access router
mayshould be the anchoring point of local IP traffic.
</t>
<t>
IP flow mobility: it shall be possible to offload selected traffic
(e.g. Internet) by moving IP flows from one access to another.
</t>
<t>
It is preferred for the distributed mobility solution requiring less
changes to the network and current mobility protocols. The distributed mobility solution
should compatible with legacy mobility mechanisms. This requirement may help the distributed
mobility solution easier for deployment
</t>
<t>
Mobility mechanism should come into play
only for node on the move (optional feature) . It leads to dynamically adapting mobility support to each MN's needs by applying traffic redirection
only to MN's flows those are ongoing when handover occurs.
</t>
</list>
</t>
</section>
<section anchor="GapAn" title="Gap analysis">
<t>
Current mobility protocols (DSMIPv6/PMIPv6) may be used in the flat architecture. For example, for
the architecture depicted in figure 1, DSMIPv6 or PMIPv6 may be used. The L-GW (Local Gateway in Figure 2)
could be the mobility anchor point (HA/LMA) for DSMIPv6/PMIPv6 and also act as MAG for PMIPv6.
But it is not optimized in many ways.
</t>
<t>
<list style='numbers'>
<t>Non-optimized routing:
When the UE attaches to the network through one L-GW, that L-GW will be the anchor point of that UE.
When the UE moves out of this L-GW’s service area, the UE/MAG has to establish a mobility tunnel back
the original L-GW. Obviously, the routing is not optimized since the UE/MAG always needs to establish
the mobility tunnel back to the original L-GW no matter where it has moved to. This will increase unnecessary
traffic to the operator’s network compared with locally breaking out the traffic. In LTE/SAE network, when the
UE attaches to the network it will always keep that IP address, this feature is called "always on". The "always on"
feature will worsen the problem. The reason is that in 2G/3G mobile network, when the UE terminates a session,
it will detach from the network, when it attach to the network again, it will get a new IP address and the anchor
point could be changed to the L-GW accordingly. But in LTE/SAE, the UE does not detach from the network as long as
it is power on.</t>
<t>Increased delay:
The non-optimized routing causes the routing path to be much longer compared with local breakout, this will
increase the transmission delay. </t>
<t>Single point of failure:
The UE will always depend on its original anchor point to maintain service continuity to wherever it has moved.
This will cause the single point of failure problem compared with distributing the mobility anchor function.</t>
</list>
</t>
</section>
<section anchor="SecSolu" title="Considerations of distributed mobility solutions">
<t>
This section discusses the applicability of MIPv6/PMIPv6 in flat architectures.
Based on the above analysis, there may be an interest to consider
specific deployment of mobility mechanisms in flat architecture.
This kind of solution may be called distributed mobility solutions
since the mobility anchor function is distributed compared with the
centralized mobility anchor point in traditional mobility protocol.
</t>
<t>
The distributed mobility solutions should make minimal changes to the
existing network entity. It is preferable to require no change
to the UE and be transparent to the application layer.
</t>
<t>
The following sub-sections only give basics for distributed mobility,
the detailed solutions will be identified in future.
</t>
<section anchor="secCBM" title ="Client-based solutions">
<t>
One solution to deploy Mobile IP in a flat architecture is to implement the HA functionalities in the access routers,
as shown on <xref target="figureCBM"/>. Any given IP flow can be considered as implicitly anchored on the current host's access router when set up.
</t>
<t>
In addition, dynamic mobility anchoring <xref target="I-D.kassi-mobileip-dmi"/> could avoid data encapsulation for motionless nodes: until the host does not move,
the IP flow is delivered as for any standard IPv6 node. The anchoring function at the access router is acting only to manage traffic indirection while
the host moves to a new access router. So, when the MN handoff, its current traffic is still attached to the anchor access router which is responsible
for forwarding the IP flows to the MN.For example, let's consider an IP flow, flow#1, initiated by the mobile node, MN, when attached to AR2.
Flow#1 will is routed in a standard way as long as the MN remain attached to AR2. If the MN moves to AR3, flow#1 remains anchored to AR2,
which plays the role of HA. If MN starts a new IP communication, flow#2, while attached to AR3; flow#2 will be routed in a standard way as long as
the MN remains attached to AR3. Then, if the MN moves to AR1, flow#1 and flow#2 will be respectively anchored to AR2/HA and AR3/HA.
</t>
<figure anchor="figureCBM" title="Distributed Client Based Mobility">
<artwork align="center">
<![CDATA[
+---+ +---+ +---+
|CN1| |CN2| |CN3|
+---+ +---+ +--,+
_.---------+----------. \
,----'' | `---'-.
,-' |flow#1 \ `-.
,' | ' `.
( IP Network| \
`. | ' ,'
`-. ; ,\'
;-----. ; _.----' '
,' `---------+----------'' |
/ | '
+---'---+ +---:---+ +-------+
| AR1 | | AR2`--|------------| AR3 |
| HA | | HA |------------|HA |
+-------+ +-------+ +-------+
flow#1 \\ \ flow#2
tunnelled \\ '
+-----+ +--\--+
| MN | ----move-------> | MN |
+-----+ +-----+
]]>
</artwork>
</figure>
</section>
<section anchor="secNBM" title ="Network based solutions">
<t>
<xref target="figureNBM"/> shows de deployment of PMIP <xref target="RFC5213"/> in a flat mobile architecture.
The basic is to distribute mobility traffic management with dynamic
user's traffic anchoring in the access network nodes. Each AR supports
both the MAG and LMA functionalities. Any given IP flow can be
considered as implicitly anchored on the current host's access router
when set up. Until the host does not move, the IP flow is delivered
as for any standard IPv6 node. The anchoring function at the access
router is thus acting only to manage traffic indirection while the
host moves to a new access router. So, when the MN handoff, its current traffic is still attached to the
anchor access router which is responsible for forwarding its
anchored MN's IP flows to the new MN's location (i.e. to the AR the MN is attached to).
For example, let's consider an IP flow, flow#1, initiated by the mobile node, MN, when attached to AR2.
Flow#1 will is routed in a standard way as long as the MN remain attached to AR2. If the MN moves to AR3,
flow#1 remains anchored to AR2, which plays the role of LMA. AR3 plays the role of MAG for MN/flow#1.
If MN starts a new IP communication, flow#2, while attached to AR3; flow#2 will be routed in a standard
way as long as the MN remains attached to AR3. Then, if the MN moves to AR1, flow#1 and flow#2 will be
respectively anchored to AR2/LMA and AR3/LMA and AR1 will provide MAG functionalities for MN.
</t>
<figure anchor="figureNBM" title="Distributed Network Based Mobility">
<artwork align="center">
<![CDATA[
+---+ +---+ +---+
|CN1| |CN2| |CN3|
+---+ +---+ +--,+
_.---------+----------. \
,----'' | `---+-.
,-' |flow#1 \ `-.
,' | \ `.
( IP Network| \
`. | \ ,'
`-. ; ,+'
;-----. ; _.----' `.
,' `---------+----------'' |
/ | flow#1 \
+---'---+ +---:---+ tunnelled +-------+
| AR1 | | AR2`--|------------| AR3 |
|MAG/LMA| |MAG/LMA|------------|MAG/LMA|
+-------+ +-------+ +-------+
flow#1 `. \ flow#2
+--`--+ +-----+
| MN | ----move-------> | MN |
+-----+ +-----+
]]>
</artwork>
</figure>
</section>
<section anchor="split" title ="Splitting the routing and the location management function">
<t>
The logical functions of the mobility anchor
defined in conventional mobility protocols may be split for both a better scalability and signaling efficiency.
For instance <xref target="I-D.chan-netext-distributed-lma"/> proposes to split the mobility anchor entity
into the following functions:
<list style="numbers">
<t>location management anchoring function</t>
<t>mobility routing anchoring function. </t>
</list>
The location management anchoring function includes
keeping track of the internetwork location of the mobile node,
which is identified with a permanent home address HoA.
The mobility routing anchoring function includes
routing the packets with HoA as destination address to the destination
or to some other network element that knows how to forward to the destination.
</t>
<t>
In the conventional mobility protocols,
these two anchoring functions have been colocated into one mobility anchor.
The collocated mobility anchor contains the full location information
to enable its role to redirect packets to the new location of the mobile node.
The result is the dilemma
in where to position this collocated mobility anchor in a hierarchical network.
On the one hand, it is simpler to have only one or possibly a very small number
of mobility anchors to centrally manage the location of a larger number of mobile nodes.
However, routing the packets through such centralized nodes often results in non-optimal routing.
On the other hand, having many mobility anchors whose locations are low in the hierarchy
will shorten the route.
Yet it will then be costly and difficult to synchronize the location information
when many such collocated mobility anchors are performing location management
and each needs to have full location information of all the mobile nodes.
</t>
<t>
Splitting the logical functions of location management and routing
enables each function to be optimized in the design.
</t>
<t>
The mobility routing function can be implemented in many physical places
instead of in one or very few centralized places only.
There are then many such places to provide the mobility routing function,
and the packets can always be served by one that is nearby.
Many of these packets would have to traverse a long route to reach a mobility routing function
if there were only one centralized mobility routing function.
</t>
<t>
The location management function, being implemented separately from the mobility routing function,
do not need to be implemented in as many places as the mobility routing function.
The implementation of the location information system can be optimized
according to the optimization of a database design.
There may be only one, except for backup, database system.
The database may still be distributed but are only distributed to much fewer number of places
than the routing functions.
</t>
<t>
After splitting the above functions,
the mobility routing anchor points serving a source node
sending packet to a destination mobile node
may lack the location information of the destination mobile node.
The mobility routing anchor may query the location management system
to obtain the location information of the mobile node to which it needs to route the first packet.
Alternatively, the location management anchor point may also possess routing function
so that the first packet may be forwarded to the location management anchor point
to route to the destination mobile node.
Meanwhile the location information of this mobile node is being sent to the mobility routing anchor.
After the mobility routing anchor has received the location information,
it caches this information for its use to route the subsequent packets to the same mobile node.
</t>
<t>
One access gateway plays the role of LM.
Location update may be implemented in a separate entity (see figure)
</t>
<figure anchor="fig.nbm" title="Distributed Network Based Mobility">
<artwork align="center">
<![CDATA[
+---+ +---+
|CN1| |CN2|
+---+ +---+
_.---------+----------.
,----'' | `----.
,-' |flow#1 `-.
,' | `.
( IP Network| )
`. | ,'
`-. ; +-----+ ,
;-----. ; +------ | LM |---+
,' `---------+--|-------+-----+ |
/ | | flow#1 |
+---'---+ +---:---+ tunnelled +-------+
| AR1 | | AR2`--|------------| AR3 |
|MAG | |MAG |------------|MAG |
+-------+ +-------+ +-------+
flow#1 `.
+--`--+ +-----+
| MN | ----move-------> | MN |
+-----+ +-----+
]]>
</artwork>
</figure>
</section>
</section>
<section anchor="security" title="Security Considerations">
<t>TBD</t>
</section>
<section title="IANA Considerations">
<t>None</t>
</section>
<section title="Contributors">
<t>
The following people contributed to this document (in no specific order):
</t>
<t>
<list style='empty'>
<t>Bo Zhou</t>
<t>China Mobile</t>
<t>zhouboyj@chinamobile.com</t>
</list>
</t>
<t>
<list style='empty'>
<t>Philippe Bertin</t>
<t>France Telecom - Orange</t>
<t>philippe.bertin@orange-ftgroup.com</t>
</list>
</t>
</section>
</middle>
<back>
<references title="Normative References">
&rfc2119;
</references>
<references title="Informative References">
<?rfc include="reference.RFC.3775" ?>
<?rfc include="reference.RFC.5213" ?>
<?rfc include="reference.RFC.5648" ?>
<?rfc include="reference.I-D.ietf-mext-flow-binding" ?>
<?rfc include="reference.I-D.chan-netext-distributed-lma" ?>
<?rfc include="reference.I-D.seite-netext-dma" ?>
<?rfc include="reference.I-D.kassi-mobileip-dmi" ?>
<reference anchor="TR23.261">
<front>
<title>IP Flow Mobility and seamless WLAN offload</title>
<author>
<organization>3GPP</organization>
</author>
<date year="2010" />
</front>
</reference>
</references>
</back>
</rfc>
| PAFTECH AB 2003-2026 | 2026-04-24 08:33:59 |