CA2352374A1 - Packet pipe architecture for access networks - Google Patents
Packet pipe architecture for access networks Download PDFInfo
- Publication number
- CA2352374A1 CA2352374A1 CA002352374A CA2352374A CA2352374A1 CA 2352374 A1 CA2352374 A1 CA 2352374A1 CA 002352374 A CA002352374 A CA 002352374A CA 2352374 A CA2352374 A CA 2352374A CA 2352374 A1 CA2352374 A1 CA 2352374A1
- Authority
- CA
- Canada
- Prior art keywords
- network
- communications traffic
- conveyor
- interface
- packet
- Prior art date
- Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
- Abandoned
Links
Classifications
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04W—WIRELESS COMMUNICATION NETWORKS
- H04W40/00—Communication routing or communication path finding
- H04W40/02—Communication route or path selection, e.g. power-based or shortest path routing
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04Q—SELECTING
- H04Q11/00—Selecting arrangements for multiplex systems
- H04Q11/04—Selecting arrangements for multiplex systems for time-division multiplexing
- H04Q11/0428—Integrated services digital network, i.e. systems for transmission of different types of digitised signals, e.g. speech, data, telecentral, television signals
- H04Q11/0478—Provisions for broadband connections
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04W—WIRELESS COMMUNICATION NETWORKS
- H04W28/00—Network traffic management; Network resource management
- H04W28/02—Traffic management, e.g. flow control or congestion control
- H04W28/0215—Traffic management, e.g. flow control or congestion control based on user or device properties, e.g. MTC-capable devices
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04W—WIRELESS COMMUNICATION NETWORKS
- H04W28/00—Network traffic management; Network resource management
- H04W28/02—Traffic management, e.g. flow control or congestion control
- H04W28/08—Load balancing or load distribution
- H04W28/082—Load balancing or load distribution among bearers or channels
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04W—WIRELESS COMMUNICATION NETWORKS
- H04W28/00—Network traffic management; Network resource management
- H04W28/16—Central resource management; Negotiation of resources or communication parameters, e.g. negotiating bandwidth or QoS [Quality of Service]
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04W—WIRELESS COMMUNICATION NETWORKS
- H04W80/00—Wireless network protocols or protocol adaptations to wireless operation
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
- H04L12/00—Data switching networks
- H04L12/54—Store-and-forward switching systems
- H04L12/56—Packet switching systems
- H04L12/5601—Transfer mode dependent, e.g. ATM
- H04L2012/5638—Services, e.g. multimedia, GOS, QOS
- H04L2012/5646—Cell characteristics, e.g. loss, delay, jitter, sequence integrity
- H04L2012/5651—Priority, marking, classes
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
- H04L12/00—Data switching networks
- H04L12/54—Store-and-forward switching systems
- H04L12/56—Packet switching systems
- H04L12/5601—Transfer mode dependent, e.g. ATM
- H04L2012/5638—Services, e.g. multimedia, GOS, QOS
- H04L2012/5665—Interaction of ATM with other protocols
Landscapes
- Engineering & Computer Science (AREA)
- Computer Networks & Wireless Communication (AREA)
- Signal Processing (AREA)
- Quality & Reliability (AREA)
- Data Exchanges In Wide-Area Networks (AREA)
- Mobile Radio Communication Systems (AREA)
Abstract
A packet pipe architecture is disclosed for an access network (100) (e.g., provides access to an IP, ATM or similar packet-based network (118) in order to convey packet data traffic), whereby the network interfaces (B.1, B.2) wi th the packet pipe (106) are standardized so that any packet pipe that satisfie s the interface requirements can be utilized in the same access network (100). Also, the packet pipe (106) uses a packet-based protocol stack with Quality of Service provisions for service delivery instead of the conventional best effort service delivery functions used. Consequently, the packet pipe (106) and access network (100) are capable of providing all of the numerous servic es available with an IP, ATM or similar packet-based network layered architectu re.
Description
wp 00131946 ..Z_ PLACKET PIPE wRCHITEC7.'URE
FOR wCCESS N~1'W~~~
. _-_ CROSS-RZwFERENCES TO RF1-ATED A.PpI-ICATIt~NS
'This Application for Patent claims the benefit: of priority from, and hereby incorporates by reference ~e entire disclosure of, ccrperuling U.S.
Provrisional Application for Patent Serial No. 60/109,899, filed N~>veml~er 25, 1998.
BACKGRO~ OF THE ~T10N
Tec ical Fie~f'the nyention ThE present invention relates in general to the; telecommunicatiotu field and, in pat'ticular, to a packet pipe architecture for access networks-es io o elated Air present day ~eless jelecomm~iGapon ~~e~ ~e vertically integt3~. T~s structure it~nplies that the radio air interface spectfie~ations which define the physical layer (as well as the network layers) aad the medium's access control functions are often propcieta;7r ~d tailored to fit particular appuc~ations such as ~oiGe or best effort data communicatiotls. However, a significant pr'o~blem Witb the existing radio air interface specifications is that they have evAlvedl with a circuit-switched legacy.
Consequently, attempts to convey Internet 1'rotocial (IP) or Asynchronous Transfer Mode (ATM) data over the existing (circuit-swimh-based) air interfaces have resulted in cumbersatne, complex, and proprietary patchwork desist solttdons which are inefficiept and incapable of handling the comglete plethora of services that can be provided by these network models.
i Pcc~Fa9ra=wg ' wo'aor~a946 For example, FIGURE 1 is a block diagram of an existing protocol stack that _ an As etric Digital Subscriber c~ be used by a gene~c access concentrator (e.g , yn~
Line ~ApSj~,) access network or radio access neEwnrk) to acce$s an IP network such .
as the lntemtt, and convey packer data tra~tc ~~eb~etv~'een. Thebasic ideabehind the rotocol stack architecture sbown in FIGURE I is that a logical point-to-point link can P
be Gonstsu~tcd bct"~,een the Temninal Equipment f f E) aTld the access tauter (i.e., F,dge Rnutet in this case) devices using conventional I~tyei ~ "tunneling.' pTOwcols (e.g., based on a conventional hP model). Network teru~inations at the layer 1 andlor layer 2 levels of the stack enable the relaying of ~' p~~k~ locally between devices, in 14 accordance ~rith the best effort pt'inciples used. However, as mentioned earlier, a problem with Such art approach is that it is limited m best effort type apPiicatiorxs, and therefore, is not capable of handling all of the nurnerous services available with an IP
or ATM layered at'chitecture. Consequently, a si,gnificutt need exists its the wireless telecommunications field for a flew network aecesS architecture that can improve on the effcietiGy of existing Sao alt interfaces while minimizing the carnphexity of the appmachused. As described in detail below, flee presetst invenrion successfully solves the above-described problems and sati$ftes this need.
SUMMARY QF THE II~NTION
In accoxdance with a pmfetrEd embodirnent of the present invention, a packet pipe architecture is pTO~idcd for an. access neWrotk te-g-~ PTa~ides access to an IP, ATM or similar packet-based network to con'~eY packet data traffic therebetween), whereby the network izzterfaees with the packet pipe are sta~daTai~ so that arty packet pipe than satisfies the interface r~uirernents can be utilized in the same ass . wo a~~3~9a6 network. Also, the packeg PIPe uses a parkec-based protocol suck I with QoS
revisions for sen'ice delivet'Y instead of the con"~tional best effort service delivery P
coons used. Consequently. the packet pipe and access network are capable of fun roviding all of the nt~erous services available with azi u'~ ATM ar similar packet-P
based network layered atrchitecrore. .
.An important teehtucal advantage of the pre.~ent invention is that a packet pipe ~.chitecture is pTOVide~ for an access network that can be optitni~ed for IP, ATM or similar packet-based metwoTk p~ket ~~ c-Another impotent technical advantage of the present invention is chat a Packet p i a atchneett~Ce is provided for asz access r~er'"ork; that can increase the efficiency of 1 pP
a radio air interface use.
Still another tmpAnant technical adyan~~~e of the pre$erlt invention 1s ihax a packet pipe architecture is provided for an lcCE:SS network that can minimize the complexity of the approach t~~-$RLbF AESCR1PTION OF T~ D~~OS
A snore complete understanding of the Method and apparatus of ~e present invention may be had by reference to the following detailed description ~vhen taken in conaunction with the accompanying drawings wherein.
FIGURE I is a block diagram of an existing pr4tocol stack chat can be used by ~, genene access concentrator or access netwot'k to access an IP network and convey packet data traffic thezebetween;
WC100~3194~
FOR wCCESS N~1'W~~~
. _-_ CROSS-RZwFERENCES TO RF1-ATED A.PpI-ICATIt~NS
'This Application for Patent claims the benefit: of priority from, and hereby incorporates by reference ~e entire disclosure of, ccrperuling U.S.
Provrisional Application for Patent Serial No. 60/109,899, filed N~>veml~er 25, 1998.
BACKGRO~ OF THE ~T10N
Tec ical Fie~f'the nyention ThE present invention relates in general to the; telecommunicatiotu field and, in pat'ticular, to a packet pipe architecture for access networks-es io o elated Air present day ~eless jelecomm~iGapon ~~e~ ~e vertically integt3~. T~s structure it~nplies that the radio air interface spectfie~ations which define the physical layer (as well as the network layers) aad the medium's access control functions are often propcieta;7r ~d tailored to fit particular appuc~ations such as ~oiGe or best effort data communicatiotls. However, a significant pr'o~blem Witb the existing radio air interface specifications is that they have evAlvedl with a circuit-switched legacy.
Consequently, attempts to convey Internet 1'rotocial (IP) or Asynchronous Transfer Mode (ATM) data over the existing (circuit-swimh-based) air interfaces have resulted in cumbersatne, complex, and proprietary patchwork desist solttdons which are inefficiept and incapable of handling the comglete plethora of services that can be provided by these network models.
i Pcc~Fa9ra=wg ' wo'aor~a946 For example, FIGURE 1 is a block diagram of an existing protocol stack that _ an As etric Digital Subscriber c~ be used by a gene~c access concentrator (e.g , yn~
Line ~ApSj~,) access network or radio access neEwnrk) to acce$s an IP network such .
as the lntemtt, and convey packer data tra~tc ~~eb~etv~'een. Thebasic ideabehind the rotocol stack architecture sbown in FIGURE I is that a logical point-to-point link can P
be Gonstsu~tcd bct"~,een the Temninal Equipment f f E) aTld the access tauter (i.e., F,dge Rnutet in this case) devices using conventional I~tyei ~ "tunneling.' pTOwcols (e.g., based on a conventional hP model). Network teru~inations at the layer 1 andlor layer 2 levels of the stack enable the relaying of ~' p~~k~ locally between devices, in 14 accordance ~rith the best effort pt'inciples used. However, as mentioned earlier, a problem with Such art approach is that it is limited m best effort type apPiicatiorxs, and therefore, is not capable of handling all of the nurnerous services available with an IP
or ATM layered at'chitecture. Consequently, a si,gnificutt need exists its the wireless telecommunications field for a flew network aecesS architecture that can improve on the effcietiGy of existing Sao alt interfaces while minimizing the carnphexity of the appmachused. As described in detail below, flee presetst invenrion successfully solves the above-described problems and sati$ftes this need.
SUMMARY QF THE II~NTION
In accoxdance with a pmfetrEd embodirnent of the present invention, a packet pipe architecture is pTO~idcd for an. access neWrotk te-g-~ PTa~ides access to an IP, ATM or similar packet-based network to con'~eY packet data traffic therebetween), whereby the network izzterfaees with the packet pipe are sta~daTai~ so that arty packet pipe than satisfies the interface r~uirernents can be utilized in the same ass . wo a~~3~9a6 network. Also, the packeg PIPe uses a parkec-based protocol suck I with QoS
revisions for sen'ice delivet'Y instead of the con"~tional best effort service delivery P
coons used. Consequently. the packet pipe and access network are capable of fun roviding all of the nt~erous services available with azi u'~ ATM ar similar packet-P
based network layered atrchitecrore. .
.An important teehtucal advantage of the pre.~ent invention is that a packet pipe ~.chitecture is pTOVide~ for an access network that can be optitni~ed for IP, ATM or similar packet-based metwoTk p~ket ~~ c-Another impotent technical advantage of the present invention is chat a Packet p i a atchneett~Ce is provided for asz access r~er'"ork; that can increase the efficiency of 1 pP
a radio air interface use.
Still another tmpAnant technical adyan~~~e of the pre$erlt invention 1s ihax a packet pipe architecture is provided for an lcCE:SS network that can minimize the complexity of the approach t~~-$RLbF AESCR1PTION OF T~ D~~OS
A snore complete understanding of the Method and apparatus of ~e present invention may be had by reference to the following detailed description ~vhen taken in conaunction with the accompanying drawings wherein.
FIGURE I is a block diagram of an existing pr4tocol stack chat can be used by ~, genene access concentrator or access netwot'k to access an IP network and convey packet data traffic thezebetween;
WC100~3194~
p~T/5~991DZ 179.
F1G~$ ~,A, ~d 28 are related block diagrams of a packet pipe architecture for an access network. w~ch c~ be ~plemeniedl in accordance with a preferred embodiment of the present invention; and ' FIGURE 3 is a protocol stack that can be uscd for the packet pipe shown in S FIGZIREs 2A and ~1~ to provide QoS differenuarion support in accessing as 1P
netyvork acrd conveying p~ket data traffic tllerebetween, in accordance with the preferred embodiment of the present in~entiop_ DIrTAII.IrD DESCR.~TIOi~i OF THE DRA~N~JS
1 p 'tee preferred embodiment of the present invention and its advantages are be$t understood by referring to FIGt~s 1-3 of the drawings, like numerals being used for iilce and corresponding pans oFthe various drawings.
essentially, itt accordance with a prefe~.rred etttbadiment of the present invention, a packet pipe ~'chitecture is provider3 for an access network (e.g-, can 1 S provide access to an TP> ATM or similar packet-based network to convey packet data traff c therebetwecn), whereby the network interfaces with the packet pipe are standardized so that any packet pipe that satisfies the interface requirements cazi be utilized in the same access network. Also, th.e packet pipe uses a packet-based protocol stack with QoS provisions for service ~3elivery ipstead of the conventional best effort service delivery functions used. Con~~equenily, the packet pipe and access network are capable of providing all of the numerous services available with an IP, ATM or similar packet-based network layered architecture.
Specifically, FIGURES 2A and 28 are related block diagrams of a packet pipe architecture for an access network 1 OQ, which can be implemented in accordaztce with i' wo oor~i9~6 the preferred etribodiment of the present invention. In the context of the present invention, a "packet pipe" can be a neturork or network cotngQnent that is used primarily to convey packets of data. The exemplary network 100 includes a Terminal Equipment (?E) unit 102. For this errtboditnent, 'it can be assumed that one or more S terminals located at end user premises can use are IP as a service bearer mechanism op~ung over an appropriate physical interface. However, the preseat in~endon is not limite8 -'to the use of such a protocol and can use other modes to transfer data, such as, for example, as ATM or other packet-hase~i implementation (e.g., for a Base T~sceiver Station (BTS) to Base Station Controller (BSC) interconnection).
'The access network 100 also includes an Interworking Functions unit at the User Side (IWF~US) 104, which fiurctiotts w reap any application flows existing between a W.3 interface and a B.1 interface (tc~ be dtsctibed in detail below). For example, a B_1 to W-3 interface mapping functiims to identify the type of flow, such as voice, data, streaming media, etc- C°tu~~T~y' the QoS requirements for such a I S flow type are laiown and thus can be identifiai for use herein_ This mapping also functions to identify and categorize the flow foe pertinent bearer services, so that the packet pipe can schedule the flow for conveyance based on the relevant QoS
requirements -for that type of flow- As such, a~ne IWF US unit 104 caxi function to serve multiple users, multiple terminals, andlor multiple sessions. In this regard, the following InterWorking functions are provided between the radio access network and the user (between the interface reference points W.3 and B_1): as IWF
between the packet pipe and a Large Area Network (L.AN) or Ethernet; an IWI' between the packet pipe and one or more Plain Old Telephone System (POTS) or Integrated Services Digital Network (ISDI~ telephones; and an IWF be~e~ the packet pipe and PCTI~E99IpZ 179 WO OOI3i94b ~6 an >rl or T1 (leased) line_ As such, ttse above-described list of IWFs is not intended to be all-inclusive.
For this embodiment, the interfaces supposed by the IWF US ! 4a uo the user at the W.3 interface refeteacc point are preferabl',y open (not proprietary) interfaces based on industry-accepted standards. A generalized or generic interface can be provided at the B.1 interface reference poitlt. FoT example, a W.3 interface can be genetic to the extent that it is capable of handling whichever packet-based or eircuit-based interface a -°I'~ provides as an input to an 1WF US and can classify QoS
requirements for 'patdculat types of flows. Cons~.guently, the IWF IJS unit IOa can be used in conjunction with a plurality of differeru packet pipes, and conversely, otie packet pipe cast be used to service different IWFs.
Ac the 8. I interface, a predetermined set of pt'im;tivss can be used with the W-Data Lint: Control (W-DLC) protocol layer, in order for the IWFs to be capable of requesting various services from the packet pipe andlor reserve resources.
These 1 S primitives can be> for example: (~oS informaunn; fairness information;, minimum traffic throughput information; resource allocation information, etc. A more detailed description of these exemplary primitives is provided below.
As such, for each of the various services, to be supported by the packet pipe, a particular protoeol stack earl be defisied. For es~ample, for Ethernet or L14N types of 2p services, layer 2 tunneling protocols (I-2TP) may be used, or it may be mote appropriate to terminate the protocols being used. In this context, the word "tetmittate" cant tneaps that a particular protocol segment iS not passed further along the chain. For example, an TP destination can b~: terminated in a rauteT (and possibly replaced by an other IP destination)- Furthermore, depending on the choice of physical interfaces and piotocox stacks used at the W.3 and W_2.1 interfaces, the access system can be designed sytruttetticalxy so that the IWFs used atboch ends of the network can be idenneal-In accordance with the presept invention, the packet pipe (ID6) provides layer I and layer 2 functions to eotz~ey packet data traffic aeross a radio air interface. For this exemplary eraboditnent, the packet pipe I06 istcludes a Radio Tet~'rtiuation (RT) unit 108 on the uses' side of the packet Pipe, a Rad,t° Relay (RR) 11'~it 1 I O coupled to the RT unit, and a Radio Nodes (RN) unit 11D c~ulPled to the RR unit oIt the network side. Preferably, the packet pipe 106 has a point-to-ntuxtipoittt capability, and x p consequently, cart supP4~ a Plurality of different sEasions from a plurality of different user terminals.
'fhc packet pipe 106 also includes a pltu'ality of B.x (e.g., B.1 attd 8.2) interfaces that operate as indep~dendy as possible from the radio technology being used. Fut~tm4~~ ~e packet pipe 1D6 is designed to provide a plurality of radio bearer services to the higher protocol layers (layers 3 arid above), which services are characterized by different QcS P~~e~ ~~ define a set of QoS levels. 'These QoS
levels can be associated with the applications in~~olved, such as, for exasuple, Voice over IP (~OIP), best effort data, data sync~ttronixed with voice, ecc_ As such, the RT
unit 148 and RN unit 112 f~capn to terminate the pr4tocols from the access roofer I 16 and tertninais 102, Tespectively. The ~.R mot 110 cart be a wireless transmitter andlor reGeive~, of a repcater_ The network 1 OD also includes an Intetwprking Functions ttttit at the Network Side (IWF NS) 114, which is coupled to the P:N unit 112 of the packet pipe.
The 1WF NS unit 114 functions to map the application flows existing between the B.2 t3N0 Ot1~31946 pCTI~E99~OZI79 interface and W-2.1 itaterface (described in detail below). For this embodiment, one IVY NS unit 114 can serve a plurality of communication sessions through a single packet pipe (106)_ Preferably, the 1~_NS unit snaps all ongoing applications, such as, for example, voice, data, etc., from a plurai'iCy of termit:als. For example, the Medium Access ConErol (MAC) Part of layer ~ (data link layer) can participate in scheduling packets from terminals operating i'n a shared resource (e.g., within the coverage of the packet pipe). The packets can b~e mapped onto relevant bearers that carry the packets in accordance with predetermined criteria, such as, far example, a QaS requirement for latency, ecc-Ip Far this embodiment, an access routes 115 provides connectivity iv apluraliry of Wide Area Networks (WANs). such as, for ex;urrple, IP ztetwork 118: A.s such, the aceess scoter operates in a conventional manner uo direct the data flowing to/frotti the WANs. Specificall)r, the primary purpose for using the access rottter as an "edge device" is to be able to provide (with a single .access device) uniform access for a multiplicity of se~ces, along with a relatively flexible bandwidth allocation capability, far each type ofgaeket; cell attdlar voice agplication handled.
r~s such, the access muter 116 funceio~s as a service access node and cart provide dlfferetluated access fune~ons in. accordance with the particular service a user has reqatested. For example, a conveutiQnal access roofer can bE: used to provide art authenricatian capability which protects an authori2ed user's iir~for=nation base (in order to provide proper access service), and also avoids inierfer~ence from a malicious user.
A gatekeeper unit 12fl operates to handle call slgtialling attd service functions (e_g_, address resolutiAn, bandwidth control, claargitsg, etc.) far the endpoints (e_g., te~titutl-to-iertninal, gateway-to terminal, or gavteway-to-gateway) in, for example, an wo oar~t9$~
1-L3?3-based (audio, video, data) netu'ork_ As such, gatekeeper functions can be provided within a gateway device or by a separate gatekeeper node (e.g_, handling up tQ several gateway devices at a time). BY Way of example, a gatekeeper unit can take pate in the call handling processes, call signalling, conversion or mapping of IP
addresses to associated phone numbers ar userpon m numbers, bandwidth allocation, fee charging, etc-A Public Switched Telephone Networ3clISDN (I'STN/ISDl~ gateway 122 operates to providE canne<tivic~r between ceTi~ll~ IP-based services, such as>
for example, VOID, and PSTN~SDN native se:vices. The PSTN/ISDN gateway can have ld the following interfaces: a W.2.2 interface to the access roister, and a W.2.3 int~aface to a PSTNIISDN network using such known in~~faces and protocols as, far example, ITU StatidaTd G.7~3 or Synchronous Dip'ta1 Hierarchy (SDH) and V~. Ttie f STNIISDN gateway can provide such function: as protocol convErsion. such as, far example, converting from an IP based protocol stack to a pertinent telecommunications protocol stack (e.g., PSTNfIISDN protocol stack oz' OSIIMTP-based protocol stack)-An ATM gateway 124 provides service connectivity between IP,based services and ATM nati~ a spices. The ATM gateway can also provide gatekeeper functions.
The ATM gateway earl be used if ATM native services (e.g., Voice Over ATM, 2p Classical IF Over ATM, etc.) are supported by Gun R.TM service netwc~Tk. An Element Management System (EMS) 126 provides monitoring and Operational con~roi functions for the elements comprisitlg the fixed radio access network 1A0.
As mentioned above apd shown in F'IGLJRE 213 the access network 1Q0 includes a plurality of interfaces at different reference points in the network. For fCi'1SE99~p~1"19t ttr0 OOI~l9sb -1.0-example. the W.3 -interface is located between the',fE unit lp2 and IWF US.
unit 104.
preferably, Ehe W.3 interface is an open interface pe.g., IP over an Ethemet or USB).
A B.1 interface i$ located between the IWF_US unlit ltD4 arid the packet pipe 106. The B_1 interface is preferably a prapnetaty t~terface" but it also, can be non-proprietary S fpr other uses. For example, a B.1 interface can tie standardized in accordance with an agreement between different access technology suppliers andlor operators.
A W.1 interface (e.g., air interface) is located between the RT unit I 08 and RR
tirait 110 or RN unit 112 (uot shown). Ip a different embodiment, the W.1 or radio air interface can also be located between the RR unit 110 and RN unit 112. The W.1 1Q interface cave be proprietary or nor;-proprietary.
A B.2 -interface is located between the packet pipe 106 and the IWF NS unit l l~t_ The B_2 inte~'ace is pxefecably a proprietary interface, bttt it can also be nnn-proprietary far other uses. Similar to a B.1 intGrfice, for example, a ~.2 interface can be standardized in aGCOrdarice with an agreement lbetween different access technology 15 suppliers andlor opetatozs.
A W.2.1 -Interface is located between the: IWF NS unit 114 and the edge or access muter llfi_ The W-2.1 interface is pre:fetably tzon-p'ropnetarY.~ A
W:'.2 interface is Located between the edge oT access tourer 116 and the IP Network 118, Gatekeeper 120, PSTNIISDN Gateway 122, and ATM Gateway I2~4. The W.2.2 20 interface is preferably a non-proprietary interface:, such as, for example, IP over Frame relay, ATM, or SC?bfETlSI3H. p W.2.3 itstecface is located between the pSTN/iSpN
Gateway 122 and PSTNIISDN Network 128, amd the ATM Gateway 124 and ATM
Network 130. The W.2.3 irnerface is preferabl'~r a non-proprietary interface such as, for exattzple, V~.2 or ATl4i forum User Network Interface (LJIVI)_ WO p0l319db A B.3 interface is located between the EMS unit 126 and various components of the radio access network 100. The 8.3 interface can be a proprietary or mon-proprietary interface- A a.4 ~ntet~e is provided between, the EMS unit and the upper layer network tn~Sem~c ~st~' ~e E.4 iaterfar_e can also be a proprietar,,r oT
nnn-proprietary intcrface.
A.s m~tiorted above, the layer 1 and layer 2 packet pipe (106) provides a plurality of radio bearer -services to the higher pmu~coI layers, which services can be characterized by diffe~eni Quality of Service (QoS) parameters. For this embodimeaT, the access network 100 manages QoS with the following approaches: integrated 14 Services (IntSer~~) orReSGrVation Protocol (RSVP) support; Differentiated Services (pifl5er'v} support; or by using a "drill down" prou~col technology which can transfer QoS parameters down fl'om the higher to the lower protocol stacks of the packet pipe 106. In accc~tdar~ce with the preferred embodiment; of the present Invention, a protocol stack forthe packetpipe 1 D6 wblch caaprovide QoS differentiation (DiftSet''~) support is shown in F1GURE 3.
As illusta-ated by the protocol stack shown in, FIGURE 3, the IP global tows a;e te'ttninated at the edges of the packet pipe 106 to provide pa'eket classification. The RSVP services ate cet;ztinated to access resource reservation parameters in order to manage sessions in the packet pipe. Also, a tourer-like technology is applied at the edges of the packet pipe. For example, the )=dge muter 116 differentiates packets in accordance wish the different QoS requirements imposed. This differentiation between packets can be performed using, for example, RSVP (developed for supporiVg different QoS classes in IP applic~itions, such as video-conferemcing, PCT4SE99A'117q WO 00!31946 multimedia, ecc.)> or a DiffServ ciassifcation fi;action. Notably, various nerwork transport mechanisms may be used with each Di:ffSetv class.
As mentioned earlier, a primary function of the packet pipe I Qf is to provide layer I and layer 2 functionalitx for conveying ~packetized traff c across a radio air interface (e.g., W. I inlerfa~ce in this example). Tlae incaface between the padcet pipe l Oft and the upper layers in the overall protocol architecture also deterraitte$ the type ofpackeas (e.g., Packet Data Units or PhTJs) that are submitted for ttansfer.
As such, the primary scenati~s for the packet pipe 106 ~.an be described as follows: an IP-optimized packet pipe; an ATM-optimized packet pipe; and a packetpipe that supports both the IP and ATM models. The packct pipe provides an interface to the ~WFs to reserve, remove or maintain a radio resource in agreement with the negotiated QoS_ in accordance wish the prefcrred embodiment of the present invention, the packet pipe i 06 can be designed to meet cextaira general requirements- A
first requirement is that the packet pipe supports provision.of different QoS
classes to the 1 S higher layers. In that regard, a set of QoS classes in the packet pipe are def ned. The packet pipe is then responsible for delivcring s<<tisfactory services within those (aoS
classes. A second requirement is that proper m~echat'usnls gist to efFciently utilize seance radio resources when they are allocated for different inforlnacion flows, and also to obta=n cf$cient access to the backbone network. A third requirement is that for proper radio resource capacity, the packet pipe'S'~ design. should account for link budget Galculatiot~s, in order to ensure that a satisfactory Bit Error Rate (BER) is secured for the Physical layer channels.
A fourth requirement for the packet pipe l4fi is that mechanisms be provided to ensure that fairness principles govern when allocating radio resources to different wo uam94s sessions or users belan~g to the same CaoS class. In this regard, ~ packet pipe can prioritize packet traffic belonging to the same or a di#ferent QoS class during petiods of congestion, which can leave control over the utilization of these scarce radio xesc~urces up to an operator.
p, f ~ requirement for the packet pipe 1 OEi is that it be capable of seginertting and reassembling dat$ trat»ntSStons. The packet ~~pipe is required to provide e~ftcient medium access conixol that also includes retrattstnission of erroneous data.
This requires a segmcniazAOa f~utCUon that splits ineeuun~ P~1~~ (1'I-PDUs) into smallez units prior to transmission across the radio air inte:t!face, in order to optimize the radio transfer by combining ihc Forward Err4r Correcuon (FEC) or redundancy by coding, attd the $ackward Error Correction ($)~C) or red~~ndancy by retraztsmission-Also, by sending smaller data units over the radio atr interface, the preemption g;anttlarity bewtnes smaller yvl~ich allows a finer tuning o1" the radio access for diffaezit QoS
Basses. Finally, a packet reassemblY capability is required on the receiver side.
1 S Although a preferred embodiment of the method and apparatus of the present inrrention has been illustrated in the accotnpanyitig Drawings and described in the foregoing Detailed Description, it will be under.,rood that the invention is not liruited to the embodiment disclosed, but is capa~hlo of numerous reatrangcmenis, modifications and substitutions without departing from the spirit of the invention as set Earth and defined by the follpWing claims.
F1G~$ ~,A, ~d 28 are related block diagrams of a packet pipe architecture for an access network. w~ch c~ be ~plemeniedl in accordance with a preferred embodiment of the present invention; and ' FIGURE 3 is a protocol stack that can be uscd for the packet pipe shown in S FIGZIREs 2A and ~1~ to provide QoS differenuarion support in accessing as 1P
netyvork acrd conveying p~ket data traffic tllerebetween, in accordance with the preferred embodiment of the present in~entiop_ DIrTAII.IrD DESCR.~TIOi~i OF THE DRA~N~JS
1 p 'tee preferred embodiment of the present invention and its advantages are be$t understood by referring to FIGt~s 1-3 of the drawings, like numerals being used for iilce and corresponding pans oFthe various drawings.
essentially, itt accordance with a prefe~.rred etttbadiment of the present invention, a packet pipe ~'chitecture is provider3 for an access network (e.g-, can 1 S provide access to an TP> ATM or similar packet-based network to convey packet data traff c therebetwecn), whereby the network interfaces with the packet pipe are standardized so that any packet pipe that satisfies the interface requirements cazi be utilized in the same access network. Also, th.e packet pipe uses a packet-based protocol stack with QoS provisions for service ~3elivery ipstead of the conventional best effort service delivery functions used. Con~~equenily, the packet pipe and access network are capable of providing all of the numerous services available with an IP, ATM or similar packet-based network layered architecture.
Specifically, FIGURES 2A and 28 are related block diagrams of a packet pipe architecture for an access network 1 OQ, which can be implemented in accordaztce with i' wo oor~i9~6 the preferred etribodiment of the present invention. In the context of the present invention, a "packet pipe" can be a neturork or network cotngQnent that is used primarily to convey packets of data. The exemplary network 100 includes a Terminal Equipment (?E) unit 102. For this errtboditnent, 'it can be assumed that one or more S terminals located at end user premises can use are IP as a service bearer mechanism op~ung over an appropriate physical interface. However, the preseat in~endon is not limite8 -'to the use of such a protocol and can use other modes to transfer data, such as, for example, as ATM or other packet-hase~i implementation (e.g., for a Base T~sceiver Station (BTS) to Base Station Controller (BSC) interconnection).
'The access network 100 also includes an Interworking Functions unit at the User Side (IWF~US) 104, which fiurctiotts w reap any application flows existing between a W.3 interface and a B.1 interface (tc~ be dtsctibed in detail below). For example, a B_1 to W-3 interface mapping functiims to identify the type of flow, such as voice, data, streaming media, etc- C°tu~~T~y' the QoS requirements for such a I S flow type are laiown and thus can be identifiai for use herein_ This mapping also functions to identify and categorize the flow foe pertinent bearer services, so that the packet pipe can schedule the flow for conveyance based on the relevant QoS
requirements -for that type of flow- As such, a~ne IWF US unit 104 caxi function to serve multiple users, multiple terminals, andlor multiple sessions. In this regard, the following InterWorking functions are provided between the radio access network and the user (between the interface reference points W.3 and B_1): as IWF
between the packet pipe and a Large Area Network (L.AN) or Ethernet; an IWI' between the packet pipe and one or more Plain Old Telephone System (POTS) or Integrated Services Digital Network (ISDI~ telephones; and an IWF be~e~ the packet pipe and PCTI~E99IpZ 179 WO OOI3i94b ~6 an >rl or T1 (leased) line_ As such, ttse above-described list of IWFs is not intended to be all-inclusive.
For this embodiment, the interfaces supposed by the IWF US ! 4a uo the user at the W.3 interface refeteacc point are preferabl',y open (not proprietary) interfaces based on industry-accepted standards. A generalized or generic interface can be provided at the B.1 interface reference poitlt. FoT example, a W.3 interface can be genetic to the extent that it is capable of handling whichever packet-based or eircuit-based interface a -°I'~ provides as an input to an 1WF US and can classify QoS
requirements for 'patdculat types of flows. Cons~.guently, the IWF IJS unit IOa can be used in conjunction with a plurality of differeru packet pipes, and conversely, otie packet pipe cast be used to service different IWFs.
Ac the 8. I interface, a predetermined set of pt'im;tivss can be used with the W-Data Lint: Control (W-DLC) protocol layer, in order for the IWFs to be capable of requesting various services from the packet pipe andlor reserve resources.
These 1 S primitives can be> for example: (~oS informaunn; fairness information;, minimum traffic throughput information; resource allocation information, etc. A more detailed description of these exemplary primitives is provided below.
As such, for each of the various services, to be supported by the packet pipe, a particular protoeol stack earl be defisied. For es~ample, for Ethernet or L14N types of 2p services, layer 2 tunneling protocols (I-2TP) may be used, or it may be mote appropriate to terminate the protocols being used. In this context, the word "tetmittate" cant tneaps that a particular protocol segment iS not passed further along the chain. For example, an TP destination can b~: terminated in a rauteT (and possibly replaced by an other IP destination)- Furthermore, depending on the choice of physical interfaces and piotocox stacks used at the W.3 and W_2.1 interfaces, the access system can be designed sytruttetticalxy so that the IWFs used atboch ends of the network can be idenneal-In accordance with the presept invention, the packet pipe (ID6) provides layer I and layer 2 functions to eotz~ey packet data traffic aeross a radio air interface. For this exemplary eraboditnent, the packet pipe I06 istcludes a Radio Tet~'rtiuation (RT) unit 108 on the uses' side of the packet Pipe, a Rad,t° Relay (RR) 11'~it 1 I O coupled to the RT unit, and a Radio Nodes (RN) unit 11D c~ulPled to the RR unit oIt the network side. Preferably, the packet pipe 106 has a point-to-ntuxtipoittt capability, and x p consequently, cart supP4~ a Plurality of different sEasions from a plurality of different user terminals.
'fhc packet pipe 106 also includes a pltu'ality of B.x (e.g., B.1 attd 8.2) interfaces that operate as indep~dendy as possible from the radio technology being used. Fut~tm4~~ ~e packet pipe 1D6 is designed to provide a plurality of radio bearer services to the higher protocol layers (layers 3 arid above), which services are characterized by different QcS P~~e~ ~~ define a set of QoS levels. 'These QoS
levels can be associated with the applications in~~olved, such as, for exasuple, Voice over IP (~OIP), best effort data, data sync~ttronixed with voice, ecc_ As such, the RT
unit 148 and RN unit 112 f~capn to terminate the pr4tocols from the access roofer I 16 and tertninais 102, Tespectively. The ~.R mot 110 cart be a wireless transmitter andlor reGeive~, of a repcater_ The network 1 OD also includes an Intetwprking Functions ttttit at the Network Side (IWF NS) 114, which is coupled to the P:N unit 112 of the packet pipe.
The 1WF NS unit 114 functions to map the application flows existing between the B.2 t3N0 Ot1~31946 pCTI~E99~OZI79 interface and W-2.1 itaterface (described in detail below). For this embodiment, one IVY NS unit 114 can serve a plurality of communication sessions through a single packet pipe (106)_ Preferably, the 1~_NS unit snaps all ongoing applications, such as, for example, voice, data, etc., from a plurai'iCy of termit:als. For example, the Medium Access ConErol (MAC) Part of layer ~ (data link layer) can participate in scheduling packets from terminals operating i'n a shared resource (e.g., within the coverage of the packet pipe). The packets can b~e mapped onto relevant bearers that carry the packets in accordance with predetermined criteria, such as, far example, a QaS requirement for latency, ecc-Ip Far this embodiment, an access routes 115 provides connectivity iv apluraliry of Wide Area Networks (WANs). such as, for ex;urrple, IP ztetwork 118: A.s such, the aceess scoter operates in a conventional manner uo direct the data flowing to/frotti the WANs. Specificall)r, the primary purpose for using the access rottter as an "edge device" is to be able to provide (with a single .access device) uniform access for a multiplicity of se~ces, along with a relatively flexible bandwidth allocation capability, far each type ofgaeket; cell attdlar voice agplication handled.
r~s such, the access muter 116 funceio~s as a service access node and cart provide dlfferetluated access fune~ons in. accordance with the particular service a user has reqatested. For example, a conveutiQnal access roofer can bE: used to provide art authenricatian capability which protects an authori2ed user's iir~for=nation base (in order to provide proper access service), and also avoids inierfer~ence from a malicious user.
A gatekeeper unit 12fl operates to handle call slgtialling attd service functions (e_g_, address resolutiAn, bandwidth control, claargitsg, etc.) far the endpoints (e_g., te~titutl-to-iertninal, gateway-to terminal, or gavteway-to-gateway) in, for example, an wo oar~t9$~
1-L3?3-based (audio, video, data) netu'ork_ As such, gatekeeper functions can be provided within a gateway device or by a separate gatekeeper node (e.g_, handling up tQ several gateway devices at a time). BY Way of example, a gatekeeper unit can take pate in the call handling processes, call signalling, conversion or mapping of IP
addresses to associated phone numbers ar userpon m numbers, bandwidth allocation, fee charging, etc-A Public Switched Telephone Networ3clISDN (I'STN/ISDl~ gateway 122 operates to providE canne<tivic~r between ceTi~ll~ IP-based services, such as>
for example, VOID, and PSTN~SDN native se:vices. The PSTN/ISDN gateway can have ld the following interfaces: a W.2.2 interface to the access roister, and a W.2.3 int~aface to a PSTNIISDN network using such known in~~faces and protocols as, far example, ITU StatidaTd G.7~3 or Synchronous Dip'ta1 Hierarchy (SDH) and V~. Ttie f STNIISDN gateway can provide such function: as protocol convErsion. such as, far example, converting from an IP based protocol stack to a pertinent telecommunications protocol stack (e.g., PSTNfIISDN protocol stack oz' OSIIMTP-based protocol stack)-An ATM gateway 124 provides service connectivity between IP,based services and ATM nati~ a spices. The ATM gateway can also provide gatekeeper functions.
The ATM gateway earl be used if ATM native services (e.g., Voice Over ATM, 2p Classical IF Over ATM, etc.) are supported by Gun R.TM service netwc~Tk. An Element Management System (EMS) 126 provides monitoring and Operational con~roi functions for the elements comprisitlg the fixed radio access network 1A0.
As mentioned above apd shown in F'IGLJRE 213 the access network 1Q0 includes a plurality of interfaces at different reference points in the network. For fCi'1SE99~p~1"19t ttr0 OOI~l9sb -1.0-example. the W.3 -interface is located between the',fE unit lp2 and IWF US.
unit 104.
preferably, Ehe W.3 interface is an open interface pe.g., IP over an Ethemet or USB).
A B.1 interface i$ located between the IWF_US unlit ltD4 arid the packet pipe 106. The B_1 interface is preferably a prapnetaty t~terface" but it also, can be non-proprietary S fpr other uses. For example, a B.1 interface can tie standardized in accordance with an agreement between different access technology suppliers andlor operators.
A W.1 interface (e.g., air interface) is located between the RT unit I 08 and RR
tirait 110 or RN unit 112 (uot shown). Ip a different embodiment, the W.1 or radio air interface can also be located between the RR unit 110 and RN unit 112. The W.1 1Q interface cave be proprietary or nor;-proprietary.
A B.2 -interface is located between the packet pipe 106 and the IWF NS unit l l~t_ The B_2 inte~'ace is pxefecably a proprietary interface, bttt it can also be nnn-proprietary far other uses. Similar to a B.1 intGrfice, for example, a ~.2 interface can be standardized in aGCOrdarice with an agreement lbetween different access technology 15 suppliers andlor opetatozs.
A W.2.1 -Interface is located between the: IWF NS unit 114 and the edge or access muter llfi_ The W-2.1 interface is pre:fetably tzon-p'ropnetarY.~ A
W:'.2 interface is Located between the edge oT access tourer 116 and the IP Network 118, Gatekeeper 120, PSTNIISDN Gateway 122, and ATM Gateway I2~4. The W.2.2 20 interface is preferably a non-proprietary interface:, such as, for example, IP over Frame relay, ATM, or SC?bfETlSI3H. p W.2.3 itstecface is located between the pSTN/iSpN
Gateway 122 and PSTNIISDN Network 128, amd the ATM Gateway 124 and ATM
Network 130. The W.2.3 irnerface is preferabl'~r a non-proprietary interface such as, for exattzple, V~.2 or ATl4i forum User Network Interface (LJIVI)_ WO p0l319db A B.3 interface is located between the EMS unit 126 and various components of the radio access network 100. The 8.3 interface can be a proprietary or mon-proprietary interface- A a.4 ~ntet~e is provided between, the EMS unit and the upper layer network tn~Sem~c ~st~' ~e E.4 iaterfar_e can also be a proprietar,,r oT
nnn-proprietary intcrface.
A.s m~tiorted above, the layer 1 and layer 2 packet pipe (106) provides a plurality of radio bearer -services to the higher pmu~coI layers, which services can be characterized by diffe~eni Quality of Service (QoS) parameters. For this embodimeaT, the access network 100 manages QoS with the following approaches: integrated 14 Services (IntSer~~) orReSGrVation Protocol (RSVP) support; Differentiated Services (pifl5er'v} support; or by using a "drill down" prou~col technology which can transfer QoS parameters down fl'om the higher to the lower protocol stacks of the packet pipe 106. In accc~tdar~ce with the preferred embodiment; of the present Invention, a protocol stack forthe packetpipe 1 D6 wblch caaprovide QoS differentiation (DiftSet''~) support is shown in F1GURE 3.
As illusta-ated by the protocol stack shown in, FIGURE 3, the IP global tows a;e te'ttninated at the edges of the packet pipe 106 to provide pa'eket classification. The RSVP services ate cet;ztinated to access resource reservation parameters in order to manage sessions in the packet pipe. Also, a tourer-like technology is applied at the edges of the packet pipe. For example, the )=dge muter 116 differentiates packets in accordance wish the different QoS requirements imposed. This differentiation between packets can be performed using, for example, RSVP (developed for supporiVg different QoS classes in IP applic~itions, such as video-conferemcing, PCT4SE99A'117q WO 00!31946 multimedia, ecc.)> or a DiffServ ciassifcation fi;action. Notably, various nerwork transport mechanisms may be used with each Di:ffSetv class.
As mentioned earlier, a primary function of the packet pipe I Qf is to provide layer I and layer 2 functionalitx for conveying ~packetized traff c across a radio air interface (e.g., W. I inlerfa~ce in this example). Tlae incaface between the padcet pipe l Oft and the upper layers in the overall protocol architecture also deterraitte$ the type ofpackeas (e.g., Packet Data Units or PhTJs) that are submitted for ttansfer.
As such, the primary scenati~s for the packet pipe 106 ~.an be described as follows: an IP-optimized packet pipe; an ATM-optimized packet pipe; and a packetpipe that supports both the IP and ATM models. The packct pipe provides an interface to the ~WFs to reserve, remove or maintain a radio resource in agreement with the negotiated QoS_ in accordance wish the prefcrred embodiment of the present invention, the packet pipe i 06 can be designed to meet cextaira general requirements- A
first requirement is that the packet pipe supports provision.of different QoS
classes to the 1 S higher layers. In that regard, a set of QoS classes in the packet pipe are def ned. The packet pipe is then responsible for delivcring s<<tisfactory services within those (aoS
classes. A second requirement is that proper m~echat'usnls gist to efFciently utilize seance radio resources when they are allocated for different inforlnacion flows, and also to obta=n cf$cient access to the backbone network. A third requirement is that for proper radio resource capacity, the packet pipe'S'~ design. should account for link budget Galculatiot~s, in order to ensure that a satisfactory Bit Error Rate (BER) is secured for the Physical layer channels.
A fourth requirement for the packet pipe l4fi is that mechanisms be provided to ensure that fairness principles govern when allocating radio resources to different wo uam94s sessions or users belan~g to the same CaoS class. In this regard, ~ packet pipe can prioritize packet traffic belonging to the same or a di#ferent QoS class during petiods of congestion, which can leave control over the utilization of these scarce radio xesc~urces up to an operator.
p, f ~ requirement for the packet pipe 1 OEi is that it be capable of seginertting and reassembling dat$ trat»ntSStons. The packet ~~pipe is required to provide e~ftcient medium access conixol that also includes retrattstnission of erroneous data.
This requires a segmcniazAOa f~utCUon that splits ineeuun~ P~1~~ (1'I-PDUs) into smallez units prior to transmission across the radio air inte:t!face, in order to optimize the radio transfer by combining ihc Forward Err4r Correcuon (FEC) or redundancy by coding, attd the $ackward Error Correction ($)~C) or red~~ndancy by retraztsmission-Also, by sending smaller data units over the radio atr interface, the preemption g;anttlarity bewtnes smaller yvl~ich allows a finer tuning o1" the radio access for diffaezit QoS
Basses. Finally, a packet reassemblY capability is required on the receiver side.
1 S Although a preferred embodiment of the method and apparatus of the present inrrention has been illustrated in the accotnpanyitig Drawings and described in the foregoing Detailed Description, it will be under.,rood that the invention is not liruited to the embodiment disclosed, but is capa~hlo of numerous reatrangcmenis, modifications and substitutions without departing from the spirit of the invention as set Earth and defined by the follpWing claims.
Claims (31)
1. A method for network access using a communications traffic conveyor, comprising the steps of:
standardizing a user interface for said communications traffic conveyor;
standardizing a network interface for said communications traffic conveyor;
arranging said communications traffic conveyor to comply with at least one standardization parameter for said user interface;
arranging said communications traffic conveyor to comply with at least one standardization parameter for said network interface; and conveying traffic between said user interface and said network interface in compliance with said at least one standardization parameter for said user interface, and said at least one standardization parameter for said network interface, wherein said communications traffic conveyor prioritizes traffic.
standardizing a user interface for said communications traffic conveyor;
standardizing a network interface for said communications traffic conveyor;
arranging said communications traffic conveyor to comply with at least one standardization parameter for said user interface;
arranging said communications traffic conveyor to comply with at least one standardization parameter for said network interface; and conveying traffic between said user interface and said network interface in compliance with said at least one standardization parameter for said user interface, and said at least one standardization parameter for said network interface, wherein said communications traffic conveyor prioritizes traffic.
2. The method of Claim 1, wherein said communications traffic conveyor comprises a packet pipe.
3. The method of Claim 1, wherein said at least one standardization parameter for said user interface comprises a first Quality of Service parameter.
4. The method of Claim 1, wherein said at least one standardization parameter for said user interface comprises a second Quality of Service parameter.
5. The method of Claim 1, wherein said first standardization parameter is equal to said second standardization parameter, and said network comprises a radio network.
6. A system for network access, comprising:
a communications traffic conveyor, said communications traffic conveyor including a termination unit coupled to a user interface on a user side, and a node coupled to a network interface on a network side;
means for said communications traffic conveyor to comply with at least one standardization parameter for said user interface;
means for said communications traffic conveyor to comply with at least one standardization parameter for said network interface;
means for said communications traffic conveyor to prioritize traffic; and means for conveying said traffic between said user interface and said network interface in compliance with said at least one standardization parameter for said user interface, and said at least one standardization parameter for said network interface.
a communications traffic conveyor, said communications traffic conveyor including a termination unit coupled to a user interface on a user side, and a node coupled to a network interface on a network side;
means for said communications traffic conveyor to comply with at least one standardization parameter for said user interface;
means for said communications traffic conveyor to comply with at least one standardization parameter for said network interface;
means for said communications traffic conveyor to prioritize traffic; and means for conveying said traffic between said user interface and said network interface in compliance with said at least one standardization parameter for said user interface, and said at least one standardization parameter for said network interface.
7. The system of Claim 6, wherein said communications traffic conveyor comprises a packet pipe.
8. The system of Claim 6, wherein said at least one standardization parameter for said user interface comprises a first Quality of Service parameter.
9. The system of Claim 6, wherein said at least one standardization parameter for said user interface comprises a second Quality of Service parameter.
10. The system of Claim 6, wherein said first standardization parameter is equal to said second standardization parameter, and said network comprises a radio network.
11. The method of Claim 1, wherein said step of standardizing a network interface further comprises:
standardizing said network interface such that any communications traffic conveyor that satisfies network interface requirements can be utilized for said network access.
standardizing said network interface such that any communications traffic conveyor that satisfies network interface requirements can be utilized for said network access.
12. The method of Claim 1, further comprising the step of:
providing multiple transmission layers for said communications traffic conveyor to convey traffic via an interface.
providing multiple transmission layers for said communications traffic conveyor to convey traffic via an interface.
13. The method of Claim 12, further comprising the step of:
supporting different Quality of Service classes to higher of said multiple transmission layers.
supporting different Quality of Service classes to higher of said multiple transmission layers.
14. The method of Claim 1, further comprising the step of:
providing point-to-multipoint function for said communications traffic conveyor, such that said communications traffic conveyor can support a plurality of sessions from a plurality of user terminals.
providing point-to-multipoint function for said communications traffic conveyor, such that said communications traffic conveyor can support a plurality of sessions from a plurality of user terminals.
15. The method of Claim 1, further comprising the step of:
mapping application flows existing between said user interface and said network interface.
mapping application flows existing between said user interface and said network interface.
16. The method of Claim 1, further comprising the step of:
dispensing a plurality of services by said communications traffic conveyor.
dispensing a plurality of services by said communications traffic conveyor.
17. The method of Claim 16, further comprising the step of:
predetermining a set of primitives associated with said plurality of services dispensed by said communications traffic conveyor.
predetermining a set of primitives associated with said plurality of services dispensed by said communications traffic conveyor.
18. The method of Claim 1, further comprising the step of:
defining a set of Quality of Service classes for said communications traffic conveyor to support.
defining a set of Quality of Service classes for said communications traffic conveyor to support.
19. The system of Claim 6, further comprising:
a relay unit, coupled to said termination unit, for transmitting information through said communications traffic conveyor.
a relay unit, coupled to said termination unit, for transmitting information through said communications traffic conveyor.
20. The system of Claim 18, wherein said relay unit is further coupled to said node coupled to a network interface.
21. The system of Claim 6, wherein said communications traffic conveyor supports a plurality of sessions from a plurality of user terminals.
22. The system of Claim 6, further comprising:
an access router on said network side, for connecting to a plurality of networks.
an access router on said network side, for connecting to a plurality of networks.
23. The system of Claim 21, wherein said plurality of networks comprises:
Wide Area Networks.
Wide Area Networks.
24. The system of Claim 21, wherein said access router directs data flow to and from said plurality of networks.
25. The system of Claim 6, further comprising:
an Interworking Functions unit coupled to said node, said Interworking Functions unit mapping application flows on said network side.
an Interworking Functions unit coupled to said node, said Interworking Functions unit mapping application flows on said network side.
26. The system of Claim 19, further comprising:
a gatekeeper unit, located on said network side, for handling call signaling and service functions.
a gatekeeper unit, located on said network side, for handling call signaling and service functions.
27. The system of Claim 6, wherein said traffic comprises:
data.
data.
28. The method of Claim 26, wherein said data is segmented by said communications traffic conveyor before said data is conveyed.
29. The method of Claim 27, wherein said data is reassembled by said communications traffic conveyor after said data is conveyed.
30. The system according to Claim 6, wherein said communications traffic conveyor accounts for link budget calculations.
31. The system according to Claim 29, wherein said link budget calculations are associated with Bit Error Rate.
Applications Claiming Priority (5)
| Application Number | Priority Date | Filing Date | Title |
|---|---|---|---|
| US10989998P | 1998-11-25 | 1998-11-25 | |
| US60/109,899 | 1998-11-25 | ||
| US09/438,225 US6747986B1 (en) | 1998-11-25 | 1999-11-12 | Packet pipe architecture for access networks |
| US09/438,225 | 1999-11-12 | ||
| PCT/SE1999/002179 WO2000031946A2 (en) | 1998-11-25 | 1999-11-24 | Packet pipe architecture for access networks |
Publications (1)
| Publication Number | Publication Date |
|---|---|
| CA2352374A1 true CA2352374A1 (en) | 2000-06-02 |
Family
ID=26807486
Family Applications (1)
| Application Number | Title | Priority Date | Filing Date |
|---|---|---|---|
| CA002352374A Abandoned CA2352374A1 (en) | 1998-11-25 | 1999-11-24 | Packet pipe architecture for access networks |
Country Status (11)
| Country | Link |
|---|---|
| US (2) | US6747986B1 (en) |
| EP (1) | EP1142268B1 (en) |
| JP (1) | JP2002531011A (en) |
| KR (1) | KR100605265B1 (en) |
| CN (1) | CN1391760A (en) |
| AU (1) | AU769836B2 (en) |
| BR (1) | BR9915655A (en) |
| CA (1) | CA2352374A1 (en) |
| DE (1) | DE69927405T2 (en) |
| MX (1) | MXPA01004668A (en) |
| WO (1) | WO2000031946A2 (en) |
Families Citing this family (24)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| US6778517B1 (en) * | 1999-10-14 | 2004-08-17 | Bellsouth Intellectual Property Corporation | Wireless broadband service |
| US6891825B1 (en) * | 1999-12-22 | 2005-05-10 | Mci, Inc. | Method and system of providing multi-user access to a packet switched network |
| FI108593B (en) * | 1999-12-31 | 2002-02-15 | Nokia Oyj | Packet routing in a multi-service network |
| US7111163B1 (en) | 2000-07-10 | 2006-09-19 | Alterwan, Inc. | Wide area network using internet with quality of service |
| US20020064152A1 (en) * | 2000-11-28 | 2002-05-30 | Lemley Donald G. | Packet voice gateway |
| US7068645B1 (en) * | 2001-04-02 | 2006-06-27 | Cisco Technology, Inc. | Providing different QOS to layer-3 datagrams when transported on tunnels |
| US7477638B1 (en) * | 2001-07-03 | 2009-01-13 | Cisco Technology, Inc. | Interworking of IP voice with ATM voice using server-based control |
| US20080002669A1 (en) * | 2001-09-14 | 2008-01-03 | O'brien Ray | Packet voice gateway |
| US7580424B2 (en) * | 2001-09-25 | 2009-08-25 | Hughes Network System, Llc | System and method for providing real-time and non-real-time services over a communications system |
| EP1440589A1 (en) * | 2001-10-19 | 2004-07-28 | Nokia Corporation | Multicast transmission to a radio access network |
| US7293150B2 (en) * | 2002-06-28 | 2007-11-06 | Microsoft Corporation | Method and system for creating and restoring an image file |
| US7443831B2 (en) * | 2003-10-03 | 2008-10-28 | Nortel Networks Limited | Call control using a layered call model |
| JP4287430B2 (en) * | 2003-10-15 | 2009-07-01 | 株式会社エヌ・ティ・ティ・ドコモ | Apparatus and method for controlling operation of a plurality of communication layers |
| US20050147035A1 (en) * | 2003-12-24 | 2005-07-07 | Nortel Networks Limited | Multiple services with policy enforcement over a common network |
| US8059672B2 (en) | 2005-05-18 | 2011-11-15 | Sprint Communications Company L.P. | Internet communications between wireless base stations and service nodes |
| CN100484093C (en) * | 2005-06-29 | 2009-04-29 | 华为技术有限公司 | Internetwork data business communicating method |
| PL2109266T3 (en) * | 2006-02-05 | 2011-09-30 | Ericsson Telefon Ab L M | Method and devices for installing packet filters in a data transmission |
| US8576795B2 (en) | 2007-03-16 | 2013-11-05 | Qualcomm Incorporated | Method and apparatus for handoff between source and target access systems |
| US9049629B2 (en) | 2007-06-18 | 2015-06-02 | Qualcomm Incorporated | Method and apparatus for fast inter-system handover |
| US8755793B2 (en) | 2008-01-04 | 2014-06-17 | Qualcomm Incorporated | Apparatus and methods to facilitate seamless handoffs between wireless communication networks |
| US8638749B2 (en) | 2008-06-06 | 2014-01-28 | Qualcomm Incorporated | Method and apparatus for inter-network handoff |
| US8681626B1 (en) | 2010-02-17 | 2014-03-25 | Sprint Communications Company L.P. | Translation of congestion notification indicators in a base station system |
| CN101808173B (en) * | 2010-03-10 | 2013-04-17 | 杭州华三通信技术有限公司 | Method and apparatus for adaptively adjusting negotiable parameters of MODEM (Modulator-Demodulator) |
| CN101847300B (en) * | 2010-04-30 | 2012-05-23 | 杭州华三通信技术有限公司 | Parameter consultation method and equipment for accessing POS terminal access interface of server |
Family Cites Families (21)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| US5438565A (en) * | 1993-03-31 | 1995-08-01 | At&T Corp. | Packet switch to provide code division, multiple access cellular service |
| US5412660A (en) * | 1993-09-10 | 1995-05-02 | Trimble Navigation Limited | ISDN-to-ISDN communication via satellite microwave radio frequency communications link |
| US5619550A (en) * | 1993-09-23 | 1997-04-08 | Motorola, Inc. | Testing within communication systems using an arq protocol |
| US5434854A (en) * | 1993-12-27 | 1995-07-18 | At&T Corp. | System for communicating digital cellular data between a cell site and a switching system or another cell site |
| JPH07307738A (en) * | 1994-05-13 | 1995-11-21 | Mitsubishi Electric Corp | Protocol processor |
| US5633868A (en) * | 1994-10-17 | 1997-05-27 | Lucent Technologies Inc. | Virtual circuit management in cellular telecommunications |
| US5794149A (en) * | 1995-12-29 | 1998-08-11 | Lucent Technologies Inc. | Base station controlled handoff method and apparatus |
| US5729536A (en) * | 1996-04-10 | 1998-03-17 | Lucent Technologies | Cellular system architectures supporting data services |
| US5974496A (en) * | 1997-01-02 | 1999-10-26 | Ncr Corporation | System for transferring diverse data objects between a mass storage device and a network via an internal bus on a network card |
| US6049593A (en) * | 1997-01-17 | 2000-04-11 | Acampora; Anthony | Hybrid universal broadband telecommunications using small radio cells interconnected by free-space optical links |
| US6259699B1 (en) * | 1997-12-30 | 2001-07-10 | Nexabit Networks, Llc | System architecture for and method of processing packets and/or cells in a common switch |
| FI108192B (en) | 1998-03-19 | 2001-11-30 | Nokia Networks Oy | A method and apparatus for controlling quality of service in a mobile communication system |
| US6377579B1 (en) * | 1998-06-11 | 2002-04-23 | Synchrodyne Networks, Inc. | Interconnecting a synchronous switching network that utilizes a common time reference with an asynchronous switching network |
| US6452915B1 (en) * | 1998-07-10 | 2002-09-17 | Malibu Networks, Inc. | IP-flow classification in a wireless point to multi-point (PTMP) transmission system |
| US6125110A (en) * | 1998-07-31 | 2000-09-26 | Motorola Inc. | Method and system for determining a packet transmission order |
| US6381455B1 (en) * | 1998-10-15 | 2002-04-30 | Lucent Technologies Inc. | System and method for warning of and providing greater immunity from an impeding call drop in a digital wireless system |
| US6526063B1 (en) * | 1998-12-23 | 2003-02-25 | Nortel Networks Limited | System and method for ATM-FR interworking of SVC signalling |
| US6275578B1 (en) * | 1998-12-23 | 2001-08-14 | At&T Corp. | Method and apparatus for providing back-up, in-band signaling in a communications network |
| EP1117265A1 (en) * | 2000-01-15 | 2001-07-18 | Telefonaktiebolaget Lm Ericsson | Method and apparatus for global roaming |
| EP1117266A1 (en) * | 2000-01-15 | 2001-07-18 | Telefonaktiebolaget Lm Ericsson | Method and apparatus for global roaming |
| US6856628B1 (en) * | 2000-10-26 | 2005-02-15 | Motorola, Inc. | Method and apparatus for tunneling packets in a packet data system |
-
1999
- 1999-11-12 US US09/438,225 patent/US6747986B1/en not_active Expired - Lifetime
- 1999-11-24 WO PCT/SE1999/002179 patent/WO2000031946A2/en active IP Right Grant
- 1999-11-24 BR BR9915655-5A patent/BR9915655A/en not_active IP Right Cessation
- 1999-11-24 EP EP99963751A patent/EP1142268B1/en not_active Expired - Lifetime
- 1999-11-24 MX MXPA01004668A patent/MXPA01004668A/en not_active IP Right Cessation
- 1999-11-24 KR KR1020017006563A patent/KR100605265B1/en not_active IP Right Cessation
- 1999-11-24 AU AU20124/00A patent/AU769836B2/en not_active Ceased
- 1999-11-24 JP JP2000584662A patent/JP2002531011A/en active Pending
- 1999-11-24 CA CA002352374A patent/CA2352374A1/en not_active Abandoned
- 1999-11-24 CN CN99813731A patent/CN1391760A/en active Pending
- 1999-11-24 DE DE69927405T patent/DE69927405T2/en not_active Expired - Fee Related
-
2004
- 2004-04-12 US US10/822,590 patent/US20040190450A1/en not_active Abandoned
Also Published As
| Publication number | Publication date |
|---|---|
| KR100605265B1 (en) | 2006-07-26 |
| JP2002531011A (en) | 2002-09-17 |
| EP1142268B1 (en) | 2005-09-21 |
| CN1391760A (en) | 2003-01-15 |
| KR20010082314A (en) | 2001-08-29 |
| AU2012400A (en) | 2000-06-13 |
| AU769836B2 (en) | 2004-02-05 |
| DE69927405D1 (en) | 2005-10-27 |
| WO2000031946A3 (en) | 2000-11-09 |
| US20040190450A1 (en) | 2004-09-30 |
| US6747986B1 (en) | 2004-06-08 |
| BR9915655A (en) | 2001-10-16 |
| WO2000031946A2 (en) | 2000-06-02 |
| MXPA01004668A (en) | 2002-04-24 |
| EP1142268A2 (en) | 2001-10-10 |
| DE69927405T2 (en) | 2006-06-22 |
Similar Documents
| Publication | Publication Date | Title |
|---|---|---|
| CA2352374A1 (en) | Packet pipe architecture for access networks | |
| US20020034162A1 (en) | Technique for implementing fractional interval times for fine granularity bandwidth allocation | |
| US8295303B2 (en) | System and method for transmission of frame relay communications over a digital subscriber line equipped with asynchronous transfer mode components | |
| US20020154629A1 (en) | Integrated PMP-radio and DSL multiplexer and method for using the same | |
| US20020059426A1 (en) | Technique for assigning schedule resources to multiple ports in correct proportions | |
| US7088724B2 (en) | Communication system interfacing control of quality of service (QOS) of asynchronous transfer mode (ATM) and internet protocol (IP) | |
| US20020163883A1 (en) | Methods and systems for providing call admission control in packetized voice networks | |
| MXPA02003528A (en) | System and method for providing pots services in dsl environment in event of failures. | |
| CN1764144A (en) | Method for carrying out VPR protection inversion in network | |
| US7023829B1 (en) | Systems and methods for providing communication between an ATM layer device and multiple multi-channel physical layer devices | |
| US20020078465A1 (en) | Method of providing high-speed digital services over a switched telephone network | |
| MXPA02003527A (en) | Components for providing voice and or data service. | |
| Doshi et al. | An ATM based PCS/cellular architecture | |
| Cisco | Service Modules | |
| EP1346599B1 (en) | Method of optimizing equipment utilization in telecommunication access network | |
| Cisco | Service Modules | |
| Cisco | Multiservice Access Technologies | |
| EP1113696A2 (en) | ATM over DSL service | |
| US20040125936A1 (en) | Method and apparatus to optimize bandwidth for compressed voice data | |
| US20040125810A1 (en) | Method and apparatus for enabling POTS telephony functionality over a network | |
| US6925093B2 (en) | Communication apparatus, communication system and method for integrating speech and data | |
| Chabalala et al. | AAL2 Tunneling over IP in the UTRAN | |
| Sawkar | An ATM Based PCS/Cellular Architecture Bharat T. Doshi AT&T Bell Laboratories Holmdel, NJ 07733, USA | |
| van de Meulenhof et al. | Technische Universiteit tlî) Eindhoven | |
| Salem | A study of ATM-frame relay cost effective interworking access at customer premises |
Legal Events
| Date | Code | Title | Description |
|---|---|---|---|
| EEER | Examination request | ||
| FZDE | Discontinued |