0 I ·- / '7- - 0 f
`PTO/SB/16 MODIFIED BY AT&T CORP.
`This is a request for filing a PROVISIONAL APPLICATION FOR PATENT under 37 CFR 1.53(c). 4/ pru V
`PROVISIONAL APPL/CAT/ON FOR PA TENT COVER SHEET
`
`-
`
`,-3
`0
`Matthew J. Sherman
`Name (line 1)
`Address (line 1) 4 Atlantis Drive
`Addtess (line 2) Succasunna
`Address (line 3) Morris County
`Address (line 4) NJ
`USA
`Address (line 5)
`07876
`
`Zip Code
`
`I Docket Number I 2001-0027
`
`INVENTOR(S)
`
`e -
`a.U") -
`-
`..,..,t =,
`ai,a,. = c
`::>cq
`':i
`;.c::,-
`u -
`.... · .. ~ ===c
`..,
`
`OAdditional Inventors are being named on the separately numbered sheets attached hereto
`
`TITLE OF THE INVENTION (180 characters max)
`Interoperability Methods For IEEE 802.lla And HIPERLAN
`
`CORRESPONDENCE ADDRESS
`
`Customer Number or Bar Code Label
`
`(Insert Customer No. or Attach bar code label here)
`
`or
`
`181 Correspondence address below
`
`.::
`NAMF
`Samuel H. Dworetsky
`AD~ESS AT&T CORP. P.O. Box 4110
`I New Jersey I ZIP CODE I 07748-4110
`CIT(t
`Middletown
`I 732-368-6932
`I FAX
`COUtJTRY United States of America
`ENCLOSED APPLICATION PARTS (check all that apply)
`D Small Entity Statement
`D other (specify)
`t81 Return Receipt Postcard (MPEP 503)
`
`:il.
`
`I STATE
`
`0 Specification Number of Pages 3
`t8I ptawing(s) Number of Sheets 12
`--
`ijVIETHOD OF PAYMENT OF FILING FEES FOR THIS PROVISIONAL APPLICATION FOR PATENT (check one)
`
`;r:::::::
`
`The~c'ommissioner is hereby authorized to charge filing fees or credit any overpayment to Deposit Account Number: 01- 2 7 4 5
`
`The invention was made by an agency of the United States Government or under a contract with an agency of the
`United States Government
`~No.
`D Yes, the name of the U.S. Government agency and the Government contract number are:
`
`SIGNATURE OF APPLICANT, ATTORNEY, OR AGENT REQUIRED
`Re . #
`NAME
`Alfred G. Steinmetz
`22971
`TELEPHONE 908-221-5425
`SIGNATURE
`"Express Mail" Mailing Lab I Number
`I hereby certify that this
`provisional application
`Is being deposited with the United States Postal Service "Express Mail Post Office to Addressee" service under 37 CFR 1.10 on the date indicated above
`and is addressed to the Assistant Commissioner of Patents, Washington D.C. , 20231
`
`DATE
`01/15/2001
`Date of Deposit
`01/15/2001
`
`Marvell Semiconductor, Inc. - Ex. 1011, Page 0001
`IPR2019-01350 (Marvell Semiconductor, Inc. v. Uniloc 2017 LLC)
`
`

`

`Interoperability Methods
`For IEEE 802.lla and HIPERLAN
`Matthew Sherman
`Jan.14,2001
`
`Background of the Invention
`
`Wireless data transmission is a rapidly growing field. One increasingly popular form of such transmission
`is wireless local areas networks (WLANs). A number of standards currently exist for WLANs. However
`they tend to be fragmented and largely incompatible. There is desire for a worldwide standard that would
`allow a single device to function virtually anywhere in the world providing high-speed connectivity.
`
`Recently, bands have opened up that hold that promise between 5 and 6 GHz. Wireless standards are being
`developed to utilize those bands. One such standard is HIPERLAN/2 (High Performance Radio Local Area
`network Type 2), which is of European origin [1-3]. Another such standard is IEEE 802.1 la, which
`originate primarily in the US [4-5]. Japan is developing standards similar to both those in the US and
`Europe. Both the US and European standards profess similar levels of perfo1mance, and use very similar
`waveforms to communicate. However, the two standards are currently incompatible - Particularly at the
`Media Access Control (MAC) layer. As such a large push has developed to create a single hybrid standard,
`or provide some means for the two standards to easily interoperate.
`
`Methods for Interoperation ofHIPERLAN and 802.1 la systems are being contemplated in which systems
`conforming to both standards might share one common channel. A MAC frame structure has been
`proposed to support this application. The proposed structure contemplates a super frame with an 802.11
`phase and a HIPERLAN/2 phase (see FIG. X). The super frame has a length of 2k X 2 ms, where k is an
`integer. Duration of the 802.11 beacon plus the 802.11 a phase is set at n X 2rns. The HIPERLAN/2 phase
`comprises m x 2ms. The sum ofm and n would be 2k.
`
`While this is an interesting approach it does have some drawbacks. For one, the approach presumes the
`802.11 terminals can be prevented from transmitting during the HIPERLAN phase. Currently, no
`mechanism exists within the 802.11 standard to allow this. It is possible that new mechanisms could be
`introduced into newer versions of the standard, and be supported by future generations of 802.11 stations.
`However, the problem would be best addressed if the solution were somehow compatible with current
`generations of terminals. It is the purpose of this disclosure to present such solutions.
`
`Summary of the Invention
`
`This application builds upon prior work for developing interoperability between the HIPERLAN and
`802. J la standards. It builds upon mechanisms suggested in a prior application, to increase the
`interoperability possible between the two standards. Specifically, it introduces mechanisms to prevent
`802.11 terminals from transmitting during time periods allocated to HIPERLAN, so that a single channel
`can be shared between the two standards. It also improves upon the protection available by suggesting a
`"super frame" format where HIPERLAN transmissions are offered the highest level of protection possible
`within 802.11, which is that within the 802.11 Contention Free Period (CFP).
`
`Brief Description of Drawings
`
`See slide set titled "Proposed HIPERLAN 802.11 Compatibility Frame".
`
`Marvell Semiconductor, Inc. - Ex. 1011, Page 0002
`IPR2019-01350 (Marvell Semiconductor, Inc. v. Uniloc 2017 LLC)
`
`

`

`Detailed Description of Invention
`
`It has been suggested that a Superframe structure can be developed that allows 802.1 la stations (STA) to
`share a single channel with HIPERLAN/2 stations. One such proposal is shown in figure X. The problem
`is that there is nothing in the proposal that would force 802.1 la STA to cease transmissions during the
`HIPERLAN phase of the Superframe. The 802.1 la STA would view the HIPERLAN phase as a part of the
`802.11 Contention Period (CP), and would normally be free to transmit during the CP. 802.11 STA have a
`mechanism call the Network Allocation Vector (NA V) that can be set to prevent the STA from
`transmitting. However, the NA V is set only under very specific conditions that do not exist at the time the
`HIPERLAN/2 frames need to seize the medium.
`
`A prior application includes an 802.11 mechanism that can be used to cause the NA V to be set while the
`HIPERLAN/2 transmissions occur. The mechanism is called there an Enhanced CTS (ECTS). If the
`HIPERLAN/2 phase is proceeded by an ECTS with the duration field properly set prevent transmissions
`during the desired frame, then a working Superframe structure can be developed consisting of
`
`Beacon, 802.11 phase, ECTS, HIPERLAN/2 phase.
`
`The Superframe would then repeat, with a Beacon following the HIPERLAN/2 phase. The Superframe
`structure would be constructed such that its total length would be 2k times 2 milliseconds (msec), where k is
`an integer. The 802.11 Beacon period (time between Beacons) would be selected to be identical to the
`Superframe length. The HIPERLAN/2 phase would be n times 2 msec, and the 802.11 phase (which
`actually would include the Beacon and ECTS) would be m times 2 msec, where m+n = 2k. For greater
`coverage, an Enhanced RTS (ERTS) followed by CTS could be used instead of the ECTS.
`
`While this scheme could work, it does have one important drawback in that 802.1 la STA that are hidden
`from the STA sending the ECTS would not set their NA V's, and might transmit during the HIPERLAN/2
`phase of the superframe. This would interfere with the operation of the HIPERLAN/2 STA. To fix this, a
`different approach can be used where the HIPERLAN phase is buried in the Contention Free Period (CFP)
`of 802.11. The CFP occurs with a regular period, and all 802 .11 terminals set their NA V's during the CFP.
`To realize such a super frame the following sequence:
`
`CFP _ Beacon, 802.11 Broadcast, 802.11 CFP, HIPERLAN/2 phase, CF_ End, 802.11 CP
`
`Here, CFP _ Beacon is a Beacon starting a CFP. Not all Beacons need start a CFP. However, the CFP must
`recur every integral number of Beacons. The inference is that the Beacon period must be a sub multiple of
`the super frame size (which is still 2k time 2 msec). Now however, 3 phases really exist. The first would
`consist of the CFP _ Beacon, 802.11 Broadcast, and 802.11 CFP. This would need to be an integral number
`times 2 msec, and that number will be specified as 1 for this application. The HIPERLAN/2 phase would
`remain at n times 2 msec, and the CF_ End, 802.11 CP would have to be m times 2 msec. The sum l+m+n
`must be 2k.
`
`Note that Broadcast traffic must immediately follow a beacon which is why it is located as such. The
`HIPERLAN/2 phase will be viewed by 802.11 terminals as part of the CFP, and accorded protection
`accordingly. The CFP's maximum length is determined by a variable regularly broadcast in Beacon
`messages. It should be set very close to the full length of the superframe. To relinquish the time to the CP,
`when the CF _End is sent, all terminals will automatically reset their NA V's. Normal CP transmissions
`would then occur. Note that additional Beacons might occur during the CP that does not start a new CFP.
`The existence of these Beacons may make it easier to handle broadcast traffic, and 802.11 power saver
`terminals, but is not a requirement.
`
`There may be some concern about Beacon jitter since this may result in jitter in the superframe.
`HIPERLAN/2 is not very tolerant of jitter. However, by utilizing the ECTS mechanism ( or more likely an
`ERTS) jitter before the Beacon can be controlled. Alternatively, the Access Port (AP), which is a special
`STA, which provides access to a Distribution Service (DS) for the medium among other things, could just
`broadcast dummy traffic just prior to Beacon transmission if desired preventing other traffic from seizing
`
`Marvell Semiconductor, Inc. - Ex. 1011, Page 0003
`IPR2019-01350 (Marvell Semiconductor, Inc. v. Uniloc 2017 LLC)
`
`

`

`the medium. Also, while it is unlikely to be needed, an ECTS could still be transmitted prior to the
`HIPERLAN/2 phase if desired to further assure that no 802.11 STA are active during the HIPERLAN/2
`phase.
`
`References:
`
`[1]
`
`[2)
`
`[3]
`
`[4]
`
`[5]
`
`TS 101 761-1, Broadband Radio Access Networks (BRAN); Hlgh PErformance Radio Local Area
`Network (HIPERLAN) Type 2; Data Link Control (DLC) Layer - Part 1 Basic Data Transport
`Function, ETSI Project BRAN, 2000
`TS 101 761-2, Broadband Radio Access Networks (BRAN); Hlgh PErformance Radio Local Area
`Network (HIPERLAN) Type 2; Data Link Control (DLC) Layer - Part 2 - Radio Link Control
`(RLC), ETSI Project BRAN, 2000
`TS 101 475, Broadband Radio Access Networks (BRAN); HIPERLAN Type 2; Physical (PHY)
`Layer, ETSI Project BRAN, 2000
`IEEE, "Reference number ISO/IEC 8802-11:1999 (E) IEEE STD 802.11, 1999 edition. International
`Standard [for] Information Technology-Telecommunications and information exchange between
`systems-Local and metropolitan area networks-Specific Requirements- Part 11: Wireless LAN
`Medium Access Control (MAC) and Physical Layer (PHY) specifications", 1999.
`IEEE, "Supplement to STANDARD [for] Information Technology-Telecommunications and
`information exchange between systems-Local and metropolitan area networks-Specific
`requirements-Part 11: Wireless LAN Medium Access Control (MAC) and Physical Layer (PHY)
`specifications: High-speed Physical Layer in the 5 GHz Band," IEEE Std 802.1 la-1999, September
`1999.
`
`Marvell Semiconductor, Inc. - Ex. 1011, Page 0004
`IPR2019-01350 (Marvell Semiconductor, Inc. v. Uniloc 2017 LLC)
`
`

`

`January 14, 2001
`
`doc.: IEEE 802.11-01/XXX
`
`Proposed HIPERLAN / 802.11a
`Compatibility Superframe Format
`
`HIPERLAN / 802.11 a Compatibility Superframe
`
`Slide 1
`
`Matthew Sherman, AT&T Labs - Research
`
`Marvell Semiconductor, Inc. - Ex. 1011, Page 0005
`IPR2019-01350 (Marvell Semiconductor, Inc. v. Uniloc 2017 LLC)
`
`

`

`January 14, 2001
`
`doc.: IEEE 802.11-01/XXX
`
`Knowledge Assumed in this
`presentation
`
`• Strong working knowledge of 802.11
`- Reference IEEE 802.11 standards
`• Peripheral understanding of HIPERLAN
`- Reference similar HIPERLAN documentation
`• General understanding of MAC protocols
`
`HIPERLAN / 802.1 la Compatibility Superframe
`
`Slide 2
`
`Matthew Sherman, AT&T Labs - Research
`
`Marvell Semiconductor, Inc. - Ex. 1011, Page 0006
`IPR2019-01350 (Marvell Semiconductor, Inc. v. Uniloc 2017 LLC)
`
`

`

`<IJ~_..
`
`., ....
`
`U« 1LJl
`
`January 14, 2001
`
`doc.: IEEE 802.11-01/XXX
`
`Assumptions
`
`• Need may exist is some areas to interoperate
`802.1 la and HIPERLAN/2 systems
`• Some AP equipment may support both standards
`- Hybrid AP (HAP)
`• Stations (STA) would support either HIPERLAN/2
`or 802.1 la but need not support both
`• Desire a Superframe format that allow both
`standards to share one channel without interference
`
`HIPERLAN I 802.1 la Compatibility Superframe
`
`Slide 3
`
`Matthew Sherman, AT&T Labs - Research
`
`Marvell Semiconductor, Inc. - Ex. 1011, Page 0007
`IPR2019-01350 (Marvell Semiconductor, Inc. v. Uniloc 2017 LLC)
`
`

`

`Structure
`• Superframe with 802.11 a phase and HiperLAN2 phase
`- Superframe of length 2k x 2 ms, where k is an integer
`- Beacon, 802.1 la phase and HiperLAN2 phase
`- Duration of the beacon plus 802.1 la phase: n x 2 ms
`- HiperLAN2 phase consists of m HiperLAN2 MAC frames
`
`nx2ms
`
`mx2ms
`
`2ms
`
`Beacon
`
`Super frame of length 2k x 2 ms
`HIPERLAN I 802.1 la Compatibility Superframe
`
`Slide 4
`
`Matthew Sherman, AT&T Labs -Research
`
`Marvell Semiconductor, Inc. - Ex. 1011, Page 0008
`IPR2019-01350 (Marvell Semiconductor, Inc. v. Uniloc 2017 LLC)
`
`

`

`"li'1•
`il"
`
`<'1J,\« ")j'"
`
`fJ1:
`
`!~,
`
`(_l)c,
`
`"ll:"' <\.1'°1J U,t>tl, .... ><<J,. ~~'"!;,
`:;;{1 ii;;;;;, if,,,j~ ::;;f£
`jf,,
`
`Januarv 14, 2001
`
`doc.: IEEE 802.11-01/XXX
`
`Drawbacks to Ericsson Proposal
`
`• No way to set NAV in 802.1 la terminals to
`cover HIPERLAN/2 transmission
`• Even ifNAV were set, 802.11 STA may
`start transmission just before NA V set
`
`• These capabilities can be added to 802.11 e
`STA, but legacy 802.1 la STA cannot be
`changed.
`
`HIPERLAN I 802.1 la Compatibility Superframe
`
`Slide 5
`
`Matthew Sherman, AT&T Labs -Research
`
`Marvell Semiconductor, Inc. - Ex. 1011, Page 0009
`IPR2019-01350 (Marvell Semiconductor, Inc. v. Uniloc 2017 LLC)
`
`

`

`"!}.'" ,i.~"h- •H"I,. "t,'u "li,'" ,}><<!~ Hi
`Jli,
`{{ .. ,i~
`u"'. 11,,,!f ;:;;}f f~,,
`
`,t.".'J" .,1,•
`it::,, IL,t~
`
`"IJ.f!'
`jf,,
`
`•l'·''f,', '""'ii.
`·;;;;rt IJ;;;;;
`
`<IP~i"/
`
`;·;;;t
`
`January 14, 2001
`
`doc.: IEEE 802.11-01/XXX
`
`AT&T Modified Ericsson Proposal
`• HAP transmits spoofing frame
`- Null or other frame type with duration field set to cover
`HIPERLAN/2 Phase
`- Use PCF Inter-Frame Spacing (PIFS) for priority access
`• Requires mod to 802.11 a standard
`- Could be done as part of 802.11 e effort
`• Would not require any mods to Legacy STA
`nx2ms
`mx2ms
`~ .. - - - - -~ - - 4-------------..
`
`Spoofing Frame
`
`2ms
`
`Beacon
`
`Super frame of length 2k x 2 ms
`
`HIPERLAN / 802.1 la Compatibility Superframe
`
`Slide 6
`
`Matthew Sherman, AT&T Labs - Research
`
`Marvell Semiconductor, Inc. - Ex. 1011, Page 0010
`IPR2019-01350 (Marvell Semiconductor, Inc. v. Uniloc 2017 LLC)
`
`

`

`January 14, 2001
`
`doc.: IEEE 802.11-01/XXX
`
`"l'l'" •J'"l•; •'."'If "~f"' "II!"
`/i;,
`(i\ It,,ii ·;::;µ
`}f"
`
`IJ~
`
`<1"'" .,p•
`1[;;,, l{1!Ji
`
`"ll'I' ,;,n1,. "'"l},. •V!"h. -•V"I<.
`:;;;Jf ff;;;: i\,.,;l ·;;;;;1
`ii,,
`
`Limitations of Modified Proposal
`
`• Hidden terminal may not hear Spoofing
`frame
`• Hidden terminals may attempt transmission
`during HIPERLAN/2 phase
`
`HIPERLAN / 802.1 la Compatibility Superframe
`
`Slide 7
`
`Matthew Sherman, AT&T Labs - Research
`
`Marvell Semiconductor, Inc. - Ex. 1011, Page 0011
`IPR2019-01350 (Marvell Semiconductor, Inc. v. Uniloc 2017 LLC)
`
`

`

`"'"fJ •J}"1i •• ~ .. ;.h
`ir;;;: tL,!t ;:::f
`
`January 14, 2001
`
`doc.: IEEE 802.11-01/XXX
`
`AT&T Proposed HIPERLAN/802.11
`Compatibility Superframe Structure
`
`CFP max Length
`
`TBTT
`
`PCF
`
`2ms
`
`lx2 ms
`
`802.11 NAV Reset
`
`~
`
`DCF
`
`nx2ms
`
`mx2ms
`Super frame of length 2k x 2 ms
`HIPERLAN/2 Formats
`802.11 Formats
`802.11 Management Frames
`Optional 802.11 Management Frames
`Potential frames from Prior DCF
`HIPERLAN I 802.1 la Compatibility Superframe
`
`B-Beacon
`E-CF End
`-
`X - Blocking or Spoofing
`Frame Sequence
`Matthew Sherman, AT&T Labs - Research
`
`Slide 8
`
`Marvell Semiconductor, Inc. - Ex. 1011, Page 0012
`IPR2019-01350 (Marvell Semiconductor, Inc. v. Uniloc 2017 LLC)
`
`

`

`January 14, 2001
`
`doc.: IEEE 802.11-01/XXX
`
`Features of Proposed Superframe
`• Support for 802.1 la, 802.1 le, and HIPELAN/2
`• Beacon broadcasts CFP parameters
`- Beacon period set to sub multiple of superframe length
`- CFP max duration is set to maximum allowed size
`- NA V set in hidden terminals even if Beacon not heard
`• 802.11 broadcast messages occur after beacons
`• 802.11 Contention Free Period (CFP) follows
`under Point Coordination Function (PCF)
`• When CFP completed HIPERLAN/2 MAC frames
`are transmitted.
`- Treated as part of CFP by 802.1 la terminals
`HIPERLAN / 802.1 la Compatibility Superframe
`Slide 9
`Matthew Sherman, AT&T Labs - Research
`
`Marvell Semiconductor, Inc. - Ex. 1011, Page 0013
`IPR2019-01350 (Marvell Semiconductor, Inc. v. Uniloc 2017 LLC)
`
`

`

`''fJ.'" ,i,,.,.,, '"";! ,_l)'HV
`;;:if 11;;~~~- fi,,,ft
`1{,.-
`
`January 14, 2001
`
`doc.: IEEE 802.11-01/XXX
`
`Features of Proposed Superframe
`(Continued)
`• After HIPERLAN/2 frames, CF_End frame
`ends formal CFP for 802.11 terminals
`• Normal 802.11 Contention Period follows
`CF End under Distributed Coordination
`Function (DCF)
`• Additional Beacon Periods may be added
`to DCF if required
`- May assist with power saver mode
`
`HIPERLAN I 802.1 la Compatibility Superframe
`
`Slide 10
`
`Matthew Sherman, AT&T Labs - Research
`
`Marvell Semiconductor, Inc. - Ex. 1011, Page 0014
`IPR2019-01350 (Marvell Semiconductor, Inc. v. Uniloc 2017 LLC)
`
`

`

`'f,-,·,:,.,,'j·',•
`
`•.:,',:,:,,',.1'_ :,:
`
`1:
`
`,•,·_:,:,',• ',·_'
`
`1'
`
`,',',,',,,'.
`
`~'H.'"' •~'"'h, ,l"'l•.· '-11:'-" "liJ" •i'.>'1.•
`\110 n,, . ·{t,,i~
`
`u;, . {\,,.tf ·::;:ri
`
`l.J}·,
`
`·,,·,",',·,,.·,
`
`January 14, 2001
`
`doc.: IEEE 802.11-01/XXX
`
`Features of Proposed Superframe
`( Continued 2)
`• HIPERLAN/2 "superframe" would have fixed offset
`from 802.11 Super frame boundary
`- May be jitter on 802.11 beacon transmission due to other 802.11
`traffic
`- Reference super frame to Target Beacon Transmit Time (TBTT)
`• If Beacon Jitter is an issue, AP could transmit extra
`Beacon, Null or other frames prior to beacon with
`Short Inter-Frame Spacing (SIFS) to block other Tx's
`before Beacon Starting superframe
`- May require mod as part of 802.1 le
`• May also use Spoofing frame concept
`
`HIPERLAN I 802.11 a Compatibility Superframe
`
`Slide 11
`
`Matthew Sherman, AT&T Labs -Research
`
`Marvell Semiconductor, Inc. - Ex. 1011, Page 0015
`IPR2019-01350 (Marvell Semiconductor, Inc. v. Uniloc 2017 LLC)
`
`

`

`January 14, 2001
`
`doc.: IEEE 802.11-01/XXX
`
`Features of Proposed Superframe
`(Continued 3)
`• AP would need to manage CFP frame sizes
`closely to guarantee HIPERLAN/2 Timing
`- AP must decide to poll or refrain from polling so that
`station traffic does not overrun start of HIPERLAN/2
`superframe
`- Easier to accomplish with 802.11 e
`• Use Transmission Opportunities (TxOP) to control frame sizes
`• AP may also send spoofing frame in case new
`802.11 STA are joining/ further assurance
`• HIPERLAN/2 formats will include appropriate
`constructs to guarantee that periods allocated to
`802.11 are not overrun
`
`HIPERLAN / 802.1 la Compatibility Superframe
`
`Slide 12
`
`Matthew Sherman, AT&T Labs -Research
`
`Marvell Semiconductor, Inc. - Ex. 1011, Page 0016
`IPR2019-01350 (Marvell Semiconductor, Inc. v. Uniloc 2017 LLC)
`
`